SIP Extension( Agent) via SIP trunk no audio 1

[Vivek2005]

Hi Guys,

I have SIP trunk and TFN all are routed to SIP trunk.
I have SIP Extension and Agent is login( we moved couple of H.323 phone to SIP), where agent log-in and Auto-IN for ready state, when the call come its answered and its complete dead air( No audio).

However, it works fine when the Agent is Aux state and Auto-in seeing a call in Queue.( like when call is in Queue saying all agents as busy pl wait) during this period if the user Auto-in ( from Aux mode to Auto-in) and picks call the call will be fine. No issues.

Issue is only when agents is Ready state to take calls.

Note: There is no issue on the calls from T1 circuit

SIP station registered via SM.

SIP trunk is via ADTRAN

Thank you!!!

 

[kyle555]

Get a trace. With call center stuff, the quick media changes in the signaling messages can confuse SIP trunks and/or CM.

I presume there's a VDN/vector involved. Does that vector have as a first step "queue to skill 1"? Add a wait 1 or 2 seconds hearing silence or ringback and it'll probably slow things down enough to fix it.

 

[Vivek2005]

Thanks Kylee!! vector have the steps as below

01 wait-time 2 secs hearing ringback
02 goto step 9 if E = 1
03 queue-to skill 700 pri m
04 announcement 2779
05 wait-time 30 secs hearing music
06 goto step 4 if unconditionally
07 stop

 

[kyle555]

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.

 

[Vivek2005]

Thank you Kylee! let me investigate again!!!

 

[Vivek2005]

Also this works on IP Phone no issue..

 

[kyle555]

Cool. So compare a traceSBC of the H323 vs SIP phone and the messaging in/out of CM and the carrier and you'll probably see some difference of with the sendonly/recvonly

 

[Vivek2005]

Will do that and update you my findings.