I encountered an interesting situation this week where a user’s calls wouldn’t sim-ring. All of the evidence said it was active, but it just wouldn’t happen; there was no attempt to initiate the sim-ring leg when an incoming call arrived.

Sim-ring remained visible to the client, was captured in the XML in his client’s Lync-UccApi-0.UccApilog, and all looked good via the dreaded SEFAUtil. We could remove and reinstate it repeatedly to no avail.

I should mention that it’s working OK for others in the office, so it’s not going to be some system-wide issue like bad gateway config.

I’ve seen strangeness like this before that turned out to be related to the mobile client, so I ran the indispensable Get-CsConnections.ps1 to see how many client devices he was using. This gave me my most interesting clue so far: everyone else in the office is on the Office 2013 client – this dude? 2016!

As he’s the only one in the office on client “16” I asked him to disable the sim-ring, sign out, move to a “15” version of the client, sign back in, re-establish sim-ring and test. Nope.

I then compared his account in Lync to one of those for whom sim-ring is working. They had different voice policies, each with custom sim-ring pstn usages:

Alas, changing his voice policy to align with his colleague wasn’t the fix either.

By this stage I’ve decided it’s definitely corruption somewhere, so I flipped him briefly to the other FE they conveniently happen to have in their Topology and back again. That’s my ‘go-to’ fix for all sorts of user-specific strangeness – but it wasn’t going to be the cure this time.

It was about now that I stumbled across this error in the Front-End’s event log, confirming (at least as far as I’m concerned) that it’s definitely due to Office 2016:

User <sipaddress> provided a routing document with errors.
Default call handling was applied instead. Merge conflict. Wait total present in both preambles.
Problems with this user's routing documents will not be reported again for another hour.
Cause: A new or experimental user agent my have published a routing document with errors.
Resolution:
Replace the user agent that published the defective configuration.

I only had a couple of tricks left up my sleeve:

• Setting him for PC-PC only and back to EV didn’t fix it.
• DBAnalyze didn’t reveal anything that I noticed.
• Update-CsUserDatabase maybe? Nuh.

And so it came to pass that I had to play my last card. Deleting him from Lync and re-enabling him was the fix. I never like doing that – it’s a bit of a sign of defeat from a diagnosticians perspective – but I guess this is today’s IT: so I just turned him off and back on again.

 
– G.