Plan for User Authorization and Outbound Call Routing in Office Communications Server

Microsoft Office Communications Server 2007 and Microsoft Office Communications Server 2007 R2 will reach end of support on January 9, 2018. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.

Outbound call routing applies to calls that are destined for a PBX or the PSTN. User authorization refers to policies that specify which users have permission to place calls along which routes.

To configure user authorization and outbound call routing for your organization, you must create the following Active Directory objects:

Table 6. Communication Server Active Directory Objects for Enterprise Voice

Object	Description
Location profile	A location profile defines all phone numbers that can be dialed from a named location. A location contains one or, typically, more normalization rules.
Normalization rule	A normalization rule is a .NET regular expression that defines a phone number pattern. A set of normalization rules associated with a particular location constitute a location profile.
Phone usage record	A phone usage record specifies a class of call (internal, local, long distance, or whatever) that can be made by various users, or groups of users, in an organization.
Voice policy	A voice policy associates one or more phone-usage records with one or a group of users.
Route	A voice route associates target phone numbers with particular IP-PSTN gateways and phone usage records.

The following figure illustrates the relationship among the various routing components. You may find it helpful to refer to this diagram as you go through the configuration process.

Figure 17. Configuring Outbound Routing

You use the Office Communications Server 2007 Administrative Tools to create the Active Directory objects shown in the above figure. The following topics explain how to configure outbound call routing for your organization and the issues you need to consider when you do so.

Note

Enterprise Voice Route Helper provides an alternative to the Office Communications Server 2007 Administrative Tools for viewing and modifying Enterprise Voice number normalization rules, location profiles, voice policy, and routes. Route Helper is available in the Office Communications Server 2007 Resource Kit.

Location Profiles

Planning location profiles consists of:

• Listing all the locales in which your organization has an office.

  In a large multinational company with numerous small branch offices this can be a time-consuming task. The list must be up to date and complete. It will need to be revised as company organization evolves.

• Identifying valid number patterns for each locale.

  The most time-consuming part of planning your location profiles is identifying the valid number patterns for each location. In some cases, you may be able to copy normalization rules that you have written for one location profile to other location profiles, especially if the corresponding locales are within the same country or even on the same continent. In other cases, small changes may be enough to make normalization rules appropriate in other locations.

• Developing an organization-wide scheme for naming location profiles and their corresponding Exchange Server 2007 UM dial plans.

  Adopting a standard naming scheme assures that names assigned to location profiles and their corresponding UM dial plans are consistent across the organization and over time, regardless of who or how many people are doing the work.

• Deciding whether multiple location profiles are required for a single location.

  If your organization maintains a single dial plan across multiple locations, you may still need to create a separate dial plan for Enterprise Voice users who are migrating from a PBX and need to have their existing extensions retained.

• Deciding whether to deploy Exchange UM before or after you have created location profiles.

  If you deploy Exchange UM before you create location profiles (recommended), then assigning names to location profiles consists simply of using the FQDN of their corresponding dial plans.

  If you create location profiles before you deploy Exchange UM, you have two main options:

  • Rename the location profiles later, when you know the FQDNs of their corresponding UM dial plans.

  • Duplicate existing location profiles and rename the copies with the FQDNs of their corresponding UM dial plans. You can keep the old location profiles, so long as you use the new ones when configuring Exchange UM.

• Assigning location profiles to Communications Server Front End Server, Enterprise Edition Pool, and Mediation Servers (or Advanced Media Gateways).

  Mediation Servers use location profiles to convert incoming numbers from a national number format to E.164 format for purposes of routing to Communications Server. Each Communications Server 2007 Front End Server and pool must be associated with a location profile to determine how outgoing calls to the PSTN or a PBX are to be routed.

• Determining whether you will need to configure your location profiles to handle scenarios in which Exchange UM initiates calls on a users behalf. For more information about this issue, along with the pros and cons of two options, see Configuring Location Profiles for Exchange UM Call Initiation Scenarios later in this topic.

When you create a location profile, you must provide a name, a description, and a set of normalization rules.

Name

A location profile name normally should reflect the location to which it applies, and within certain constraints the choice is yours. However, integrating Exchange UM with Communications Server imposes an additional requirement on location profile names; namely, that they match the FQDNs of their corresponding UM dial plans. For example, if the name of a UM dial plan is "London," then the name of the corresponding location profile must be London.forestFQDN, where forest FQDN is the forest in which the UM dial plan is located.

