Site Prefixes

A common scenario with an organization spread across multiple sites is that extensions are not unique within the organization. Typically, a PBX exists in each site and the same extensions are used across sites. When this occurs, users can either use a DID to reach users in another site or a site prefix might be assigned.

For example, consider a scenario where Company ABC has offices in San Francisco and San Jose. Alice and Bob both work in the San Francisco office where Alice has extension 234 and Bob has extension 456. When Bob wants to dial Alice, he can simply dial 234 and be connected immediately. Now assume Joe works in the San Jose office where a different PBX exists, also with extension 234. Bob cannot dial Joe using 234 because he will connect to Alice instead.

What happens as a workaround is a site prefix code is assigned to Bob’s dial plan so that he can dial San Jose extensions by prepending an extra digit. In this scenario, assume 6 is the site prefix for San Jose from San Francisco. This means Bob can dial 6234 and be connected to Joe, but still dial 234 to reach Alice directly.

The same kind of site prefix is used in this scenario for San Jose users to dial San Francisco users directly. In Company ABC’s case, San Jose users must use 7 as a prefix to dial San Francisco. Although Joe and Alice have the same three-digit extension, Joe can contact Alice by dialing 7234.

Site prefixes can be potentially confusing for end users because it requires them to remember to dial extra digits for different sites. Oftentimes, they have to consult a list of site prefixes or look up a contact phone number when dialing a different location.

Remembering site prefixes is mitigated by Lync Server 2010 endpoints because most of the dialing can be done by simply clicking a contact. As opposed to traditional telephony, users will become more and more reliant on click-to-dial features instead of remembering extensions. Despite the ease of the user experience, administrators will still be tasked with correctly assigning site prefixes to telephone URIs and creating appropriate normalization rules. This can become a complex voice routing and dial plan configuration in the end.

How Site Prefixes Affect Normalization Rules

Site prefix scenarios directly affect Lync Server telephone URIs and dial plan normalization rules. In Lync Server 2010, a telephone URI must be unique across the organization for it to be routed correctly. This means that Alice and Joe cannot both have a telephone URI of tel:+234 assigned because this is not unique.

For example, assume San Francisco users have DID numbers all using the +1 (415) 333-3xxx format. Alice’s telephone URI should be assigned as tel:+14153333234. Joe’s office has DIDs as well with a +1 (408) 444-4xxxx format, and his telephone URI can be assigned as tel:+14154444234.

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 San Jose both expect to use three-digit dialing, but depending on which office the call originates from, it should route to a different user. This must be handled by using separate dial plans and normalization rules.

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 San Jose extensions with a 6 as the site prefix, but still be routed to Joe’s URI.

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

Dial Plan: San Francisco

Name: 3 digits to San Francisco

Starting Digits: Blank

Length: Exactly three digits

Digits to Remove: None

Digits to Add: +14153333

This rule takes three digits and converts it to +14153333xxx 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 San Jose users:

Dial Plan: San Francisco

Name: 4 digits to San Jose

Starting Digits: 6

Length: Exactly four digits

Digits to Remove: 1

Digits to Add: +14084444

This rule matches a four-digit string starting with 6, the San Jose site prefix, removes the 6, and then prepends +14084444 to the remaining three digits. Once assigned to the San Francisco site, pool, or users accounts, Bob can dial 234, which translates to +14153333234 and matches Alice’s account. Bob can also dial 6234, which translates to +14084444234 that matches Joe’s account in San Jose.

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

Dial Plan: San Jose

Name: 3 digits to San Jose

Starting Digits: Blank

Length: Exactly three digits

Digits to Remove: None

Digits to Add: +14084444

Dial Plan: San Jose

Name: 4 digits to San Francisco

Starting Digits: 7

Length: Exactly four digits

Digits to Remove: 1

Digits to Add: +14153333

It is easy to see how complex a dial plan can become when multiple overlapping sites are involved. This example only uses two sites, but for an organization with many sites, some significant planning should be performed in advance of the Lync Server 2010 voice deployment.

To simplify the dial plan, use the following guidance:

• Assign unique extensions to users whenever possible.

• Assign E.164-formatted telephone URIs to user accounts.

• Create and use the test cases in the voice routing configuration to validate a dial plan.