H.323 Overview

H.323 is an application-layer control protocol for establishing and terminating multimedia sessions with participants. H.322 can dynamically adjust and modify session attributes, such as required session bandwidth, media type (voice and video), encoding/decoding format of media, and support for broadcast.

H.323 uses the Client/Server model to establish calls through communication between the gateway and gatekeeper.

H.323, packet-based multimedia communications system, is an ITU-T standard that specifies the components, protocols, and procedures that provide multimedia communication services over packet networks that does not provide guaranteed quality of service (QoS), such as IP. It has long been used by traditional carriers and network device manufacturers in their VoIP solutions. Now, it is one of the standards for VoIP.

H.323 architecture

Figure:H-01 

An H.323 network consists of H.323 terminals, gateways, an optional gatekeeper, and multipoint control units (MCUs).

H.323 Terminals

An H.323 terminal is an endpoint in the network that provides for real-time, two-way communications with another H.323 terminal, gateway, or multipoint control unit (MCU). The communications consist of control, indications, audio, moving color video pictures, or data between the two terminals. A terminal may provide audio only; audio and data; audio and video; or audio, data, and video. The terminal can be a computer-based video conferencing system or other device.

A gatekeeper supports a broad variety of H.323 terminal implementations from many different vendors. These terminals must support the standard H.323 Registration, Admission, and Status (RAS) protocol to function with the gatekeeper.

H.323 Gateways

An H.323 gateway is an endpoint on the LAN that provides real-time communications between H.323 terminals on the LAN and other ITU terminals on a WAN or to other H.323 gateways.

Gateways allow H.323 terminals to communicate with devices that are running other protocols. They provide protocol conversion between the devices that are running different types of protocols.

H.323 Gatekeepers

An H.323 gatekeeper is an H.323 entity on the LAN that provides address translation and that controls access to the LAN for H.323 terminals, gateways, and MCUs.

Gatekeepers are optional nodes that manage endpoints in an H.323 network. The endpoints communicate with the gatekeeper using the RAS protocol.

Endpoints attempt to register with a gatekeeper on startup. When they wish to communicate with another endpoint, they request admission to initiate a call using a symbolic alias for the endpoint, such as an E.164 address or an e-mail address. If the gatekeeper decides that the call can proceed, it returns a destination IP address to the originating endpoint. This IP address may not be the actual address of the destination endpoint, but it may be an intermediate address, such as the address of a proxy or a gatekeeper that routes call signaling.

Multipoint Control Unit

A multipoint control unit (MCU) is an endpoint on the network that allows three or more endpoints to participate in a multipoint conference. It controls and mixes video, audio, and data from endpoints to create a robust multimedia conference. An MCU may also connect two endpoints in a point-to-point conference, which may later develop into a multipoint conference.

H.323 stack

The H.323 stack is implemented at the application layer. The H.323 standard includes these protocols:

•  H.225.0 (including Q.931 and RAS protocol) and H.245  for signaling control

• G.711, G.729, G.723.1, and G.723.A for audio codec

• H.261 and H.263 for video codec

• T.120 series (including T.123, T.124, T.125, T.126, T.127, and T.324) for multimedia data transmission.

The real-time transport protocol (RTP) provides end-to-end real-time audio and video delivery services. Its functionality is enhanced through its control protocol, the RTP control protocol (RTCP). The primary function of RTCP is to provide feedback on the quality of data distribution, which allows the application system to accommodate to different network conditions and helps with fault location and diagnosis as well. These two protocols work together to ensure real-time voice transmission.

H.323 Call Processing

Discovery and Registration

Gateways and gatekeepers communicate using the Registration, Admission, and Status (RAS) protocol for discovery and registration. When endpoints are brought online, they first attempt to discover their gatekeeper. They discover their gatekeeper either by sending multicast a discovery request or by being configured with the address and, optionally, with the name of the gatekeeper and by sending a unicast discovery request.

Following successful discovery, each endpoint registers with the gatekeeper. The gatekeeper keeps track of which endpoints are online and available to receive calls.

Aliwei IOS Network Address Translation (NAT) supports all H.225 and H.245 message types, including those sent in the RAS protocol.

Call Setup

In a typical H.323 call setup scenario, after RAS messages are exchanged, H.225 setup messages are sent over a control channel. For example, both gateways are registered to the same gatekeeper, and the gatekeeper has chosen direct call signaling.

1. Gateway 1 (the calling gateway) initiates the admission request (ARQ) (1)/admission confirmation (ACF) (2) exchange with that gatekeeper.

2. The gatekeeper returns the call signaling channel address of Gateway 2 (the called gateway) in the ACF.

3. Gateway 1 then sends the setup (3) message to Gateway 2 using that transport address.

4. The setup is complete and the call is proceeding (4).

5. If Gateway 2 wishes to accept the call, it initiates an ARQ (5)/ACF (6) exchange with the gatekeeper.

