Resiliency Routing for Enterprise Voice in Lync Server 2013

Resiliency routing for Enterprise Voice in Lync Server 2013 is one of those areas that might seem complex but is actually quite easy to set up and configure. I've run into plenty of deployments where this area is often overlooked or misunderstood. The best way to explain resiliency routing for Enterprise Voice in Lync Server 2013 is by means of some examples. But before I walk you through two resiliency scenarios, I want to discuss some routing terms and set the backdrop for the scenarios.

Routing Terminology

To implement resiliency routing, you need to be familiar with routing terminology. Here are the most important terms and what they mean:

• User policy. This term refers to a list of features available to users.
• Phone usage. With routing, phone usage refers to a service class that determines the locale to which users can make calls (e.g., local calls, long distance calls, international calls).
• Route name. This term refers to a descriptive name for a given route.
• Number pattern. The number pattern is the normalization rule given for a phone number. The normalization rule specifies how to translate the phone number to the E.164 international numbering plan.
• Gateway. A gateway is a media termination device used to connect to Lync Server 2013.
• Trunk. The trunk is the Mediation server and gateway. You can refer to a trunk by its Fully Qualified Domain Name (FQDN) or IP address.

Backdrop for the Sample Scenarios

Let's set the scene for the two scenarios. Suppose that Enterprise Voice in Lync Server 2013 has been enabled for users in three locations: Houston, San Antonio, and Chicago. You want to have redundant routes to the local Public Switched Telephone Network (PSTN) in each location. The goal is to have the users be unaware if a route fails, except for possibly a slight delay incurred when the call is routed through a different path in the dial plan.

Resiliency Routing Layout

The resiliency routing layout for this example is broken into Table 1 and Table 2. Table 1 contains the user policies and phone usages, both of which are crucial in deciding the path a phone call will take. In Table 1, each user who is enabled for Enterprise Voice is assigned a user policy. This policy is where the different phone usages are defined. When there are multiple phone usages, they're considered in the order they're listed.

Table 2 displays the routing paths that calls will make based on the phone number that's dialed. The route name should be a descriptive indicator of the phone usage and/or trunk location (or the path that's traveled). The number pattern is the normalization rule, which works in the background after a user dials an extension or phone number in the Lync client. Based on the phone number that's dialed by the Lync user, a certain phone usage is assigned and a trunk path is determined. When there are multiple trunks for a route, they're tried in the order they're listed.

Houston Resiliency Scenario

Let's now walk through a resiliency scenario for a user in the Houston office:

1. A Houston user is assigned the Default Calling Policy.
2. The user dials a Houston-based customer (832-555-5555), which leverages the Local phone usage based on the order of the phone usages listed in the Default Calling Policy.
3. The Local phone usage belongs to the Houston Local Route.
4. The Houston Local Route has two trunks associated with it: Hou-Trunk1 and Hou-Trunk2.
5. Hou-GW1 is unavailable, so Hou-Trunk1 is marked as being down.
6. The call leverages the next gateway in the route, which is Hou-GW2.
7. The call departs through the Hou-GW2 gateway and connects to the Session Initiation Protocol (SIP) peer, which could an IP-PBX.

Figure 1 shows the path taken in the Houston resiliency scenario.

San Antonio Resiliency Scenario

Let's walk through another resiliency scenario:

1. A San Antonio user is assigned the Default Calling Policy.
2. The user dials a local customer in San Antonio (210-555-5555), which leverages the USPSTNHopoff phone usage because the Local phone usage doesn't apply to the area code 210.
3. The USPSTNHopoff phone usage belongs to the Universal Route.
4. The Universal Route has a catchall number pattern for the policy to which the user is assigned, so it will be leveraged.
5. The Universal Route has two trunks associated with it: Hou-Trunk1 and Chi-Trunk1.
6. Hou-GW1 has just become unavailable, so Hou-Trunk1 is marked as down. Note that when two gateways are in the same phone usage and not separated by specific number pattern, the call can leave out either gateway, similar to a round-robin effect. In this scenario, the assumption is that the call's first attempt was not out the Chi-Trunk1 trunk to the Chi-GW1 gateway but rather out the Hou-Trunk1 trunk to the Hou-GW1 gateway.
7. The call leverages the next gateway in the route, which is Chi-GW1.
8. The call departs through the Chi-GW1 gateway and connects to the SIP peer, which could an IP-PBX.

Figure 2 shows the path taken in the San Antonio resiliency scenario.

Need to Consider What-If Route Scenarios

Resiliency routing is a subtle but important feature in Lync Server 2013. The Microsoft Lync team is positioning and building Lync to be a software PBX replacement, so it's important that you don't overlook what happens naturally in a lot of PBXs—that is, redundant routing of calls ingress and egress the organization when certain hardware or routes become unavailable. With the integration of Lync as a VoIP software application, it's important to consider what-if route scenarios the next time you're planning, configuring, or managing a Lync deployment.