Tuesday, 4 December 2018

MoH - Skype, AudioCodes and an SIP Carrier

Troubleshooting an MoH issue today, where a SfB client would places a PSTN caller on hold, and the PSTN caller would get no MoH.  

SBC connection to PSTN was via a SIP trunk.

What I found was:
When call placed on hold from SfB client the INVITE had sdp of a=sendonly
This was received by the SBC and the AudioCodes "Remote Hold Format" on the IP Profile associated with the Skype side was set to "Transparent"

The "Remote Hold Format" on the ITSP side was also set to "Transparent"

In this instance the INVITE was forward to the carrier with an a=sendonly attribute.

But the ITSP would reply with a "200 OK" but the attribute was set to a=inactive.  This effectively shutdown the media path and the ITSP would not get the MoH stream from the SBC.



The Fix:
After reading the manual for the AudioCodes SBC and seeing what all the values in the "Remote Hold Format"



  • Transparent = (Default) Device forwards SDP as is.
  • Send Only = Device sends SDP with 'a=sendonly'.
  • Send Only Zero ip = Device sends SDP with 'a=sendonly' and 'c=0.0.0.0'.
  • Inactive = Device sends SDP with 'a=inactive'.
  • Inactive Zero ip = Device sends SDP with 'a=inactive' and 'c=0.0.0.0'.
  • Not Supported = This option can be used when the remote side does not support call hold. The device terminates call hold requests received on the leg interfacing with the initiator of the call hold, and replies to this initiator with a SIP 200 OK response. However, call retrieve (resume) requests received from the initiator are forwarded to the remote side. The device can play a held tone to the held party if the 'SBC Play Held Tone' parameter is set to Yes.
  • Hold and Retrieve Not Supported = This option can be used when the remote side does not support call hold and retrieve (resume). The device terminates call hold and call retrieve requests received on the leg interfacing with the initiator of the call hold/retrieve, and replies to this initiator with a SIP 200 OK response. Therefore, the device does not forward call hold and/or retrieve requests to the remote side.
When the "Remote Hold Format" on the IP Profile associated with the ITSP was change to Hold and Retrieve Not Supported, the behavior of the SBC was changed to that once it received the INVITE with a=sendonly, it did NOT forward to the ITSP, so the media path was never altered from SBC to ITSP, and MoH was then played to the PSTN caller..





Teams Tracing/Logging

This post is to outline the logging/tracing items for a MS Teams environment, most of the tracing will be from the Teams Client/Web App/etc....