CCIE Training

Many businesses globally – large and small alike – have been converting calls from routing over traditional PSTN carrier trunks – such as E1 & T1 PRI or CAS – to much lower cost, yet still high performance, SIP ITSP (Internet Telephony Service Provider) trunks for years now. INE is no different than your business with regard to this – we have been using SIP trunks in lieu some traditional PSTN calling for years now as well. In fact, in response to a US Federal Communications Commission sub-commitee’s exploration on “PSTN Evolution” in December 2009, a representative from the US carrier AT&T described the traditional circuit-switched PSTN as “relics of a by-gone era”, and said that “Due to technological advances, changes in consumer preference, and market forces, the question is when, not if, POTS service and the PSTN over which it is provided will become obsolete” – source: Reuters [emphasis mine].

The challenge however, becomes that every SIP ITSP carrier has a slightly different way of implementing these sorts of trunks, and each has different provider network equipment that you, the customer, must connect to, and interoperate (properly) with. If you are a large national or multinational business, you may for instance sometimes even connect to two or three different types of provider network equipment, between possibly having multiple contracts with multiple carriers, and even sometimes having to deal with different provider equipment within a single carrier’s network.

Now while you both speak the same agreed upon language (namely SIP), it seems more often than not that you don’t always seem to speak exactly the same dialect of that language. This presents a major challenge in that calls and supplementary services (such as Hold, Resume, Blind Transfer, Semi-Attended Transfer, Fully-Attended Transfer, Forwarding, Faxing, etc) don’t behave as expected, or worse, that some functions don’t work at all.

It is not that SIP isn’t fully mature yet (it will turn 15 years old next year and has been widely used for over 10 years now), or that it is fully standardized and therefore governed by those IETF standards and working groups, it is simply that – as every one of us in the field for any respectable amount of time now knows – not every equipment vendor chooses to implement every single extension and option defined in every IETF RFC for SIP. I mean, have you ever actually looked at how many RFCs there are that deal with not just the core functions, but describe every option and extension to the SIP protocol? There are well over 100 RFCs! Therein lies the problem.

So what are we to do? Cisco Unified Border Element to the rescue! Today we will cover just a few of CUBE’s ability to perform SIP Normalization to allow optimum interoperability with many various SIP ITSPs.

At its base, CUBE consists of allowing both inbound and outbound call legs to be of the type VoIP. Here we first explore a very basic configuration where we have 2 Inbound/Outbound Dial-Peers (depending on which direction the call originates from) To/From the CUCMs in the cluster, and 2 Inbound/Outbound Dial-Peers To/From a fictional AT&T SIP ITSP trunk. We are allowing a codec negotiation and also possibly a DTMF relay internetworking between CUBE  and the CUCMs on Dial-Peer’s 101 & 102 (we needed both of these for another utility on this router using the SIP stack), while allowing for the codec of G.729 Annex B on the AT&T carrier side in Dial-Peers 1001 & 1002. We are also load balancing calls between both of the CUCM Subscriber servers and also between both of the SBCs on AT&T’s side that they have given us to peer with. We see this here:

!
ip domain retry 0
ip domain timeout 2
ip domain name ine.com
ip name-server 177.1.100.110
!
voice service voip
 address-hiding
 allow-connections sip to sip
 redirect ip2ip
 sip
  bind control source-interface Loopback0
  bind media source-interface Loopback0
  header-passing error-passthru
  midcall-signaling passthru
  g729 annexb-all
!
voice class codec 1
 codec preference 1 g711ulaw
 codec preference 2 g729r8
!
!
dial-peer voice 101 voip
 description ** TO/FROM CUCM SUBSCRIBER 1 **
 destination-pattern 2065011...$
 voice-class codec 1
 session protocol sipv2
 session target ipv4:177.1.10.20
 incoming called-number .
 dtmf-relay sip-kpml rtp-nte
!
dial-peer voice 102 voip
 description ** TO/FROM CUCM SUBSCRIBER 2 **
 destination-pattern 2065011...$
 voice-class codec 1
 session protocol sipv2
 session target ipv4:177.1.10.25
 dtmf-relay sip-kpml rtp-nte
