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.
Did you resolve this issue eventually or just disable MoH?
We seem to be having the same issue.
the media attribute is really important for call on hold/media on hold. Unfortunately this is for example is not explicitly mentioned by RFC 5359, so I am not surprised that some providers might have a misunderstanding of the specification.
Started having the one way audio problem intermittently with some users. From our SIP traces it appears that Skype for Business 2015 (Lync) sends an a=sendonly when the call is put on hold, but sends the same a=sendonly when the call is resumed from hold, resulting (correctly but not desired) in one way audio.
This appears to be a fault with Skype for Business, that it does not correctly send a=sendrecv when the call is resumed. I tried to repeat the error with uses who have experienced this problem, and it worked every time (as it does when IT calls you back). This is either intermittent, or it requires a special set of circumstances to cause the fault.
Cheers,
Finn