Rec. ITU-T H.225.0 (03/2022) 11
sequence). In some cases, the gateway may find that the SCN side mode change occurs more quickly
than the packet-based network side mode change, resulting in the possibility of the loss of audio
information. The gateway may adopt several approaches at the discretion of the manufacturer:
a) the gateway may transcode audio, thus hiding the SCN mode changes;
b) the gateway may simply throw away audio information; or
c) the gateway may operate as an H.231 MCU, thus gaining control over all SCN side mode
changes.
No general rule exists concerning whether H.245 or RTP procedures (see Annexes A, B and C) take
precedence; each conflict and its resolution is specifically mentioned in this Recommendation.
Note also that there is no fixed association between SSRCs and logical channels; Rec. ITU-T H.245
provides this association which may be used for audio/video synchronization.
In general, two types of conference modes of operation on the packet-based network side are possible:
distributed and centralized. It is also possible that different choices may be made for different media,
e.g., distributed audio/video and centralized data. Procedures for determining what sort of conference
to establish are in Rec. ITU-T H.323; the messages of this Recommendation are intended to support
all allowed combinations, noting that distributed control and data are for further study although
supported by the H.245 capability signalling.
6.2 Use of RTP/RTCP
The H.225.0 endpoint shall be capable of using separate TSAP IDs for audio and video and the
associated RTCP channels as described in Annexes A and B. Optionally, endpoints may choose to
use different packet-based network addresses for audio and video, but for each packet-based network
address the convention of Annexes A and B should be followed in the use of TSAP IDs. Using H.245
signalling, additional audio and video channels may be established if the terminal supports this
capability.
An optional capability to use a single transport address for both audio and video is for further study.
Unless an exception is specifically mentioned here, implementations shall follow those of RTP as
contained in Annex A unless modified by text in this Recommendation. Implementations shall follow
the RTP profile (see Annex B) only as specifically mentioned in this Recommendation.
RTP translators and mixers are not elements of the H.323 system, and any information about them in
Annexes A and B shall be regarded as informative. Note that both gateways and MCUs have some
aspects of both mixers and translators, and the information in Annexes A and B may be helpful in the
implementation of gateways and MCUs. However, MCUs are not mixers, and mixers are not MCUs.
Note that gateways, for example, on a packet-based network-to-packet-based network call via the
gateway may act as translators.
Version (V): Version 2 of RTP shall be used.
CSRC Count (CC): Use of the CSRC count in this Recommendation is optional. When not in use,
the value of CC shall be zero (0). The CSRC may be used by MCUs to provide information on
contributors to the audio sum when distributed audio processing is occurring. Note that there are no
capabilities associated with the ability to understand the CSRC count so the MCU/MC has no way of
knowing whether and how the terminal in the conference makes use of the information.
CNAME: In the simplest case of a point-to-point connection on the packet-based network, the SSRC
is used to identify an audio/video source from a terminal, and the streams are associated by a CNAME
as being supplied by the same endpoint as specified in Annex A.
When using RTCP, either RR or SR packets shall be sent periodically as described in Annex A. The
CNAME SDES message
shall be used. Other SDES messages (see Annex A) are optional, but shall
not be used for conference control or conference information when either H.245 and/or T.120 control