Time for a post on one of the basic components of digit manipulation; Translation Patterns. There is a multitude of applications such as changing the called number, changing the calling number and hopping from on Partition to the other. There are also a lot of places where digits can get manipulated; num-exp and translate expressions on voice gateways, applied to voice ports and dial peers, really the list is endless. This post will only discuss the use of Translation patterns on CUCM.
Translation patterns do not directly make any call routing decisions. The manipulate digits, before a call routing decision get made. Translation patterns use Route pattern style matching. And the resulted pattern is then re-analyzed by the system, which may in fact lead to another Translation Pattern being invoked.
Translation patterns, contrary to route patterns, do not have a ﬁnal call-routing destination (route list, gateway, or trunk). Translation patterns exist only to manipulate digits.
As can be seen in the screenshot below a Translation Pattern configuration web page can be broken up in 3 parts:
- Pattern definition
- Route option
- Digit transformation.
As you can see, the "urgent priority" box is ticked (which is the default). when this is ticked, it means that as soon as the pattern gets matched, the translation pattern will be invoked. It will not wait for the interdigit timeout to expire. which means the system will not wait and see if additional digits get offered. For example you have a translation pattern 4XXX and a user tries to dial 41239, now as soon as the 4123 gets offered the pattern is matched. This can suck big time. But what you have to remember is how digits get offered to the CUCM system. With SCCP this is done on a digit-by-digit basis, in which case the above scenario will cause some headache. SIP, on the other hand will present its digits en bloc, in its initial INVITE, which means that the interdigit timout is not a consideration at all from the CUCM's point of view. Back in the old days on older version of CUCM, the urgent priority option could not get disabled and was always active
Examples of translation pattern usage
- Strip a PSTN DID range to an internal number range that is used as extensions on phones. In which case, you can use discard digits Predot to only use 4 digits, if you have a 4 digit internal numbering plan
- Short dails, for instance #123 to order a pizza in which case you translate the #123 pattern into the called number (PSTN number) of your favorite pizza joint
- Hopping partition or moving from one partition to the other. This is a tricky one. A scenario where you can use this is when you have an overlapping number plan on the same CUCM cluster. For instance you have a phone in branch A, partion A extension 8888 and a phone in branch B, partion B extension8888, you tell your people in branche A, in order to call 8888 in branch B they dial #8888. For this create a translation pattern #.XXXX with a CSS containing partition B. the called party transformation is discard digits Predot. This will mean that as soon as that translation pattern gets hit, it will reduce #8888 into 8888 and it will look up the result in the CSS of the TP, containing partition B and thus handing the call of to phone B in branch B.
Routing Next hop based on calling party
I could have snuck this under examples, but I think this topic needs a bit more elaboration. This feature is actually pretty cool. Traditionally translation patterns get triggered, based on dialed digits; digits that in some way a user/phone has offered to the system to make a call to. Ticking the routing Next hop based on calling party-box changes this behavior around, the translation pattern in question does not get invoked by what is being called, but by what or who is calling. This, by itself can provide a whole new layer of call normalization or globalization. UC guerilla has done a great post on an actual scenario for this: http://www.ucguerrilla.com/2014/03/using-cisco-ucm-route-next-hop.html
How to test a TranslationPattern
Block the pattern, set the cause code to "precedence level exceeded" and you will hear a message indicating announcing the fail code, This will point out exactly that you are in fact hitting the intended Translation Pattern, when dialing a number that should considered by your Translation Pattern.
The second method to test a translation pattern, is to use The dialed number Analyzer (DNA) in the serviceability menu. All it does is, check the dial plan to see if the TP that you are interested in, is actually getting hit.
The third, and probably, the most painstaking method is to make a test call and collect the traces for this call, and see what patterns, partitions and CSS's are invoked by the call. This will give you the most detail possible. Make sure that the trace configuration is set to "detailed" to get enough info in your tracelog files.