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

 

When simple changes aren’t…tales of MGCP to h.323 conversions

Maintenance windows have a way of reminding you that simple changes aren’t always so simple.

Take a recent after hours task of switching over some MGCP gateways to h.323.  The primary inbound gateway was already h.323 and the MGCP gateways were – well, MGCP – so it made sense to make everything uniform and do the conversion.

So I changed all my calls to route in and out the primary gateway, which was already h.323, and set about making my changes.  In case you haven’t done this before, here is a brief outline of the process – not meant to be a step-by-step, all inclusive list, just a general idea of the process.

On the gateway side:

-set isdn switch type on the router (you can get this from the MGCP configuration in CUCM)
-bind h323 to source interface
-create inbound and outbound dial peers on the router
-remove MGCP bind command and other MGCP configuration (you will need to shutdown the voice port to do this)
-reconfigure the T1 controller
-confirm MULTIPLE_FRAME_ESTABLISHED
-put in place any translation patterns required
-add commands for calling name and/or Facility IE support if required

On the Cisco Unified Call Manager side:

-create the gateway 
-add the gateway to a route group
-add the gateway to a test route list
-create a few route patterns to send calls out the gateway
-add gateway to production route list(s)

My plan was proceeding perfectly up until I needed to send a long distance call out one of the recently converted gateways.  The call received a reorder tone from the carrier even though the debug isdn q931 output showed my call going out with the proper digit format. I knew long distance calls were working going out this gateway before, so I was pretty sure it had to be something with my configuration even though it looked like a carrier issue.  

After comparing configurations with the current h.323 gateway (PRI to the same carrier), uttering a lot of fairly creative yet non repeatable curses, and wasting an hour of my life with a clueless carrier tech who swore I wasn’t sending the 1 required for long distance, the obvious finally hit me.  And it was annoyingly painful.

See, I had made the assumption that long distance calling had been tested out the primary gateway when it was installed.  I foolishly believed that outbound long distance via the primary h.323 gateway had been tested at installation, as this is pretty much standard and *should* be part of any voice gateway install process.  Once I wised up and tested that theory, however, I realized that all long distance calling to the carrier was broken from every gateway, including the old h.323 one which I hadn’t changed anything on.  Knowing this couldn’t be the result of my conversion efforts, I was now able to think through what the real source of the issue could be.

When you send the carrier the right digit format and yet they emphatically insist you most definitely aren’t, you are likely hitting an issue I blogged about in my first ever post.  In some cases, a carrier switch reads your ISDN plan type and takes digit stripping action based on it. They seem to be completely unaware they are even doing it, so don’t expect the carrier to ever discover this is your problem. The solution is simply to set a translation pattern that changes the plan type to UNKNOWN and then the carrier switch doesn’t try to do you any favors and manipulate the digits. Problem solved.

I am now adding testing inbound and outbound calling from ALL gateways before making changes to my check list.  Pass the bourbon please.

Bonus material:
At the time, I didn’t think about the 8945 phones (and newer phones with video capabilities) that often require you add a specific command to the ISDN voice port, otherwise outbound calls from the device fail. I discovered this while finishing up my testing plan and was able to fix it before anyone noticed.  A very good reason to have a thorough testing plan no matter how small the changes being made. Here’s a link to a forum post on this type of issue and the command you need to fix it:

voice-port 0/1/0:23
bearer-cap speech

Also, your lucky day, some commands for calling name when carrier is using the Facility IE:

voice service voip
h323
h225 display-ie ccm-compatible
!
interface Serial0/1/0:23
isdn supp-service name calling
isdn outgoing display-ie

Published 7/2/2014

Not All PRIs Connect to Telcos…

Occasionally in voice world you end up configuring PRI connections to devices other than telco gateways. Sometimes these are PRIs between PBXs, fax servers, or other third-party vendor voice gateways for applications. These are typically connections internal to the organization versus a PRI to the outside world. Many times these require you to think just a little bit differently than your standard PRI turn-ups to get to that fabulous MULTIPLE_FRAME_ESTABLISHED goodness.

I’ll offer you a few things to look out for should you find yourself in this type of situation.  Keep in mind that no voice installation is ever *standard* so your mileage may vary.

1. T1 crossover cable. It’s a thing.  Often times the vendor bringing in their voice gateway will tell you things like “it’s just an RJ45 hand-off” or “just provide us a straight-through cable” but don’t believe the lies. More often than not in cases where you are going from your voice gateway to a vendor’s voice gateway, you will need a T1 crossover cable to achieve blinky green light success. You can order these via your favorite cable vendor or Google it to see the pin out and make one yourself, should you be that kind of handy.

2. ISDN switch-type. When you setup a PRI with a telco, they tell you what switch type and line encoding you will use, not much room for creativity.  With these back to back non-telco PRIs, I have found that vendors often have no idea what switch type you should be using and just start naming some that sound believable.  As with any PRI, you need to find an ISDN switch type that both sides can support and this could take some guessing if the vendor doesn’t know. For what it’s worth, I have had a lot of success with primary-5ess, but terrible luck with primary-ni. Of course the switch types and line coding must match between the devices.