6. The gatekeeper responses with ACF/ARJ (6).

7. Gateway 2 sends an alerting (7) message to Gateway 1. (If Gateway 2 receives an admission reject [ARJ] (6) message instead of an ACF message, it sends a release complete message to Gateway 1 instead of the alerting message.)

8. Gateway 2 responds with the connect (8) messege to Gateway 1

Figure:H-03 Both Gateways Registered to the Same Gatekeeper

Fast connect allows endpoints to establish media channels without waiting for a separate H.245 connection to be opened. This streamlines the number of messages that are exchanged and the amount of processing that must be done before endpoint connections can be established. A high-level view of the fast-connect procedures within the H.323 protocol follows:

1. The calling endpoint transmits a setup message containing the fastStart element that contains a sequence of encoded logical channel structures, each representing a different capability media type for both "send" and "receive" directions.

2. The called endpoint selects one or more of the media types offered by the calling endpoint for the sending and receiving directions and returns its selections in a fastStart element in any H.225 message up to and including connect. At this point, the called endpoint must be prepared to receive media along any of the channels it selected.

3. If H.245 procedures are needed and one or both of the endpoints do not support tunneling, a separate H.245 connection is used.

Fast connect is not explicitly configurable. All H.323 Version 2 VoIP endpoints are capable of initiating or accepting fast-connect calls. It is assumed that the gateway is capable of sending and receiving fast-connect procedures unless its corresponding dial peer has been configured for the Resource Reservation Protocol (RSVP). RSVP means the quality of service is set by the req-qos command to a value other than the default of best-effort. If the dial peer has been configured for RSVP, traditional "slow" connect procedures are followed, and the endpoint neither attempts to initiate fast connect nor responds to a fast-connect request from its peer.

A terminating endpoint can reject fast connect by simply omitting the fastStart element from all H.225 messages up to and including connect. In this case, normal H.245 procedures are followed and a separate H.245 TCP connection is established. So, if an endpoint does not support the fast-connect procedures, normal H.245 procedures are followed. In addition, certain conditions can cause a fast-connect call to fall back to normal H.245 procedures to complete the call.

Once a media connection has been opened (an audio path has been established), either endpoint has the option of switching to H.245 procedures (if they are needed) by using H.245 tunneling, whereby H.245 messages are encapsulated within the h245Control element of H.225 messages.

The dtmf-relay command is the only H.245-cognizant command that can initiate H.245-tunneling procedures from a fast-connect call. If H.245 tunneling is active on the call, switching to a separate H.245 connection is not supported.

An Aliwei terminating endpoint accepts a fast-connect request only if a pair of symmetric codecs (codecs that in both directions are equivalent or identical) can be selected from a list that has been offered. The originating endpoint is constrained only by what it can send through the codec (or voice class codec list) associated with the dial peer.

If the Aliwei originating endpoint has offered multiple codecs and the terminating endpoint selects a pair of asymmetric (mismatched) codecs, the originating endpoint initiates separate H.245 procedures to correct the asymmetric codec situation.

Fast connect is backward compatible with H.323 Version 1 configurations.

Call Termination

Either gateway may terminate a call in one of the following ways:

1. Discontinuing transmission of video at the end of a complete picture and then closes all logical channels for video.

2. Discontinuing transmission of data and then closes all logical channels for data.

3. Discontinuing transmission of voice and then closes all logical channels for voice.

4. Transmitting the H.245 endSessionCommand message in the H.245 control channel, indicating to the far end that it wishes to disconnect the call and then discontinues H.245 message transmission.

5. Waiting to receive the endSessionCommand message from the other gateway and then closes the H.245 control channel.

6. Sending a release complete message if the call signaling channel is open and the channel is closed.

7. Clearing the call by using the procedures defined below.

An endpoint receiving an endSessionCommand message without first having transmitted it carries out steps 1 and 7 above, except that in Step 5, the gateway waits for the endSessionCommand message from the first endpoint.

Terminating a call may not terminate a conference; a conference may be explicitly terminated using an H.245 message (dropConference). In this case, the gateways wait for the multipoint controller to terminate the calls as described.

In networks that contain a gatekeeper, the gatekeeper needs to know about the release of bandwidth. After performing steps 1 to 6 in the preceding section, each endpoint transmits an H.225 disengage request (DRQ) message (3) to its gatekeeper. The gatekeeper responds with the disengage confirm (DCF) message (4). After sending the DRQ message, the endpoints do not send further unsolicited information request response (IRR) messages that relate to that call to the gatekeeper. At this point, the call is terminated. The DRQ and DCF messages are sent on the RAS channel.

Aliwei IOS H.323 gateways will terminate a call if a TCP connection is closed while the call is in progress, or if a TCP connection error is detected when signaling message are sent or received.

Figure:H-04 Call Termination Direct Call Model