Planning a large OCS deployment with multiple pools can be tricky. Planning your dial plan can also be something of a challenge especially if your new to the world of voice and have come from a server or data background. I am not going to go through the basics but look more at future proofing a large dial plan so that adding more routes and complexity further down the track can be simplified.
Let’s start with location profiles and normalizations rules. One of the big things I have committed to with the OCS deployment I am working on, is change is for the better and things like abbreviated and regionalized dialing are things of the past with click to dial (that’s the line I take anyway). With a large voice deployment (100,000+ endpoints no matter what they are) standardization is key to simplifying configuration and keeping your TCO down. Standardizing on a ten-digit NANP dial plan inbound and outbound was key on keeping the dial plan simple in a multi region, multi PBX environment. No more abbreviated dialing per geographical region and no more access codes to get an outside line. This worked well with the idea of centralizing our deployment and keeping OCS in our datacenters. With OCS, not requiring tie trunks between pools like a typical PBX makes the job a whole lot simpler as well. See Location Profile example below (save image and enlarge to get a better look):
As you can see its pretty basic and with that in mind now we can limit our UM dial plans as well and in a centralized model it’s going to work well. Of course this isn’t the approach most voice people will take. Looking at traditional PBX model’s most old voice guys are going to stick their nose up at no abbreviated dialing for a user. Well all I can say is if you know the persons number by heart their more than likely in your buddy list anyway and you can just click to dial.
The exception to this would be special services should you require them and in a large enterprise dial 0 for operator is a pretty common one. This of course would be a simple add and better yet normalizing the 0 to a ten digit NANP to go to a local operator number even better for outbound dialing. Of course, simplicity is not for everyone and the more localized your special services the more likely you are going to need more location profiles. No one wants to dial security *77659(example only) in St Louis and talk with the security people in Redmond. So it’s something to be aware of.
If you have not already noticed 011 for international is still there. Some habits just die hard I guess. Just to reiterate the simpler you keep your dial plan the simpler it will be to do things like add new sites and pools. Making a ten-digit dial plan could be your best friend.
where do i go to start from scratch? i lost the dial plan and policies and database- no backup after server crash.
ReplyDeleteSide Note (I am a telecom guy) - NANPA is 11 digits not 10 digits. All NANPA numbers start with 1 (country code for Canada and the US and Caribbean) and thus are unique world wide. New Zealand uses 10 digits (2 digit country code & 1 digit area code & 7 digit phone number). Your use of 011 fixes that issue unless you call someone in New Zealand from AD. The company I work for is world wide and we decided on using normalized phone numbers (as found in AD for OC contacts). We don’t use 9 or 011 since other countries use OC to make calls and 9 and 011 might not mean anything to coworkers outside the US. Some sites use 0 to get an outside line and 00 to make an internaional call.
ReplyDeleteThanks for calling that out. You are totally correct. My intention was to talk solely abouta US bound deplyment and so I went for 10 digits even though as you point out NANP is actually 11 but keep in mind the discussion is about normalization. I like to think of it as correcting a users bad habits to get it into E164 format. The enterprise I work for has tried to standardise on ten digits for dialing so dialing the 1 is not required. 011 is another habit that just cant be avoided since this is what users currently have now (in the US).
ReplyDeleteSo just remember normalization is not what you send out the trunk or what you can dial but its what you are willing to correct for users before dialing. (The call to NEW Zealand in E164 format would go through fine if you have route for it). We could force all users to follow E164 and everything would be great but like many enterprises that have multiple PBX deployments that vary in vendor and age, this would be unacceptable to both management and users. So we need to get close to what our enterprise dialing plan is across the board in the US anyway. As for other locations around the world a new location profile with country specific dial patterns could also be built.
I am certainly green with jealousy that you could deploy with out dial codes and being able to stick with just the E164 format. Your users must be a little more flexible than the ones I work with:-)
This comment has been removed by the author.
ReplyDeleteJust some good house keeping, the format for NANP is:
ReplyDeleteNPA NXX Station
Displaying NANP in international format requires the 1. Depending on where you are calling you may or may not require the one.
So both 10 digits and 1+10 fall into the NANP format