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 didnot 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.

Post navigation

3 thoughts on “The Sting of Rejection: Part 2”

Just thought I’d let other visitors know that selecting a VIC3-4FXS will work if you have a VIC-4FXS installed. I guess 8.6 removed the VIC-4FXS from the selection menu. Searching on Google brought me here, so thought to leave this info for future visitors 🙂