<?xml version="1.0" encoding="US-ASCII"?> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-rtcweb-rtp-usage-26" ipr="trust200902"> number="8834"
     submissionType="IETF" consensus="true" obsoletes="" updates=""
     xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true"
     version="3" ipr="trust200902" docName="draft-ietf-rtcweb-rtp-usage-26">
<!-- xml2rfc v2v3 conversion 2.34.0 -->

    <title abbrev="RTP for WebRTC">Web Real-Time Communication (WebRTC): Media WebRTC">Media Transport and Use of RTP</title> RTP in WebRTC</title>
    <seriesInfo name="RFC" value="8834"/>
    <author fullname="Colin Perkins" initials="C. S." initials="C." surname="Perkins">
      <organization>University of Glasgow</organization>
          <street>School of Computing Science</street>
          <code>G12 8QQ</code>
          <country>United Kingdom</country>
    <author fullname="Magnus Westerlund" initials="M." surname="Westerlund">
          <street>Farogatan 6</street>

          <city>SE-164 80 Kista</city>
          <code>164 80</code>
        <phone>+46 10 714 82 87</phone>
    <author fullname="Joerg fullname="Jörg Ott" initials="J." surname="Ott">
      <organization>Aalto University</organization>
          <street>School of Electrical Engineering</street>
    <date day="12" month="June" year="2015" /> month="September" year="2020"/>
    <workgroup>RTCWEB Working Group</workgroup>
      <t>The framework for Web Real-Time Communication (WebRTC) framework provides support
      for direct interactive rich communication using audio, video, text,
      collaboration, games, etc. between two peers' web-browsers. 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, context and gives requirements for which RTP features, profiles,
      and extensions need to be supported.</t>
    <section title="Introduction"> numbered="true" toc="default">
      <t>The <xref target="RFC3550">Real-time target="RFC3550" format="default">Real-time Transport Protocol (RTP)</xref>
      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 signalling, signaling, these form
      the basis for many teleconferencing systems.</t>
      <t>The Web Real-Time communication Communication (WebRTC) framework provides the
      protocol building blocks to support direct, interactive, real-time
      communication using audio, video, collaboration, games, etc., etc. between
      two peers' web-browsers. 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, endpoints, along with
      suggested extensions for enhanced functionality.</t>
      <t>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 <xref
      target="I-D.ietf-rtcweb-overview"></xref>.</t> target="RFC8825" format="default"/>.</t>
      <t>The structure of this memo is as follows. <xref
      target="sec-rationale"></xref> target="sec-rationale" format="default"/> outlines our rationale in for preparing this
      memo and choosing these RTP features. <xref
      target="sec-terminology"></xref> target="sec-terminology" format="default"/> defines terminology. Requirements for
      core RTP protocols are described in <xref target="sec-rtp-core"></xref> target="sec-rtp-core" format="default"/>,
      and suggested RTP extensions are described in <xref
      target="sec-rtp-extn"></xref>. target="sec-rtp-extn" format="default"/>. <xref target="sec-rtp-robust"></xref> target="sec-rtp-robust" format="default"/>
      outlines mechanisms that can increase robustness to network problems,
      while <xref target="sec-rate-control"></xref> target="sec-rate-control" format="default"/> describes
      congestion control and rate adaptation mechanisms. The discussion of
      mandated RTP
      mechanisms concludes in <xref target="sec-perf"></xref> target="sec-perf" format="default"/> with a review of
      performance monitoring and network management tools. <xref
      target="sec-extn"></xref> target="sec-extn" format="default"/> gives some guidelines for future incorporation
      of other RTP and RTP Control Protocol (RTCP) extensions into this
      framework. <xref target="sec-signalling"></xref> target="sec-signalling" format="default"/> describes requirements
      placed on the signalling signaling channel. <xref target="sec-webrtc-api"></xref> target="sec-webrtc-api" format="default"/>
      discusses the relationship between features of the RTP framework and the
      WebRTC application programming interface (API), and <xref
      target="sec-rtp-func"></xref> target="sec-rtp-func" format="default"/> discusses RTP implementation
      considerations. The memo concludes with <xref
      target="sec-security">security target="sec-security" format="default">security considerations</xref> and <xref
      target="sec-iana">IANA target="sec-iana" format="default">IANA considerations</xref>.</t>
    <section anchor="sec-rationale" title="Rationale"> numbered="true" toc="default">
      <t>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, designers and to 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, extensions and to define a common baseline RTP feature
      set for all WebRTC Endpoints. 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.</t>
      <t>RTP and RTCP extensions that are not discussed in this document can
      be implemented by WebRTC Endpoints endpoints if they are beneficial for new use
      cases. However, they are not necessary to address the WebRTC use cases
      and requirements identified in <xref target="RFC7478"></xref>.</t> target="RFC7478" format="default"/>.</t>
      <t>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
      video-conferencing systems, or for room-based high-quality telepresence
    <section anchor="sec-terminology" title="Terminology">
      <t>The numbered="true" toc="default">
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref
      target="RFC2119"></xref>. The RFC 2119 interpretation of these key words
      applies target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when written when, they appear in ALL CAPS. 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.</t> memo.

      <t>We define the following additional terms:<list style="hanging">
          <t hangText="WebRTC MediaStream:">The terms:</t>
      <dl newline="false" spacing="normal">
        <dt>WebRTC MediaStream:</dt>
        <dd>The MediaStream concept defined by
          the W3C in the <xref
          target="W3C.WD-mediacapture-streams-20130903">WebRTC target="W3C-MEDIA-CAPTURE" format="default">WebRTC API</xref>. A
          MediaStream consists of zero or more MediaStreamTracks.</t>

          <t hangText="MediaStreamTrack:">Part MediaStreamTracks.</dd>
        <dd>Part of the MediaStream concept
          defined by the W3C in the <xref
          target="W3C.WD-mediacapture-streams-20130903">WebRTC target="W3C-MEDIA-CAPTURE" format="default">WebRTC API</xref>. A
          MediaStreamTrack is an individual stream of media from any type of
          media source like such as a microphone or a camera, but also conceptual
          sources, like a
          sources such as an audio mix or a video composition, composition are possible.</t>

          <t hangText="Transport-layer Flow:">A uni-directional also possible.</dd>
        <dt>Transport-layer flow:</dt>
        <dd>A unidirectional flow of
          transport packets that are identified by having a particular 5-tuple
          of source IP address, source port, destination IP address,
          destination port, and transport protocol used.</t>

          <t hangText="Bi-directional Transport-layer Flow:">A bi-directional protocol.</dd>
        <dt>Bidirectional transport-layer flow:</dt>
        <dd>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.</t>
        </list></t> same.</dd>
      <t>This document uses the terminology from <xref
      target="I-D.ietf-avtext-rtp-grouping-taxonomy"></xref> target="RFC7656" format="default"/> and <xref
      target="I-D.ietf-rtcweb-overview"></xref>. target="RFC8825" format="default"/>. Other terms are used
      according to their definitions from the <xref target="RFC3550">RTP
      Specification</xref>. Especially target="RFC3550" format="default">RTP
      specification</xref>. In particular, note the following frequently used
      terms: RTP Stream, stream, RTP Session, session, and Endpoint.</t> endpoint.</t>
    <section anchor="sec-rtp-core" title="WebRTC numbered="true" toc="default">
      <name>WebRTC Use of RTP: Core Protocols"> Protocols</name>
      <t>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 endpoints need to implement to function effectively on today's
      <section anchor="sec-rtp-rtcp" title="RTP numbered="true" toc="default">
        <name>RTP and RTCP"> RTCP</name>
        <t>The <xref target="RFC3550">Real-time target="RFC3550" format="default">Real-time Transport Protocol (RTP)
          </xref> is REQUIRED <bcp14>REQUIRED</bcp14> 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 Control Protocol (RTCP). RTCP is a fundamental
        and integral part of RTP, RTP and MUST <bcp14>MUST</bcp14> be implemented and used in all
        WebRTC Endpoints.</t> endpoints.</t>
        <t>The following RTP and RTCP features are sometimes omitted in
        limited functionality
        limited-functionality implementations of RTP, but they are REQUIRED <bcp14>REQUIRED</bcp14> in all
        WebRTC Endpoints: <list style="symbols">
            <t>Support endpoints: </t>
        <ul spacing="normal">
          <li>Support for use of multiple simultaneous SSRC synchronization source
            (SSRC) values in a
            single RTP session, including support for RTP endpoints that send
            many SSRC values simultaneously, following <xref
            target="RFC3550"></xref> target="RFC3550" format="default"/> and <xref
            target="I-D.ietf-avtcore-rtp-multi-stream"></xref>. target="RFC8108" format="default"/>. The RTCP
            optimizations for multi-SSRC sessions defined in <xref
            MAY target="RFC8861" format="default"/>
            <bcp14>MAY</bcp14> be supported; if supported supported, the usage MUST <bcp14>MUST</bcp14> be signalled.</t>

            <t>Random signaled.</li>
          <li>Random choice of SSRC on joining a session; collision detection
            and resolution for SSRC values (see also <xref

            <t>Support target="sec-ssrc" format="default"/>).</li>
          <li>Support for reception of RTP data packets containing CSRC
            contributing source (CSRC)
            lists, as generated by RTP mixers, and RTCP packets relating to

          <li>Sending correct synchronisation synchronization information in the RTCP Sender
            Reports, to allow receivers to implement lip-synchronisation; lip synchronization; see
            <xref target="rapid-sync"></xref> target="rapid-sync" format="default"/> regarding support for the rapid
            RTP synchronisation extensions.</t>

            <t>Support synchronization extensions.</li>
          <li>Support for multiple synchronisation synchronization contexts. Participants
            that send multiple simultaneous RTP packet streams SHOULD <bcp14>SHOULD</bcp14> do so as
            part of a single synchronisation synchronization context, using a single RTCP
            CNAME for all streams and allowing receivers to play the streams
            out in a synchronised synchronized manner. For compatibility with potential
            future versions of this specification, or for interoperability
            with non-WebRTC devices through a gateway, receivers MUST <bcp14>MUST</bcp14> support
            multiple synchronisation 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, circumstances; see <xref

            <t>Support target="sec-cname" format="default"/>.</li>
          <li>Support for sending and receiving RTCP SR, RR, SDES, Source
          Description (SDES), and BYE
            packet types. Note that support for other RTCP packet types is
            <bcp14>OPTIONAL</bcp14> unless mandated by other parts of this specification.
            Note that additional RTCP Packet packet types are used by the <xref
            target="sec-profile">RTP/SAVPF Profile</xref> target="sec-profile" format="default">RTP/SAVPF profile</xref> and the other <xref
            target="sec-rtp-extn">RTCP target="sec-rtp-extn" format="default">RTCP extensions</xref>. WebRTC endpoints
            that implement the SDP Session Description Protocol (SDP) bundle
            negotiation extension will use the
            SDP grouping framework 'mid' Grouping Framework "mid" attribute to identify media streams.
            Such endpoints MUST <bcp14>MUST</bcp14> implement the RTCP SDES MID media
            identification (MID) item described in
            <xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"></xref>.</t>

            <t>Support target="RFC8843" format="default"/>.</li>
          <li>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 randomised randomized RTCP
            transmission intervals to avoid synchronisation synchronization of RTCP reports;
            support for RTCP timer reconsideration (Section 6.3.6 of <xref
            target="RFC3550"></xref>) (<xref
            target="RFC3550" section="6.3.6" sectionFormat="of"/>) and
            reverse reconsideration (Section
            6.3.4 of <xref target="RFC3550"></xref>).</t>

            <t>Support (<xref target="RFC3550" sectionFormat="of" section="6.3.4"/>).</li>
          <li>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, senders -- e.g., using the SDP "b=" line
            <xref target="RFC4566"></xref><xref target="RFC3556"></xref>.</t>

            <t>Support target="RFC4566" format="default"/> <xref target="RFC3556" format="default"/>.</li>
          <li>Support for the reduced minimum RTCP reporting interval
            described in Section 6.2 of <xref target="RFC3550"></xref>. target="RFC3550"
            sectionFormat="of" section="6.2"/>. When
            using the reduced minimum RTCP reporting interval, the fixed
            (nonreduced) minimum interval MUST <bcp14>MUST</bcp14> be used when calculating the
            participant timeout interval (see Sections 6.2 <xref target="RFC3550"
            section="6.2" sectionFormat="bare"/> and 6.3.5 <xref target="RFC3550"
            section="6.3.5" sectionFormat="bare"/> of <xref
            target="RFC3550" format="default"/>). The delay before sending the
            compound RTCP packet can be set to zero (see Section 6.2 of <xref
            target="RFC3550" section="6.2" sectionFormat="of"/> as updated by <xref

            <t>Support target="RFC8108" format="default"/>).</li>
          <li>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, specific and can be used
            with any RTP payload format.</t>

            <t>Ignore format.</li>
          <li>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 not signalled RTCP packet
            types or receiving RTP header
            extensions being received. or RTCP packet types that were not signaled. If a compound RTCP
            packet is received that contains a mixture of known and unknown
            RTCP packet types, types is received, the known packets packet types need to be processed as
            usual, with only the unknown packet types being discarded.</t>
          </list></t> discarded.</li>
        <t>It is known that a significant number of legacy RTP
        implementations, especially those targeted at VoIP-only systems, systems with
        only Voice over IP (VoIP), do
        not support all of the above features, 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
        <t>Other implementation considerations are discussed in <xref
        target="sec-rtp-func"></xref>.</t> target="sec-rtp-func" format="default"/>.</t>
      <section anchor="sec-profile" title="Choice numbered="true" toc="default">
        <name>Choice of the RTP Profile"> Profile</name>
        <t>The complete specification of RTP for a particular application
        domain requires the choice of an RTP Profile. profile. For WebRTC use, the
        <xref target="RFC5124">Extended Secure target="RFC5124" format="default">extended secure RTP Profile profile for RTCP-Based
        RTCP-based feedback
        (RTP/SAVPF)</xref>, as extended by <xref
        target="RFC7007"></xref>, MUST target="RFC7007" format="default"/>, <bcp14>MUST</bcp14> be implemented. The RTP/SAVPF profile
        is the combination of the basic <xref target="RFC3551">RTP/AVP target="RFC3551" format="default">RTP/AVP
        profile</xref>, the <xref target="RFC4585">RTP target="RFC4585" format="default">RTP profile for RTCP-based
        feedback (RTP/AVPF)</xref>, and the <xref target="RFC3711">secure target="RFC3711" format="default">secure RTP
        profile (RTP/SAVP)</xref>.</t>
        <t>The RTCP-based feedback extensions <xref target="RFC4585"></xref> target="RFC4585" format="default"/>
        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 <xref

        <t><list style="empty">
            <t>Note: target="conf-ext" format="default"/>.</t>

          <aside><t>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
            "trr&nbhy;int". The most important factor for interworking with
            RTP/(S)AVP endpoints via a gateway is to set the trr-int "trr-int" parameter
            to a value representing 4 seconds, seconds; see Section 6.1 in <xref
            target="RFC8108" section="7.1.3" sectionFormat="of"/>.</t>
        <t>The secure RTP (SRTP) profile extensions <xref
        target="RFC3711"></xref> target="RFC3711" format="default"/> are needed to provide media encryption,
        integrity protection, replay protection protection, and a limited form of source
        authentication. WebRTC Endpoints MUST NOT endpoints <bcp14>MUST NOT</bcp14> send packets using the basic
        RTP/AVP profile or the RTP/AVPF profile; they MUST <bcp14>MUST</bcp14> employ the full
        RTP/SAVPF profile to protect all RTP and RTCP packets that are
        generated (i.e.,
        generated. In other words, implementations MUST <bcp14>MUST</bcp14> use SRTP and SRTCP). SRTCP. The
        RTP/SAVPF profile MUST <bcp14>MUST</bcp14> be configured using the cipher suites,
        DTLS-SRTP protection profiles, keying mechanisms, and other parameters
        described in <xref target="I-D.ietf-rtcweb-security-arch"></xref>.</t> target="RFC8827" format="default"/>.</t>
      <section anchor="sec.codecs" title="Choice numbered="true" toc="default">
        <name>Choice of RTP Payload Formats">
        <t>Mandatory to implement Formats</name>
        <t>Mandatory-to-implement audio codecs and RTP payload formats for
        WebRTC endpoints are defined in <xref
        target="I-D.ietf-rtcweb-audio"></xref>. Mandatory to implement target="RFC7874" format="default"/>. Mandatory-to-implement video
        codecs and RTP payload formats for WebRTC endpoints are defined in
        <xref target="I-D.ietf-rtcweb-video"></xref>. target="RFC7742" format="default"/>. WebRTC endpoints MAY <bcp14>MAY</bcp14>
        additionally implement any other codec for which an RTP payload format
        and associated signalling signaling has been defined.</t>
        <t>WebRTC Endpoints 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 <bcp14>MUST</bcp14> 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.</t>
        <t>Endpoints can signal support for multiple RTP payload formats, 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 <xref target="sec-ssrc"></xref>, target="sec-ssrc" format="default"/>,
        the RTP payload type number is sometimes used to associate an RTP
        packet stream with a signalling 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 signalled signaled in the "a=rtpmap:" lines in the
        media sections of the SDP. This leads to the following
        considerations:<list style="empty">
        <ul empty="true" spacing="normal">
          <li>If RTP packet streams are being associated with signalling signaling
            contexts based on the RTP payload type, then the assignment of RTP
            payload type numbers MUST <bcp14>MUST</bcp14> be unique across signalling

            <t>If signaling
          <li>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.</t>

            <t>If uniqueness.</li>
          <li>If the RTP payload type number is not being used to associate
            RTP packet streams with a signalling signaling context, then the same RTP
            payload type number can be used to indicate the exact same RTP
            payload format configuration in multiple contexts.</t>
          </list>A contexts.</li>
        <t>A single RTP payload type number MUST NOT <bcp14>MUST NOT</bcp14> 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 <xref target="I-D.ietf-mmusic-sdp-bundle-negotiation">SDP
        bundle target="RFC8843" format="default">SDP
        BUNDLE group</xref> form a single RTP session).</t>
        <t>An endpoint that has signalled signaled support for multiple RTP payload
        formats MUST <bcp14>MUST</bcp14> be able to accept data in any of those payload formats at
        any time, unless it has previously signalled 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 signalled signaled for the type of media that is being
        sent by that source; see <xref target="sec.session-mux"></xref>. target="sec.session-mux"
        format="default"/>. To
        support rapid rate adaptation by changing codec, codecs, RTP does not require
        advance signalling signaling for changes between RTP payload formats used by a
        single SSRC that were signalled signaled during session set-up.</t> setup.</t>
        <t>If performing changes between two RTP payload types that use
        different RTP clock rates, an RTP sender MUST <bcp14>MUST</bcp14> follow the
        recommendations in Section 4.1 of <xref target="RFC7160"></xref>. target="RFC7160" section="4.1"
        sectionFormat="of"/>. RTP
        receivers MUST <bcp14>MUST</bcp14> follow the recommendations in Section 4.3 of <xref
        target="RFC7160"></xref> target="RFC7160" format="default"/> in order to support sources that switch
        between clock rates in an RTP session (these session. These recommendations for
        receivers are backwards compatible with the case where senders use
        only a single clock rate).</t> rate.</t>
      <section anchor="sec.session-mux" title="Use numbered="true" toc="default">
        <name>Use of RTP Sessions"> Sessions</name>
        <t>An association amongst a set of endpoints communicating using RTP
        is known as an RTP session <xref target="RFC3550"></xref>. target="RFC3550" format="default"/>. 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, audio and a
        separate RTP session using a different transport-layer flow for the
        video). WebRTC Endpoints endpoints are REQUIRED <bcp14>REQUIRED</bcp14> 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).</t>
        <t>In modern day 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 flow. This will
        prevent the use of some quality-of-service mechanisms, as discussed in
        <xref target="sec-differentiated"></xref>). target="sec-differentiated" format="default"/>. Implementations are
        therefore also REQUIRED <bcp14>REQUIRED</bcp14> to support transport of all RTP packet
        streams, independent of media type, in a single RTP session using a
        single transport layer transport-layer flow, according to <xref
        target="I-D.ietf-avtcore-multi-media-rtp-session"></xref> target="RFC8860" format="default"/> (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
        <bcp14>MUST</bcp14> agree to this usage. In an SDP context, the
        mechanisms described in <xref
        target="I-D.ietf-mmusic-sdp-bundle-negotiation"></xref> target="RFC8843" format="default"/> can be used to
        signal such a bundle of RTP packet streams forming a single RTP
        <t>Further discussion about the suitability of different RTP session
        structures and multiplexing methods to different scenarios can be
        found in <xref
        target="I-D.ietf-avtcore-multiplex-guidelines"></xref>.</t> target="I-D.ietf-avtcore-multiplex-guidelines" format="default"/>.</t>
      <section anchor="sec.rtcp-mux" title="RTP numbered="true" toc="default">
        <name>RTP and RTCP Multiplexing"> Multiplexing</name>
        <t>Historically, RTP and RTCP have been run on separate transport
        transport-layer flows (e.g., two UDP ports for each RTP session, one port
        for RTP and one port for RTCP). With the increased use of Network
        Address/Port Translation (NAT/NAPT) (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 set-up setup times,
        implementations are REQUIRED <bcp14>REQUIRED</bcp14> to support multiplexing RTP data packets
        and RTCP control packets on a single transport-layer flow <xref
        target="RFC5761"></xref>. target="RFC5761" format="default"/>. Such RTP and RTCP multiplexing MUST <bcp14>MUST</bcp14> be
        negotiated in the signalling signaling channel before it is used. If SDP is used
        for signalling, signaling, this negotiation MUST <bcp14>MUST</bcp14> use the mechanism defined in
        <xref target="RFC5761"/>. target="RFC5761" format="default"/>. Implementations can also support sending RTP and RTCP on
        separate transport-layer flows, but this is OPTIONAL <bcp14>OPTIONAL</bcp14> to implement.  If
        an implementation does not support RTP and RTCP sent on separate
        transport-layer flows, it MUST <bcp14>MUST</bcp14> indicate that using the mechanism
        defined in <xref target="I-D.ietf-mmusic-mux-exclusive"/>. target="RFC8858" format="default"/>.
        <t>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 <xref target="RFC6263"></xref>.</t> target="RFC6263" format="default"/>.</t>
      <section title="Reduced numbered="true" toc="default">
        <name>Reduced Size RTCP"> RTCP</name>
        <t>RTCP packets are usually sent as compound RTCP packets, and <xref
        target="RFC3550"></xref> target="RFC3550" format="default"/> requires that those compound packets start
        with an a Sender Report (SR) or Receiver Report (RR) packet. When using
        frequent RTCP feedback messages under the RTP/AVPF Profile profile <xref
        target="RFC4585"></xref> target="RFC4585" format="default"/>, 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.</t>
        <t>To avoid this problem, <xref target="RFC5506"></xref> target="RFC5506" format="default"/> 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, conditions and
        to allow them to adapt their transmission and encoding behaviour. behavior.
        Implementations MUST <bcp14>MUST</bcp14> support sending and receiving non-compound noncompound RTCP
        feedback packets <xref target="RFC5506"></xref>. target="RFC5506" format="default"/>. Use of non-compound noncompound
        RTCP packets MUST <bcp14>MUST</bcp14> be negotiated using the signalling signaling channel. If SDP
        is used for signalling, signaling, this negotiation MUST <bcp14>MUST</bcp14> use the attributes
        defined in <xref target="RFC5506"></xref>. target="RFC5506" format="default"/>. For backwards
        compatibility, implementations are also REQUIRED <bcp14>REQUIRED</bcp14> to support the use of
        compound RTCP feedback packets if the remote endpoint does not agree
        to the use of non-compound noncompound RTCP in the signalling signaling exchange.</t>
      <section title="Symmetric RTP/RTCP"> numbered="true" toc="default">
        <name>Symmetric RTP/RTCP</name>
        <t>To ease traversal of NAT and firewall devices, implementations are
        <bcp14>REQUIRED</bcp14> to implement and use <xref target="RFC4961">Symmetric target="RFC4961" format="default">symmetric
        RTP</xref>. The reason for using symmetric RTP is primarily to avoid
        issues with NATs and Firewalls firewalls by ensuring that the send and receive
        RTP packet streams, as well as RTCP, are actually bi-directional 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 as network, because the NAT mappings or firewall state is not
        unnecessarily bloated. The amount of per flow per-flow QoS state kept in the
        network is also reduced.</t>
      <section anchor="sec-ssrc"
               title="Choice numbered="true" toc="default">
        <name>Choice of RTP Synchronisation Synchronization Source (SSRC)"> (SSRC)</name>
        <t>Implementations are REQUIRED <bcp14>REQUIRED</bcp14> to support signalled signaled RTP
        synchronization source (SSRC) identifiers. If SDP is used, this MUST <bcp14>MUST</bcp14>
        be done using the "a=ssrc:" SDP attribute defined in Section 4.1 Sections <xref
        target="RFC5576" sectionFormat="bare" section="4.1" format="default"/>
        Section 5 <xref target="RFC5576" sectionFormat="bare" section="5"
        format="default"/> of <xref target="RFC5576"></xref> target="RFC5576"/> and the "previous-ssrc" source attribute defined in Section 6.2 of <xref
        target="RFC5576"></xref>; target="RFC5576"
        sectionFormat="of" section="6.2" format="default"/>; other per-SSRC attributes defined in <xref
        target="RFC5576"></xref> MAY target="RFC5576" format="default"/> <bcp14>MAY</bcp14> be supported.</t>
        <t>While support for signalled signaled SSRC identifiers is mandated, their use
        in an RTP session is OPTIONAL. <bcp14>OPTIONAL</bcp14>. Implementations MUST <bcp14>MUST</bcp14> be prepared to
        accept RTP and RTCP packets using SSRCs that have not been explicitly
        signaled ahead of time. Implementations MUST <bcp14>MUST</bcp14> support random SSRC
        assignment and MUST <bcp14>MUST</bcp14> support SSRC collision detection and resolution,
        according to <xref target="RFC3550"></xref>. target="RFC3550" format="default"/>. When using signalled signaled SSRC
        values, collision detection MUST <bcp14>MUST</bcp14> be performed as described in Section
        5 of
        <xref target="RFC5576"></xref>.</t> target="RFC5576" sectionFormat="of" section="5" format="default"/>.</t>
        <t>It is often desirable to associate an RTP packet stream with a
        non-RTP context. For users of the WebRTC API API, a mapping between SSRCs
        and MediaStreamTracks are is provided per <xref
        target="sec-webrtc-api"></xref>. target="sec-webrtc-api" format="default"/>. For gateways or other usages usages, it is
        possible to associate an RTP packet stream with an "m=" line in a
        session description formatted using SDP. If SSRCs are signalled signaled, this
        is straightforward (in SDP SDP, the "a=ssrc:" line will be at the media
        level, allowing a direct association with an "m=" line). If SSRCs are
        not signalled, signaled, the RTP payload type numbers used in an RTP packet
        stream are often sufficient to associate that packet stream with a
        signalling context (e.g.,
        signaling context. For example, if RTP payload type numbers are assigned as
        described in <xref target="sec.codecs"></xref> target="sec.codecs" format="default"/> 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, SDP and so
        map to an "m=" line).</t> line.</t>
      <section anchor="sec-cname"
               title="Generation numbered="true" toc="default">
        <name>Generation of the RTCP Canonical Name (CNAME)"> (CNAME)</name>
        <t>The RTCP Canonical Name (CNAME) provides a persistent
        transport-level identifier for an RTP endpoint. While the
        Synchronisation Source (SSRC)
        SSRC identifier for an RTP endpoint can
        change if a collision is detected, detected or when the RTP application is
        restarted, its RTCP CNAME is meant to stay unchanged for the duration
        of a an <xref target="W3C.WD-webrtc-20130910">RTCPeerConnection</xref>, target="W3C.WebRTC" format="default">RTCPeerConnection</xref>,
        so that RTP endpoints can be uniquely identified and associated with
        their RTP packet streams within a set of related RTP sessions.</t>
        <t>Each RTP endpoint MUST <bcp14>MUST</bcp14> have at least one RTCP CNAME, and that RTCP
        CNAME MUST <bcp14>MUST</bcp14> be unique within the RTCPeerConnection. RTCP CNAMEs
        identify a particular synchronisation context, 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 unsynchronised unsynchronized
        reference clocks, and hence different synchronisation synchronization contexts, it
        will need to use multiple RTCP CNAMEs, one for each synchronisation synchronization
        <t>Taking the discussion in <xref target="sec-webrtc-api"></xref> target="sec-webrtc-api" format="default"/> into
        account, a WebRTC Endpoint MUST NOT endpoint <bcp14>MUST NOT</bcp14> use more than one RTCP CNAME in
        the RTP sessions belonging to a single RTCPeerConnection (that is, an
        RTCPeerConnection forms a synchronisation synchronization context). RTP middleboxes
        <bcp14>MAY</bcp14> 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 multi-party multiparty RTP
        <t>The <xref target="RFC3550">RTP target="RFC3550" format="default">RTP specification</xref> 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 <xref
        target="sec-security">privacy target="sec-security" format="default">privacy viewpoint</xref>. Accordingly, a WebRTC
        Endpoint MUST
        endpoint <bcp14>MUST</bcp14> generate a new, unique, short-term persistent RTCP CNAME
        for each RTCPeerConnection, following <xref target="RFC7022"></xref>, target="RFC7022" format="default"/>,
        with a single exception; if explicitly requested at creation creation, an
        RTCPeerConnection MAY <bcp14>MAY</bcp14> use the same CNAME as as an existing
        RTCPeerConnection within their common same-origin context.</t>

        <t>A WebRTC Endpoint MUST endpoint <bcp14>MUST</bcp14> support reception of any CNAME that matches
        the syntax limitations specified by the <xref target="RFC3550">RTP target="RFC3550" format="default">RTP
        specification</xref> and cannot assume that any CNAME will be chosen
        according to the form suggested above.</t>
      <section anchor="sec-leap-sec" title="Handling numbered="true" toc="default">
        <name>Handling of Leap Seconds"> Seconds</name>
        <t>The guidelines given in <xref target="RFC7164" format="default"/> regarding
        handling of leap seconds to limit their
        impact on RTP media play-out and synchronization given in <xref
        target="RFC7164"></xref> SHOULD <bcp14>SHOULD</bcp14> be followed.</t>
    <section anchor="sec-rtp-extn" title="WebRTC numbered="true" toc="default">
      <name>WebRTC Use of RTP: Extensions"> Extensions</name>
      <t>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.</t>
      <section anchor="conf-ext"
               title="Conferencing numbered="true" toc="default">
        <name>Conferencing Extensions and Topologies"> Topologies</name>
        <t>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
        <xref target="I-D.ietf-avtcore-rtp-topologies-update"></xref>.</t> target="RFC7667" format="default"/>.</t>
        <t>While the use of IP multicast groups is popular in IPTV systems,
        the topologies based on RTP middleboxes are dominant in interactive
        video conferencing
        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 endpoints are not
        expected to support topologies based on IP multicast groups or to
        mesh-based topologies, such as a point-to-multipoint mesh
        configured as a single RTP session (Topo-Mesh ("Topo-Mesh" in the terminology of
        <xref target="I-D.ietf-avtcore-rtp-topologies-update"></xref>). target="RFC7667" format="default"/>).
        However, a point-to-multipoint mesh constructed using several RTP
        sessions, implemented in WebRTC using independent <xref
        target="W3C.WD-webrtc-20130910">RTCPeerConnections</xref>, target="W3C.WebRTC" format="default">RTCPeerConnections</xref>, can be
        expected to be used in WebRTC, WebRTC and needs to be supported.</t>
        <t>WebRTC Endpoints endpoints implemented according to this memo are expected to
        support all the topologies described in <xref
        target="I-D.ietf-avtcore-rtp-topologies-update"></xref> target="RFC7667" format="default"/> 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: <list style="symbols">
            <t>Video switching MCUs </t>
        <ul spacing="normal">
          <li>Video-switching Multipoint Control Units (MCUs) (Topo-Video-switch-MCU) SHOULD NOT <bcp14>SHOULD NOT</bcp14> be
            used, since they make the use of RTCP for congestion control and
            quality of service
            quality-of-service reports problematic (see Section 3.8 of <xref

            target="RFC7667" section="3.8" sectionFormat="of"/>).</li>
          <li>The Relay-Transport Translator (Topo-PtM-Trn-Translator)
            topology SHOULD NOT <bcp14>SHOULD NOT</bcp14> be used used, because its safe use requires a
            congestion control algorithm or RTP circuit breaker that handles
            point to multipoint, which has not yet been standardised.</t>
          </list></t> standardized.</li>
        <t>The following topology can be used, however it has some issues
        worth noting:<list style="symbols">
            <t>Content modifying noting:</t>
        <ul spacing="normal">
          <li>Content-modifying MCUs with RTCP termination
            (Topo-RTCP-terminating-MCU) MAY <bcp14>MAY</bcp14> 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 <xref
          </list></t> target="RFC7667"
            section="3.9" sectionFormat="of"/>).</li>
        <t>The RTP extensions described in Sections <xref target="sec-fir"></xref> target="sec-fir" format="counter"/> to <xref target="sec.tmmbr"></xref> target="sec.tmmbr" format="counter"/> 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, correctly but might offer poor performance.
        Support for the listed extensions will greatly improve the quality of
        experience and,
        experience; to provide a reasonable baseline quality, some of
        these extensions are mandatory to be supported by WebRTC
        <t>The RTCP conferencing extensions are defined in <xref
        target="RFC4585" format="default">"Extended RTP Profile for Real-time
        Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)</xref> (RTP/AVPF)"</xref>
        and the memo on <xref
        target="RFC5104">Codec target="RFC5104" format="default">"Codec Control
        Messages (CCM) in RTP/AVPF</xref>; the RTP Audio-Visual Profile with Feedback (AVPF)"</xref>; they
        are fully usable by the <xref target="RFC5124">Secure target="RFC5124" format="default"> secure variant of this
        profile (RTP/SAVPF)</xref>.</t>
        <section anchor="sec-fir" title="Full numbered="true" toc="default">
          <name>Full Intra Request (FIR)"> (FIR)</name>
          <t>The Full Intra Request message is defined in Sections 3.5.1 <xref
          target="RFC5104" section="3.5.1" sectionFormat="bare"/> and
          <xref target="RFC5104" section="4.3.1" sectionFormat="bare"/> of the <xref target="RFC5104">Codec target="RFC5104" format="default">Codec Control Messages</xref>.
          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 <bcp14>MUST</bcp14> understand and react to FIR
          feedback messages they receive, since this greatly improves the user
          experience when using centralised centralized mixer-based conferencing. Support
          for sending FIR messages is OPTIONAL.</t> <bcp14>OPTIONAL</bcp14>.</t>
        <section title="Picture numbered="true" toc="default">
          <name>Picture Loss Indication (PLI)"> (PLI)</name>
          <t>The Picture Loss Indication message is defined in Section 6.3.1
          of the
          <xref target="RFC4585">RTP/AVPF target="RFC4585" section="6.3.1" sectionFormat="of">the RTP/AVPF profile</xref>. 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 above, as there
          could be multiple ways to fulfil fulfill the request. WebRTC Endpoints endpoints that
          are sending media MUST <bcp14>MUST</bcp14> understand and react to PLI feedback messages
          as a loss tolerance loss-tolerance mechanism. Receivers MAY <bcp14>MAY</bcp14> send PLI messages.</t>
        <section title="Slice numbered="true" toc="default">
          <name>Slice Loss Indication (SLI)"> (SLI)</name>
          <t>The Slice Loss Indication message is defined in Section 6.3.2 of
          the <xref target="RFC4585">RTP/AVPF
          target="RFC4585" section="6.3.2" sectionFormat="of">the RTP/AVPF profile</xref>. 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, blocks and would like
          to have these repaired somehow. It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> 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 <bcp14>SHOULD</bcp14> attempt to repair the lost slice(s).</t>
        <section title="Reference numbered="true" toc="default">
          <name>Reference Picture Selection Indication (RPSI)"> (RPSI)</name>
          <t>Reference Picture Selection Indication (RPSI) messages are
          defined in Section 6.3.3 of the <xref target="RFC4585">RTP/AVPF target="RFC4585"
          section="6.3.3" sectionFormat="of">the RTP/AVPF
          profile </xref>. Some video encoding 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 learnt learned
          that encoder-decoder synchronisation synchronization has been lost, then a known as
          known-as-correct reference picture can be used as a base for future
          coding. The RPSI message allows this to be signalled. signaled. Receivers that
          detect that encoder-decoder synchronisation synchronization has been lost SHOULD <bcp14>SHOULD</bcp14>
          generate an RPSI feedback message if the codec being used supports reference
          reference-picture selection. A An RTP packet stream packet-stream sender that
          receives such an
          RPSI message SHOULD <bcp14>SHOULD</bcp14> 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.</t>
        <section title="Temporal-Spatial Trade-off numbered="true" toc="default">
          <name>Temporal-Spatial Trade-Off Request (TSTR)"> (TSTR)</name>
          <t>The temporal-spatial trade-off request and notification are
          defined in Sections 3.5.2 <xref target="RFC5104" section="3.5.2"
          sectionFormat="bare"/> and 4.3.2 <xref target="RFC5104" section="4.3.2" sectionFormat="bare"/> of <xref
          target="RFC5104"></xref>. target="RFC5104" format="default"/>. This request can be used to ask the video
          encoder to change the trade-off it makes between temporal and
          spatial resolution, resolution -- for example example, to prefer high spatial image quality
          but low frame rate. Support for TSTR requests and notifications is
        <section anchor="sec.tmmbr"
                 title="Temporary numbered="true" toc="default">
          <name>Temporary Maximum Media Stream Bit Rate Request (TMMBR)"> (TMMBR)</name>
          <t>The TMMBR Temporary Maximum Media Stream Bit Rate Request (TMMBR) feedback message is defined in Sections 3.5.4 <xref
          target="RFC5104" section="3.5.4" sectionFormat="bare"/> and 4.2.1 <xref
          target="RFC5104" section="4.2.1" sectionFormat="bare"/>
          of the <xref target="RFC5104">Codec target="RFC5104" format="default">Codec Control Messages</xref>. This
          request and its notification corresponding Temporary Maximum Media Stream Bit
          Rate Notification (TMMBN) message <xref target="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 endpoints that are
          sending media are REQUIRED <bcp14>REQUIRED</bcp14> to implement support for TMMBR messages, messages
          and MUST <bcp14>MUST</bcp14> follow bandwidth limitations set by a TMMBR message
          received for their SSRC. The sending of TMMBR requests messages is
      <section title="Header Extensions"> numbered="true" toc="default">
        <name>Header Extensions</name>
        <t>The <xref target="RFC3550">RTP target="RFC3550" format="default">RTP specification</xref> 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 <bcp14>OPTIONAL</bcp14> in WebRTC, but if they are
        used, they MUST <bcp14>MUST</bcp14> be formatted and signalled signaled following the general
        mechanism for RTP header extensions defined in <xref
        target="RFC5285"></xref>, target="RFC8285" format="default"/>, since this gives well-defined semantics to
        RTP header extensions.</t>
        <t>As noted in <xref target="RFC5285"></xref>, target="RFC8285" format="default"/>, the requirement from
        the RTP specification that header extensions are "designed so that the
        header extension may be ignored" <xref target="RFC3550"></xref> target="RFC3550" format="default"/>
        stands. To be specific, header extensions MUST <bcp14>MUST</bcp14> only be used for data
        that can safely be ignored by the recipient without affecting
        interoperability and MUST NOT <bcp14>MUST NOT</bcp14> 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 signalled 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
        <section anchor="rapid-sync" title="Rapid Synchronisation"> numbered="true" toc="default">
          <name>Rapid Synchronization</name>
          <t>Many RTP sessions require synchronisation synchronization between audio, video,
          and other content. This synchronisation synchronization is performed by receivers,
          using information contained in RTCP SR packets, as described in the
          <xref target="RFC3550">RTP target="RFC3550" format="default">RTP specification</xref>. This basic
          mechanism can be slow, however, so it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the rapid
          RTP synchronisation synchronization extensions described in <xref
          target="RFC6051"></xref> target="RFC6051" format="default"/> be implemented in addition to RTCP SR-based
          <t>This header extension uses the <xref target="RFC5285"></xref>
          generic header extension framework, framework described in <xref
          target="RFC8285" format="default"/> and so needs to be negotiated
          before it can be used.</t>
        <section anchor="sec-client-to-mixer"
                 title="Client-to-Mixer numbered="true" toc="default">
          <name>Client-to-Mixer Audio Level"> Level</name>
          <t>The <xref target="RFC6464">Client to Mixer Audio Level target="RFC6464" format="default">client-to-mixer audio level
          extension</xref> 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.</t>
          <t>The <xref target="RFC6464">Client-to-Mixer Audio Level</xref> target="RFC6464" format="default">client-to-mixer audio level header
          extension MUST </xref> <bcp14>MUST</bcp14> be implemented. It is REQUIRED <bcp14>REQUIRED</bcp14> that
          implementations are be capable of encrypting the header extension
          according to <xref target="RFC6904"></xref> target="RFC6904" format="default"/>, since the information
          contained in these header extensions can be considered sensitive.
          The use of this encryption is RECOMMENDED, however <bcp14>RECOMMENDED</bcp14>; however, usage of the
          encryption can be explicitly disabled through API or signalling.</t> signaling.</t>

          <t>This header extension uses the <xref target="RFC5285"></xref>
          generic header extension framework, framework described in <xref
          target="RFC8285" format="default"/> and so needs to be negotiated
          before it can be used.</t>
        <section anchor="sec-mixer-to-client"
                 title="Mixer-to-Client numbered="true" toc="default">
          <name>Mixer-to-Client Audio Level"> Level</name>
          <t>The <xref target="RFC6465">Mixer to Client Audio Level target="RFC6465" format="default">mixer-to-client audio level header
          extension</xref> provides an endpoint with the audio level of the
          different sources mixed into a common source stream by a 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 optimisation optimization of non
          critical functions, non-critical functions and is hence OPTIONAL <bcp14>OPTIONAL</bcp14> to implement. If this
          header extension is implemented, it is REQUIRED <bcp14>REQUIRED</bcp14> that implementations
          be capable of encrypting the header extension according to <xref
          target="RFC6904"></xref> target="RFC6904" format="default"/>, since the information contained in these
          header extensions can be considered sensitive. It is further
          <bcp14>RECOMMENDED</bcp14> that this encryption is be used, unless the encryption has
          been explicitly disabled through API or signalling.</t> signaling.</t>

          <t>This header extension uses the <xref target="RFC5285"></xref>
          generic header extension framework, framework described in <xref
          target="RFC8285" format="default"/> and so needs to be negotiated
          before it can be used.</t>
        <section anchor="sec-mid" title="Media numbered="true" toc="default">
          <name>Media Stream Identification"> Identification</name>
          <t>WebRTC endpoints that implement the SDP bundle negotiation
          extension will use the SDP grouping framework 'mid' Grouping Framework "mid" attribute to
          identify media streams. Such endpoints MUST <bcp14>MUST</bcp14> implement the RTP MID
          header extension described in <xref
          target="I-D.ietf-mmusic-sdp-bundle-negotiation"></xref>.</t> target="RFC8843" format="default"/>.</t>
          <t>This header extension uses the <xref target="RFC5285"></xref>
          generic header extension framework, framework described in <xref
          target="RFC8285" format="default"/> and so needs to be negotiated
          before it can be used.</t>
        <section anchor="sec-cvo" title="Coordination numbered="true" toc="default">
          <name>Coordination of Video Orientation"> Orientation</name>
          <t>WebRTC endpoints that send or receive video MUST <bcp14>MUST</bcp14> implement the
          coordination of video orientation (CVO) RTP header extension as
          described in Section 4 of <xref
          target="I-D.ietf-rtcweb-video"></xref>.</t> target="RFC7742" section="4" sectionFormat="of"/>.</t>
          <t>This header extension uses the <xref target="RFC5285"></xref>
          generic header extension framework, framework described in <xref
          target="RFC8285" format="default"/> and so needs to be negotiated
          before it can be used.</t>

    <section anchor="sec-rtp-robust"
             title="WebRTC numbered="true" toc="default">
      <name>WebRTC Use of RTP: Improving Transport Robustness"> Robustness</name>
      <t>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 bit-rate MUST bitrate <bcp14>MUST</bcp14> be rate
      controlled to avoid causing network congestion (see <xref
      target="sec-rate-control"></xref>). target="sec-rate-control" format="default"/>). As a result, improving robustness
      might require a lower base encoding quality, quality but has the potential to
      deliver that quality with fewer errors. The mechanisms described in the
      following sub-sections subsections can be used to improve tolerance to packet
      <section anchor="sec-rtx"
               title="Negative numbered="true" toc="default">
        <name>Negative Acknowledgements and RTP Retransmission"> Retransmission</name>
        <t>As a consequence of supporting the RTP/SAVPF profile,
        implementations can send negative acknowledgements (NACKs) for RTP
        data packets <xref target="RFC4585"></xref>. target="RFC4585" format="default"/>. 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 optimise optimize the user experience by adapting the
        media encoding to compensate for known lost packets.</t>
        <t>RTP packet stream senders are REQUIRED <bcp14>REQUIRED</bcp14> to understand the Generic generic
        NACK message defined in Section 6.2.1 of <xref
        target="RFC4585"></xref>, target="RFC4585"
        sectionFormat="of" section="6.2.1"/>, but MAY they <bcp14>MAY</bcp14> choose to ignore some or all of this
        feedback (following Section 4.2 of <xref target="RFC4585"></xref>). target="RFC4585"
        sectionFormat="of" section="4.2"/>).
        Receivers MAY <bcp14>MAY</bcp14> send NACKs for missing RTP packets. Guidelines on when
        to send NACKs are provided in <xref target="RFC4585"></xref>. target="RFC4585" format="default"/>. It is
        not expected that a receiver will send a NACK for every lost RTP
        packet, rather
        packet; rather, it needs to consider the cost of sending NACK feedback, feedback
        and the importance of the lost packet, packet to make an informed decision on
        whether it is worth telling the sender about a packet loss packet-loss event.</t>
        <t>The <xref target="RFC4588">RTP Retransmission Payload Format</xref> target="RFC4588" format="default">RTP retransmission payload format</xref>
        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 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
        <xref target="RFC3550"></xref>). target="RFC3550" section="6.4.1" sectionFormat="of"/>). The use of
        retransmissions can also increase the forward RTP bandwidth, bandwidth and can
        potentially caused 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 needs need
        to be considered before RTP retransmission is used.</t>
        <t>Receivers are REQUIRED <bcp14>REQUIRED</bcp14> to implement support for RTP retransmission
        packets <xref target="RFC4588"></xref> target="RFC4588" format="default"/> sent using SSRC multiplexing, multiplexing
        and MAY <bcp14>MAY</bcp14> also support RTP retransmission packets sent using session
        multiplexing. Senders MAY <bcp14>MAY</bcp14> send RTP retransmission packets in response
        to NACKs if support for the RTP retransmission payload format has been
        negotiated and if 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.</t>
      <section anchor="sec-FEC" title="Forward numbered="true" toc="default">
        <name>Forward Error Correction (FEC)"> (FEC)</name>
        <t>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. It needs to be noted Note that using redundant encoding
        or FEC will lead to increased play out play-out delay, which needs to be
        considered when choosing FEC schemes and their parameters.</t>
        <t>WebRTC endpoints MUST <bcp14>MUST</bcp14> follow the recommendations for FEC use given
        in <xref target="I-D.ietf-rtcweb-fec"></xref>. target="RFC8854" format="default"/>. WebRTC endpoints MAY <bcp14>MAY</bcp14>
        support other types of FEC, but these MUST <bcp14>MUST</bcp14> be negotiated before they
        are used.</t>
    <section anchor="sec-rate-control"
             title="WebRTC numbered="true" toc="default">
      <name>WebRTC Use of RTP: Rate Control and Media Adaptation"> Adaptation</name>
      <t>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 bit-rates, 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, bit rate, 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 endpoints <bcp14>MUST</bcp14>
      ensure that the RTP traffic they generate can adapt to match changes in
      the available network capacity.</t>
      <t>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
      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).</t>
      <t>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 <xref target="I-D.ietf-rmcat-cc-requirements"></xref>. target="RFC8836" format="default"/>.
      If a standardized congestion control algorithm that satisfies these
      requirements is developed in the future, this memo will need to be be
      updated to mandate its use.</t>
      <section title="Boundary numbered="true" toc="default">
        <name>Boundary Conditions and Circuit Breakers"> Breakers</name>
        <t>WebRTC Endpoints MUST endpoints <bcp14>MUST</bcp14> implement the RTP circuit breaker algorithm
        that is described in <xref
        target="I-D.ietf-avtcore-rtp-circuit-breakers"></xref>. target="RFC8083" format="default"/>. The RTP
        circuit breaker is designed to enable applications to recognise 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 <bcp14>MUST</bcp14> 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.</t>
        <t>The session establishment signalling session-establishment signaling will also necessarily
        establish boundaries to which the media bit-rate bitrate will conform. The
        choice of media codecs provides upper- upper and lower-bounds lower bounds on the
        supported bit-rates bitrates that the application can utilise utilize to provide useful
        quality, and the packetisation packetization choices that exist. In addition, the
        signaling channel can establish maximum media bit-rate bitrate boundaries
        using, for example, the SDP "b=AS:" or "b=CT:" lines and the RTP/AVPF
        Temporary Maximum Media Stream Bit Rate (TMMBR) Requests
        TMMBR messages (see <xref
        target="sec.tmmbr"></xref> target="sec.tmmbr" format="default"/> of this memo). Signalled Signaled bandwidth
        limitations, such as SDP "b=AS:" or "b=CT:" lines received from the
        peer, MUST <bcp14>MUST</bcp14> be followed when sending RTP packet streams. A WebRTC
        endpoint receiving media SHOULD <bcp14>SHOULD</bcp14> signal its bandwidth limitations.
        These limitations have to be based on known bandwidth limitations, for
        example the capacity of the edge links.</t>
      <section title="Congestion numbered="true" toc="default">
        <name>Congestion Control Interoperability and Legacy Systems"> Systems</name>
        <t>All endpoints that wish to interwork with WebRTC MUST <bcp14>MUST</bcp14> implement
        RTCP and provide congestion feedback via the defined RTCP reporting
        <t>When interworking with legacy implementations that support RTCP
        using the <xref target="RFC3551">RTP/AVP target="RFC3551" format="default">RTP/AVP profile</xref>, congestion
        feedback is provided in RTCP RR packets every few seconds.
        Implementations that have to interwork with such endpoints MUST <bcp14>MUST</bcp14> ensure
        that they keep within the <xref
        target="I-D.ietf-avtcore-rtp-circuit-breakers"> RTP target="RFC8083" format="default">RTP
        circuit breaker</xref> constraints to limit the
        congestion they can cause.</t>
        <t>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 purpose purposes such as <xref
        target="RFC5104"> target="RFC5104" format="default"> TMMBR</xref>. Implementations that have to interwork
        with such endpoints MUST <bcp14>MUST</bcp14> ensure that they stay within
        the <xref
        target="I-D.ietf-avtcore-rtp-circuit-breakers"> target="RFC8083" format="default"> RTP circuit
        breaker</xref> 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.</t>
        <t>With proprietary congestion control algorithms 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, controlled when the other
        direction is not controlled. This memo cannot mandate behaviour behavior for
        proprietary congestion control algorithms, but implementations that
        use such algorithms ought to be aware of this issue, issue and try to ensure
        that effective congestion control is negotiated for media flowing in
        both directions. If the IETF were to standardise 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.</t>
    <section anchor="sec-perf"
             title="WebRTC numbered="true" toc="default">
      <name>WebRTC Use of RTP: Performance Monitoring"> Monitoring</name>
      <t>As described in <xref target="sec-rtp-rtcp"></xref>, target="sec-rtp-rtcp" format="default"/>, implementations
      are REQUIRED <bcp14>REQUIRED</bcp14> to generate RTCP Sender Report (SR) and Reception 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 packet-loss and jitter statistics.</t>
      <t>A large number of additional performance metrics are supported by the
      RTCP Extended Reports (XR) framework, framework; see <xref
      target="RFC3611"></xref><xref target="RFC6792"></xref>. target="RFC3611"
      format="default"/> and <xref target="RFC6792" format="default"/>. 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 <bcp14>MAY</bcp14> generate RTCP XR packets as appropriate. The use of
      RTCP XR packets SHOULD <bcp14>SHOULD</bcp14> be signalled; signaled; implementations MUST <bcp14>MUST</bcp14> ignore RTCP XR
      packets that are unexpected or not understood.</t>
    <section anchor="sec-extn" title="WebRTC numbered="true" toc="default">
      <name>WebRTC Use of RTP: Future Extensions"> Extensions</name>
      <t>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 the <xref target="RFC2736"> Guidelines target="RFC2736" format="default">"Guidelines for Writers of RTP
      Payload Format Specifications </xref>, Specifications"</xref>, <xref
      target="I-D.ietf-payload-rtp-howto">How target="RFC8088" format="default">"How to Write an RTP Payload
      Format"</xref>, and <xref target="RFC5968"> Guidelines target="RFC5968" format="default">"Guidelines for Extending the
      RTP Control Protocol</xref>, and SHOULD Protocol (RTCP)"</xref>. They also <bcp14>SHOULD</bcp14> take into account any future
      guidelines for extending RTP and related protocols that have been
      <t>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.</t>
    <section anchor="sec-signalling" title="Signalling Considerations"> numbered="true" toc="default">
      <name>Signaling Considerations</name>
      <t>RTP is built with the assumption that an external signalling 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

      <t><list style="hanging">
          <t hangText="RTP Profile:">The
      <dl newline="false" spacing="normal">
        <dt>RTP profile:</dt>
        <dd>The name of the RTP profile to be used in the
          session. The <xref target="RFC3551">RTP/AVP</xref> target="RFC3551" format="default">RTP/AVP</xref> and <xref
          target="RFC4585">RTP/AVPF</xref> target="RFC4585" format="default">RTP/AVPF</xref> profiles can interoperate on a basic
          level, as can their secure variants variants, <xref
          target="RFC3711">RTP/SAVP</xref> target="RFC3711" format="default">RTP/SAVP</xref> and <xref
          target="RFC5124">RTP/SAVPF</xref>. target="RFC5124" format="default">RTP/SAVPF</xref>. The secure variants of the
          profiles do not directly interoperate with the non-secure 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 <bcp14>MUST</bcp14> be
          signaled. Interworking functions might transform this into the
          RTP/SAVP profile for a legacy use case, case by indicating to the WebRTC
          endpoint that the RTP/SAVPF is used and configuring a trr-int "trr-int" value
          of 4 seconds.</t>

          <t hangText="Transport Information:">Source seconds.</dd>
        <dt>Transport information:</dt>
        <dd>Source and destination IP
          address(es) and ports for RTP and RTCP MUST <bcp14>MUST</bcp14> be signalled signaled for each RTP
          session. In WebRTC WebRTC, these transport addresses will be provided by
          <xref target="RFC5245">ICE</xref> target="RFC8445" format="default">Interactive Connectivity Establishment
          (ICE)</xref> that signals candidates and
          arrives at nominated candidate address pairs. If <xref
          target="RFC5761">RTP target="RFC5761" format="default">RTP and RTCP multiplexing</xref> is to be used, used
          such that a single port, i.e. port -- i.e., transport-layer flow, flow -- is used for RTP
          and RTCP flows, this MUST <bcp14>MUST</bcp14> be signalled signaled (see <xref

          hangText="RTP Payload Types, target="sec.rtcp-mux" format="default"/>).</dd>
        <dt>RTP payload types, media formats, and format parameters:">The parameters:</dt>
          mapping between media type names (and hence the RTP payload formats
          to be used), used) and the RTP payload type numbers MUST <bcp14>MUST</bcp14> be signalled. signaled.
          Each media type MAY <bcp14>MAY</bcp14> also have a number of media type parameters that
          <bcp14>MUST</bcp14> also be signalled signaled to configure the codec and RTP payload format
          (the "a=fmtp:" line from SDP). <xref target="sec.codecs"></xref> target="sec.codecs" format="default"/> of
          this memo discusses requirements for uniqueness of payload

          <t hangText="RTP Extensions:">The
        <dt>RTP extensions:</dt>
        <dd>The use of any additional RTP header
          extensions and RTCP packet types, including any necessary
          parameters, MUST <bcp14>MUST</bcp14> be signalled. signaled. This signalling is to ensure signaling ensures
          that a WebRTC Endpoint's behaviour, endpoint’s behavior, especially when sending, of any
          extensions is predictable and consistent. For robustness, robustness and for
          compatibility with non-WebRTC systems that might be connected to a
          WebRTC session via a gateway, implementations are REQUIRED <bcp14>REQUIRED</bcp14> to ignore
          unknown RTCP packets and RTP header extensions (see also <xref

          <t hangText="RTCP Bandwidth:">Support target="sec-rtp-rtcp" format="default"/>).</dd>
        <dt>RTCP bandwidth:</dt>
        <dd>Support for exchanging RTCP Bandwidth bandwidth
          values to with the endpoints will be necessary. This SHALL <bcp14>SHALL</bcp14> be done as
          described in <xref target="RFC3556">"Session target="RFC3556" format="default">"Session Description Protocol
          (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP)
          Bandwidth"</xref> 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, important to prevent differences in RTCP
          packet timing and timeout intervals causing interoperability
      <t>These parameters are often expressed in SDP messages conveyed within
      an offer/answer exchange. RTP does not depend on SDP or on the
      offer/answer model, model but does require all the necessary parameters to be
      agreed upon, upon and provided to the RTP implementation. Note that in WebRTC WebRTC,
      it will depend on the signalling signaling model and API how these parameters need
      to be configured configured, but they will be need to either be set in the API or
      explicitly signalled signaled between the peers.</t>
    <section anchor="sec-webrtc-api" title="WebRTC numbered="true" toc="default">
      <name>WebRTC API Considerations"> Considerations</name>
      <t>The <xref target="W3C.WD-webrtc-20130910">WebRTC target="W3C.WebRTC" format="default">WebRTC API</xref> and the
      <xref target="W3C.WD-mediacapture-streams-20130903">Media target="W3C-MEDIA-CAPTURE" format="default">Media Capture and
      Streams API</xref> defines define and uses 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 like source, such as a
      microphone or a camera, but also conceptual sources, like a an audio mix or
      a video composition, are also possible. The MediaStreamTracks within a
      MediaStream might need to be synchronized during play back.</t> playback.</t>

      <t>A MediaStreamTrack's realisation realization in RTP RTP, in the context of an
      RTCPeerConnection, consists of a source packet stream stream, identified with 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, streams; these are created when applying <xref
      target="sec-FEC">Forward target="sec-FEC" format="default">Forward Error Correction</xref> or <xref
      target="sec-rtx">RTP target="sec-rtx" format="default">RTP retransmission</xref> to the source packet
      <t>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 a an RTCPeerConnection SHALL <bcp14>SHALL</bcp14> result in an independent
      source packet stream, stream with its own set of associated packet streams, 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 optimisations optimizations would need to
      take into account that the constraints for one of the MediaStreamTracks
      can change at any moment change, moment, meaning that the encoding configurations might
      no longer be identical identical, and two different encoder instances would then be
      <t>The same MediaStreamTrack can also be included in multiple
      MediaStreams, thus multiple sets of MediaStreams can implicitly need to
      use the same synchronisation 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 <xref
      target="sec-cname"></xref>. <list style="empty">
          <t>The target="sec-cname" format="default"/>. </t>

        <aside><t>The requirement on using to use the same CNAME for all SSRCs that
          originate from the same endpoint, endpoint does not require a middlebox that
          forwards traffic from multiple endpoints to only use a single
      <t>Different CNAMEs normally need to be used for different
      RTCPeerConnection instances, as specified in <xref
      target="sec-cname"></xref>. target="sec-cname" format="default"/>. 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 <xref
      target="I-D.ietf-rtcweb-security"></xref> target="RFC8826" section="4.4.1" sectionFormat="of"/> for details). A web
      application can request that the CNAMEs used in different
      RTCPeerConnections (within a same-orign same-origin context) be the same, same; this
      allows for synchronization of the endpoint's RTP packet streams across
      the different RTCPeerConnections.<list style="empty">
          <t>Note: this RTCPeerConnections.</t>

        <aside><t>Note: This doesn't result in a tracking issue, since the creation
          of matching CNAMEs depends on existing tracking within a single
      <t>The above will currently force a WebRTC Endpoint endpoint that receives
      a MediaStreamTrack on one RTCPeerConnection and adds it as an outgoing one
      on any RTCPeerConnection to perform resynchronisation 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 synchronisation. synchronization. The sending entity is also responsible for
      congestion control for its sent streams. In cases of packet loss 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 etc., repair, followed by encoding of the media again
      into the outgoing packet stream. Optimisations Optimizations of this method are
      clearly possible and implementation specific.</t>
      <t>A WebRTC Endpoint MUST endpoint <bcp14>MUST</bcp14> support receiving multiple MediaStreamTracks,
      where each of the different MediaStreamTracks (and their its sets of
      associated packet streams) uses different CNAMEs. However,
      MediaStreamTracks that are received with different CNAMEs have no
      defined synchronisation.<list style="empty">
          <t>Note: synchronization.</t>

        <aside><t>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 multi-stream multistream middleboxes or endpoints that are not

      <t><xref target="I-D.ietf-rtcweb-jsep">Javascript target="RFC8829" format="default">"JavaScript Session Establishment
      Protocol (JSEP)"</xref> specifies that the binding between the WebRTC
      MediaStreams, MediaStreamTracks MediaStreamTracks, and the SSRC is done as specified in <xref target="I-D.ietf-mmusic-msid">"Cross Session Stream target="RFC8830" format="default">"WebRTC MediaStream Identification in the Session
      Description Protocol"</xref>. Section 4.1 of <xref
      target="I-D.ietf-mmusic-msid">The MSID target="RFC8830"
      format="default">the MediaStream Identification (MSID) document</xref> also defines, in
      section 4.1, defines
      how to map unknown source packet stream streams with unknown SSRCs to
      MediaStreamTracks and MediaStreams. This later is relevant to handle
      some cases of legacy interoperability. Commonly Commonly, the RTP Payload Type 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.</t>

      <t>Finally, this specification puts a requirement on the WebRTC API to
      realize a method for determining the <xref target="sec-rtp-rtcp">CSRC target="sec-rtp-rtcp" format="default">CSRC
      list</xref> as well as the <xref
      target="sec-mixer-to-client">Mixer-to-Client target="sec-mixer-to-client" format="default">mixer-to-client audio levels</xref> (when
      supported) and
      supported); the basic requirements for this is further discussed in
      <xref target="sec-media-stream-id"></xref>.</t> target="sec-media-stream-id" format="default"/>.</t>
    <section anchor="sec-rtp-func" title="RTP numbered="true" toc="default">
      <name>RTP Implementation Considerations"> Considerations</name>
      <t>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 behaviour behavior of middleboxes, that is not the focus of this memo.</t>
      <section title="Configuration numbered="true" toc="default">
        <name>Configuration and Use of RTP Sessions"> Sessions</name>
        <t>A WebRTC Endpoint endpoint will be a simultaneous participant in one or more
        RTP sessions. Each RTP session can convey multiple media sources, sources and
        include media data from multiple endpoints. In the following, some
        ways in which WebRTC Endpoints endpoints can configure and use RTP sessions are
        <section anchor="sec.multiple-flows"
                 title="Use numbered="true" toc="default">
          <name>Use of Multiple Media Sources Within within an RTP Session"> Session</name>
          <t>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: <list style="hanging">
              <t hangText="Multiple </t>
          <li><t>Multiple media types:">Outside types:</t>
            <t>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 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 <xref target="sec.session-mux"></xref>, target="sec.session-mux" format="default"/>, using RTP
              and RTCP multiplexing (<xref target="sec.rtcp-mux"></xref>) target="sec.rtcp-mux" format="default"/>) to
              further reduce the number of UDP ports needed. This RTP session
              then uses only one bi-directional bidirectional transport-layer flow, 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.</t>

              <t hangText="Multiple Capture Devices:">A
            <t>Multiple capture devices:</t>
            <t>A WebRTC Endpoint 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.</t>

              <t hangText="Associated Repair Data:">An
            <t>Associated repair data:</t>
            <t>An endpoint might send a 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.</t>

              <t hangText="Layered or Multiple Description Coding:">An
            <t>Layered or multiple-description coding:</t>
            <t>Within a single
              RTP session, an endpoint can use a layered media codec, codec -- for example
              example, H.264 SVC, SVC --
              or a multiple description codec, multiple-description codec that generates multiple RTP
              packet streams, each with a distinct RTP SSRC, within a single
              RTP session.</t>

              <t hangText="RTP Mixers, Translators, SSRC.</t>
            <t>RTP mixers, translators, and Other Middleboxes:">An other middleboxes:</t>
              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, endpoint, or it might be an RTP mixer,
              translator, or some other form of media processing media-processing middlebox. In
              the latter cases, the middlebox might send mixed or relayed RTP
              streams from several participants, that which the WebRTC Endpoint endpoint will
              need to render. Thus, even though a WebRTC Endpoint 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 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.</t>
        <section anchor="sec.multiple-sessions"
                 title="Use numbered="true" toc="default">
          <name>Use of Multiple RTP Sessions"> Sessions</name>
          <t>In addition to sending and receiving multiple RTP packet streams
          within a single RTP session, a WebRTC Endpoint endpoint might participate in
          multiple RTP sessions. There are several reasons why a WebRTC
          endpoint might choose to do this: <list style="hanging">
              <t hangText="To </t>

            <li><t>To interoperate with legacy devices:">The devices:</t>
            <t>The common
              practice in the non-WebRTC world is to send different types of
              media in separate RTP sessions, sessions -- for example example, using one RTP
              session for audio and another RTP session, on a separate
              transport layer
              transport-layer flow, for video. All WebRTC Endpoints endpoints need to
              support the option of sending different types of media on
              different RTP sessions, sessions so they can interwork with such legacy
              devices. This is discussed further in <xref

              <t hangText="To target="sec.session-mux" format="default"/>.</t></li>
            <li><t>To provide enhanced quality of service:">Some service:</t>
              network-based quality of service quality-of-service mechanisms operate on the
              granularity of transport layer transport-layer flows. If it is desired to use of
              these mechanisms to provide differentiated quality of service
              for some RTP packet streams, 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 quality-of-service
              marking. This is discussed further in <xref

              <t hangText="To target="sec-differentiated" format="default"/>.</t></li>

            <li><t>To separate media with different purposes:">An purposes:</t>
              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, resolution but show low resolution 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, sessions to simplify the
              operation of the RTP middlebox. In the WebRTC context 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 extension, or
              RTCP packets, but packets. However, it can be easier to distinguish the RTP packet
              streams if they arrive on separate RTP sessions on separate
              transport-layer flows.</t>

              <t hangText="To flows.</t></li>
            <li><t>To directly connect with multiple peers:">A
              multi-party peers:</t>
              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 <xref target="fig-mesh"></xref>. target="fig-mesh" format="default"/>. 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 are is
              part of the same session beyond the sender itself.</t>

          <figure align="center" anchor="fig-mesh"
                  title="Multi-unicast using several anchor="fig-mesh">
            <name>Multi-unicast Using Several RTP sessions">
            <artwork><![CDATA[ Sessions</name>
            <artwork name="" type="" align="left" alt="">
+---+     +---+
| A |<--->| B |
+---+     +---+
  ^         ^
   \       /
    \     /
     v   v
     | C |
     +---+            ]]></artwork>

          <t><list style="hanging">

            <t>The multi-unicast topology could also be implemented as a
              single RTP session, spanning multiple peer-to-peer transport
              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 recommend RECOMMENDED that this is 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 showed 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 bit-rates 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 as C will. C. It is believed that
              these advantages outweigh the limitations in debugging

              <t hangText="To

            <li><t>To indirectly connect with multiple peers:">A peers:</t>
              common scenario in multi-party multiparty conferencing is to create
              indirect connections to multiple peers, using an RTP mixer,
              translator, or some other type of RTP middlebox. <xref
              target="fig-mixerFirst"></xref> target="fig-mixerFirst" format="default"/> outlines a simple topology that
              might be used in a four-person centralised centralized conference. The
              middlebox acts to optimise 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.</t>

          <figure align="center" anchor="fig-mixerFirst"
                  title="RTP mixer anchor="fig-mixerFirst">
            <name>RTP Mixer with only unicast paths">
            <artwork><![CDATA[ Only Unicast Paths</name>
            <artwork name="" type="" align="left" alt="">
+---+      +-------------+      +---+
| A |<---->|             |<---->| B |
+---+      | RTP mixer,  |      +---+
           | translator, |
           | or other    |
+---+      | middlebox   |      +---+
| C |<---->|             |<---->| D |
+---+      +-------------+      +---+    ]]></artwork>


          <t><list style="hanging">

            <t>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 multi-party multiparty session. Other
              types of middlebox 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. endpoint. This includes functions
              like requesting the breaking of the encoding chain and have having the
              encoder produce a so called so-called Intra frame. Another common aspect
              is limiting the
              bit-rate bitrate of a given stream to better suit the mixer view of match the
              multiple down-streams. Others mixed
              output. Other aspects are controlling the most suitable
              frame rate, picture resolution, and the trade-off between frame-rate frame rate
              and spatial quality. The middlebox has the responsibility to
              correctly perform congestion control, source identification, identify sources, and
              manage synchronisation synchronization while providing the application with
              suitable media optimisations. 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, endpoint before sending it them on towards the endpoint(s), endpoint(s);
              thus they need to be able to decrypt and then re-encrypt the RTP
              packet stream before sending it out.</t>

              <t>RTP Mixers can create a situation where an endpoint
              experiences a situation in-between a session with only two
              endpoints and multiple RTP sessions. Mixers
            <t>Mixers are expected to not
              forward RTCP reports regarding RTP packet streams across
              themselves. This is due to the difference in between the RTP packet
              streams provided to the different endpoints. The original media
              source lacks information about a mixer's manipulations prior to
              sending it being
              sent to the different receivers. This scenario also results
              in that an endpoint's feedback or requests go 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 fulfil fulfill the receivers 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.</t>

            <t>Providing source authentication in multi-party 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, keys and can thus inject packets claimed claiming to
              come from another endpoint in the session. Any node performing
              relay can perform non-cryptographic 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, mechanisms -- for example example,
              <xref target="RFC4383">TESLA target="RFC4383" format="default"> Timed Efficient Stream Loss-Tolerant
              Authentication (TESLA) for SRTP</xref>, SRTP</xref> -- that are not part
              of the base WebRTC standards.</t>

              <t hangText="To

            <li><t>To forward media between multiple peers:">It peers:</t>
            <t>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-encoding re-encoded and transmitted as a new
            <t>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 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
            <t>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 to from the RTP session on which
              the media was received. This will require media transcoding for
              congestion control purpose purposes to produce a suitable bit-rate 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 legs, removing almost all dependencies, and allowing
              the forwarding endpoint to optimise 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.</t>
        <section anchor="sec-differentiated"
                 title="Differentiated numbered="true" toc="default">
          <name>Differentiated Treatment of RTP Streams"> Streams</name>
          <t>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, controls both which RTP packet streams
          will be sent, sent and their allocation of bit-rate bitrate out of the
          current available aggregate aggregate, as determined by the congestion
          <t>It is expected that the <xref
          target="W3C.WD-webrtc-20130910">WebRTC target="W3C.WebRTC" format="default">WebRTC API</xref> 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 congestion
          control response in determining
          how to divide the available bandwidth between
          the RTP packet streams. 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, in regards with regard to
          how robust that codec is to against packet loss. However, a default policy
          might to be to use the same priority for a redundant RTP packet stream
          as for the source RTP packet stream.</t>
          <t>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 to prioritize for prioritizing packets.
          Three common methods for classifying IP packets are: <list
              <t hangText="DiffServ:">The </t>
            <dd>The endpoint marks a packet with a
              DiffServ code point to indicate to the network that the packet
              belongs to a particular class.</t>

              <t hangText="Flow based:">Packets class.</dd>
            <dt>Flow based:</dt>
            <dd>Packets that need to be given a
              particular treatment are identified using a combination of IP
              and port address.</t>

              <t hangText="Deep Packet Inspection:">A address.</dd>
            <dt>Deep packet inspection:</dt>
            <dd>A network classifier (DPI)
              inspects the packet and tries to determine if the packet
              represents a particular application and type that is to be
          <t>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 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 flow-based differentiation.
          The used flows, their 5-tuples 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.</t>
          <t>DiffServ assumes that either the endpoint or a classifier can
          mark the packets with an appropriate DSCP 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 DSCP 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 <xref target="I-D.ietf-tsvwg-rtcweb-qos">"DSCP
          and other packet markings target="RFC8837"
	  format="default">"Differentiated Services Code Point (DSCP) Packet
	  Markings for RTCWeb WebRTC QoS"</xref>.</t>

          <t>Deep Packet Inspectors will, despite
          <t>Despite the SRTP media encryption, deep packet inspectors will
          still be fairly capable at 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 determine, for example example, the stream's media type. Using
          packet sizes, reception times, packet inter-spacing, RTP timestamp
          increments, and sequence numbers, fairly reliable classifications are
          <t>For packet based packet-based marking schemes schemes, it might be possible to mark
          individual RTP packets differently based on the relative priority of
          the RTP payload. For example example, video codecs that have I, P, and B
          pictures could prioritise prioritize any payloads carrying only B frames less,
          as these are less damaging to loose. lose. However, depending on the QoS
          mechanism and what markings that are applied, this can result in not
          only different packet drop packet-drop probabilities but also packet reordering, reordering;
          see <xref target="I-D.ietf-tsvwg-rtcweb-qos"></xref> target="RFC8837" format="default"/> and <xref
          target="I-D.ietf-dart-dscp-rtp"></xref> target="RFC7657" format="default"/> for further discussion. As a
          default policy policy, all RTP packets related to a an RTP packet stream ought
          to be provided with the same prioritization; per-packet
          prioritization is outside the scope of this memo, memo but might be
          specified elsewhere in future.</t>
          <t>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 (SR), (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.</t>

      <section title="Media numbered="true" toc="default">
        <name>Media Source, RTP Streams, and Participant Identification"> Identification</name>
        <section anchor="sec-media-stream-id"
                 title="Media numbered="true" toc="default">
          <name>Media Source Identification"> Identification</name>
          <t>Each RTP packet stream is identified by a unique synchronisation synchronization
          source (SSRC) identifier. The SSRC identifier is carried in each of
          the RTP packets comprising a an RTP packet stream, and is also used to
          identify that stream in the corresponding RTCP reports. The SSRC is
          chosen as discussed in <xref target="sec-ssrc"></xref>. target="sec-ssrc" format="default"/>. The first
          stage in demultiplexing RTP and RTCP packets received on a single
          transport layer
          transport-layer flow at a WebRTC Endpoint 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.</t>
          <t>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 contributing source (CSRC) list,
          indicating which original SSRCs contributed to the combined source
          stream. As described in <xref target="sec-rtp-rtcp"></xref>, target="sec-rtp-rtcp" format="default"/>,
          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 needs need to be exposed to the WebRTC
          application using some API, 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 name space namespace to WebRTC
          <t>If the mixer-to-client audio level extension <xref
          target="RFC6465"></xref> target="RFC6465" format="default"/> is being used in the session (see <xref
          target="sec-mixer-to-client"></xref>), target="sec-mixer-to-client" format="default"/>), the information in the CSRC
          list is augmented by audio level 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
        <section title="SSRC numbered="true" toc="default">
          <name>SSRC Collision Detection"> Detection</name>
          <t>The RTP standard requires RTP implementations to have support for
          detecting and handling SSRC collisions, collisions -- i.e., be able to resolve the conflict
          when two different endpoints use the same SSRC value (see section
          8.2 of <xref target="RFC3550"></xref>). target="RFC3550" section="8.2" sectionFormat="of"/>). This requirement also
          applies to WebRTC Endpoints. endpoints. There are several scenarios where SSRC
          collisions can occur: <list style="symbols">
              <t>In </t>
          <ul spacing="normal">
            <li>In a point-to-point session where each SSRC is associated
              with either of the two endpoints and where the main media
              carrying media-carrying SSRC
              identifier will be announced in the signalling 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 <xref target="RFC5576">Source-Specific target="RFC5576" format="default">source-specific SDP
              attributes</xref>. Still, collisions can occur if both endpoints
              start using a new SSRC identifier prior to having signalled signaled it
              to the peer and received acknowledgement on the signalling signaling
              message. The <xref target="RFC5576">Source-Specific SDP
              Attributes</xref> target="RFC5576"
              format="default">"Source-Specific Media Attributes in the
              Session Description Protocol (SDP)"</xref>
              contains a mechanism to signal how the
              endpoint resolved the SSRC collision.</t>

              <t>SSRC collision.</li>
            <li>SSRC values that have not been signalled 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 <xref
              target="RFC4588"></xref>. target="RFC4588" format="default"/>. 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.</t>

              <t>Multiple level.</li>
            <li>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 middlebox, collisions can occur.</t>

              <t>An occur.</li>
            <li>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 is be able to recognise recognize and handle the
              case when it occurs. This case becomes even more problematic
              when media mixers, mixers and so on, such are involved, where the stream
              received is a different stream but still contains this client's
          <t>These SSRC/CSRC collisions can only be handled on the RTP level as
          long as
          when the same RTP session is extended across multiple
          RTCPeerConnections by a an RTP middlebox. To resolve the more generic
          case where multiple RTCPeerConnections are interconnected,
          identification of the media source(s) source or sources that are part of a MediaStreamTrack
          being propagated across multiple interconnected RTCPeerConnection
          needs to be preserved across these interconnections.</t>
        <section title="Media Synchronisation Context"> numbered="true" toc="default">
          <name>Media Synchronization Context</name>
          <t>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, synchronisation 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.</t>
          <t>The next provision is that the internal clocks of all media
          sources -- i.e., what drives the RTP timestamp, 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 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; it whether or not the information is used is up to the receiver to use it or not.</t> receiver.</t>
    <section anchor="sec-security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The overall security architecture for WebRTC is described in <xref
      target="I-D.ietf-rtcweb-security-arch"></xref>, target="RFC8827" format="default"/>, and security
      considerations for the WebRTC framework are described in <xref
      target="I-D.ietf-rtcweb-security"></xref>. target="RFC8826" format="default"/>. These considerations also
      apply to this memo.</t>
      <t>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 not believed that there are any no new security considerations resulting from
      the combination of these various protocol extensions.</t>

      <t>The <xref target="RFC5124">Extended
      <t><xref target="RFC5124" format="default">"Extended Secure RTP
      Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback</xref> (RTP/SAVPF) Feedback (RTP/SAVPF)"</xref>
      provides handling of fundamental issues by offering confidentiality,
      integrity, and partial source authentication. A media-security solution
      that is mandatory to implement and use media security solution is created by combining this secured RTP
      profile and <xref target="RFC5764">DTLS-SRTP keying</xref> target="RFC5764" format="default">DTLS-SRTP keying</xref>, as defined by
      <xref target="I-D.ietf-rtcweb-security-arch">Section 5.5 of</xref>.</t> target="RFC8827" section="5.5" sectionFormat="of"/>.</t>
      <t>RTCP packets convey a Canonical Name (CNAME) identifier that is used
      to associate RTP packet streams that need to be synchronised 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. <xref
      target="sec-cname"></xref> target="sec-cname" format="default"/> of this memo mandates generation of
      short-term persistent RTCP CNAMES, as specified in RFC7022, RFC 7022, resulting in
      untraceable CNAME values that alleviate this risk.</t>
      <t>Some potential denial of service 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 <xref
      target="RFC3556"></xref>, target="RFC3556" format="default"/> 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) <xref target="RFC4585"></xref>. target="RFC4585" format="default"/>. The risks are as
      follows:<list style="numbers">
      <ol spacing="normal" type="1">
        <li>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;</t>

          <t>the traffic;</li>
        <li>the RTCP interval could be configured to a very small value,
          causing endpoints to generate high rate high-rate RTCP traffic, potentially
          leading to denial of service due to the non-congestion controlled RTCP traffic; and</t>

          <t>RTCP traffic not being
          congestion controlled; and</li>
        <li>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 which that are based on the reporting interval (this interval. This is a
          particular concern if endpoints use a small but non-zero nonzero value for
          the RTP/AVPF minimal receiver report interval (trr-int) <xref
          target="RFC4585" format="default"/>, as discussed in Section 6.1 of
        </list>Premature target="RFC8108" section="6.1" sectionFormat="of"/>.</li>
      <t>Premature participant timeout can be avoided by using the fixed
      (nonreduced) minimum interval when calculating the participant timeout
      (see <xref target="sec-rtp-rtcp"></xref> target="sec-rtp-rtcp" format="default"/> of this memo and Section 6.1 of
      <xref target="I-D.ietf-avtcore-rtp-multi-stream"></xref>). target="RFC8108" section="7.1.2" sectionFormat="of"/>). To address
      the other concerns, endpoints SHOULD <bcp14>SHOULD</bcp14> ignore parameters that configure
      the RTCP reporting interval to be significantly longer than the default
      five second
      five-second interval specified in <xref target="RFC3550"></xref> target="RFC3550" format="default"/> (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.</t>
      <t>The guidelines in <xref target="RFC6562"></xref> target="RFC6562" format="default"/> apply when using
      variable bit rate bitrate (VBR) audio codecs such as Opus (see <xref
      target="sec.codecs"></xref> target="sec.codecs" format="default"/> for discussion of mandated audio codecs).
      The guidelines in <xref target="RFC6562"></xref> target="RFC6562" format="default"/> also apply, but are of
      lesser importance, when using the client-to-mixer audio level header
      extensions (<xref target="sec-client-to-mixer"></xref>) target="sec-client-to-mixer" format="default"/>) or the
      mixer-to-client audio level header extensions (<xref
      target="sec-mixer-to-client"></xref>). target="sec-mixer-to-client" format="default"/>). The use of the encryption of the
      header extensions are RECOMMENDED, <bcp14>RECOMMENDED</bcp14>, unless there are known reasons, like
      RTP middleboxes performing voice activity based voice-activity-based source selection or
      third party
      third-party monitoring that will greatly benefit from the information,
      and this has been expressed using API or signalling. signaling. If further evidence
      is produced to show that information leakage is significant from audio
      audio-level indications, then use of encryption needs to be mandated at
      that time.</t>
      <t>In multi-party multiparty communication scenarios using RTP Middleboxes, middleboxes, a lot
      of trust is placed on these middleboxes to preserve the sessions session's
      security. The middlebox needs to maintain the confidentiality, confidentiality and integrity
      and perform source authentication. As discussed in <xref
      target="sec.multiple-flows"></xref> target="sec.multiple-flows" format="default"/>, the middlebox can perform checks
      that prevents prevent any endpoint participating in a conference to impersonate from impersonating
      another. Some additional security considerations regarding multi-party multiparty
      topologies can be found in <xref
      target="I-D.ietf-avtcore-rtp-topologies-update"></xref>.</t> target="RFC7667" format="default"/>.</t>
    <section anchor="sec-iana" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This memo makes document has no request of IANA.</t>

      <t>Note to RFC Editor: this section is to be removed on publication as
      an RFC.</t>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>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.</t> IANA actions.</t>
    <references title="Normative References">
      <?rfc include="reference.RFC.3550"?>

      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.2736'?>

      <?rfc include='reference.RFC.3551'?>

      <?rfc include='reference.RFC.3556'?>

      <?rfc include='reference.RFC.3711'?>

      <?rfc include='reference.RFC.4566'?>

      <?rfc include='reference.RFC.4585'?>

      <?rfc include='reference.RFC.4588'?>

      <?rfc include='reference.RFC.4961'?>

      <?rfc include='reference.RFC.5104'?>

      <?rfc include='reference.RFC.5124'?>

      <?rfc include='reference.RFC.5285'?>

      <?rfc include='reference.RFC.5506'?>

      <?rfc include='reference.RFC.5761'?>

      <?rfc include='reference.RFC.5764'?>

      <?rfc include='reference.RFC.6051'?>

      <?rfc include='reference.RFC.6464'?>

      <?rfc include='reference.RFC.6465'?>

      <?rfc include='reference.RFC.6562'?>

      <?rfc include='reference.RFC.6904'?>

      <?rfc include='reference.RFC.7007'?>

      <?rfc include='reference.RFC.7022'?>

      <?rfc include='reference.RFC.7160'?>

      <?rfc include='reference.RFC.7164'?>

      <?rfc include='reference.I-D.ietf-avtcore-multi-media-rtp-session'?>
      <?rfc include='reference.I-D.ietf-mmusic-mux-exclusive'?>

      <?rfc include='reference.I-D.ietf-avtcore-rtp-multi-stream'?>

      <?rfc include='reference.I-D.ietf-avtcore-rtp-multi-stream-optimisation'?>

      <?rfc include='reference.I-D.ietf-rtcweb-audio'?>

      <?rfc include='reference.I-D.ietf-rtcweb-video'?>

      <?rfc include='reference.I-D.ietf-rtcweb-security'?>

      <?rfc include='reference.I-D.ietf-avtcore-rtp-circuit-breakers'?>

      <?rfc include='reference.I-D.ietf-rtcweb-security-arch'?>

      <?rfc include='reference.I-D.ietf-rtcweb-fec'?>

      <?rfc include='reference.I-D.ietf-mmusic-sdp-bundle-negotiation'?>

      <?rfc include='reference.I-D.ietf-rtcweb-overview'?>

      <?rfc include='reference.I-D.ietf-avtcore-rtp-topologies-update'?>

