Friday, January 21, 2011

Lync Enterprise Voice Best Practices - Usages and Routes

Over the past while, I've typed some lengthy posts about the importance of E.164 phone number formatting and my take on normalization best practices. Now to pull it all together for the final act, I'll be talking about Lync PSTN usages and routes.

When you look at the Voice Routing section of the Lync Control Panel, you'll see the following "tabs": Dial Plan, Voice Policy, Route, PSTN Usage, Trunk Configuration and Test Voice Routing:

From this section, you can manage most aspects of your Enterprise Voice deployment.


Dial Plans were briefly discussed in my previous post.  A dial plan is a collection of normalization rules that are assigned to sites, pools or users.  Dial plans are designed to allow users to dial phone numbers as they are accustomed to, but still outputs properly formatted E.164 phone numbers, no matter what they type. When you create a dial plan at the site or pool level, all users within that site or pool whose Dial Plan Policy is set to Automatic will be assigned that policy.  There can only be one Dial Plan per site/pool.  If one dial plan is assigned to a site and another one to a pool, the pool-level policy will take precedence.  If you want more granular control, you can create user-level dial plans.  You have to assign users to the user-level Dial Plan policy either through the control panel or via Powershell.

Voice Policies define the capabilities of the users assigned to it. Capabilities can include call transfer and call forward, among others. Capabilities also include the types of calls (local, long distance, international etc) members are allowed to make via PSTN Usages.  Voice policies are assigned to users or sites. Site policies will automatically be named the same as the site, while user policies can be given whatever name suits you.

When you create a voice policy, you have the option to associate PSTN Usages to the policy. If you're just starting out, this list will be blank.

PSTN Usages
PSTN usages are the link between a voice policy and a route. The combination of the three determines the calls a user can make and what route the calls will take.  PSTN usages can contain multiple routes, and can be assigned to multiple voice policies.

You can only create PSTN usages through the Voice Policy interface. When you create PSTN usages within a specific voice policy, it will automatically link to that policy.  You can also create routes from within the PSTN Usage creation dialog box, which makes the whole creation process efficient.

PSTN usage names should relate to calls of the same type: like Local, Long Distance/National, or International. If you've got more than one site where PSTN calls will be made and has a defined PSTN gateway, its best to qualify the usages with site information (you'll see why later). I prefer (and this is the same format used for the Dialing Rule Optimizer):  country-state/prov-city-callclass or country-city-callclass.

Some examples:
NA-ON-Toronto-Local
NA-BC-Vancouver-National
NA-TX-Dallas-International
GB-London-National
IT-Rome-Local
JP-Tokyo-International

I tend to use NA (North America) instead of US and CA, because both countries share the same country code (1). Again, if you have a better scheme, go ahead and use it.  There is no right or wrong way to do this.

Routes
Once the PSTN usages are created, I then create routes. If you've followed best practices and ensured that every phone number that enters the system is formatted for E.164, this is where your diligence pays off. A route defines the actual path a call takes on its way out to the PSTN via a defined PSTN gateway. When a user makes a call, a route is selected based on two things: a matching rule (ie. 11-digit numbers starting with +1) and whether that route is part of a PSTN usage assigned to the user.

Create routes according to the calls you want to send out that particular gateway.  You can be as generic or as specific as you want.  For instance, you could create a single route called All Calls, and have a matching pattern of ^\+\d+$ (which means accept any call starting with + and at least one digit.).

I prefer to get more granular, even if I won't be imposing limits on the calls users can make. Increased granularity allows you to impose great control over call paths. For instance, you can easily setup least cost routing and backup routes by using properly formatted routes.

I like to setup at least 5 different routes for each gateway: Local, National (long distance), International, Toll-Free, and Service Codes.  As with usages and normalization rules, I like to follow the same naming convention: country-state/prov-city-routeclass or country-city-routeclass.  I assign the routes to the respective PSTN usage.  National and International routes go into the National and International PSTN usages respectively.  Local, Toll-Free and Service Codes all go into the Local PSTN usage.

For North American deployments, I highly recommend running the Dialing Rule Optimizer for creating local dialing rules for any North American phone number.

