Inbound Number Normalization Bug in Lync (FIXED)

I came across an issue recently where a North American company had deployed Enterprise Voice using the Lync Dialing Rule Optimizer.  Outbound calling would work fine, but inbound calls would fail with a busy signal.  I was testing against a number that was supposed to route to an Exchange auto-attendant.

I ran a trace using the Snooper tool and found a big glaring red error staring at me:

404 - No matching rule has been found in the dial plan for the called number. 

The detailed error looked like this:

Direction: outgoing;source="local"
Peer: lyncpool.contoso.com:58964
Message-Type: response
Start-Line: SIP/2.0 404 No matching rule has been found in the dial plan for the called number.
From: "604xxxxxxx";epid=5A81C7C2F0;tag=b356e0ebc3
To: ;tag=FCA83E847F99452AC4A563DB1552D6C4
CSeq: 2389 INVITE
Call-ID: 9d03fadf-282b-461b-912b-fbefe95a111b
ms-application-via: LYNCMON.contoso.com_LyncMonitoring;ms-server=LYNCFE.contoso.com;ms-pool=lyncfepool.contoso.com;ms-application=51FB453D-5B9F-45df-83B4-ADD1F7E604A8
Via: SIP/2.0/TLS 10.0.5.10:58964;branch=z9hG4bK71da34d1;ms-received-port=58964;ms-received-cid=18FC00
ms-diagnostics: 14010;reason="Unable to find an exact match in the rules set";source="LYNCFE.contoso.com";CalledNumber="4165551111";ProfileName="HeadOffice";appName="TranslationService"
Server: TranslationService/4.0.0.0

The inbound phone number was coming in as 10-digits, and excluded the North American country code 1 (which isn't unusual for a lot of phone providers).  I knew the normalization rules were working properly for outbound calls, but I couldn't figure out why inbound was failing.

I zeroed in on my NA-National rule.  The rule is formatted as follows:

^1?([2-9]\d\d[2-9]\d{6})$  ----NormalizeTo----> +1$1

This rule will accept any 10-digit valid North American formatted telephone number OR any valid 11-digit North American formatted telephone number starting with a 1.  Users in many areas tend to use 10-digits and exclude the leading 1 when dialing phone numbers, or they may use the full 11-digit proper format. The NA-National rule deals with both these cases by starting the rule with 1?.  When a question mark is present in a regular expression, it means that the preceding element is optional.  So, in our case, the NA-National rule will match both 10-digit and 11-digit North American numbers.

Unfortunately, there seems to be a bug in earlier versions of Lync Server 2010 (prior to the March 2012 update from what I can tell) that results in inbound numbers failing to normalize against a rule that includes a question mark.  When I removed the 1? from the rule, inbound calls worked as expected.

Thankfully, it appears that someone at MS has already caught this and fixed it somewhere between the November 2011 Lync Server update and the March 2012 update.  I didn't try to figure out which update fixed it, but I knew it was broken on a server running the November 2011 updates, and was fixed with the March 2012 update.

If you keep up-to-date with your Lync server patches, you won't come across this bug.  So, make sure you have the latest Lync Server updates applied before running the Optimizer for North American deployments.