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

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.