Recently, we’ve discovered an issue with “call on hold” functionality in combination with a Cisco CUBE as cpe for Direct SIP-Trunking with Lync 2013.
In this situation, we enabled Music on Hold (which is disabled by default), while also respecting all settings and configuration provided by the ITSP for the SIP Trunk. The situation is when we put an incoming call on hold, the lync client played the music on hold file to the calling party. When resuming the call, only the calling party could hear the called (lync) party. The employee could not hear the caller anymore.
Further analysis with the trunk provider showed us that this call, while going into hold, sent a sip media flow attribute “sendonly”. This allows only one way audio, so music can be played while preserving bandwith and/or quality.
However, when resuming the call, no new invite is sent to cancel the one way audio! As test, and eventually workaround, we now disabled the Music on Hold feature by the following command on a Lync front-end:
Set-csclientpolicy -EnableMusicOnHold $false
After restartig the Lync client and verifying the in-band client policy has been applied, we tried this again. Now no music is played, but the call could be retieved correctly with two way audio.
Now, in the on-hold state, the “sendonly” sip media flow attribute isn’t applied, but audio is cut off in both directions instead. Then, when the call is resumed, an invite with the usual “sendrecv” is sent which is understood by cube and provider, thus the call contines with bidirectional audio as expected!
Currently, there seems not to be any real solution to this problem. Music on Hold is not one of the features being tested when ITSP’s validate their trunks for the (Lync) certification, and it might be because of that, that this won’t work in certain situations.
Update July 2014:
The ITSP has followed this issue throughout with Microsoft. Microsoft (unofficially) stated that they comply with RFC3261 for the media attributes. Although they are right, apparently PBX vendors take this one a bit different as the issue only arises within Lync. Fortunately, the ITSP has changed the behavior of media attributes in their network for Lync SIP trunks, so the issue has been solved.
Bottom line: if you find yourself in this situation, give it a try to contact your ITSP and request them if they can change the media attribute behavior on the SIP trunk.