Questo sito utilizza cookie di profilazione (propri e di terze parti) per ottimizzare la tua esperienza online e per inviarti pubblicità in linea con le tue preferenze. Continuando a utilizzare questo sito senza modificare le tue preferenze acconsenti all’uso dei cookie. Se vuoi saperne di più o negare il consenso a tutti o ad alcuni cookie clicca qui>
The website that you are visiting also provides Arabian language. Do you wish to switch language version?
يوفر موقع الويب الذي تزوره المحتوى باللغة العربية أيضًا. هل ترغب في تبديل إصدار اللغة؟
The website that you are visiting also provides Russia language Do you wish to switch language version?
Данный сайт есть в английской версии. Желаете ли Вы перейти на английскую версию?
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: firstname.lastname@example.org, we can see the codec in sdp body is iLBC:
But we have not configured ilbc codec for mrfc:
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.
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.