!
dial-peer voice 1001 voip
 description ** TO/FROM SIP ITSP - AT&T SBC 1 **
 destination-pattern +T
 voice-class sip localhost dns:corphqr1.ine.com
 session protocol sipv2
 session target dns:sip1.att.com
 incoming called-number 2065011...$
 dtmf-relay rtp-nte
 codec g729br8
!
dial-peer voice 1002 voip
 description ** TO/FROM SIP ITSP - AT&T SBC 2 **
 destination-pattern +T
 voice-class sip localhost dns:corphqr1.ine.com
 session protocol sipv2
 session target dns:sip2.att.com
 incoming called-number 2065011...$
 dtmf-relay rtp-nte
 codec g729br8
!
dial-peer hunt 1
!

Now what if we have a carrier who wants to see our specific domain name (ine.com) after the @ in the Contact header of a SIP INVITE request message (so 2065011001@ine.com   vs.   2065011001@177.1.254.1), possibly for something like compliance with SIP Asserted-Identity? Let’s look at what the SIP INVITE might look like prior to any modification to the above configuration:

Sent:
INVITE sip:+12065015111@sip2.att.com:5060 SIP/2.0
Via: SIP/2.0/UDP 177.1.254.1:5060;branch=z9hG4bK2BAFFD
Remote-Party-ID: "Jack Shepherd" <sip:2065011001@corphqr1.ine.com>;party=calling;screen=yes;privacy=off
From: "Jack Shepherd" <sip:2065011001@corphqr1.ine.com>;tag=8074E2B0-20E7
To: <sip:+12065015111@sip2.att.com>
Date: Fri, 20 Aug 2010 02:34:27 GMT
Call-ID: 9FE12628-A81511DF-8700FC78-AA8D9DEB@corphqr1.ine.com
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 2682052728-2819953119-2264595576-2861407723
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1281926067
Contact: <sip:2065011001@177.1.254.1:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires:  1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 292

v=0
o=CiscoSystemsSIP-GW-UserAgent 5117 3857 IN IP4 177.1.254.1
s=SIP Call
c=IN IP4 177.1.254.1
t=0 0
m=audio 16532 RTP/AVP 18 100 19
c=IN IP4 177.1.254.1
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=rtpmap:19 CN/8000
a=ptime:20

!
voice class sip-profiles 1
 request INVITE sip-header Contact modify "<sip:(.*)@(.*):5060>" "<sip:\1@ine.com:5060>"
!
dial-peer voice 1001 voip
 voice-class sip profiles 1
!
dial-peer voice 1002 voip
 voice-class sip profiles 1
!

Now let’s take a look at what that did to the contents of our Contact header in a new call, and thus a new SIP INVITE message that we send out to AT&T:

Sent:
INVITE sip:+12065015111@sip2.att.com:5060 SIP/2.0
Via: SIP/2.0/UDP 177.1.254.1:5060;branch=z9hG4bK2BAFFD
Remote-Party-ID: "Jack Shepherd" <sip:2065011001@corphqr1.ine.com>;party=calling;screen=yes;privacy=off
From: "Jack Shepherd" <sip:2065011001@corphqr1.ine.com>;tag=8074E2B0-20E7
To: <sip:+12065015111@sip2.att.com>
Date: Fri, 20 Aug 2010 02:34:27 GMT
Call-ID: 9FE12628-A81511DF-8700FC78-AA8D9DEB@corphqr1.ine.com
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 2682052728-2819953119-2264595576-2861407723
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1281926067
Contact: <sip:2065011001@ine.com:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires:  1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 292

v=0
o=CiscoSystemsSIP-GW-UserAgent 5117 3857 IN IP4 177.1.254.1
s=SIP Call
c=IN IP4 177.1.254.1
t=0 0
m=audio 16532 RTP/AVP 18 100 19
c=IN IP4 177.1.254.1
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=rtpmap:19 CN/8000
a=ptime:20

Excellent! It did exactly what we asked it to!

