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 won’t 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 doesn’t 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

That’s 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 don’t 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)