Lync Enterprise Voice Best Practices - Extensions

In earlier posts, I've tried to outline what I consider to be best practices when it comes to Enterprise Voice in Lync.  There hasn't been a lot of detailed guidance on the subject, and while "my" way is certainly not the only way to do things, it has worked well for me and the other Lync consultants in my company.  If you haven't read my other posts on the subject, here they are in order:

http://profsmythe.blogspot.com /2010/12/enterprise-voice-best-practices-in-lync.html">E.164 Formatting

http://profsmythe.blogspot.com /2011/01/enterprise-voice-best-practices-in-lync.html">Normalization

http://profsmythe.blogspot.com /2011/01/enterprise-voice-best-practices-in-lync_21.html">Usages and Routes

In http://profsmythe.blogspot.com /2010/12/enterprise-voice-best-practices-in-lync.html">E.164 Formatting, I briefly touched on how to manage extensions for companies that don't use Direct Inward Dialing (DID) numbers for their users.  DIDs are usually known as "direct numbers", where you don't have to dial a central number to speak to a receptionist (or auto-attendant) to reach your target user. For cost, business or technical reasons, a company may not use DIDs for their internal users.  Instead, they assign everyone an extension off a main office number.

So, how to best handle this sort of situation in Lync? As mentioned in the E.164 formatting post, you should always use E.164 format for all your phone numbers.  For extensions, this should be:

+<country code><area or city code><local number>;ext=<internal extension>
Example:  +15197772222;ext=2345

For consistency more than anything, every number in a given office should have the same main number, followed by a unique extension.  Don't give in to the urge to just assign extensions to your users.  You will make your life difficult down the road when you have to deal with multiple locations and special routing scenarios.  Ideally, each office should use unique extension range, even if it is technically allowed to use the same extension (assuming the main number is different for each site).  For example, while the below example is allowed because the entire phone number is unique, even though the extensions are the same:

Bob at Waterloo Office: +15197778888;ext=2345
Lara at Toronto Office: +14163334444;ext=2345

it's better to have something like this:

Bob at Waterloo Office: +15197778888;ext=2345
Lara at Toronto Office: +14163334444;ext=3456

This way, you can easily create normalization rules so users can dial by extension across the company (even though they will likely dial by name most often).  Examples:

^(2\d{3})$ --> normalize to +15197778888;ext=$1
^(3\d{3})$ --> normalize to +14163334444;ext=$1

For outbound calling, the PSTN likely won't recognize the ;ext= format in the user's Caller ID and may default to show the main office number, but if it doesn't work, you can always use the Alternate caller ID in a route to make sure the main office number is sent as the Caller ID.

One thing to stress is that you cannot use the office number alone for any purpose in Lync if you've used that number for your extensions.  If you're using +14163334444;ext=3xxx for your users, you cannot use +14163334444 by itself for your Exchange auto-attendant or Response Group.  If you try this, all inbound calls will fail with an error along the lines of "485 Ambiguous".  If you find yourself in a situation where you are getting "485 Ambiguous", try using Tom Arbuthnot's Get-LyncNumberAssignment script that will help locate any rouge numbers that may be assigned to UM, common area phones etc.

If you've set up extension dialing and are getting the dreaded "485 Ambiguous" when trying to reach someone, its likely because you have defined your office number somewhere without an extension. 

To properly handle your auto-attendant or Response Group, it should be assigned an extension just as you would for any other user.  To make sure it will answer all inbound calls, create a pool-level dial plan that converts the main office number to the proper extension for your auto-attendant/response group.  For example:

Main office number: +12127778888
Main office response group: +12127778888;ext=2000

The pool-level normalization rule would be something like this:

^(12127778888)$ --> +12127778888;ext=2000

All calls coming into the main office number should be automatically routed to the appropriate auto-attendant/response group.

In conclusion, I hope this post answers a lot of the questions that come up with how to best handle extensions in Lync.  While there is nothing stopping you from assigning just the extension to the user, I truly believe that starting off with a consistent deployment around E.164 will make your life easier and will help prevent issues down the road.

UPDATE 22-Jul-2011:

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 +.

There are several workarounds:

1. If you are using a 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://profsmythe.blogspot.com /2012/02/re-routing-incoming-calls-to.html" target="_blank">Create an MSPL script to forward the incoming number to the autoattendant directly.

I've confirmed this is the expected behaviour for Lync.  I've made my case to the right people, so maybe we'll see a change in the future.