Testing voice translation rules

To see how a voice translation rule applies to a particular string, use the command “test voice translation-rule {ruleset} {string}”

Using Translation rules and translation profiles to manipulate the calling and called numbers

Here is the lab setting:

Mongi Shop is in Austin. Mongi wants to buy a bicycle from a local store. When he dials in the Sports Shop number (in Austin too), we need to make sure that on the gateway:

• the calling number is expanded to its E.164 format, which is the single PSTN number Mongi bought from Telco,
• the called number is expanded to its E.164 format too

Using translation rules and translation profiles
– we modify the outgoing calling number to a full E164 Local PSTN number –> apply it to the outbound dial peer
– we modify the incoming called number to a four-digit internal number –> apply it to the inbound dial peer

Let’s select the internal Mongi line:

Then dial the full PSTN number:

Also, when a PSTN call to the Mongi PSTN line, the called number is transformed into a four-digit number. And the internal line rings.

If there were another internal number with extension 5001, then we could translate it easily to the DID number, leveraging the “&” reg exp and the “\1” reg exp, like this:

The “&” reg exp in voice translation rules is replaced by the the matched set.

Using translation rules and translation profiles to block incoming calling numbers

It is possible to leverage translation rules and translation profile to block a certain number -or range of numbers- in the inbound direction.

Here is our network setting:

x4002 — PSTN router — Mongi Shop — x5002

Initially, extension 4002 on PSTN can call extension 5002 on Mongi Shop:

On Mongi Shop router, we are going to block incoming calling numbers that begin with 4. We configure a blocking voice translation rule:

Apply the translation rule to a voice translation profile:

Then we apply the voice translation profile to an inbound matched dial peer, with the command call-block translation-profile.

And optionally configure a disconnect cause with the command call-block disconnect-cause:

Now we dial again from PSTN to Mongi Phone, and the call fails:

Which comes first for an inbound voip call leg, global translation profile or dial peer matching?

To demonstrate that, let’s use this diagram:

On this lab, I added a voice translation rule that changes “5” to “22”. I applied it to a translation profile, with the called string. Then I applied the Voice Translation Profile globally.

The command to apply voice a translation profile globally to an inbound voip call leg is voip-incoming translation-profile {TPname}

I dialed from PSTN to Mongi Shop. The call did not succeed. 

It seems like, on Mongi router, a dial peer is matched in the inbound direction first, then the called number was altered (with the global translation profile).

Are global translation profile applied for an incoming voice call leg before dial peer matching? I did not find that on my home lab. I wonder why the CVOICE Foundation Learning Guide put Global Voice Translation as number one in the digit manipulation order of execution, in the incoming voip call:

And with the Cisco Voice Gateways And Gatekeepers book, it says “Before inbound dial peer match”:

With this post, and with the results I found in my previous post Using Num Exp, I begin to wonder if I am right and the others are wrong. Or maybe it’s the IOS behaviour that changed across the years. One thing is clear now: I will no longer take anything for granted from Cisco Press, or even from a CCIE.

Voice translation profile order of execution if it appears at many levels

Voice translation profile order of execution for inbound call legs

If a voice translation profile is applied globally and another one at a dial peer level, the global voice translation profile overrides the dial peer voice translation profile. Let’s demonstrate that.

We configure two voice translation profiles:

• one global voice translation profile
• one voice translation profile applied at a dial peer level

We make an incoming call. The call fails.

After the inbound dial peer match, the global voice translation profile is executed and it overrides the voice translation profile configured under the dial peer. So what happened is:

1. a call arrives at Mongi router
2. an dial peer (111) matches the inbound call leg
3. the global voice translation profile is executed
4. the voice translation profile configured under dial peer 111 is overridden.

If we delete the global voice translation profile, IOS will look at the voice translation profile configured under the inbound matched dial peer:

Debug voice translation

We activate debug voice translation and we make a call from PSTN to HQ DID number.

The calling number is 7175428411. The TON is unknown. The dial plan is unknown, and it is a calling number:

Remember that a voice translation rule can modify the following parameters of a call:

• digits
• type of number
• numbering plan

I have configured two voice translation rules (or rulesets):

The IOS searches for matches for the configured voice rulesets under the dial peer for the inbound call leg. The dial peer has voice translation rule 5:

The calling number 7175438411 was modified successfully.

Now the called number:

Test voice translation rule

A method to test the effect of voice translation rules on dial strings is the command test voice translation rule.

For the previous PSTN calling party number, we test the impact of voice translation rule 5 on it:

Modifying the type of number and the numbering plan with translation rules

In my home lab, since I don’t have access to a ISDN network, I emulated ISDN calls and number types by leveraging voice translation rules and voice translation profiles.

For example, I want to make the emulated-PSTN line 5124771551 call HQ gateway with number type National and numbering plan ISDN. I did it with this configuration:

I applied the same concept for other lines (national, international). However, one question is: how can a line be emulated as number type Subscriber on one side, and National on the other side?

What I did is to configure a separate voice translation rule for calls to HQ gateway and for calls to Branch1. In fact, a PSTN call from 7177438411 to HQ DID block 717851XXX is considered by PSTN as a Subscriber line, while if it were to Branch1 it would be a National call.