Lync Normalization; Why, where and how?

I’ve seen some confusion on the why’s and how’s on Lync normalization. And felt like sharing my thoughts on the topic.
First of all; I am not referring to the “normalization of the address book”. This process is an important part of the entire picture, but others have covered that topic far and wide. No, I will focus on the Normalization for dialing habits and routes.

Let’s take a look at the whole “Normalization” idea: Any number entering the system (dialed by a user or as an incoming call from a trunk) should be normalized to a globally unique E.164 number. This is a really good idea several vendors have embraced (more or less).

With normalization, you will never ever have to worry about overlapping number plans. In older PBX implementations extensions had 3-6 digits as their extensions, and migrating and managing many sites could often be quite a task. Never again!
Another great benefit or normalization is how easy least cost routing and pstn rerouting just got. As all numbers are formatted the same way, users don’t have to think for one second where the call will exit. We do the trick for them. And if the least cost gateway is down? We just send it out a different gateway in a different state, or in a different country if the call is that important to us. There we do a last second translation on the trunk, to match whatever format the provider expects.
A final reason for normalizing might be to make a transition from a traditional PBX to the “IPT world” easier. Let’s recognize the simple trait of human nature. Even if we now want the users to search other users in the address book and just click to call, old habits die hard. Some user will insist on dialing the old fashion way of entering 3-5 digits for a local call. After all, Microsoft re-introduced the dial-pad into Lync for a reason.
(Note; If you’ve been working with Cisco and CUCM products, Localization is known as “Globalization”. Same idea, same process, different label)

Haven taken care of some of the why; let’s move on to the where/how:
All normalization rules can be created in the Lync Control panel in the “Voice Routing” section, or with PowerShell. I’ll show a few screen shots here, but if you’re interested in PowerShell; Here’s the link for you: http://technet.microsoft.com/en-us/library/gg415662.aspx

In order to begin, you need to know about dial-plans. Everybody needs a Dial-plan. The Dial-plan contain a collection Normalization rules which apply to the user. There is always at least one “Global” dial-plan for everyone, but there could be plenty more. If all users dial the same way, and all your gateways receive numbers in the same format, all you need is the Global plan. But if users will have to dial differently (due to restrictions or habits, doesn’t matter), you might consider splitting up your plans. All plans in a user’s path will possibly match, so select your priorities carefully. In addition to the Global plan, you can create a plan according to pool, site (a site can have several pools) or user.
The “pool” policy is where you will find you pstn entities to normalize incoming pstn calls differently from the global ones.

Here is a really simple Normalization I have created for users in the Norwegian office:


Explanation; As of old, we expect all users who use the dial-pad and not click on a contact, to stick with their old habits and press “0” for an outside dial-tone (No dial tone is provided, of course, but the habit remains). What this rule is doing, is catching everything beginning with a “0”, followed by at least 3 digits (This rule will not catch emergency calls of 11X). It will remove the “0” and add the Norwegian country code of +47 to the beginning (Thus creating a true E.164 number, ready to send out to the pstn). How each gateway or trunk handle or manipulate this further is something I’ll touch on a bit later. But for now, let’s pretend I dialed 012345678. This will now be normalized to +4712345678 (as seen in the screen shot).

I also want you to pay attention to the “Internal extension” tick box on the normalization page:


This is what you select if this normalization should result in an extension within your organization (used for optimizing calls internally). You would create such a normalization rule to handle dialing internally, with only a few digits. Maybe users are used to dial a 9 followed by 4 last digits of a number to reach users in a different site. You would create a rule matching a similar pattern: ^9(\d{4})$. Drop the 9, and add (translate) whatever should be added.
Again; A user dials 95678. You drop the 9 and add +471234 (+471234$1 would be the correct syntax). “What’s the deal with that, why the trouble” you might think. But here’s the deal. If this site happened to have a wan outage at the moment, but did have a separate pstn gateway. The normalization just prepared you for an alternate route implementation. Just ship the call out your local gateway and the call will go through. Simple as that! You only have to allow it in your policies and route setup. (Sorry, not covered in this post). Users won’t know the difference.

By now, I hope you both know why to normalize, and how to do it.
If you, like me have a direct sip-trunk to a provider, this might actually be all you need to know. As your sip-trunk provider hopefully abides by the E.164 standards and will gladly accept only this format. If all sites and trunks are set up this way, all you have to do to control the flow of your calls is to create specific routes and pstn usages. No matter where the call eventually goes out. It is properly formatted. If not, you have to create translation rules on the outgoing trunk.

This wasn’t supposed to be a complete “Enterprise Voice” how to post. But I felt like giving you an example of the setup described if your pstn access does not support the E.164 format.

I’ll give you two different patterns to compare. But first my imaginary setup: A company with two sites. One site in Norway, and one site somewhere in the U.S.
Both sites have a local PSTN access, and we try as often as possible to use a least cost route for calls. And for some important users, we make sure the calls go out for any call (we don’t care about the cost of the call. Not making the call is a potential lost deal).

Here is what I “know” about my users, and the pstn access in the two countries:
Norway -

• Users dial 0 for an outgoing call
• PSTN expects 8 digit numbers for all Norwegian calls (not taking care of service numbers and such in this example)
• PSTN expects 00 for an international call
• 47 is the country code for Norway.

U.S. -

• Users dial 9 for an outgoing call
• PSTN expects 10 digits for a local call, within the state (I believe some states only require 7 digits, but I am keeping It “simple” here)
• PSTN expects 1+10 digits for all long distance calls within North America
• PSTN expects 011 as an international call
• 1 is the country code for North America

If a user in Norway wants to reach a Norwegian number: “12345678”, he or she would dial “012345678”. We would then normalize this to +4712345678.
When the call goes out the Norwegian GW, we would translate +4712345678 back to 12345678 and send the call out. If, for some reason, the pstn GW was out of service. And this call was so important we wanted to send it out as an international call from U.S., we’re almost there already. AS long as the Voice route sees the U.S. GW as a possible path, it would try to send the call out through that GW. All we have to do would be to create a translation rule at the trunk, translating +4712345678 to 0114712345678.

When we create a normalization rule for U.S.’s international calls (“90114712345678 to +4712345678”) by stripping access codes and adding the “+”. We would already have the translation rules in place to send the call out, either way.

It would work just as well the other way around, as well. After creating normalization and translations for local and long distance calls in the US, they would all be normalized to +1SOMETHING. Translations on the GW would recognize local ranges and strip off the +1, and for Long distance calls it would only strip the +.

If a call then, to the US, could not go out in U.S., but would be sent out in Norway. We would have to create a translation rule where we removed the +, and added 00 for international calls. Plain and simple.

As a summary: Normalize on the way “in” to the system, translate to the expected output on the way out (Sometimes referred to as localization).