These values are captured in the phone-context attribute of the Exchange UM dial plan. For example, if the Exchange UM dial plan name is, say, London*,* then the phone-context attribute is set to London.forestFQDN. And if the forest FQDN is Contoso.com*,* then the name of the London location profile should be London.Contoso.com.

With regard to naming location profiles, you have two deployment options:

Regardless of the order of deployment, a separate location profile must exist for each Exchange UM dial plan. If the same dial plan name is used in multiple Exchange forests, a matching location profile must be created that matches the UM dial plan FQDN for each forest.

The OCSUMUtil tool that is included with Office Communications Server 2007 can be used to validate location profile names. The tool does not correct invalid names; it simply alerts you to the need to do so. For information about using this tool, see Step 1. Configure Exchange UM to Work with Communications Server.

Note

If you are not deploying Exchange 2007 Unified Messaging, then you can, with only a few constraints, give whatever name you like to a location profile, so long as that name is unique.

Description

We recommend that you type the common, recognizable name of the geographic location to which the corresponding location profile applies. For example, if the location profile name is London.Contoso.com, then the recommended Description would be London. If you have deployed the Office Communicator 2007 Phone Edition, the name in this field will be displayed to end users for the purpose of allowing them to select the appropriate location profile for a call.

Normalization rules

Normalization rules specify how to convert numbers dialed in various formats to standard E.164 format. Normalization rules are necessary for call routing and authorization because users can, and do, use various formats when entering phone numbers in their contact lists.

Normalizing user-supplied phone numbers provides a consistent format that facilitates:

• Matching a dialed number to the intended recipient's SIP-URI.

• Applying dialing authorization rules to the calling party.

The following number fields are among those that your normalization rules may need to account for:

• Dial plan

• Country Code

• Area Code

• Length of extension

• Site prefix

You create normalization rules in the Communications Server 2007 snap-in for MMC, using .NET Regular Expressions. Table 7 shows sample normalization rules that are written as .NET regular expressions. The samples are examples only and are not meant to be a prescriptive reference for creating normalization rules.

Table 7. Normalization Rules Using .NET Regular Expressions

Rule Name	Description	Number Pattern	Translation	Example
4digitExtension	Translates 4-digit extensions	^(\d{4})$	+1425555$1	0100 is translated to +1425550100
5digitExtension	Translates 5-digit extensions that begin with the digit 5	^5(\d{4})$	+1425555$1	50100 is translated to +14255550100
7digitcallingRedmond	Translates 7-digit numbers to Redmond local number	^(\d{7})$	+1425$1	5550100 is translated to +14255550100
7digitcallingDallas	Translates 7-digit numbers to Dallas local number	^(\d{7})$	+1972$1	5550100 is translated to +19725550100
10digitcallingUS	Translates 10-digit numbers in US	^(\d{10})$	+1$1	2065550100 is translated to +12065550100
LDCallingUS	Translates numbers with LD prefix in US	^1(\d{10})$	+$1	12145550100 is translated to +12145550100
IntlCallingUS	Translates numbers with international prefix in US	^011(\d*)$	+$1	01191445550100 is translated to +91445550100
RedmondOperator	Translates 0 to Redmond Operator	^0$	+14255550100	0 is translated to +14255550100
RedmondSitePrefix	Translates numbers with on-net prefix (6) and Redmond site code (222)	^6222(\d{4})$	+1425555$1	62220100 is translated to +14255550100
NYSitePrefix	Translates numbers with on-net prefix (6) and NY site code (333)	^6333(\d{4})$	+1202555$1	63330100 is translated to +12025550100
DallasSitePrefix	Translates numbers with on-net prefix (6) and Dallas site code (444)	^6444(\d{4})$	+1972555$1	64440100 is translated to +19725550100

The normalization rules contained in location profiles are used by the Communicator Phone Edition to optimize the users dialing experience. When the Communicator Phone Edition is off hook while a user is entering digits, it uses the rules contained in the location profile to determine if sufficient digits have been entered in order to generate an INVITE request to Communications Server.

For detailed information about using .NET regular expressions, see .NET Framework Regular Expressions at https://r.office.microsoft.com/r/rlidOCS?clid=1033&p1=RegExpr.

Note

For additional assistance with regular expressions, consider using the Route Helper application that is included in the Office Communications Server 2007 Resource Kit. Route Helper is an alternative to the MMC snap-in for viewing and modifying Enterprise Voice number normalization rules, location profiles, voice policy, and routes.

The following table illustrates a sample location profile for Redmond, Washington, USA, based on the normalization rules shown in the previous table.