<displayreference target="I-D.ietf-avtcore-multiplex-guidelines" to="MULTIPLEX"/>

        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2736.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3551.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3556.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3711.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4566.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4585.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4588.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4961.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5104.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5124.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8285.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5506.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5761.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5764.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6051.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6464.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6465.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6562.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6904.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7007.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7022.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7160.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7164.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7742.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7874.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8083.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

<!-- draft-ietf-avtcore-multi-media-rtp-session: RFC 8860 -->
<reference anchor='W3C.WD-webrtc-20130910'
           target='http://www.w3.org/TR/2013/WD-webrtc-20130910'> anchor="RFC8860" target="https://www.rfc-editor.org/info/rfc8860">
<title>WebRTC 1.0: Real-time Communication Between Browsers</title>
    <title>Sending Multiple Types of Media in a Single RTP
    <author initials='A.' surname='Bergkvist' fullname='Adam Bergkvist'>
    <organization /> initials="M." surname="Westerlund" fullname="Magnus Westerlund">
    <author initials='D.' surname='Burnett' fullname='Daniel Burnett'>
    <organization /> initials="C." surname="Perkins" fullname="Colin Perkins">
    <author initials="J." surname="Lennox" fullname="Jonathan Lennox">
     <date month="September" year="2020"/>
   <seriesInfo name="RFC" value="8860"/>
   <seriesInfo name="DOI" value="10.17487/RFC8860"/>

