Skip to main content

Guidelines for Extending the RTP Control Protocol (RTCP)
RFC 5968

Document Type RFC - Informational (September 2010)
Authors Colin Perkins , Joerg Ott
Last updated 2015-10-14
RFC stream Internet Engineering Task Force (IETF)
Formats
Additional resources Mailing list discussion
IESG Responsible AD Robert Sparks
Send notices to (None)
RFC 5968
4.  Issues with RTCP Extensions

   Issues that have come up in the past with extensions to RTP and RTCP
   include (but are probably not limited to) the following:

   o  Defining RTP or RTCP extensions only or primarily for unicast two-
      party sessions.  RTP is inherently a group communication protocol,
      even when operating on a unicast connection.  Extensions may
      become useful in the future well outside their originally intended
      area of application, and should consider this.  Stating that
      something works for unicast only is not acceptable, particularly
      since various flavours of multicast have become relevant again,
      and as middleboxes such as repair servers, mixers, and RTCP-
      supporting Multipoint Control Units (MCUs) [RFC5117] become more
      widely used.

   o  Assuming reliable (instant) state synchronisation.  RTCP reports
      are sent irregularly and may be lost.  Hence, there may be a
      significant time lag (several seconds) between intending to send a
      state update to the RTP peer(s) and the packet being received; in
      some cases, the packet may not be received at all.

   o  Requiring reliable delivery of RTCP reports.  While reliability
      can be implemented on top of RTCP using acknowledgements, this
      will come at the cost of significant additional delay, which may
      defeat the purpose of providing the feedback in the first place.
      Moreover, for scalability reasons due to the group-based nature of
      RTCP, these ACKs need to be adaptively rate limited or targeted to
      a subgroup or individual entity to avoid implosion as group sizes
      increase.  RTCP is not intended or suitable for use as a reliable
      control channel.

   o  Issuing commands, rather than giving hints.  RTCP is about
      reporting observations -- in a best-effort manner -- between RTP
      entities.  Causing actions on the remote side requires some form
      of reliability (see above), and adherence cannot be verified.

   o  Expanding RTCP reporting, to use it as a network management tool.
      RTCP is sensitive to the size of RTCP reports as the latter
      determines the mean reporting interval given a certain bitrate
      share for RTCP (yet, RTCP may also be used to report information
      that has fine-grained temporal characteristics, if summarisation
      or data reduction by the endpoint would lose essential
      resolution).  The information going into RTCP reports should
      primarily target the peer(s) (and thus include information that
      can be meaningfully reacted upon); nevertheless, such reports may

Ott & Perkins                 Informational                     [Page 9]
RFC 5968             Guidelines for RTCP Extensions       September 2010

      provide useful information to augment other network management
      tools.  Gathering and reporting statistics beyond this is not an
      RTCP task and should be addressed by out-of-band protocols.

   o  Creating serious complexity.  Related to the previous item, RTCP
      reports that convey all kinds of data need to gather and
      calculate/infer this information to begin with (which requires
      very precise specifications).  Given that it already seems to be
      difficult to even implement baseline RTCP, any added complexity
      can only discourage implementers, may lead to buggy
      implementations (in which case the reports do not serve their
      intended purpose), and hinder interoperability.

   o  Introducing architectural issues.  Extensions are written without
      considering the architectural concepts of RTP.  For example,
      point-to-point communication is assumed, yet third-party monitors
      are expected to listen in.  Besides being a bad idea to rely on
      eavesdropping entities on the path, this is obviously not possible
      if Secure RTP (SRTP) is being used with encrypted SRTCP packets.

   This list is surely not exhaustive.  Also, the authors do not claim
   that the suggested extensions (even if using acknowledgements) would
   not serve a legitimate purpose.  We rather want to draw attention to
   the fact that the same results may be achievable in a way that is
   architecturally cleaner and conceptually more RTP/RTCP-compliant.
   The following section contains a first attempt to provide some
   guidelines on what to consider when thinking about extensions to RTP
   and RTCP.

5.  Guidelines

   Designing RTCP extensions requires consideration of a number of
   issues, as well as in-depth understanding of the operation of RTP
   mechanisms.  While it is expected that there are many aspects not yet
   covered by RTCP reporting and operation, quite a bit of functionality
   is readily available for use.  Other mechanisms should probably never
   become part of the RTP family of specifications, despite the
   existence of their equivalents in other environments.  In the
   following, we provide some guidance to consider when (and before!)
   developing an extension to RTCP.

   We begin with a short checklist concerning the applicability of RTCP
   in the first place:

   o  Check what can be done with the existing mechanisms, exploiting
      the information that is already available in RTCP.  Is the need
      for an extension only perceived (e.g., due to lazy implementers,
      or artificial constraints in endpoints), or is the function or

