Topic Last Modified: 2011-01-26
Call routes specify how Microsoft Lync Server 2010 communications software handles outbound calls placed by Enterprise Voice users. When a user dials a number, the Front End Server normalizes the dial string to E.164 format, if necessary, and attempts to match it to a SIP URI. If the server cannot make the match, it applies outgoing call routing logic based on the number. The final step in defining that logic is creating a separate named call route for each set of destination phone numbers that are listed in each dial plan.
Before you define outbound call routes, you should complete the following steps:
- Deploy one or more PSTN gateways or SIP trunking connections
and Lync Server 2010 Mediation Servers.
- Create dial plans as needed for sites, individuals, and Contact
- Create public switched telephone network (PSTN) usage
In addition, to enable outbound call routing, you must create and assign one or more voice policies. This task can be done either before or after you define outbound call routes.
For each route, you must specify:
- A name by which it can be readily identified.
- An optional description in cases where the name alone may not
be sufficient to describe the route.
- The regular expression matching pattern that identifies the
destination phone numbers to which the route is applied, along with
exceptions to which the matching pattern is not to be applied
- The FQDN of one or more the gateways that you want to assign to
- The PSTN usage records that users must have in order to call
numbers matching the destination phone number regular
You can specify call routes in the Microsoft Lync Server 2010 Control Panel. These call routes populate the server routing table, which Lync Server uses to route calls that are destined for the PSTN.
Multiple Gateway Support
Lync Server 2010 provides improved flexibility in deploying PSTN gateways. A given gateway can be assigned to multiple call routes and associated with one Mediation Server or a pool of Mediation Servers. Multiple gateways can be associated with either a single Mediation Server or a pool of Mediation Servers. When defining a call route, you specify the gateways associated with that route, but you do not specify which Mediation Servers are associated with the route. Instead, you use Topology Builder to associate gateways, and therefore routes, with Mediation Servers. In other words, routing determines which gateway to use for a call and the Mediation Server associated with that gateway handles the call.
Least Cost Routing
The ability to specify the PSTN gateways to which various numbers are routed enables you to determine which routes incur the lowest costs and implement them accordingly. The rule of thumb in selecting gateways is to choose the one closest to the location of the destination number in order to minimize long-distance charges. For example, if you are in New York and calling a number in Rome, you would carry the call over the IP network to the gateway in your Rome office, thereby incurring a charge only for a local call.
For an example of how least cost routing might be used, consider the following: Fabrkam decides to allow German users to dial U.S. numbers by using the U.S. gateway. Fabrkam also wants to configure the system so that all calls from U.S. Lync Server users to Germany and adjacent countries terminate on the German gateway. This routing will save money, because a call from Germany to Austria, for example, is less expensive than a call from the U.S. to Austria.
Translating Outbound Dial Strings
Lync Server 2010, like its immediate predecessors, requires all dial strings to be normalized to E.164 format for the purpose of performing reverse number lookup (RNL). Downstream components such as gateways, PBXs, or SIP trunks, however, may require numbers in local dialing formats. As a result, in Microsoft Office Communications Server 2007 R2, it was sometimes necessary to individually configure downstream components or even reroute calls in order to accept the E.164 dial strings. Unlike its predecessor, however, Lync Server 2010 allows you to create one or more rules that assist in manipulating the Request URI prior to routing it to the gateway. For example, you could write a rule to remove +44 from the head of a dial string and replace it with 0144.
In planning which and how many gateways to associate with a given Mediation Server cluster, it may prove useful to group gateways with similar local dialing requirements so as to reduce the number of required translation rules and the time it takes to write them.
Configuring Caller ID
Lync Server 2010 provides a way to manipulate the caller ID for outbound calls. For example, if an organization wants to mask employees’ direct-dial extensions and replace them with the generic corporate or departmental number, an administrator can now do that by using Microsoft Lync Server 2010 Control Panel to suppress the caller ID and replace it with a specified alternative caller ID. In planning your routing logic, you will at least need to consider whether caller ID replaced is desirable for certain individuals, groups, or sites or, perhaps even, for all employees.
|For calls that are re-routed over the PSTN, the generic caller ID will be presented instead of the original caller ID. This can cause the call to bypass Do Not Disturb or privacy settings the callee may have configured.|
Additional Routing Logic
In creating outbound call routes, you should be aware of the following factors affecting routing logic:
- If the domain portion of the request URI does not contain a
supported domain for the enterprise, the outbound routing component
on the server does not process the call. For example, in certain
scenarios where a call is established over a federated boundary,
the domain portion of the URI is used to route the call over to the
enterprise that is responsible for applying the outbound routing
- If a user is not enabled for Enterprise Voice, the server
applies other routing logic as appropriate.
- If a call is routed to a gateway that is fully occupied (all
trunk lines are busy), the gateway rejects the call and the
outbound routing logic redirects the call to the next-least-cost
route. Careful consideration should be given to this, because a
gateway sized for a small office overseas (for example, Zurich),
may actually carry a significant amount of nonlocal traffic for
international calls to Switzerland. If the gateway is not correctly
sized for this additional traffic, calls to Switzerland may be
routed by way of a gateway in Germany, resulting in larger toll