Lync: Local and Site-to-Site Dial Plan GUI Script

In a multiple, or even single, site VOIP deployment there are some  steps you can take to make life a whole lot easier on your end users. One of of the common features implemented across phone deployments (VoIP or otherwise) is site local and site-to-site dialing shortcuts. These shortcuts generally reduce the number of digits users have to dial to reach one another. In this post I’ll go over how you might setup such a dial plan in Lync. First I’ll go over how you might setup such a plan manually then I’ll provide a GUI tool to do the same thing.

The Basics

Dial Plans – Without going into Lync voice routing details already thoroughly covered elsewhere you need to already understand the following:

1. Dial plans do serve a few other purposes but for the sake of this discussion A dial plan processes phone numbers you enter and optionally transforms them into other numbers.
2. Dial plans can be assigned to scopes for user, Lync pool, Lync site, and global (the default).
3. The Lync site scope is not AD sites and services but rather sites defined within the Lync topology. This is mostly important to understand in the context of this conversation as I’ve seen few cases where you can assign dial plans by this scope. This leaves you back to the next best scope when assigning dial plans, user.

You can learn all about dial plans from the source: http://technet.microsoft.com/en-us/library/gg413082.aspx

Prefix – Throughout this discussion I refer to ‘prefix’ as any numbers that come before the local site DID 3 or 4 (or any digit length) dial plan. So if a site is using local 4 digit dialing in the US the prefix in the following DID is the underlined section.

Local Extension – The left over digits after you have stripped away a common prefix will be the local extension. This tends to be between 4 to 6 digits.

Global Extension – If you put the site code together with the local extension you get the global extension. This is a personal preference for me but it tends to work out well in deployments to assign DIDs with extensions in the following fully E.164 formatted URI:

The Site Local Dial Plan

A site local dial plan (again, typically scoped at the user level) purpose is to make local calls between your users easier. In a non-Lync old-school world of handsets and old PBXes it is a great feature. Typically a site local plan takes the form of a 3 or 4 digit dial plan. Most PBX systems readily support this scenario and your heavy phone users tend to think it is the cat’s meow.

If you know how to use your Lync enabled devices or simply use the Lync client remembering extensions becomes less important. When you are migrating the main office phone system to Lync that you really shouldn’t have to remember extensions and codes to reach office staff anymore. But that means little to the personal assistant to the President of the company who is used to reaching others with a few digits now does it? Also, shorter numbers can make a printed local site directory listing more contrite I suppose.

The Intersite Dial Plan

The ability to quickly reach people in the same site via shortened numbers is usually extended slightly for calls between sites. So a local 4 digit dial plan may turn into a 6 digit plan when attempting to reach other sites. That 6 digits would consist of a 2 digit site code and the 4 digits of a user’s DID. Having site codes makes it a bit easier to dial out to other sites and seems snazzy to end users too. Likely there is already some kind of intersite dialing codes in place that would be cool to be able to keep when upgrading the phone system (also anything the ‘old’ system could do that the ‘new’ system cannot becomes ammunition for complaints).

Making The Dial Plans

To create site local dial plan rules you need to know some items up front, most importantly your phone number ranges and your site codes. It is important to bring up site codes which will be used for intersite dialing very early on. The site codes to use may not be as obvious as you’d think. Some companies have per site expense codes which are used or other internally important numbers that make sense to use.

The issue with creating either a 4 or 6 digit dialing plan a deployment is that DID ranges are very infrequently a cut and dry list. I’ve run into some DID allocations in metro areas which span several dozens of partial ranges or even more than one possible prefix. I’ve come up with some example data to illustrate this kind of DID allocation. This is the same example data that is included with the utility I’ve created and covers two sites with multiple DID ranges (all wildly fictitious of course).

Chicago’s prefixes: 1222333 and 1222444

New York’s prefixes: 1555444 and 1555445

Issue 1: Crazy Regular Expressions

Say you do have all of your ranges laid out and are ready to create your 4 digit dialing. If you have some basic ranges or all your extensions are internal only then things are pretty easy to normalize. But if you have a heavily fragmented DID list you should not simply cater to the lowest common denominator. Lets take a peek at an example:

This is pretty easy to read:

Note: Before I found RegexNumRangeTool I’d create these kind of regular expressions by hand. RegexNumRangeTool is still a great tool for the one off number range you need to match in a regular expression. It has one downfall in that it will automatically strip out leading zeros from results. This is bad for DID ranges but you can precede your ranges with an arbitrary number and then strip it from the results to get around it. I actually use the base code from this project in the utility I created (mostly unchanged!).

That prior example is just for one easy range. Here is a slightly modified range and its resulting regular expression.

Quite a difference! Now if you had both ranges you had to account for you’d have to concatenate the regular expression to include both match possibilities:

So why wouldn’t you just use something simpler like this?