There are many other things that the Cisco’s UBE can do for us, and we have only covered one small one here in this article. For a lot more great information on this product check out INE’s Class-on-Demand CCIE Voice Deep Dive for CUBE. By the way, Cisco’s implementation of what others in the industry might label a “SBC” (Session Border Controller), goes far beyond what other industry SBCs are able to offer in terms of both features and scalability (CUBE hardware support ranges from ISRs for SMBs, up through ISR-G2s and ASRs for Enterprises, up to the 12000 series routers for SPs). I will cover many more of the offered features of the CUBE in follow-up postings, so stay tuned!

I will leave you with a great Cisco article describing some basic functionality of CUBE and SIP Normalization, and also a lot of great Cisco configuration examples from live SIP ITSP trunks that Cisco has installed and tested with in their RTP labs, as well as live PBX integrations that they have performed, and subsequently written up these “recommended practice” documents.

That is a very true saying – in fact one that we believe strongly in here at INE. However we also understand just how expensive it can be to undertake studying for any CCIE Lab exam. That is why, whenever we can, we try to reduce the load on you – the students – to bear this cost. Take for instance our CCIE RS Volume II for Dynamips – we do all we can to provide you the best available instruction while trying to reduce, or sometimes even be able to eliminate the hardware costs associated with studying.

So now we have taken to task trying to do the same for our CCIE Voice track products. We can’t quite virtualize all of the routers used as voice gateways (pesky DSP’s and TDM trunk cards that dynamips won’t ever be able to support since we actually need hardware for the drivers to be able to trigger the signaling), but we thought we would try to reduce the hardware cost for you, the student, in any way we can with the necessary hardware. Anyone having decided to study for the CCIE Voice lab exam has no doubt realized that even if you decide not to take on the enormous cost of building your own rack to practice with, and instead, to rent rack time from any vendor on the market, you still must purchase your own hardware 7961 IP Phones along with some sort of a hardware VPN solution (such as an ASA 5505 or 851 ISR router) at a minimum in order to be able to practice for all of the most important features tested in the lab. This is quite simply due to the fact that the much older 7960’s and all current SCCP Software Client phones (including Cisco CIPC, IPBlue VT-GO*, etc) don’t support any of the newer features – those that are most critical to studying for the latest lab exam. Even if you can manage to find refurbished 7961 IP Phones from eBay for roughly $150/phone and $500/ASA5505 – you still have to invest over $1,000USD just in hardware before you are ready to rent the rack! Seeing as how the 7961 phones are already a generation behind the current ones, and the possibility that when you pass your lab 6-12 months from now that they will likely be 2 generations old and harder to sell for the same price you paid for them – it becomes a very expensive venture to undertake!

To that end, we have made the decision to equip each of our voice racks with three 7961 phones (one at each “site” within the rack topology). Now the only way adding these phones to our racks makes any sense for our students is if we give them some way of controlling them. So we decided to form an exclusive partnership with the most premier remote phone control software company on the market – VoIP Integration. They recently upgraded their very popular Remote Phone software and have added a bunch of features, not to mention made the screen refresh rate a lot faster. Anyway – onto the good stuff. If you are a current (or future) Voice customer of INE, our strategic partnership with them will allow you to purchase their normally $199 Remote Phone software for a significantly reduced cost. One license will allow you to run multiple instances of the software in order to allow you to control all of the phones connected to your rack from a single PC.

If you have the ability to procure these hardware 7961 phones, they are still a great study option, and we still of course still support both IPSec EzVPN in Network Extension Mode and SSL VPN for everyone of our 14 Voice racks, just as we have done for well over a year now. And of course every live Voice course that we teach uses six hardware 7961 IP Phones – that won’t change.

Students outside the US who have experienced higher latency and trouble getting their remote hardware phones to stay registered to CUCM or CUCME may also wish to consider this option and ultimately find this to be a very acceptable alternative.