Table 8. Redmond location profile based on Table 7 normalization rules

Redmond.forestFQDN

5digitExtension

7digitcallingRedmond

10digitcallingUS

IntlCallingUS

RedmondSitePrefix

NYSitePrefix

DallasSitePrefix

RedmondOperator

Note

The normalization rules names shown in the preceding table do not include spaces, but this is a matter of choice. The first name in the table, for example, could have been written "5 digit extension" or "5-digit Extension" and still be valid.

Configuring Location Profiles for Exchange UM Call Initiation Scenarios

Multiple scenarios, such as playing a voice message on the phone or calling a personal contact, require Exchange UM to initiate calls on a user's behalf. Often, the targets of such calls are users in the GAL or people in a user's personal contacts. Calls initiated by UM are routed through Communications Server, just like calls from other clients.

When Exchange UM SP1 sends an E.164 number to Communications Server, UM does not pass the prefixed plus sign (+) required for E.164 numbers. To work around this problem, two options are available to administrators:

Option 1: Define one location profile for both UM and Communications Server clients

This option requires that you add rules to the location profile that identify E.164 numbers whose plus sign (+) prefix is missing. For example, a Redmond, WA, USA, location profile might require a rule that prefixes the plus sign (+) to all 11-digit numbers starting with the number 1. In practice, formulating rules that correctly identify all instances of E.164 numbers whose initial plus sign (+) is missing can be difficult and time-consuming.

This is the recommended option when the dial patterns are similar across Communications Server clients and UM (for example, when there is no requirement for an off-net prefix).

Even when dialing patterns are not similar across Communications Server clients and UM, administrators have the option of defining and ordering normalization rules to cater to both scenarios. This approach introduces additional complexity, but enables Communications Server clients to make calls from Outlook contact lists, even if the number format does not adhere to the normal dial plan.

Option 2: Define two location profiles - one that translates numbers from Communications Server clients, and another one that translates numbers from Exchange UM

This option eliminates the complexity of having to assure that a single location profile accounts for two sets of dialing patterns, one from Exchange UM, the other from Communications Server clients. The disadvantage is the need to configure and maintain two location profiles.

Phone Usage Records

Planning phone usage records consists mainly of listing all the call permissions that are currently in force in your organization, from the CEO down to temporary workers, consultants, and contingent staff. This process also provides an opportunity to re-examine existing permissions and revise them if desired. You can create phone usage records only for those permissions that apply to your anticipated Enterprise Voice users, but a better long-range solution might be to simply create phone usage records for all permissions regardless of whether some may not currently apply to the group of users to be enabled for Enterprise Voice. If permissions change or new users with different permissions are added, you will have already created the required phone usage records.

Table 9 shows a typical phone usage table:

Table 9. Phone Usage Records

Phone Attribute	Description
Local	Local calls
Long-Distance	Long distance calls
International	International calls
Delhi	Delhi full-time employees
Redmond	Redmond full-time employees
RedmondTemps	Redmond temporary employees
Zurich	Zurich full-time employees

By themselves, phone usage records do not do anything. For them to work, you must associate them with:

• Voice policies, which are assigned to users.

• Routes, which are assigned to phone numbers.

The following two topics describe voice policies and routes. For information about how to create and configure them, see Step 7. Configure Outbound Call Routing.

Voice Policies

Enterprise Voice policies are essentially collections of phone usage records that are assigned to one or more users. Policies also include an option of enabling or disabling the simultaneous ringing feature. The simultaneous ringing feature enables users to configure Communicator such that incoming calls, in addition to ringing the users registered endpoints, also ring an additional nonregistered endpoint, such as a personal mobile phone. Normally, simultaneous ringing should be enabled, but in the event of excessive congestion, you have the ability to disable this feature.

Most organizations will have multiple voice policies, typically a default policy that applies to all users and one or more special policies that are applied on a per-user basis. You have the option of creating your own voice policies from scratch or editing existing policies.

Phone usage order is critical because in matching users to routes, the server compares phone usages from top to bottom. If the first usage matches the call route, the call is routed. The remaining phone usages provide backup in the event of route congestion or call failure.

Defining voice policies for users includes:

• Creating a default policy for your organization. This policy will apply to all users to whom you have not explicitly assigned a per user policy.

• Defining one or more per-user policies as needed.

• Adding one or more phone usage records (see "To Create a Phone Usage Record" in Step 7. Configure Outbound Call Routing).

• Specifying whether to enable the simultaneous ringing feature for Enterprise Voice users (not supported for PBX coexistence scenarios).

