3825 MGCP using the loopback interface?

Unanswered Question
Nov 14th, 2008

I have a 3825 and using it for MGCP and Gatekeeper function.

Can the registration happen on the loopback interface? I tried to use the loop (yes it routes in my network just fine) but it will not register. If I use the GIG 0/0 interface, MGCP works fine.

What gives? Did I miss something on the "can't do that" list somewhere?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3 (1 ratings)
Loading.
Brandon Buffin Fri, 11/14/2008 - 11:58

No, this should work. So, you used "mgcp bind" to bind the signalling/media to the loopback interface? Does "debug mgcp all" show the MGCP packets sent and received? Does "show mgcp" show that MGCP is bound to the proper interface?

Brandon

Tommer Catlin Fri, 11/14/2008 - 12:09

Yeah, i was missing the bind in the MGCP. My Control is active, but my media is inactive.

My ccm-manager is showing registring. Never "registered"

This is all a new setup.. so it could be something goofy on the CUCM as well, but it all looks correct

Brandon Buffin Fri, 11/14/2008 - 12:44

One thing to check is the domain name on the router. If you have "ip domain-name domain.com" for example and the hostname is "router", you would need router.domain.com as the name of the gateway in CUCM. Simply "router" in CUCM will not work. Just a thought.

Brandon

Tommer Catlin Fri, 11/14/2008 - 12:47

you know what. I think because i dont have my PRI plugged in yet, it will never register. But I thought I could push out configuration changes from CUCM, but I guess not. I will have to get the PRI plugged and go from there

allan.thomas Fri, 11/14/2008 - 14:02

The gateway does not necessarily need to be registered in order to push out configuration changes, providing the gateway has an IP Address in CUCM, any changes you make should be propergated after you Update and reset the gateway.

To verify this do a 'debug ccm-manager config events' on the gateway. Update the MGCP endpoint and the reset the gateway.

Here is a partial debug output, you will see that the XML file is downloaded:-

Nov 14 21:57:09.243: cmapp_xml_cfg_chg_msg: RESET

Nov 14 21:57:09.243: cmapp_xml_send_msg_to_cmapp: ep_name = S0/[email protected]-GWY-01,

msg = 0

Nov 14 21:57:09.243: cmapp_xml_find_ep_by_name: Checking for ep_name [[email protected]

PT-GWY-01]

Nov 14 21:57:09.243: cmapp_xml_process_xml_event: ev_id = 0

Nov 14 21:57:09.243: cmapp_xml_init_ep:

Nov 14 21:57:09.243: cmapp_xml_exec_fsm: Endpoint is [S0/[email protected]-GWY-01]

Nov 14 21:57:09.243: cmapp_xml_exec_fsm: endpoint = S0/[email protected]-GWY-01 state =

CMAPP_XML_IDLE, event = CMAPP_XML_EVT_RESET_GW

Nov 14 21:57:09.243: cmapp_xml_process_reset: state = CMAPP_XML_IDLE, event = CM

APP_XML_EVT_RESET_GW

Nov 14 21:57:09.243: cmapp_xml_convert_ep_name_to_file_name: Converted ep_name S

0/[email protected]-GWY-01 to file_name [email protected]-GWY-01

Nov 14 21:57:09.247: cmapp_xml_tftp_download_file line 90: File (tftp://192.168.

0.6/[email protected]) read 0 bytes

Nov 14 21:57:09.247: xmlmem = 66E7A5F0 malloc, F:cmapp_xml_tftp_download_file L

:94, S:1050

Nov 14 21:57:09.247: cmapp_xml_tftp_download_file line 99: File (tftp://192.168.

0.6/[email protected]) size 1050 bytes

Nov 14 21:57:09.255: cmapp_xml_tftp_download_file line 120: File (tftp://192.168

.0.6/[email protected]) read 1050 bytes

Nov 14 21:57:09.255: cmapp_xml_get_xml_file: Read file tftp://192.168.0.6/S0_DS1

[email protected], len = 1050

Nov 14 21:57:09.255: cmapp_xml_exec_fsm: New state = CMAPP_XML_FILE_DNLD, ep = 6

6B07338

Nov 14 21:57:09.255: cmapp_xml_find_ep_by_name: Checking for ep_name [[email protected]

PT-GWY-01]

Nov 14 21:57:09.255: cmapp_xml_exec_fsm: Endpoint is [S0/[email protected]-GWY-01]

Nov 14 21:57:09.255: cmapp_xml_exec_fsm: endpoint = S0/[email protected]-GWY-01 state =

CMAPP_XML_FILE_DNLD, event = CMAPP_XML_EVT_FILE_DOWNLOADED

A show ccm-manager config-download will also show the download attemps increasing and the configuration attempts and successes also increasing.

Hope this helps.

Allan

Pls rate helpful posts.

Tommer Catlin Fri, 11/14/2008 - 15:47

It's like the are not even talking to each other. I keep getting:

*Nov 14 23:47:11.519: cmapp_xml_process_timer:

*Nov 14 23:47:11.519: cmapp_xml_find_ep_by_name: Checking for ep_name [*]

*Nov 14 23:47:11.519: cmapp_xml_exec_fsm: Endpoint is [*]

*Nov 14 23:47:11.519: cmapp_xml_exec_fsm: endpoint = * state = CMAPP_XML_FILE_DN

LD, event = CMAPP_XML_EVT_FILE_DNLD_TIMER

*Nov 14 23:47:11.519: cmapp_xml_file_retry_timer_expired: state = CMAPP_XML_FILE

_DNLD, event = CMAPP_XML_EVT_FILE_DNLD_TIMER

*Nov 14 23:47:11.519: cmapp_xml_exec_fsm: New state = CMAPP_XML_FILE_DNLD, ep =

665879B0

I have reloaded, reset on both ends, nothing. Tried using the GIG 0/0 interface as well, no change. I certainly can ping both ways, so I know the network is open... checking for any ACL problems, but I doubt it. They are on the same switch and same subnet.

Tommer Catlin Fri, 11/14/2008 - 16:01

Man.. it must be Friday late afternoon. I totally missed I had the MGCP domain name wrong on CUCM. ugggg.... thanks for your help though! I will post up some points. the debug ccm-manager events helped me. I kept looking at the domain name.. and going.. wait a second.. that is wrong!

cheers

allan.thomas Fri, 11/14/2008 - 16:51

Glad that you were able to get to the bottom it, sorry I missed your earlier posts. If you think its late afternoon there it's the early hours here in UK 00:50am.

Have good weekend.

Allan.

Actions

This Discussion