Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

Catch-all or default route for inbound DIDs on a PRI

Here's the scenario:

We have a PRI from the telco delivering 4-digits. The 2821 ISR is configured for 2-digit extensions. The telco has assigned DIDs 2500 - 2599. We have about 20 extensions defined and calling into them directly works as it should. In fact everything is working just fine. What we are trying to accomplish is this: if one of the 80 remaining DIDs is dialed, we want to route them to the operator (x00). As it stands if we receive the digits 2508 (since x08 isn't assigned) we see a cause code of 'unallocated number'. How do I construct a rule that accomplishes the following:

if 2-digit extension is defined then route accordingly; else route to operator

Here is our existing inbound translation-rule.

voice translation-rule 1
rule 1 /^3008/ /00/ (last four from original published BTN routing to the operator extension)
rule 2 /^2560/ /60/ (CUE dial-in from pstn)
rule 3 /^..\(..\)/ /\1/ (ditch the first two digits the telco sends)

I can't seem to find a way to do this that doesn't break rule 3 and route everything to 00.

Thanks for any help.

2 REPLIES
Hall of Fame Super Gold

Re: Catch-all or default route for inbound DIDs on a PRI

This is a little tricky but can be done.

Route back calls via loopback after changing called number

voice translation-profile set-oper

translate called 20


voice translation-rule 20

rule 1 /.*/ /00/



dial-peer voice 100 voip

destination-pattern ..

session-target ipv4:

codec g711u

no vad

translation-profile set-oper outgoing


dial-peer voice 101 voip

incoming called-number 00

codec g711u

no vad

New Member

Re: Catch-all or default route for inbound DIDs on a PRI

Thank you for the suggestion. We tried to implement this, but as soon as I did every outbound call began to route to the operator at 00. The CME would not take the following command:

rule 1 /.*/ /00/

So I made it:

rule 1 /\.*/ /00/

Perhaps that was incorrect.

In the interest of a quick, albeit partial fix, what we ended up doing was creating ephone-dns for the remaining DNs and then call forwarding them to 00. This works for everything up to 89, so better than nothing for the time being. Any other ideas?

245
Views
0
Helpful
2
Replies
CreatePlease to create content