RTCP support in H.323

Paul Long plong at IPDIALOG.COM
Wed May 9 17:59:25 EDT 2001


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 at mailbag.cps.INTEL.COM]On Behalf Of Rex Coldren
  Sent: Tuesday, May 08, 2001 12:40 PM
  To: ITU-SG16 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20010509/c553c6cb/attachment-0001.htm>


More information about the sg16-avd mailing list