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

The Sting of Rejection: Part 2

We left off the last episode with one registered conference bridge and one snarky MGCP port touting its Registration Rejected message as a badge of honor.

So what makes MGCP ports unhappy enough to reject all caring efforts of devoted voice engineers?

A few things you should check first:

Is MGCP configured and running on your gateway? Sounds simple enough, but easy to miss the actual “turning it on” step.

In this particular case, I was configuring a single port on an otherwise h323 gateway as an MGCP port, so my configuration looked something like this:

mgcp
mgcp call-agent 192.168.1.10 service-type mgcp version 0.1
ccm-manager fallback-mgcp
ccm-manager redundant-host 192.168.1.11
dial-peer voice 10 pots
     description MY MGCP PORT
     service mgcpapp
     destination-pattern 7777
     port 0/2/0
application
     global
          service alternate default

The above configuration allows not only for port 0/2/0 to be controlled via MGCP, but also allows the port to failover to h323 when in SRST mode.

So once you’ve checked the gateway configuration and everything looks kosher, you can move onto checking the CUCM piece of the puzzle.  There are (at least) two common errors when it comes to MGCP port configuration.  One, and by far the most common, is to get the device name wrong.

Easiest way to check this is to do a #show ccm-manager on the gateway and see what is listed as the device name in the output . Go ahead and copy and paste this into CUCM to be sure you have it correct. Your device name will look like mygateway@mysitename.com if the domain name is set. This needs to be precise in CUCM or the gateway won’t register – it would be like calling your new girlfriend by your old girlfriend’s name. Hostile doesn’t begin to describe it.

The other most common mistake is to pick the wrong module, card type, and/or slot for your gateway in CUCM.

The best way to ensure you are picking the right module, card type, and slot for your gateway from the CUCM drop-down menus is to do a #show diag on the router. This will show you the part number and slot you should be picking.

If your card is a VIC3-4FXS, selecting a VIC-4FXS in CUCM is not the same thing. Extending the previous analogy, saying your girlfriend has blue eyes when they are really green, will not help your cause. And in that example, the results may be fatal.  With CUCM however, you will likely be greeted with a Registration Rejected message and a raspberry blown in your general direction should you err in your selection.

Here’s an example of what you will be looking at, be sure to confirm part number and location with your router output:

MGCP module selection

On this particular brain-dead day, I had managed not to make either of these mistakes but was still getting a Registration Rejected error. Troubleshooting finally revealed I had made two very bad assumptions.  One- I assumed that the IP address CUCM was seeing for the port on the gateway was reflective of connectivity to that IP address.  Two- I assumed the networking had been done before the voice person was called in.  In hindsight, both of these assumptions were really very silly.

If you haven’t configured an MGCP port before, CUCM shows the IP address of the port after it tries to initially register.  Do not make my mistake and assume this means CUCM can actually reach that ip address.  Logs confirmed that, since I had not bound MGCP to any particular interface, MGCP was sending messages to CUCM which included the highest configured IP address on the router.  Just because CUCM knew about this address did not in fact mean that it was actually reachable.

Once I was issued my clue card, I easily confirmed with an unsuccessful set of pings – sourced from IP address CUCM had reported seeing- that indeed connectivity did not exist between the two devices.

The solution was simple enough – bind MGCP to an interface that could actually reach CUCM and voilà – instantly registered MGCP port.  I will point out that actually fixing the routing is an even better solution, but unfortunately outside my scope on this project, so second best had to do.

Here’s what the fix looked like:

mgcp bind control source-interface GigabitEthernet0/1
mgcp bind media source-interface GigabitEthernet0/1

So there you have it – many more slow days like this and my blog entries will practically write themselves!

Publish date 02/24/2012

Runt post: A little VG224, MGCP annoyance…

While I am not a fan of MGCP for general gateway setup, I agree that it’s a good protocol to go with when setting up a VG224 device.  For those not familiar, you can use a VG224 device to connect multiple analog devices to your VoIP network.  Keep in mind that each analog device you add to your IP network makes a baby cry, but if you’re going to do it anyway and have quite a few analog stations, these devices make sense.

Up until recently, I had never had the privilege of configuring one of these guys from scratch.  Like adding any MCGP gateway, though, its a pretty straight forward process, so imagine my surprise when my VG224 wouldn’t register with call manager.

I saw the Unregistered status in Call Manager, and I also saw this on the gateway when I did a #show ccm-manager from the CLI. The status stayed in Registering toward the primary, then would occasionally swap to Registering toward the secondary. What had I forgotten?  Most commonly the mistake is to forget to use the fully qualified domain name as the device name in Call Manager. If “ip domain name” is set on the router, be sure to include the domain name as part of your device name when adding your VG224 to CUCM.  (Pro tip: You can see what the FQDN name should be in the #show ccm-manager output.)

This wasn’t my mistake though.  My “mistake” was simply this – I was trying to get the VG224 to register, but I hadn’t added any configuration to the ports.  My thought was “let’s get this thing registered, then I’ll go back in and add the directory numbers to the ports” – the VG224’s thought, however, was “I’m not registering until this chick defines some ports.”

Alas, after about 20 minutes of checking the configuration against known good configurations, I decided to proceed with adding the directory number information to the ports and worry about the registration at the end.  After I configured the first port, though, the VG224 starting showing as Registered in Call Manager and I proceeded to kick myself for wasting my own time.

Here’s what you *should* see in the output of a properly registered VG224 using MGCP, notice the Domain Name, this is what needs to be added in Call Manager for the device name:

My_VG224_#show ccm-manager
MGCP Domain Name: My_VG_224_my.lab.com
Priority        Status                   Host
============================================================
Primary         Registered               10.10.10.1
First Backup    Backup Ready             10.10.10.2
Second Backup   None                     

Current active Call Manager:    10.10.10.1
Backhaul/Redundant link port:   2428
Failover Interval:              30 seconds
Keepalive Interval:             15 seconds
Last keepalive sent:            14:12:27 CDT Apr 25 2002 (elapsed time: 00:00:14)
Last MGCP traffic time:         14:12:27 CDT Apr 25 2002 (elapsed time: 00:00:14)
Last failover time:             15:33:26 CDT Apr 11 2002 from (10.10.10.2)
Last switchback time:           15:35:01 CDT Apr 11 2002 from (10.10.10.1)
Switchback mode:                Graceful
MGCP Fallback mode:             Not Selected
Last MGCP Fallback start time:  None
Last MGCP Fallback end time:    None
MGCP Download Tones:            Disabled
TFTP retry count to shut Ports: 2