Check out the most comprehensive, actively managed Lync blog roll in the known universe, your one-stop source for links to over 100 of the very best Lync blogs. Here you will also find weekly blog highlights and a feed for a dozen of the top blogs.
Lync Server Support Home
Top Lync Solutions RSS Feed
Microsoft Senior Support engineers walk you through real-life support cases, giving you an insider’s view into the systematic approach they use to troubleshoot Lync Server issues.
These short videos focus on specific tasks and show you how to accomplish them for Microsoft Lync Server 2010.
To provide the best user experience and prepare for future growth, it is important to use the correct numbering format when assigning phone numbers to users. This article describes how to effectively assign phone numbers to Lync Server 2010 Enterprise Voice users.
Author: Thomas Binder and Doug Lawty
Publication date: November 30, 2011
Product version: Lync Server 2010
When rolling out Enterprise Voice in your organization, use the following best practice recommendations to define your numbering plan and to assign telephone numbers to Enterprise Voice users. Defining the correct numbering plan is a crucial factor in the success of your Enterprise Voice deployment. To provide the best user experience, allow room for future growth opportunities, such as expansion to other countries or merger and acquisitions (M&A).
Design your phone number plan for Lync to take into consideration the following objectives:
Let’s consider each of these objectives in more detail and provide recommendations for assigning phone numbers in different situations.
Lync Server 2010 follows RFC 3966. RFC 3966 prescribes the format of TEL URIs in SIP. The RFC also defines additional parameters – such as extension, phone context, and so forth – to add to the TEL URI. Phone numbers can be either local or global. Global phone numbers must start with a + sign followed by digits that represent an E.164 number. E.164 is the standard for PSTN numbers and specifies country codes. Local numbers – those that are not globally unique – must provide the context in which they are unique. To specify this context, the phone-context parameter is added to the TEL URI. The combination of the phone number and phone context creates a number unique.
The following are valid RFC 3966 TEL URI examples:
All these formats comply with RFC 3966. It is not recommended, however, to assign all formats to users. A phone number is assigned to a Lync user when the Line URI property of the user’s Active Directory account is populated with a string similar to the listed examples. The following sections explain the recommended number format for each Line URI.
When a private number format (such as tel:135), is used in Lync and an employee places outbound calls, the correct caller ID is not displayed. When a Lync user makes an outbound call, we want the called party to see a valid number so she can return the call. When the user does not have a public telephone number, we want to display the company’s receptionist or auto attendant caller ID, so that the called party can return the call. To accomplish this, we have the following options:
Note. Lync Server also provides the ability to suppress the caller’s ID by replacing it with another number (for more information read Voice Routes in the Technical Library).
As a best practice make sure to always provide a caller ID that can be called back when calling outside the enterprise. Specify a Line URI that contains a DID number.
Phone number extensions are used in multiple ways in Lync. If you dial in to a conference and you want to join as an authenticated user, you must provide your extension and PIN. Also if you want to authenticate with your PIN on a Lync qualified phone, your extension and PIN numbers are required. For more information read Device Connection Process in the Technical Library. Users without an extension receive a warning message on the dial-in conferencing page (see Figure 1). This may lead to support calls.
Figure 1. A warning is displayed for users that do not have an extension configured
The user experience is improved when users can authenticate with a short extension instead of a 10-digit phone number. If a user does not have an extension configured, instead of requiring the user to enter their full phone number, Lync attempts to normalize the entered digits to the full E.164 phone number. If it finds a matching normalization rule to map the entered digits into a valid internal phone number, Lync Server is able to authenticate the user. However, the more complex the deployment the more likely it is that this approach will not work. For example, if users are travelling and dial in to conference numbers in other countries with different normalization rules, their extension may not be recognized.
Best practice is to always assign extensions to all users using one of the formats with the ext parameter.
Phone numbers within a PBX deployment must be unique. In an enterprise with multiple PBXs deployed, it is possible that some of these local numbers may overlap. If a user, whose PBX phone is hosted on one PBX, calls another internal user whose PBX phone is hosted on a PBX with an overlapping number range, the caller needs to use a prefix to differentiate the call and dial out to the other PBX.
By contrast Lync relies on Active Directory services to provide a companywide directory service. Using local extensions or regional number formats in one of the telephone number fields of a global directory does not work. Users from one location are not able to call users in a different location using their local phone number.
As a best practice, populate Active Directory with phone numbers that are globally unique.
A deployment may begin with a single integrated PBX or gateway. Superficially, it makes sense to build a Lync dial plan that accommodates the dial plan of the PBX. This works when all your users are in a single region. It may also work if you use local extensions in Lync.
However, building a plan based on a local extension limits future growth. When you integrate additional locations, a numbering plan based on a local extension no longer works. This occurs because the expanded deployment is not local to only one location. When you federate with other companies or when you deploy SIP Trunking be sure that all numbers provided are globally unique and routable.
Even when you start with a limited scenario, plan for future growth. Always use globally unique numbers.
There are a number of different configurations that may initially seem like a good idea due to their simplicity. Later they may turn out to be poor decisions that block future growth.
Common mistakes include, but are not limited, to the following:
This can lead to the following problems in the following situations:
Using global numbers simplifies your Lync Server dial plan more than is possible with a typical PBX deployment. One could say this is another reason why Lync isn’t an IP-PBX. It’s not a private branch exchange. It’s an enterprise-wide Unified Communications system.
After defining the goals and best practices for assigning a user’s phone number in the enterprise, the following summarizes how to configure phone numbers for users with DIDs and for those with only internal extensions.
Configuring Users with DIDs
For users with a DID phone number, specify the global number and the extension in the user’s Line URI. After deciding how many digits to use for the extension, append the last number of digits from the user’s DID to the Line URI with the extension parameter. As an example, if the PSTN phone number for a user is +12125550135, specify the Line URI as, tel:+12125550135;ext=135, assuming a 3 digit extension.
Configuring Users with Internal Extensions
For users with private extensions that can only be dialed from within the organization, you must specify the call back phone number displayed as the caller ID and append the user’s extension. For example the Line URI of tel:+12125550100;ext=863 presents as caller ID the number of an auto attendant (+12125550100) while 863 represents the extension of the user.
Note. When you use this format, no other phone number in your Lync deployment can be assigned the number, +12125550100, without an extension. You must configure the auto attendant with an extension (for example tel:+12125551000;ext=0), and create a normalization rule to normalize incoming call for +12125550100 to tel:+12125551000;ext=0. This can be accomplished by creating a pool level dial plan for the gateway receiving the inbound call.
RFC 3966 is flexible in terms of defining phone numbers. It is recommended to use the ext format for all users – those with DIDs and those with private numbers. This provides users with the best PIN authentication experience and always provides a valid caller ID for outbound calls.
Using an E.164 global number in the Line URI at the initial deployment, provides the most flexibility for future growth of your Lync Server environment – whether you deploy additional PSTN gateways in the same or new locations, introduce SIP Trunking, or expand to new locations.
Keywords: Lync, Enterprise Voice, phone number plan, E.164, extensions, Line URI