Lync Enterprise Voice Best Practices - E.164 Formatting

For all the strengths of Lync in the Enterprise Voice department, there doesn't seem to be a lot of practical advice is how to properly design voice routing. Everytime I have to design voice routing for a client, I constantly end up second-guessing myself on the best way to go about it.  Microsoft's assistance in this area has improved since the OCS R2 days, but administrators are still left to their own devices when it comes down to the nitty-gritty details like:

• Internal phone number formatting and normalization
• How to best configure routes and PSTN usages

For the first bullet point, administrators can struggle with questions like "What format should I store numbers in Active Directory?", and "How should I normalize phone numbers inputted by users"


For storing numbers in Active Directory, you should save every number in E.164 format.  E.164 is an internationally recognized standard for phone numbers.  The standard is:

+<CountryCode><City/AreaCode><LocalNumber>;ext=<ext>

The country code is 1-3 digits long, while the city/area code and local number length can vary. The ext= portion is usually only used for companies with internal extensions. Public phone numbers in E.164 format look something like this:

+14162223333 for Toronto, Canada
+60321345678 for Kuala Lumpur, Malaysia

The Canada country code (and also for US and a good portion of the Caribbean) is 1, while Malaysia's country code is 60.  The area code for Toronto is 416 (and 905, 647, 289), while Kuala Lumpur's city code is 3.  Local numbers in Canada are 7 digits long, while KL's are 8 digits long (but are 6 or 7 digits long in other parts of Malaysia).

When inputting phone numbers in Active Directory, you can add separators as you see fit for readability. So, +1 (416) 222-3333 is OK, as is +60.3.2134.5678.

Users with internal extensions, and no direct number (DID) should use the ;ext= component. Start with the central number for the office and add the extension, like +19052223333;ext=555.  Don't store the number as just the extension.

Do not add country-specific routing codes for international calls in your Active Directory, like 011 or 00. These routing codes are not part of the E.164 standard. Also, do not exclude the country code from your numbers using the rationale that all your users are in the same city.

If you don't use E.164, you're likely going to have issues.  One real-world example is a Canadian company that stored their international numbers with 011 at the start (the international routing code for Canada). While it made clicking-to-dial from Communicator/Lync easier, it meant that users from other countries that used different international routing codes couldn't dial the number without throwing an error.

Another North American company had a PSTN carrier that required that local calls not include the long distance code 1. Since all their Enterprise Voice users were located in one city, they felt it was easiest to just not include the 1 in all their Active Directory users phone properties.  Once they expanded Enterprise Voice to other locations in another province, they found that the new users couldn't dial the original users due to the lack of a leading 1 (which is required for long distance calls in North America).

Even if you never plan on expanding to a different city or country, it's important to stick with E.164 formatting. If you federate with another company and publish your phone numbers, its entirely likely they won't be able to click-to-dial if you don't use E.164 phone numbers, simply because the other company can't anticipate whatever internal numbering scheme you came up with.

When you can assume that every incoming phone number will be formatted consistently, its relatively trivial to create trunk translation rules to add any required routing digits such as 011 for international calls, or removing the 1 for local calls before passing the call to the PSTN or next gateway.

"But wait!" you say.  "I have to remove the 1 for local calls and the list of local numbers is way too long to work with. How do I go about getting over that hurdle?" Simple! Use the Lync Dialing Rule Optimizer as discussed in Dialing Rule Optimizer for E.164 Phone Numbers and Least Cost Routing in Lync.

If you don't want to go through the hassle of fixing your internal phone numbers in Active Directory, I suggest using the Company_Phone_Number_Normalization_Rules.txt.  This file is filled with regular expressions that will convert any invalid phone numbers found in Active Directory to properly formatted E.164 numbers during the address book generation phase. You have to create the rules yourself based on your requirements, but there is lots of help out there to get you started (plus there are samples in the Sample_Company_Phone_Number_Normalization_Rules.txt).  You can find it in C:\Program Files\Microsoft Lync Server 2010\Web Components\Address Book Files\Files.  For a good overview of the Company_Phone_Number_Normalization_Rules.txt, see Jeff Schertz's blog entry on the topic.

At pretty much every deployment I ever do, I start with these basic normalization rules in the Company_Phone_Number_Normalization_Rules.txt file, which tends to capture many styles of AD phone numbers:

\+?1(\d{10})+1$1

\+?1(\d{10})\D+(\d+)+1$1;ext=$2

\+?(\d{6,14})+$1 

\+?(\d{6,14})\D+(\d+)+$1;ext=$2

If you stick with E.164 from the start, you will avoid the potential for dialing issues down the road.

My next post will discuss how to handle phone number normalization in Lync.  After that, I'll discuss route building.

For another great post on this topic (relating to OCS, but still very applicable to Lync), see this post on Doug's DTMF blog.