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.
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.
Don't make the mistake of assigning multiple gateways from different sites in the hopes of achieving failover routing. Lync doesn't use any sort of ordering when determining which gateway to use within a given route. Its very likely that calls will route equally between the two, which would make for a nasty surprise when the bills come in. For example, don't put gateways from your Toronto and Rome deployments in the same route. Some calls will route through Toronto, and others will route through Rome. To properly achieve failover routing, use PSTN usage ordering, as discussed later.
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.
Each site should look something like this, using Ottawa as an example:
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:
If your calls have to route through a PBX before going to the PSTN, you can add the necessary external access prefix here as well. For example (using 9 as the external access prefix):
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:
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.
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.
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.
Don't make the mistake of assigning multiple gateways from different sites in the hopes of achieving failover routing. Lync doesn't use any sort of ordering when determining which gateway to use within a given route. Its very likely that calls will route equally between the two, which would make for a nasty surprise when the bills come in. For example, don't put gateways from your Toronto and Rome deployments in the same route. Some calls will route through Toronto, and others will route through Rome. To properly achieve failover routing, use PSTN usage ordering, as discussed later.
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.
Each site should look something like this, using Ottawa as an example:
| PSTN Usage | Route | Rule |
| NA-ON-Ottawa-Local | NA-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-National | NA-ON-Ottawa-National | ^\+1[2-9]\d{9}$ |
| NA-ON-Ottawa-International | NA-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 Name | Pattern | Translation | Sent to GW Example |
| NA-ON-Toronto-Local | ^\+1((416|647)\d{7}) | $1 | 4165551111 |
| NA-ON-Toronto-National | ^\+(1\d{10})$ | $1 | 12125551111 |
| NA-ON-Toronto-International | ^\+([2-9]\d{6,})$ | 011$1 | 011525551111 |
| NA-ON-Toronto-Service | ^\+([2-9]11)$ | $1 | 411 |
If your calls have to route through a PBX before going to the PSTN, you can add the necessary external access prefix here as well. For example (using 9 as the external access prefix):
| Trunk Translation Rule Name | Pattern | Translation | Sent to GW Example |
| NA-ON-Toronto-Local | ^\+1((416|647)\d{7}) | 9$1 | 94165551111 |
| NA-ON-Toronto-National | ^\+(1\d{10})$ | 9$1 | 912125551111 |
| NA-ON-Toronto-International | ^\+([2-9]\d{6,})$ | 9011$1 | 9011525551111 |
| NA-ON-Toronto-Service | ^\+([2-9]11)$ | 9$1 | 9411 |
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
HU-Budapest-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.
Great post!
ReplyDeleteThere is a error in your Toll Free PSTN usage rule. It should be ^\+1(800|888|877|866|855)\d{7}$
Whoops...thanks for that. I'll fix right away.
ReplyDeletegreat post! exactly what i need now. Thanks!
ReplyDeleteHi 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.
ReplyDeleteYou 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.
ReplyDeleteKen
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.
ReplyDeleteKen great post, very useful.
ReplyDeleteQuestion - 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?
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.
ReplyDeleteKen
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!
ReplyDeleteHi there,
ReplyDeleteI suspect you've got your dialing rules setup incorrectly. Can you share your details?
Ken
Don't you believe you get lost when you are using same name for:
ReplyDeletePSTN 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)
Hey Anonymous,
ReplyDeleteSure 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
You had easy international rule:
ReplyDeleteNA-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)?
Hi Anonymous,
ReplyDeleteIt'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
Hi Ken,
ReplyDeleteI 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.
Hey Carolyn,
ReplyDeleteWhat 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
** The Toll Free PSTN usage rule should be ^\+1(800|888|877|866|855)\d{7}$ **
ReplyDeleteHaving 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}$
Thanks for the tip! I've updated the rule in the optimizer accordingly.
ReplyDeleteKen
Add Russia code +7, please.
ReplyDeleteI mean to the Dialing Rule Optimizer.
DeleteI 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.
DeleteKen
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!
ReplyDeleteI found the answer....pool dial plans are used as service dial plans and can normalize incoming calls from PSTN/SIP providers.
DeleteI 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
ReplyDeletehere 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
Hey Frank,
DeleteIts 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
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.
DeleteIt 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.
DeleteKen
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.
ReplyDeleteI 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.
DeleteTradeoffs...
Ken
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.
ReplyDeleteThe 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.
In the +44/GB drop down list at
ReplyDeletehttp://www.lyncoptimizer.com/ note the spelling corrections for several place names as listed at
http://stakeholders.ofcom.org.uk/telecoms/numbering/
In the +44/GB settings produced by http://www.lyncoptimizer.com/ I would like to suggest some additions and improvements.
ReplyDeleteLocal 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.
Thanks for that! I'll update the rules with your suggestions.
DeleteKen
Thanks. At the moment it looks like it's still on the old version.
DeleteI'll check back next week.
Hello,
ReplyDeleteI 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?
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.
DeleteKen
hi,
ReplyDeleteplease 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
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.
DeleteKen
Hi,
ReplyDeleteJust 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)?
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.
DeleteKen
Hi Ken,
ReplyDeleteGreat 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
Hi got a smal lab enviroment and I whant to connect sip trunk from Lync to Cisco.
ReplyDeleteOn 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
Hi Ken,
ReplyDeleteIn 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
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"
DeleteKen
Hi Ken,
ReplyDeleteIf 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?
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.
ReplyDeleteissue 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.
ReplyDeleteissue 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.
ReplyDeleteHi Ken,
ReplyDeleteThanks for a wonderful explanation. I have a small query, i am trying to setup a global voice routing and have 2 local pstn gateway in each datacenter if i define both the gateway in the route originating datacenter 1 for all the local, national and international route how would the outgoing calls be loadbalanced? I haven't been able to find any arcile that talks about this scenario but i have seen people talking that lync will split the calls between multiple gateways but i am not sure how true that it. Also i want to know what lync does in the event one of the gateway goes offline or not responding, i know that lync sends sip options frequently to check the gateway availability does it stops sending outbound calls to the gateway not responding to sip options? if yes then are there any configuration items around this would be helpful to know. Thanks!
If you put both gateways for the one datacenter in a route, then Lync will round-robin the calls between them. There's no control over which one is used at any given time, but in a same-DC scenario, its perfect. If one of those GWs is not responding to SIP OPTIONS requests, Lync will mark it as down and skip it.
DeleteKen
Great Thanks! And the only way to make Lync use the gateway in round-robin fashion is to use a dns host record resolving to 2 ip's (one for each gateway?) or can i just specify 2 ip's in lync topology and it will do it anyway. I will also be creating another set of pstn usages that will route the call to the secondary datacenter in the event of 1st datacenter goes unavailable.
ReplyDeleteJust add the two IPs to the topology as PSTN gateways. Then add those GWs to the routes, and you'll be all set for round-robining.
DeleteKen
Hi Ken...need to knw what's will be checked first, Dial plan or Voice Policy. Let's say a user have local calling voice policy assigned and he tries to dial an international number I:e 00+country code+ number. Dialled number will normalised first and then gets failed because of policy or policy will fail the call immediately without number being translated.
ReplyDeleteNumbers will always be normalized first before being evaluated by a voice policy.
Delete