<!-- draft-ietf-avtcore-rtp-multi-stream: RFC 8108 -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8108.xml"/>

<!-- draft-ietf-avtcore-rtp-multi-stream-optimisation: RFC 8861 -->
<reference anchor="RFC8861" target="https://www.rfc-editor.org/info/rfc8861">
    <title>Sending Multiple RTP Streams in a Single RTP Session:
    Grouping RTP Control Protocol (RTCP) Reception Statistics and Other Feedback</title>
    <author initials="J." surname="Lennox" fullname="Jonathan Lennox">
    <author initials="M." surname="Westerlund" fullname="Magnus Westerlund">
    <author initials="Q." surname="W" fullname="Qin Wu">
    <author initials="C." surname="Perkins" fullname="Colin Perkins">
    <date month="September" year="2020"/>
  <seriesInfo name="RFC" value="8861"/>
  <seriesInfo name="DOI" value="10.17487/RFC8861"/>

<!--draft-ietf-mmusic-mux-exclusive-12; part of C238; RFC 8858-->
<reference anchor='RFC8858' target="https://www.rfc-editor.org/info/rfc8858">
<title>Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP)
Multiplexing Using the Session Description Protocol (SDP)</title>
<author initials='C.' surname='Jennings' fullname='Cullen Jennings'> surname='Holmberg' fullname='Christer Holmberg'>
    <organization />
