Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

Microsoft Lync Server 2010 : Planning for Voice Deployment - Dial Plan

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
4/28/2013 11:17:31 AM

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.
Other -----------------
- Backup and Restore of Microsoft Lync Server 2010 : Restore Processes
- Monitoring Windows Small Business Server 2011 : Using WSUS Reports
- Monitoring Windows Small Business Server 2011 : Using the Windows SBS 2011 Best Practices Analyzer
- SharePoint 2010 and PowerShell: Real-World Solutions : Automate a SharePoint 2010 Installation
- SharePoint 2010 and PowerShell: Real-World Solutions : Scripted Installation of SharePoint 2010 Using Windows PowerShell
- Microsoft Systems Management Server 2003 : Using the Distribute Software To Collection Wizard
- Microsoft Systems Management Server 2003 : Configuring the Software Distribution Component
- Client Access to Exchange Server 2007 : Getting the Most Out of the Microsoft Outlook Client - Security Enhancements in Outlook 2007
- Client Access to Exchange Server 2007 : Getting the Most Out of the Microsoft Outlook Client - What's New in Outlook 2007
- Windows Server 2008 R2 : High Availability, Live Migration, and Snapshots
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server