SIP485 Ambiguous Error with Exchange UM when using SIP Trunking… How to use a main line phone number with extensions to avoid this.

There is a well known issue when using an E.164 dialplan in Lync Server that includes the extension portion the dial string (such as +14165551212;ext=1000) and assigning that to an Exchange UM AutoAttendant.  If you are using a provider that sends the full E.164 number that includes the + sign in the SIP Invite, Lync will not apply any normalization rules on this inbound call, assuming that you created a normalization rule that takes the 10 digit inbound number and adds the “;ext=” portion of the string to ensure uniqueness in the phone number.  This is well documented here by Ken Lasko at http://ucken.blogspot.ca/2011/05/enterprise-voice-best-practices-in-lync.html as well as some possible workarounds. 

In a pure SIP Trunking environment most certified providers will send the full E.164 number though to the Lync Server meaning you would need to use an MSPL script or add a gateway to do the manipulation required to allow this scenario to work.  I don’t like either of these workarounds in a SIP Trunking scenario because they add complexity and cost in the case of adding a gateway.  In Canada while working with ThinkTel I found a much better way to address this scenario.  It works like this. 

Lets assume you have a Lync deployment with Exchange Unified Messaging and you have a requirement to enable all users for Enterprise Voice but don’t want to utilize Direct Inward Dial numbers (DID) for all users.  Rather, you want to have a single main office number and have the Exchange UM Auto Attendant answer the call with a Speech Enabled Auto Attendant that can ask the caller whom they want to speak with.  The caller speaks the name and the call is transferred to the Lync user that does not have a DID.  In order to make this work in a scenario where you don’t have DIDs assigned to the user you must use E.164 numbers with extensions for a couple of reasons.  You need to maintain a unique number per user in Lync but at the same time advertise the single main line number for that group of users.  (Note, you might be thinking you can do this using Trunk level settings to overwrite the CallerID which would work for a single trunk.  But if you were supporting multiple locations over a single trunk then this breaks down.

So what you will need to do standardize on a single Main Line number, say +14165551212 and then assign that number to all your users including an extension.  So for Tom Jones, you would apply the LineUri or tel:+14165551212:ext=1005.  When Tom makes an outbound call the number that is shown is only the first part of main number of the office which is exactly what you want. 

So how do we get Exchange UM to answer the call now without the nasty SIP485 errors?   Ask your provider to do a CNF or Calling Number Forward for your main number of 4165551212 to another DID.  In this case use +14165551213 for example.  Assign this number to the Exchange UM AA that will answer the main office calls.  When  callers call 4165551212 number it will be forwarded unbeknownst to the caller to the other DID number allowing Lync Server to route the call over to the Exchange UM AA. 

This allows you to use a single number per main office and assign it to the Lync Users with a unique extension all while letting Exchange UM do its thing and answer the call.  The following diagram illustrates the call flow:

 

 

You can setup this scenario as many times as you need.  For example, one per office location you are supporting of this.

Please note that while works very well using ThinkTel, it may be an option for all SIPT providers.  Its best to discuss this scenario with them during your planning phase.

Comments

[Jeff Colvin]

Just have to watch out for the calls which are redirected back to the main number when people "test" things. I had a customer call someone else, who routed calls back to them, the Calling number was their Main number and of course it was Ambiguous. Wish MS would route calls no matter whether their RNL worked or not.

Cheers,
JeffCSP

[Dino Caputo]

Thanks Jeff! So far I have had good success with this method. Agree with your comments and would add it would be good to allow for Lync and Exchange UM to both "understand" and route E.164 numbers that include extensions.