<date month="September" year='2020' />
<seriesInfo name='RFC' value='8858' />
<seriesInfo name="DOI" value="10.17487/RFC8858"/>

<!-- draft-ietf-rtcweb-fec: RFC 8854 -->
<reference anchor="RFC8854" target="https://www.rfc-editor.org/info/rfc8854">
    <title>WebRTC Forward Error Correction Requirements</title>
    <author initials="J." surname="Uberti" fullname="Justin Uberti">
    <date month="September" year="2020"/>
  <seriesInfo name="RFC" value="8854"/>
  <seriesInfo name="DOI" value="10.17487/RFC8854"/>

<!-- draft-ietf-rtcweb-overview: RFC 8825 -->
<reference anchor="RFC8825" target="https://www.rfc-editor.org/info/rfc8825">
    <title>Overview: Real-Time Protocols for Browser-Based Applications</title>
    <author initials='A.' surname='Narayanan' fullname='Anant Narayanan'> initials="H." surname="Alvestrand" fullname="Harald T. Alvestrand">
      <organization />
    <date month='September' day='10' year='2013' month="September" year="2020" />
  <seriesInfo name='World Wide Web Consortium WD' value='WD-webrtc-20130910' />
<format type='HTML' target='http://www.w3.org/TR/2013/WD-webrtc-20130910' name="RFC" value="8825" />
  <seriesInfo name="DOI" value="10.17487/RFC8825"/>

 <!--draft-ietf-rtcweb-security: RFC 8826 -->
 <reference anchor="RFC8826" target="https://www.rfc-editor.org/info/rfc8826">
 <title>Security Considerations for WebRTC</title>
 <author initials='E.' surname='Rescorla' fullname='Eric Rescorla'>
 <date month='September' year='2020'/>
 <seriesInfo name="RFC" value="8826"/>
 <seriesInfo name="DOI" value="10.17487/RFC8826"/>

 <!--draft-ietf-rtcweb-security-arch: RFC 8827 -->
 <reference anchor="RFC8827" target="https://www.rfc-editor.org/info/rfc8827">
 <title>WebRTC Security Architecture</title>
 <author initials='E.' surname='Rescorla' fullname='Eric Rescorla'>
 <date month='September' year='2020'/>
 <seriesInfo name="RFC" value="8827"/>
 <seriesInfo name="DOI" value="10.17487/RFC8827"/>

