Using Num Exp

Network setting:  x5002— Mongi Shop router — PSTN router — x4002

Effect of Num Exp on an outbound call

On Mongi router, I configured num exp to convert 4 to 5.

And I configured “debug voip dialpeer” to see which dial peer it will match.

What happens is when I dial x4002 from Mongi phone, the gateway converts the dialed string from 4002 to 5002, which makes the same Mongi phone ring:

If we look at the debug output, we see that dial peer 20001 is matched, which is the pots dial peer associated with Mongi phone;

So the dialed string is modified, then the gateway looked into its dial peers to check for outbound matches.

If we do a “show dialplan number 4002”, we clearly see that the called number is converted to 5002 and we see which dial peer is executed:

Let’s convert the digit “7” to “4” on Mongi router:

We call from Mongi phone to 7002. This is a non-existing number. The call succeeds.

If the order was inverted, the dialed string “7002” would not have been matched in any outbound dial peer, and the call would have failed.

By the way, to view any configured Num Exp on a router, do a “show num-exp”

What if we modify the Num Exp to see if it impacts the calling number?

I changed the “num-exp” statement a bit: instead of “num-exp 4 5”, we do a “num-exp 5 7”:

I make the call from x5002 to x4002. The call is correctly expanded and the ringing PSTN phone displays the correct caller number:

So Num Exp did not change the dialing string from 5002 to 7002 as you might have expected. Num Exp operates only on the dialed string.

These quick experiments confirm that Num Exp operation is performed before any outbound dial peer matching occurs.

Effect of Num Exp on an inbound call

We revert the changes and leave only “Num Exp 4 5” on Mongi Router.

When we dial from PSTN x4002 to Mongi phone x5002, the call succeeds. Nothing strange.

Let’s try another example. Instead of “num-exp 4 5” we do a “ num-exp 5 7” on Mongi router.

We make a call from PSTN x4002 to Mongi shop x5002.

The call fails.

After inbound voip dial peer matching, Num Exp kicks in and transforms 5 to 7, resulting in a dialed string of 7002 instead of 5002. This transformation is not seen in the “debug voip dialpeer”.

There is no dial peer that matches the pattern 7002 in the outbound direction. So the call fails.

So for inbound call legs, Num Exp is executed after an inbound dial peer is matched. And it is executed on both the calling number and called number.

Which comes first, Num Exp or inbound voip dialpeer matching?

In the previous examples, we saw that, for an inbound Voip call leg, dial peer matching occurs before Num Exp. However, this was discussed in the Cisco networking community:

• Scott Morris, the Uber Geek, said that Num Exp always comes before dial peer matching.
• Denise Donohue, David Mallory and Ken Salhoff (all are CCIEs) in their book Cisco Voice Gateways And Gatekeepers, say Num Exp comes before inbound voip dial peer matching. Kevin Wallace, author of CVOICE Foundation Learning Guide, says the same thing.
• Mark Snow from INE said that Num Exp kicks in after inbound voip dial peer matching.

So to see what really happens, here is another example:

• I created a Voice translation rule that changes “5” to “7”

• I create a Voice Translation Profile which uses the voice translation rule in a called number

• I associated the voice translation Profile to the inbound voip dial peer on Mongi Router

• I created a Num Exp that converts “7” to “5”

Here is the result when I dial from PSTN into Mongi Router: the call succeeds:

The inbound voip dial peer was matched, its translation profile executed, then came the Num Exp.