Ott & Perkins                 Informational                    [Page 10]
RFC 5968             Guidelines for RTCP Extensions       September 2010

      data really not available (or derivable from existing reports)?
      It is worthwhile remembering that redundant information supplied
      by a protocol runs the risk of being inconsistent at some point,
      and various implementations may handle such situations differently
      (e.g., give precedence to different values).  Similarly, there
      should be exactly one (well-specified) way of performing every
      function and operation of the protocol.

   o  Is the extension applicable to RTP entities running anywhere in
      the Internet, or is it a link- or environment-specific extension?
      In the latter cases, local extensions (e.g., header compression,
      or non-RTP protocols) may be preferable.  RTCP should not be used
      to carry information specific to a particular (access) link.

   o  Is the extension applicable in a group communication environment,
      or is it specific to point-to-point communications?  RTP and RTCP
      are inherently group communication protocols, and extensions must
      scale gracefully with increasing group sizes.

   From a conceptual viewpoint, the designer of every RTCP extension
   should ask -- and answer(!) -- at least the following questions:

   o  How will this new building block complement and work with the
      other components of RTCP?  Are all interactions fully specified?

   o  Will this extension work with all different profiles (e.g., the
      Secure RTP profile [RFC3711], and the extended RTP profile for
      RTCP-based feedback [RFC4585])?  Are any feature interactions
      expected?

   o  Should this extension be kept in-line with baseline RTP and its
      existing profiles, or does it deviate so much from the base RTP
      operation that an incompatible new profile must be defined?  Use
      and definition of incompatible profiles are strongly discouraged,
      but if they prove necessary, how do nodes using the different
      profiles interact?  What are the failure modes, and how is it
      ensured that the system fails in a safe manner?

   o  How does this extension interoperate with other nodes when the
      extension is not understood by the peer(s)?

   o  How will the extension deal with different networking conditions
      (e.g., how does performance degrade with increases in losses and
      latency, possibly across orders of magnitude)?

Ott & Perkins                 Informational                    [Page 11]
RFC 5968             Guidelines for RTCP Extensions       September 2010

   o  How will this extension work with group communication scenarios,
      such as multicast?  Will the extensions degrade gracefully with
      increasing group sizes?  What will be the impact on the RTCP
      report frequency and bitrate allocation?

   For the specific design, the following considerations should be taken
   into account (they're a mixture of common protocol design guidelines,
   and specifics for RTCP):

   o  First of all, if there is (and for RTCP this applies quite often)
      a mechanism from a different networking environment, don't try to
      directly recreate this mechanism in RTP/RTCP.  The Internet
      environment is extremely heterogeneous, and will often have
      drastically different properties and behaviour to other network
      environments.  Instead, ask what the actual semantics and the
      result required to be perceived by the application or the user
      are.  Then, design a mechanism that achieves this result in a way
      that is compatible with RTP/RTCP.  (And do not forget that every
      mechanism will break when no packets get through -- the Internet
      does not guarantee connectivity or performance.)

   o  Target re-usability of the specification.  That is, think broader
      than a specific use case, and try to solve the general problem in
      cases where it makes sense to do so.  Point solutions need a very
      good motivation to be dealt with in the IETF in the first place.
      This essentially suggests developing building blocks whenever
      possible, allowing them to be combined in different environments
      than initially considered.  Where possible, avoid mechanisms that
      are specific to particular payload formats, media types, link or
      network types, etc.

   o  For everything (packet format, value, procedure, timer, etc.)
      being defined, make sure that it is defined properly, so that
      independent interoperable implementation can be built.  It is not
      sufficient that you can implement the feature: it has to be
      implemented in several years by someone unfamiliar with the
      working group discussion and industry context.  Remember that
      fields need to be both generated and reacted upon, that mechanisms
      need to be implemented, etc., and that all of this increases the
      complexity of an implementation.  Features that are too complex
      won't get implemented (correctly) in the first place.

   o  Extensions defining new metrics and parameters should reference
      existing standards whenever possible, rather than try to invent
      something new and/or proprietary.

