A dial plan’s scope determines the hierarchical level at which the dial plan can be applied. In Microsoft Communications Server 2010, in-band provisioning enables you to configure dial plans with the following scope levels (listed from the most specific to the most general). If a User dial plan is not assigned, in-band provisioning sends the Pool default dial plan. If there is no Pool dial plan, in-band provisioning sends the Site default dial plan. Finally, if there is no other dial plan configured for the user, in-band provisioning sends the Global dial plan.

• User dial plan: can be assigned to individual users, groups, or contact objects. Voice applications can look up and use a per-user dial plan when a phone-context value of user-default is received. Note that for the purpose of assigning a dial plan, a contact object is treated as an individual user.
  
  
• Pool dial plan: can be created at the service level for any PSTN gateway or registrar in your topology. To define a Pool dial plan, you must specify the particular service (PSTN gateway or registrar pool) to which the dial plan applies.
  
  
• Site dial plan: can be created for an entire site, except for any users, groups, or contact objects that are assigned a Pool dial plan or User dial plan. To define a Site dial plan, you must specify the site to which the dial plan applies.
  
  
• Global dial plan: is the default dial plan installed with the product. You can edit the Global dial plan, but you cannot delete it. This dial plan applies to all Enterprise Voice users, groups, and contact objects in your deployment unless you configure and assign a dial plan with more specific scope.
  
  

Planning dial plans 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 site.
  
  The most time-consuming part of planning your dial plans is identifying the valid number patterns for each site. In some cases, you may be able to copy normalization rules that you have written for one dial plan to other dial plans, especially if the corresponding sites are within the same country, region or even continent. In other cases, small changes to numbers in one dial plan may be enough to use them in other dial plans.
  
  
• Developing an organization-wide scheme for naming dial plans.
  
  Adopting a standard naming scheme assures consistency across an organization and makes maintenance and updates easier.
  
  
• Deciding whether multiple dial plans 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 per-user dial plans are required.
  
  
• Assigning dial plans to Communications Server Front End Servers, Enterprise pools, and Mediation Servers.
  
  Mediation Servers use dial plans to convert incoming numbers from a local number format to E.164 format for purposes of routing to Communications Server. Each Microsoft Office Communications Server 2007 Front End Server and pool must be associated with a dial plan to determine how outgoing calls to the public switched telephone network (PSTN) or a PBX are to be routed.
  
  

To create a dial plan, you specify values in the following fields, as required.

Name and Simple Name

Description

Dial-in Conferencing Region

External Access Prefix

You can specify an external access prefix of up to four characters (#, *, and 0-9) if users need to dial one or more additional leading digits (for example, 9) to get an external line.

Note:
If you specify an external access prefix, you do not need to create an additional normalization rule to accommodate the prefix.

Normalization rules define how phone numbers expressed in various formats are to be routed for the named location. The same number string may be interpreted and translated differently depending on the locale from which it is dialed. 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
  
  

Creating Normalization Rules

Sample Normalization Rules

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 your own 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 following table illustrates a sample dial plan for Redmond, Washington, USA, based on the normalization rules shown in the previous table.

Table 2. Redmond Dial Plan Based on Normalization Rules Shown in Table 1

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.