Friday, May 20, 2011

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:

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

29 comments:

  1. It works if you have no VIP with DID and few branches.
    1. For each branche we need to create Dial Plan to let users to use short numbers to call to their city.
    2. In each Dial Plan we need to create all rules like "^(2\d{3})$ --> normalize to +15197778888;ext=$1" and exclusions for each VIP

    ReplyDelete
  2. Just want to congratulate you for the job well done.
    I'm learning a lot from the blog.

    ReplyDelete
  3. I tried this, but have the problem that calls from a media gateway, where the caller is using ext=#### do not route correctly. Lync logs a SIP error "Multiple users associated with the source phone number"

    ReplyDelete
  4. You've got to make sure that there are no users assigned to that number without an extension. If you have 99 users assigned to +12223334444;ext=2xx and just one user/response group/teleconference number with +12223334444 without an extension, you'll get an error.

    ReplyDelete
  5. This is a great article. I am stock with extension calling with the main number. Can you explain no how to setup an exchange auto-attendant handle extension call with main number. How do you define a pool-level normalization rule for the auto-attendant? How do I define the Exchange Auto Attendant pilot identifier with extension?

    ReplyDelete
  6. With Exchange auto-attendants, its a little different. The pilot number you define in Exchange doesn't allow you to use ;ext= in the number, but this doesn't really matter. You can use any number there. When you use the OCSUMUtil.exe to create the Lync contact objects, I recommend that you don't use the suggested number that comes from the AA, but to define a properly defined number with the ;ext=. After that, just create the pool-level dial plan that translates the main office number to the full E.164 with extension as described in the article.

    ReplyDelete
    Replies
    1. Would it be possible for you to elaborate on how to create that pool level dial plan? Dial plans have been a huge source of confusion for me and I don't really understand them at all.

      Delete
  7. Ken,

    Thanks for the clarification. It works. I have branch office with 10 people and they share the same main office number. Which method is better to handle the extension call (response group/AA)?

    Once again Thank you for your help.

    ReplyDelete
  8. It depends on your needs (I know, not the answer you're looking for). I actually end up doing both in most cases. The way I found works well is to create a response group that can be answered by a live receptionist(s). I have it failover to an AA if the receptionist doesn't answer after 30 seconds, or if its afterhours.

    I think this will make a good topic for a post! Thanks for the idea!

    ReplyDelete
  9. I have tried to get extensions to work, but they fail with a "SIP/2.0 485 Ambiguous" error. Microsoft Premier Services says it is a known bug. How did you get this to work when they can not?

    ReplyDelete
  10. Hey John,
    Are you trying to set this up to route directly to an AA or a response group? I've had great success doing it this way to a response group, but it seems as though it doesn't work if routing directly to an Exchange AA (just tested today).

    I will dig deeper and see if I can find out what's going on.

    ReplyDelete
  11. The issue for me is a bug in the process that does the Reverse Name Lookup in Lync routing. It has nothing to do with the destination phone number - that routes just fine. In this bug, the RNL does not get the extension. For example, a SIP Invite From +15551234567;ext=1000, it does a RNL on +15551234567 and gets multiple entries, and fails to route the call with a "SIP/2.0 485 Ambiguous" error. I have been told it will be fixed in CU4.

    ReplyDelete
  12. And it happens if you have a NON-DID number => Team Group in Lync.

    The first call will work fine - but none of the team members will ring, and if you do a trace you get "Ambiguous".

    So there is no real workaround - since if you normalize the number correctly, it will surely error out.

    Please tell me they will have a fix before October. :)

    ReplyDelete
  13. I might be missing something how to I setup a normalised rule to dial internal all ext start at 300 and end at 700

    ReplyDelete
    Replies
    1. Hey Frank,
      You can use the Lync Dialing Rule Optimizer to generate dialing rules for extensions. Using your digits as an example, I would create a normalization rule like this:

      ^(30[0-9]|3[1-9][0-9]|[4-6][0-9][0-9]|700)$ --> +15552223333;ext=$1 (replace 15552223333 with the main office number for that location.

      This assumes you've set everyone in Lync with their phone numbers setup like tel:+15552223333;ext=333 etc.

      Ken

      Delete
  14. Im Trying to use your best practice for extensions. When I use them internally everything works great as far as normalization and RNLs. When I have a call come over a trunk however I get a sip 485. Any Ideas? THe number is used no where else without an ext.

    ReplyDelete
    Replies
    1. Did you make note of the update at the bottom of the page about incoming calls prepended with a + sign?

      Ken

      Delete
  15. Hi
    I have a customer that have DDI's however they only have 30 DDI but 60 staff. How best approach the method of assigning numbers to all staff but still be able to assign 30 DDI's to select people?

    For example. Do I assign everyone the mainline number then assign an extension, then create a dialplan normalisation rule to convert a DDI number to one to the mainline number with extention?

    Thank you
    Neo

    ReplyDelete
    Replies
    1. I would assign the DIDs to the appropriate people who would benefit the most from having DIDs (executives, sales...that sort of thing). Save a bunch for things like teleconferencing, voicemail access etc. Assign those DIDs directly to the Lync users. The remainder should have an extension off the main number.

      Delete
  16. So for example, if my DiD's were 324600 to 630, a user would get the URI of tel:+441878324600 and a non DID user would get the main line number of i.e. tel:+441878324599;ext=200 ?

    If so, if I wanted internal user to ring a users extension I would create a normalisation rule to add the first part before the DDI and have a different rule for non DID users?

    If I understand you correctly, I can have both URI's that do, and do not have the ;ext at the end in the same deployment?
    Thank you.

    ReplyDelete
  17. Ken, I see one problem with this solution. First inbound calls are easy to address with Audiocdes since audiocdes can be setup to add the ";ext=XXXX" on the inbound call before passing to Lync. However, the propblem exists with Lync calls to the main number of a location. So if you are a large operation with some 20+ international sites on Lync and each site uses Non-DID nunmbers and this convention, then you would have to have 20+ Normalization rules in each sites dial plan for each of the main numbers so that users at each site can call the main number of each site. This is what I am trying to resolve right now and trying to decide if I should change my base numbers to dummy numbers or put all the normalization rules in each of my dial plans.

    ReplyDelete
    Replies
    1. If you use the same extension for each of the sites (say ext=0000), then you can create a single normalization rule that will include every main office number and just append the ;ext=0000 to the end of it. Something like (4420123456|396123456) and normalize to \+$1;ext=0000

      Ken

      Delete
  18. Hello Ken,
    I am getting the sip error 2.0\485 ambiguous error. This is my set up.
    I have used your nomralization rules and set up Tel:+14509011234;ext=7xxx ( for Lync extensions) and +14509011234;ext=1xx ( for pbx extensions).
    I can dial out from Lync to PBX and Outside but cannot receive calls from PSTN. I get the sip error via logs.
    How do I create a RNL ? better still how I do resolve the Issue ?When I attempt to remove the (+) from the normalization rule. I get error 403 - source address not available.
    Kinda run out of ideas on what to do.

    ReplyDelete
    Replies
    1. Check everything that has a phone number defined in Lync, including users, common area phones, response group queues, dial-in conferencing access numbers and Exchange AA objects. You will likely see that somewhere you've defined an object with a phone number of Tel:+14509011234 (without an extension). Either that, or the phone numbers that are coming into Lync have the + sign already prepended to it. If so, then Lync won't attempt normalization (as I mentioned in the blog update).

      Ken

      Delete
    2. Hello Ken,
      I am able to dial out through the PSTN and Receive calls at my Lync extensions . However I am unable to receive calls on my lync extensions via the PBX phones that have their extensions set up using your normalization rules. However I can get calls from other extensions that are not included in that normalization setting. . I get the error message 485 Ambiguous.

      Delete
  19. Okay I promised that if I figured it out I will post my solution.
    My installation consisted of a Ip Pbx tied to an Ip-edge with mediatrix as a gateway.
    I was stumped at the 485 ambiguous error.
    1. I checked and all users including AA were assigned an extension.
    2. The plus sign was not in any of the logs. Neither in the From address nor the To address.
    How we resolved the issue was critically understanding what the error message was saying which was multiple phone numbers attached to source phone hence when we tried to dial from the 3 digit pbx phones because we used used Ken's optimiser we entered the E164 of both lync extensions and pbx extensions ( perhaps that was the issue - no need to enter the pbx extension when using ken's amazing script - Just your lync extensions) in any case even though the logs were not showing that the E164 was used when dialing lync extensions from the pbx phones. It was the only thing that made sense because we could dial lync extensions from those phones that were not included in the normalization script. So by removing the main number from the dialing plan resolved the issue. Phew !!

    ReplyDelete
    Replies
    1. Hey Richard,
      Glad you found a solution. I came across this once before in a similar situation, and had to resort to the same solution. It bugs me, because I don't think you should have to do this. It smells like a bug to me. I'm going to do more investigation now.

      Ken

      Delete
    2. Hey Richard,
      Turns out that the January 2014 CU for Lync fixes the 485 Ambiguous issue you're talking about. I've already heard of several others who've applied it and had the problem go away.

      Ken

      Delete