A Safety Net for Lync Gateway AD-Lookups

Posted by Greig Sheridan on 8 August 2012, 6:36 am

Superceded 12th Nov2012 by the Mk-II.

A not uncommon user-misconfiguration for a Lync user is to find their account possessing a LineURI (their “msRTCSIP-Line”) telephone number, but for them to not be enabled for Enterprise Voice.

This more commonly occurs in the early stages of a deployment (ahead of cutover), or as the on-site admins settle into the new product and role.

Lync doesn’t have a problem with this – but things *will* start to go awry if your gateway has AD-lookups enabled and sends calls for that phone number to Lync!

Here’s a “safety net” you can add to the NET UX1000 and UX2000 gateways that gives you some ways to better handle these calls – at least until you can fix the user accounts!

The Problem

If your user’s not enabled for Enterprise Voice and you send a call to them from the Gateway, Lync will reject it with a 504:

SIP/2.0 504 Server time-out
FROM: <sip:<CallerNumber>@1.1.1.1:5067;user=phone>;tag=a5a0121-24
TO: <sip:+612<CalledNumber>@uxsba.contoso.com;user=phone>;tag=44b819d;epid=8B8CB136CF
CSEQ: 1 INVITE
CALL-ID: call-35CA0A00-0000-0010-0C13-4@1.1.1.2
VIA: SIP/2.0/TLS 1.1.1.1:5067;branch=z9hGPS9-UX-0a5a-1111-0000
CONTENT-LENGTH: 0
SERVER: RTCC/4.0.0.0 MediationServer

Inelegant, and certainly lacking an explanation of the real cause. Viewing a trace of the Front-End with Snooper doesn’t make it any clearer either.

You can identify the offending users on your Lync with this commandlet:

Get-CsUser -filter {EnterpriseVoiceEnabled -eq $false} | where-object {$_.LineURI -ne ""} | ft identity

It’s just one of those little things you’re going to encounter every so on.

A Band-Aid

To enhance your gateway’s AD routing decision we just need to add another test to the Transformation Table to check the user’s enabled for EV. That’s easy enough to determine, because a user enabled for EV has an msRTCSIP-OptionFlags value of 385. (More reading on that here).

Thankfully the UX gives us the ability to test for the flags, through the use of one of its “user values”.

Here’s what this transformation table is doing, line-by-line:

Turn a standard 8-digit Aussie Called Number into E.164. (Note that in the real world this table would also have other entries to reformat the Calling Number as well)
If the Called Number matches an msRTCSIP-Line number, change the Called Number to the same thing. (In this case the Output Field is irrelevant and does nothing – the crucial point is the match in the Input Field)
If the Called Number = (.*) – that is to say anything – we assign the value of 385 to User Value 1.
If User Value 1 now equals the matched user’s msRTCSIP-OptionFlags, we’ll match. As with 2, the Output Field is irrelevant in this entry.

So now this table won’t be true until we match on the phone number being in AD *and* the user’s enabled for EV. If you’re in a pre-cutover stage and still running a PABX, a call that fails to meet all of these Mandatory criteria will now filter down to the next routing table entry, presumably to the user still on their PABX phone – or perhaps to be caught by our safety net.

Savvy readers might have noticed that it’s theoretically possible to combine rules 2 and 3: “if we match on msRTCSIP-Line, assign 385 to User Value 1”. That’s correct, but in so doing we’d then potentially be testing in the next line for a value of User Value 1 that hadn’t been previously declared. This didn’t sit comfortably with me, so I’ve opted to keep them as separate entries.

The Safety Net

The Safety Net looks very much like the standard AD lookup, with 1 major change – if we match on Called Number in AD, we change the Called Number to that of the safety net destination – perhaps direct to a special Response Group for the Helpdesk, to Reception, or to an Auto-Attendant.

The logic here is that this entry follows the above test for EV, so by a process of elimination, any call that reaches us does have an msRTCSIP-Line, but they’re NOT enabled for EV – and thus the safety net needs to kick in.

Here’s what the over-arching Routing Table looks like: