Over the past while, I've typed some lengthy posts about the importance of http://innaz2.blogspot.com /2010/12/enterprise-voice-best-practices-in-lync.html">E.164 phone number formatting and my take on http://innaz2.blogspot.com /2011/01/enterprise-voice-best-practices-in-lync.html">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 http://innaz2.blogspot.com /2011/01/enterprise-voice-best-practices-in-lync.html">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 http://innaz2.blogspot.com /2011/01/enterprise-voice-best-practices-in-lync.html">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.
0 komentar:
Posting Komentar