Dial Plan Design: DN Length
We’ve previously discussed interdigit timeout and E.164. With these foundational concepts out of the way we can dive more specifically into UCM.
Let’s start with this statement and look at how to get there: All DNs in UCM should be configured in E.164 format.
I think it’s fair to say that 5 years ago if building UCM (~4.x/5.x days) the DNs were the same length as internal extension dialing. When I say DN I mean the Directory Number field configured when clicking on “Line DN [x]” on a Device in UCM. Maybe the DNs were 4 digits, maybe 5. In larger organizations maybe they were 7 or 8 digits including a site code. In some organizations it was common practice to have a Partition for each site for these internal DNs as there might be overlap between sites. Translation patterns would add or strip digits as necessary to complete calls across the organization.
Then Cisco went and added things like Local Route Groups (LRGs). Mobile Connect became a core feature, not a secondary app. CUPC and later Jabber were introduced with click-to-call and Application Dial Rules (ADRs). InterCompany Media Engine (IME) was released and required E.164. Then SAF CCD and ILS came along to do much the same job as IME, but inside a single org that had multiple clusters. Transformation patterns and the ability to manipulate call ID presentation is ubiquitous. Even outside of Cisco’s product enhancements I think we’ve seen a trend in the last five to seven years of UC becoming the norm rather than the leading edge. More and more organizations started to consolidate the PBX at every site and centralize that management in a platform like Cisco’s Unified Communications Manager.
Each of the things mentioned in that last paragraph changed the way we think about the dial plan. Route patterns can be re-used across multiple sites via Local Route Groups. To prevent on-net calls from being sent to the PSTN when they show up in a corporate directory as the full DID a separate translation or ADR is required for every DID range to strip the call back down to the 5-digit DNs. Mobile Connect required ADRs or customized CSS’s to allow end users to put their cell phone numbers into the User Options page in their preferred format. Organizations consolidating PBXs in an attempt to lower the administrative burden find again and again that deciding on a common dial plan for all those sites is a difficult thing.
There has to be a better way, right? A method to the madness that scales. One that won’t require re-ordering ADRs every time a new DID range is purchased. That won’t require adding a pattern or partition to every site’s CSS to allow all the existing sites to dial the new location that was just brought online. And, of course, there is a better way.
Very simply, create every DN as an E.164 formatted string that matches the DID. Every, single one. Put them all in the same Partition. Now we have a single place in the dial plan for every internal destination formatted as a unique, non-overlapping string. How does this benefit us?
- Administration – A single Partition and format no matter what the site. There is no need to scroll through hundreds of partitions or remember site codes or extension lengths when creating a phone for the new guy that starts tomorrow.
- AAR – Remember when you had to create separate AAR Groups and prefixes for every location? Forget it. Create a single AAR Group and a single AAR CSS that points directly to a single E.164-formatted Route Pattern attached to a Route List with a Local Route Group. Done.
- Want to make sure the masses aren’t dialing their friends in the office a few states over via the PSTN and incurring toll charges? Put a simple Translation Pattern in place of each PSTN-facing Route Pattern to Globalize the dial string to E.164 so UCM can quickly analyze whether this pattern is On Net. More on this powerful technique in the next post.
- Application Dial Rules – There’s no longer a need for ADRs that map to individual sites or DID ranges. Create a single set of generic patterns that normalize all dialed strings to E.164 format. Analyze that E.164 string to see whether it is On Net or Off Net.
- Deploying IME, SAF CCD or ILS? Similar to AAR, check a few boxes and call it a day. No need for messy translations and workarounds.
- Ready to deploy Centralized SIP Trunking and need to put a single Inbound CSS on that SIP Trunk that can reach every site? A single CSS with a single Partition can do the job here. No per-site translations required.
What about non-DIDs? Yes, there are places in UCM where non-DIDs may be required. In my humble opinion these should be extremely rare. Buy more DIDs, they’re relatively cheap. Assign them to anything and everything. Assign them to Agent lines, assign them to common area phones, assign them to nearly everything. Even locations that previously had a single main number with an auto attendant/receptionist that transferred calls to everyone via their non-DID extension in the past… yup, every one of these people should get DIDs as well. Hide it on outbound calls if you must, but assign DIDs. It just makes life easier.
When non-DIDs are required I suggest following the same format as E.164 keeping the + and country code, but modifying the area code to some string that is clearly not valid. Then put all of these non-DIDs in the same “All Internal” Partition where the E.164-formatted DIDs exist. In the US it might look like this:
- The zeroes make it clear to admins and end users alike that this is not a valid NANPA/PSTN number.
- In the case of multiple clusters it may make sense to assign an NXX to each cluster. Take an organization with three UCM clusters in the US. East Coast, Midwest and West Coast. In the example above the NXX 001 would correspond to the East Coast cluster, 002 to the Midwest cluster and 003 to the West Coast cluster. This type of assignment can make sense, but don’t go overboard and overthink this.
- Most numbering plans reserve both area codes and numbering codes. I do not recommend using some of these reserved area codes like 777 or 950 as these are not easily distinguishable by end users as non-DIDs.
- I also do not recommend keeping the country code and valid area code followed by a reserved or dummy NXX for the same reason. The 958 or 555 NXX is reserved, but how many end users will readily recognize this?
Always be consistent with this and develop a plan to assign and track these non-DID assignments across sites and clusters.