Ordering Normalization Rules

Site prefix scenarios directly affect Lync Server telephone URIs and dial-plan normalization rules. In Lync Server 2013, a telephone URI must be unique across the organization for it to be routed correctly. This means that even if Alice and Joe have the same extension within their own offices, their Line URIs must still be unique.

For example, assume that San Francisco users have DID numbers all using the +1 (415) 777-3xxx format. Alice’s telephone URI should be assigned as tel:+14157773234. Joe’s office has DIDs as well with a +1 (312) 444-5xxx format, and his telephone URI can be assigned as tel:+13124445234.

Now the URIs are unique, but this does not account for the expected user behavior of how to dial three digits in each location to reach local users. For example, users in San Francisco and Chicago both expect to use three-digit dialing, but depending on which office the call originates from, it should route to a different user. Users in San Francisco expect to reach Alice when they dial 234, and users in Chicago expect to reach Joe when they dial 234. This must be handled by using separate dial plans and normalization rules for the two sites.

For each unique site, administrators must create a separate dial plan to be assigned to users. These dial plans also contain different normalization rules depending on the site prefixes assigned.

Continuing the previous example, a San Francisco dial plan is assigned to Alice and Bob, which accommodates three-digit dialing rules that resolve to the local users. A separate rule needs to exist for dialing Chicago extensions which allows callers to reach Joe using 6 as the site prefix.

In this scenario, the San Francisco dial plan should contain rules such as the following:

Dial Plan: San Francisco

Name: Three-digit San Francisco extensions

Starting Digits: Blank

Length: Exactly three digits

Digits to Remove: None

Digits to Add: +14157773

This rule takes three digits and converts them to +14157773xxx so that San Francisco users can use three digits to reach a local user. In addition to this rule, the San Francisco dial plan needs another rule to accommodate dialing a site prefix to Chicago users:

Dial Plan: San Francisco

Name: Four digits to Chicago

Starting Digits: 6

Length: Exactly four digits

Digits to Remove: 1

Digits to Add: +13125554

This rule matches a four-digit string starting with 6, the Chicago site prefix, removes the 6, and then prepends +13125554 to the remaining three digits. Once assigned to the San Francisco users account, Bob can dial 234, which translates to +14157773234 and matches Alice’s account. Bob can also dial 6234, which translates to +13125554234 and matches Joe’s account in Chicago.

On the opposite site, the Chicago dial plan contains at least two rules to facilitate local three-digit dialing to Chicago users and uses a site prefix of 7 to reach San Francisco users.

Dial Plan: Chicago

Name: Three digits to Chicago

Starting Digits: Blank

Length: Exactly three digits

Digits to Remove: None

Digits to Add: +13125554

Dial Plan: Chicago

Name: Four digits to San Francisco

Starting Digits: 7

Length: Exactly four digits

Digits to Remove: 1

Digits to Add: +14157773

It is easy to see how complex a dial plan can become when multiple overlapping sites are involved. This example uses only two sites, but for an organization with many sites, some significant planning should be performed in advance of the Lync Server 2010 voice deployment. For example, imagine if Company ABC later opens sites in New York and Seattle. Each site will require a unique dial plan, and normalization rules to accommodate extension-based dialing.

When beginning to develop a dial plan use the following tips:

• Collect all the existing extensions for a site and the associated DID ranges.

• Determine whether sites have overlapping extensions and whether site prefixes will be required.

• Order the normalization rules properly within each dial plan. Remember that the rules are processed in a top-down fashion.

• Always assign E.164-formatted telephone URIs to user accounts.