If you include all 4 digit results then there is a chance you will be including non organizational numbers in your results. If you only have one prefix to transform the 4 digits with then this isn’t actually so bad (especially if the local office favorite take out joint is caught in the range I suppose, 4 digit fast dialing for delivery!). I’ve actually included an option in my utility to use these simplified transforms when possible.

The problem with this approach becomes more apparent when you have multiple prefixes to deal with at the same site. Using the same example ranges as above lets change the prefixs and see what happens:

The first regular expression and transform do not change. But the second transform does change to the new prefix.

Because of this we cannot combine the regular expression. And if we use a generic 4 digit matching regex with one of the ranges as the transform you end up with 4 digit dialing that can never utilize the second range. This is what is known as an ambiguous result.

Issue 2: Overlapping Ranges

If you look closely at the example ranges I’ve provided with the utility I’ve created what you end up having at Chicago is two ranges with different prefixes which have overlaps in their last 4 digit ranges. In these instances there is no one regular expression which will be able to resolve the 4 digits (5950 – 6000) to both prefixes.

If you want to do 4 digit dialing then you need to recognize that one or the other DID ranges simply should not be expected to work as a destination for local 4 digit or remote 6 digit dialing. The DIDs can still be used (perhaps for faxing or conference rooms or other purposes) but we will simply not be including them as a transformation in our dialing rules.

As can be expected, the smaller digit you want to use for local digit dialing the more likely you will have these kinds of overlaps. If you start playing around with the utility I’ve created you will see it even prevents digit counts which will result in overlapping beginning and ending DID prefixes in a single range. If you are going to go to the lower numbers for local digit dialing then you will need to split out your range entries accordingly.

Some Reservations

It should be noted that it isn’t wise to automatically setup local and intersite dialing for every environment for a number of reasons. There are a few things to consider when doing this:

It is more administrative overhead when setting up new users as you will likely need to setup per user dial plans for the accounts as well when enabling them for Lync.

It can result in some pretty large regular expressions which means extra processing just to dial numbers. This usually doesn’t affect Lync clients on the desktop but it may affect physical phones if they are set to download and use Lync dial plans (something which you can do on the VVX series Polycom phones for instance).

Intersite dial plan normalizations do not really scale to very large deployments. In these cases it is not unheard of to use special routing codes in only some sites. The utility I’ve created can facilitate the creation of the correct normalization rules but was not meant to be used in these complex scenarios.

The Utility

Release Information

01/08/2015 – Initial Release

Description

This script is meant to ease the process of creating and deploying site local and intersite dial plans within Lync. The general idea is to enter in all the local site DID ranges with local site codes. Then, based on a digit count, create both the normalization rules needed for local dialing and for intersite dialing. Optionally you can also create generic unassigned number ranges.

Example DID range data has been included which can be loaded for an initial test run. This data includes a few sites in the following format:

Chicago

1. Local 4 Digit dialing
2. New York 6 digit dialing (20 + ####)

New York

1. Local 4 digit dialing
2. Chicago 6 digit dialing (10 + ####)

Global

1. New York 6 digit dialing (20 + ####)
2. Chicago 6 digit dialing (10 + ####)

The example data purposefully includes some overlaps that might cause ambiguous results thus generating some exceptions for the exceptions list.

Notes

Here are some important things to be aware of regarding this utility. It would behoove you to read through these:

• The exceptions are chosen a bit arbitrarily. For any duplicate found between effective DID ranges (based on the site local digits defined) there will always be a duplicate found in at least two ranges. One of these will be marked for the exceptions list, the other will be processed for possible transformation. A carefully input set of ranges can be used to manipulate which ranges are chosen.
• Duplicate ranges can cause ambiguous transforms to occur so this utility attempts to isolate them and notify you to make exceptions in your DID assignments.
• You can right-click and copy the contents of or clear any table in the form.
• Ranges which are added that are exact duplicates will be ignored in processing.
• The script output is meant to be a guideline and should be reviewed before running. What the script attempts to do is:

• This utility is not at all meant to be a replacement for the most excellent Lync Dialing Rule Optimizer by Ken Lasko. It should compliment it though. I’m actually going to say that if you don’t really understand Lync dial plans that you probably should refrain from using this or Ken’s tool until you do (I’ve inherited a few too many environments with wildly inappropriate or incorrect voice routing due to inexperienced engineers blindly running the optimizer’s results without truly understanding what they were inputting).
• I’ve included an option for simplified normalization rules. If selected simplified rules will only get created for sites where there is a uniform prefix (no ambiguities).
• The exceptions are listed with the original DID ranges but with the starting and ending digit columns updated to show the overlapped ranges (see screenshot).

Screenshot

Here is an obligilitory screen shot of the utility I put together to help automate some of this process for you. The highlighted exception item is to show the last note listed in the notes.

Output

Here is what the script output from the example input might look like:

Download

Get the script and example data set from either the Microsoft technet gallery or my github repository.