ITPRO NERDERY

Lync Hold Issue

---

In a recent Enterprise Voice deployment I struck an issue where a small number of users couldn’t place a call on hold. When they tried, the Lync client errored with “Failed to place call on hold” and instead put the client’s mic and speakers on mute. Removing this mute sometimes worked and sometimes resulted in a dropped call.

All users in this particular deployment were subject to the same client policy, same client version, same voice routing.. generally, everything was the same from one user to the next.

After running some S4/SIPStack trace logs on the gateway, and analysing the SIP Options packet that was being sent to the SIP gateway, I could see that in a working request, the SIP Invite that got sent included a=inactive (which is normal), whereas in a failing request, the Invite sent a=sendonly instead. What I couldn’t figure out was why two clients with the same settings/policy/routes would send two different hold methods. What made this particularly odd was that the user that was having the issue could log on to a different computer, and placing a call on hold would work fine.

So, issue had to be client-side.

One of the things I looked at during the debug process was the Lync registry entries. After painstakingly comparing registry keys line by line, I found that only one of the clients had the MusicOnHold registry keys listed – and it was the one that wasn’t working. Looking at the client options (Tools > Options > Alerts) showed that both had the same options selected (in this case, ‘Enable Music on Hold’ was ticked and greyed out (managed by policy), and the hold music file was populated with the default wma file), yet on the client that was working fine, the two MusicOnHold registry keys (below) were completely missing.

[HKEY_CURRENT_USERSoftwareMicrosoftCommunicator]

“MusicOnHoldDisabled”=dword:00000000

“MusicOnHoldAudioFile” =”C:Program Files (x86)Microsoft LyncMediaDefaultHold.wma”

After backing up the keys, I deleted the MusicOnHoldAudioFile key, and rebooted. Bingo. Problem solved.

Tried reinstating the key again, and sure enough, problem returned immediately.

I have come across one other customer having the same issue, and they apparently found the problem disappeared when they apply CU5, however I haven’t been able to verify that completely with them, and when I tried the CU5 update, the issue persisted.

Why exactly this happens is soon to be the subject of a support ticket with Microsoft. When I get an outcome from that, I’ll be sure to update this post.