Debugging H.

323
Before we get too much into looking straight at the actual h.323 debug
messages, lets check out an extremely useful command for troubleshooting
H.323 including both gateway stuff and gatekeeper stuff.
This has lots of useful info on the
PeterCCIE18371#show h323 gateway
H.323 STATISTICS AT 3d01h
H.225 REQUESTS SENT RECEIVED FAILED
Setup 1 0 0
Setup confirm 0 1 0
Alert 0 1 0
Progress 0 0 0
Call proceeding 0 1 0
Notify 0 1 0
Info 0 0 0
User Info 0 0 0
Facility 0 0 0
Release 1 1 0
Reject 0 0 0
Passthrough 0 0 0
H225 establish timeout 0
RAS failed 0
H245 failed 0
Here we see lots of useful general messages about the type of h225 requests we
have sent and received, rather than wading through h225 debug outputs you
could clear the counters before you made a call with
Clear h323 gateway
Then look at these counters as you make calls. You can see from the above that
we first sent a setup, received an alert, call-proceeding (ring ring), notify, release
(hung up)
Lets take a moment now and say that I setup my CUCME to register to a
gatekeeper. I then create a dial-peer to a number I know the gatekeeper wont be
able to resolve so I can see what happens when I try and make a call and look at

the stats. I will also try and tell the gateway to register with a zone-name that
doesnt exist. Lets look at what happens
PeterCCIE18371#show h323 gateway ras
RAS STATISTICS AT 3d01h
RAS MESSAGE REQUESTS SENT CONFIRMS RCVD REJECTS RCVD
GK Discovery grq 15 gcf 1 grj 2
Registration rrq 2 rcf 2 rrj 0
Admission arq 0 acf 0 arj 0
Bandwidth brq 0 bcf 0 brj 0
Disengage drq 0 dcf 0 drj 0
Unregister urq 1 ucf 1 urj 0
Resource Avail rai 0 rac 0
Req In Progress rip 0
RAS MESSAGE REQUESTS RCVD CONFIRMS SENT REJECTS SENT
GK Discovery grq 0 gcf 0 grj 0
Registration rrq 0 rcf 0 rrj 0
Admission arq 0 acf 0 arj 0
Bandwidth brq 0 bcf 0 brj 0
Disengage drq 0 dcf 0 drj 0
Unregister urq 0 ucf 0 urj 0
Resource Avail rai 0 rac 0
You can see here in the part I have highlighted in red ((grj 2) that our attempts at
registration have been rejected. This normally indicates a config problem
between the gatekeeper and gateway, say something like a certain someone not
actually using the same zone name ;)
When I try and make a call, because the gateway is not even registered my
session target ras dialpeer is totally ignored:
PeterCCIE18371#show gateway
H.323 ITU-T Version: 4.0 H323 Stack Version: 0.1
H.323 service is up
Gateway PeterCCIE is not registered to any gatekeeper
Alias list (CLI configured)
E164-ID 3002

E164-ID 911
E164-ID 2123942123
E164-ID 6178632683
E164-ID 32141891
E164-ID 6745738932
E164-ID 9004522138
H323-ID PeterCCIE
Alias list (last RCF) is empty
So lets first clear our stats and then fix up our registration so we actually register
then make another test call.
#clear h323 gateway
----- Dialed number here ---PeterCCIE18371#show h323 gateway
H.323 STATISTICS AT 3d01h
H.225 REQUESTS SENT RECEIVED FAILED
Setup 0 0 0
Setup confirm 0 0 0
Alert 0 0 0
Progress 0 0 0
Call proceeding 0 0 0
Notify 0 0 0
Info 0 0 0
User Info 0 0 0
Facility 0 0 0
Release 0 0 0
Reject 0 0 0
Passthrough 0 0 0
H225 establish timeout 0
RAS failed 1
H245 failed 0

Thats interesting! We get a lovely new field called RAS failed so we can tell its
tried to route the call via the gatekeeper..
RAS MESSAGE REQUESTS SENT CONFIRMS RCVD REJECTS RCVD
GK Discovery grq 1 gcf 1 grj 0
Registration rrq 2 rcf 2 rrj 0
Admission arq 1 acf 0 arj 1
Bandwidth brq 0 bcf 0 brj 0
Disengage drq 0 dcf 0 drj 0
Unregister urq 0 ucf 0 urj 0
Resource Avail rai 0 rac 0
Req In Progress rip 0
The bit I have highlighted in red shows that there was an admission request (1)
and then an admission reject (1) because we had the wrong number.
Unfortunately you dont get much detail as to exactly why the call was admission
reject, and this could be because of invalid number OR no bandwidth. Annoying
right? Well keep scrolling down
RAS MESSAGE REQUESTS RCVD CONFIRMS SENT REJECTS SENT
GK Discovery grq 0 gcf 0 grj 0
Registration rrq 0 rcf 0 rrj 0
Admission arq 0 acf 0 arj 0
Bandwidth brq 0 bcf 0 brj 0
Disengage drq 0 dcf 0 drj 0
Unregister urq 0 ucf 0 urj 0
Resource Avail rai 0 rac 0
Req In Progress rip 0
DISC CAUSE CODE FROM OTHER PEER FROM H323 PEER
3 no route to destinatio 0 1
No route to destination! We are given the exact reason why the call was rejected.
I truly believe you could work out 99 percent of issues without requiring any sort
of debug messages with this command. It presents them in an easy to read
format. This works for H.323 gateway stuff too, observe the output when I make
another test call to a number not configured to use a gatekeeper but just a
simple H.323 dial-peer where I have set my codec to use g.711 but the other end
is configured for G.729 only.
PeterCCIE18371#show h323 gateway

(Output omitted)
DISC CAUSE CODE FROM OTHER PEER FROM H323 PEER
3 no route to destinatio 0 1
47 no resource (47) 0 1
47, No resource, which we can take to mean that the codec is not supported.
This is my attempt at a similar post to my SIP debugging. Here I have tried to
find the most useful debug commands I could for H.323 gatekeepers.
Debug commands used in H323
Debug cch323 h225 (debug h225 asn1 or debug h225 events is simply too
detailed to get anything useful at all!)
Debug h245 asn1
(this has some much more handy info)
You can do these same debugs on a Call-manager too by enabling the
appropriate traces (h245 detailed and h323 detailed)