For many of you geeks and nerds out there like me (I’ll take a poll as to which one is better at another time), you’ve worked with some *NIX flavor for many years now. For others of you, you have most likely dabbled with various Linux distro’s and have come to know commands as needed. One extremely powerful tool that you may or may not have come across during your years is SED or the Stream Editor (sometimes referred to as the String Editor as well). This tool can take input from stdin and manipulate it as it leaves via stdout.
For those of you that have used SED in the past, you will certainly notice some similarities to the Cisco set of commands known fondly to many voice folks as Voice Translation Rules, and given your ability to pick out the differences, may help you in your quick adaptation to Cisco’s iteration of this tool.
For those of you that have not ever used this tool, take no worry. For in these next series of blog posts I will attempt to break down not only the components of Voice Translation Rules, but of the overall science of Digit Manipulation in IOS, into bite-sized chunks that will help you to digest it much easier.
Here in this first installation of the blog series, I won’t so much go into practical application along with placement, debugging and the big picture, as I will seek to first help you out with the laws that must be conformed to, in a single rule within the overarching ruleset. Then in near future installations, I will provide not only the framework for wherein this ruleset applies, but also how it affects other forms of digit manipulation as well as detailed debugging to give you a full pragmatic understanding of the power of Digit Manipulation in IOS.
So to begin with, a quick understanding of what we are attempting to accomplish is probably in line. We desire to take a string of digits, in whatever form they are given to us, and change them to something different. We may wish to change a small part of the digits, or the entirety of them. We may not wish to change anything at all about the digits themselves, but instead possibly something about them, namely their Type and Plan attributes.
In order to begin using Voice Translation Rules, we must start out with an understanding of how they work, that is to say “What laws govern them? What laws must we follow in order to obtain our desired output?”.
The First Law of Voice Translation Rules we will very basically see is that our beginning matched number, and our output translated number, must both be surrounded in (or delineated by) a set of forward slashes. So the syntax goes:
voice translation-rule 1 rule 1 /matched-digit-string/ /translated-digit-string/
So it would stand to reason that:
voice translation-rule 1 rule 1 /6145551212/ /6148682121/
Would result in the number 6145551212 being translated to 6148682121 – and that would be correct. We also have a handy test tool to assist us in deciding if what we put in and desire to get out – works the way we intended it to. We run it from exec mode (not global config mode) – and it goes like this:
VORack52R1#test voice translation-rule 1 6145551212 Matched with rule 1 Original number: 6145551212 Translated number: 6148682121 Original number type: none Translated number type: none Original number plan: none Translated number plan: none VORack52R1#
So that’s the first bit. Not too overly complicated is it? Not really – but as we add flexibility in what we can match and what we can do with what we match, you will begin to see the amount of complexity go up. Really what you may see is the amount of readability go down – but again just remember – bite-sized-chunks – after all it’s the only way to eat an elephant (INE does not condone the harming of animals in any way – it’s just a colloquialism).
So next let’s take a look at things a step further. Notice in my above example I didn’t do anything to change the prefixed digits of 614, I seemingly desired for them to stay the same. That being the case, did I need to even include them? What if I simply omitted them altogether? Would everything still match and result in the same output? Let’s take that question/theory for a spin:
VORack52R1#sh run | s voice t voice translation-rule 1 rule 1 /5551212/ /8682121/ VORack52R1# VORack52R1# VORack52R1#test voice translation-rule 1 6145551212 Matched with rule 1 Original number: 6145551212 Translated number: 6148682121 Original number type: none Translated number type: none Original number plan: none Translated number plan: none VORack52R1#
It certainly looks like everything still worked just fine. But why did it? Voice Translation-Rules don’t manipulate data that they are not given to match on. In other words, if the data isn’t included the beginning matched number, then it is simply left alone (e.g. whatever came in – goes out – untouched). OK, you might say – but why did the matched number of /5551212/ allow a match on a string of 6145551212 – the string in the matched number didn’t include the prefix of 614 – so why did it allow the match? Simple answer: Because we never told it that it wasn’t allowed to. Well – can we tell it that it isn’t allowed to? Sure – this brings us to our Second Law of Voice Translation Rules – namely the ability to use Regular Expressions (or “regex”) in the matched number. NOTE: Regex can only be used in matching numbers, not in the translated number. This is the same in IOS as it is in CUCM. Most regular expressions apply. As a reminder, I will very, very briefly excerpt a few more commonly used elements here:
? Matches the preceding element zero or one time.
+ Matches the preceding element one or more times.
^ Matches the beginning of a literal string.
$ Matches the end of a literal string.
| Defines that what goes directly before and after this symbol is a Boolean OR.
\( \) Defines a marked subexpression. The string matched within the parentheses can be recalled later.
About Mark Snow, CCIE #14073:
Mark Snow has been actively working with data and traditional telephony as a Network Consulting Engineer since 1995, and has been working with Cisco Call Manager and voice-over technology since 1998. Mark has been actively teaching and developing content for the CCIE Voice track since 2005, and the Security track since 2007. Mark's story with both data and voice technology started out quite young, as he began learning around the age of five from his father who was a patented inventor and a research scientist at AT&T Bell Laboratories. Mark started out on Unix System V and basic analog telephony, and went on from there to large data networking projects with technologies such as Banyan Vines, IPX and of course IP, and large phone systems such as Nortel 61c, Tadiran Coral, Avaya Definity and of course Cisco Unified Communications Manager in both enterprise and 911 PSAP environments across the US and internationally. Mark is also an accomplished pilot and punched his ticket in 2001. When Mark isn't learning, labing, consulting or teaching, he can be found either piloting or possibly jumping out of a perfectly good airplane, hanging off a rock somewhere or else skiing out west. He also might just be enjoying a quiet day at the beach with his wife and two wonderful young kids, Ryleigh and Judah.
4 Responses to “Lost in (Voice) Translation – I didn’t quite hear what you SED”
Leave a Reply