Assigning Telephone Numbers to Lync Enterprise Voice Users
Published May 20 2019 04:17 PM 2,561 Views
Occasional Visitor
First published on TECHNET on Nov 30, 2011

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).

Telephone Numbering Goals

Design your phone number plan for Lync to take into consideration the following objectives:

  • Compliance with Internet Engineering Task Force (IETF) standards.

  • Specify a valid caller ID. This enables a callee to quickly return a missed call.

  • Define phone numbers with extensions.

  • Leverage telephone numbers configured in Active Directory.

  • Plan for future growth.

  • Avoid common mistakes.

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:

  • tel:+12125550135.

  • tel:+12125550135;ext=135 where the extension is part of the phone number.

  • tel:+12125550100;ext=863 where the extension is not part of the phone number.

  • tel:135;phone-context=HQ.

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.

Specify valid caller ID

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:

  • Direct inward dialing (DID) – sometimes called direct dial-in (DDI) – these numbers are globally unique phone numbers that can be called directly from the PSTN. If the user has a DID assigned, it will be presented as the caller ID for all outgoing calls and no additional configuration is necessary. Use one of the formats where the user’s DID is specified as a global number – for example tel:+12125550135 or tel:+12125550135;ext=135 . (The next section encourages the use of the second format.)

  • If a user does not have a DID number and can only be reached through an internal extension, configure a DID number as the caller ID so that the callee can return the call. Usually, this number is the company’s receptionist or auto attendant number. Use the format where the call back number is specified as a global number and the user’s internal extension is added – for example tel:+12125550100;ext=863 .

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.

Define Phone Numbers with an Extension

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.

Leverage Telephone Numbers Configured in Active Directory

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.

Allow for growth

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.

Avoid Common Mistakes

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:

  • Do not include an outside line access code as part of the phone number.
    In a U.S. based company users often have to dial a 9 as the common outside line code, some administrators mistakenly configure phone numbers to be normalized to +912125550135 , instead of the actual E.164 number, +12125550135 .

  • Do not treat private extensions as global numbers.
    When the company does not use DIDs, some administrators mistakenly decide to populate the Line URI with the extension and prefixes a plus, for example +863 instead of the correct +12125550100;ext=863 .

  • Failure to include the country code.
    Since the company is only active in a single country some administrators mistakenly decide not to include the country code in the phone numbers, for example +2125550135 instead of +12125550135 .

This can lead to the following problems in the following situations:

  • People cannot dial E.164 numbers using Outlook contacts or through the Lync Browser Helper if normalization rules only allow for your dial plan.

  • Federated partners receive the phone number through the Lync contact card but are not able to call the number, because their configuration correctly expects E.164 numbers.

    • Because +91 is the international dialing code for India, +912125550135 is routed to India.

    • Because +86 is the international dialing code for China, +863 is routed to China.

    • Because +212 is the international dialing code for Morocco, +2125550135 is routed to Morocco.

  • The company expands to international locations, which requires it to change all existing locally defined phone numbers to globally unique numbers.

  • The company wants to integrate SIP Trunking. Because most SIP Trunk providers do not support private numbers, you need to use globally unique numbers.

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.

Lync Server Resources

We Want to Hear from You

Keywords : Lync, Enterprise Voice, phone number plan, E.164, extensions, Line URI

Version history
Last update:
‎May 20 2019 04:17 PM
Updated by: