debug gatekeeper main 10

H.323 gatekeepers can be a difficult topic to approach.  Most people have not integrated this into their environment and, therefore, have little hands-on experience deploying and troubleshooting this technology.  Personally, I think the idea of a gatekeeper is a pretty cool concept.  If using H.323 gateways, it can make your dial plan management a whole lot simpler.

One of the frustrations related to using gatekeepers is the lack of debugging available.  Fear not, my friend!  I recently stumbled across an undocumented debug command that will make your gatekeeper work easier: debug gatekeeper main 10

In this scenario, I placed a call from extension 3002 at a remote-site CUCME to extension 5002 in a CUCM cluster.  Calls are routing to the gatekeeper via an H.225 RAS dial peer, with tech-prefix of #1:

@@@ Turn on gatekeeper debugging
HQ-RTR#debug gatekeeper main 10
HQ-RTR#
*Feb  7 20:28:24.866: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_process: QUEUE_EVENT (minor 0) wakeup
*Feb  7 20:28:24.866: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_arq: arqp=0x48D839A0,crv=0x1A, answerCall=0
*Feb  7 20:28:24.866: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_sep_arq: ARQ Didn’t use GK_AAA_PROC
*Feb  7 20:28:24.866: //2A31F52E8078/2A329156807A/GK/gk_dns_query: No Name servers

@@@  At this point, 1#5002 was received by the gatekeeper.  It saw that #1 was a tech-prefix for an H.225 gatekeeper-controlled trunk in CUCM that is registered to the gatekeeper.
*Feb  7 20:28:24.866: //2A31F52E8078/2A329156807A/GK/rassrv_get_addrinfo: (1#5002) Matched tech-prefix 1#

@@@  At this point, the gatekeeper goes on to the next section of digits “5002.”  It looks in its tables and sees that “zone prefix 5…” directs these calls to the H.225 gatekeeper-controlled trunk in CUCM
*Feb  7 20:28:24.866: //2A31F52E8078/2A329156807A/GK/rassrv_get_addrinfo: (1#5002) Matched zone prefix 5 and remainder 002

@@@ RAS admission requests are sent to the side sourcing the call.
*Feb  7 20:28:24.866: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1
*Feb  7 20:28:24.866: //2A31F52E8078/2A329156807A/GK/rassrv_arq_select_viazone: about to check the source side, src_zonep=0x48D06EAC
*Feb  7 20:28:24.866: //2A31F52E8078/2A329156807A/GK/rassrv_arq_select_viazone: matched zone is PL, and z_invianamelen=0

@@@ RAS admission requests are sent to the side receiving the call.
HQ-RTR#7 20:28:24.866: //2A31F52E8078/2A329156807A/GK/rassrv_arq_select_viazone: about to check the destination side, dst_zonep=0x48D06EAC
*Feb  7 20:28:24.866: //2A31F52E8078/2A329156807A/GK/rassrv_arq_select_viazone: matched zone is PL, and z_outvianamelen=0
*Feb  7 20:28:24.866: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_get_ingress_network: ARQ non-std ingress network = 1

@@@ RAS bandwidth requests are sent
HQ-RTR#
*Feb  7 20:28:26.518: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_process: QUEUE_EVENT (minor 0) wakeup
*Feb  7 20:28:26.518: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_brq: state = 0xF
*Feb  7 20:28:26.518: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_brq: brqp=0x48D80C84, crv=0x1A, bandWidth=160

@@@ RAS information requests are sent
*Feb  7 20:28:26.518: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_process: QUEUE_EVENT (minor 0) wakeup
*Feb  7 20:28:26.522: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_rassrv_irr: irrp=0x48D80ED0, from 10.10.110.3:54771
HQ-RTR#
*Feb  7 20:28:32.122: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_process: got a TIMER event
*Feb  7 20:28:32.122: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_handle_timers
*Feb  7 20:28:32.122: //xxxxxxxxxxxx/xxxxxxxxxxxx/GK/gk_handle_timers: managed timer expired 0x467C9258