I started writing this series three years ago, but got distracted by other tasks and neglected to complete this last post in the series. It’s one of the most important. Before I begin writing about other topics I wanted to come back to this draft and the notes I started three years ago and finally publish it.
First, let’s set our baseline. The common wisdom in Cisco UC for as long as I can remember has been to use the “Device/Line” approach. Older SRNDs spent plenty of time explaining this approach, which can be summed up as follows:
- Provide access to ALL destinations via the Device CSS (unrestricted access to internal & PSTN)
- Restrict access and create Classes of Service via the Line CSS and exact match blocking patterns.
- The resulting concatenation of the Device and Line CSS’s would provide the user’s Class of Service.
E.g. if I had a pattern, 9.1[2-9]XX[2-9]XXXXXX to provide long distance calling in the US applied to the Device CSS, but I wanted this phone to have Local-only dialing privileges I would need to create a duplicate pattern, 9.1[2-9]XX[2-9]XXXXXX, that would be set to block or reject the call. This blocking pattern would be applied to the Line.
The thought was that you only needed one set of blocking patterns to handle an entire country dialing plan. That same 9.1[2-9]XX[2-9]XXXXXX that blocked LD calls in Minnesota would work equally well for users in California, Kentucky, etc. It was intended to minimize the overall configuration needed.
But with +E.164 patterns this starts to break down. These blocking patterns that provide Class of Service can no longer be applied globally when it comes to E.164 because they are source specific (i.e. the context of the call matters). Take a look at this same E.164 pattern and see what I mean:
- +1651XXXXXXX in Minneapolis, MN blocks Local calls
- +1651XXXXXXX in Chicago, IL blocks Long Distance calls
- +1651XXXXXXX in Germany blocks International calls
Once deciding to allow users to dial E.164 patterns our entire Class of Service design breaks down. We’d need to individually create blocking patterns at every geographic location based on their local, LD and Intl patterns.
What’s the alternative? A single CSS. That single CSS should have:
- Route Patterns that are ONLY in +E.164 format
- All other patterns are Translation patterns that Globalize to +E.164 format
In this way we create translation patterns that allow all of the end user dialing habits, globalize those varied dialing habits to a standard E.164 number and then provide class of service based on the E.164 patterns.
Here are two examples:
In the first we have an end user that dialed 9 608 298 1100. Looking at the translation patterns in that LD partition you can see that they also could have dialed 9 1 608 298 1100 or +1 608 298 1100 and the end result would be the same. We expand to E.164, use the Originating CSS option on the translation and try again, but now we match the +E.164 Route Pattern.
In the second example we see a CSS that only provides Local calling from Minneapolis. We still match the same translation pattern for this call and expand to an E.164 number. But now when we loop back around there is no matching pattern for the +16082981100 number. There is access to the local area code +1763XXXXXXX, but no long distance area codes.
One benefit of this is that toll fraud patterns like 1-900 numbers only need to be defined once as +E.164 blocking patterns. No matter how a user tries to dial (with PSTN Access Code, with/without 1, etc.) the only Route Pattern that will match and potentially provide PSTN access is the single blocking pattern.
What are some other benefits of this Single CSS approach?
- There are places we can’t apply a Device/Line approach because CUCM only allows one CSS
- Call Forward CSS’s (except CFwdAll)
- Rerouting and Out-of-dialog CSS’s
- Integrations (SIP Trunks to 3rd party systems, Expressway, etc.)
- Device/Line is complicated and confusing. It’s second nature for most voice engineers now, but new engineers and customers who rarely touch the Call Routing config in CUCM have trouble following the “resultant CSS” to know what access a phone truly has. A single CSS is easier to troubleshoot.
- No need to create exact match blocking patterns for Line CSS’s for every pattern created and added to a Device CSS. Let’s face it, the system might be perfect on First Day of Service, but come back a year or two later and I guarantee there are toll fraud holes in that Device/Line design from admins inadvertently creating new patterns and not creating a partner exact match blocking pattern for all of the Line CSS’s.
Where should we apply this single CSS? The Device or the Line? Choose carefully for your design.
- If applied to the Device it is changed by Device Mobility and Extension Mobility
- If applied to the Line it follows that user when roaming.
This isn’t a one size fits all scenario, but I’ve found this approach to work well.
- Apply a single CSS to the Line only.
- Apply Emergency (911) patterns to the Device since emergency calls should be location-specific rather than user-specific. But do so via each Device Pool’s Device Mobility CSS. Even if you are not using Device Mobility this CSS will still apply to the phone and keeps extra config off of the phone. It also means it’s less likely admins will forget to set it and cause an issue with emergency calling.
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.
E.164 seems to be a buzzword lately when it comes to dial plan design. Let’s first define E.164.
The ITU-T developed the E.164 recommendation that defines a standard number format. That format is a global standard of up to 15 digits usually prefixed by a +. (Thanks, Wikipedia.) What does that mean for us? It means that we can define every PSTN-dialable number in a consistent, standard format that guarantees each is unique. Here are some examples of E.164 numbers.
This standard format is good for the majority of folks in IT who have slight OCD tendencies when it comes to naming standards and documentation in general. The unique part of it helps us when designing a dial plan to avoid unwanted behaviors like interdigit timeout. Recall our discussion of interdigit timeout and leading digits or characters. The E.164 recommendation to use the + char as a prefix means these globally unique strings will not overlap with any other internal dialing patterns.
E.164 sounds great as a potential tool to avoid interdigit timeout, but unfortunately Cisco does not fully support the + char in all UC products. Here’s a quick snapshot (to the best of my knowledge as of 7/20/2013 and UC 9.1):
- UCM – Fully Supported.
- However, in some fields it requires the + to be escaped. E.g. a DN must be in the format \+16515551234. This is moderately acceptable for an administrator except for the fact that it’s very difficult to keep straight which fields require the escape character and which do not when creating bulk load import spreadsheets. This is entirely unacceptable when the UI designers do not catch this distinction and it slips through to an end user facing location in the /ucmuser User Option web page or in the Queue Status app or elsewhere.
- CUC – Fully Supported.
- In 9.x. Prior to 9.x the + was only supported in Alternate Extension fields and not the Primary Extension field. CUC 9.x supports the + in the Primary Extension field and evaluates a number with or without the + as the same extension. E.g. If I configure one user with the extension +16515551234 and another with the extension 16515551234 the second user creation will fail due to an overlap (assuming both are created in the same Partition).
- UCCX – Not supported for Agent DNs
- This is a major problem and needs to be fixed. The common workaround is to create a separate partition in UCM for Agent DNs and configure them without the +, then limit the use of that partition to only necessary CSS’s.
- CER – Partial Support
- CER can dynamically track phones configured with DNs that include a +. It can route calls from these phones no problem.
- CER cannot create manually configured phones with DNs that include a +.
- It also cannot search for a phone by Extension if it includes a +.
- Finally, it does not support ELINs that include a +.
- IM&P/Jabber – Fully supported
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:
- 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.
- 22 1234
- 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.
- Require a suffix or terminating character to signal to UCM that the user is done entering digits. The standard terminating character is #.
- 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.
- 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.