Enterprise Voice Routes specify how Office Communications Server 2007 R2 handles calls placed by Enterprise Voice users. When a user places a call, the server, if necessary, normalizes the phone number to E.164 format and attempts to match it to a SIP URI. If the server is unable to make the match, it applies outgoing call routing logic based on the number. You define that logic in the form of a separate route for each set of target phone numbers that are listed in the location profile for each locale.
Before you define outbound call routes, you should complete the following steps:
- Deploy one or more media gateways or SIP trunking connections
and, if necessary, Office Communications Server 2007 R2 Mediation
- Create a location profile consisting of normalization rules for
target phone numbers.
- Create phone usage records.
In addition, to enable outbound call routing, you must also create and assign one or more voice policies, but this step 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 that identifies the target phone numbers
to which the route is applied.
- The FQDNs of the gateways that can route to the target numbers.
- The phone usage records that users must have in order to call
numbers matching the target phone number regular expression.
You create routes in the Office Communications Server 2007 R2 snap-in for MMC. These routes populate the routing table, which embodies the outbound call routing logic that is followed by the server for numbers to the PSTN.
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.
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 Component 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 charges.