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

NET UX MoH

So everyone knows by now that the Lync IP phones don't support Music on Hold (MoH), the some of the early Lync phone clients would let you place calls on hold from the Lync client on the PC and then MoH would be played from the PC.  But this seems to have been "removed" as a feature during a CU update.


From version 2.1.x of the NET UX gateway you can now have MoH played to PSTN callers when a Lync IP Phone places a call on hold.

The supported file types include:

• PCMA
• PCMU
• WAV 
• PCM
• G726

The supported file must have a sampling rate of 8KHz and be a mono channel.

There is also a limit to the size of the file that can be uploaded. On the UX1000 the max file size is 1MB and 4MB for the UX2000.


Steps in configuring the UX for MoH include:
Upload the selected file to the DSP of the UX gateway, from the Settings tab, select "Media --> Media System Configuration" and select "Upload Music File"

Once the upload has been completed you will get the following "Upload Status"

Verify that the MoH file has been uploaded into the UX DSP's by selecting "System --> DSPs"

The next steps involve updating the signalling groups to allow for the MoH, select the SIP signalling group to the Lync Mediation server, there are three (3) options

• Disabled
• Always Enabled
• Enabled for 2-Way Hold Only

MoH	Meaning
Disabled	Music is never played
Always Enabled	Music is always played for the extension placed on hold. This is one-way only
Enabled for 2-Way Hold Only	Music is only played when both parties to a call have placed the call on hold. For example, if party A and party B both place the call on hold music will be heard by whichever party takes the call off hold first, indicating that the other person has placed the call on hold.

The usual setting for this value is "Always Enabled"