Info Lync Bug with Incoming E.164 Phone Numbers?

If your company uses internal extensions instead of DIDs for your users, you may have come across http://moymoycikukecik.blogspot.com /2011/05/enterprise-voice-best-practices-in-lync.html">my blog post on how to best setup Lync Enterprise Voice for internal extensions.

There appears to be an issue with using my method of using the main office number as a base for all internal extensions in certain circumstances. The issue seems to arise when the incoming phone number coming from the PSTN is prepended with a plus sign (a properly formatted E.164 phone number). When Lync sees an incoming call that starts with a +, it assumes the number is properly formatted and does not apply any translation rules. Since my method relies on a translation rule to add a ;ext=<ext> to ensure the incoming call is going to a unique number, Lync will return a 485 Ambiguous (because there are many numbers with the main number as a base) and drop the call.

This only occurs in situations where incoming calls are prepended with a plus sign. This will typically occur when using SIP providers or PSTN gateways (AudioCodes, Dialogic etc) that prefix incoming calls with a +.  I verified this with a client that has both a PSTN connection via a Dialogic (that doesn't add a + to incoming calls) and a SIP provider that does add a + to incoming calls).

There are several workarounds:

1. If you are using a Direct SIP provider, they may be able to not send the + to your Lync server. Call your provider and ask if this is an option.
2. If you are using a PSTN gateway or IP-PBX that is sending a +, you should be able to easily modify the incoming rule to drop the + sign (as your rule is most likely explicitly adding a +)
3. http://moymoycikukecik.blogspot.com /2012/02/re-routing-incoming-calls-to.html" target="_blank">Use an MSPL script to re-route incoming calls to the appropriate auto-attendant.

I've confirmed that this behaviour is by design.  I've brought up these cases as an example to the proper people, so maybe we'll see this changed in a future release.