Ott & Perkins                 Informational                    [Page 12]
RFC 5968             Guidelines for RTCP Extensions       September 2010

   o  Remember that not every bit or every action must be represented or
      signalled explicitly.  It may be possible to infer the necessary
      pieces of information from other values or their evolution (a very
      prominent example is TCP congestion control).  As a result, it may
      be possible to de-couple bits on the wire from local actions and
      reduce the overhead.

   o  Particularly with media streams, reliability can often be "soft".
      Rather than implementing explicit acknowledgements, receipt of a
      hint may also be observed from the altered behaviour (e.g., the
      reception of a requested intra-frame, or changing the reference
      frame for video, changing the codec, etc.).  The semantics of
      messages should be idempotent so that the respective message may
      be sent repeatedly.  Requiring hard reliability does not scale
      with increasing group sizes, and does not degrade gracefully as
      network performance reduces.

   o  Choose the appropriate extension point.  Depending on the type of
      RTCP extension being developed, new data items can be transported
      in several different ways:

      *  A new RTCP Source Description (SDES) item is appropriate for
         transporting data that describes the source, or the user
         represented by the source, rather than the ongoing media
         transmission.  New SDES items may be registered to transport
         source description information of general interest (see
         [RFC3550], Section 15), or the PRIV item ([RFC3550],
         Section 6.5.8) may be used for proprietary extensions.

      *  A new RTCP XR block type is appropriate for transporting new
         metrics regarding media transmission or reception quality (see
         [RFC3611], Section 6.2).

      *  New RTP profiles may define a profile-specific extension to
         RTCP SR and/or RR packets, to give additional feedback (see
         [RFC3550], Section 6.4.3).  It is important to note that while
         extensions using this mechanism have low overhead, they are not
         backwards compatible with other profiles.  Where compatibility
         is needed, it's generally more appropriate to define a new RTCP
         XR block or a new RTCP packet type instead.

      *  New RTCP AVPF (Audio-Visual Profile with Feedback) transport-
         layer feedback messages should be used to transmit general-
         purpose feedback information that will be generated and
         processed by the RTP transport.  Examples include (negative)

Ott & Perkins                 Informational                    [Page 13]
RFC 5968             Guidelines for RTCP Extensions       September 2010

         acknowledgements for particular packets, or requests to limit
         the transmission rate.  This information is intended to be
         independent of the codec or application in use (see [RFC4585],
         Sections 6.2 and 9).

      *  New RTCP AVPF payload-specific feedback messages should be used
         to convey feedback information that is specific to a particular
         media codec, RTP payload format, or category of RTP payload
         formats.  Examples include video picture loss indication or
         reference picture selection, which are useful for many video
         codecs (see [RFC4585], Sections 6.3 and 9).

      *  New RTCP AVPF application layer feedback messages should be
         used to convey higher-level feedback, from one application to
         another, above the level of codecs or transport (see [RFC4585],
         Sections 6.4 and 9).

      *  A new RTCP application-defined, or APP, packet is appropriate
         for private use by applications that don't need to interoperate
         with others, or for experimentation before registering a new
         RTCP packet type ([RFC3550], Section 6.7).  It is not
         appropriate to define a new RTCP APP packet in a standards
         document: use one of the other extension points, or define a
         new RTCP packet type instead.

      *  Finally, new RTCP packet types may be registered with IANA if
         none of the other RTCP extension points are appropriate (see
         [RFC3550], Section 15).

   The RTP framework was designed following the principle of application
   level framing with integrated layer processing, proposed by Clark and
   Tennenhouse [ALF].  Effective use of RTP requires that extensions and
   implementations be designed and built following the same philosophy.
   That philosophy differs markedly from many previous systems in this
   space, and making effective use of RTP requires an understanding of
   those differences.

6.  Security Considerations

   This memo does not specify any new protocol mechanisms or procedures,
   and so raises no explicit security considerations.  When designing
   RTCP extensions, it is important to consider the following points:

Ott & Perkins                 Informational                    [Page 14]
RFC 5968             Guidelines for RTCP Extensions       September 2010

   o  Privacy: RTCP extensions, in particular new Source Description
      (SDES) items, can potentially reveal information considered to be
      sensitive by end users.  Extensions should carefully consider the
      uses to which information they release could be put, and should be
      designed to reveal the minimum amount of additional information
      needed for their correct operation.

   o  Congestion control: RTCP transmission timers have been carefully
      designed such that the total amount of traffic generated by RTCP
      is a small fraction of the media data rate.  One consequence of
      this is that the individual RTCP reporting interval scales with
      both the media data rate and the group size.  The RTCP timing
      algorithms have been shown to scale from two-party unicast
      sessions to groups with tens of thousands of participants, and to
      gracefully handle flash crowds and sudden departures [TimerRecon].
      Proposals that modify the RTCP timer algorithms must be careful to
      avoid congestion, potentially leading to denial of service, across
      the full range of environments where RTCP is used.

   o  Denial of service: RTCP extensions that change the location where
      feedback is sent must be carefully designed to prevent denial of
      service attacks against third-party nodes.  When such extensions
      are signalled, for example in the Session Description Protocol
      (SDP), this typically requires some form of authentication of the
      signalling messages (e.g., see the security considerations of
      [RFC5760]).

   The security considerations of the RTP specification [RFC3550] apply,
   along with any applicable profile (e.g., [RFC3551]).

