H.323 Call Setup

After discovery, registration, and call placement are complete, the H.323 call moves into the call setup stage. At this stage, the gateways are communicating directly to set up the connection. An alternative is gatekeeper-routed call signaling, where all call setup messages traverse the gatekeeper. Figure 1 helps us conceptualize this process.

Figure 1: H.323 Call Setup

The call setup is based on the ITU-Q.931 (H.225 is a subset of Q.931), which provides a means to establish, maintain, and terminate network connections across an ISDN. This process comprises six distinct phases, as shown in Figure 1.

1. Gateway X sends an H.225 call-signaling setup message to Gateway Y to request a connection.

2. Gateway Y sends an H.225 message back to Gateway X, advising that it may proceed with the call.

3. Gateway Y sends an RAS message (ARQ) on the RAS channel to the gatekeeper to request permission to accept the call.

4. Gatekeeper confirms that the call can be accepted by sending a message (ACF) back to Gateway Y.

5. Gateway Y sends an H.225 message to Gateway X, alerting that the connection has been established.

6. Gateway Y sends an H.225 message to Gateway X, confirming call connection to establish the call.

Logical Channel Setup

After call setup, all communications travel over logical channels. The H.245 manages these logical channels. Multiple logical channels of varying types (video, audio, and data) are allowed for a single call.

The H.245 Logical Channel Signaling Entity (LCSE) opens a logical channel for each media stream. Channels may be unidirectional or bi-directional. Figure 2 helps us visualize how the H.323 utilizes virtual channels.

Figure 2: Media Channel Setup

The H.245 control channel is established between Gateway X and Gateway Y. Gateway X uses H.245 to identify its capabilities via a Terminal Capability Set (TCS) message to Gateway Y. The media channel setup flow is as follows:

1. Gateway X exchanges its capabilities with Gateway Y by sending an H.245 TCS message.

2. Gateway Y acknowledges Gateway X's capabilities by sending an H.245 TCS Acknowledge message.

3. Gateway Y exchanges its capabilities with Gateway X by sending an H.245 TCS message.

4. Gateway X acknowledges Gateway Y's capabilities by sending an H.245 TCS Acknowledge message.

5. Gateway X opens a media channel with Gateway Y by sending an H.245 Open Logical Channel (OLC) message and includes the transport address of the RTCP channel.

6. Gateway Y acknowledges the establishment of the logical channel with Gateway X by sending an H.245 OLC Acknowledge message, including:

   • RTP transport addresses (used to send the RTP media stream) allocated by Gateway Y

   • RTCP address previously received from Gateway X

7. Gateway Y opens a media channel with Gateway X by sending an H.245 OLC message and includes the transport address of the RTCP channel.

8. Gateway X acknowledges the establishment of the logical channel with Gateway Y by sending an H.245 OLC Acknowledge message and includes:

   • RTP transport addresses (used to send the RTP media stream) allocated by Gateway X

   • RTCP address previously received from Gateway Y

Figure 3 highlights this process:

Figure 3: Media Channel Setup Call Flow

Media Stream and Media Control Flows

RTP media streams are transported over UDP ports 16384 through 16384 + 4x (where x is the number of voice ports on the gateways). For example, a Cisco 3620 router with four E&M ports would use UDP ports 16384–16400 for RTP flows.

RTCP manages media streams in the H.323 call flow by supporting QoS feedback from receivers. The source may use this information to adapt encoding or buffering schemes. RTCP uses a dedicated logical channel for each RTP media stream. Figure 4 illustrates the steps in this stage of the H.323 call flow.

In the example shown in Figure 9.34, four actions are occurring:

1. Gateway X sends the RTP encapsulated media stream to Gateway Y.

2. Gateway Y sends the RTP encapsulated media stream back to Gateway X.

3. Gateway X sends the RTCP messages to Gateway Y.

4. Gateway Y sends the RTCP messages back to Gateway X.

Endpoints may seek changes in the amount of bandwidth initially requested and confirmed. The gatekeeper must be asked for bandwidth increases or decreases. Endpoints must comply with gatekeeper responses and requests. The bandwidth change flow is diagramed in Figure 5. This process consists of six stages:

Figure 5: Bandwidth Change Request.

1. The initiating gateway sends a bandwidth request (BRQ) to the gatekeeper to request the desired bandwidth.

2. The gatekeeper responds with a bandwidth confirmation (BCF) message for the requested bandwidth.

3. A logical channel is established between the two gateways with the specified bandwidth.

4. A BRQ is sent from the remote router to the gatekeeper to change the bandwidth of the connection.

5. The gatekeeper responds to the gateway with a BCF to confirm the new bandwidth.

6. The logical channel is re-established with the new bandwidth.

Call Termination

Call termination stops the media streams and closes the logical channels, and may be requested by any endpoint or gatekeeper. It ends the H.245 session, releases H.225/Q.931 connections, and provides disconnect confirmation to the gatekeeper via RAS. Figure 6 shows call termination flow and is described as follows:

Figure 6: Call Termination (H.245/H.225/Q.931/RAS)

1. Gateway Y initiates call termination by sending an H.245 End Session Command (ESC) message to Gateway X.

2. Gateway X releases the call endpoint and confirms with an H.245 ESC message to Gateway Y.

3. Gateway Y completes the call release by sending an H.245 Release Complete message to Gateway X.

4. Gateway X and Gateway Y disengage with the gatekeeper by sending a RAS DRQ message.

5. Gatekeeper disengages and confirms by sending DCF messages to both Gateway X and Gateway Y.

H.323 Endpoint-to-Endpoint Signaling

Assuming that endpoints (clients) know each other's IP addresses, the H.323 signaling is shown in Figure 7.

Figure 8: H.323 Endpoint-to-Endpoint Signaling