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:

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