Microsoft Lync Server 2010 : Planning for Voice Deployment - Voice Routing

Voice routing in Lync Server 2010 is composed of a few different components, including the dial plan discussed previously. It is difficult to discuss the remaining components separately because how they are connected directly affects voice routing.

This section discusses the voice policies, PSTN usages, routes, and trunk configuration that make up the rest of the voice routing components in Lync Server 2010.

Voice Policies

Voice policies in Lync Server 2010 define what features users might leverage with their Enterprise Voice service. This includes options such as simultaneous ringing, team call, or call forwarding. The other main component of voice policies is that PSTN usages are associated with a policy.

From a planning perspective, examine the various options of a voice policy and make a decision on whether multiple policies are required. Policies can be global, assigned to a site, or directly assigned to user accounts.

PSTN usages are the key component of voice policies from a dialing perspective because they control what routes a user account might use. For example, a route might exist that matches a dial string considered as long distance by the organization and a PSTN usage of Long Distance is associated with that route. For a user to successfully dial the number, he must be assigned a voice policy that includes the PSTN usage.

For example, assume Company ABC’s San Francisco office is allowed to dial local numbers beginning only with the 415 area code. A route for the dial string pattern beginning with +1415 exists and is associated with the PSTN usage Local, and the PSTN usage Local is included in the Global voice policy for Company ABC. Now a group of executives must be able to dial long distance numbers to Chicago’s 312 area code, but because they have no PSTN usage that allows this route, their calls will fail. The rest of the office should also not be allowed to dial this area code.

To accommodate the executives, a new policy, route, and PSTN usage must be created. First, create a route that begins with +1312 and is associated with a PSTN usage of Long Distance. Next, a voice policy called Executives should be created, which includes both the Local and Long Distance PSTN usages. Finally, the new voice policy should be assigned to the executive user accounts who require this capability.

Because they now have a voice policy that includes a PSTN usage matching the route, only their Enterprise Voice accounts are able to place calls to the 312 area code. The rest of the San Francisco office will still not be able to make those calls even when the route exists because their voice policy does not include the PSTN usage associated with the route.

PSTN Usages

The PSTN usage object in Lync Server often seems confusing because it has no settings or configuration options other than a name. There are no user options or policies configured on a usage and it cannot even be created by itself. Instead, PSTN usages can only be created through a voice policy. Usages are also not even associated directly with users. They are associated with routes and voice policies so that they can be considered the glue that ties a route to a voice policy associated with a user.

PSTN usages are typically identified by different classes of services. For example, usages such as Emergency, Information, Local, Long Distance, or International might be created. An organization might choose to create more specific usages if necessary. PSTN usages can also be ordered within a voice policy and are processed from top to bottom. When placing a call, the routes that include the user’s first PSTN usage are returned and a match for the dial string is attempted. If no match occurs, or if all the gateways are unavailable, the second PSTN usage in the voice policy is compared against the available routes. The first PSTN usage that matches an available route is used.

Routes

Routes in Lync Server 2010 are a definition of where to send calls that match a specific dial string. Administrators define a matching pattern and a gateway or gateways associated with the pattern to send a call. Each route is also associated with PSTN usages to define what type of call this might be.

The PSTN usage defined varies depending on the gateway associated with the route. For example, a route matching the +1312 area code associated with an IP/PSTN gateway in Chicago might be considered a PSTN usage of Local, but when associated with an IP/PSTN gateway in San Francisco, it necessitates a PSTN usage of Long Distance.

Route Resilience

Resiliency for routes is done by providing multiple gateways in a single route, or by creating a redundant route that uses a gateway in a different location. Routes are processed in from a top-to-bottom order so that the priority for a route can specified by adjusting the route placement within the list. For example, a route matching the +1312 area code using an IP/PSTN gateway in Chicago should be placed higher in the list than a route matching the same string using an IP/PSTN gateway in San Francisco because it is considered a local call to the Chicago gateways.

There are two aspects to consider when planning for route resilience in Lync Server 2010: high availability in the primary site and resilience in a failover scenario. High availability is typically achieved by associating multiple gateways within the same location with the route and PSTN usage. In this example, Lync Server 2010 round-robins requests across the two IP/PSTN gateways in Chicago when operating at full capacity. If one of the gateways fails, calls are sent only to the gateway still available.

If both of these gateways fail, an organization might want to still route calls to the destination number, but accept potential long distance charges and route calls out at the gateway in another physical site. This is accomplished by creating a second route with the same dial string, different gateway, and different PSTN usage.

