Cart
First of all let’s start proceedings with the disclaimer. H323 is an ITU protocol used to set up VOIP calls between two endpoints (conferences, gateways, terminals) sitting on the network. It is a very, very complex umbrella protocol with many sub-protocols from ITU and IETF referenced/defined. Not to mention the copious amounts of revisions that have taken place over the past 15 or so years. Needless to say, this blog is not going to be a full comprehensive guide to H323. It is however a streamlined summary (kind of a fast start guide :-) of what is most relevant based on the CCIE Voice Lab blueprint. We will focus in this blog on the H323 messaging involved in a call between UCM & UCME via a gatekeeper.
Calls between UCM & UCME via a gatekeeper
In reality, the fact that we are dealing with UCM and UCME is insignificant. You can treat this situation as a call between two H323 endpoints (gateways).
In this example let’s think of the UCM and UCME as Endpoint 1 and 2 respectively which are both registered to the same Gatekeeper. The same call flow is applicable when you consider Endpoint 1 & 2 as two UCM clusters, two UCME’s or two H323 gateways registered to the same Gatekeeper.
Endpoint 1 (calling endpoint) initiates the ARQ (1)/ACF (2) exchange with that Gatekeeper. Contained within the ARQ is a bandwidth request (16kbps and 128kbps for G729 and G711 respectively) and also a telephone (E164) number. The Gatekeeper shall return the Call Signaling Channel Transport Address of Endpoint 2 (called endpoint) in the ACF. You can use the debug gatekeeper main 10 to see how gatekeeper resolves the E164 number and debug gatekeeper call 10 to see the incoming bandwidth request from Endpoint 1. If either the called number cannot be resolved or the bandwidth request is unsuccessful, an ARJ message is returned to Endpoint 1.
Endpoint 1 then sends the Setup (3) message to Endpoint 2 using the Transport Address contained within the ACF message from Gatekeeper. If Endpoint 2 wishes to accept the call, it initiates an ARQ (5)/ACF (6) exchange with the Gatekeeper. It is possible that an ARJ (6) is received by Endpoint 2, in which case it sends Release Complete to Endpoint 1. Endpoint 2 responds with the Connect (8) message which contains an H.245 Control Channel Transport Address for use in H.245 signaling.
You are able to see a high level view of the RAS messaging using the debug ras command on the gatekeeper. The beauty of this command is that is shows the IP addresses of the source/destination in decimal format. In order to see the entire RAS message use the command debug h225 asn1 on the gatekeeper. This command produces A LOT of output and should be used sparingly! If it wise to increases the RRQ keepalive timer to avoid the RRQ/RCF keepalive mechanism from flooding the debug output on screen/log. You are able to do this within UCM from system > gatekeeper and from UCME using the command ras rrq ttl within voice service voip/h323. I suggest 5 minutes as a reasonable value. The debug h225 asn1 command could be used on Endpoint 1 and/or 2 which would in addition to the RAS messaging that particular endpoint exchanged with the gatekeeeper show you the H225 Call Signaling messaging (Setup, Call Proceeding, Alerting, Connect).
Location Request
If Endpoint 2 was registered to another Gatekeeper (Gatekeeper 2) then Gatekeeper 1 would contain a zone prefix to a remote zone which has been defined on Gatekeeper 2. Endpoint 1 (calling endpoint) sends an ARQ (1) to Gatekeeper 1. Gatekeeper 1 sends an LRQ (2) to locate called Endpoint 2. Gatekeeper 2 returns an LCF (3) with the Call Signaling Channel Transport Address of the Endpoint 2. This information is passed onto Endpoint 1 inside the ACF (4) message. Endpoint 1 would then send a Setup message to the Call Signaling Address of Endpoint 2 and the H225 messaging would continue in an identical manner in the previous example.
H245 Messaging
The H225/RAS messaging discussed up to now is responsible for finding the location of the called party. The called party will ring and the calling party will hear ringback. Once the call has been answered then a whole new messaging (H245) sequence is initiated. This H245 messaging is responsible select the appropriate codec/dtmf transport mechanism used for the call and the endpoints RTP/RTCP channels to be used for the media being sent between the endpoints.
There are three main phases of H245 messaging which you are able to see using the debug h245 asn1 command.
(1) TCS. The Terminal Capability Set Message is sent between the endpoints involved in the call to indicate the codecs, dtmf and other capabilities of each endpoint. Each TCS Message must be acknowledged by the other endpoint. If there are no overlapping capabilities then you will see the Terminal Set Reject Message.
(2) MSD. Master/Slave Determination is used to determine the codec since the TCS messages could have indicated multiple codecs supported. The Master will decide the codec and other capabilities to be used in the call. The Master is chosen based on Endpoint type (gateway > terminal), Endpoint capabilities (video & audio > audio only) and randomly (identical endpoints).
(3) OLC. Open Logical Channel messages are used to inform each endpoint of the RTP/RTCP ip address/port numbers.
There is one variation to the above H245 messaging sequence- H245 FastConnect. This was introduced in H323 v2 and solves the problem of having the H245 handshake once the call has answered. In a nutshell when Fast Connect is used the Fast Start Information Element is contained in the SETUP message- this Fast Start IE contains the TCS Message. This allows capabilities Exchange to occur before the call has answered thereby meaning that logical channels are opened quicker compared with H323 Slow Start. The Called Party acknowledges the TCS and sends it’s own TCS in the Connect Message.
Vik Malhi – CCIE#13890
Managing Partner / Instructor – IPexpert Inc
Tags: ccie voice, h323 call flow, h323 gate keeper
