Dead air after agent unhold the call with customer

[avaya137xx]

we have huge impact right now one business , anyone can help
when the avaya one-x agent (work from home agents) place the customer on hold and wait for 1 or 2 min and come back to call it was dead air.
this is intermittent issue .

call type - PSTN
trunk - SIP Carrier
ISP - Verizon
Avaya CM - 8.1.2
Media resource -- medpro ( g650) , G450 , Media-server ( call can pick any of the media resource type )
phone- H.323

 

[kyle555]

Gotta see the SDP in the trace to take the call off hold

 

[avaya137xx]

our call flow is just huge and its intermittent
so how do we look at SM trace

 

[avaya137xx]

I assume it should be our avaya our media server .
any idea how to troubleshoot on AMS

 

[kyle555]

I'd start with the SBC side. A normal hold will look something like this:

I'm an Avaya PBX, you're the PSTN.

I send you a reinvite with SDP with a=sendonly - that's me sending you music and me not listening to you
You 200OK with recvonly indicating you're willing to listen to my hold music
On unhold, I send you a reinvite with no SDP - that's to solicit all media capabilities from you. If we were G711 before, that's fine, but if you support 722 and 729, you'd 200OK with SDP with a=sendrecv and saying you support 711, 722, 719
I reply with ACK with SDP with my media capabilities and a=sendrecv

Sometimes if there's stuff happening too quick, it can fool the SBC. Especially things like reinvite handling on your interworking profiles - that's where it stores a SDP offer from the start of the call offering 2way audio and uses that instead of the reinvite without SDP when I unhold toward you in case your PSTN doesn't support reinvite without SDP.

So, if you see it staying one-way audio in terms of SDP between the SBCs, you have a signaling problem.
If the same sendonly comes from your Aura stack when you unhold, you have an Aura problem
If the unhold elicits sendrecv from both sides, you have an RTP problem.

Start between the SBCs and work backward from there.

 

[avaya137xx]

its a Sonus SBC.

we have them involved in the call , still troubleshoot going on .
Codec here is G.729.
keep you posted what they look at SDP message

 

[avaya137xx]

Something interesting going on

We have increased the audio / video audit termination time to 600000 from 300000 now....it quite resolved the issue.

But we still see the event in the avaya media serevr.

"Media audit session terminated due to inactive media"

Can anyone explain why this is happening.

 

[kyle555]

Well, it shouldn't be after unhold with the customer then, it should be at a certain point in time. Basically that's the Media Server tearing down a call when the signaling has it believe it SHOULD have audio and isn't.

 

[avaya137xx]

intrestingly , this is fixed after chnaging the on the SIP trunk below parametr

hold/unhold notification - yes /no.

we set it to no and it fixed