4.2 H.323 Network SignalingH.323 is defined as a binary protocol, which allows for efficient message processing in network elements. The syntax of the protocol is defined in ASN.1 and uses the Packed Encoding Rules (PER) form of message encoding for efficient message encoding on the wire. Below is an overview of the various communication flows in H.323 systems.
4.2.1 H.225.0 Call SignalingOnce the address of the remote endpoint is resolved, the endpoint will use H.225.0 Call Signaling in order to establish communication with the remote entity. H.225.0 messages are:
-Setup and Setup acknowledge
-Call Proceeding
-Connect
-Alerting
-Information
-Release Complete
-Facility
-Progress
-Status and Status Inquiry
-Notify
- H.323 - Establishment H.323 Call
- h.323-establishment-call.png (4.18 KiB) เปิดดู 12650 ครั้ง
Figure 3 - Establishment of an H.323 call
In the simplest form, an H.323 call may be established as follows (figure 3):
In this example, the endpoint (EP) on the left initiated communication with the gateway on the right and the gateway connected the call with the called party. In reality, call flows are often more complex than the one shown, but most calls that utilize the Fast Connect procedures defined within H.323 can be established with as few as 2 or 3 messages. Endpoints must notify their gatekeeper (if gatekeepers are used) that they are in a call.
Once a call has concluded, a device will send a Release Complete message. Endpoints are then required to notify their gatekeeper (if gatekeepers are used) that the call has ended.
4.2.2 RAS SignalingEndpoints use the RAS protocol in order to communicate with a gatekeeper. Likewise, gatekeepers use RAS to communicate with peer gatekeepers. RAS is a fairly simple protocol composed of just a few messages. Namely:
-Gatekeeper request, reject, and confirm messages (GRx)
-Registration request, reject, and confirm messages (RRx)
-Unregister request, reject, and confirm messages (URx)
-Admission request, reject, and confirm messages (ARx)
-Bandwidth request, reject, and confirm message (BRx)
-Disengage request, reject, and confirm (DRx)
-Location request, reject, and confirm messages (LRx)
-Info request, ack, nack, and response (IRx)
-Nonstandard message
-Unknown message response
-Request in progress (RIP)
-Resource availability indication and confirm (RAx)
-Service control indication and response (SCx)
-Admission confirm sequence (ACS)
- Between 2 Endpoints and 2 Gatekeepers
- h.323-between-endpoints-and-gatekeeper.png (33.99 KiB) เปิดดู 12650 ครั้ง
Figure 4 - A high-level communication exchange between two endpoints (EP) and two gatekeepers (GK)
When an endpoint is powered on, it will generally send either a gatekeeper request (GRQ) message to "discover" gatekeepers that are willing to provide service or will send a registration request (RRQ) to a gatekeeper that is predefined in the system’s administrative setup. Gatekeepers will then respond with a gatekeeper confirm (GCF). If a GRQ has been sent the endpoint will then select a gatekeeper with which to register by sending a registration request (RRQ), to which the gatekeeper responds with a registration confirm (RCF). At this point, the endpoint is known to the network and can make and place calls.
When an endpoint wishes to place a call, it will send an admission request (ARQ) to the gatekeeper. The gatekeeper will then resolve the address (either locally, by consulting another gatekeeper, or by querying some other network service) and return the address of the remote endpoint in the admission confirm message (ACF). The endpoint can then place the call.
Upon receiving a call, a remote endpoint will also send an ARQ and receive an ACF in order to get permission to accept the incoming call. This is necessary, for example, to authenticate the calling device or to ensure that there is available bandwidth for the call.
Figure 4 depicts a high-level communication exchange between two endpoints (EP) and two gatekeepers (GK).
4.2.3 H.245 Call ControlOnce a call has initiated (but not necessarily fully connected) endpoints may initiate H.245 call control signaling in order to provide more extensive control over the conference. H.245 is a rather voluminous specification with many procedures that fully enable multipoint communication, though in practice most implementations only implement the minimum necessary in order to enable point-to-point voice and video communication.
H.245 provides capabilities such as capability negotiation, master/slave determination, opening and closing of "logical channels" (i.e., audio and video flows), flow control, and conference control. It has support for both unicast and multicast communication, allowing the size of a conference to theoretically grow without bound.
4.2.3.1 Capability NegotiationOf the functionality provided by H.245, capability negotiation is arguably the most important, as it enables devices to communicate without having prior knowledge of the capabilities of the remote entity. H.245 enables rich multimedia capabilities, including audio, video, text, and data communication. For transmission of audio, video, or text, H.323 devices utilize both ITU-defined codecs and codecs defined outside the ITU. Codecs that are widely implemented by H.323 equipment include:
- Video codecs: H.261, H.263, H.264
- Audio codecs: G.711, G.729, G.729a, G.723.1, G.726
- Text codecs: T.140
H.245 also enables real-time data conferencing capability through protocols like T.120. T.120-based applications generally operate in parallel with the H.323 system, but are integrated to provide the user with a seamless multimedia experience. T.120 provides such capabilities as application sharing T.128, electronic whiteboard T.126, file transfer T.127, and text chat T.134 within the context of the conference.
When an H.323 device initiates communication with a remote H.323 device and when H.245 communication is established between the two entities, the Terminal Capability Set (TCS) message is the first message transmitted to the other side.
4.2.3.2 Master/Slave DeterminationAfter sending a TCS message, H.323 entities (through H.245 exchanges) will attempt to determine which device is the "master" and which is the "slave." This process, referred to as Master/Slave Determination (MSD), is important, as the master in a call settles all "disputes" between the two devices. For example, if both endpoints attempt to open incompatible media flows, it is the master who takes the action to reject the incompatible flow.
4.2.3.3 Logical Channel SignalingOnce capabilities are exchanged and master/slave determination steps have completed, devices may then open "logical channels" or media flows. This is done by simply sending an Open Logical Channel (OLC) message and receiving an acknowledgement message. Upon receipt of the acknowledgement message, an endpoint may then transmit audio or video to the remote endpoint.
4.2.3.4 Fast Connect
- A Typical H.245 Exchange
- h.323-h245-exchange.png (10.39 KiB) เปิดดู 12650 ครั้ง
Figure 5 - A typical H.245 exchange
A typical H.245 exchange looks similar to figure 5:
After this exchange of messages, the two endpoints (EP) in this figure would be transmitting audio in each direction. The number of message exchanges is numerous, each has an important purpose, but nonetheless takes time.
For this reason, H.323 version 2 (published in 1998) introduced a concept called Fast Connect, which enables a device to establish bi-directional media flows as part of the H.225.0 call establishment procedures. With Fast Connect, it is possible to establish a call with bi-directional media flowing with no more than two messages, like in figure 3.
Fast Connect is widely supported in the industry. Even so, most devices still implement the complete H.245 exchange as shown above and performs that message exchange in parallel to other activities, so there is no noticeable delay to the calling or called party.