<!-- draft-ietf-mmusic-sdp-bundle-negotiation (RFC 8843) -->
<reference anchor="RFC8843" target="https://www.rfc-editor.org/info/rfc8843">
    <title>Negotiating Media Multiplexing Using the Session Description Protocol (SDP)</title>
    <author initials="C" surname="Holmberg" fullname="Christer Holmberg">
    <author initials="H" surname="Alvestrand" fullname="Harald Alvestrand">
    <author initials="C" surname="Jennings" fullname="Cullen Jennings">
    <date month="September" year="2020"/>
  <seriesInfo name="RFC" value="8843"/>
  <seriesInfo name="DOI" value="10.17487/RFC8843"/>

        <reference anchor="W3C.WebRTC" target="https://www.w3.org/TR/2019/CR-webrtc-20191213/">
            <title>WebRTC 1.0: Real-time Communication Between Browsers</title>
            <author initials="C." surname="Jennings">
            <author initials="H." surname="Boström">
            <author initials="J-I." surname="Bruaroey">
            <date year="2019" month="December" day="13"/>
            <refcontent>W3C Candidate Recommendation</refcontent>

        <reference anchor='W3C.WD-mediacapture-streams-20130903'
           target='http://www.w3.org/TR/2013/WD-mediacapture-streams-20130903'> anchor="W3C-MEDIA-CAPTURE" target="https://www.w3.org/TR/2019/CR-mediacapture-streams-20190702/">
            <title>Media Capture and Streams</title>
            <author initials='D.' surname='Burnett' fullname='Daniel Burnett'>
    <organization /> initials="D." surname="Burnett" fullname="Daniel Burnett">
            <author initials='A.' surname='Bergkvist' fullname='Adam Bergkvist'>
    <organization initials="A." surname="Bergkvist" fullname="Adam Bergkvist">
            <author initials="C." surname="Jennings" fullname="Cullen Jennings">
            <author initials="A." surname="Narayanan" fullname="Anant Narayanan">
            <author initials="B" surname="Aboba" fullname="Bernard Aboba">
            <author initials="J-I." surname="Bruaroey" fullname="Jan-Ivar Bruaroey">
            <author initials="H" surname="Boström" fullname="Henrik Boström">
            <date month="July" day="2" year="2019"/>
         <refcontent>W3C Candidate Recommendation</refcontent>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3611.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4383.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8445.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5576.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5968.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6263.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6792.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7478.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7656.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7657.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7667.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8088.xml"/>
