doc: Add RFC documents

1 files changed, 2195 insertions, 0 deletions

diff --git a/doc/rfc/rfc8834.txt b/doc/rfc/rfc8834.txt
new file mode 100644
index 0000000..4e1ff9f
--- /dev/null
+++ b/doc/rfc/rfc8834.txt
@@ -0,0 +1,2195 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                        C. Perkins
+Request for Comments: 8834                         University of Glasgow
+Category: Standards Track                                  M. Westerlund
+ISSN: 2070-1721                                                 Ericsson
+                                                                  J. Ott
+                                             Technical University Munich
+                                                            January 2021
+
+
+                Media Transport and Use of RTP in WebRTC
+
+Abstract
+
+   The framework for Web Real-Time Communication (WebRTC) provides
+   support for direct interactive rich communication using audio, video,
+   text, collaboration, games, etc. between two peers' web browsers.
+   This memo describes the media transport aspects of the WebRTC
+   framework.  It specifies how the Real-time Transport Protocol (RTP)
+   is used in the WebRTC context and gives requirements for which RTP
+   features, profiles, and extensions need to be supported.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8834.
+
+Copyright Notice
+
+   Copyright (c) 2021 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Rationale
+   3.  Terminology
+   4.  WebRTC Use of RTP: Core Protocols
+     4.1.  RTP and RTCP
+     4.2.  Choice of the RTP Profile
+     4.3.  Choice of RTP Payload Formats
+     4.4.  Use of RTP Sessions
+     4.5.  RTP and RTCP Multiplexing
+     4.6.  Reduced Size RTCP
+     4.7.  Symmetric RTP/RTCP
+     4.8.  Choice of RTP Synchronization Source (SSRC)
+     4.9.  Generation of the RTCP Canonical Name (CNAME)
+     4.10. Handling of Leap Seconds
+   5.  WebRTC Use of RTP: Extensions
+     5.1.  Conferencing Extensions and Topologies
+       5.1.1.  Full Intra Request (FIR)
+       5.1.2.  Picture Loss Indication (PLI)
+       5.1.3.  Slice Loss Indication (SLI)
+       5.1.4.  Reference Picture Selection Indication (RPSI)
+       5.1.5.  Temporal-Spatial Trade-Off Request (TSTR)
+       5.1.6.  Temporary Maximum Media Stream Bit Rate Request (TMMBR)
+     5.2.  Header Extensions
+       5.2.1.  Rapid Synchronization
+       5.2.2.  Client-to-Mixer Audio Level
+       5.2.3.  Mixer-to-Client Audio Level
+       5.2.4.  Media Stream Identification
+       5.2.5.  Coordination of Video Orientation
+   6.  WebRTC Use of RTP: Improving Transport Robustness
+     6.1.  Negative Acknowledgements and RTP Retransmission
+     6.2.  Forward Error Correction (FEC)
+   7.  WebRTC Use of RTP: Rate Control and Media Adaptation
+     7.1.  Boundary Conditions and Circuit Breakers
+     7.2.  Congestion Control Interoperability and Legacy Systems
+   8.  WebRTC Use of RTP: Performance Monitoring
+   9.  WebRTC Use of RTP: Future Extensions
+   10. Signaling Considerations
+   11. WebRTC API Considerations
+   12. RTP Implementation Considerations
+     12.1.  Configuration and Use of RTP Sessions
+       12.1.1.  Use of Multiple Media Sources within an RTP Session
+       12.1.2.  Use of Multiple RTP Sessions
+       12.1.3.  Differentiated Treatment of RTP Streams
+     12.2.  Media Source, RTP Streams, and Participant Identification
+       12.2.1.  Media Source Identification
+       12.2.2.  SSRC Collision Detection
+       12.2.3.  Media Synchronization Context
+   13. Security Considerations
+   14. IANA Considerations
+   15. References
+     15.1.  Normative References
+     15.2.  Informative References
+   Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   The Real-time Transport Protocol (RTP) [RFC3550] provides a framework
+   for delivery of audio and video teleconferencing data and other real-
+   time media applications.  Previous work has defined the RTP protocol,
+   along with numerous profiles, payload formats, and other extensions.
+   When combined with appropriate signaling, these form the basis for
+   many teleconferencing systems.
+
+   The Web Real-Time Communication (WebRTC) framework provides the
+   protocol building blocks to support direct, interactive, real-time
+   communication using audio, video, collaboration, games, etc. between
+   two peers' web browsers.  This memo describes how the RTP framework
+   is to be used in the WebRTC context.  It proposes a baseline set of
+   RTP features that are to be implemented by all WebRTC endpoints,
+   along with suggested extensions for enhanced functionality.
+
+   This memo specifies a protocol intended for use within the WebRTC
+   framework but is not restricted to that context.  An overview of the
+   WebRTC framework is given in [RFC8825].
+
+   The structure of this memo is as follows.  Section 2 outlines our
+   rationale for preparing this memo and choosing these RTP features.
+   Section 3 defines terminology.  Requirements for core RTP protocols
+   are described in Section 4, and suggested RTP extensions are
+   described in Section 5.  Section 6 outlines mechanisms that can
+   increase robustness to network problems, while Section 7 describes
+   congestion control and rate adaptation mechanisms.  The discussion of
+   mandated RTP mechanisms concludes in Section 8 with a review of
+   performance monitoring and network management tools.  Section 9 gives
+   some guidelines for future incorporation of other RTP and RTP Control
+   Protocol (RTCP) extensions into this framework.  Section 10 describes
+   requirements placed on the signaling channel.  Section 11 discusses
+   the relationship between features of the RTP framework and the WebRTC
+   application programming interface (API), and Section 12 discusses RTP
+   implementation considerations.  The memo concludes with security
+   considerations (Section 13) and IANA considerations (Section 14).
+
+2.  Rationale
+
+   The RTP framework comprises the RTP data transfer protocol, the RTP
+   control protocol, and numerous RTP payload formats, profiles, and
+   extensions.  This range of add-ons has allowed RTP to meet various
+   needs that were not envisaged by the original protocol designers and
+   support many new media encodings, but it raises the question of what
+   extensions are to be supported by new implementations.  The
+   development of the WebRTC framework provides an opportunity to review
+   the available RTP features and extensions and define a common
+   baseline RTP feature set for all WebRTC endpoints.  This builds on
+   the past 20 years of RTP development to mandate the use of extensions
+   that have shown widespread utility, while still remaining compatible
+   with the wide installed base of RTP implementations where possible.
+
+   RTP and RTCP extensions that are not discussed in this document can
+   be implemented by WebRTC endpoints if they are beneficial for new use
+   cases.  However, they are not necessary to address the WebRTC use
+   cases and requirements identified in [RFC7478].
+
+   While the baseline set of RTP features and extensions defined in this
+   memo is targeted at the requirements of the WebRTC framework, it is
+   expected to be broadly useful for other conferencing-related uses of
+   RTP.  In particular, it is likely that this set of RTP features and
+   extensions will be appropriate for other desktop or mobile video-
+   conferencing systems, or for room-based high-quality telepresence
+   applications.
+
+3.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in BCP
+   14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.  Lower- or mixed-case uses of these key
+   words are not to be interpreted as carrying special significance in
+   this memo.
+
+   We define the following additional terms:
+
+   WebRTC MediaStream:  The MediaStream concept defined by the W3C in
+      the WebRTC API [W3C.WD-mediacapture-streams].  A MediaStream
+      consists of zero or more MediaStreamTracks.
+
+   MediaStreamTrack:  Part of the MediaStream concept defined by the W3C
+      in the WebRTC API [W3C.WD-mediacapture-streams].  A
+      MediaStreamTrack is an individual stream of media from any type of
+      media source such as a microphone or a camera, but conceptual
+      sources such as an audio mix or a video composition are also
+      possible.
+
+   Transport-layer flow:  A unidirectional flow of transport packets
+      that are identified by a particular 5-tuple of source IP address,
+      source port, destination IP address, destination port, and
+      transport protocol.
+
+   Bidirectional transport-layer flow:  A bidirectional transport-layer
+      flow is a transport-layer flow that is symmetric.  That is, the
+      transport-layer flow in the reverse direction has a 5-tuple where
+      the source and destination address and ports are swapped compared
+      to the forward path transport-layer flow, and the transport
+      protocol is the same.
+
+   This document uses the terminology from [RFC7656] and [RFC8825].
+   Other terms are used according to their definitions from the RTP
+   specification [RFC3550].  In particular, note the following
+   frequently used terms: RTP stream, RTP session, and endpoint.
+
+4.  WebRTC Use of RTP: Core Protocols
+
+   The following sections describe the core features of RTP and RTCP
+   that need to be implemented, along with the mandated RTP profiles.
+   Also described are the core extensions providing essential features
+   that all WebRTC endpoints need to implement to function effectively
+   on today's networks.
+
+4.1.  RTP and RTCP
+
+   The Real-time Transport Protocol (RTP) [RFC3550] is REQUIRED to be
+   implemented as the media transport protocol for WebRTC.  RTP itself
+   comprises two parts: the RTP data transfer protocol and the RTP
+   Control Protocol (RTCP).  RTCP is a fundamental and integral part of
+   RTP and MUST be implemented and used in all WebRTC endpoints.
+
+   The following RTP and RTCP features are sometimes omitted in limited-
+   functionality implementations of RTP, but they are REQUIRED in all
+   WebRTC endpoints:
+
+   *  Support for use of multiple simultaneous synchronization source
+      (SSRC) values in a single RTP session, including support for RTP
+      endpoints that send many SSRC values simultaneously, following
+      [RFC3550] and [RFC8108].  The RTCP optimizations for multi-SSRC
+      sessions defined in [RFC8861] MAY be supported; if supported, the
+      usage MUST be signaled.
+
+   *  Random choice of SSRC on joining a session; collision detection
+      and resolution for SSRC values (see also Section 4.8).
+
+   *  Support for reception of RTP data packets containing contributing
+      source (CSRC) lists, as generated by RTP mixers, and RTCP packets
+      relating to CSRCs.
+
+   *  Sending correct synchronization information in the RTCP Sender
+      Reports, to allow receivers to implement lip synchronization; see
+      Section 5.2.1 regarding support for the rapid RTP synchronization
+      extensions.
+
+   *  Support for multiple synchronization contexts.  Participants that
+      send multiple simultaneous RTP packet streams SHOULD do so as part
+      of a single synchronization context, using a single RTCP CNAME for
+      all streams and allowing receivers to play the streams out in a
+      synchronized manner.  For compatibility with potential future
+      versions of this specification, or for interoperability with non-
+      WebRTC devices through a gateway, receivers MUST support multiple
+      synchronization contexts, indicated by the use of multiple RTCP
+      CNAMEs in an RTP session.  This specification mandates the usage
+      of a single CNAME when sending RTP streams in some circumstances;
+      see Section 4.9.
+
+   *  Support for sending and receiving RTCP Sender Report (SR),
+      Receiver Report (RR), Source Description (SDES), and BYE packet
+      types.  Note that support for other RTCP packet types is OPTIONAL
+      unless mandated by other parts of this specification.  Note that
+      additional RTCP packet types are used by the RTP/SAVPF profile
+      (Section 4.2) and the other RTCP extensions (Section 5).  WebRTC
+      endpoints that implement the Session Description Protocol (SDP)
+      bundle negotiation extension will use the SDP Grouping Framework
+      "mid" attribute to identify media streams.  Such endpoints MUST
+      implement the RTCP SDES media identification (MID) item described
+      in [RFC8843].
+
+   *  Support for multiple endpoints in a single RTP session, and for
+      scaling the RTCP transmission interval according to the number of
+      participants in the session; support for randomized RTCP
+      transmission intervals to avoid synchronization of RTCP reports;
+      support for RTCP timer reconsideration (Section 6.3.6 of
+      [RFC3550]) and reverse reconsideration (Section 6.3.4 of
+      [RFC3550]).
+
+   *  Support for configuring the RTCP bandwidth as a fraction of the
+      media bandwidth, and for configuring the fraction of the RTCP
+      bandwidth allocated to senders -- e.g., using the SDP "b=" line
+      [RFC4566] [RFC3556].
+
+   *  Support for the reduced minimum RTCP reporting interval described
+      in Section 6.2 of [RFC3550].  When using the reduced minimum RTCP
+      reporting interval, the fixed (nonreduced) minimum interval MUST
+      be used when calculating the participant timeout interval (see
+      Sections 6.2 and 6.3.5 of [RFC3550]).  The delay before sending
+      the initial compound RTCP packet can be set to zero (see
+      Section 6.2 of [RFC3550] as updated by [RFC8108]).
+
+   *  Support for discontinuous transmission.  RTP allows endpoints to
+      pause and resume transmission at any time.  When resuming, the RTP
+      sequence number will increase by one, as usual, while the increase
+      in the RTP timestamp value will depend on the duration of the
+      pause.  Discontinuous transmission is most commonly used with some
+      audio payload formats, but it is not audio specific and can be
+      used with any RTP payload format.
+
+   *  Ignore unknown RTCP packet types and RTP header extensions.  This
+      is to ensure robust handling of future extensions, middlebox
+      behaviors, etc., that can result in receiving RTP header
+      extensions or RTCP packet types that were not signaled.  If a
+      compound RTCP packet that contains a mixture of known and unknown
+      RTCP packet types is received, the known packet types need to be
+      processed as usual, with only the unknown packet types being
+      discarded.
+
+   It is known that a significant number of legacy RTP implementations,
+   especially those targeted at systems with only Voice over IP (VoIP),
+   do not support all of the above features and in some cases do not
+   support RTCP at all.  Implementers are advised to consider the
+   requirements for graceful degradation when interoperating with legacy
+   implementations.
+
+   Other implementation considerations are discussed in Section 12.
+
+4.2.  Choice of the RTP Profile
+
+   The complete specification of RTP for a particular application domain
+   requires the choice of an RTP profile.  For WebRTC use, the extended
+   secure RTP profile for RTCP-based feedback (RTP/SAVPF) [RFC5124], as
+   extended by [RFC7007], MUST be implemented.  The RTP/SAVPF profile is
+   the combination of the basic RTP/AVP profile [RFC3551], the RTP
+   profile for RTCP-based feedback (RTP/AVPF) [RFC4585], and the secure
+   RTP profile (RTP/SAVP) [RFC3711].
+
+   The RTCP-based feedback extensions [RFC4585] are needed for the
+   improved RTCP timer model.  This allows more flexible transmission of
+   RTCP packets in response to events, rather than strictly according to
+   bandwidth, and is vital for being able to report congestion signals
+   as well as media events.  These extensions also allow saving RTCP
+   bandwidth, and an endpoint will commonly only use the full RTCP
+   bandwidth allocation if there are many events that require feedback.
+   The timer rules are also needed to make use of the RTP conferencing
+   extensions discussed in Section 5.1.
+
+      |  Note: The enhanced RTCP timer model defined in the RTP/AVPF
+      |  profile is backwards compatible with legacy systems that
+      |  implement only the RTP/AVP or RTP/SAVP profile, given some
+      |  constraints on parameter configuration such as the RTCP
+      |  bandwidth value and "trr-int".  The most important factor for
+      |  interworking with RTP/(S)AVP endpoints via a gateway is to set
+      |  the "trr-int" parameter to a value representing 4 seconds; see
+      |  Section 7.1.3 of [RFC8108].
+
+   The secure RTP (SRTP) profile extensions [RFC3711] are needed to
+   provide media encryption, integrity protection, replay protection,
+   and a limited form of source authentication.  WebRTC endpoints MUST
+   NOT send packets using the basic RTP/AVP profile or the RTP/AVPF
+   profile; they MUST employ the full RTP/SAVPF profile to protect all
+   RTP and RTCP packets that are generated.  In other words,
+   implementations MUST use SRTP and Secure RTCP (SRTCP).  The RTP/SAVPF
+   profile MUST be configured using the cipher suites, DTLS-SRTP
+   protection profiles, keying mechanisms, and other parameters
+   described in [RFC8827].
+
+4.3.  Choice of RTP Payload Formats
+
+   Mandatory-to-implement audio codecs and RTP payload formats for
+   WebRTC endpoints are defined in [RFC7874].  Mandatory-to-implement
+   video codecs and RTP payload formats for WebRTC endpoints are defined
+   in [RFC7742].  WebRTC endpoints MAY additionally implement any other
+   codec for which an RTP payload format and associated signaling has
+   been defined.
+
+   WebRTC endpoints cannot assume that the other participants in an RTP
+   session understand any RTP payload format, no matter how common.  The
+   mapping between RTP payload type numbers and specific configurations
+   of particular RTP payload formats MUST be agreed before those payload
+   types/formats can be used.  In an SDP context, this can be done using
+   the "a=rtpmap:" and "a=fmtp:" attributes associated with an "m="
+   line, along with any other SDP attributes needed to configure the RTP
+   payload format.
+
+   Endpoints can signal support for multiple RTP payload formats or
+   multiple configurations of a single RTP payload format, as long as
+   each unique RTP payload format configuration uses a different RTP
+   payload type number.  As outlined in Section 4.8, the RTP payload
+   type number is sometimes used to associate an RTP packet stream with
+   a signaling context.  This association is possible provided unique
+   RTP payload type numbers are used in each context.  For example, an
+   RTP packet stream can be associated with an SDP "m=" line by
+   comparing the RTP payload type numbers used by the RTP packet stream
+   with payload types signaled in the "a=rtpmap:" lines in the media
+   sections of the SDP.  This leads to the following considerations:
+
+      If RTP packet streams are being associated with signaling contexts
+      based on the RTP payload type, then the assignment of RTP payload
+      type numbers MUST be unique across signaling contexts.
+
+      If the same RTP payload format configuration is used in multiple
+      contexts, then a different RTP payload type number has to be
+      assigned in each context to ensure uniqueness.
+
+      If the RTP payload type number is not being used to associate RTP
+      packet streams with a signaling context, then the same RTP payload
+      type number can be used to indicate the exact same RTP payload
+      format configuration in multiple contexts.
+
+   A single RTP payload type number MUST NOT be assigned to different
+   RTP payload formats, or different configurations of the same RTP
+   payload format, within a single RTP session (note that the "m=" lines
+   in an SDP BUNDLE group [RFC8843] form a single RTP session).
+
+   An endpoint that has signaled support for multiple RTP payload
+   formats MUST be able to accept data in any of those payload formats
+   at any time, unless it has previously signaled limitations on its
+   decoding capability.  This requirement is constrained if several
+   types of media (e.g., audio and video) are sent in the same RTP
+   session.  In such a case, a source (SSRC) is restricted to switching
+   only between the RTP payload formats signaled for the type of media
+   that is being sent by that source; see Section 4.4.  To support rapid
+   rate adaptation by changing codecs, RTP does not require advance
+   signaling for changes between RTP payload formats used by a single
+   SSRC that were signaled during session setup.
+
+   If performing changes between two RTP payload types that use
+   different RTP clock rates, an RTP sender MUST follow the
+   recommendations in Section 4.1 of [RFC7160].  RTP receivers MUST
+   follow the recommendations in Section 4.3 of [RFC7160] in order to
+   support sources that switch between clock rates in an RTP session.
+   These recommendations for receivers are backwards compatible with the
+   case where senders use only a single clock rate.
+
+4.4.  Use of RTP Sessions
+
+   An association amongst a set of endpoints communicating using RTP is
+   known as an RTP session [RFC3550].  An endpoint can be involved in
+   several RTP sessions at the same time.  In a multimedia session, each
+   type of media has typically been carried in a separate RTP session
+   (e.g., using one RTP session for the audio and a separate RTP session
+   using a different transport-layer flow for the video).  WebRTC
+   endpoints are REQUIRED to implement support for multimedia sessions
+   in this way, separating each RTP session using different transport-
+   layer flows for compatibility with legacy systems (this is sometimes
+   called session multiplexing).
+
+   In modern-day networks, however, with the widespread use of network
+   address/port translators (NAT/NAPT) and firewalls, it is desirable to
+   reduce the number of transport-layer flows used by RTP applications.
+   This can be done by sending all the RTP packet streams in a single
+   RTP session, which will comprise a single transport-layer flow.  This
+   will prevent the use of some quality-of-service mechanisms, as
+   discussed in Section 12.1.3.  Implementations are therefore also
+   REQUIRED to support transport of all RTP packet streams, independent
+   of media type, in a single RTP session using a single transport-layer
+   flow, according to [RFC8860] (this is sometimes called SSRC
+   multiplexing).  If multiple types of media are to be used in a single
+   RTP session, all participants in that RTP session MUST agree to this
+   usage.  In an SDP context, the mechanisms described in [RFC8843] can
+   be used to signal such a bundle of RTP packet streams forming a
+   single RTP session.
+
+   Further discussion about the suitability of different RTP session
+   structures and multiplexing methods to different scenarios can be
+   found in [RFC8872].
+
+4.5.  RTP and RTCP Multiplexing
+
+   Historically, RTP and RTCP have been run on separate transport-layer
+   flows (e.g., two UDP ports for each RTP session, one for RTP and one
+   for RTCP).  With the increased use of Network Address/Port
+   Translation (NAT/NAPT), this has become problematic, since
+   maintaining multiple NAT bindings can be costly.  It also complicates
+   firewall administration, since multiple ports need to be opened to
+   allow RTP traffic.  To reduce these costs and session setup times,
+   implementations are REQUIRED to support multiplexing RTP data packets
+   and RTCP control packets on a single transport-layer flow [RFC5761].
+   Such RTP and RTCP multiplexing MUST be negotiated in the signaling
+   channel before it is used.  If SDP is used for signaling, this
+   negotiation MUST use the mechanism defined in [RFC5761].
+   Implementations can also support sending RTP and RTCP on separate
+   transport-layer flows, but this is OPTIONAL to implement.  If an
+   implementation does not support RTP and RTCP sent on separate
+   transport-layer flows, it MUST indicate that using the mechanism
+   defined in [RFC8858].
+
+   Note that the use of RTP and RTCP multiplexed onto a single
+   transport-layer flow ensures that there is occasional traffic sent on
+   that port, even if there is no active media traffic.  This can be
+   useful to keep NAT bindings alive [RFC6263].
+
+4.6.  Reduced Size RTCP
+
+   RTCP packets are usually sent as compound RTCP packets, and [RFC3550]
+   requires that those compound packets start with an SR or RR packet.
+   When using frequent RTCP feedback messages under the RTP/AVPF profile
+   [RFC4585], these statistics are not needed in every packet, and they
+   unnecessarily increase the mean RTCP packet size.  This can limit the
+   frequency at which RTCP packets can be sent within the RTCP bandwidth
+   share.
+
+   To avoid this problem, [RFC5506] specifies how to reduce the mean
+   RTCP message size and allow for more frequent feedback.  Frequent
+   feedback, in turn, is essential to make real-time applications
+   quickly aware of changing network conditions and to allow them to
+   adapt their transmission and encoding behavior.  Implementations MUST
+   support sending and receiving noncompound RTCP feedback packets
+   [RFC5506].  Use of noncompound RTCP packets MUST be negotiated using
+   the signaling channel.  If SDP is used for signaling, this
+   negotiation MUST use the attributes defined in [RFC5506].  For
+   backwards compatibility, implementations are also REQUIRED to support
+   the use of compound RTCP feedback packets if the remote endpoint does
+   not agree to the use of noncompound RTCP in the signaling exchange.
+
+4.7.  Symmetric RTP/RTCP
+
+   To ease traversal of NAT and firewall devices, implementations are
+   REQUIRED to implement and use symmetric RTP [RFC4961].  The reason
+   for using symmetric RTP is primarily to avoid issues with NATs and
+   firewalls by ensuring that the send and receive RTP packet streams,
+   as well as RTCP, are actually bidirectional transport-layer flows.
+   This will keep alive the NAT and firewall pinholes and help indicate
+   consent that the receive direction is a transport-layer flow the
+   intended recipient actually wants.  In addition, it saves resources,
+   specifically ports at the endpoints, but also in the network, because
+   the NAT mappings or firewall state is not unnecessarily bloated.  The
+   amount of per-flow QoS state kept in the network is also reduced.
+
+4.8.  Choice of RTP Synchronization Source (SSRC)
+
+   Implementations are REQUIRED to support signaled RTP synchronization
+   source (SSRC) identifiers.  If SDP is used, this MUST be done using
+   the "a=ssrc:" SDP attribute defined in Sections 4.1 and 5 of
+   [RFC5576] and the "previous-ssrc" source attribute defined in
+   Section 6.2 of [RFC5576]; other per-SSRC attributes defined in
+   [RFC5576] MAY be supported.
+
+   While support for signaled SSRC identifiers is mandated, their use in
+   an RTP session is OPTIONAL.  Implementations MUST be prepared to
+   accept RTP and RTCP packets using SSRCs that have not been explicitly
+   signaled ahead of time.  Implementations MUST support random SSRC
+   assignment and MUST support SSRC collision detection and resolution,
+   according to [RFC3550].  When using signaled SSRC values, collision
+   detection MUST be performed as described in Section 5 of [RFC5576].
+
+   It is often desirable to associate an RTP packet stream with a non-
+   RTP context.  For users of the WebRTC API, a mapping between SSRCs
+   and MediaStreamTracks is provided per Section 11.  For gateways or
+   other usages, it is possible to associate an RTP packet stream with
+   an "m=" line in a session description formatted using SDP.  If SSRCs
+   are signaled, this is straightforward (in SDP, the "a=ssrc:" line
+   will be at the media level, allowing a direct association with an
+   "m=" line).  If SSRCs are not signaled, the RTP payload type numbers
+   used in an RTP packet stream are often sufficient to associate that
+   packet stream with a signaling context.  For example, if RTP payload
+   type numbers are assigned as described in Section 4.3 of this memo,
+   the RTP payload types used by an RTP packet stream can be compared
+   with values in SDP "a=rtpmap:" lines, which are at the media level in
+   SDP and so map to an "m=" line.
+
+4.9.  Generation of the RTCP Canonical Name (CNAME)
+
+   The RTCP Canonical Name (CNAME) provides a persistent transport-level
+   identifier for an RTP endpoint.  While the SSRC identifier for an RTP
+   endpoint can change if a collision is detected or when the RTP
+   application is restarted, its RTCP CNAME is meant to stay unchanged
+   for the duration of an RTCPeerConnection [W3C.WebRTC], so that RTP
+   endpoints can be uniquely identified and associated with their RTP
+   packet streams within a set of related RTP sessions.
+
+   Each RTP endpoint MUST have at least one RTCP CNAME, and that RTCP
+   CNAME MUST be unique within the RTCPeerConnection.  RTCP CNAMEs
+   identify a particular synchronization context -- i.e., all SSRCs
+   associated with a single RTCP CNAME share a common reference clock.
+   If an endpoint has SSRCs that are associated with several
+   unsynchronized reference clocks, and hence different synchronization
+   contexts, it will need to use multiple RTCP CNAMEs, one for each
+   synchronization context.
+
+   Taking the discussion in Section 11 into account, a WebRTC endpoint
+   MUST NOT use more than one RTCP CNAME in the RTP sessions belonging
+   to a single RTCPeerConnection (that is, an RTCPeerConnection forms a
+   synchronization context).  RTP middleboxes MAY generate RTP packet
+   streams associated with more than one RTCP CNAME, to allow them to
+   avoid having to resynchronize media from multiple different endpoints
+   that are part of a multiparty RTP session.
+
+   The RTP specification [RFC3550] includes guidelines for choosing a
+   unique RTP CNAME, but these are not sufficient in the presence of NAT
+   devices.  In addition, long-term persistent identifiers can be
+   problematic from a privacy viewpoint (Section 13).  Accordingly, a
+   WebRTC endpoint MUST generate a new, unique, short-term persistent
+   RTCP CNAME for each RTCPeerConnection, following [RFC7022], with a
+   single exception; if explicitly requested at creation, an
+   RTCPeerConnection MAY use the same CNAME as an existing
+   RTCPeerConnection within their common same-origin context.
+
+   A WebRTC endpoint MUST support reception of any CNAME that matches
+   the syntax limitations specified by the RTP specification [RFC3550]
+   and cannot assume that any CNAME will be chosen according to the form
+   suggested above.
+
+4.10.  Handling of Leap Seconds
+
+   The guidelines given in [RFC7164] regarding handling of leap seconds
+   to limit their impact on RTP media play-out and synchronization
+   SHOULD be followed.
+
+5.  WebRTC Use of RTP: Extensions
+
+   There are a number of RTP extensions that are either needed to obtain
+   full functionality, or extremely useful to improve on the baseline
+   performance, in the WebRTC context.  One set of these extensions is
+   related to conferencing, while others are more generic in nature.
+   The following subsections describe the various RTP extensions
+   mandated or suggested for use within WebRTC.
+
+5.1.  Conferencing Extensions and Topologies
+
+   RTP is a protocol that inherently supports group communication.
+   Groups can be implemented by having each endpoint send its RTP packet
+   streams to an RTP middlebox that redistributes the traffic, by using
+   a mesh of unicast RTP packet streams between endpoints, or by using
+   an IP multicast group to distribute the RTP packet streams.  These
+   topologies can be implemented in a number of ways as discussed in
+   [RFC7667].
+
+   While the use of IP multicast groups is popular in IPTV systems, the
+   topologies based on RTP middleboxes are dominant in interactive
+   video-conferencing environments.  Topologies based on a mesh of
+   unicast transport-layer flows to create a common RTP session have not
+   seen widespread deployment to date.  Accordingly, WebRTC endpoints
+   are not expected to support topologies based on IP multicast groups
+   or mesh-based topologies, such as a point-to-multipoint mesh
+   configured as a single RTP session ("Topo-Mesh" in the terminology of
+   [RFC7667]).  However, a point-to-multipoint mesh constructed using
+   several RTP sessions, implemented in WebRTC using independent
+   RTCPeerConnections [W3C.WebRTC], can be expected to be used in WebRTC
+   and needs to be supported.
+
+   WebRTC endpoints implemented according to this memo are expected to
+   support all the topologies described in [RFC7667] where the RTP
+   endpoints send and receive unicast RTP packet streams to and from
+   some peer device, provided that peer can participate in performing
+   congestion control on the RTP packet streams.  The peer device could
+   be another RTP endpoint, or it could be an RTP middlebox that
+   redistributes the RTP packet streams to other RTP endpoints.  This
+   limitation means that some of the RTP middlebox-based topologies are
+   not suitable for use in WebRTC.  Specifically:
+
+   *  Video-switching Multipoint Control Units (MCUs) (Topo-Video-
+      switch-MCU) SHOULD NOT be used, since they make the use of RTCP
+      for congestion control and quality-of-service reports problematic
+      (see Section 3.8 of [RFC7667]).
+
+   *  The Relay-Transport Translator (Topo-PtM-Trn-Translator) topology
+      SHOULD NOT be used, because its safe use requires a congestion
+      control algorithm or RTP circuit breaker that handles point to
+      multipoint, which has not yet been standardized.
+
+   The following topology can be used, however it has some issues worth
+   noting:
+
+   *  Content-modifying MCUs with RTCP termination (Topo-RTCP-
+      terminating-MCU) MAY be used.  Note that in this RTP topology, RTP
+      loop detection and identification of active senders is the
+      responsibility of the WebRTC application; since the clients are
+      isolated from each other at the RTP layer, RTP cannot assist with
+      these functions (see Section 3.9 of [RFC7667]).
+
+   The RTP extensions described in Sections 5.1.1 to 5.1.6 are designed
+   to be used with centralized conferencing, where an RTP middlebox
+   (e.g., a conference bridge) receives a participant's RTP packet
+   streams and distributes them to the other participants.  These
+   extensions are not necessary for interoperability; an RTP endpoint
+   that does not implement these extensions will work correctly but
+   might offer poor performance.  Support for the listed extensions will
+   greatly improve the quality of experience; to provide a reasonable
+   baseline quality, some of these extensions are mandatory to be
+   supported by WebRTC endpoints.
+
+   The RTCP conferencing extensions are defined in "Extended RTP Profile
+   for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/
+   AVPF)" [RFC4585] and "Codec Control Messages in the RTP Audio-Visual
+   Profile with Feedback (AVPF)" [RFC5104]; they are fully usable by the
+   secure variant of this profile (RTP/SAVPF) [RFC5124].
+
+5.1.1.  Full Intra Request (FIR)
+
+   The Full Intra Request message is defined in Sections 3.5.1 and 4.3.1
+   of Codec Control Messages [RFC5104].  It is used to make the mixer
+   request a new Intra picture from a participant in the session.  This
+   is used when switching between sources to ensure that the receivers
+   can decode the video or other predictive media encoding with long
+   prediction chains.  WebRTC endpoints that are sending media MUST
+   understand and react to FIR feedback messages they receive, since
+   this greatly improves the user experience when using centralized
+   mixer-based conferencing.  Support for sending FIR messages is
+   OPTIONAL.
+
+5.1.2.  Picture Loss Indication (PLI)
+
+   The Picture Loss Indication message is defined in Section 6.3.1 of
+   the RTP/AVPF profile [RFC4585].  It is used by a receiver to tell the
+   sending encoder that it lost the decoder context and would like to
+   have it repaired somehow.  This is semantically different from the
+   Full Intra Request above, as there could be multiple ways to fulfill
+   the request.  WebRTC endpoints that are sending media MUST understand
+   and react to PLI feedback messages as a loss-tolerance mechanism.
+   Receivers MAY send PLI messages.
+
+5.1.3.  Slice Loss Indication (SLI)
+
+   The Slice Loss Indication message is defined in Section 6.3.2 of the
+   RTP/AVPF profile [RFC4585].  It is used by a receiver to tell the
+   encoder that it has detected the loss or corruption of one or more
+   consecutive macro blocks and would like to have these repaired
+   somehow.  It is RECOMMENDED that receivers generate SLI feedback
+   messages if slices are lost when using a codec that supports the
+   concept of macro blocks.  A sender that receives an SLI feedback
+   message SHOULD attempt to repair the lost slice(s).
+
+5.1.4.  Reference Picture Selection Indication (RPSI)
+
+   Reference Picture Selection Indication (RPSI) messages are defined in
+   Section 6.3.3 of the RTP/AVPF profile [RFC4585].  Some video-encoding
+   standards allow the use of older reference pictures than the most
+   recent one for predictive coding.  If such a codec is in use, and if
+   the encoder has learned that encoder-decoder synchronization has been
+   lost, then a known-as-correct reference picture can be used as a base
+   for future coding.  The RPSI message allows this to be signaled.
+   Receivers that detect that encoder-decoder synchronization has been
+   lost SHOULD generate an RPSI feedback message if the codec being used
+   supports reference-picture selection.  An RTP packet-stream sender
+   that receives such an RPSI message SHOULD act on that messages to
+   change the reference picture, if it is possible to do so within the
+   available bandwidth constraints and with the codec being used.
+
+5.1.5.  Temporal-Spatial Trade-Off Request (TSTR)
+
+   The temporal-spatial trade-off request and notification are defined
+   in Sections 3.5.2 and 4.3.2 of [RFC5104].  This request can be used
+   to ask the video encoder to change the trade-off it makes between
+   temporal and spatial resolution -- for example, to prefer high
+   spatial image quality but low frame rate.  Support for TSTR requests
+   and notifications is OPTIONAL.
+
+5.1.6.  Temporary Maximum Media Stream Bit Rate Request (TMMBR)
+
+   The Temporary Maximum Media Stream Bit Rate Request (TMMBR) feedback
+   message is defined in Sections 3.5.4 and 4.2.1 of Codec Control
+   Messages [RFC5104].  This request and its corresponding Temporary
+   Maximum Media Stream Bit Rate Notification (TMMBN) message [RFC5104]
+   are used by a media receiver to inform the sending party that there
+   is a current limitation on the amount of bandwidth available to this
+   receiver.  There can be various reasons for this: for example, an RTP
+   mixer can use this message to limit the media rate of the sender
+   being forwarded by the mixer (without doing media transcoding) to fit
+   the bottlenecks existing towards the other session participants.
+   WebRTC endpoints that are sending media are REQUIRED to implement
+   support for TMMBR messages and MUST follow bandwidth limitations set
+   by a TMMBR message received for their SSRC.  The sending of TMMBR
+   messages is OPTIONAL.
+
+5.2.  Header Extensions
+
+   The RTP specification [RFC3550] provides the capability to include
+   RTP header extensions containing in-band data, but the format and
+   semantics of the extensions are poorly specified.  The use of header
+   extensions is OPTIONAL in WebRTC, but if they are used, they MUST be
+   formatted and signaled following the general mechanism for RTP header
+   extensions defined in [RFC8285], since this gives well-defined
+   semantics to RTP header extensions.
+
+   As noted in [RFC8285], the requirement from the RTP specification
+   that header extensions are "designed so that the header extension may
+   be ignored" [RFC3550] stands.  To be specific, header extensions MUST
+   only be used for data that can safely be ignored by the recipient
+   without affecting interoperability and MUST NOT be used when the
+   presence of the extension has changed the form or nature of the rest
+   of the packet in a way that is not compatible with the way the stream
+   is signaled (e.g., as defined by the payload type).  Valid examples
+   of RTP header extensions might include metadata that is additional to
+   the usual RTP information but that can safely be ignored without
+   compromising interoperability.
+
+5.2.1.  Rapid Synchronization
+
+   Many RTP sessions require synchronization between audio, video, and
+   other content.  This synchronization is performed by receivers, using
+   information contained in RTCP SR packets, as described in the RTP
+   specification [RFC3550].  This basic mechanism can be slow, however,
+   so it is RECOMMENDED that the rapid RTP synchronization extensions
+   described in [RFC6051] be implemented in addition to RTCP SR-based
+   synchronization.
+
+   This header extension uses the generic header extension framework
+   described in [RFC8285] and so needs to be negotiated before it can be
+   used.
+
+5.2.2.  Client-to-Mixer Audio Level
+
+   The client-to-mixer audio level extension [RFC6464] is an RTP header
+   extension used by an endpoint to inform a mixer about the level of
+   audio activity in the packet to which the header is attached.  This
+   enables an RTP middlebox to make mixing or selection decisions
+   without decoding or detailed inspection of the payload, reducing the
+   complexity in some types of mixers.  It can also save decoding
+   resources in receivers, which can choose to decode only the most
+   relevant RTP packet streams based on audio activity levels.
+
+   The client-to-mixer audio level header extension [RFC6464] MUST be
+   implemented.  It is REQUIRED that implementations be capable of
+   encrypting the header extension according to [RFC6904], since the
+   information contained in these header extensions can be considered
+   sensitive.  The use of this encryption is RECOMMENDED; however, usage
+   of the encryption can be explicitly disabled through API or
+   signaling.
+
+   This header extension uses the generic header extension framework
+   described in [RFC8285] and so needs to be negotiated before it can be
+   used.
+
+5.2.3.  Mixer-to-Client Audio Level
+
+   The mixer-to-client audio level header extension [RFC6465] provides
+   an endpoint with the audio level of the different sources mixed into
+   a common source stream by an RTP mixer.  This enables a user
+   interface to indicate the relative activity level of each session
+   participant, rather than just being included or not based on the CSRC
+   field.  This is a pure optimization of non-critical functions and is
+   hence OPTIONAL to implement.  If this header extension is
+   implemented, it is REQUIRED that implementations be capable of
+   encrypting the header extension according to [RFC6904], since the
+   information contained in these header extensions can be considered
+   sensitive.  It is further RECOMMENDED that this encryption be used,
+   unless the encryption has been explicitly disabled through API or
+   signaling.
+
+   This header extension uses the generic header extension framework
+   described in [RFC8285] and so needs to be negotiated before it can be
+   used.
+
+5.2.4.  Media Stream Identification
+
+   WebRTC endpoints that implement the SDP bundle negotiation extension
+   will use the SDP Grouping Framework "mid" attribute to identify media
+   streams.  Such endpoints MUST implement the RTP MID header extension
+   described in [RFC8843].
+
+   This header extension uses the generic header extension framework
+   described in [RFC8285] and so needs to be negotiated before it can be
+   used.
+
+5.2.5.  Coordination of Video Orientation
+
+   WebRTC endpoints that send or receive video MUST implement the
+   coordination of video orientation (CVO) RTP header extension as
+   described in Section 4 of [RFC7742].
+
+   This header extension uses the generic header extension framework
+   described in [RFC8285] and so needs to be negotiated before it can be
+   used.
+
+6.  WebRTC Use of RTP: Improving Transport Robustness
+
+   There are tools that can make RTP packet streams robust against
+   packet loss and reduce the impact of loss on media quality.  However,
+   they generally add some overhead compared to a non-robust stream.
+   The overhead needs to be considered, and the aggregate bitrate MUST
+   be rate controlled to avoid causing network congestion (see
+   Section 7).  As a result, improving robustness might require a lower
+   base encoding quality but has the potential to deliver that quality
+   with fewer errors.  The mechanisms described in the following
+   subsections can be used to improve tolerance to packet loss.
+
+6.1.  Negative Acknowledgements and RTP Retransmission
+
+   As a consequence of supporting the RTP/SAVPF profile, implementations
+   can send negative acknowledgements (NACKs) for RTP data packets
+   [RFC4585].  This feedback can be used to inform a sender of the loss
+   of particular RTP packets, subject to the capacity limitations of the
+   RTCP feedback channel.  A sender can use this information to optimize
+   the user experience by adapting the media encoding to compensate for
+   known lost packets.
+
+   RTP packet stream senders are REQUIRED to understand the generic NACK
+   message defined in Section 6.2.1 of [RFC4585], but they MAY choose to
+   ignore some or all of this feedback (following Section 4.2 of
+   [RFC4585]).  Receivers MAY send NACKs for missing RTP packets.
+   Guidelines on when to send NACKs are provided in [RFC4585].  It is
+   not expected that a receiver will send a NACK for every lost RTP
+   packet; rather, it needs to consider the cost of sending NACK
+   feedback and the importance of the lost packet to make an informed
+   decision on whether it is worth telling the sender about a packet-
+   loss event.
+
+   The RTP retransmission payload format [RFC4588] offers the ability to
+   retransmit lost packets based on NACK feedback.  Retransmission needs
+   to be used with care in interactive real-time applications to ensure
+   that the retransmitted packet arrives in time to be useful, but it
+   can be effective in environments with relatively low network RTT.
+   (An RTP sender can estimate the RTT to the receivers using the
+   information in RTCP SR and RR packets, as described at the end of
+   Section 6.4.1 of [RFC3550]).  The use of retransmissions can also
+   increase the forward RTP bandwidth and can potentially cause
+   increased packet loss if the original packet loss was caused by
+   network congestion.  Note, however, that retransmission of an
+   important lost packet to repair decoder state can have lower cost
+   than sending a full intra frame.  It is not appropriate to blindly
+   retransmit RTP packets in response to a NACK.  The importance of lost
+   packets and the likelihood of them arriving in time to be useful need
+   to be considered before RTP retransmission is used.
+
+   Receivers are REQUIRED to implement support for RTP retransmission
+   packets [RFC4588] sent using SSRC multiplexing and MAY also support
+   RTP retransmission packets sent using session multiplexing.  Senders
+   MAY send RTP retransmission packets in response to NACKs if support
+   for the RTP retransmission payload format has been negotiated and the
+   sender believes it is useful to send a retransmission of the
+   packet(s) referenced in the NACK.  Senders do not need to retransmit
+   every NACKed packet.
+
+6.2.  Forward Error Correction (FEC)
+
+   The use of Forward Error Correction (FEC) can provide an effective
+   protection against some degree of packet loss, at the cost of steady
+   bandwidth overhead.  There are several FEC schemes that are defined
+   for use with RTP.  Some of these schemes are specific to a particular
+   RTP payload format, and others operate across RTP packets and can be
+   used with any payload format.  Note that using redundant encoding or
+   FEC will lead to increased play-out delay, which needs to be
+   considered when choosing FEC schemes and their parameters.
+
+   WebRTC endpoints MUST follow the recommendations for FEC use given in
+   [RFC8854].  WebRTC endpoints MAY support other types of FEC, but
+   these MUST be negotiated before they are used.
+
+7.  WebRTC Use of RTP: Rate Control and Media Adaptation
+
+   WebRTC will be used in heterogeneous network environments using a
+   variety of link technologies, including both wired and wireless
+   links, to interconnect potentially large groups of users around the
+   world.  As a result, the network paths between users can have widely
+   varying one-way delays, available bitrates, load levels, and traffic
+   mixtures.  Individual endpoints can send one or more RTP packet
+   streams to each participant, and there can be several participants.
+   Each of these RTP packet streams can contain different types of
+   media, and the type of media, bitrate, and number of RTP packet
+   streams as well as transport-layer flows can be highly asymmetric.
+   Non-RTP traffic can share the network paths with RTP transport-layer
+   flows.  Since the network environment is not predictable or stable,
+   WebRTC endpoints MUST ensure that the RTP traffic they generate can
+   adapt to match changes in the available network capacity.
+
+   The quality of experience for users of WebRTC is very dependent on
+   effective adaptation of the media to the limitations of the network.
+   Endpoints have to be designed so they do not transmit significantly
+   more data than the network path can support, except for very short
+   time periods; otherwise, high levels of network packet loss or delay
+   spikes will occur, causing media quality degradation.  The limiting
+   factor on the capacity of the network path might be the link
+   bandwidth, or it might be competition with other traffic on the link
+   (this can be non-WebRTC traffic, traffic due to other WebRTC flows,
+   or even competition with other WebRTC flows in the same session).
+
+   An effective media congestion control algorithm is therefore an
+   essential part of the WebRTC framework.  However, at the time of this
+   writing, there is no standard congestion control algorithm that can
+   be used for interactive media applications such as WebRTC's flows.
+   Some requirements for congestion control algorithms for
+   RTCPeerConnections are discussed in [RFC8836].  If a standardized
+   congestion control algorithm that satisfies these requirements is
+   developed in the future, this memo will need to be updated to mandate
+   its use.
+
+7.1.  Boundary Conditions and Circuit Breakers
+
+   WebRTC endpoints MUST implement the RTP circuit breaker algorithm
+   that is described in [RFC8083].  The RTP circuit breaker is designed
+   to enable applications to recognize and react to situations of
+   extreme network congestion.  However, since the RTP circuit breaker
+   might not be triggered until congestion becomes extreme, it cannot be
+   considered a substitute for congestion control, and applications MUST
+   also implement congestion control to allow them to adapt to changes
+   in network capacity.  The congestion control algorithm will have to
+   be proprietary until a standardized congestion control algorithm is
+   available.  Any future RTP congestion control algorithms are expected
+   to operate within the envelope allowed by the circuit breaker.
+
+   The session-establishment signaling will also necessarily establish
+   boundaries to which the media bitrate will conform.  The choice of
+   media codecs provides upper and lower bounds on the supported
+   bitrates that the application can utilize to provide useful quality,
+   and the packetization choices that exist.  In addition, the signaling
+   channel can establish maximum media bitrate boundaries using, for
+   example, the SDP "b=AS:" or "b=CT:" lines and the RTP/AVPF TMMBR
+   messages (see Section 5.1.6 of this memo).  Signaled bandwidth
+   limitations, such as SDP "b=AS:" or "b=CT:" lines received from the
+   peer, MUST be followed when sending RTP packet streams.  A WebRTC
+   endpoint receiving media SHOULD signal its bandwidth limitations.
+   These limitations have to be based on known bandwidth limitations,
+   for example the capacity of the edge links.
+
+7.2.  Congestion Control Interoperability and Legacy Systems
+
+   All endpoints that wish to interwork with WebRTC MUST implement RTCP
+   and provide congestion feedback via the defined RTCP reporting
+   mechanisms.
+
+   When interworking with legacy implementations that support RTCP using
+   the RTP/AVP profile [RFC3551], congestion feedback is provided in
+   RTCP RR packets every few seconds.  Implementations that have to
+   interwork with such endpoints MUST ensure that they keep within the
+   RTP circuit breaker [RFC8083] constraints to limit the congestion
+   they can cause.
+
+   If a legacy endpoint supports RTP/AVPF, this enables negotiation of
+   important parameters for frequent reporting, such as the "trr-int"
+   parameter, and the possibility that the endpoint supports some useful
+   feedback format for congestion control purposes such as TMMBR
+   [RFC5104].  Implementations that have to interwork with such
+   endpoints MUST ensure that they stay within the RTP circuit breaker
+   [RFC8083] constraints to limit the congestion they can cause, but
+   they might find that they can achieve better congestion response
+   depending on the amount of feedback that is available.
+
+   With proprietary congestion control algorithms, issues can arise when
+   different algorithms and implementations interact in a communication
+   session.  If the different implementations have made different
+   choices in regards to the type of adaptation, for example one sender
+   based, and one receiver based, then one could end up in a situation
+   where one direction is dual controlled when the other direction is
+   not controlled.  This memo cannot mandate behavior for proprietary
+   congestion control algorithms, but implementations that use such
+   algorithms ought to be aware of this issue and try to ensure that
+   effective congestion control is negotiated for media flowing in both
+   directions.  If the IETF were to standardize both sender- and
+   receiver-based congestion control algorithms for WebRTC traffic in
+   the future, the issues of interoperability, control, and ensuring
+   that both directions of media flow are congestion controlled would
+   also need to be considered.
+
+8.  WebRTC Use of RTP: Performance Monitoring
+
+   As described in Section 4.1, implementations are REQUIRED to generate
+   RTCP Sender Report (SR) and Receiver Report (RR) packets relating to
+   the RTP packet streams they send and receive.  These RTCP reports can
+   be used for performance monitoring purposes, since they include basic
+   packet-loss and jitter statistics.
+
+   A large number of additional performance metrics are supported by the
+   RTCP Extended Reports (XR) framework; see [RFC3611] and [RFC6792].
+   At the time of this writing, it is not clear what extended metrics
+   are suitable for use in WebRTC, so there is no requirement that
+   implementations generate RTCP XR packets.  However, implementations
+   that can use detailed performance monitoring data MAY generate RTCP
+   XR packets as appropriate.  The use of RTCP XR packets SHOULD be
+   signaled; implementations MUST ignore RTCP XR packets that are
+   unexpected or not understood.
+
+9.  WebRTC Use of RTP: Future Extensions
+
+   It is possible that the core set of RTP protocols and RTP extensions
+   specified in this memo will prove insufficient for the future needs
+   of WebRTC.  In this case, future updates to this memo have to be made
+   following "Guidelines for Writers of RTP Payload Format
+   Specifications" [RFC2736], "How to Write an RTP Payload Format"
+   [RFC8088], and "Guidelines for Extending the RTP Control Protocol
+   (RTCP)" [RFC5968].  They also SHOULD take into account any future
+   guidelines for extending RTP and related protocols that have been
+   developed.
+
+   Authors of future extensions are urged to consider the wide range of
+   environments in which RTP is used when recommending extensions, since
+   extensions that are applicable in some scenarios can be problematic
+   in others.  Where possible, the WebRTC framework will adopt RTP
+   extensions that are of general utility, to enable easy implementation
+   of a gateway to other applications using RTP, rather than adopt
+   mechanisms that are narrowly targeted at specific WebRTC use cases.
+
+10.  Signaling Considerations
+
+   RTP is built with the assumption that an external signaling channel
+   exists and can be used to configure RTP sessions and their features.
+   The basic configuration of an RTP session consists of the following
+   parameters:
+
+   RTP profile:  The name of the RTP profile to be used in the session.
+      The RTP/AVP [RFC3551] and RTP/AVPF [RFC4585] profiles can
+      interoperate on a basic level, as can their secure variants, RTP/
+      SAVP [RFC3711] and RTP/SAVPF [RFC5124].  The secure variants of
+      the profiles do not directly interoperate with the nonsecure
+      variants, due to the presence of additional header fields for
+      authentication in SRTP packets and cryptographic transformation of
+      the payload.  WebRTC requires the use of the RTP/SAVPF profile,
+      and this MUST be signaled.  Interworking functions might transform
+      this into the RTP/SAVP profile for a legacy use case by indicating
+      to the WebRTC endpoint that the RTP/SAVPF is used and configuring
+      a "trr-int" value of 4 seconds.
+
+   Transport information:  Source and destination IP address(es) and
+      ports for RTP and RTCP MUST be signaled for each RTP session.  In
+      WebRTC, these transport addresses will be provided by Interactive
+      Connectivity Establishment (ICE) [RFC8445] that signals candidates
+      and arrives at nominated candidate address pairs.  If RTP and RTCP
+      multiplexing [RFC5761] is to be used such that a single port --
+      i.e., transport-layer flow -- is used for RTP and RTCP flows, this
+      MUST be signaled (see Section 4.5).
+
+   RTP payload types, media formats, and format parameters:  The mapping
+      between media type names (and hence the RTP payload formats to be
+      used) and the RTP payload type numbers MUST be signaled.  Each
+      media type MAY also have a number of media type parameters that
+      MUST also be signaled to configure the codec and RTP payload
+      format (the "a=fmtp:" line from SDP).  Section 4.3 of this memo
+      discusses requirements for uniqueness of payload types.
+
+   RTP extensions:  The use of any additional RTP header extensions and
+      RTCP packet types, including any necessary parameters, MUST be
+      signaled.  This signaling ensures that a WebRTC endpoint's
+      behavior, especially when sending, is predictable and consistent.
+      For robustness and compatibility with non-WebRTC systems that
+      might be connected to a WebRTC session via a gateway,
+      implementations are REQUIRED to ignore unknown RTCP packets and
+      RTP header extensions (see also Section 4.1).
+
+   RTCP bandwidth:  Support for exchanging RTCP bandwidth values with
+      the endpoints will be necessary.  This SHALL be done as described
+      in "Session Description Protocol (SDP) Bandwidth Modifiers for RTP
+      Control Protocol (RTCP) Bandwidth" [RFC3556] if using SDP, or
+      something semantically equivalent.  This also ensures that the
+      endpoints have a common view of the RTCP bandwidth.  A common view
+      of the RTCP bandwidth among different endpoints is important to
+      prevent differences in RTCP packet timing and timeout intervals
+      causing interoperability problems.
+
+   These parameters are often expressed in SDP messages conveyed within
+   an offer/answer exchange.  RTP does not depend on SDP or the offer/
+   answer model but does require all the necessary parameters to be
+   agreed upon and provided to the RTP implementation.  Note that in
+   WebRTC, it will depend on the signaling model and API how these
+   parameters need to be configured, but they will need to either be set
+   in the API or explicitly signaled between the peers.
+
+11.  WebRTC API Considerations
+
+   The WebRTC API [W3C.WebRTC] and the Media Capture and Streams API
+   [W3C.WD-mediacapture-streams] define and use the concept of a
+   MediaStream that consists of zero or more MediaStreamTracks.  A
+   MediaStreamTrack is an individual stream of media from any type of
+   media source, such as a microphone or a camera, but conceptual
+   sources, like an audio mix or a video composition, are also possible.
+   The MediaStreamTracks within a MediaStream might need to be
+   synchronized during playback.
+
+   A MediaStreamTrack's realization in RTP, in the context of an
+   RTCPeerConnection, consists of a source packet stream, identified by
+   an SSRC, sent within an RTP session that is part of the
+   RTCPeerConnection.  The MediaStreamTrack can also result in
+   additional packet streams, and thus SSRCs, in the same RTP session.
+   These can be dependent packet streams from scalable encoding of the
+   source stream associated with the MediaStreamTrack, if such a media
+   encoder is used.  They can also be redundancy packet streams; these
+   are created when applying Forward Error Correction (Section 6.2) or
+   RTP retransmission (Section 6.1) to the source packet stream.
+
+   It is important to note that the same media source can be feeding
+   multiple MediaStreamTracks.  As different sets of constraints or
+   other parameters can be applied to the MediaStreamTrack, each
+   MediaStreamTrack instance added to an RTCPeerConnection SHALL result
+   in an independent source packet stream with its own set of associated
+   packet streams and thus different SSRC(s).  It will depend on applied
+   constraints and parameters if the source stream and the encoding
+   configuration will be identical between different MediaStreamTracks
+   sharing the same media source.  If the encoding parameters and
+   constraints are the same, an implementation could choose to use only
+   one encoded stream to create the different RTP packet streams.  Note
+   that such optimizations would need to take into account that the
+   constraints for one of the MediaStreamTracks can change at any
+   moment, meaning that the encoding configurations might no longer be
+   identical, and two different encoder instances would then be needed.
+
+   The same MediaStreamTrack can also be included in multiple
+   MediaStreams; thus, multiple sets of MediaStreams can implicitly need
+   to use the same synchronization base.  To ensure that this works in
+   all cases and does not force an endpoint to disrupt the media by
+   changing synchronization base and CNAME during delivery of any
+   ongoing packet streams, all MediaStreamTracks and their associated
+   SSRCs originating from the same endpoint need to be sent using the
+   same CNAME within one RTCPeerConnection.  This is motivating the use
+   of a single CNAME in Section 4.9.
+
+      |  The requirement to use the same CNAME for all SSRCs that
+      |  originate from the same endpoint does not require a middlebox
+      |  that forwards traffic from multiple endpoints to only use a
+      |  single CNAME.
+
+   Different CNAMEs normally need to be used for different
+   RTCPeerConnection instances, as specified in Section 4.9.  Having two
+   communication sessions with the same CNAME could enable tracking of a
+   user or device across different services (see Section 4.4.1 of
+   [RFC8826] for details).  A web application can request that the
+   CNAMEs used in different RTCPeerConnections (within a same-origin
+   context) be the same; this allows for synchronization of the
+   endpoint's RTP packet streams across the different
+   RTCPeerConnections.
+
+      |  Note: This doesn't result in a tracking issue, since the
+      |  creation of matching CNAMEs depends on existing tracking within
+      |  a single origin.
+
+   The above will currently force a WebRTC endpoint that receives a
+   MediaStreamTrack on one RTCPeerConnection and adds it as outgoing one
+   on any RTCPeerConnection to perform resynchronization of the stream.
+   Since the sending party needs to change the CNAME to the one it uses,
+   this implies it has to use a local system clock as the timebase for
+   the synchronization.  Thus, the relative relation between the
+   timebase of the incoming stream and the system sending out needs to
+   be defined.  This relation also needs monitoring for clock drift and
+   likely adjustments of the synchronization.  The sending entity is
+   also responsible for congestion control for its sent streams.  In
+   cases of packet loss, the loss of incoming data also needs to be
+   handled.  This leads to the observation that the method that is least
+   likely to cause issues or interruptions in the outgoing source packet
+   stream is a model of full decoding, including repair, followed by
+   encoding of the media again into the outgoing packet stream.
+   Optimizations of this method are clearly possible and implementation
+   specific.
+
+   A WebRTC endpoint MUST support receiving multiple MediaStreamTracks,
+   where each of the different MediaStreamTracks (and its sets of
+   associated packet streams) uses different CNAMEs.  However,
+   MediaStreamTracks that are received with different CNAMEs have no
+   defined synchronization.
+
+      |  Note: The motivation for supporting reception of multiple
+      |  CNAMEs is to allow for forward compatibility with any future
+      |  changes that enable more efficient stream handling when
+      |  endpoints relay/forward streams.  It also ensures that
+      |  endpoints can interoperate with certain types of multistream
+      |  middleboxes or endpoints that are not WebRTC.
+
+   "JavaScript Session Establishment Protocol (JSEP)" [RFC8829]
+   specifies that the binding between the WebRTC MediaStreams,
+   MediaStreamTracks, and the SSRC is done as specified in "WebRTC
+   MediaStream Identification in the Session Description Protocol"
+   [RFC8830].  Section 4.1 of the MediaStream Identification (MSID)
+   document [RFC8830] also defines how to map source packet streams with
+   unknown SSRCs to MediaStreamTracks and MediaStreams.  This later is
+   relevant to handle some cases of legacy interoperability.  Commonly,
+   the RTP payload type of any incoming packets will reveal if the
+   packet stream is a source stream or a redundancy or dependent packet
+   stream.  The association to the correct source packet stream depends
+   on the payload format in use for the packet stream.
+
+   Finally, this specification puts a requirement on the WebRTC API to
+   realize a method for determining the CSRC list (Section 4.1) as well
+   as the mixer-to-client audio levels (Section 5.2.3) (when supported);
+   the basic requirements for this is further discussed in
+   Section 12.2.1.
+
+12.  RTP Implementation Considerations
+
+   The following discussion provides some guidance on the implementation
+   of the RTP features described in this memo.  The focus is on a WebRTC
+   endpoint implementation perspective, and while some mention is made
+   of the behavior of middleboxes, that is not the focus of this memo.
+
+12.1.  Configuration and Use of RTP Sessions
+
+   A WebRTC endpoint will be a simultaneous participant in one or more
+   RTP sessions.  Each RTP session can convey multiple media sources and
+   include media data from multiple endpoints.  In the following, some
+   ways in which WebRTC endpoints can configure and use RTP sessions are
+   outlined.
+
+12.1.1.  Use of Multiple Media Sources within an RTP Session
+
+   RTP is a group communication protocol, and every RTP session can
+   potentially contain multiple RTP packet streams.  There are several
+   reasons why this might be desirable:
+
+   *  Multiple media types:
+
+      Outside of WebRTC, it is common to use one RTP session for each
+      type of media source (e.g., one RTP session for audio sources and
+      one for video sources, each sent over different transport-layer
+      flows).  However, to reduce the number of UDP ports used, the
+      default in WebRTC is to send all types of media in a single RTP
+      session, as described in Section 4.4, using RTP and RTCP
+      multiplexing (Section 4.5) to further reduce the number of UDP
+      ports needed.  This RTP session then uses only one bidirectional
+      transport-layer flow but will contain multiple RTP packet streams,
+      each containing a different type of media.  A common example might
+      be an endpoint with a camera and microphone that sends two RTP
+      packet streams, one video and one audio, into a single RTP
+      session.
+
+   *  Multiple capture devices:
+
+      A WebRTC endpoint might have multiple cameras, microphones, or
+      other media capture devices, and so it might want to generate
+      several RTP packet streams of the same media type.  Alternatively,
+      it might want to send media from a single capture device in
+      several different formats or quality settings at once.  Both can
+      result in a single endpoint sending multiple RTP packet streams of
+      the same media type into a single RTP session at the same time.
+
+   *  Associated repair data:
+
+      An endpoint might send an RTP packet stream that is somehow
+      associated with another stream.  For example, it might send an RTP
+      packet stream that contains FEC or retransmission data relating to
+      another stream.  Some RTP payload formats send this sort of
+      associated repair data as part of the source packet stream, while
+      others send it as a separate packet stream.
+
+   *  Layered or multiple-description coding:
+
+      Within a single RTP session, an endpoint can use a layered media
+      codec -- for example, H.264 Scalable Video Coding (SVC) -- or a
+      multiple-description codec that generates multiple RTP packet
+      streams, each with a distinct RTP SSRC.
+
+   *  RTP mixers, translators, and other middleboxes:
+
+      An RTP session, in the WebRTC context, is a point-to-point
+      association between an endpoint and some other peer device, where
+      those devices share a common SSRC space.  The peer device might be
+      another WebRTC endpoint, or it might be an RTP mixer, translator,
+      or some other form of media-processing middlebox.  In the latter
+      cases, the middlebox might send mixed or relayed RTP streams from
+      several participants, which the WebRTC endpoint will need to
+      render.  Thus, even though a WebRTC endpoint might only be a
+      member of a single RTP session, the peer device might be extending
+      that RTP session to incorporate other endpoints.  WebRTC is a
+      group communication environment, and endpoints need to be capable
+      of receiving, decoding, and playing out multiple RTP packet
+      streams at once, even in a single RTP session.
+
+12.1.2.  Use of Multiple RTP Sessions
+
+   In addition to sending and receiving multiple RTP packet streams
+   within a single RTP session, a WebRTC endpoint might participate in
+   multiple RTP sessions.  There are several reasons why a WebRTC
+   endpoint might choose to do this:
+
+   *  To interoperate with legacy devices:
+
+      The common practice in the non-WebRTC world is to send different
+      types of media in separate RTP sessions -- for example, using one
+      RTP session for audio and another RTP session, on a separate
+      transport-layer flow, for video.  All WebRTC endpoints need to
+      support the option of sending different types of media on
+      different RTP sessions so they can interwork with such legacy
+      devices.  This is discussed further in Section 4.4.
+
+   *  To provide enhanced quality of service:
+
+      Some network-based quality-of-service mechanisms operate on the
+      granularity of transport-layer flows.  If use of these mechanisms
+      to provide differentiated quality of service for some RTP packet
+      streams is desired, then those RTP packet streams need to be sent
+      in a separate RTP session using a different transport-layer flow,
+      and with appropriate quality-of-service marking.  This is
+      discussed further in Section 12.1.3.
+
+   *  To separate media with different purposes:
+
+      An endpoint might want to send RTP packet streams that have
+      different purposes on different RTP sessions, to make it easy for
+      the peer device to distinguish them.  For example, some
+      centralized multiparty conferencing systems display the active
+      speaker in high resolution but show low-resolution "thumbnails" of
+      other participants.  Such systems might configure the endpoints to
+      send simulcast high- and low-resolution versions of their video
+      using separate RTP sessions to simplify the operation of the RTP
+      middlebox.  In the WebRTC context, this is currently possible by
+      establishing multiple WebRTC MediaStreamTracks that have the same
+      media source in one (or more) RTCPeerConnection.  Each
+      MediaStreamTrack is then configured to deliver a particular media
+      quality and thus media bitrate, and it will produce an
+      independently encoded version with the codec parameters agreed
+      specifically in the context of that RTCPeerConnection.  The RTP
+      middlebox can distinguish packets corresponding to the low- and
+      high-resolution streams by inspecting their SSRC, RTP payload
+      type, or some other information contained in RTP payload, RTP
+      header extension, or RTCP packets.  However, it can be easier to
+      distinguish the RTP packet streams if they arrive on separate RTP
+      sessions on separate transport-layer flows.
+
+   *  To directly connect with multiple peers:
+
+      A multiparty conference does not need to use an RTP middlebox.
+      Rather, a multi-unicast mesh can be created, comprising several
+      distinct RTP sessions, with each participant sending RTP traffic
+      over a separate RTP session (that is, using an independent
+      RTCPeerConnection object) to every other participant, as shown in
+      Figure 1.  This topology has the benefit of not requiring an RTP
+      middlebox node that is trusted to access and manipulate the media
+      data.  The downside is that it increases the used bandwidth at
+      each sender by requiring one copy of the RTP packet streams for
+      each participant that is part of the same session beyond the
+      sender itself.
+
+      +---+     +---+
+      | A |<--->| B |
+      +---+     +---+
+        ^         ^
+         \       /
+          \     /
+           v   v
+           +---+
+           | C |
+           +---+
+
+              Figure 1: Multi-unicast Using Several RTP Sessions
+
+      The multi-unicast topology could also be implemented as a single
+      RTP session, spanning multiple peer-to-peer transport-layer
+      connections, or as several pairwise RTP sessions, one between each
+      pair of peers.  To maintain a coherent mapping of the relationship
+      between RTP sessions and RTCPeerConnection objects, it is
+      RECOMMENDED that this be implemented as several individual RTP
+      sessions.  The only downside is that endpoint A will not learn of
+      the quality of any transmission happening between B and C, since
+      it will not see RTCP reports for the RTP session between B and C,
+      whereas it would if all three participants were part of a single
+      RTP session.  Experience with the Mbone tools (experimental RTP-
+      based multicast conferencing tools from the late 1990s) has shown
+      that RTCP reception quality reports for third parties can be
+      presented to users in a way that helps them understand asymmetric
+      network problems, and the approach of using separate RTP sessions
+      prevents this.  However, an advantage of using separate RTP
+      sessions is that it enables using different media bitrates and RTP
+      session configurations between the different peers, thus not
+      forcing B to endure the same quality reductions as C will if there
+      are limitations in the transport from A to C.  It is believed that
+      these advantages outweigh the limitations in debugging power.
+
+   *  To indirectly connect with multiple peers:
+
+      A common scenario in multiparty conferencing is to create indirect
+      connections to multiple peers, using an RTP mixer, translator, or
+      some other type of RTP middlebox.  Figure 2 outlines a simple
+      topology that might be used in a four-person centralized
+      conference.  The middlebox acts to optimize the transmission of
+      RTP packet streams from certain perspectives, either by only
+      sending some of the received RTP packet stream to any given
+      receiver, or by providing a combined RTP packet stream out of a
+      set of contributing streams.
+
+      +---+      +-------------+      +---+
+      | A |<---->|             |<---->| B |
+      +---+      | RTP mixer,  |      +---+
+                 | translator, |
+                 | or other    |
+      +---+      | middlebox   |      +---+
+      | C |<---->|             |<---->| D |
+      +---+      +-------------+      +---+
+
+                 Figure 2: RTP Mixer with Only Unicast Paths
+
+      There are various methods of implementation for the middlebox.  If
+      implemented as a standard RTP mixer or translator, a single RTP
+      session will extend across the middlebox and encompass all the
+      endpoints in one multiparty session.  Other types of middleboxes
+      might use separate RTP sessions between each endpoint and the
+      middlebox.  A common aspect is that these RTP middleboxes can use
+      a number of tools to control the media encoding provided by a
+      WebRTC endpoint.  This includes functions like requesting the
+      breaking of the encoding chain and having the encoder produce a
+      so-called Intra frame.  Another common aspect is limiting the
+      bitrate of a stream to better match the mixed output.  Other
+      aspects are controlling the most suitable frame rate, picture
+      resolution, and the trade-off between frame rate and spatial
+      quality.  The middlebox has the responsibility to correctly
+      perform congestion control, identify sources, and manage
+      synchronization while providing the application with suitable
+      media optimizations.  The middlebox also has to be a trusted node
+      when it comes to security, since it manipulates either the RTP
+      header or the media itself (or both) received from one endpoint
+      before sending them on towards the endpoint(s); thus they need to
+      be able to decrypt and then re-encrypt the RTP packet stream
+      before sending it out.
+
+      Mixers are expected to not forward RTCP reports regarding RTP
+      packet streams across themselves.  This is due to the difference
+      between the RTP packet streams provided to the different
+      endpoints.  The original media source lacks information about a
+      mixer's manipulations prior to being sent to the different
+      receivers.  This scenario also results in an endpoint's feedback
+      or requests going to the mixer.  When the mixer can't act on this
+      by itself, it is forced to go to the original media source to
+      fulfill the receiver's request.  This will not necessarily be
+      explicitly visible to any RTP and RTCP traffic, but the
+      interactions and the time to complete them will indicate such
+      dependencies.
+
+      Providing source authentication in multiparty scenarios is a
+      challenge.  In the mixer-based topologies, endpoints source
+      authentication is based on, firstly, verifying that media comes
+      from the mixer by cryptographic verification and, secondly, trust
+      in the mixer to correctly identify any source towards the
+      endpoint.  In RTP sessions where multiple endpoints are directly
+      visible to an endpoint, all endpoints will have knowledge about
+      each others' master keys and can thus inject packets claiming to
+      come from another endpoint in the session.  Any node performing
+      relay can perform noncryptographic mitigation by preventing
+      forwarding of packets that have SSRC fields that came from other
+      endpoints before.  For cryptographic verification of the source,
+      SRTP would require additional security mechanisms -- for example,
+      Timed Efficient Stream Loss-Tolerant Authentication (TESLA) for
+      SRTP [RFC4383] -- that are not part of the base WebRTC standards.
+
+   *  To forward media between multiple peers:
+
+      It is sometimes desirable for an endpoint that receives an RTP
+      packet stream to be able to forward that RTP packet stream to a
+      third party.  The are some obvious security and privacy
+      implications in supporting this, but also potential uses.  This is
+      supported in the W3C API by taking the received and decoded media
+      and using it as a media source that is re-encoded and transmitted
+      as a new stream.
+
+      At the RTP layer, media forwarding acts as a back-to-back RTP
+      receiver and RTP sender.  The receiving side terminates the RTP
+      session and decodes the media, while the sender side re-encodes
+      and transmits the media using an entirely separate RTP session.
+      The original sender will only see a single receiver of the media,
+      and will not be able to tell that forwarding is happening based on
+      RTP-layer information, since the RTP session that is used to send
+      the forwarded media is not connected to the RTP session on which
+      the media was received by the node doing the forwarding.
+
+      The endpoint that is performing the forwarding is responsible for
+      producing an RTP packet stream suitable for onwards transmission.
+      The outgoing RTP session that is used to send the forwarded media
+      is entirely separate from the RTP session on which the media was
+      received.  This will require media transcoding for congestion
+      control purposes to produce a suitable bitrate for the outgoing
+      RTP session, reducing media quality and forcing the forwarding
+      endpoint to spend the resource on the transcoding.  The media
+      transcoding does result in a separation of the two different legs,
+      removing almost all dependencies, and allowing the forwarding
+      endpoint to optimize its media transcoding operation.  The cost is
+      greatly increased computational complexity on the forwarding node.
+      Receivers of the forwarded stream will see the forwarding device
+      as the sender of the stream and will not be able to tell from the
+      RTP layer that they are receiving a forwarded stream rather than
+      an entirely new RTP packet stream generated by the forwarding
+      device.
+
+12.1.3.  Differentiated Treatment of RTP Streams
+
+   There are use cases for differentiated treatment of RTP packet
+   streams.  Such differentiation can happen at several places in the
+   system.  First of all is the prioritization within the endpoint
+   sending the media, which controls both which RTP packet streams will
+   be sent and their allocation of bitrate out of the current available
+   aggregate, as determined by the congestion control.
+
+   It is expected that the WebRTC API [W3C.WebRTC] will allow the
+   application to indicate relative priorities for different
+   MediaStreamTracks.  These priorities can then be used to influence
+   the local RTP processing, especially when it comes to determining how
+   to divide the available bandwidth between the RTP packet streams for
+   the sake of congestion control.  Any changes in relative priority
+   will also need to be considered for RTP packet streams that are
+   associated with the main RTP packet streams, such as redundant
+   streams for RTP retransmission and FEC.  The importance of such
+   redundant RTP packet streams is dependent on the media type and codec
+   used, with regard to how robust that codec is against packet loss.
+   However, a default policy might be to use the same priority for a
+   redundant RTP packet stream as for the source RTP packet stream.
+
+   Secondly, the network can prioritize transport-layer flows and
+   subflows, including RTP packet streams.  Typically, differential
+   treatment includes two steps, the first being identifying whether an
+   IP packet belongs to a class that has to be treated differently, the
+   second consisting of the actual mechanism for prioritizing packets.
+   Three common methods for classifying IP packets are:
+
+   DiffServ:  The endpoint marks a packet with a DiffServ code point to
+      indicate to the network that the packet belongs to a particular
+      class.
+
+   Flow based:  Packets that need to be given a particular treatment are
+      identified using a combination of IP and port address.
+
+   Deep packet inspection:  A network classifier (DPI) inspects the
+      packet and tries to determine if the packet represents a
+      particular application and type that is to be prioritized.
+
+   Flow-based differentiation will provide the same treatment to all
+   packets within a transport-layer flow, i.e., relative prioritization
+   is not possible.  Moreover, if the resources are limited, it might
+   not be possible to provide differential treatment compared to best
+   effort for all the RTP packet streams used in a WebRTC session.  The
+   use of flow-based differentiation needs to be coordinated between the
+   WebRTC system and the network(s).  The WebRTC endpoint needs to know
+   that flow-based differentiation might be used to provide the
+   separation of the RTP packet streams onto different UDP flows to
+   enable a more granular usage of flow-based differentiation.  The used
+   flows, their 5-tuples, and prioritization will need to be
+   communicated to the network so that it can identify the flows
+   correctly to enable prioritization.  No specific protocol support for
+   this is specified.
+
+   DiffServ assumes that either the endpoint or a classifier can mark
+   the packets with an appropriate Differentiated Services Code Point
+   (DSCP) so that the packets are treated according to that marking.  If
+   the endpoint is to mark the traffic, two requirements arise in the
+   WebRTC context: 1) The WebRTC endpoint has to know which DSCPs to use
+   and know that it can use them on some set of RTP packet streams. 2)
+   The information needs to be propagated to the operating system when
+   transmitting the packet.  Details of this process are outside the
+   scope of this memo and are further discussed in "Differentiated
+   Services Code Point (DSCP) Packet Markings for WebRTC QoS" [RFC8837].
+
+   Despite the SRTP media encryption, deep packet inspectors will still
+   be fairly capable of classifying the RTP streams.  The reason is that
+   SRTP leaves the first 12 bytes of the RTP header unencrypted.  This
+   enables easy RTP stream identification using the SSRC and provides
+   the classifier with useful information that can be correlated to
+   determine, for example, the stream's media type.  Using packet sizes,
+   reception times, packet inter-spacing, RTP timestamp increments, and
+   sequence numbers, fairly reliable classifications are achieved.
+
+   For packet-based marking schemes, it might be possible to mark
+   individual RTP packets differently based on the relative priority of
+   the RTP payload.  For example, video codecs that have I, P, and B
+   pictures could prioritize any payloads carrying only B frames less,
+   as these are less damaging to lose.  However, depending on the QoS
+   mechanism and what markings are applied, this can result in not only
+   different packet-drop probabilities but also packet reordering; see
+   [RFC8837] and [RFC7657] for further discussion.  As a default policy,
+   all RTP packets related to an RTP packet stream ought to be provided
+   with the same prioritization; per-packet prioritization is outside
+   the scope of this memo but might be specified elsewhere in future.
+
+   It is also important to consider how RTCP packets associated with a
+   particular RTP packet stream need to be marked.  RTCP compound
+   packets with Sender Reports (SRs) ought to be marked with the same
+   priority as the RTP packet stream itself, so the RTCP-based round-
+   trip time (RTT) measurements are done using the same transport-layer
+   flow priority as the RTP packet stream experiences.  RTCP compound
+   packets containing an RR packet ought to be sent with the priority
+   used by the majority of the RTP packet streams reported on.  RTCP
+   packets containing time-critical feedback packets can use higher
+   priority to improve the timeliness and likelihood of delivery of such
+   feedback.
+
+12.2.  Media Source, RTP Streams, and Participant Identification
+
+12.2.1.  Media Source Identification
+
+   Each RTP packet stream is identified by a unique synchronization
+   source (SSRC) identifier.  The SSRC identifier is carried in each of
+   the RTP packets comprising an RTP packet stream, and is also used to
+   identify that stream in the corresponding RTCP reports.  The SSRC is
+   chosen as discussed in Section 4.8.  The first stage in
+   demultiplexing RTP and RTCP packets received on a single transport-
+   layer flow at a WebRTC endpoint is to separate the RTP packet streams
+   based on their SSRC value; once that is done, additional
+   demultiplexing steps can determine how and where to render the media.
+
+   RTP allows a mixer, or other RTP-layer middlebox, to combine encoded
+   streams from multiple media sources to form a new encoded stream from
+   a new media source (the mixer).  The RTP packets in that new RTP
+   packet stream can include a contributing source (CSRC) list,
+   indicating which original SSRCs contributed to the combined source
+   stream.  As described in Section 4.1, implementations need to support
+   reception of RTP data packets containing a CSRC list and RTCP packets
+   that relate to sources present in the CSRC list.  The CSRC list can
+   change on a packet-by-packet basis, depending on the mixing operation
+   being performed.  Knowledge of what media sources contributed to a
+   particular RTP packet can be important if the user interface
+   indicates which participants are active in the session.  Changes in
+   the CSRC list included in packets need to be exposed to the WebRTC
+   application using some API if the application is to be able to track
+   changes in session participation.  It is desirable to map CSRC values
+   back into WebRTC MediaStream identities as they cross this API, to
+   avoid exposing the SSRC/CSRC namespace to WebRTC applications.
+
+   If the mixer-to-client audio level extension [RFC6465] is being used
+   in the session (see Section 5.2.3), the information in the CSRC list
+   is augmented by audio-level information for each contributing source.
+   It is desirable to expose this information to the WebRTC application
+   using some API, after mapping the CSRC values to WebRTC MediaStream
+   identities, so it can be exposed in the user interface.
+
+12.2.2.  SSRC Collision Detection
+
+   The RTP standard requires RTP implementations to have support for
+   detecting and handling SSRC collisions -- i.e., be able to resolve
+   the conflict when two different endpoints use the same SSRC value
+   (see Section 8.2 of [RFC3550]).  This requirement also applies to
+   WebRTC endpoints.  There are several scenarios where SSRC collisions
+   can occur:
+
+   *  In a point-to-point session where each SSRC is associated with
+      either of the two endpoints and the main media-carrying SSRC
+      identifier will be announced in the signaling channel, a collision
+      is less likely to occur due to the information about used SSRCs.
+      If SDP is used, this information is provided by source-specific
+      SDP attributes [RFC5576].  Still, collisions can occur if both
+      endpoints start using a new SSRC identifier prior to having
+      signaled it to the peer and received acknowledgement on the
+      signaling message.  "Source-Specific Media Attributes in the
+      Session Description Protocol (SDP)" [RFC5576] contains a mechanism
+      to signal how the endpoint resolved the SSRC collision.
+
+   *  SSRC values that have not been signaled could also appear in an
+      RTP session.  This is more likely than it appears, since some RTP
+      functions use extra SSRCs to provide their functionality.  For
+      example, retransmission data might be transmitted using a separate
+      RTP packet stream that requires its own SSRC, separate from the
+      SSRC of the source RTP packet stream [RFC4588].  In those cases,
+      an endpoint can create a new SSRC that strictly doesn't need to be
+      announced over the signaling channel to function correctly on both
+      RTP and RTCPeerConnection level.
+
+   *  Multiple endpoints in a multiparty conference can create new
+      sources and signal those towards the RTP middlebox.  In cases
+      where the SSRC/CSRC are propagated between the different endpoints
+      from the RTP middlebox, collisions can occur.
+
+   *  An RTP middlebox could connect an endpoint's RTCPeerConnection to
+      another RTCPeerConnection from the same endpoint, thus forming a
+      loop where the endpoint will receive its own traffic.  While it is
+      clearly considered a bug, it is important that the endpoint be
+      able to recognize and handle the case when it occurs.  This case
+      becomes even more problematic when media mixers and such are
+      involved, where the stream received is a different stream but
+      still contains this client's input.
+
+   These SSRC/CSRC collisions can only be handled on the RTP level when
+   the same RTP session is extended across multiple RTCPeerConnections
+   by an RTP middlebox.  To resolve the more generic case where multiple
+   RTCPeerConnections are interconnected, identification of the media
+   source or sources that are part of a MediaStreamTrack being
+   propagated across multiple interconnected RTCPeerConnection needs to
+   be preserved across these interconnections.
+
+12.2.3.  Media Synchronization Context
+
+   When an endpoint sends media from more than one media source, it
+   needs to consider if (and which of) these media sources are to be
+   synchronized.  In RTP/RTCP, synchronization is provided by having a
+   set of RTP packet streams be indicated as coming from the same
+   synchronization context and logical endpoint by using the same RTCP
+   CNAME identifier.
+
+   The next provision is that the internal clocks of all media sources
+   -- i.e., what drives the RTP timestamp -- can be correlated to a
+   system clock that is provided in RTCP Sender Reports encoded in an
+   NTP format.  By correlating all RTP timestamps to a common system
+   clock for all sources, the timing relation of the different RTP
+   packet streams, also across multiple RTP sessions, can be derived at
+   the receiver and, if desired, the streams can be synchronized.  The
+   requirement is for the media sender to provide the correlation
+   information; whether or not the information is used is up to the
+   receiver.
+
+13.  Security Considerations
+
+   The overall security architecture for WebRTC is described in
+   [RFC8827], and security considerations for the WebRTC framework are
+   described in [RFC8826].  These considerations also apply to this
+   memo.
+
+   The security considerations of the RTP specification, the RTP/SAVPF
+   profile, and the various RTP/RTCP extensions and RTP payload formats
+   that form the complete protocol suite described in this memo apply.
+   It is believed that there are no new security considerations
+   resulting from the combination of these various protocol extensions.
+
+   "Extended Secure RTP Profile for Real-time Transport Control Protocol
+   (RTCP)-Based Feedback (RTP/SAVPF)" [RFC5124] provides handling of
+   fundamental issues by offering confidentiality, integrity, and
+   partial source authentication.  A media-security solution that is
+   mandatory to implement and use is created by combining this secured
+   RTP profile and DTLS-SRTP keying [RFC5764], as defined by Section 5.5
+   of [RFC8827].
+
+   RTCP packets convey a Canonical Name (CNAME) identifier that is used
+   to associate RTP packet streams that need to be synchronized across
+   related RTP sessions.  Inappropriate choice of CNAME values can be a
+   privacy concern, since long-term persistent CNAME identifiers can be
+   used to track users across multiple WebRTC calls.  Section 4.9 of
+   this memo mandates generation of short-term persistent RTCP CNAMES,
+   as specified in RFC 7022, resulting in untraceable CNAME values that
+   alleviate this risk.
+
+   Some potential denial-of-service attacks exist if the RTCP reporting
+   interval is configured to an inappropriate value.  This could be done
+   by configuring the RTCP bandwidth fraction to an excessively large or
+   small value using the SDP "b=RR:" or "b=RS:" lines [RFC3556] or some
+   similar mechanism, or by choosing an excessively large or small value
+   for the RTP/AVPF minimal receiver report interval (if using SDP, this
+   is the "a=rtcp-fb:... trr-int" parameter) [RFC4585].  The risks are
+   as follows:
+
+   1.  the RTCP bandwidth could be configured to make the regular
+       reporting interval so large that effective congestion control
+       cannot be maintained, potentially leading to denial of service
+       due to congestion caused by the media traffic;
+
+   2.  the RTCP interval could be configured to a very small value,
+       causing endpoints to generate high-rate RTCP traffic, potentially
+       leading to denial of service due to the RTCP traffic not being
+       congestion controlled; and
+
+   3.  RTCP parameters could be configured differently for each
+       endpoint, with some of the endpoints using a large reporting
+       interval and some using a smaller interval, leading to denial of
+       service due to premature participant timeouts due to mismatched
+       timeout periods that are based on the reporting interval.  This
+       is a particular concern if endpoints use a small but nonzero
+       value for the RTP/AVPF minimal receiver report interval (trr-int)
+       [RFC4585], as discussed in Section 6.1 of [RFC8108].
+
+   Premature participant timeout can be avoided by using the fixed
+   (nonreduced) minimum interval when calculating the participant
+   timeout (see Section 4.1 of this memo and Section 7.1.2 of
+   [RFC8108]).  To address the other concerns, endpoints SHOULD ignore
+   parameters that configure the RTCP reporting interval to be
+   significantly longer than the default five-second interval specified
+   in [RFC3550] (unless the media data rate is so low that the longer
+   reporting interval roughly corresponds to 5% of the media data rate),
+   or that configure the RTCP reporting interval small enough that the
+   RTCP bandwidth would exceed the media bandwidth.
+
+   The guidelines in [RFC6562] apply when using variable bitrate (VBR)
+   audio codecs such as Opus (see Section 4.3 for discussion of mandated
+   audio codecs).  The guidelines in [RFC6562] also apply, but are of
+   lesser importance, when using the client-to-mixer audio level header
+   extensions (Section 5.2.2) or the mixer-to-client audio level header
+   extensions (Section 5.2.3).  The use of the encryption of the header
+   extensions are RECOMMENDED, unless there are known reasons, like RTP
+   middleboxes performing voice-activity-based source selection or
+   third-party monitoring that will greatly benefit from the
+   information, and this has been expressed using API or signaling.  If
+   further evidence is produced to show that information leakage is
+   significant from audio-level indications, then use of encryption
+   needs to be mandated at that time.
+
+   In multiparty communication scenarios using RTP middleboxes, a lot of
+   trust is placed on these middleboxes to preserve the session's
+   security.  The middlebox needs to maintain confidentiality and
+   integrity and perform source authentication.  As discussed in
+   Section 12.1.1, the middlebox can perform checks that prevent any
+   endpoint participating in a conference from impersonating another.
+   Some additional security considerations regarding multiparty
+   topologies can be found in [RFC7667].
+
+14.  IANA Considerations
+
+   This document has no IANA actions.
+
+15.  References
+
+15.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2736]  Handley, M. and C. Perkins, "Guidelines for Writers of RTP
+              Payload Format Specifications", BCP 36, RFC 2736,
+              DOI 10.17487/RFC2736, December 1999,
+              <https://www.rfc-editor.org/info/rfc2736>.
+
+   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
+              Jacobson, "RTP: A Transport Protocol for Real-Time
+              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
+              July 2003, <https://www.rfc-editor.org/info/rfc3550>.
+
+   [RFC3551]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
+              Video Conferences with Minimal Control", STD 65, RFC 3551,
+              DOI 10.17487/RFC3551, July 2003,
+              <https://www.rfc-editor.org/info/rfc3551>.
+
+   [RFC3556]  Casner, S., "Session Description Protocol (SDP) Bandwidth
+              Modifiers for RTP Control Protocol (RTCP) Bandwidth",
+              RFC 3556, DOI 10.17487/RFC3556, July 2003,
+              <https://www.rfc-editor.org/info/rfc3556>.
+
+   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+              RFC 3711, DOI 10.17487/RFC3711, March 2004,
+              <https://www.rfc-editor.org/info/rfc3711>.
+
+   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+              Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
+              July 2006, <https://www.rfc-editor.org/info/rfc4566>.
+
+   [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,
+              DOI 10.17487/RFC4585, July 2006,
+              <https://www.rfc-editor.org/info/rfc4585>.
+
+   [RFC4588]  Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
+              Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
+              DOI 10.17487/RFC4588, July 2006,
+              <https://www.rfc-editor.org/info/rfc4588>.
+
+   [RFC4961]  Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
+              BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007,
+              <https://www.rfc-editor.org/info/rfc4961>.
+
+   [RFC5104]  Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
+              "Codec Control Messages in the RTP Audio-Visual Profile
+              with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104,
+              February 2008, <https://www.rfc-editor.org/info/rfc5104>.
+
+   [RFC5124]  Ott, J. and E. Carrara, "Extended Secure RTP Profile for
+              Real-time Transport Control Protocol (RTCP)-Based Feedback
+              (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
+              2008, <https://www.rfc-editor.org/info/rfc5124>.
+
+   [RFC5506]  Johansson, I. and M. Westerlund, "Support for Reduced-Size
+              Real-Time Transport Control Protocol (RTCP): Opportunities
+              and Consequences", RFC 5506, DOI 10.17487/RFC5506, April
+              2009, <https://www.rfc-editor.org/info/rfc5506>.
+
+   [RFC5761]  Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
+              Control Packets on a Single Port", RFC 5761,
+              DOI 10.17487/RFC5761, April 2010,
+              <https://www.rfc-editor.org/info/rfc5761>.
+
+   [RFC5764]  McGrew, D. and E. Rescorla, "Datagram Transport Layer
+              Security (DTLS) Extension to Establish Keys for the Secure
+              Real-time Transport Protocol (SRTP)", RFC 5764,
+              DOI 10.17487/RFC5764, May 2010,
+              <https://www.rfc-editor.org/info/rfc5764>.
+
+   [RFC6051]  Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
+              Flows", RFC 6051, DOI 10.17487/RFC6051, November 2010,
+              <https://www.rfc-editor.org/info/rfc6051>.
+
+   [RFC6464]  Lennox, J., Ed., Ivov, E., and E. Marocco, "A Real-time
+              Transport Protocol (RTP) Header Extension for Client-to-
+              Mixer Audio Level Indication", RFC 6464,
+              DOI 10.17487/RFC6464, December 2011,
+              <https://www.rfc-editor.org/info/rfc6464>.
+
+   [RFC6465]  Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real-
+              time Transport Protocol (RTP) Header Extension for Mixer-
+              to-Client Audio Level Indication", RFC 6465,
+              DOI 10.17487/RFC6465, December 2011,
+              <https://www.rfc-editor.org/info/rfc6465>.
+
+   [RFC6562]  Perkins, C. and JM. Valin, "Guidelines for the Use of
+              Variable Bit Rate Audio with Secure RTP", RFC 6562,
+              DOI 10.17487/RFC6562, March 2012,
+              <https://www.rfc-editor.org/info/rfc6562>.
+
+   [RFC6904]  Lennox, J., "Encryption of Header Extensions in the Secure
+              Real-time Transport Protocol (SRTP)", RFC 6904,
+              DOI 10.17487/RFC6904, April 2013,
+              <https://www.rfc-editor.org/info/rfc6904>.
+
+   [RFC7007]  Terriberry, T., "Update to Remove DVI4 from the
+              Recommended Codecs for the RTP Profile for Audio and Video
+              Conferences with Minimal Control (RTP/AVP)", RFC 7007,
+              DOI 10.17487/RFC7007, August 2013,
+              <https://www.rfc-editor.org/info/rfc7007>.
+
+   [RFC7022]  Begen, A., Perkins, C., Wing, D., and E. Rescorla,
+              "Guidelines for Choosing RTP Control Protocol (RTCP)
+              Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022,
+              September 2013, <https://www.rfc-editor.org/info/rfc7022>.
+
+   [RFC7160]  Petit-Huguenin, M. and G. Zorn, Ed., "Support for Multiple
+              Clock Rates in an RTP Session", RFC 7160,
+              DOI 10.17487/RFC7160, April 2014,
+              <https://www.rfc-editor.org/info/rfc7160>.
+
+   [RFC7164]  Gross, K. and R. Brandenburg, "RTP and Leap Seconds",
+              RFC 7164, DOI 10.17487/RFC7164, March 2014,
+              <https://www.rfc-editor.org/info/rfc7164>.
+
+   [RFC7742]  Roach, A.B., "WebRTC Video Processing and Codec
+              Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016,
+              <https://www.rfc-editor.org/info/rfc7742>.
+
+   [RFC7874]  Valin, JM. and C. Bran, "WebRTC Audio Codec and Processing
+              Requirements", RFC 7874, DOI 10.17487/RFC7874, May 2016,
+              <https://www.rfc-editor.org/info/rfc7874>.
+
+   [RFC8083]  Perkins, C. and V. Singh, "Multimedia Congestion Control:
+              Circuit Breakers for Unicast RTP Sessions", RFC 8083,
+              DOI 10.17487/RFC8083, March 2017,
+              <https://www.rfc-editor.org/info/rfc8083>.
+
+   [RFC8108]  Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
+              "Sending Multiple RTP Streams in a Single RTP Session",
+              RFC 8108, DOI 10.17487/RFC8108, March 2017,
+              <https://www.rfc-editor.org/info/rfc8108>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8285]  Singer, D., Desineni, H., and R. Even, Ed., "A General
+              Mechanism for RTP Header Extensions", RFC 8285,
+              DOI 10.17487/RFC8285, October 2017,
+              <https://www.rfc-editor.org/info/rfc8285>.
+
+   [RFC8825]  Alvestrand, H., "Overview: Real-Time Protocols for
+              Browser-Based Applications", RFC 8825,
+              DOI 10.17487/RFC8825, January 2021,
+              <https://www.rfc-editor.org/info/rfc8825>.
+
+   [RFC8826]  Rescorla, E., "Security Considerations for WebRTC",
+              RFC 8826, DOI 10.17487/RFC8826, January 2021,
+              <https://www.rfc-editor.org/info/rfc8826>.
+
+   [RFC8827]  Rescorla, E., "WebRTC Security Architecture", RFC 8827,
+              DOI 10.17487/RFC8827, January 2021,
+              <https://www.rfc-editor.org/info/rfc8827>.
+
+   [RFC8843]  Holmberg, C., Alvestrand, H., and C. Jennings,
+              "Negotiating Media Multiplexing Using the Session
+              Description Protocol (SDP)", RFC 8843,
+              DOI 10.17487/RFC8843, January 2021,
+              <https://www.rfc-editor.org/info/rfc8843>.
+
+   [RFC8854]  Uberti, J., "WebRTC Forward Error Correction
+              Requirements", RFC 8854, DOI 10.17487/RFC8854, January
+              2021, <https://www.rfc-editor.org/info/rfc8854>.
+
+   [RFC8858]  Holmberg, C., "Indicating Exclusive Support of RTP and RTP
+              Control Protocol (RTCP) Multiplexing Using the Session
+              Description Protocol (SDP)", RFC 8858,
+              DOI 10.17487/RFC8858, January 2021,
+              <https://www.rfc-editor.org/info/rfc8858>.
+
+   [RFC8860]  Westerlund, M., Perkins, C., and J. Lennox, "Sending
+              Multiple Types of Media in a Single RTP Session",
+              RFC 8860, DOI 10.17487/RFC8860, January 2021,
+              <https://www.rfc-editor.org/info/rfc8860>.
+
+   [RFC8861]  Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
+              "Sending Multiple RTP Streams in a Single RTP Session:
+              Grouping RTP Control Protocol (RTCP) Reception Statistics
+              and Other Feedback", RFC 8861, DOI 10.17487/RFC8861,
+              January 2021, <https://www.rfc-editor.org/info/rfc8861>.
+
+   [W3C.WD-mediacapture-streams]
+              Jennings, C., Aboba, B., Bruaroey, J-I., and H. Boström,
+              "Media Capture and Streams", W3C Candidate Recommendation,
+              <https://www.w3.org/TR/mediacapture-streams/>.
+
+   [W3C.WebRTC]
+              Jennings, C., Boström, H., and J-I. Bruaroey, "WebRTC 1.0:
+              Real-time Communication Between Browsers", W3C Proposed
+              Recommendation, <https://www.w3.org/TR/webrtc/>.
+
+15.2.  Informative References
+
+   [RFC3611]  Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
+              "RTP Control Protocol Extended Reports (RTCP XR)",
+              RFC 3611, DOI 10.17487/RFC3611, November 2003,
+              <https://www.rfc-editor.org/info/rfc3611>.
+
+   [RFC4383]  Baugher, M. and E. Carrara, "The Use of Timed Efficient
+              Stream Loss-Tolerant Authentication (TESLA) in the Secure
+              Real-time Transport Protocol (SRTP)", RFC 4383,
+              DOI 10.17487/RFC4383, February 2006,
+              <https://www.rfc-editor.org/info/rfc4383>.
+
+   [RFC5576]  Lennox, J., Ott, J., and T. Schierl, "Source-Specific
+              Media Attributes in the Session Description Protocol
+              (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
+              <https://www.rfc-editor.org/info/rfc5576>.
+
+   [RFC5968]  Ott, J. and C. Perkins, "Guidelines for Extending the RTP
+              Control Protocol (RTCP)", RFC 5968, DOI 10.17487/RFC5968,
+              September 2010, <https://www.rfc-editor.org/info/rfc5968>.
+
+   [RFC6263]  Marjou, X. and A. Sollaud, "Application Mechanism for
+              Keeping Alive the NAT Mappings Associated with RTP / RTP
+              Control Protocol (RTCP) Flows", RFC 6263,
+              DOI 10.17487/RFC6263, June 2011,
+              <https://www.rfc-editor.org/info/rfc6263>.
+
+   [RFC6792]  Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use
+              of the RTP Monitoring Framework", RFC 6792,
+              DOI 10.17487/RFC6792, November 2012,
+              <https://www.rfc-editor.org/info/rfc6792>.
+
+   [RFC7478]  Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
+              Time Communication Use Cases and Requirements", RFC 7478,
+              DOI 10.17487/RFC7478, March 2015,
+              <https://www.rfc-editor.org/info/rfc7478>.
+
+   [RFC7656]  Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
+              B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
+              for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
+              DOI 10.17487/RFC7656, November 2015,
+              <https://www.rfc-editor.org/info/rfc7656>.
+
+   [RFC7657]  Black, D., Ed. and P. Jones, "Differentiated Services
+              (Diffserv) and Real-Time Communication", RFC 7657,
+              DOI 10.17487/RFC7657, November 2015,
+              <https://www.rfc-editor.org/info/rfc7657>.
+
+   [RFC7667]  Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
+              DOI 10.17487/RFC7667, November 2015,
+              <https://www.rfc-editor.org/info/rfc7667>.
+
+   [RFC8088]  Westerlund, M., "How to Write an RTP Payload Format",
+              RFC 8088, DOI 10.17487/RFC8088, May 2017,
+              <https://www.rfc-editor.org/info/rfc8088>.
+
+   [RFC8445]  Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
+              Connectivity Establishment (ICE): A Protocol for Network
+              Address Translator (NAT) Traversal", RFC 8445,
+              DOI 10.17487/RFC8445, July 2018,
+              <https://www.rfc-editor.org/info/rfc8445>.
+
+   [RFC8829]  Uberti, J., Jennings, C., and E. Rescorla, Ed.,
+              "JavaScript Session Establishment Protocol (JSEP)",
+              RFC 8829, DOI 10.17487/RFC8829, January 2021,
+              <https://www.rfc-editor.org/info/rfc8829>.
+
+   [RFC8830]  Alvestrand, H., "WebRTC MediaStream Identification in the
+              Session Description Protocol", RFC 8830,
+              DOI 10.17487/RFC8830, January 2021,
+              <https://www.rfc-editor.org/info/rfc8830>.
+
+   [RFC8836]  Jesup, R. and Z. Sarker, Ed., "Congestion Control
+              Requirements for Interactive Real-Time Media", RFC 8836,
+              DOI 10.17487/RFC8836, January 2021,
+              <https://www.rfc-editor.org/info/rfc8836>.
+
+   [RFC8837]  Jones, P., Dhesikan, S., Jennings, C., and D. Druta,
+              "Differentiated Services Code Point (DSCP) Packet Markings
+              for WebRTC QoS", RFC 8837, DOI 10.17487/RFC8837, January
+              2021, <https://www.rfc-editor.org/info/rfc8837>.
+
+   [RFC8872]  Westerlund, M., Burman, B., Perkins, C., Alvestrand, H.,
+              and R. Even, "Guidelines for Using the Multiplexing
+              Features of RTP to Support Multiple Media Streams",
+              RFC 8872, DOI 10.17487/RFC8872, January 2021,
+              <https://www.rfc-editor.org/info/rfc8872>.
+
+Acknowledgements
+
+   The authors would like to thank Bernard Aboba, Harald Alvestrand,
+   Cary Bran, Ben Campbell, Alissa Cooper, Spencer Dawkins, Charles
+   Eckel, Alex Eleftheriadis, Christian Groves, Chris Inacio, Cullen
+   Jennings, Olle Johansson, Suhas Nandakumar, Dan Romascanu, Jim
+   Spring, Martin Thomson, and the other members of the IETF RTCWEB
+   working group for their valuable feedback.
+
+Authors' Addresses
+
+   Colin Perkins
+   University of Glasgow
+   School of Computing Science
+   Glasgow
+   G12 8QQ
+   United Kingdom
+
+   Email: csp@csperkins.org
+   URI:   https://csperkins.org/
+
+
+   Magnus Westerlund
+   Ericsson
+   Torshamnsgatan 23
+   SE-164 80 Kista
+   Sweden
+
+   Email: magnus.westerlund@ericsson.com
+
+
+   Jörg Ott
+   Technical University Munich
+   Department of Informatics
+   Chair of Connected Mobility
+   Boltzmannstrasse 3
+   85748 Garching
+   Germany
+
+   Email: ott@in.tum.de