Each site should look something like this, using Ottawa as an example:
PSTN UsageRouteRule
NA-ON-Ottawa-LocalNA-ON-Ottawa-Local
NA-ON-Ottawa-TollFree
NA-ON-Ottawa-Service
^\+1613\d{7}$
^\+1(800|888|877|866|855)\d{7}$
^\+[2-9]11$
NA-ON-Ottawa-NationalNA-ON-Ottawa-National^\+1[2-9]\d{9}$
NA-ON-Ottawa-InternationalNA-ON-Ottawa-International^\+[2-9]\d{6,}$
 
Trunk Translation
With your voice policy/PSTN usages/routes all setup, calls should be routed to the proper gateway for sending out to the PSTN. However, the local PSTN provider likely has their own formatting rules for calls that may not be compatible with E.164.

To accomodate these requirements, you create trunk translation rules to add or remove digits from your E.164 formatted phone numbers before sending the call out to the PSTN.  For instance, a Toronto gateway to the PSTN might need to strip the +1 from local calls, strip the + from long distance calls and add 011 to international calls.  Again, the Dialing Rule Optimizer can help create the local ruleset for your deployment.  An example for Toronto would look something like this:
Trunk Translation Rule NamePatternTranslationSent to GW Example
NA-ON-Toronto-Local^\+1((416|647)\d{7})$14165551111
NA-ON-Toronto-National^\+(1\d{10})$$112125551111
NA-ON-Toronto-International^\+([2-9]\d{6,})$011$1011525551111
NA-ON-Toronto-Service^\+([2-9]11)$$1411

PSTN Usages Ordering
When you have all your usages and routes defined, it is very important to put your PSTN usages in the correct order in your Voice Policies.  When searching for a route, Lync will start at the top of the PSTN usage list and work its way down until it finds a functional route that matches the dialed number.  If the selected route is not available because the gateway is down or can't accept any more calls, then Lync will keep searching for a matching, working route.  Order your PSTN usages so that calls will use the cheapest toll options and also provide failover capabilities. 

Imagine you have a 3 site deployment, with offices in Vancouver, Toronto and Budapest, Hungary.  You've setup your usages and routes according to my guide.  Your PSTN usage for the Vancouver site Voice Policy would look something like this:
NA-BC-Vancouver-Local
NA-ON-Toronto-Local

NA-BC-Vancouver-National
NA-ON-Toronto-National

HU-Budapest-Local
HU-Budapest-National
NA-BC-Vancouver-International
NA-ON-Toronto-International
HU-Budapest-International

In this manner, calls will use the least-cost route for any given call, and should the preferred route not be available, the call will use the next cheapest available option.  The most used usages are positioned at the top to reduce call connection time.  Because every phone number is normalized to E.164, it can be easily routed to any gateway, which will then add any necessary routing codes (like 011) before sending it out.  This may take a fair bit of work to setup, especially with a large deployment with several sites, but I think the benefits outweigh the time involved in setting it up.

Of course, with the flexibility provided by Lync, this is just one method of setting up your Enterprise Voice deployment.  If you've got other ideas or methods, I'd love to hear them.