<!-- draft-ietf-mmusic-msid-17 (RFC 8830) -->
        <reference anchor="RFC8830" target="https://www.rfc-editor.org/info/rfc8830">
            <title>WebRTC MediaStream Identification in the Session Description Protocol</title>
            <author initials="H" surname="Alvestrand" fullname="Harald Alvestrand">
            <date month="September" year="2020"/>
          <seriesInfo name="RFC" value="8830" />
          <seriesInfo name="DOI" value="10.17487/RFC8830"/>

<!-- draft-ietf-avtcore-multiplex-guidelines (EDIT) -->
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-avtcore-multiplex-guidelines.xml"/>

<!-- draft-ietf-rmcat-cc-requirements-09: RFC 8836  -->
<reference anchor="RFC8836" target="https://www.rfc-editor.org/info/rfc8836">
    <title>Congestion Control Requirements for Interactive Real-Time Media</title>
    <author initials="R" surname="Jesup" fullname="Randell Jesup">
    <author initials='C.' surname='Jennings' fullname='Cullen Jennings'>
    <organization initials="Z" surname="Sarker" fullname="Zaheduzzaman Sarker" role="editor">
    <date month="September" year="2020"/>
  <seriesInfo name="RFC" value="8836" />
  <seriesInfo name="DOI" value="10.17487/RFC8836"/>

