Normalization Rules
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.
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 recipients 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. The following table 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 85 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 +14255550100 |
5digitExtension |
Translates 5-digit extensions |
^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.
The following table illustrates a sample location profile for Redmond, Washington, USA, based on the normalization rules shown in the previous table.
Table 86 Redmond location profile based on normalization rules shown in the previous table
| 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 users behalf. Often, the targets of such calls are users in the GAL or people in a users 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.