49 comments:

  1. Great post!

    There is a error in your Toll Free PSTN usage rule. It should be ^\+1(800|888|877|866|855)\d{7}$

    ReplyDelete
  2. Whoops...thanks for that. I'll fix right away.

    ReplyDelete
  3. great post! exactly what i need now. Thanks!

    ReplyDelete
  4. Hi is there any rule i can create that says for instance: for any call placed from lync to internal IP phones and PSTN phones, send it to the PBX.

    ReplyDelete
  5. You can create a blanket rule that just forwards everything to the PBX. The default route that Lync creates can do that job for you. If you dial a number and it doesn't match an Enterprise Voice enabled user, it will route out to your PBX.

    Ken

    ReplyDelete
  6. Very helpful! I ran into the "builder does not support advanced expressions" error when trying to add routes that match an exact number of digits with a $ at the end. Looks like you can't do it through the GUI, but the New-CsVoiceRoute command lets you add routes that match exact digits. Thanks again.

    ReplyDelete
  7. Ken great post, very useful.

    Question - What would cause some users to have have good call quality (external calls), while others have choppy calls?

    We have ruled out the gateway or network/data/switch issues.

    All internal or Lync to Lync calls are excellent even to external (federated)

    Its just strange

    Any ideas?

    ReplyDelete
  8. I would need to know more about your environment before I could make a guess. How are you connecting to the PSTN? Via a gateway? Direct SIP? Have you deployed the monitoring server? If not, I highly recommend it. The monitoring server reports will give you a very good idea where the problem lies.

    Ken

    ReplyDelete
  9. I have just set up our Lync environment but when I try to make calls outside, it comes up on the lync client as {number} is set to Do Not Disturb. I've tried multiple numbers to no end. Any help would be appreciated!

    ReplyDelete
  10. Hi there,
    I suspect you've got your dialing rules setup incorrectly. Can you share your details?

    Ken

    ReplyDelete
  11. Don't you believe you get lost when you are using same name for:
    PSTN usage: NA-ON-Ottawa-Local
    Route: NA-ON-Ottawa-Local
    Trunk Translation rule name: NA-ON-Ottawa-Local (assumed so, even you change the city)

    ReplyDelete
  12. Hey Anonymous,
    Sure you might get confused seeing the same name on the same page, but its all about context. Every time you see a route/usage/translation rule its pretty clear what section you're in. I feel that its redundant to include Usage/Route/TranslationRule. However, that's just me. If enough people tell me otherwise, I'd be happy to change it.

    Ken

    ReplyDelete
  13. You had easy international rule:
    NA-ON-Ottawa-International ^\+[2-9]\d{6,}$ As there are no other country who have code "+1".

    But how you make if your Lync is in Panama (+507) how to get international calls where country code is Paraguya (+597) or Peru (+51)?

    ReplyDelete
  14. Hi Anonymous,
    It's just as easy to deal with a country like Panama as any other country. You will have local routes that are higher priority than the international route. So, in your case, you would have something like this:

    PA-PanamaCity-National: ^\+507\d{7}$
    PA-PanamaCity-International: ^\+[1-9]\d{6,)$

    When a call comes through starting with +507, the National rule will take precedence. If it doesn't start with +507, the International rule will be the next match.

    Ken

    ReplyDelete
  15. Hi Ken,
    I have a branch office that will not be on Lync and have their own phone system. They do use Lync for IMing and such but not EV. Is there a way to setup Lync to Tranfer the call to their main number if someone selects a user in the Find by name option.

    ReplyDelete
  16. Hey Carolyn,
    What you can do is to set the office number of the branch office users in Active Directory to the branch office phone number. That way when EV Lync users select those users, the call will route to the branch office main number.

    Even better, add the users extension to the end of the number. It won't route calls to them directly, but it will give your EV users a visual reminder on the extension. For example, if your branch office number is 12125551111 and a user's extension there is 222, I would set the office number for that user's AD account to +1.212.555.1111;ext=222

    Ken

    ReplyDelete
  17. ** The Toll Free PSTN usage rule should be ^\+1(800|888|877|866|855)\d{7}$ **

    Having found the first "8" once, there's no need to keep on parsing from the beginning to find it again.

    Try this:

    ^\+18(00|88|77|66|55)\d{7}$

    ReplyDelete
  18. Thanks for the tip! I've updated the rule in the optimizer accordingly.

    Ken

    ReplyDelete
  19. Replies
    1. I mean to the Dialing Rule Optimizer.

      Delete
    2. I looked into creating dialing rules for Russia, and it appears that things are in flux and are changing quickly. If I were to attempt this, I would need some help from you with developing the rules.

      Ken

      Delete
  20. I'm new to EV and when reading about trunk translation it seems I can strip/add digits as needed to send outbound to the sip trunk provider that doesnt accept E.164, however what about inbound calls coming from the sip trunk? Is there some trunk translation going on there to convert them to E.164? I ask because we have an MPLS provider that is offering a SIP trunk for Lync doing SIP over TCP that will connect directly to a dedicated mediation server. I haven't heard back from the provider yet, but I believe they won't be sending it over E.164. thanks!

    ReplyDelete
    Replies
    1. I found the answer....pool dial plans are used as service dial plans and can normalize incoming calls from PSTN/SIP providers.

      Delete
  21. I must be missing something I try create the na-toronto but when I dial from the lync client it give me call could not be completed error

    here the ps I used (change gateway for sercurity:
    Get-CsVoicePolicy | Remove-CsVoicePolicy -Confirm -Force
    Get-CsVoiceRoute | Remove-CsVoiceRoute -Confirm -Force
    Get-CsTrunkConfiguration | Remove-CsTrunkConfiguration -Confirm -Force
    $a = Get-CsPstnUsage
    Set-CsPstnUsage -Confirm -Force -Usage @{remove=$a.Usage}
    Set-CsPstnUsage -Force -Usage @{add="Internal","Local","Long Distance"}

    Set-CsDialPlan -Identity "Global" -SimpleName "defaultprofile"
    Remove-CsVoiceNormalizationRule -Identity "Global/Prefix All" -Force
    New-CsVoiceNormalizationRule -Parent Global -Name ElevenDigit -Description "11-digit normalization rule" -Pattern '^(\d{11})$' -Translation '+$1'
    New-CsVoiceNormalizationRule -Parent Global -Name TenDigit -Description "10-digit normalization rule" -Pattern '^(\d{10})$' -Translation '+1$1'
    New-CsVoiceNormalizationRule -Parent Global -Name International -Description "International Dial Plan" -Pattern '^011(\d{6}\d+)$' -Translation '+$1'
    New-CsVoiceNormalizationRule -Parent Global -Name 411directory -Description "411 directory service" -Pattern '^411$' -Translation '+18004664411'
    New-CsVoiceNormalizationRule -Parent Global -Name 611customerservice -Description "611 customer service" -Pattern '^611$' -Translation '+$1'
    New-CsVoiceNormalizationRule -Parent Global -Name 911emergencyservice -Description "911 emergency service" -Pattern '^911$' -Translation '+$1'


    Set-CsVoicePolicy -Identity Global -AllowCallForwarding $true -AllowPSTNReRouting $true -AllowSimulRing $true -EnableBWPolicyOverride $false -EnableCallPark $true -EnableCallTransfer $true -EnableDelegation $true -EnableMaliciousCallTracing $true -EnableTeamCall $true -PstnUsages @{add="Internal","Local","Long Distance"}
    New-CsVoiceRoute -Identity localroute -NumberPattern ^+ -PstnGatewayList @{add="PstnGateway:Voip.voip.xxxy.com"} -PstnUsages @{add="Internal","Local","Long Distance"}

    Set-CsTrunkConfiguration -Identity Global -MaxEarlyDialogs 20 -SRTPMode "Required" -ConcentratedTopology $true

    ReplyDelete
    Replies
    1. Hey Frank,
      Its probably because you're sending the wrong number of digits to your PSTN provider. You probably need to be using trunk translation rules to strip the + or the +1 where required.

      Ken

      Delete
    2. Ken: does it matter if you have strip the digits from the media gateway as opposed to inside Lync (i.e. before sending it to the media gateway). The gateway is a AudioCodes Mediant 1000 with a PRI Card (Canadian). Thx in advance.

      Delete
    3. It doesn't really matter, but I like to keep everything in one place. It's easier to troubleshoot when you don't have to look in several places for changes to numbers. Plus, its easier to make changes via Lync than Audiocodes.

      Ken

      Delete
  22. Ken, nice blog. But what about large enterprises with many more sites. For example, we have some 32 sites and setting up 5 Routes and 3 PSTN Usages for each site gets to be quite a large list.

    ReplyDelete
    Replies
    1. I agree that the list of routes/usages/etc can get very large, that's why its important to have a standardized naming convention. You can reduce the number of routes/usages etc by just setting a single route/usage per gateway, but you'd lose the ability to limit the types of calls users can make.

      Tradeoffs...

      Ken

      Delete
  23. I have today updated the page with the full RegEx list for validating and formatting UK telephone numbers. The list includes the local dialling rules specific to every area code.

    The list can be found at: http://www.aa-asterisk.org.uk/index.php/Regular_Expressions_for_Validating_and_Formatting_UK_Telephone_Numbers

    I hope this data is of some use to either you or your readers.

    ReplyDelete
  24. In the +44/GB drop down list at
    http://www.lyncoptimizer.com/ note the spelling corrections for several place names as listed at
    http://stakeholders.ofcom.org.uk/telecoms/numbering/

    ReplyDelete
  25. In the +44/GB settings produced by http://www.lyncoptimizer.com/ I would like to suggest some additions and improvements.


    Local number normalization:
    - Pattern: '^(([2-8]\d\d|9[0-8]\d|99[0-8])\d{1,5})$'
    - This pattern is OK, but it could be customised 'per area code'
    (as per the very long list on the other site I mentioned).


    Toll-free number normalization:
    - Pattern: '^0(80[08]\d{6,7}|0500\d{6})$'
    - Suggest: '^0(80(0\d{6,7}|8\d{7}|01111)|500\d{6})$'
    - Optimised 0800 and 0808 for correct number length.
    - Added 08001111 which was previously misclassified as 'national'.
    - Stray 0 in 0500 removed.


    Premium number normalization:
    - Pattern: '^0((9[01]\d|845|982)\d{7})$'
    - Suggest: '^0((9[018]\d|87[123]|70\d)\d{7})$'
    - All 098, not just 0982, is 'premium' (as are both 090 and 091).
    - Added 0871, 0872, 0873 to 'premium' (regulated by PhonePayPlus).
    - Added 070 to 'premium' (regulated by PhonePayPlus).
    - Removed 0845 as it is NOT premium (at least not in the way that 09 numbers are).


    National number normalization:
    - Pattern: '^0((1\d\d)\d{6,7}|[235]\d{9}|7[0-3]\d{8}|8(001111|45464\d|[47]\d{8}))$'
    - Suggest: '^0(1\d{8,9}|[23]\d{9}|5[56]\d{8}|8((4[2-5]|70)\d{7}|45464\d))$'
    - Optimised 01 pattern. No change for 02 and 03.
    - In 05, only 055 and 056 are 'national' (0500 is 'toll-free').
    - Removed 070 as it is 'premium' (regulated by PhonePayPlus).
    - Removed 071, 072, 073 as these will be used by 'mobile' in the future.
    - Removed 08001111 as it is 'toll-free'.
    - Optimised 0842, 0843, 0844, 0845, 0870. These are 'business rate' but are included
    here in 'national' because they are cheaper to call than full 'premium' numbers.
    - Removed 0871, 0872, 0873 as they are 'premium' (changed 087 pattern to 0870 here).


    Mobile number normalization:
    - Pattern: '^0(7[4-9]\d{8})$'
    - Suggest: '^07([4-57-9]\d{8}|624\d{6})$' which includes only current allocations,
    - OR use: '^07([1-57-9]\d{8}|624\d{6})$' with future-proofing for 071, 072 and 073
    which will eventually also be used for 'mobile'.
    - in 076, only 07624 is 'mobile'. The remainder of 076 is used by pagers.


    International number normalization:
    - Pattern: '^00((1[2-9]\d\d[2-9]\d{6})|([2-9]\d{6,14}))$'
    - This pattern is OK.


    Classifying numbers into a small number of categories isn't easy as there are many different types.

    ReplyDelete
    Replies
    1. Thanks for that! I'll update the rules with your suggestions.

      Ken

      Delete
    2. Thanks. At the moment it looks like it's still on the old version.

      I'll check back next week.

      Delete
    3. Beginning with version 8.2, Lync Optimizer uses the local dialling rules data found in the derivative XML file to create local dialling rules customised for each individual UK area code.

      For other number types, Lync Optimizer uses optimised versions of the patterns found in the comments above. Further details on both features can be found in this post and in the subsequent replies below it.

      Delete
  26. Hello,

    I am new to Lync voice, can i use a cisco router as my gateway to the PSTN network? And when i need to make outside calls, ask lync to route the calls to the cisco router to take outside?

    ReplyDelete
    Replies
    1. If you really mean a Cisco router, then no, you can't use it as your gateway to the PSTN. If you mean Cisco Call Manager, then yes, you can.

      Ken

      Delete
  27. hi,
    please I just integrated an E1 with several channels to my Lync deplorement, I am however successful on making outbound calls to other numbers but every time I want to make inbound calls, it flags the message Number does not exist.
    please help

    ReplyDelete
    Replies
    1. Its likely that the inbound number format isn't in a format that is being normalized by any rules. Use the logger tool to see what number is being sent from the PSTN to Lync.

      Ken

      Delete
  28. Hi,

    Just a question to get it clear. We are busy to integrate EV. Everybody has a got a DID. Lync is routed to a SIP-trunk. When I look for someone in the Lync client I now can choose between LyncCall and Work (the DID number). When I call the work number (when the LyncClient is online) will the call be routed through the SIP trunk or will the Lync server check if the client is online and will the call be routed direct to the client. In other words; will calling the work number (DID) be free of charge (because it won't go through the SIP-trunk)?

    ReplyDelete
    Replies
    1. Yes, if an internal Lync user dials the DID number, Lync will see that it is assigned to a Lync user and will keep the call internal. It won't go out the SIP trunk.

      Ken

      Delete
  29. Hi Ken,

    Great blog! If a contact in the addressbook only has a emailaddress Lync will still have the option to make a LyncCall. This won't work for 99,9% because the external contact won't have a Lync client / environment. Is it possible to disable LyncCall? This won't have an effect on our own users because the all have a DID in Lync

    ReplyDelete
  30. Hi got a smal lab enviroment and I whant to connect sip trunk from Lync to Cisco.
    On Lync I have the number range of 7xxx and on Cisco 8.6 I got 6xxx.
    And what I know so far it that I need to do a normalisation for e.164 to make 7xxx to +467xxx on the trunk to Lync.

    my question is how do i create a route pattern to be pointed to sip trunk to Cucm.
    BR
    Robert

    ReplyDelete
  31. Hi Ken,

    In relation to your comment in a post above:

    "Ken LaskoOctober 11, 2011 at 4:10 PM
    You can create a blanket rule that just forwards everything to the PBX. The default route that Lync creates can do that job for you. If you dial a number and it doesn't match an Enterprise Voice enabled user, it will route out to your PBX.

    Ken"

    I have a client who has a branch site with an SBS and PSTN gateway. They have strict data caps on their connection. They would like Lync to always route all calls to the gateway and via the PSTN when an internal users DDI is called. How would I go about getting this to work.

    Once I know this I can reverse it for calls from the central site to the branch site to do the same.

    A great post as well :)

    Alastair

    ReplyDelete
    Replies
    1. You can use call admission control to accomplish this. You would set the available bandwidth to a very small value, which would force all calls to reroute to the PSTN, assuming your voice policies are set to "Enable PSTN reroute"

      Ken

      Delete
  32. Hi Ken,
    If I have several business units in one site, each with their own main-line/published number - and they want to send that published number as their Alternate Caller ID - it looks like I would have to create unique routes for each business unit. Does that seem right? As in, there is no way to do this from their Voice Policy?
    It looks like I am going to have to create multiple local/national/international routes, all with the same trunks/gateways and patterns to match for every business unit that wants to send a unique Alternate Caller ID... :-/
    Just thinking I should be able to pass this to the route via their policy somehow. Have you ever came across this requirement?

    ReplyDelete
  33. Question when I set the call forwarding we get this for example 18178467514;phone-context=enterprise. So I set call forwarding to 18178467514 that is the format. Strange if someone calls ip to ip I get the URI setup in the lync server for example 18175760500;ext=1007 but when I call from Exchange and forward to lync when I forward the number the number set for call forwarding coming as 18178467514;phone-context=enterprise.

    ReplyDelete
  34. issue is when I call lync to lync and they have simult or call forward on we get the line uri. If they call unified message on exchange 2013 and dial the extension and person still has call forwarding on it give the call forwarding number instead of the line uri specified in lync is there a way to change so that it will always call the line uri number.

    ReplyDelete
  35. issue is when I call lync to lync and they have simult or call forward on we get the line uri. If they call unified message on exchange 2013 and dial the extension and person still has call forwarding on it give the call forwarding number instead of the line uri specified in lync is there a way to change so that it will always call the line uri number.

    ReplyDelete