<!-- draft-ietf-tsvwg-rtcweb-qos-18: RFC 8837  -->
<reference anchor="RFC8837" target="https://www.rfc-editor.org/info/rfc8837">
    <title>Differentiated Services Code Point (DSCP) Packet Markings for
    WebRTC QoS</title>
    <author initials="P." surname="Jones" fullname="Paul Jones">
    <author initials='A.' surname='Narayanan' fullname='Anant Narayanan'>
    <organization initials="S." surname="Dhesikan" fullname="Subha Dhesikan">
    <author initials="C." surname="Jennings" fullname="Cullen Jennings">
    <author initials="D." surname="Druta" fullname="Dan Druta">
    <date month="September" year="2020"/>
  <seriesInfo name="RFC" value="8837" />
  <seriesInfo name="DOI" value="10.17487/RFC8837"/>

 <reference anchor="RFC8829" target="https://www.rfc-editor.org/info/rfc8829">
 <title>JavaScript Session Establishment Protocol (JSEP)</title>
 <author initials='J.' surname='Uberti' fullname='Justin Uberti'>
 <author initials="C." surname="Jennings" fullname="Cullen Jennings">
 <author initials="E." surname="Rescorla" fullname="Eric Rescorla"
 <date month='September' day='3' year='2013' /> year='2020'/>
 <seriesInfo name='World Wide Web Consortium WD' value='WD-mediacapture-streams-20130903' />