You create voice policies in the Communications Server 2007 MMC snap-in.

• If you want to apply a single policy to all Enterprise Voice users in your organization, then you need only to choose or customize the default policy.

• If you want to apply special policies to certain individuals or groups of Enterprise Voice users, then you must choose the "Use per user" option, and then create one or more special policies and explicitly assign them to specific individuals or groups of users. Any users to whom you do not explicitly assign a policy will be governed by the default policy.

Call Routes

Enterprise Voice Routes specify how Communications Server 2007 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 have completed the following steps:

• Deployed one or more media gateways and, if necessary, Communications Server 2007, Mediation Servers.

• Created a location profile consisting of normalization rules for target phone numbers.

• Created 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 usages that users must have in order to call numbers matching the target phone number regular expression.

You create routes in the Communications Server 2007 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 logic.

• 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 will reject the call and the Outbound Routing Component will redirect 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 non-local 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.

Routing Configuration Examples

This section will provide guidance on routing configuration on some common scenarios, this is by no means a prescriptive guidance, but is just meant to illustrate the flexibility offered by the routing framework.

As mentioned earlier, the routing logic uses the phone usage attribute assigned to the caller as well as the dialed number in order to determine the optimal route. The following scenarios include configuration settings for phone usages for the user and routing table configuration to accomplish the desired routing behavior.

Important

The following examples demonstrate how routes are configured in Communications Server. For these routes to work, numbers routed to each gateway must be localized on the gateway, using the gateways administrative interface.

The following figure captures the gateway deployment and site topology that will be used to illustrate the scenarios in this section:

Figure 18. Gateway deployment and site topology

The following are the characteristics in the sample deployment:

• 3 sites (Redmond, Dallas, New York)

• Redmond site has 2 gateways (Red-GW1, Red-GW2)

• Dallas site has 1 gateway (Dallas-GW1)

The example scenarios in this section assume that the normalization rule and location profiles have been configured, and the post-translated number is what is used for the routing decision.

Note

The examples in this section assume that gateways have been deployed and configured, Please refer to the Deployment guide for instructions on gateway deployment.

Basic Routing Setup

Assuming that a few users from Redmond, Dallas, and New York are being enabled for Enterprise Voice, here is a sample definition of a phone usages and routes that enable a very basic routing setup:

Note

The phone usage names used in the following examples omit spaces, but this is a matter of taste or convention. Spaces are valid for phone usage names.

User Policy	Phone Usages
Default Calling Policy	GlobalPSTNHopoff

Route Name	Number Pattern	Phone Usages	Gateway
Universal Route	^\+?(\d*)$	GlobalPSTNHopoff	Red-GW1 Red-GW2 Dallas-GW1

In the previous example, all the users that are being enabled for Enterprise Voice in the three sites are assigned a policy of DefaultCallingPolicy

The illustrated route is configured to direct all calls from users with a phone usage of GlobalPSTNHopoff (users with DefaultCallingPolicy, in this example) to one of three gateways (the \+? indicates that the leading + is optional).

Using the Correct Gateway for Local Calls

Extending the previous simple example, if administrators would like to configure the routes so that calls that are local to the context of the gateway are routed via that gateway, and other calls are routed through any of the gateways, the following configuration enables that scenario:

User Policy	Phone Usages
Default Calling Policy	Local GlobalPSTNHopoff

Route Name	Number Pattern	Phone Usages	Gateway
Redmond Local Route	^\+1(425|206|253)(\d{7})$	Local	Red-GW1 Red-GW2
Dallas Local Route	^\+1(972|214|469)(\d{7})$	Local	Dallas-GW1
Universal Route	^\+?(\d*)$	GlobalPSTNHopoff	Red-GW1 Red-GW2 Dallas-GW1

• All users are assigned the Default Calling Policy.

• The policy has two phone usage attributes, Local and GlobalPSTNHopOff. For any number dialed by users with this policy, a route matching the Local phone usage attribute is sought first before trying to match a route with the GlobalPSTNHopoff phone usage attribute.

• Redmond Local Route: This route will be used for calls made to a number that starts with +1 followed by 425, 206, or 253, followed by seven digits, for users with a phone usage of Local.

• Dallas Local Route: This route will be used for calls made to a number that starts with +1 followed by 972, 214, 469, or 817, followed by seven digits, for users with a phone usage of Local.

Examples:

• Calls made to +14255550100 are routed using either Red-GW1 or Red-GW2 (Redmond Local Route).

