During my travels across the Lync Enterprise Voice landscape, I come across numerous Lync deployments that make some fundamental mistakes in how to manage phone numbers, call routing and other details. They're always fixed by the end of the engagement, but I'd like to share some of these to help keep others from making the same mistakes. This will be an ongoing series of unknown duration.
#1 - Failover/Resiliency Routing
This is one of the more misunderstood concepts in Lync Enterprise Voice. Its a question that often trips people up on the Lync Voice exam (70-337), and is something that even respected websites like Windows IT Pro gets wrong (despite my attempts to get them to correct it).
The idea behind failover or resiliency routing is that you want to use a particular PSTN gateway for your normal day-to-day call routing, but have a backup PSTN trunk ready in case the primary one is down. This is different from load-balanced routing, where your goal is to evenly spread call traffic between two or more trunks.
The idea behind failover or resiliency routing is that you want to use a particular PSTN gateway for your normal day-to-day call routing, but have a backup PSTN trunk ready in case the primary one is down. This is different from load-balanced routing, where your goal is to evenly spread call traffic between two or more trunks.
For example, say you have a Lync deployment in your Boston office and another one in your Seattle office. For reasons that should be obvious, you want to ensure that your Boston users always use the Boston PSTN gateway for outbound calls to reduce WAN traffic and call latency. If the Boston trunk is down, calls should failover to the Seattle PSTN trunk. The same goes for your Seattle users. We could make things more interesting by bringing least-cost routing into play, but we're going to keep it simple here.
A common error people make in an attempt to make things simple and easier to manage is to create a single route for all calls, and place both the Boston and Seattle trunks inside that route. Since they added the Boston trunk first, it appears first in the list, and they are lulled into thinking that calls will always use the Boston trunk unless its down, at which point the Seattle trunk is used.
In actual fact, calls will load-balance themselves between the Boston and Seattle trunks. Sure, if Boston is down, all calls will route via Seattle, but any well-designed EV deployment should never needlessly send calls across the country on the corporate WAN unless absolutely necessary. If your other site is in a different country, you could be left with some pretty high phone bills since half of your national calls will be routed out the other country's gateway as an international call.
A clue to this behaviour can be found when you look at a route in the Control Panel. You'll notice that while you can add/remove trunks to a route, there is no way to change the order of the trunks. This should be a clue to the fact that you have no control over which trunk is used within a route.
The proper way to achieve failover routing is via PSTN Usage ordering. Instead of creating a single route with multiple gateways inside it, you create a Boston PSTN Usage with a route to the Boston PSTN gateway, and another Seattle PSTN Usage with a route to the Seattle gateway. In the voice policy assigned to your Boston users, add both the Boston and Seattle PSTN usages, ensuring the Boston one is above the Seattle one. For your Seattle voice policy, put Seattle first.
Now, you have achieved true failover routing. For Boston users, all calls will route out the Boston trunk, unless it is down. The same thing works for your Seattle users.
Incidentally, putting multiple trunks in a single route does have its uses. If you have multiple PSTN gateways within the same datacentre for redundancy, its OK to do things this way, since you usually don't really care which trunk is used for outbound calls. Calls will be load-balanced between all the trunks, skipping any gateways marked as down. The above picture shows exactly that situation (although its not obvious since most of the trunk name is truncated). However this should never be considered failover routing, simply round-robin or load-balanced routing.
Essentially, you want to avoid placing trunks from different locations within the same route. This ensures you have control over how your calls are routed, keeping WAN utilization and costs low.
Tune in next week for our next exciting episode: " http://googledoodlenewstoday.blogspot.com /2014/09/EVMisconceptionsEAP.html" target="_blank">PBX External Access Prefixes"
In actual fact, calls will load-balance themselves between the Boston and Seattle trunks. Sure, if Boston is down, all calls will route via Seattle, but any well-designed EV deployment should never needlessly send calls across the country on the corporate WAN unless absolutely necessary. If your other site is in a different country, you could be left with some pretty high phone bills since half of your national calls will be routed out the other country's gateway as an international call.
Voice Policy | PSTN Usage | Route | Trunks |
|---|---|---|---|
Global | AllCalls | AllCalls | BostonGW SeattleGW |
A clue to this behaviour can be found when you look at a route in the Control Panel. You'll notice that while you can add/remove trunks to a route, there is no way to change the order of the trunks. This should be a clue to the fact that you have no control over which trunk is used within a route.
The proper way to achieve failover routing is via PSTN Usage ordering. Instead of creating a single route with multiple gateways inside it, you create a Boston PSTN Usage with a route to the Boston PSTN gateway, and another Seattle PSTN Usage with a route to the Seattle gateway. In the voice policy assigned to your Boston users, add both the Boston and Seattle PSTN usages, ensuring the Boston one is above the Seattle one. For your Seattle voice policy, put Seattle first.
Voice Policy | PSTN Usage | Route | Trunks |
|---|---|---|---|
Boston | Boston-AllCalls | Boston-AllCalls | BostonGW |
Seattle-AllCalls | Seattle-AllCalls | SeattleGW |
Now, you have achieved true failover routing. For Boston users, all calls will route out the Boston trunk, unless it is down. The same thing works for your Seattle users.
Incidentally, putting multiple trunks in a single route does have its uses. If you have multiple PSTN gateways within the same datacentre for redundancy, its OK to do things this way, since you usually don't really care which trunk is used for outbound calls. Calls will be load-balanced between all the trunks, skipping any gateways marked as down. The above picture shows exactly that situation (although its not obvious since most of the trunk name is truncated). However this should never be considered failover routing, simply round-robin or load-balanced routing.
Voice Policy | PSTN Usage | Route | Trunks |
|---|---|---|---|
Boston | Boston-AllCalls | Boston-AllCalls | BostonGW1 BostonGW2 |
Seattle-AllCalls | Seattle-AllCalls | SeattleGW1 SeattleGW2 |
Essentially, you want to avoid placing trunks from different locations within the same route. This ensures you have control over how your calls are routed, keeping WAN utilization and costs low.
Tune in next week for our next exciting episode: " http://googledoodlenewstoday.blogspot.com /2014/09/EVMisconceptionsEAP.html" target="_blank">PBX External Access Prefixes"
0 comments:
Post a Comment