A dial plan’s scope determines the hierarchical level at which the dial plan can be applied. In Lync Server 2010, a user can be assigned a specific per-user dial plan. If a user dial plan is not assigned, the Registrar pool dial plan is applied. If there is no Registrar pool dial plan, the site dial plan is applied. Finally, if there is no other dial plan applicable to the user, the global dial plan is applied.

Clients obtain dial plan scope levels through in-band provisioning settings provided when users log on to Lync Server. As the administrator, you can manage and assign dial plan scope levels using Lync Server Control Panel.

Note:
The service level PSTN gateway dial plan is applied to the incoming calls from a particular gateway.

Dial plan scope levels are defined as follows:

• 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. 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.
  
  The list must be up to date and complete. It will need to be revised as company organization evolves. In a large multinational company with numerous small branch offices, this can be a time-consuming task.
  
  
• 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 who need to have their existing extensions retained.
  
  
• Deciding whether per-user dial plans are required. For example, if you have users at a branch site who are registered with the central site or if you have users who are registered on a Survivable Branch Appliance, you can address special dialing scenarios with per-user dial plans and normalization rules. For details, see Branch-Site Resiliency Requirements.
  
  
• Determining dial plan scope (as previously described in this topic).
  
  

To create a dial plan, you specify values in the following fields, as required, by using Lync Server Control Panel or Lync Server Management Shell.

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 because users can, and do, use various formats when entering phone numbers in their Contacts lists.

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

• 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 +2145550100
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, United States, 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.