PBX Network Topology
http://blog.ucomsgeek.com/2014/02/pbx-replacement-series-pbx-network.html
Analogs
http://blog.ucomsgeek.com/2014/02/pbx-replacement-series-analogs.html
Toll Fraud
http://blog.ucomsgeek.com/2014/02/pbx-replacement-series-toll-fraud.html
Overview
In my next installment, I would like to dive in to PBX Dial Plans. Chances are there is very little PBX documentation or you might also hear my favorite... "The PBX is the documentation".
There is also an even smaller chance that if there is PBX documentation, it won't be the dial plan. Why? Because it is a pain to really track and do a dial plan well. If you have a seasoned PBX Administrator on staff give them a big hug and buy them a nice steak dinner right now, because they are your single biggest asset to understanding how things are laid out.
On a side note... many PBX Administrators are really scared of Lync right now. They think because Microsoft is replacing their PBX, they will get replaced too by the "server administrators". That is the farthest thing from the truth. Sure the server administrators will probably take a greater role in managing the communications environment, but they won't get "Voice" like a seasoned PBX Administrator. Most of the knowledge these professionals have can't be learned easily anymore. They also have years and possibly decades of experience of how not to do things that might be specific to the business environment you are working in. What you should encourage them to do is embrace learning a new skill set that will make them even more valuable because not only do they have critical knowledge about telecommunications, but they will also learn new Server and Applications skills (which is easier for them to do than for a server administrator to learn telecommunications). Those two together are really powerful, throw in some data communications and QoS and you get what I call a true Converged Engineer.
Meanwhile... back at the ranch, let's dig in to PBX Dial Plans...
PBX Dial Plan
First off, I want to go in to the two different types of PBX dial plans. They are Coordinated and Uniform (Nortel speak). Haven't heard those terms before? Doesn't surprise me. I never heard those terms until I started at Nortel even though I was a network manager at a university and had voice for the university under my domain. There is also a good chance that depending on the PBX vendor the terms might be defined differently or have different names (which can be confusing... I know). No worries, I plan to describe them in detail so hopefully we will all get on the same page regardless of what each of us calls them.
Coordinated
In a coordinated dial plan each extension in the PBX network is unique and all the same number of digits. Each person can dial each other directly using just the digits of the extension regardless of where they are.
Typically you will see ranges of numbers dedicated to a site. For instance, all the Denver numbers start with 45XX and all the Dallas numbers start with 46XX. The range is totally arbitrary and can really be any range.
A well managed Coordinated dial plan will usually break ranges in to 10s, 100s, 1000s... 10000s you get the idea. An example of a badly managed dial plan would have Denver range be 4523 through 4547 and the Dallas range be 4548 through 4581. Although it is certainly valid, these are harder to handle in routing tables in the PBX (and harder in Lync too).
If you are in the rare situation where you are developing your own dial plan, you will want to pick ranges that allow for future growth. There isn't any hard set rule on what you should do. So most people go with their gut... or base it on some knowledge they have about the business and how much they grow.
DIDs in a coordinated dial plan usually start out by matching the last few digits of the DID number. For example 3035554500 would correspond to an extension 4500. When you have 4 or 5 digits for an extension, you will find that assigning all 4 or 5 digits to an extension can chew through a dial plan number availability quickly. One way PBX Administrators handle this potential overlap is even though your carrier may send you 4500 the users DID (3035554500) they map to an extension that is really 3500. These nuances are really important to understand and have documented. When you start to write normalization rules, knowing details like this up front will save you a lot of effort. Also, keep a watchful eye for situations where the DID does not line up with an extension in some sort of pattern. You'll need to write one off normalization rules to handle these properly and you should also see if the customer can clean these up in any way (might be a multi year process).
As you might have surmised above... the biggest challenge with Coordinated Dial Plans is that they run out of digits once you go past a few sites. Depending on the number of users, you might start to feel pain around the 10 site mark. If you start to run out of room there isn't really any easy way out. You will feel pain. My suggestion these days is to move to an E.164 dial plan (along the lines of Uniform below) where users calling another site have to dial 10 digits. Within a site can still be their short extension. If you move to an E.164 dial plan there is no chance or conflict (this goes for International dial plans as well)
Uniform
In a Uniform dial plan, each site has access to the entire range of numbers, but when dialing another site, it requires a site code or prefix to identify where you are calling. In the example of Denver calling Dallas you might have a site code of 20 in front of the extension so the user would dial 204623 to reach a user and vice versa Dallas calling Denver would dial 214512 as an example. A Denver user calling another Denver user would just call the 4 digits, but certainly could call the site code too if they wanted.
Now usually with this type of dial plan you also have an Access code associated with internal site to site dialing. Think of it as like dialing a 9 before a PSTN number. At Nortel, we used to use a 6. So in the example above the Dallas user would dial a 6+21+4512 to reach the user in Denver.
Site codes don't have to be just 1 or two digits. Typically for really large PBX networks you might see more. Nortel used a 3 digit site code with 4 digit extensions. They were a truly global company with over 100,000 people at one point just to give you some perspective.
Why do we care about PBX Dial Plans?
Simple... we want to replicate the voice dialing user experience in Lync.
Normalization Rules
One primary way your users will complain is if they have to learn a new way to dial Bob in Accounting. To keep this from happening, an understanding of how the users dial numbers today is needed, so you can replicate that with Normalization rules in Lync. Need help with Normalization rules? See one of my first blog posts for some help.
So I'm going to assume you have great documentation at this point. If not, you better get cracking and better hope this deployment isn't due to be done this week. If you are having to create documentation chances are you won't get everything. In this case you need to consider using a generic normalization rules that will catch all the extensions you don't know about. To do this normalize using the HQ main office number +13035551000;ext=XXXX. When you configure your Trunk Configuration to strip out what you don't need, you'll just grab the extension and pass to the PBX and the call will complete.
As you are going through your documentation look for things that aren't consistent. If it doesn't look right, or stands out... ask questions. Usually there is something more sinister going on. Worst case scenario would be a dial plan that has different number of digits depending on what site they call. If you run in to one of these... stop the presses (hopefully SOW isn't signed yet) and tell the customer that they need to make everything consistent across the board. Proceeding will only mean pain for everyone. If you proceed, you will be in an endless loop of workarounds that at some point will become unmanageable.
When you are putting together normalization rules, you should at least be looking for information to complete the following:
- 911 with and without Access Code
- Special formatted numbers (Paging, Hunt Groups, Emergency Notification etc)
- Dial Receptionist for each site (Company Operator)
- Extension (for example 4-Digit)
- 10-Digit for Internal DIDs
- PSTN Local 7-Digit with and without Access Code (if needed)
- PSTN Long Distance with and without Access Code
- PSTN International with and without Access Code
Also, when you start out developing your dial plan in Lync, ask yourself at least one critical question. Will I need to handle Non-DID extensions? Those are the extensions that a user can call internally that have no dedicated PSTN number. They can only be reached from an internal phone, or by transferring from an internal phone. For Non-DID dial plans you have no choice but to use the +1XXXXXXXXXX;ext=XXXX format when assigning numbers to users or endpoints. I would use the format anyway for other reasons like Pin auth and Dial in conferencing authentication, but regardless Non-DID REQUIRES you use this format.
Since I am a fan of +1XXXXXXXXXX;ext=XXXX, even in environments that all have DIDs, you should always write User Dial Plan rules for extension dialing to normalize to this format, but also 10-Digit versions of Internal DIDs that specifically normalize to the +1XXXXXXXXXX;ext=XXXX format. I know... I know... Microsoft will match the first part... but I've been working with this stuff long enough that I don't trust that to work 100% of the time. I follow this rule religiously, and it creates a lot of extra work, but my deployments have a great track record. Also, don't forget to make sure you Normalize the Lync Address Book in the same way.
Now, if you have a Uniform dial plan you will want to include the site code after the ;ext= when you assign numbers to endpoints or normalize (+1XXXXXXXXXX;ext=21XXXX). Why? mainly to make Caller ID to the PBX easier. Wasn't what you expected was it? I am a fan of doing all Number manipulation on Lync. This includes having separate Trunks in Lync for PBX routes so I can strip down the Caller ID to match the user experience on the PBX. Don't do this and you'll be writing a ton of rules in the Trunk Configuration. Don't do it Trunk Configuration? Then when the user goes to dial the person back the call won't complete because they won't know the site code. Get it? Got it? Good!
Routing
More than likely you will have more than one place you are connecting to the PBX network through. Because of this you will want to know what numbers in the dial plan go where. If the PBX Network is Hub and Spoke there are finite resources available and not sending the calls to the closest PBX to its destination could cause congestion.
This is also important if you are doing any routing for analog devices that are connected to the Gateway.
Unassigned Number Handling
At first when you are doing co-existence you will not want to have Unassigned Numbers in Lync. But as you eliminate each PBX you will want to add Unassigned Numbers to Lync. This will prevent routing loops in your PRI Gateway's and SBCs. Unfortunately you can't do ranges of DIDs with the ;ext= format. You can only do straight E.164 numbers or numbers with ;ext= and the first part of the number being the same +13035551000;ext=1000 through +13035551000;ext=2000. No Bueno.
This will mean that your call will route out to the PSTN and back in before it gets unassigned number handling. Not optimal, but configuring the rest of Lync to work around this one issue causes more problems in my opinion.
So what this looks like is your User Dial Plan rule will normalize to +1XXXXXXXXXX;ext=XXXX not find a match for user, endpoint or unassigned number and route out through a PSTN Trunk. That call will then come back in on another channel and your PSTNGateway Dial Plan should normalize that incoming PSTN number to E.164 in the following format +1XXXXXXXXXX and then try to match a user or endpoint. When there is not user or endpoint found it will stop at your unassigned number handling.
911 Emergency
I know the normalization rules for 911 are fairly trivial to write, but what you need to find out in your dial plan is if each site, or floor, or zone has a specific number that needs to be passed to 911 operators. You can handle this a couple different ways. Either doing a Location Policy or handling with Voice Policies and Routes (with a Caller ID override).
If the PBX is actually doing true E-911 then you might need to consider using the E-911 function in Lync or using a similar E-911 or ELIN capability in the Gateway.
Paging
Within the dial plan you will also want to identify any paging within the PBX environment. Sometimes these are feature keys on the phone, but other times, they might actually dial something the resembles an extension. If it is a feature key, then you will need to develop a plan on how to handle Paging (usually analog FXS/FXO gateway connected to Paging system with Analog port). If it is extension based paging you have more detective work to do. You will need to identify how the paging system is connected and can you use a similar method with Lync or does the whole paging system need to be swapped out.
The above items are the critical pieces that get forgotten about when the talking heads go on about PBX replacement. PBX replacement is not easy and you need to always be prepared for that surprise that no one thought about.
No comments:
Post a Comment