Continuing the example, assume Company ABC also has an IP/PSTN gateway in San Francisco and a secondary route for the +1312 area code using this gateway. The primary route for +1312 should use the Chicago IP/PSTN gateway. Additionally, a PSTN usage of Chicago Backup Long Distance is associated with the secondary route. A voice policy including the Local and Chicago Backup Long Distance PSTN usages is created and assigned to San Francisco users. This ensures that in the event of both Chicago IP/PSTN gateways becoming unavailable, calls are routed out the San Francisco IP/PSTN gateway. This scenario is shown in Figure 1. The reason the San Francisco gateway is not associated with the same route as the Chicago gateways is that Lync Server will distribute outbound calls to each gateway equally. To use San Francisco only as a backup route, it needs to have a unique route and PSTN usage associated.

Figure 1. Route Resilience Example

Trunks

Trunk configuration in Lync Server 2010 is an object that administrators can use to define the connection between Lync Mediation servers and IP/PSTN gateways within the infrastructure. One important feature is that a trunk configuration can control how dial strings are passed to a specific IP/PSTN gateway.

In Office Communications Server 2007 R2, any outbound dialing rules had to be performed by the IP/PSTN gateway itself, which required organizations to maintain dialing rules in multiple locations. With Lync Server 2010, dial strings can be manipulated before being sent to an IP/PSTN gateway so that digits can be removed, added, or translated.

A common example is where an IP/PSTN gateway does not support the + prefix in E.164 and needs to be removed before being sent. In other cases, the PBX might require special prefixes for local, long distance, or international calls and these digits can be appended through the trunk configuration.

Trunk configuration is also where Media Bypass features can be enabled or disabled. Media Bypass is a new feature that enables a Lync endpoint to bypass the Mediation server transcoding of RTAudio to G.711 and simply send G.711 directly to the IP/PSTN gateway. This removes the need for additional processing resources on the Mediation server and is the main reason support for collocating the Mediation server with the Front End is available in Lync Server 2010.

In addition to translation rules and Media Bypass features, the trunk configuration controls whether media encryption is required and whether a separate media termination point exists.

Trunk configuration exists at a global level by default, can be constrained to a site, or can be defined on a specific IP/PSTN gateway. This flexibility enables organizations to use Media Bypass on IP/PSTN gateways that support the feature and leave the feature disabled on others. It also accommodates situations where the IP/PSTN gateway expects different dial strings in different locations.

For example, Company ABC’s IP/PSTN gateways in Chicago might support a + in the dial string, but the San Francisco IP/PSTN gateway might require it to be removed before passing a call successfully. Because all the trunk configuration translation rules occur only after a number is normalized and routed, it is completely transparent to the end user and she can continue dialing the same patterns regardless of where the call is sent. This is especially useful in a failure scenario where calls are routed out a backup location, but the users have no idea that their calls are redirected to a different gateway.

Use the following steps when planning for trunk configuration to identify whether any changes should be made:

• Identify the appropriate dial string format for each IP/PSTN gateway in the topology.
  
  
• Identify which IP/PSTN gateways support Media Bypass.
  
  
• Create a trunk configuration for each unique group of settings, scoped appropriately to a site or IP/PSTN gateway.
  
  

Tying It All Together

Now that voice policies, PSTN usages, routes, and trunk configuration have been defined, an important step is determining how all these components interact. Figure 2 shows a sample configuration where two different voice policies exist, each with a different set of PSTN usages assigned. Office workers can only make calls considered local, but executives can place local, long distance, and international calls. Company ABC has voice gateways in both San Francisco and Chicago, so even if a San Francisco user dials a Chicago area code such as 312, the call can still be considered local if going out the Chicago voice gateway.

Figure 2. Voice Routing

Executives can place calls which begin with the dial strings +1415, +44, +1312, or +1765 because each of these routes is associated with a PSTN usage included in their voice policy. Because office workers only have the Local PSTN usage in their policy, they can place calls only to numbers beginning with +1415 or +1312. Calls placed to a dial string beginning with +44 or +1765 will be unsuccessful for office workers. After a call matches a route, it will pass through the trunk configuration associated with the gateway. In this case, the San Francisco and Chicago voice gateways have different trunk configurations that manipulate digits before being sent to the gateway.

Sizing

How to correctly size an IP/PSTN gateway or SIP trunk for Lync Server 2010 voice services is a common question and, unfortunately, is going to vary greatly depending on the users in each location. Sizing for an IP/PSTN gateway depends on the user’s dialing habits as well as whether any simultaneous ringing is configured.

Microsoft offers some planning numbers that can be used to perform a rough analysis. If at all possible, retrieve reporting data from the existing PBX to determine the expected usage requirements for each site. Table 28.1 offers a suggestion on how many PSTN ports to allocate to a site depending on the usage level. For example, in a branch office with 25 users with light usage, only two PSTN ports are suggested.