You need to look at a full trace and look at the SDP media offers to/from the carrier and CM and possibly the phone.
You're obviously running into some sort of compatibility issue. Is there a devconnect note for your carrier? Even if there was, it usually includes the basics like MWI, call forwarding, conference/transfer and not ACD stuff.
If you have a H323 or digital phone, does it have the same problem with a call coming in on the SIP trunk to the ACD?
You said the problem happens when the agent is "auto-in" and available when the call arrives, but not if the call were queued. Is it still the case whether the call is auto-answer or not?
What you're ultimately looking for in the message exchange between you and the carrier is the SDP parts which can be in INVITEs, ACKs, 200OKs, UPDATEs, 1xx level messages, and you're going to see it update several times.
As a simple example, a H323 phone calling out a SIP trunk where that SIP sig group does not have "h323 station outgoing direct media" will have an offer from CM-->SM-->SBC of "the IP of a media gateway".
Once the call is answered and CM shuffles the gateway out, it'll send a reinvite to SM/SBC with the IP of the phone in the C= line of the SDP.
The SBC will send a reinvite to the carrier with new SDP as well, except the carrier doesn't know or care what you're internal IPs are, or that you changed the internal IP. Your SBC's reinvite will ask the carrier to send to the same B1 IP and port as before. It would be the same if that H323 phone transferred the call to another H323 phone - 1 reinvite to get the gateway back, another reinvite to shuffle the 2nd h323 phone right to the SBC. That'll all pass out to the carrier as "reinvite: same B1 IP and Port Please!"
The SBC has a feature called reinvite handling where it stores the last media offer in an invite message and if another invite would go out with the same parameters, it just doesn't bother forwarding to the carrier because it's unnecessary.
In any case, the situation gets more complex when things are juggling around - there's holds and one way segments, like listening to hold music, where CM might send out SDP with a line like 'a=sendonly' meaning "hey, I'm not listening to anything you have to say, you're listening to my hold music!" and the carrier should reply with a=recvonly.
The point is that you will run into trouble with different vendor equipment and configurations in how they interpret they should go down from 2 way to 1 way or no way audio and back to 2 way audio and it certainly sounds like you've found a gap. Knowing how that looks in signaling, with traces, will be vital to getting support from either Avaya and/or your carrier.
Go read the release notes for the latest service pack for your version. They list all the fixes of all previous service packs and maybe you'll find your case in there.
Depending how many people use that trunk/how many SIP agents you have/etc you might be able to disable shuffling for those phones or the trunk group if you have the DSPs to spare or find some other configuration workaround that changes the signaling just enough to trip up either CM or your carrier.
