Feb
25

Austin has devised a dial plan that meets the needs of his company (Backyard Adventures, Inc), and one of the core components of it meets a requirement set forth by his company's executive branch - namely, that although people in U.S. offices of his company dial a '9' as a PSTN access code prior to dialing any additional digits for outside public calls, the executive branch dictates that they do not want the IP phones that dialed such a number to see that preliminary '9' on the phone's display, once the call has been placed.
(e.g. If Pablo dialed 9-206-501-5111 for a local call in Seattle, then his display should only show 2065015111 once the call has been placed)

So Austin --knowing that by default, CUCM updates it's phones' Calling Displays at every digit manipulation step along the way that occurs while the call is still in control of CUCM-- decides to make sure that CUCM strips the '9' off of every egress gateway or trunk, before the call is sent onto the actual IOS device providing gateway services between itself and all of the company's PSTN PRI circuits. This actually meets two objectives of his: the first being the desired behavior just discussed, and the second being the execution of a uniform dial plan with regards to digit manipulation for egress gateways and Called Party Transformation Patterns - whether they be to MGCP gateways (where that '9' must be stripped prior to sending to the IOS device), or to H.323 or SIP GW/Trunks all the same.

Now something that he didn't count on was this: While he was in control of the CUCM and its dial plan, he has to work together with Tyrone who is in control of all the IOS devices, whether for routing or for voice services. Tyrone has informed Austin that all outbound dial peers pointing to the PSTN, begin with a '9' (and are displayed just below). Tyrone also informs Austin that it is fine if Austin sends the PSTN-bound calls to his (Tyrone's) IOS gateways without a '9', but just so that Austin is prepared, he will be reintroducing (prepending) all PSTN-bound calls with a '9' for any gateways that are controlled with the H.323 and/or SIP signaling protocols, so as to match the outbound dial peers - and that he will be doing that on the inbound VoIP dial peer from the CUCM, with Voice Translation Rules as follows:

OUTBOUND PSTN DIAL PEERS
!
dial-peer voice 10 pots
destination-pattern 911$
port 0/0/0:23
forward-digits 3
!
dial-peer voice 11 pots
destination-pattern 9[2-9]..[2-9]......$
port 0/0/0:23
forward-digits 10
!
dial-peer voice 12 pots
destination-pattern 91[2-9]..[2-9]......$
port 0/0/0:23
forward-digits 11
!
dial-peer voice 13 pots
destination-pattern 9011T
port 0/0/0:23
prefix 011
!
INBOUND CUCM DIAL PEER & VTR
!
voice translation-rule 9
rule 1 /^[2-9].........$/ /9&/
rule 2 /^1[2-9].........$/ /9&/
rule 3 /^011.*/ /9&/
!
voice translation-profile Prefix_9_DNIS
translate called 9
!
dial-peer voice 101 voip
translation-profile incoming Prefix_9_DNIS
incoming called-number .
voice-class codec 1
session protocol sipv2
dtmf-relay sip-kpml rtp-nte
!

Now Austin knows that both the H.323 and SIP signaling protocols will retroactively inform the CUCM of any changes to the Called Number, and while he tries to persuade Tyrone to change his method of prefixing the '9', he fails to do so.

So, your contest question for this weekend is this (and requires two separate answers, one for H.323 and different for SIP):

  • Given the above outbound dial peers for any H.323-to-PRI/PSTN and/or SIP-to-PRI/PSTN voice gateways in the Backyard Adventures' unified communications network, and given the fact that Tyrone will not be changing the Voice Translation Rules that he already has implemented on his gateways' inbound dial peers in any way: What configuration can Tyrone add to his H.323 & SIP IOS gateways (separately) to prevent the singaling protocol, and therefore CUCM, from reintroducing the '9' back into the Called Number display of users' such as Pablo's phones when they go to place a call?
  • For extra credit, include the best debug command to ensure that what you wish to happen to the Called Number, is indeed what is actually happening to it. The extra prize to go along with the extra credit answer is this: If you get it correct, you will know you are that much closer to answering exam questions properly for either the TVOICE v8 or the CCIE Voice Lab Troubleshooting tasks! ;-)