One final reason that drove us to form this partnership and invest in phones for our racks was that we’ve been asked by so many of our Voice students to provide an option for them to study with 7961 phones as they travel from site to site, and don’t wish to, or in many cases simply cannot, take their hardware phones with them. This gives them the inexpensive option to study using either our phones directly connected to our racks or else their own phones at their main study location connected to our racks via VPN, remotely controlled with this software.

Either way you choose, you now have an equally suitable option for studying for your Voice lab. The only unfortunate part about this is that you know have less of a reason not to be studying for your exam.

Only thing you have to do to qualify for this deeply-discounted version of VoIP Integration’s Remote Phone software is to have 1) purchased any one of INE’s Voice Products, and 2) send me an email expressing your wish to purchase a copy of their discounted software. VoIP Integration will then in turn send you an email to purchase the software at the discounted rate.

Finally – stay tuned for a new announcement approximately one week from now on a brand new Voice product that I personally am very excited to deliver! Something that I have been wanting to do now for a very long time, and something that so far, every live classroom student that I’ve run the concept by, has emphatically communicated back to me how deeply needed this type of instruction is in the Cisco UC marketplace, well beyond the help for the CCIE exam that it will provide. I wish I could give you more info right now – but my flight is landing for my next week’s training class, and I am being told to put my laptop away. So watch this blog early next Friday for the announcement of when this product will (so very soon) launch!

In the (modified) words of Napolean Dynamite:

I hope all of your wildest (studying) dreams come true,

Mark Snow

*IPBlue VT-GO can register to CUCM as a 7961/62 phone, however it does not actually act like one. Many of the most important features tested in the lab, specific to the 7961, don’t work with the IPBlue soft-client – such as Globalization and Mapping Globalized to Localized, G.722 codec negotiation, and many of the softkeys needed.

We had a great response in turnout to Josh’s vSeminar yesterday. Thanks to everyone who made it out, we certainly hope it was beneficial for you!

A few comments from attendees in the ET helped us realize that the next Voice vSeminar, this Friday covering Simplifying Globalization and Localization, might be best held at 4pET/1pPT, rather than the 6pET/3pPT that it was originally scheduled for. So we changed it.

So why a lecture on this topic? Well, every class that I have taught over the last few months has invariably had most students walking in with a printout of the 40+ page, 3-part series on Globalization, Localization, and Mapping the Global to Local Variant blogs that I posted here on this blog a bit back. They all seem to have the same thing to say: “Excellent post, now can you simplify it just a bit for me and can you also explain why we would want to do any of this?”. So to that end – I decided to take on the task of helping you understand not only how in a much simpler way, but possibly more importantly, the why of it all.

Now while the CCIE is normally an exam based much more around the how of things, and much less about the why of things (we typically leave the why to the CCDE side of camp), then what is the reason for thinking that the why is important? The reason I submit for this is simply put that in nearly 5 years of teaching students to understand the technologies involved in any CCIE, I find that students’ brains’ tend to absorb (learn and truly grasp vs. simply learning) the material both more rapidly and thoroughly if they understand the reasons why one might want to implement any sort of technology vs. simply being told that the why of things are not important and that they simply need to learn the technology to pass the lab.

It’s going to be a great seminar that will be sure to keep your attention, simplify this seemingly esoteric topic (it’s not that esoteric by the way – that’s the point of the vSeminar), as well as provide you with invaluable information for taking and much more importantly – passing the CCIE Voice Lab exam.

See all you hard studiers there!

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.

So if we go back to our most recent example with only 7 digits beginning with 555 to match from, and give it a ^ before the matched number, we should see that our input of 10 digits beginning with 614, will simply not match:

VORack52R1#sh run | s voice t
voice translation-rule 1
 rule 1 /^5551212/ /8682121/
VORack52R1#
VORack52R1#
VORack52R1#test voice translation-rule 1 6145551212
6145551212 Didn't match with any of rules
VORack52R1#    

And that’s exactly what we see. However if we modify our input number to only 7 digits beginning with 555, we should still have a match and a subsequent translate:

VORack52R1#test voice translation-rule 1 5551212
Matched with rule 1
Original number: 5551212        Translated number: 8682121
Original number type: none      Translated number type: none
Original number plan: none      Translated number plan: none

