Tag: voice translation rules

Short and sweet – how to block an incoming call on your voice gateway

Welcome to a quick post on how to block an incoming call when you know the calling number you want to block. Specifically, this is how I would block an incoming call on a Cisco voice gateway with an ISDN PRI attached. Your mileage might vary a little with SIP trunks and will definitely vary quite a bit with MGCP.*

The first thing you need to do is create yourself a voice translation rule, something like this ought to do the trick:

voice translation-rule 9
rule 1 reject /5550005555/   <<keep in mind this is the calling number you want to block, but I like to test initially with an outside number such as my cell phone that I can test with.

Then set yourself up a lovely translation profile that references the rule you just created. Name it something obvious so that the next administrator doesn’t have to beat you to death for your obscurity:

voice translation-profile CALLBLOCK
translate calling 9

To complete the configuration, add these two commands to your incoming POTS dial-peer.  If you aren’t sure what your incoming dial-peer is, use the debug voip dialpeer all command and make a test call.  This is a good idea even if you think you know what the inbound dial-peer is because sometimes life is whimsical, and dial-peer configurations even more so.

dial-peer voice 4445 pots
call-block translation-profile incoming CALLBLOCK
call-block disconnect-cause incoming unassigned-number

There are a few ways to test this.  As I mentioned before, you can use your own cell phone number in the original configuration and confirm that the call blocking works. Then just substitute the to-be-blocked number into the voice translation rule.

You can also run the following command and see what the router *thinks* it will do when it sees the number you are trying to block:

test voice translation-rule 9 /5550005555/
/5550005555/ blocked on rule 1

As with all things voice, there are eleventy-billion ways to accomplish a task, this post just covers one.  If you have another method you prefer, please share in the comments, would love to hear it.

Published 03/10/2015

*The process with SIP trunks is practically the same, your inbound dial-peer won’t be POTS, though.  MGCP will require you to use CUCM 8.0 or later for this, check out this document. 

 

Translating nothing into nothing…

Wanna confuse a just-starting-out voice engineer quickly? Just show them voice translation rules. Seemingly simple on the surface, black magic voodoo underneath.  At least it can seem that way to someone new to voice…

The most recent dark magic I learned to perform came about on an issue I was 90% sure was a carrier issue – I like to hold out a 10% chance that the carrier actually did get it right, it’s only fair.

So a user reports that international calls to Great Britain are failing- no other international calls are failing, just those.  Now, I don’t know about your users, but mine *often* have trouble even figuring out the digits to dial to make a long distance call, so my confidence in them being able to accurately enter an international access code is low. Okay, non-existent.

So we fire up the good ole “debug isdn q931” and to my surprise the user is actually right. Surprise being the appropriate emotion since, let’s face it, that doesn’t happen everyday.  I take a capture of the call failure to Great Britain and a capture of the successful international call and conclude that the carrier must be goofing something up somewhere.

Now, I’m really not a blame-it-on-the-other-guy type of gal, but come on- the dial strings are hitting the same route pattern, sent to the same gateway, to the same dial-peer, and out the same voice port.  And only Great Britain numbers fail – thinking it’s not likely my system- seeing that there’s equal treatment to all things international on this end. I reasonably conclude the carrier switch must have some super special, surely unintentional, non-routing going on.

Arming the user with debugs, I send him on his way to confront the carrier with the proof of their Anglophobic ways. That’s when I learn I have overlooked something significant in the debugs- something the lovely carrier technician pointed out – likely with a smirk on his I-know-I’m-right face.

The q931 debugs showed the “type” for the Great Britain calls being marked with type as “International” whereas the calls for other international destinations were being marked with type of  “Unknown.”  Why is this significant?  Well, the “International” designation when received by a carrier switch causes that switch to prepend a 011 to the dialed string.  In this case, it’s extremely detrimental since 011 was already part of the digits placed on the line.

There are many ways to fix this issue, the one I liked best as you may have guessed, involves a translation pattern and was suggested by one of my brilliant coworkers.

It goes like this:

voice translation-rule 1
  rule 1 // // type any unknown plan any unknown

This rule will take anything that hits it, change any “type” to Unknown and any “plan” to Unknown.

It then needs to be added to a translation profile that will catch the called number:

voice translation-profile SET_UNKNOWN
  translate called 1

This then gets applied to the outgoing international dial peer:

dial-peer voice 10000 pots
translation-profile outgoing SET_UNKNOWN
destination-pattern 9011T
prefix 011
port 0/0/0:23

And there you have it.  Calls to the Queen Mother can now commence and users can rejoice!

In case you are still reading this and are interested in the debugs, here are some pertinent excerpts:

From the unsuccessful call (X’s added to protect calling/called parties): Note, Plan:ISDN, Type: International

Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98396
Exclusive, Channel 22
Calling Party Number i = 0x2181, ‘XXXXXX3547’
Plan:ISDN, Type:National
Called Party Number i = 0x91, ‘01144XX80212223’
Plan:ISDN, Type:International

From the successful call (X’s added to protect calling/called parties) – Note, Plan: Unknown, Type:Unknown:

Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98395
Exclusive, Channel 21
Calling Party Number i = 0x2181, ‘XXXXXX3547’
Plan:ISDN, Type:National
Called Party Number i = 0x80, ‘01133XX2087574’
Plan:Unknown, Type:Unknown