<format type='HTML' target='http://www.w3.org/TR/2013/WD-mediacapture-streams-20130903' /> name="RFC" value="8829"/>
 <seriesInfo name="DOI" value="10.17487/RFC8829"/>


    <references title="Informative References">
      <?rfc include='reference.RFC.3611'?>

      <?rfc include='reference.RFC.4383'?>

      <?rfc include='reference.RFC.5245'?>

      <?rfc include='reference.RFC.5576'?>

      <?rfc include='reference.RFC.5968'?>

      <?rfc include='reference.RFC.6263'?>

      <?rfc include='reference.RFC.6792'?>

      <?rfc include='reference.RFC.7478'?>

      <?rfc include='reference.I-D.ietf-mmusic-msid'?>

      <?rfc include='reference.I-D.ietf-avtcore-multiplex-guidelines'?>

      <?rfc include='reference.I-D.ietf-payload-rtp-howto'?>

      <?rfc include='reference.I-D.ietf-rmcat-cc-requirements'?>

      <?rfc include='reference.I-D.ietf-tsvwg-rtcweb-qos'?>

      <?rfc include='reference.I-D.ietf-avtext-rtp-grouping-taxonomy'?>

      <?rfc include='reference.I-D.ietf-dart-dscp-rtp'?>

      <?rfc include='reference.I-D.ietf-rtcweb-jsep'?>
    <section anchor="Acknowledgements" numbered="false" toc="default">
<t>The authors would like to thank <contact fullname="Bernard Aboba"/>,
<contact fullname="Harald Alvestrand"/>, <contact fullname="Cary Bran"/>,
<contact fullname="Ben Campbell"/>, <contact fullname="Alissa Cooper"/>,
<contact fullname="Spencer Dawkins"/>, <contact fullname="Charles Eckel"/>,
<contact fullname="Alex Eleftheriadis"/>, <contact fullname="Christian
Groves"/>, <contact fullname="Chris Inacio"/>, <contact fullname="Cullen
Jennings"/>, <contact fullname="Olle Johansson"/>, <contact fullname="Suhas
Nandakumar"/>, <contact fullname="Dan Romascanu"/>, <contact fullname="Jim
Spring"/>, <contact fullname="Martin Thomson"/>, and the other members of the
IETF RTCWEB working group for their valuable feedback.</t>

<!-- vim: set ts=2 sw=2 tw=78 et ai: -->