VORack52R1#  

And of course indeed we do.

So now let’s move on and take a look at that last powerful expression I posted above – the one with open and close parenthesis, and those backslashes preceding each parenthesis. The backslashes are typical in most scripting languages to escape something that could otherwise be interpreted by the parser as part of the string. We need to inform the parser that it is not part of the string – but in fact an operator designed to do something. In this case it is designed to set apart a section or “set” of our string, that we wish to later recall. So let’s go back to the example of 10 digits that begin (and only begin) with 614, and then set about to change only the 555 to 868, while preserving whatever 4 trailing “Subscriber” digits come in following the 555 prefix. To do that we will include the 614 along with a ^ to denote that the string must begin with a 614. Then we will ”set apart” the part of the number beginning with 555 and ending in any 4 digits. Finally we will change the 555 to 868, and reuse whatever 4 Subscriber digits came into the original string. This brings us to a very important Third Law of Voice Translation Rules, which is that in the translated number portion of the rule – a backslash has a very different role: The Backslash is always followed by a Numeral – and that numeral defines which “section” or “set” from the original matched number is now being “recalled” to this current position. You may have multiple backslash\numerals – and each one independently of the others recalls whatever section is represented by a numeral. It is best to keep things simple and have as few as needed – but complexity can easily be undertaken if the desired outcome requires it. Here we will demonstrate this with a simple single “set” in the matched number, followed by a recall of that set to the translated number, and then of course the “test” to prove the theory.

 VORack52R1#sh run | s voice t
voice translation-rule 1
 rule 1 /^614555\(....\)/ /614868\1/
VORack52R1#
VORack52R1#
VORack52R1#test voice translation-rule 1 6145551212
Matched with rule 1
Original number: 6145551212     Translated number: 6148681212
Original number type: none      Translated number type: none
Original number plan: none      Translated number plan: none

VORack52R1# 

Again we could get a bit more complex with multiple “sets” and “recalls” in the matched and translated number respectively, and yet yield the same resultset:

VORack52R1#sh run | s voice t
voice translation-rule 1
 rule 1 /^\(614\)555\(....\)/ /\1868\2/
VORack52R1#
VORack52R1#
VORack52R1#test voice translation-rule 1 6145551212
Matched with rule 1
Original number: 6145551212     Translated number: 6148681212
Original number type: none      Translated number type: none
Original number plan: none      Translated number plan: none

VORack52R1#

Again – we simply created 2 sets, and then when the placeholder came time in the translated number to recall the contents of that first or second set, we did so with a \1 or \2, along with the other normal string digits (868) we wished to replace.

Another thing we can do is to, as I mentioned above, not change the matched number into anything, but rather to leave it be use the Voice Translation Rules to change the Numbering Type and Plan. The format is a bit odd – it is:

/matched-number/ /translated-number/ type matching-type translated-type plan matching-plan translated-plan

So here in this example we have a common US rural carrier issue, namely that the carrier will refuse the call if both the carrier international prefix string of “011″ and also the numbering type and plan of “international” and “isdn” are all included in the called party IE. To resolve this we simply need to allow any digits that come in, to go out, while at the same time changing the type and plan from ”international” and “isdn” to  ”unknown” and “unknown”. This will do the trick for some carriers.

VORack52R1#sh run | s voice t
voice translation-rule 1
 rule 1 // // type international unknown plan isdn unknown
VORack52R1#
VORack52R1#
VORack52R1#test voice translation-rule 1 011442055551212 type international plan isdn
Matched with rule 1
Original number: 011442055551212        Translated number: 011442055551212
Original number type: international     Translated number type: unknown
Original number plan: isdn      Translated number plan: unknown

VORack52R1#

So that will end our first dive into Voice Translation Rules – and beginning into the much bigger picture of Digit Manipulation in IOS. Stay tuned in the very near future as I will paint (with pretty visuals) a much deeper understanding of both as we take both a more detailed look into many of the components, as well as broader overall view as to where it’s best to use each component, and how they all fit and play nicely together.