• Calls made to +12145550100 are routed using Dallas-GW1 (Dallas Local Route).

• Calls made to +12035550100 are routed using Red-GW1, Red-GW2, or Dallas-GW1 (Universal Route).

• If Dallas-GW1 is unavailable, calls made to +12145550100 are routed using the Universal Route (based on using the globalPSTNHopOff phone usage).

Limit Certain Users to Call Only Local Numbers

This scenario illustrates an example where an administrator in Redmond would like to set up a calling policy to limit certain users in Redmond to just call local numbers in the Redmond Area:

User Policy	Phone Usages
Default Calling Policy	Local GlobalPSTNHopoff
Redmond Local Policy	RedmondLocal

Route Name	Number Pattern	Phone Usages	Gateway
Redmond Local Route	^\+1(425|206|253)(\d{7})$	Local RedmondLocal	Red-GW1 Red-GW2
Dallas Local Route	^\+1(972|214|469)(\d{7})$	Local	Dallas-GW1
Universal Route	^\+?(\d*)$	GlobalPSTNHopoff	Red-GW1 Red-GW2 Dallas-GW1

• Administrators assign the Redmond Local Policy to users for whom they would like to restrict the calling to just Redmond destinations.

• Since the only route that has the RedmondLocal phone usage is Redmond Local Route, that is the only authorized route for users with the Redmond Local Policy.

Source-Based Routing

There are certain situations where the administrator would like to limit the gateway that is used for calls from users from a particular location. The following configuration illustrates how this may be accomplished for a situation where an administrator would like to limit calls from Dallas users to always exit out of the Dallas gateway:

User Policy	Phone Usages
Default Calling Policy	Local GlobalPSTNHopoff
Redmond Local Policy	RedmondLocal
Dallas Calling Policy	DallasUsers

Route Name	Number Pattern	Phone Usages	Gateway
Redmond Local Route	^\+1(425|206|253)(\d{7})$	Local RedmondLocal	Red-GW1 Red-GW2
Dallas Local Route	^\+1(972|214|469)(\d{7})$	Local	Dallas-GW1
Universal Route	^\+?(\d*)$	GlobalPSTNHopoff	Red-GW1 Red-GW2 Dallas-GW1
Dallas Users Route	^\+?(\d*)$	DallasUsers	Dallas-GW1

• Administrator creates a policy called Dallas Calling Policy and assigns a phone usage of DallasUsers to it.

• All users in Dallas are assigned the Dallas Calling Policy.

• For a call originated by a user with this policy, since the only route that contains this policy is the Dallas Users Route, Dallas-GW1 is always selected as the egress gateway for all calls.

Note that the previous configuration example does not preclude users from other locations (for example, with Default Calling Policy) from using the gateway located in Dallas.

Configuring a Failover Route

Extending the previous example, if an administrator wants to define a failover route that may be used in case the Dallas-GW1 is brought down for maintenance, or is unavailable, the following example illustrates the required configuration change:

User Policy	Phone Usages
Default Calling Policy	Local GlobalPSTNHopoff
Redmond Local Policy	RedmondLocal
Dallas Calling Policy	DallasUsers GlobalPSTNHopoff

Route Name	Number Pattern	Phone Usages	Gateway
Redmond Local Route	^\+1(425|206|253)(\d{7})$	Local RedmondLocal	Red-GW1 Red-GW2
Dallas Local Route	^\+1(972|214|469)(\d{7})$	Local	Dallas-GW1
Universal Route	^\+?(\d*)$	GlobalPSTNHopoff	Red-GW1 Red-GW2 Dallas-GW1
Dallas Users Route	^\+?(\d*)$	DallasUsers	Dallas-GW1

• In the previous example, a phone usage of GlobalPSTNHopoff is added after the DallasUsers phone usage in the Dallas Calling Policy.

• This enables calls with the Dallas Calling policy to use routes that are configured for the GlobalPSTNHopoff if a route for DallasUsers phone usage is unavailable.

Setting up Basic 911 Routing

Basic 911 routing requires that calls to 911 is routed to the gateway local to the location of the user, this may be accomplished using the following configuration:

User Policy	Phone Usages
Default Calling Policy	Local GlobalPSTNHopoff
Redmond Calling Policy	Redmond911 Local GlobalPSTNHopoff
Redmond Local Policy	Redmond911 RedmondLocal
Dallas Calling Policy	Dallas911 DallasUsers GlobalPSTNHopoff

