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

If you read the dial plan section of Cisco’s UC SRND or happen to attend one of their dial plan design presentations at Cisco Live or a similar event you will invariably read or hear the words Globalization and Localization. What do they mean and how does it apply to dial plan design?

The UC SRND provides a guiding principal for global dial plan design:

Accept localized forms upon call ingress, and globalize them; route the call based on the globalized form; and localize the call to comply to the form required by the destination.
Cisco UC SRND 9.x – Dial Plan

If you’ve read my last two posts about E.164 numbers and choosing a DN Length (E.164 vs some arbitrary number of digits) you should be on board with the benefits of having a consistent format for the core of your dial plan. When you can build all of your call routing decisions with the assumption that all dial strings involved are unique with a consistent format it becomes very easy to make those decisions.

However, the source and destination devices often expect a format other than E.164. End users dialing from phones expect to be able to dial PSTN access codes, leave off the country code or area code for a local call or dial an abbreviated format using site codes. Similarly, a destination like the telephone carrier providing PSTN access may expect specific formats like 10 digits for local metro calls or an international access code like 00 or 011. In a world where we demand E.164 formatted numbers to make call routing decisions none of these things are allowed to enter the ‘dial plan core’.

This is why we must globalize (or expand to E.164) numbers that enter our dial plan and then localize (customize from E.164) numbers when they leave. Here’s a quick diagram that shows this concept with a slew of features that take place in the ‘core routing’ section of our dial plan that are made easier when we have the consistency of E.164 numbers.

How do we go about this? With Transformation Patterns.

First, what’s the difference between a Transformation Pattern and a Translation Pattern? A Translation directly affects the path or route that a call takes. A CSS is applied to a translation and this affects where the call goes next. A Transformation changes the format of a called or calling party number, but does not itself change the route or path that a call takes. When the call arrives at the next hop the path may change based on the new format of the number delivered, but that decision is made at the next step in the process.

Two quick notes on Transformation Patterns:

1. The Transformation CSS ignores patterns in the <None> partition. It is the only type of CSS within CUCM that does this.
2. The CSS assigned to a device as the Called Party Transformation CSS should include ONLY Called Party Transformation Patterns and no Calling Party Transformations. Same thing the other way when applying a Calling Party Transformation CSS. Bad things might happen if this is not followed that range from CCM core dumping to calls ending up in unexpected places.

Where should we apply these Transformation Patterns? At a minimum in two places.

First, we should apply them to our inbound SIP Trunks or Gateways to the Inbound Calling Party Transformation CSS to globalize the calling party numbers we receive from the carrier to E.164. This puts the E.164 formatted number in phone directories like Missed and Received Calls and allows for easy dial back. This is part of our Globalization.

You might also ask whether we should Globalize the Called Party on ingress to CUCM. The answer here is yes, but I prefer to do this on the voice gateway rather than CUCM so that the expansion to E.164 will persist through SRST when our phones with +E.164 formatted DNs are registered to the local gateway. This means the called party will show up on CUCM in a globalized format already.

Second, we should apply Called Party Transformation Patterns on our outbound SIP Trunks or Gateways to Localize the call as it leaves CUCM. For customers that use PSTN Access Codes (e.g. dial 9 to get an outside line), I prefer to do all of this within CUCM so that I am sending the localized, PSTN Access Code-prefixed pattern to the voice gateway. Once again, this has benefits for SRST as my users are used to dialing with a PSTN Access Code and my dial-peers on the voice gateway will match those dialing habits.

Remember that each of these Called Party Transformations will be a \+… pattern. Because we globalized the called number to +E.164 in order to have a consistent, unique number to make an intelligent call routing decision we lost the context of the user dialed string. Said another way, I no longer know whether the user dialed the number with or without a country code (if the user intended it to be a local or LD call). CUCM needs to have the logic that matches what the carrier expects to see. Local area codes for that site should not include the country code, in the US maybe they should even be dialed as a 7-digit pattern instead of a 10-digit pattern. CUCM must have this logic because the users are unable to influence this by dialing differently (we globalize it and that context doesn’t make it all the way through to the end device). A site like http://www.localcallingguide.com/lca_prefix.php is helpful in finding which area codes and exchanges should be local for a particular site in the US.