As always, the winner of this contest will have their choice of any one of these items:

  • $100USD Amazon Gift Card
  • $100USD in GradedLabs Tokens (which is just a bit more than 3 Voice rack sessions)
  • $100USD worth of INE.com online store credit - which goes perfectly as a complement to your checkout cart containing INE's all new All Access Pass!

The way we will hold the contest is as follows:

  • You must answer all questions correctly - this means that the solution provided must fully meet the requirement (i.e. If something else breaks, such as normal dialing, or digit appearance is not as requested, as a result of your answer - it will not be counted as a correct answer
  • You must submit your answers in the comments section of this post along with a valid email address to reach you for your prize (submissions emailed to INE will not be accepted)
  • If there are multiple, correct respondents, then we will place all of the correct respondents names into an online randomizer - the modern day 'hat', if you will
  • We will not allow any of the response comments to be seen here publicly until Monday morning when we choose the winner, so as not to give an unfair advantage to anyone
  • Also a new one: If you have won a previous contest, you will not be eligable to be in the drawing for this contest, that is unless you happen to be the only correct answer - in which case, we have to give it to someone, don't we? :)

I'll be watching them over the weekend, and I will return on Monday to gather up the winners, choose a random name, and post all of the comments with my own replies and comments.

Again, we will be try to hold these sorts of contests bi-weekly, so check back often to increase your chance of winning!

P.S. Stay tuned at the beginning of next week as we announce an exciting new Non-VPN method of accessing all of our Voice Racks!

Good Luck!
Mark



Congratulations to Earl Hough, the winner of this contest!

As promised below in my comments, here is an updated post with the solution set:
For the H.323 Gateway:

voice service voip
no supplementary-service h225-notify cid-update

... and to verify, run:

debug cch323 h225

For the SIP Gateway:


voice class sip-profiles 1
response 183 sip-header Remote-Party-ID modify "<sip:9([2-9].*)@177.1.254.1>" "<sip:\1@177.1.254.1>"
response 183 sip-header Remote-Party-ID modify "<sip:9(1[2-9].*)@177.1.254.1>" "<sip:\1@177.1.254.1>"
response 183 sip-header Remote-Party-ID modify "<sip:9(011.*)@177.1.254.1>" "<sip:\1@177.1.254.1>"
response 200 sip-header Remote-Party-ID modify "<sip:9([2-9].*)@177.1.254.1>" "<sip:\1@177.1.254.1>"
response 200 sip-header Remote-Party-ID modify "<sip:9(1[2-9].*)@177.1.254.1>" "<sip:\1@177.1.254.1>"
response 200 sip-header Remote-Party-ID modify "<sip:9(011.*)@177.1.254.1>" "<sip:\1@177.1.254.1>"
!
dial-peer voice 101 voip
voice-class sip profiles 1

... and to verify, run:

debug ccsip info

When running the 'debug ccsip info', we see:


//1554/D0D02EC28E93/SIP/Info/sipSPISendInviteResponse: Associated container=0x4A1DBD58 to Invite Response 183
//-1/xxxxxxxxxxxx/SIP/Info/sip_profiles_application_modify_remove_header: Header before modification : Remote-Party-ID: <sip:92065015111@177.1.254.1>;party=c
alled;screen=no;privacy=off
//-1/xxxxxxxxxxxx/SIP/Info/sip_profiles_application_modify_remove_header: Header after modification : Remote-Party-ID: <sip:2065015111@177.1.254.1>;party=cal
Jan
27

The Cisco Unified Communications feature called Mobile Connect (also familiarly referred to as Single Number Reach) is truly a great feature of Unified Communications Manager, and can provide us with many efficiencies both in being able to be reachable just about anywhere, and in being able to be easily identified when placing inbound calls from our mobile phones into the CUCM cluster to our colleagues. As admins, we know that if we wish to have our users place calls from their mobile phones inbound to their colleagues inside the CUCM cluster, that we need to match up all or at least part of their inbound calling party number (CLID) to their CUCM Remote Destination. But what happens when what the carrier is sending CLID digits inbound to our IOS voice gateways that differs significantly from our Remote Destinations in CUCM, especially if we have truly embraced Cisco's push toward true Globalization in v7.0, v8.0 & v8.5?

The fact is that many, if not most European carriers (as well as many more all over the world) send CLID in through an ISDN PRI into the enterprise gateway with a preceding "0" as a courtesy  digit for easy recognition and ease in dialing back out, since this "0" is very commonly used as a carrier-recognized national dialing prefix. If we were speaking of the US and Canada, this "0" we are speaking of would be akin to dialing a "1" prior to the national number. Now in the US and Canada, if a carrier in the US sent CLID into a gateway with a "1" preceding any 10 digit number, this would work fine since the US/Canada country code also happens to be "1". However, the "0" preceding a variable length number is not valid in a true E.164 number format (e.g. If you dialed the phone number from outside of whatever country we were talking about, you would omit that preceding 0 from your dialed digits).

So what are we to do to get our inbound CLID to match our RD's?

That is exactly what we will explore here today in video format, as you watch a very small excerpt from our video-based solutions to one of the many new labs we will have in our new CCIE Voice Volume I & II workbooks.

Click here for the 25 minute video discussion on "The Trouble with European MGCP Gateways and Mobile Connect Inbound Calling Party Matching".

(BTW, if the video starts off with a bit of an echo, just hit CTRL-R to refresh the stream. And then stay tuned to this blog for some very exciting announcements about new formats for video solutions in the very near future)

Happy Labbing,

Mark

Nov
12

Just wanted to update all our CCIE Voice rack renters out there that the new Variphy Remote Phone Control app that I blogged about a few days ago will go live here by the next rack rental session at 3pm PT. Information on how to use it can be found in the first few minutes of this video demonstration of the product.

Oct
21

Join me tomorrow, October 22nd at 12:00 PM PST / 3:00 PM EST, for the free vSeminar: Unified Mobility Interactions with Local Route Group and Globalization.

To attend this free vSeminar, use the following URL tomorrow at 12:00 PM PST / 3:00 PM EST: Unified Mobility Interactions with Local Route Group and Globalization

In case you missed any previous vSeminars, be sure to check out the recent updates here.

If you are interested in learning more about technologies covered by the CCIE Voice Lab Exam, check out INE's Voice Deep Dive. The CCIE Voice Deep Dive is the ideal way to gain in-depth knowledge about specific topics and technologies. We've now just completed 17 modules, and unlike other Class on Demand's that only go to 20 or possibly 25 hours, ours now span over 95 hours of training, and we still have more to go. It truly doesn't get any "deeper" than this. We will post an update with the complete new table of contents to these 3 newly released Deep Dive modules on CUCME, next week.

Hope to see you tomorrow!

May
07

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.

Apr
13

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.

So again to be clear:
Who: CCIE Voice and CCVP Candidates
What: Free vSeminar on "Simplifying Globalization and Localization"
Where: You can access this vSeminar at http://www.ine.com/free-ccie-vseminar.htm
When: April 16, 2010 at 1:00 PM PDT - 2:00 PM PDT (4:00 PM EDT - 5:00 PM EDT)
Why: Because we all love free - don't we?
How: I'm going to present it

So, again - just to be clear:

Who: CCIE Voice and CCVP Candidates
What: Free vSeminar on "Simplifying Globalization and Localization"
Where: You can access this vSeminar at http://www.ine.com/free-ccie-vseminar.htm
When: April 16, 2010 at 1:00 PM PDT - 2:00 PM PDT (4:00 PM EDT - 5:00 PM EDT)
Why: Because we all love free - don't we?
How: I'm going to present it

See all you hard studiers there!

Mar
31

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:

<span style="font-family: sans-serif, 'Times New Roman', 'Bitstream Charter', Times, serif;"><span style="border-collapse: collapse; -webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: 2px;">/<em>matched-number</em>/ /<em>translated-number</em>/ type <em>matching-type translated-type</em> plan <em>matching-plan translated-plan</em></span></span>

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.

Subscribe to INE Blog Updates

New Blog Posts!