When beginning a Lync Server 2010 voice
deployment, one of the first steps is to determine the dial plan. The
dial plan defines how users will contact other users in the organization
and includes how many digits are used in each site, whether site
prefixes are used, and any number translations
required from site to site. Dial plan objects in Lync Server 2010
contain a collection of normalization rules that are associated with a
site, pool, or directly assigned to user accounts.
Note
In a migration scenario from a legacy PBX, an
organization has the option to maintain as much of the existing dial
plan as possible or to begin developing a new dial plan for Lync Server
210. Which option is selected varies based on the tolerance of the
organization and end users to accommodate changes. However, in many
cases some changes are necessary to facilitate a period of coexistence.
Assigning Telephone URIs
When deploying Lync Server 2010 voice services, an
organization assigns telephone URIs to each user account enabled for
Enterprise Voice. These URIs can either be direct inward dial (DID)
numbers, which are unique both internally and across the PSTN.
Alternatively, the URIs can be based on extensions that are unique only
to the organization or within a site.
When assigning URIs to end users, keep in mind that
all URIs within the organization must be unique. Typically,
organizations with multiple sites have different or multiple DID ranges
per office, or extensions that are unique only within a specific site.
To accommodate these scenarios, multiple dial plans and normalization
rules can be created to accommodate the expectations of end users.
Direct Inward Dialing
The simplest dial plan possible within Lync Server
2010 is when each user in the organization has a direct DID number. DIDs
are unique across the PSTN, and therefore, unique with the Lync Server
deployment. A PSTN caller or an internal user can use the same dial
string to reach another user when DIDs are assigned to each user in the
organization.
Caution
The downside of DIDs is that they are longer dial
strings than an extension, which means that they require a user to enter
more digits to reach a user. The Lync client is primarily based on
click-to-dial functionality, so a dial string becomes less of an issue.
However, for users manually dialing using keypads, this can be
frustrating.
DIDs also typically map to a user’s internal
extension. For example, at Company ABC’s San Francisco office, Alice has
a DID of +1 (415) 333-3234, but internal users can simply dial a
four-digit extension, 3234, to reach Alice. This gives the flexibility
of numbers being unique across the site, but with the capability for
PSTN callers to reach users directly. Internal users also have a short
dial string to remember in order to reach Alice.
On
the Lync Server 2010 configuration side, Alice’s telephone URI field
should be entered as tel:+14153333234 in order to uniquely identify her
in the organization. A normalization rule within the San Francisco dial
plan converts a four-digit extension starting with 3 into the full E.164
URI for users. That rule resembles the following:
Dial Plan: San Francisco
Name: Four digits beginning with 3 to San Francisco
Starting Digits: 3
Length: Exactly four digits
Digits to Remove: None
Digits to Add: +1415333
This rule accommodates the dialing habits of San
Francisco users, but consider a scenario where Company ABC also has a
San Jose office where users have DIDs starting with +1 (408) 444-4xxx.
Because all the San Jose extensions start with a 4, any four-digit
extension beginning with a 4 can be translated to include the San Jose
DID prefix. San Jose users should have a telephone URI assigned
resembling tel:+14084444xxx.
Dial Plan: San Francisco
Name: 4 digits beginning with 4 to San Jose
Starting Digits: 4
Length: Exactly four digits
Digits to Remove: None
Digits to Add: +1408444
After this rule is added to the dial plan, San
Francisco users can dial by entering just four digits on a keypad or
within the Lync client and correctly route to a user in either San
Francisco or San Jose.
Internal Extensions Only
Many times organizations will not offer DID numbers
to users, or might assign DIDs to only some users. In this case, the
remaining users only have an internal extension defined. This is a
completely acceptable deployment option with Lync Server 2010, but there
can be some confusion as to how the telephone URI should be assigned to
user accounts.
The most common method is to identify a main office,
or automated attendant phone number, that external users can dial and be
transferred to in order to reach users with an internal extension. This
type of attendant does not have to exist, but it usually makes sense to
leverage this number in the telephone URI. After this number is
identified, it should be used as the telephone URI with an ;ext=xxx
suffix. The number of digits in the extension field can vary depending
on the organization or even the site.
For
example, let’s say that Company ABC’s San Francisco office does not
offer DIDs to users and uses internal extensions only. The main office
number is +1 (415) 333-3000 and Alice has extension 234. In this case,
Alice’s telephone URI field should be tel:+14153333000;ext=234, which
uniquely identifies her within the organization.
This kind of scenario must also be accounted for
within a dial plan. The dial plan within San Francisco must include a
normalization rule that takes a three-digit dial into this URI, such as
the following rule:
Dial Plan: San Francisco
Name: 3 digits to San Francisco
Starting Digits: Blank
Length: Exactly three digits
Digits to Remove: 0
Digits to Add: +14153333000;ext=
Note
The Normalization Rule Wizard cannot be used to
create this type of rule because the ;ext= component is not a valid
number. Instead, define the regular expression matching pattern and
translation rule manually. In this example, the matching pattern is
^(\d{3}) and the translation rule is +14153333000;ext=$1.
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.
Note
San
Jose users can potentially use 6 as a site prefix to dial San Francisco,
but a separate digit was used here for clarity. There is no requirement
to use the same site prefix between two sites.
Tip
The number of digits required for site prefixes
depends on how many sites with overlapping extensions exist within an
organization. If there are only a few sites with overlapping extensions,
a single digit may be used to identify each site. If there are many
sites with overlapping extensions, it might be necessary to use two or
even three digits as a site prefix.
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.
Tip
If at all possible, consider using a dial plan with
unique extensions across the organization. This might not be possible in
all cases, but will greatly simplify the voice deployment.
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.
Tip
Organizations can include a site prefix in the
telephone URIs. However, the best practice is to use a full
E.164-formatted number.
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.
Note
In reality, Bob will most likely just click contacts
within the Lync contact list to dial each contact. However, the dial
plan normalization rules are still required to handle the
behind-the-scenes routing.
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.
