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