1. Interdigit Timeout
2. E.164
3. DN Length
4. Localization and Globalization
5. No Device/Line?!

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?

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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:

• +1000001XXXX
  • 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.

1. Interdigit Timeout
2. E.164
3. DN Length
4. Localization and Globalization
5. No Device/Line?!

One of the most interesting parts of my job designing Cisco UC solutions is dial plan design. This will be the first in a series of posts discussing enterprise dial plan design as it relates to Cisco UC. The topic for this first post? A discussion of one of the more important design constraints when it comes to dial plans: avoiding interdigit timeout.

Interdigit timeout is a primary factor every time I walk into a new organization to help with a dial plan design. Interdigit timeout occurs when a user dials a string of numbers, but the system still matches multiple possible destinations (patterns) and must wait to see if more digits will be entered or if it should pick the best match with the current dial string.

Here’s a simple example. Let’s say I allow users to dial each other internally via 4-digit extensions. The CEO has also determined that to make life easy for end users they should be able to dial a 10-digit number to reach PSTN dialers so that their office phone works just like the iPhone in their pocket. So I decide to call Deb at extension 6515. The system matches this, but also recognizes that I have a pattern 651[2-9]XXXXXX to route calls local to St. Paul, MN out the St. Paul site’s gateway. Deb’s 6515 extension has the same digits as an Irish pub in St. Paul, MN with a phone number 6515551234. Because of this, it must wait a few seconds to see if I will enter more digits to dial that Irish pub where a tall, cold glass of Guinness awaits or if I really intended to dial Deb. This is very confusing to users who are not used to hearing silence or waiting for the phone to start playing ringback. Chaos ensues and the help desk manager just started researching office pranks to exact revenge on the voice team.

Let’s apply this to UCM on a larger scale. In any UCM we likely have thousands of potential patterns that exist as DNs, Translation Patterns, and Route Patterns. To incur interdigit timeout we need variable length patterns. If every pattern was 4 digits long the system would never need to wait to see if there is a 5th digit. Once we have variable length patterns we can quickly eliminate overlap (which causes interdigit timeout) with a different leading digit. This is why you often have PSTN access codes (e.g. dial 9 for an outside line). I like to create a Leading Digit chart to help understand potential areas for overlap. This requires knowing all extension ranges, DID ranges, PSTN patterns, etc. and might look like this.

• 0 – Reserved for Operator
• 1 – Extensions at Site1 – 4 digits, 1000-1499
• 2 – Extensions at Site2 – 4 digits, 2700-2799
• 3 – Extensions at Site3 – 5 digits, 30000-31999
• 4 – Extensions at Site4 – 4 digits, 4000-4999
• 5 – Open
• 6 – Open
• 7 – Open
• 8 – Extensions at Site5 – 4 digits, 8100-8199
• 9 – Reserved for PSTN Access Code
• * – Reserved for feature codes
• # – Reserved as end of dialing string termination character
• + – E.164 Prefix

This is a pretty concise way of showing where we have room for expansion when ordering new DID ranges to make them fit in the existing dial plan without overlap. The example above is an ideal situation with some leading digits completely open and some with plenty of room for expansion.

Many large enterprises don’t have this luxury. As often as I have a small company with an ideal outcome in their “Leading Digit” analysis I have another company that states, “We have 50 sites with a mix of 3, 4 and 5 digit extension dialing that start with every digit, 1-9”. Often that company is moving from many disparate phone systems at each site to a single, centralized phone system for all sites. It’s easy to explain that some changes need to occur to make this work when all sites must be taken into consideration. What isn’t so easy is getting end users (and execs) to accept these changes. We try to find the change that will have the smallest impact.

What techniques can we use to avoid interdigit timeout issues? Here are a few examples:

1.  Implement a site access code. Each site has a 2-digit site code followed by a 4-digit extension and some renumbering may be required.
   1. 22 1234
2. Use a prefix character like *. This is very similar to the idea of a site access code, but a slightly different track. It essentially moves a client on an existing 4-digit dial plan to a 5-digit dial plan and takes advantage of the fact that * is typically not used in dial plans or extensions today.
   1. *1234
3. Require a suffix or terminating character to signal to UCM that the user is done entering digits. The standard terminating character is #.
   1. 1234#
4. Renumber the extensions at some sites to open up a leading digit like 9 to use as a global PSTN Access Code. Alternate: Buy more DIDs and renumber.
5. Limit the scope of these shorter dial strings. Rather than allowing all users to 4-digit dial every other user allow 4-digit dialing only within a single site and calls to other sites require the full DID.

Generally I end up with some variation or mix of these options. In subsequent posts on dial plan design this topic of avoiding interdigit timeout will be a common theme. Next we’ll look at the ITU-T’s E.164 recommendation including it’s ability to help avoid interdigit timeout.