No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Application server changing the SDP causes no call hold music when the B party hold the call

Publication Date:  2012-08-06 Views:  62 Downloads:  0
Issue Description
In the site IMS network deployed together with application server ETAS9960. IMS and NGN connected by SIP trunk to route the PSTN calls.
A user who register with IMS core and subscribbed to also a ETAS user (User A)make a call to user B who is a PSTN subscriber. B Answer the call and then hold the call.
User A cannot hear call hold music or anything.
Alarm Information
There were lot of complaints from the IMS subscribers saying calls suddenly get mute. specially when IMS users dial a IVR number in the PSTN. because normally when dial a IVR first IVR answer the call play an annoucement and then hold the call untill route to destination.
Handling Process
according to normal call flow for call hold, INVITE message should be with  a=sendonly  and the response 200 OK message with 
a-recvonly.
With the expert help found the related configuration which controlled the changing SDP as below.
use3264Hold = True
After set this parameter to false call hold tone can be hear. and also in the signaling ETAS not changing the SDP.
Root Cause
01. Since the complaint was cannot call to PSTN IVR number, we have made test call to same IVR and observed.
02. From test calls observed that call get connected and then when the call is hold by IVR we cannot hear the call hold tone.
03. Then checked the signaling messages.
04. When the B party hold the call IMS core receive the INVITE from other NE(NGN) with SDP and a=sendonly attribute.
05. This INVITE message is received by application server (ETAS9960) and send to caller ( User A ) but SDP has changed to ,
a=inactive.
06. So a=inactive causes terminal to not prepare the RTP port and it will be the reason for no call hold tone.
Please check the attachment Call hold eror_call flow trace from AS.txt for signaling trace from ETAS9960.
Suggestions
Call hold tone is provided by the party who initiated the hold. So in this case first we might think B side ( PSTN ) should check. But since carefully cahecked the signaling able to find the cause.

END