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

MRFP does not support iLBC codec caused the operator monitor failed

Publication Date:  2012-08-06 Views:  106 Downloads:  0
Issue Description
The ims version is 8.1. when test operator monitor supplementary service we find if the caller and called are both ims subscribers the operator can monitoring the conversation successfully, but if one side is pstn user, then the operator monitoring failed.

This operator monitor supplementary service means the operator can monitor a call between two subscribers by dialing the access code of the operator monitor service + number of the target subscriber if the target subscriber has not subscribed to the forbid operator monitor service. And the main scenario is: when the operator finds a long-duration call (for example, when alarm 20032 conversation duration reaches the maximum duration allowed by the ats9900 is generated or there is a long-duration cdr on the ccf), the operator can use the operator monitor service to check whether the long-duration call is valid. if the long-duration call is invalid, the operator can run rel session in the mml command - ats9900 window to forcibly release the call.
Alarm Information
Null
Handling Process

1. Open the SCSCF, ATS and MRFC's interface tracing windows and tracing the operator IMPU and the monitored subscriber IMPU together. For the MRFC's interface trace, you should trace out the ATS message first, and find out the INVITE message which ATS send to MRFC, then use the PAI or FROM header in this INVITE to trace the MRFC's message. then, reproduce the call scenario again and save the messages.


2. Because this service is processed on ats, so we can compare the ats' messages first. from the monitored subscriber's ats message (monitored_ats_subscriber impu.ptmf) we find when ats send invite to mrfc, mrfc respond with 488 (p169). but there is no 488 in the ims to ims call messages


3. Find out the correlative invite message according to the callid in 488 response: x0qbkx8389ymb8q2gm8jgxj29pgqpbzm@ats.mai1-ats01.maaii.com.1, we can see the codec in sdp body is iLBC:

But we have not configured ilbc codec for mrfc:

add mrfpres:mrfpid=0,regionid=1,acodec=g711a-1&g711u-1&g722-0&g723_1-0&g726-0&g728-0&g729-1&gsm_fr-0&gsm_hr-0&gsm_efr-0&fr_amr-0&hr_amr-0&umts_amr-0&umts_amr_2-0&tdma_efr-0&pdc_efr-0&umts_amrwb-0&gsm-0&amr-1&amr-wb-1&
ilbc-0&evrc-1&evrc0-0&evrcb-1&evrcb0-0,vcodec=h261-0&h263-1&h264-1&mpeg4-1,capbl2833=basiccapability-1;
 
there is no intersection of codec, so mrfc respond 488.

4. When look into the message according with the operator monitor's call flow, we can see this re-invite is ats send to mrfc for asking mrfp add pstn subscriber into the 3 party conversation. before this step, ats has sent the re-invites to both ims subscriber and pstn subscriber to refresh the media negotiation and received the responses. p151 and p154 are ats refresh the media with pstn, and in p154 pstn responded with new codec: iLBC.


5. Check the ims to ims call messages we find when ats send re-invite to ims subscribers for refreshing the media, the ims subscribers have not change the codec, kept G711, that is why operator can monitor the ims to ims call normally.

6. As we know the mrfp can not support ilbc codec in ims8.1 version, it can support this codec in ims8.3. so, even if we modify the mrfpres data to add the ilbc codec, this problem can not be resolved.

7. Discussing this issue with customer, customer agrees to change the pstn setting to make it always use G711 codec. after pstn changed its setting, the problem solved.

Root Cause

Because the operator can monitor the ims to ims conversation, just can not monitor the ims to pstn conversation, so there should be something wrong with pstn network. So we can trace the interface messages of both call, and compare them to find out the differences. Then look into the difference to find out the root cause.

Suggestions
1. IMS8.1 can not support iLBC codec, but in IMS8.3 can support.
2. The call flow of operator monitor is:

(1): ue-b is talking with ue_c.
(2-3): ue_a dials the access code of the operator monitor service + number of ue_b to monitor the call between ue_b and ue_c.
(3): the as receives the invite message and triggers the operator monitor service based on the access code of the operator monitor service dialed by ue_a.
(4-7): the as sends a re-invite message to ue_b for media negotiation. ue_b returns a 200 response to the as, which contains ue_b's media.
(8-25): the as sends an invite message to the mrf, requesting conference resources for ue_a, ue_b, and ue_c. in the invite message, ue_b's media is contained and the request_uri header field is set to conference uri.
(26): conference resources are successfully requested.
(27): the as returns a 200 response to ue_a, in which the mrf's media is contained and the media direction is sendonly
(28-31): the as sends a re-invite message to ue_c to for media negotiation. ue_c returns a 200 response to as, which contains ue_c's media.
(32-35): the as sends re-invite message containing ue-c's media to the mrf, instructing the mrf to add ue_c to the three-party conference.
(36-39): the as sends ack responses to ue_b and ue_c, which contain the mrf's media.
(40): ue_b and ue_c enter the three-party conference.
(41-44): the as sends a re-invite message to ue_a for media negotiation. ue_a returns a 200 response to as, which contains ue_a's media.
(45-48): the as sends re-invite message containing ue-a's media to the mrf, instructing the mrf to add ue_a to the three-party conference.
(49-50): the as returns a 200 response to ue_a, in which the mrf's media is contained and the media direction is sendonly.
(51): ue_a enters the three-party conference. at this time, ue_a can hear ue_b and ue_c, but ue_b and ue_c cannot hear ue_a.

END