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.
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.