3. “Reverse” dial-peers. Typically dial-peers follow a general standard of sending 4 or 5 digits to the CUCM and sending local, long distance, and international patterns out the serial interface of the PRI.  When passing calls between gateways in an internal situation, you need to think about what is going to be coming across to your voice gateway from this new PRI connection.  Many times it’s devices that will be trying to make outbound calls. That means they will be sending calls to your gateway and then your gateway will need to pass them to CUCM to send them out.*  You will also need to communicate to your third-party application configuration team (which may be you) the correct pre-pending for the vendor to use in order to match your dial-peers. For example, will the devices be dialing with a 9 or without?  Here’s an example of a dial-peer that would handle a local call by sending it to CUCM for further processing. Note, in the example I am requiring the vendor to pre-pend**:

dial-peer voice 10 voip
destination-pattern 9[2-9]………
modem passthrough nse codec g711ulaw
session target ipv4:10.10.10.10
dtmf-relay h245-alphanumeric
no vad
voice-class codec 100
voice-class h323 1

4. ISDN, someone needs to be in charge. This where the fairly obscure isdn protocol-emulate network command comes in.  The default in IOS, which you don’t see (because it’s the default), is isdn protocol-emulate user.  You may need to change this to get the PRI to a MULTIPLE_FRAME_ESTABLISHED state. To do so you add the emulate network command under the serial interface like so***:

interface Serial1/0/0:23
no ip address
no ip directed-broadcast
isdn switch-type primary-5ess
isdn protocol-emulate network
isdn incoming-voice modem
no cdp enable

Fortunately troubleshooting these types of connections are about as straight forward as other ISDN PRIs and debug isdn q931 is your best friend. Also, debug voip dialpeer all comes in super handy.

Published 4/30/2014

*this assumes the new vendor PRI and your current telco PRI are not terminating on the same box.  If they are you may need to enable h323 to h323 connections as well as deal with any clocking issues from having basically two providers housed in the same box.  There are specific caveats on making this type of scenario work, refer to Cisco’s documentation for your gateway.

**keep in mind that POTS dial peers consume, that is strip, explicitly matched digits and voip dial peers do not. So if, for example, you are sending a four digit extension across to the vendor’s gateway via a POTS dial peer with a destination pattern of 5000, you should add a forward-digits all to the dial peer to compensate for this behavior.

***bonus information on the isdn protocol-emulate network command

Your name please…

One of the woes we voice engineers deal with on nearly every deployment is the compelling need users have to not only see the calling number of the individual bothering them via telephone, but also the name.  I assume this is so they can add the names of the really annoying callers to a list that gets mailed to the North Pole every December.  (hey, those telemarketers deserve that coal they get in their stockings, no question about it…)

While every deployment is different and I am far too lazy to outline every possible configuration for calling name to show up for users, I will highlight the importance of the command set below being in the router configuration if you are dealing with H323 gateways, calling name is being delivered in the Facility IE, and your inbound calling name isn’t being displayed on the phone*:

voice service voip
h323
h225 display-ie ccm-compatible

How will you know you need this command set?

Well, let’s say you’ve done your due diligence and confirmed with the carrier that calling name *is* being sent. Please don’t skip this step, you will beat your head against your desk until unconscious when you find you’ve been troubleshooting a calling name issue for days and the customer never ordered the service on the line.

Let’s say you have also confirmed, with my favorite debug of all time debug isdn q931, that you are seeing calling name in the debug.  In some cases, like the one we are discussing, calling name may be coming in the Facility IE, and you should see it clearly in the debug**.  It will look something like this:

RX <- FACILITY pd = 8  callref = 0x018C
Facility i = 0x9F8B0100A117020101020100800F41524E4F4C4420414D592020202020
Protocol Profile =  Networking Extensions
0xA117020101020100800F41524E4F4C4420414D592020202020
Component = Invoke component
Invoke Id = 1
Operation = CallingName
Name Presentation Allowed Extended
Name = AMY

Typically if you have gotten this far and your inbound calling name is still not showing, you are nearly there.  Adding the aforementioned h225 display-ie ccm-compatible command should do the trick.

Note that if you are dealing with a gateway running really old IOS, you may not see this command available.  You’ve got to be on at least version 12.4(20)T or else you will be one sad panda. Once you enter these commands, you’ll not only see calling name in the debugs, but your customer should see it on the phone as well and think you are a miracle worker, as we voice engineers often are.

*If you love yourself you’ll be dealing with H323 voice gateways and not MGCP. MGCP, however, does have some nifty check boxes to get  Facility IE calling name working – however, that remains material for another blog post.

**If you don’t see calling name in the debug, then you likely need to enter a few commands to make the Facility IE delivery work. Your serial interface should look something like this:

interface Serial0/0/0:23
no ip address
encapsulation hdlc
isdn switch-type primary-ni
isdn incoming-voice voice
isdn supp-service name calling
isdn outgoing display-ie

Try the above commands if you are seeing something like the debug output below. Also be certain that your switch type supports Facility IE, not all switch types do. On a related note, switch type must be agreed upon between yourself and the carrier, don’t believe you can change one end and the other end will just work. It’s voice mind you, rarely do things just *work*…

Facility i = 0x9F8B0100A11D02010106042B0C0900801254656C65547261636B204F7574626F756E64
Protocol Profile =  Networking Extensions
0xA11D02010106042B0C0900801254656C65547261636B204F7574626F756E64
Component = Invoke component, Unsupported operation

***Additional FWIW – I recently did an upgrade from 6.1 to 8.6 and inbound calling name wasn’t a problem on 6.1 without the ccm-compatible command, but after the upgrade calling name only worked with this command added. I also found this link from 2010 to helpful when troubleshooting this type of issue: https://supportforums.cisco.com/docs/DOC-8873

Published March 3/26/2013