Rex,

In H.323, you are required to implement _and use_ RTP and RTCP for audio and video. For example, you are required to send RR or SR RTCP packets. However, I do not believe an EP is required to actually use the information in the RTCP stream. At minimum, I would think an EP must extract the RTCP CNAME so that it can pass that info to the GK in IRR.perCallInfo.

Here is some relevant text:

6.1/H.225.0v4: "H.225.0 terminals shall be capable of sending audio and video using RTP via unreliable channels to minimize delay."

6.2.8.2/H.323v4: "If the logical channel is to carry a media type using RTP (audio or video), the openLogicalChannel message shall include the mediaControlChannel parameter containing the Transport Address for the reverse RTCP channel."

ibid: "If the logical channel is to carry a media type using RTP, the openLogicalChannelAck message shall include both the mediaChannel parameter containing the RTP Transport Address for the media channel and the mediaControlChannel parameter containing the Transport Address for the forward RTCP channel."

6.2/H.225.0v4: "When using RTCP, either RR or SR packets shall be sent periodically as described in Annex A."

Paul Long

ipDialog, Inc.

-----Original Message-----
From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@mailbag.cps.INTEL.COM]On Behalf Of Rex Coldren
Sent: Tuesday, May 08, 2001 12:40 PM
To: ITU-SG16@mailbag.cps.INTEL.COM
Subject: RTCP support in H.323

All,
   I'll be lazy and ask rather than looking through the ASN.1 to find it...
Is there support in H.323 for signaling to use RTCP?
   There is a current thread on the IETF AVT e-mail reflector where
talk is of making RTCP mandatory (i.e.-changing it from a SHOULD
to a MUST in the RTP specification). The last I heard was that the
MUST would apply to implementing RTCP, and not necessarily to
using it. Presumably the application level call signaling protocol can
be responsible for signaling whether RTCP was to be used.

   If an endpoint implemented RTCP it should at least benignly ignore
received RTCP reports and would not need to send any. So a given
operator could specify that RTCP not be signaled if it were not
practical in their network. Obvious examples would be wireless
networks and cable networks where there are access bandwidth
constraints.
Cheers,
Rex