scope:

This Recommendation describes the means by which audio, video, data, and control are associated, coded, and packetized for transport between H.323 equipment on a packet-based network. This includes the use of an H.323 gateway, which in turn may be connected to H.320, H.324, or H.310/H.321 terminals on N-ISDN, GSTN, or B-ISDN respectively. The equipment descriptions and procedures are described in ITU-T Rec. H.323 while this Recommendation covers protocols and message formats. Communication via an H.323 gateway to an H.322 gateway for guaranteed Quality of Service (QoS) LANs and thus to H.322 endpoints is also possible.

This Recommendation is intended to operate over a variety of different packet-based networks, including IEEE 802.3, Token Ring, etc. Thus, this Recommendation is defined as being above the Transport layer such as TCP/IP/UDP, SPX/IPX, etc. Specific profiles for particular transport protocol suites are included in Appendix IV. Thus, the scope of H.225.0 communication is between H.323 entities on the same packet-based network, using the same transport protocol. This packet-based network may be a single segment or ring, or it logically could be an enterprise data network comprising multiple packet-based networks bridged or routed to create one interconnected network. It should be emphasized that operation of H.323 terminals over the entire Internet, or even several connected packet-based networks may result in poor performance. The possible means by which quality of service might be assured on this packet-based network, or on the Internet in general is beyond the scope of this Recommendation. However, this Recommendation provides a means for the user of H.323 equipment to determine that quality problems are the result of packet-based network congestion, as well as procedures for corrective actions. It is also noted that the use of multiple H.323 gateways connected over the public ISDN network is a straightforward method for increasing quality of service.

ITU-T Rec. H.323 and this Recommendation are intended to extend H.320 and H.221 connections onto the non-guaranteed QoS packet-based network environment conferences. As such the primary conference model¹ is one with size in the range of a few participants to a few thousand, as opposed to large-scale broadcast operations, with strong admission control, and tight conference control.

This Recommendation makes use of (RTP/RTCP) Real-time Transport Protocol/Real-Time Transport Control Protocol for media stream packetization and synchronization for all underlying packet-based networks (see Annexes A, B and C). Please note that the usage of RTP/RTCP as specified in this Recommendation is not tied in any way to the usage of TCP/IP/UDP. This Recommendation assumes a call model where initial signalling on a non-RTP transport address is used for call establishment and capability negotiation (see ITU-T Recs H.323 and H.245), followed by the establishment of one or more RTP/RTCP connections. This Recommendation contains details on the usage of RTP/RTCP.

In ITU-T Rec. H.221, audio, video, data, and control are multiplexed into one or more synchronized physical SCN calls. On the packet-based network side of an H.323 call, none of these concepts apply. There is no need to carry from the SCN side the H.221 concept of a P × 64 kbit/s call, e.g., 2 by 64 kbit/s, 3 by 64 kbit/s, etc. Thus, on the packet-based network side, for example, there are only single "connection" calls with a maximum rate limited to 128 kbit/s, not 2 × 64 kbit/s fixed rate calls. Another example has single "connection" packet-based network calls with a maximum rate limited to 384 kbit/s interworking with 6 × 64 kbit/s on the SCN side². The primary rationale of this approach is to put complexity in the gateway rather than the terminal and to avoid extending onto the packet-based network features of H.320 that are tightly tied to ISDN unless this is necessary.

In general, H.323 terminals are not aware directly of the H.320 transfer rate while interworking through an H.323 gateway; instead, the gateway uses H.245 FlowControlCommand messages to limit the media rate on each logical channel in use to that allowed by the H.221 multiplex. The gateway may allow the packet-based network side video rates to substantially underrun the SCN side rates (or the reverse) though the usage of a rate reducing function and H.261 fill frames; the details of such operations are beyond the scope of ITU-T Rec. H.323 and this Recommendation. Note that the H.323 terminal is indirectly aware of the H.320 transfer rates via the video maximum bit rate fields in ITU-T Rec. H.245 and shall not transmit at rates that exceed these rates.

This Recommendation is designed so that, with an H.323 gateway, interoperability with H.320 (1990), H.320 (1993), and H.320 (1996) terminals is possible. However, some features of this Recommendation may be directed toward allowing enhanced operations with future versions of ITU-T Rec. H.320. It is also possible that the quality of service on the H.320 side may vary based on the features and capabilities of the H.323 gateway (see Figure 1).

The general approach of this Recommendation is to provide a means of synchronizing packets that make use of the underlying packet-based network/transport facilities. This Recommendation does not require all media and control to be mixed into a single stream, which is then packetized. The framing mechanisms of ITU-T Rec. H.221 are not utilized for the following reasons:

• Not using H.221 allows each media to receive different error treatment as appropriate.

• H.221 is relatively sensitive to the loss of random groups of bits; packetization allows greater robustness in the packet-based network environment.

• H.245 and H.225.0 call signalling messages can be sent over reliable links provided by the packet-based network.

• The flexibility and power of H.245 as compared to H.242.

¹ An optional broadcast-only conference model is under consideration; of necessity the broadcast model does not provide tight admissions or conference control.

² Note that video and data rates on the LAN side must match the video and data rates in the SCN side H.320 multiplex; the audio and control rates are not required to match. Stated another way one would normally expect that, using H.245 flow control, the LAN/SCN gateway will force the video and data rates to fit into the H.221 SCN multiplex. However, since audio may be transcoded in the gateway often, one will frequently find that the LAN audio rate and the SCN rate do not match. Also there should be no expectation that the H.221 bit rate for control (800 bit/s) will generally match the H.245 bit rate on the LAN side. Also note that the LAN rate may under-run the SCN rate for either/both video or/and data, but it cannot exceed the maximum amount that fits into the SCN side multiplex.