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 Office Communications Server 2007 R2 snap-in for the Microsoft Management Console (MMC), using .NET Framework regular expressions. The following table shows sample normalization rules that are written as .NET Framework regular expressions. The samples are examples only and are not meant to be a prescriptive reference for creating normalization rules.
Table 1.Normalization Rules Using .NET Framework 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 numbers |
^(\d{7})$ |
+1425$1 |
5550100 is translated to +14255550100 |
|
7digitcallingDallas |
Translates 7-digit numbers to Dallas local numbers |
^(\d{7})$ |
+1972$1 |
5550100 is translated to +19725550100 |
|
10digitcallingUS |
Translates 10-digit numbers in the United States |
^(\d{10})$ |
+1$1 |
2065550100 is translated to +12065550100 |
|
LDCallingUS |
Translates numbers with long distance prefixes in the United States |
^1(\d{10})$ |
+$1 |
12145550100 is translated to +12145550100 |
|
IntlCallingUS |
Translates numbers with international prefixes in the United States |
^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 Microsoft Office Communicator 2007 R2 Phone Edition to optimize the user’s dialing experience. When Communicator 2007 R2 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 Office Communications Server.
For details about using .NET Framework regular expressions, see
“.NET Framework Regular Expressions” at
 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 2. 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. |
Phone Number Normalization Rules
Enhancements in Office Communications Server 2007 R2
Office Communications Server 2007 R2 has a new enhancement to phone number normalization that can prevent ambiguous results when users dial off-hook (that is, when they dial with the handset not in the cradle or when they use the speakerphone) and an external access prefix matches a long-distance prefix.
Normalization Rules in Office Communications Server 2007
Devices such as Communicator Phone Edition use normalization rules to interpret the digits entered by users when they are dialing off-hook. During off-hook dialing, as a user enters digits using the dial pad, the telephone compares the numbers that are entered with the normalization rules. When a match is detected, the telephone initiates the call by sending a SIP INVITErequest to Office Communications Server. If the dial plan has rules with overlapping digit sequences, users can get ambiguous results when they use off-hook dialing.
For example:
- The rule
[^9425(\d{7})$ +1425$1]translates a 10-digit telephone
number starting with
9425into an 11-digit number starting with
+1, converting
94255550100into
14255550100.
- The rule
[^(\d{5})$ +125355$1]translates a 5-digit telephone number
into an 11-digit number starting with
+125355, converting
90101into
+12535590101.
When a user dials the number 94255550102, as soon 42555is entered, a match is detected with the second rule and a call is initiated (that is, a SIP INVITErequest is sent) prematurely.
To alleviate this issue in Office Communications Server 2007, rules containing the character sequence t?are ignored by Communicator Phone Edition and not used to perform off-hook dialing optimization.
Normalization Rules in Office Communications Server 2007 R2
To correct the issue described in the previous section, in Office Communications Server 2007 R2:
- The administrator can define the external access prefix for the
location profile to help disambiguate the overlapping rules.
- The administrator can flag the rules that map to internal
enterprise phone numbers.
These changes have the following effects:
- The schema changes to the location profile and the
normalization rules are sent to the client (such as the
Communicator Phone Edition) via in-band provisioning.
- All rules specific for Communicator Phone Edition can be
removed from the location profile. For example, the
t?character sequence described previously can be removed
from the regular expressions because it is no longer necessary.
- If the first digit dialed by a user matches the external access
prefix, the device (such as Communicator Phone Edition) ignores the
digit and does not use rules that are tagged as
InternalExtension. For example, if a user dials
08005551212, the first zero is removed by the device and the
call is handled as a toll-free call. Because telephone numbers
starting with a
0are not treated as internal extensions, a normalization
rule match is not made as soon as the user dials the first four
digits.
- If the administrator wants to unify the on-hook and off-hook
dialing experiences, rules that are specific to Office Communicator
and do not apply to the telephone device must be tagged with the
doNotdialFromDeviceflag, which causes the device to ignore
those rules when it performs rule matching. For example, using the
preceding dialing rules example, calls from the device to local
numbers must be prefixed with a
0, but Office Communicator calls can be made without adding
a leading
0.
For details about configuring Office Communications Server 2007 R2 with normalization rule enhancements, see Planning for Voice.
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 global address list or people in a user’s personal contacts. Calls initiated by UM are routed through Office Communications Server, just like calls from other clients.
When Exchange UM SP1 sends an E.164 number to Office 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, United States, 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 Office 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 Office 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 it enables Office 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 Office 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 Office Communications Server clients. The disadvantage is the need to configure and maintain two location profiles.