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:

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:

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

Figure 1: Call Route Path in the Houston Resiliency Scenario

San Antonio Resiliency Scenario

Let's walk through another resiliency scenario:

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

Figure 2: Call Route Path 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.