7.  Acknowledgements

   This document has been motivated by many discussions in the AVT WG.
   The authors would like to acknowledge the active members in the group
   for providing the inspiration.

8.  References

8.1.  Normative References

   [RFC2198]      Perkins, C., Kouvelas, I., Hodson, O., Hardman, V.,
                  Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-
                  Parisis, "RTP Payload for Redundant Audio Data",
                  RFC 2198, September 1997.

   [RFC2326]      Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
                  Streaming Protocol (RTSP)", RFC 2326, April 1998.

Ott & Perkins                 Informational                    [Page 15]
RFC 5968             Guidelines for RTCP Extensions       September 2010

   [RFC3550]      Schulzrinne, H., Casner, S., Frederick, R., and V.
                  Jacobson, "RTP: A Transport Protocol for Real-Time
                  Applications", STD 64, RFC 3550, July 2003.

   [RFC3551]      Schulzrinne, H. and S. Casner, "RTP Profile for Audio
                  and Video Conferences with Minimal Control", STD 65,
                  RFC 3551, July 2003.

   [RFC3556]      Casner, S., "Session Description Protocol (SDP)
                  Bandwidth Modifiers for RTP Control Protocol (RTCP)
                  Bandwidth", RFC 3556, July 2003.

   [RFC3611]      Friedman, T., Caceres, R., and A. Clark, "RTP Control
                  Protocol Extended Reports (RTCP XR)", RFC 3611,
                  November 2003.

   [RFC3711]      Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
                  K. Norrman, "The Secure Real-time Transport Protocol
                  (SRTP)", RFC 3711, March 2004.

   [RFC4571]      Lazzaro, J., "Framing Real-time Transport Protocol
                  (RTP) and RTP Control Protocol (RTCP) Packets over
                  Connection-Oriented Transport", RFC 4571, July 2006.

   [RFC4585]      Ott, J., Wenger, S., Sato, N., Burmeister, C., and J.
                  Rey, "Extended RTP Profile for Real-time Transport
                  Control Protocol (RTCP)-Based Feedback (RTP/AVPF)",
                  RFC 4585, July 2006.

   [RFC4588]      Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
                  Hakenberg, "RTP Retransmission Payload Format",
                  RFC 4588, July 2006.

   [RFC5109]      Li, A., "RTP Payload Format for Generic Forward Error
                  Correction", RFC 5109, December 2007.

   [RFC5506]      Johansson, I. and M. Westerlund, "Support for Reduced-
                  Size Real-Time Transport Control Protocol (RTCP):
                  Opportunities and Consequences", RFC 5506, April 2009.

8.2.  Informative References

   [RFC1925]      Callon, R., "The Twelve Networking Truths", RFC 1925,
                  April 1996.

   [RFC5117]      Westerlund, M. and S. Wenger, "RTP Topologies",
                  RFC 5117, January 2008.

Ott & Perkins                 Informational                    [Page 16]
RFC 5968             Guidelines for RTCP Extensions       September 2010

   [RFC5760]      Ott, J., Chesterfield, J., and E. Schooler, "RTP
                  Control Protocol (RTCP) Extensions for Single-Source
                  Multicast Sessions with Unicast Feedback", RFC 5760,
                  February 2010.

   [RFC5761]      Perkins, C. and M. Westerlund, "Multiplexing RTP Data
                  and Control Packets on a Single Port", RFC 5761,
                  April 2010.

   [RFC5762]      Perkins, C., "RTP and the Datagram Congestion Control
                  Protocol (DCCP)", RFC 5762, April 2010.

   [ALF]          Clark, D. and D. Tennenhouse, "Architectural
                  Considerations for a New Generation of Protocols",
                  Proceedings of ACM SIGCOMM 1990, September 1990.

   [TimerRecon]   Schulzrinne, H. and J. Rosenberg, "Timer
                  Reconsideration for Enhanced RTP Scalability",
                  Proceedings of IEEE Infocom 1998, March 1998.

Authors' Addresses

   Joerg Ott
   Aalto University
   School of Science and Technology
   Otakaari 5 A
   Espoo, FIN  02150
   Finland

   EMail: jo@netlab.tkk.fi

   Colin Perkins
   University of Glasgow
   Department of Computing Science
   Glasgow  G12 8QQ
   United Kingdom

   EMail: csp@csperkins.org

Ott & Perkins                 Informational                    [Page 17]