Redesigning dial plan from four/six digit to seven digit extensions

Thought I would post this project that I am working on here for input since their are some knowledgeable Voice guys on the forum.

We're running into overlap with four digit extensions and up to this point have been accommodating using two additional digits for some sites to control the overlap, ie. 1234 and 771234.

We're planning to go to seven digit using the prefix/DID as the new extension. All of our sites are NANP and based on the reports I've run we have zero overlap past three digits. We have approximately 2,000 users in 150 sites but are adding new sites all of the time that aren't on VoIP yet.

Also, looking at the dial peers in CUBE, I'll be able to replace all of my incoming with a single translation pattern, rule 1 /^.*$.......$/ /\1/

Anyone here ever done anything similar? Pros/Cons, Anything I am missing?

Find more posts tagged with

SAVE $250 on Your CISCO Boot Camp — Use Code "EXAM26"

Exclusively for TechExams members for Infosec Boot Camps starting before April 30, 2026

View CISCO Boot Camps

Comments

pitviper

I’ve done 3 digit site codes because it’s much easier to control the site code than the prefix. Do you have multiple sites in the same town? Or are worried about being assigned a different prefix should you need to expand a site?

On a side note the guy before me must have gotten a deal a sweet deal on DID blocks beginning with “9” because we have a ton of em!

aaron0011

I agree that site codes are easier to control than prefixes but we were having a hard time deciding how we would logically assign the site codes if we picked the first three digits and used a system like 101, 102, 201, 202, etc. With using the last seven of the PTSN number it makes it extremely easy to configure call routing in and out gateways/CUBEs.

In some cases we do have multiple sites in the same town or area. We have at least 20 extra DIDs per site and in larger ones we have 60+ so expanding sites shouldn't be a problem going forward. In our business we don't have large sites with hundreds of users per except for Corp and we're all good here.

I like the idea of being able to look at someones signature or business card and know their extension right away. Also, we are migrating to click to call via CTI with Lync/Outlook so users having to dial an extra three digits will not be a problem.

shodown

E.164 dial plan and be done with it. It will take much longer to migrate and figure it all out, but all the heavy lifting will be done.

aaron0011

shodown wrote: »

E.164 dial plan and be done with it. It will take much longer to migrate and figure it all out, but all the heavy lifting will be done.

That's my plan (no pun intended)...just hashing out how my DNs will be configured...or are you saying use the full E.164 number as the DN?

This project is also a 6.1.5 to 9.1 upgrade so a lot of changes with call routing with LRGs coming into play. Majority of sites are SIP through CUBE but there are some PRI sites that are mostly H.323, I've only come across a few MGCP so far and plan to get rid of those. Just started a new job and was handed this project with one other guy working with me.

shodown

Yes I'm saying use the entire 7 or 10 digit. Use the plus sign if you have international sites. Hell since your all SIP they can even send you the plus sign from the carrier. That will make everything a breeze once its done. You can create translation patterns so people can still dial 4 digits in there site. This is one of the hardest thing to sell, but it will save the org so much money in time once its done.

aaron0011

Gotcha yeah, we're going to do a E.164 dial plan with a single \+! RP and use translation patterns and transformations for subscriber national, international dialing. I was just asking about actual DN lengths and we're going to stick with using the last seven of each users full PSTN so prefix+DID.

We have about 150 remote site gateways currently so adding in LRG is going to cut down on the complexity a ton from what is currently in the 6.X cluster.