Route Name	Number Pattern	Phone Usages	Gateway
Redmond Local Route	^\+1(425|206|253)(\d{7})$	Local RedmondLocal	Red-GW1 Red-GW2
Dallas Local Route	^\+1(972|214|469)(\d{7})$	Local	Dallas-GW1
Universal Route	^\+?(\d*)$	GlobalPSTNHopoff	Red-GW1 Red-GW2 Dallas-GW1
Dallas Users Route	^\+?(\d*)$	DallasUsers	Dallas-GW1
Redmond 911 route	^911$	Redmond911	Red-GW1
Dallas 911 route	^911$	Dallas911	Dallas-GW1

• A new policy called Redmond Calling Policy is created and a phone usage of Redmond911 is added to it, similarly a phone usage of Dallas911 is added to the Dallas Calling Policy.

• 911 calls made from users with a phone usage of Redmond911 will be routed via Red-GW1 using the Redmond 911 route, and users with a phone usage of Dallas911 are routed via the Dallas 911 route.

The previous configuration illustrates the flexibility where the same number is routed via different gateways based on the calling user.

Setting up an International Gateway

Due to lower negotiated international calling rates from a particular site, administrators might want to route all international calls from the US through a particular gateway, the following configuration illustrates how all international calls are routed via Red-GW1.

User Policy	Phone Usages
Default Calling Policy	Local International GlobalPSTNHopoff

Route Name	Number Pattern	Phone Usages	Gateway
Redmond Local Route	^\+1(425|206|253)(\d{7})$	Local	Red-GW1 Red-GW2
Dallas Local Route	^\+1(972|214|469)(\d{7})$	Local	Dallas-GW1
Universal Route	^\+?(\d*)$	GlobalPSTNHopoff	Red-GW1 Red-GW2 Dallas-GW1
Intl Route	^\+([2-9])(\d*)$	International	Red-GW1

Although there are different ways to implement regular expression patterns, the previous example shows a sample configuration.

• A phone usage of International is added to the policy.

• An Intl route is introduced that matches a number that starts with +2 through +9 (international to the US), and has a phone usage of international.

Configuring a New Gateway

If for instance, the administrator decided to deploy a new gateway, once the gateway is set up and configured, the gateway can be configured into the Routing tables. In this example, a new gateway is deployed in New York and is configured to be the gateway of choice for local New York numbers and also is used as part of the Universal Route.

User Policy	Phone Usages
Default Calling Policy	Local International GlobalPSTNHopoff

Route Name	Number Pattern	Phone Usages	Gateway
Redmond Local Route	^\+1(425|206|253)(\d{7})$	Local	Red-GW1 Red-GW2
Dallas Local Route	^\+1(972|214|469)(\d{7})$	Local	Dallas-GW1
NY Local Route	^\+1(212|646|917)(\d{7})$	Local	NY-GW1
Universal Route	^\+?(\d*)$	GlobalPSTNHopoff	Red-GW1 Red-GW2 Dallas-GW1 NY-GW1
Intl Route	^\+([2-9])(\d*)$	International	Red-GW1

A new route is created to route calls local to NY via the new NY-GW1.

The same gateway is also added to the Universal route to help with load sharing.

Blocking Calls to Certain Destination Numbers

There are situations where the administrator would like to block calls from the enterprise to certain destinations due to toll charges (for example, premium numbers such as 1900 numbers, operator assistance, 1411, and so on).

Note that the current release of Office Communications Server does not allow for a configuration that can be used to explicitly block a destination. Calls are blocked implicitly if there is no matching pattern found in the Routing table.

For example, an administrator who chooses to block calls to 1900 and 1411 numbers would have to define regular expressions that exclude 1900*. The following configuration shows an example of how this can be accomplished, and does not preclude other ways of accomplishing the same effect.

User Policy	Phone Usages
Default Calling Policy	Local International GlobalPSTNHopoff

Route Name	Number Pattern	Phone Usages	Gateway
Redmond Local Route	^\+1(425|206|253)(\d{7})$	Local	Red-GW1 Red-GW2
Dallas Local Route	^\+1(972|214|469)(\d{7})$	Local	Dallas-GW1
NY Local Route	^\+1(212|646|917)(\d{7})$	Local	NY-GW1
Universal Route	^\+?(?!(1900|1411))(\d*)$	GlobalPSTNHopoff	Red-GW1 Red-GW2 Dallas-GW1 NY-GW1
Intl Route	^\+([2-9])(\d*)$	International	Red-GW1

The Universal Route is modified to route on all numbers except 1900 or 1411 numbers with an optional leading PLUS SIGN (+).