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:
- The Transformation CSS ignores patterns in the <None> partition. It is the only type of CSS within CUCM that does this.
- 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.
A couple interesting items I learned about Cisco Unified Communications Manager’s (UCM) Automated Alternate Routing (AAR) feature today.
- In UCM 8.6, even with 1kb of bandwidth allocated for audio it still lets one call through. The second gets stopped or uses AAR. This one might be a bug… more research on that.
- If a DN has a Remote Destination or Dual Mode phone associated to it, AAR will not kick in. The call will be placed to the RD only and the AAR path will not be used. I’m still trying to decide if this is desirable and I’m leaning towards no and a TAC case.
- When exceeding Video Bandwidth for a location a call between two video phones will still traverse the WAN as usual if there is audio bandwidth available, but just set itself up as an audio-only call. Then if video bandwidth opens up and the call is held/resumed video will be added back into the call (unfortunately, looks like a hold/resume is required to get UCM to renegotiate the media. It’d be cool if UCM would keep track of the call and add video when the bandwidth opened up.).
Ah… IOS. Refreshing after spending a week with ACME Packet’s ACLI. And at the same time it certainly has it’s own frustrations. It took me a while to get this working in my lab (partially because I was in Boston and my lab is most decidedly not), but I have a feeling DNS SRV records with SIP are going to prove very useful to me in the future.
The goal here: use DNS SRV records to minimize the number of dial-peers required in IOS. Typically CUCM is set up in some sort of redundant fashion so that there are multiple call processing servers. Going deeper, the configuration of CUCM is such that CM Groups are created with a max of three servers per group meaning everything needs to be pointed at two or three different servers in case one goes down. So we want to use one dial-peer to send a particular call to a CM Group made up of three servers rather than the usual three.
VoIP dial-peers use session targets to determine where to send a matching call. With no DNS SRV records each pattern would require three dial-peers using preference commands as shown below (Note: The use of an ipv4: target vs dns: target makes no difference here, I am using ipv4 in this example for contrast. DNS A records for each server would still require three dial-peers, it is only with DNS SRV records that we can collapse three dial-peers down into one).
dial-peer voice 1 voip destination-pattern 2000 preference 1 session protocol sipv2 session target ipv4:10.0.0.1 dial-peer voice 2 voip destination-pattern 2000 preference 2 session protocol sipv2 session target ipv4:10.0.0.2 dial-peer voice 3 voip destination-pattern 2000 preference 3 session protocol sipv2 session target ipv4:10.0.0.3
With DNS SRV records we can cut this down to one dial-peer:
dial-peer voice 1 voip destination-pattern 2000 session protocol sipv2 session target dns:cmgroup1.lab.local
along with a little extra config (to host the DNS SRV records in IOS to remove reliance on the corporate DNS server)
ip host cucm1.lab.local 10.0.0.1 ip host cucm2.lab.local 10.0.0.2 ip host cucm3.lab.local 10.0.0.3 ip host _sip._udp.cmgroup1.lab.local srv 1 50 5060 cucm1.lab.local ip host _sip._udp.cmgroup1.lab.local srv 1 50 5060 cucm2.lab.local ip host _sip._udp.cmgroup1.lab.local srv 1 50 5060 cucm3.lab.local ip name-server 127.0.0.1 ip domain name lab.local
Finally, in order for a CUCM subscriber server to accept a SIP URI with a destination of @cmgroup1.lab.local rather than @<servername>.lab.local each parent DNS SRV records (cmgroup1.lab.local) must be added to the Cluster FQDN list in Enterprise Parameters. If this step is not completed, expect to see SIP 404 Not Found errors. From the CUCM Help:
This parameter defines one or more Fully Qualified Domain Names (FQDN) for this cluster. Multiple FQDNs must be separated by a space. Wildcards can be specified within an FQDN using an asterisk (*). Examples are cluster-1.rtp.cisco.com and *.cisco.com. Requests containing URLs (for example, SIP calls) whose host portion matches any of the FQDNs in this parameter will be recognized as a request destined for this cluster and/or devices attached to it.
Many thanks to these helpful resources, the first in the list is an especially good resource: