<?xml version="1.0" encoding="US-ASCII"?>
<!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"?> version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-rtcweb-rtp-usage-26" ipr="trust200902"> indexInclude="true" ipr="trust200902" number="8834" prepTime="2021-01-16T22:07:58" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage-26" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc8834" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <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" stream="IETF"/>
    <author fullname="Colin Perkins" initials="C. S." initials="C." surname="Perkins">
      <organization>University
      <organization showOnFrontPage="true">University of Glasgow</organization>
      <address>
        <postal>
          <street>School of Computing Science</street>
          <city>Glasgow</city>
          <code>G12 8QQ</code>
          <country>United Kingdom</country>
        </postal>
        <email>csp@csperkins.org</email>
        <uri>https://csperkins.org/</uri>
      </address>
    </author>
    <author fullname="Magnus Westerlund" initials="M." surname="Westerlund">
      <organization>Ericsson</organization>
      <organization showOnFrontPage="true">Ericsson</organization>
      <address>
        <postal>
          <street>Farogatan 6</street>

          <city>SE-164 80 Kista</city>
          <street>Torshamnsgatan 23</street>
          <city>Kista</city>
          <code>164 80</code>
          <country>Sweden</country>
        </postal>

        <phone>+46 10 714 82 87</phone>
        <email>magnus.westerlund@ericsson.com</email>
      </address>
    </author>
    <author fullname="Joerg fullname="Jörg Ott" initials="J." surname="Ott">
      <organization>Aalto University</organization>
      <organization showOnFrontPage="true">Technical University Munich</organization>
      <address>
        <postal>
          <street>School
          <extaddr>Department of Informatics</extaddr>
          <extaddr>Chair of Electrical Engineering</street>

          <city>Espoo</city>

          <code>02150</code>

          <country>Finland</country> Connected Mobility</extaddr>
          <street>Boltzmannstrasse 3</street>
          <city>Garching</city>
          <code>85748</code>
          <country>Germany</country>
        </postal>

        <email>jorg.ott@aalto.fi</email>
        <email>ott@in.tum.de</email>
      </address>
    </author>
    <date day="12" month="June" year="2015" />

    <workgroup>RTCWEB Working Group</workgroup>

    <abstract>
      <t>The month="01" year="2021"/>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">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>
    </abstract>
  </front>

  <middle>
    <boilerplate>
      <section title="Introduction">
      <t>The <xref target="RFC3550">Real-time Transport Protocol (RTP)</xref>
      provides anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a framework for delivery product 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, these form Internet Engineering Task Force
            (IETF).  It represents the basis for many teleconferencing systems.</t>

      <t>The Web Real-Time communication (WebRTC) framework provides consensus of the
      protocol building blocks to support direct, interactive, real-time
      communication using audio, video, collaboration, games, etc., between
      two peers' web-browsers. This memo describes how IETF community.  It has
            received public review and has been approved for publication by
            the RTP framework Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is to
      be used available in Section 2 of
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the WebRTC context. It proposes a baseline set current status of RTP
      features that are this document, any
            errata, and how to provide feedback on it may be implemented by all WebRTC Endpoints, along with
      suggested extensions for enhanced functionality.</t>

      <t>This memo specifies a protocol intended for use within obtained at
            <eref target="https://www.rfc-editor.org/info/rfc8834" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and the WebRTC
      framework, but persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is not restricted subject to that context. An overview of BCP 78 and the
      WebRTC framework is given IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in <xref
      target="I-D.ietf-rtcweb-overview"></xref>.</t>

      <t>The structure effect on the date of
            publication of this memo is document. Please review these documents
            carefully, as follows. <xref
      target="sec-rationale"></xref> outlines our rationale in preparing this
      memo they describe your rights and choosing these RTP features. <xref
      target="sec-terminology"></xref> defines terminology. Requirements for
      core RTP protocols are restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in <xref target="sec-rtp-core"></xref>
            Section 4.e of the Trust Legal Provisions and suggested RTP extensions are provided without
            warranty as described in <xref
      target="sec-rtp-extn"></xref>. <xref target="sec-rtp-robust"></xref>
      outlines mechanisms that can increase robustness to network problems,
      while <xref target="sec-rate-control"></xref> describes congestion
      control and rate adaptation mechanisms. The discussion the Simplified BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-rationale">Rationale</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-webrtc-use-of-rtp-core-prot">WebRTC Use of mandated RTP
      mechanisms concludes in <xref target="sec-perf"></xref> with a review RTP: Core Protocols</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-rtp-and-rtcp">RTP and RTCP</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-choice-of-the-rtp-profile">Choice of
      performance monitoring and network management tools. <xref
      target="sec-extn"></xref> gives some guidelines for future incorporation the RTP Profile</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-choice-of-rtp-payload-forma">Choice of other RTP and Payload Formats</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-use-of-rtp-sessions">Use of RTP Sessions</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.5">
                <t indent="0" pn="section-toc.1-1.4.2.5.1"><xref derivedContent="4.5" format="counter" sectionFormat="of" target="section-4.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-rtp-and-rtcp-multiplexing">RTP and RTCP Multiplexing</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.6">
                <t indent="0" pn="section-toc.1-1.4.2.6.1"><xref derivedContent="4.6" format="counter" sectionFormat="of" target="section-4.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-reduced-size-rtcp">Reduced Size RTCP</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.7">
                <t indent="0" pn="section-toc.1-1.4.2.7.1"><xref derivedContent="4.7" format="counter" sectionFormat="of" target="section-4.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-symmetric-rtp-rtcp">Symmetric RTP/RTCP</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.8">
                <t indent="0" pn="section-toc.1-1.4.2.8.1"><xref derivedContent="4.8" format="counter" sectionFormat="of" target="section-4.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-choice-of-rtp-synchronizati">Choice of RTP Control Protocol (RTCP) extensions into this
      framework. <xref target="sec-signalling"></xref> describes requirements
      placed on the signalling channel. <xref target="sec-webrtc-api"></xref>
      discusses the relationship between features Synchronization Source (SSRC)</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.9">
                <t indent="0" pn="section-toc.1-1.4.2.9.1"><xref derivedContent="4.9" format="counter" sectionFormat="of" target="section-4.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-generation-of-the-rtcp-cano">Generation of the RTP framework RTCP Canonical Name (CNAME)</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.10">
                <t indent="0" pn="section-toc.1-1.4.2.10.1"><xref derivedContent="4.10" format="counter" sectionFormat="of" target="section-4.10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-handling-of-leap-seconds">Handling of Leap Seconds</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-webrtc-use-of-rtp-extension">WebRTC Use of RTP: Extensions</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conferencing-extensions-and">Conferencing Extensions and the
      WebRTC application programming interface (API), Topologies</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.1.2">
                  <li pn="section-toc.1-1.5.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.1.1"><xref derivedContent="5.1.1" format="counter" sectionFormat="of" target="section-5.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-full-intra-request-fir">Full Intra Request (FIR)</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.2.1"><xref derivedContent="5.1.2" format="counter" sectionFormat="of" target="section-5.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-picture-loss-indication-pli">Picture Loss Indication (PLI)</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.3">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.3.1"><xref derivedContent="5.1.3" format="counter" sectionFormat="of" target="section-5.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-slice-loss-indication-sli">Slice Loss Indication (SLI)</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.4">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.4.1"><xref derivedContent="5.1.4" format="counter" sectionFormat="of" target="section-5.1.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-reference-picture-selection">Reference Picture Selection Indication (RPSI)</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.5">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.5.1"><xref derivedContent="5.1.5" format="counter" sectionFormat="of" target="section-5.1.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-temporal-spatial-trade-off-">Temporal-Spatial Trade-Off Request (TSTR)</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.1.2.6">
                    <t indent="0" pn="section-toc.1-1.5.2.1.2.6.1"><xref derivedContent="5.1.6" format="counter" sectionFormat="of" target="section-5.1.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-temporary-maximum-media-str">Temporary Maximum Media Stream Bit Rate Request (TMMBR)</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-header-extensions">Header Extensions</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.2.2">
                  <li pn="section-toc.1-1.5.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.1.1"><xref derivedContent="5.2.1" format="counter" sectionFormat="of" target="section-5.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-rapid-synchronization">Rapid Synchronization</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.2.1"><xref derivedContent="5.2.2" format="counter" sectionFormat="of" target="section-5.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-client-to-mixer-audio-level">Client-to-Mixer Audio Level</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.3.1"><xref derivedContent="5.2.3" format="counter" sectionFormat="of" target="section-5.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mixer-to-client-audio-level">Mixer-to-Client Audio Level</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.2.2.4">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.4.1"><xref derivedContent="5.2.4" format="counter" sectionFormat="of" target="section-5.2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-media-stream-identification">Media Stream Identification</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.2.2.5">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.5.1"><xref derivedContent="5.2.5" format="counter" sectionFormat="of" target="section-5.2.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-coordination-of-video-orien">Coordination of Video Orientation</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-webrtc-use-of-rtp-improving">WebRTC Use of RTP: Improving Transport Robustness</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-negative-acknowledgements-a">Negative Acknowledgements and <xref
      target="sec-rtp-func"></xref> discusses RTP implementation
      considerations. The memo concludes with <xref
      target="sec-security">security considerations</xref> Retransmission</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-forward-error-correction-fe">Forward Error Correction (FEC)</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-webrtc-use-of-rtp-rate-cont">WebRTC Use of RTP: Rate Control and <xref
      target="sec-iana">IANA considerations</xref>.</t>
    </section>

    <section anchor="sec-rationale" title="Rationale">
      <t>The RTP framework comprises the RTP data transfer protocol, the RTP
      control protocol, Media Adaptation</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-boundary-conditions-and-cir">Boundary Conditions and numerous RTP payload formats, profiles, Circuit Breakers</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-congestion-control-interope">Congestion Control Interoperability and
      extensions. This range Legacy Systems</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-webrtc-use-of-rtp-performan">WebRTC Use of add-ons has allowed RTP to meet various needs
      that were not envisaged by the original protocol designers, RTP: Performance Monitoring</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-webrtc-use-of-rtp-future-ex">WebRTC Use of RTP: Future Extensions</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-signaling-considerations">Signaling Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-webrtc-api-considerations">WebRTC API Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" format="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-rtp-implementation-consider">RTP Implementation Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.12.2">
              <li pn="section-toc.1-1.12.2.1">
                <t indent="0" pn="section-toc.1-1.12.2.1.1"><xref derivedContent="12.1" format="counter" sectionFormat="of" target="section-12.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-configuration-and-use-of-rt">Configuration and to
      support many new media encodings, but raises the question Use of what
      extensions are to be supported by new implementations. The development RTP Sessions</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.12.2.1.2">
                  <li pn="section-toc.1-1.12.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.12.2.1.2.1.1"><xref derivedContent="12.1.1" format="counter" sectionFormat="of" target="section-12.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-use-of-multiple-media-sourc">Use of the WebRTC framework provides Multiple Media Sources within an opportunity to review the available RTP features and extensions, Session</xref></t>
                  </li>
                  <li pn="section-toc.1-1.12.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.12.2.1.2.2.1"><xref derivedContent="12.1.2" format="counter" sectionFormat="of" target="section-12.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-use-of-multiple-rtp-session">Use of Multiple RTP Sessions</xref></t>
                  </li>
                  <li pn="section-toc.1-1.12.2.1.2.3">
                    <t indent="0" pn="section-toc.1-1.12.2.1.2.3.1"><xref derivedContent="12.1.3" format="counter" sectionFormat="of" target="section-12.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-differentiated-treatment-of">Differentiated Treatment of RTP Streams</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.12.2.2">
                <t indent="0" pn="section-toc.1-1.12.2.2.1"><xref derivedContent="12.2" format="counter" sectionFormat="of" target="section-12.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-media-source-rtp-streams-an">Media Source, RTP Streams, and to define Participant Identification</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.12.2.2.2">
                  <li pn="section-toc.1-1.12.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.12.2.2.2.1.1"><xref derivedContent="12.2.1" format="counter" sectionFormat="of" target="section-12.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-media-source-identification">Media Source Identification</xref></t>
                  </li>
                  <li pn="section-toc.1-1.12.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.12.2.2.2.2.1"><xref derivedContent="12.2.2" format="counter" sectionFormat="of" target="section-12.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ssrc-collision-detection">SSRC Collision Detection</xref></t>
                  </li>
                  <li pn="section-toc.1-1.12.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.12.2.2.2.3.1"><xref derivedContent="12.2.3" format="counter" sectionFormat="of" target="section-12.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-media-synchronization-conte">Media Synchronization Context</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="13" format="counter" sectionFormat="of" target="section-13"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.14">
            <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="14" format="counter" sectionFormat="of" target="section-14"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.15">
            <t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="15" format="counter" sectionFormat="of" target="section-15"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.15.2">
              <li pn="section-toc.1-1.15.2.1">
                <t indent="0" pn="section-toc.1-1.15.2.1.1"><xref derivedContent="15.1" format="counter" sectionFormat="of" target="section-15.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.15.2.2">
                <t indent="0" pn="section-toc.1-1.15.2.2.1"><xref derivedContent="15.2" format="counter" sectionFormat="of" target="section-15.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.16">
            <t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.17">
            <t indent="0" pn="section-toc.1-1.17.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">The <xref target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550">Real-time Transport Protocol (RTP)</xref>
      provides a common baseline framework for delivery of audio and video teleconferencing
      data and other real-time media applications. Previous work has defined
      the RTP feature
      set protocol, along with numerous profiles, payload formats, and
      other extensions. When combined with appropriate signaling, these form
      the basis for all WebRTC Endpoints. many teleconferencing systems.</t>
      <t indent="0" pn="section-1-2">The Web Real-Time Communication (WebRTC) framework provides the
      protocol building blocks to support direct, interactive, real-time
      communication using audio, video, collaboration, games, etc. between
      two peers' web browsers. This builds on memo describes how the past 20 years of RTP
      development framework is to mandate the use of extensions that have shown widespread
      utility, while still remaining compatible with
      be used in the wide installed base WebRTC context. It proposes a baseline set of RTP implementations where possible.</t>

      <t>RTP and RTCP extensions
      features that are not discussed in this document can to be implemented by all WebRTC Endpoints if they are beneficial endpoints, along with
      suggested extensions for enhanced functionality.</t>
      <t indent="0" pn="section-1-3">This memo specifies a protocol intended for new use
      cases. However, they are within the WebRTC
      framework but is not necessary restricted to address that context. An overview of the
      WebRTC use cases
      and requirements identified framework is given in <xref target="RFC7478"></xref>.</t>

      <t>While the baseline set target="RFC8825" format="default" sectionFormat="of" derivedContent="RFC8825"/>.</t>
      <t indent="0" pn="section-1-4">The structure 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 as follows. <xref target="sec-rationale" format="default" sectionFormat="of" derivedContent="Section 2"/> outlines our rationale for other conferencing-related uses of
      RTP. In particular, it is likely that preparing this set of RTP features
      memo and
      extensions will be appropriate for other desktop or mobile video
      conferencing systems, or choosing these RTP features. <xref target="sec-terminology" format="default" sectionFormat="of" derivedContent="Section 3"/> defines terminology. Requirements for room-based high-quality telepresence
      applications.</t>
    </section>

    <section anchor="sec-terminology" title="Terminology">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
      core RTP protocols are described in this
      document <xref target="sec-rtp-core" format="default" sectionFormat="of" derivedContent="Section 4"/>,
      and suggested RTP extensions are to be interpreted as described in <xref
      target="RFC2119"></xref>. target="sec-rtp-extn" format="default" sectionFormat="of" derivedContent="Section 5"/>. <xref target="sec-rtp-robust" format="default" sectionFormat="of" derivedContent="Section 6"/>
      outlines mechanisms that can increase robustness to network problems,
      while <xref target="sec-rate-control" format="default" sectionFormat="of" derivedContent="Section 7"/> describes
      congestion control and rate adaptation mechanisms. The RFC 2119 interpretation discussion of these key words
      applies only when written
      mandated RTP
      mechanisms concludes in ALL CAPS. Lower- or mixed-case uses <xref target="sec-perf" format="default" sectionFormat="of" derivedContent="Section 8"/> with a review of
      these key words are not to be interpreted as carrying special
      significance in
      performance monitoring and network management tools. <xref target="sec-extn" format="default" sectionFormat="of" derivedContent="Section 9"/> gives some guidelines for future incorporation
      of other RTP and RTP Control Protocol (RTCP) extensions into this memo.</t>

      <t>We define
      framework. <xref target="sec-signalling" format="default" sectionFormat="of" derivedContent="Section 10"/> describes requirements
      placed on the following additional terms:<list style="hanging">
          <t hangText="WebRTC MediaStream:">The MediaStream concept defined by signaling channel. <xref target="sec-webrtc-api" format="default" sectionFormat="of" derivedContent="Section 11"/>
      discusses the W3C in relationship between features of the RTP framework and the
      WebRTC application programming interface (API), and <xref
          target="W3C.WD-mediacapture-streams-20130903">WebRTC API</xref>. A
          MediaStream consists of zero or more MediaStreamTracks.</t> target="sec-rtp-func" format="default" sectionFormat="of" derivedContent="Section 12"/> discusses RTP implementation
      considerations. The memo concludes with <xref target="sec-security" format="default" sectionFormat="of" derivedContent="Section 13">security considerations</xref> and <xref target="sec-iana" format="default" sectionFormat="of" derivedContent="Section 14">IANA considerations</xref>.</t>
    </section>
    <section anchor="sec-rationale" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-rationale">Rationale</name>
      <t hangText="MediaStreamTrack:">Part of the MediaStream concept
          defined by indent="0" pn="section-2-1">The RTP framework comprises the W3C in RTP data transfer protocol, the <xref
          target="W3C.WD-mediacapture-streams-20130903">WebRTC API</xref>. A
          MediaStreamTrack is an individual stream of media from any type RTP
      control protocol, and numerous RTP payload formats, profiles, and
      extensions. This range of
          media source like a microphone or a camera, add-ons has allowed RTP to meet various needs
      that were not envisaged by the original protocol designers and support
      many new media encodings, but also conceptual
          sources, like a audio mix or a video composition, are possible.</t>

          <t hangText="Transport-layer Flow:">A uni-directional flow it raises the question of
          transport packets that what
      extensions are identified to be supported by having a particular 5-tuple new implementations. The development
      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
          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 WebRTC framework provides an opportunity to review the forward path transport-layer flow, available
      RTP features and the
          transport protocol is the same.</t>
        </list></t>

      <t>This document uses the terminology from <xref
      target="I-D.ietf-avtext-rtp-grouping-taxonomy"></xref> extensions and <xref
      target="I-D.ietf-rtcweb-overview"></xref>. Other terms are used
      according to their definitions from the <xref target="RFC3550">RTP
      Specification</xref>. Especially note the following frequently used
      terms: define a common baseline RTP Stream, feature
      set for all WebRTC endpoints. This builds on the past 20 years of RTP Session, and Endpoint.</t>
    </section>

    <section anchor="sec-rtp-core" title="WebRTC Use
      development to mandate the use of RTP: Core Protocols">
      <t>The following sections describe extensions that have shown widespread
      utility, while still remaining compatible with the core features wide installed base
      of RTP implementations where possible.</t>
      <t indent="0" pn="section-2-2">RTP and RTCP extensions that need to are not discussed in this document can
      be implemented, along with the mandated RTP profiles. Also
      described implemented by WebRTC endpoints if they are beneficial for new use
      cases. However, they are not necessary to address the core extensions providing essential features that all WebRTC Endpoints need to implement to function effectively on today's
      networks.</t>

      <section anchor="sec-rtp-rtcp" title="RTP use cases
      and RTCP">
        <t>The requirements identified in <xref target="RFC3550">Real-time Transport Protocol (RTP)
        </xref> is REQUIRED to be implemented as the media transport protocol
        for WebRTC. RTP itself comprises two parts: target="RFC7478" format="default" sectionFormat="of" derivedContent="RFC7478"/>.</t>
      <t indent="0" pn="section-2-3">While the baseline set of RTP data transfer
        protocol, features and extensions defined in this
      memo is targeted at the RTP control protocol (RTCP). RTCP requirements of the WebRTC framework, it is a fundamental
        and integral part
      expected to be broadly useful for other conferencing-related uses of RTP,
      RTP. In particular, it is likely that this set of RTP features and MUST
      extensions will be implemented appropriate for other desktop or mobile
      video-conferencing systems, or for room-based high-quality telepresence
      applications.</t>
    </section>
    <section anchor="sec-terminology" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-3-1">
    The key words "<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 used "<bcp14>OPTIONAL</bcp14>" in all
        WebRTC Endpoints.</t>

        <t>The following RTP and RTCP features this document are sometimes omitted to be interpreted as
    described in
        limited functionality implementations of RTP, but are REQUIRED BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/>
    when, and only when, they appear in all
        WebRTC Endpoints: <list style="symbols">
            <t>Support for use capitals, as shown here.
    Lower- or mixed-case uses of multiple simultaneous SSRC values
      these key words are not to be interpreted as carrying special
      significance in a
            single RTP session, including support for RTP endpoints that send
            many SSRC values simultaneously, this memo.
</t>
      <t indent="0" pn="section-3-2">We define the following <xref
            target="RFC3550"></xref> and <xref
            target="I-D.ietf-avtcore-rtp-multi-stream"></xref>. The RTCP
            optimisations for multi-SSRC sessions additional terms:</t>
      <dl newline="false" spacing="normal" indent="3" pn="section-3-3">
        <dt pn="section-3-3.1">WebRTC MediaStream:</dt>
        <dd pn="section-3-3.2">The MediaStream concept defined by
          the W3C in <xref
            target="I-D.ietf-avtcore-rtp-multi-stream-optimisation"></xref>
            MAY be supported; if supported the usage MUST be signalled.</t>

            <t>Random choice of SSRC on joining a session; collision detection
            and resolution for SSRC values (see also <xref
            target="sec-ssrc"></xref>).</t>

            <t>Support for reception target="W3C.WD-mediacapture-streams" format="default" sectionFormat="of" derivedContent="W3C.WD-mediacapture-streams">WebRTC API</xref>. A
          MediaStream consists of RTP data packets containing CSRC
            lists, as generated zero or more MediaStreamTracks.</dd>
        <dt pn="section-3-3.3">MediaStreamTrack:</dt>
        <dd pn="section-3-3.4">Part of the MediaStream concept
          defined by RTP mixers, and RTCP packets relating to
            CSRCs.</t>

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

            <t>Support for multiple synchronisation contexts. Participants
            that send multiple simultaneous RTP packet streams SHOULD do so as
            part target="W3C.WD-mediacapture-streams" format="default" sectionFormat="of" derivedContent="W3C.WD-mediacapture-streams">WebRTC API</xref>. A
          MediaStreamTrack is an individual stream of media from any type of
          media source such as a single synchronisation context, using a single RTCP
            CNAME for all streams and allowing receivers to play the streams
            out in microphone or a synchronised manner. For compatibility with potential
            future versions of this specification, camera, but conceptual
          sources such as an audio mix or for interoperability
            with non-WebRTC devices through a gateway, receivers MUST support
            multiple synchronisation contexts, indicated video composition are also possible.</dd>
        <dt pn="section-3-3.5">Transport-layer flow:</dt>
        <dd pn="section-3-3.6">A unidirectional flow of
          transport packets that are identified by the use a particular 5-tuple
          of
            multiple RTCP CNAMEs source IP address, source port, destination IP address,
          destination port, and transport protocol.</dd>
        <dt pn="section-3-3.7">Bidirectional transport-layer flow:</dt>
        <dd pn="section-3-3.8">A bidirectional
          transport-layer flow is a transport-layer flow that is symmetric.
          That is, the transport-layer flow in an RTP session. This specification
            mandates the usage of reverse direction has a single CNAME when sending RTP
            Streams in some circumstances, see <xref
            target="sec-cname"></xref>.</t>

            <t>Support for sending
          5-tuple where the source and receiving RTCP SR, RR, SDES, destination address and BYE
            packet types. Note that support for other RTCP packet types is
            OPTIONAL, unless mandated by other parts of this specification.
            Note that additional RTCP Packet types ports are used by
          swapped compared to the <xref
            target="sec-profile">RTP/SAVPF Profile</xref> forward path transport-layer flow, and the other <xref
            target="sec-rtp-extn">RTCP extensions</xref>. WebRTC endpoints
            that implement
          transport protocol is the SDP bundle negotiation extension will use same.</dd>
      </dl>
      <t indent="0" pn="section-3-4">This document uses the
            SDP grouping framework 'mid' attribute terminology from <xref target="RFC7656" format="default" sectionFormat="of" derivedContent="RFC7656"/> and <xref target="RFC8825" format="default" sectionFormat="of" derivedContent="RFC8825"/>. Other terms are used
      according to identify media streams.
            Such endpoints MUST implement their definitions from the RTCP SDES MID item described in <xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"></xref>.</t>

            <t>Support for multiple endpoints in a single target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550">RTP
      specification</xref>. In particular, note the following frequently used
      terms: RTP stream, RTP session, and for
            scaling endpoint.</t>
    </section>
    <section anchor="sec-rtp-core" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-webrtc-use-of-rtp-core-prot">WebRTC Use of RTP: Core Protocols</name>
      <t indent="0" pn="section-4-1">The following sections describe the core features of RTP and RTCP transmission interval according
      that need to be implemented, along with the number of
            participants in mandated RTP profiles. Also
      described are the session; support for randomised RTCP
            transmission intervals core extensions providing essential features that all
      WebRTC endpoints need to avoid synchronisation of RTCP reports;
            support for RTCP timer reconsideration (Section 6.3.6 of <xref
            target="RFC3550"></xref>) implement to function effectively on today's
      networks.</t>
      <section anchor="sec-rtp-rtcp" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-rtp-and-rtcp">RTP and reverse reconsideration (Section
            6.3.4 of RTCP</name>
        <t indent="0" pn="section-4.1-1">The <xref target="RFC3550"></xref>).</t>

            <t>Support for configuring the RTCP bandwidth target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550">Real-time Transport Protocol (RTP)
          </xref> is <bcp14>REQUIRED</bcp14> to be implemented as a fraction of the media bandwidth, and transport protocol
        for configuring the fraction of the RTCP
            bandwidth allocated to senders, e.g., using WebRTC. RTP itself comprises two parts: the SDP "b=" line
            <xref target="RFC4566"></xref><xref target="RFC3556"></xref>.</t>

            <t>Support for RTP data transfer
        protocol and the reduced minimum RTP Control Protocol (RTCP). RTCP reporting interval
            described in Section 6.2 is a fundamental
        and integral part of <xref target="RFC3550"></xref>. When
            using the reduced minimum RTCP reporting interval, the fixed
            (non-reduced) minimum interval MUST RTP and <bcp14>MUST</bcp14> be implemented and used when calculating the
            participant timeout interval (see Sections 6.2 in all
        WebRTC endpoints.</t>
        <t indent="0" pn="section-4.1-2">The following RTP and 6.3.5 of <xref
            target="RFC3550"></xref>). The delay before sending the initial
            compound RTCP packet can be set to zero (see Section 6.2 features are sometimes omitted in
        limited-functionality implementations of <xref
            target="RFC3550"></xref> as updated by <xref
            target="I-D.ietf-avtcore-rtp-multi-stream"></xref>).</t>

            <t>Support RTP, but they are <bcp14>REQUIRED</bcp14> in all
        WebRTC endpoints: </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-3">
          <li pn="section-4.1-3.1">Support for use of multiple simultaneous synchronization source
            (SSRC) values in a
            single RTP session, including support for discontinuous transmission. RTP allows endpoints to
            pause and resume transmission at any time. When resuming, that send
            many SSRC values simultaneously, following <xref target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550"/> and <xref target="RFC8108" format="default" sectionFormat="of" derivedContent="RFC8108"/>. The RTCP
            optimizations for multi-SSRC sessions defined in <xref target="RFC8861" format="default" sectionFormat="of" derivedContent="RFC8861"/>
            <bcp14>MAY</bcp14> be supported; if supported, the usage <bcp14>MUST</bcp14> be signaled.</li>
          <li pn="section-4.1-3.2">Random choice of SSRC on joining a session; collision detection
            and resolution for SSRC values (see also <xref target="sec-ssrc" format="default" sectionFormat="of" derivedContent="Section 4.8"/>).</li>
          <li pn="section-4.1-3.3">Support for reception of RTP
            sequence number will increase data packets containing
            contributing source (CSRC)
            lists, as generated by one, RTP mixers, and RTCP packets relating to
            CSRCs.</li>
          <li pn="section-4.1-3.4">Sending correct synchronization information in the RTCP Sender
            Reports, to allow receivers to implement lip synchronization; see
            <xref target="rapid-sync" format="default" sectionFormat="of" derivedContent="Section 5.2.1"/> regarding support for the rapid
            RTP synchronization extensions.</li>
          <li pn="section-4.1-3.5">Support for multiple synchronization contexts. Participants
            that send multiple simultaneous RTP packet streams <bcp14>SHOULD</bcp14> do so as usual, while
            part of a single synchronization context, using a single RTCP
            CNAME for all streams and allowing receivers to play the increase streams
            out in a synchronized manner. For compatibility with potential
            future versions of this specification, or for interoperability
            with non-WebRTC devices through a gateway, receivers <bcp14>MUST</bcp14> support
            multiple synchronization contexts, indicated by the use of
            multiple RTCP CNAMEs in an RTP timestamp value will depend on session. This specification
            mandates the duration usage of the
            pause. Discontinuous transmission is most commonly used with a single CNAME when sending RTP
            streams in some
            audio payload formats, but is not audio specific, circumstances; see <xref target="sec-cname" format="default" sectionFormat="of" derivedContent="Section 4.9"/>.</li>
          <li pn="section-4.1-3.6">Support for sending and can be used
            with any RTP payload format.</t>

            <t>Ignore unknown receiving RTCP Sender Report (SR), Receiver  Report (RR), Source Description (SDES), and BYE
            packet types. Note that support for other RTCP packet types and RTP header extensions.
            This is to ensure robust handling
            <bcp14>OPTIONAL</bcp14> unless mandated by other parts of future extensions, middlebox
            behaviours, etc., this specification.
            Note that can result in not signalled additional RTCP packet types or RTP header extensions being received. If a compound RTCP
            packet is received that contains a mixture of known are used by the <xref target="sec-profile" format="default" sectionFormat="of" derivedContent="Section 4.2">RTP/SAVPF profile</xref> and unknown
            RTCP packet types, the known packets types need other <xref target="sec-rtp-extn" format="default" sectionFormat="of" derivedContent="Section 5">RTCP extensions</xref>. WebRTC endpoints
            that implement the Session Description Protocol (SDP) bundle
            negotiation extension will use the
            SDP Grouping Framework "mid" attribute to be processed as
            usual, with only identify media streams.
            Such endpoints <bcp14>MUST</bcp14> implement the unknown packet types being discarded.</t>
          </list></t>

        <t>It is known that RTCP SDES media
            identification (MID) item described in
            <xref target="RFC8843" format="default" sectionFormat="of" derivedContent="RFC8843"/>.</li>
          <li pn="section-4.1-3.7">Support for multiple endpoints in a significant number of legacy single RTP
        implementations, especially those targeted at VoIP-only systems, do
        not support all of the above features, session, and in some cases do not
        support for
            scaling the RTCP at all. Implementers are advised transmission interval according to consider the
        requirements for graceful degradation when interoperating with legacy
        implementations.</t>

        <t>Other implementation considerations are discussed in <xref
        target="sec-rtp-func"></xref>.</t>
      </section>

      <section anchor="sec-profile" title="Choice number of
            participants in the RTP Profile">
        <t>The complete specification session; support for randomized RTCP
            transmission intervals to avoid synchronization of RTP RTCP reports;
            support for a particular application
        domain requires RTCP timer reconsideration (<xref target="RFC3550" section="6.3.6" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3550#section-6.3.6" derivedContent="RFC3550"/>) and
            reverse reconsideration (<xref target="RFC3550" sectionFormat="of" section="6.3.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3550#section-6.3.4" derivedContent="RFC3550"/>).</li>
          <li pn="section-4.1-3.8">Support for configuring the choice RTCP bandwidth as a fraction of an RTP Profile. For WebRTC use, the
        <xref target="RFC5124">Extended Secure RTP Profile
            media bandwidth, and for RTCP-Based
        Feedback (RTP/SAVPF)</xref>, as extended by <xref
        target="RFC7007"></xref>, MUST be implemented. The RTP/SAVPF profile
        is configuring the combination fraction of basic <xref target="RFC3551">RTP/AVP
        profile</xref>, the <xref target="RFC4585">RTP profile for RTCP-based
        feedback (RTP/AVPF)</xref>, and RTCP
            bandwidth allocated to senders -- e.g., using the SDP "b=" line
            <xref target="RFC3711">secure RTP
        profile (RTP/SAVP)</xref>.</t>

        <t>The RTCP-based feedback extensions <xref target="RFC4585"></xref>
        are needed target="RFC4566" format="default" sectionFormat="of" derivedContent="RFC4566"/> <xref target="RFC3556" format="default" sectionFormat="of" derivedContent="RFC3556"/>.</li>
          <li pn="section-4.1-3.9">Support for the improved RTCP timer model. This allows more
        flexible transmission of reduced minimum RTCP packets reporting interval
            described in response to events, rather
        than strictly according <xref target="RFC3550" sectionFormat="of" section="6.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3550#section-6.2" derivedContent="RFC3550"/>. When
            using the reduced minimum RTCP reporting interval, the fixed
            (nonreduced) minimum interval <bcp14>MUST</bcp14> be used when calculating the
            participant timeout interval (see Sections <xref target="RFC3550" section="6.2" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3550#section-6.2" derivedContent="RFC3550"/> and <xref target="RFC3550" section="6.3.5" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3550#section-6.3.5" derivedContent="RFC3550"/> of <xref target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550"/>). The delay before sending the
            initial
            compound RTCP packet can be set to bandwidth, and is vital zero (see <xref target="RFC3550" section="6.2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3550#section-6.2" derivedContent="RFC3550"/> as updated by <xref target="RFC8108" format="default" sectionFormat="of" derivedContent="RFC8108"/>).</li>
          <li pn="section-4.1-3.10">Support for being able discontinuous transmission. RTP allows endpoints to
        report congestion signals as well as media events. These extensions
        also allow saving RTCP bandwidth,
            pause and an endpoint resume transmission at any time. When resuming, the RTP
            sequence number will commonly only
        use increase by one, as usual, while the full RTCP bandwidth allocation if there are many events that
        require feedback. The timer rules are also needed to make use of increase
            in the RTP conferencing extensions discussed in <xref
        target="conf-ext"></xref>.</t>

        <t><list style="empty">
            <t>Note: The enhanced RTCP timer model defined in timestamp value will depend on the RTP/AVPF
            profile duration of the
            pause. Discontinuous transmission is backwards compatible most commonly used 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
            audio payload formats, but it is not audio specific and
            "trr-int" (the most important factor for interworking can be used
            with
            RTP/(S)AVP endpoints via a gateway any RTP payload format.</li>
          <li pn="section-4.1-3.11">Ignore unknown RTCP packet types and RTP header extensions.
            This is to set the trr-int parameter
            to a value representing 4 seconds, see Section 6.1 ensure robust handling of future extensions, middlebox
            behaviors, etc., that can result in <xref
            target="I-D.ietf-avtcore-rtp-multi-stream"></xref>).</t>
          </list></t>

        <t>The secure receiving RTP (SRTP) profile header
            extensions <xref
        target="RFC3711"></xref> are needed to provide media encryption,
        integrity protection, replay protection and or RTCP packet types that were not signaled. If a limited form of source
        authentication. WebRTC Endpoints MUST NOT send packets using the basic
        RTP/AVP profile or the RTP/AVPF profile; they MUST employ compound RTCP
            packet that contains a mixture of known and unknown
            RTCP packet types is received, the full
        RTP/SAVPF profile known packet types need to protect all be processed as
            usual, with only the unknown packet types being discarded.</li>
        </ul>
        <t indent="0" pn="section-4.1-4">It is known that a significant number of legacy RTP
        implementations, especially those targeted at systems with
        only Voice over IP (VoIP), do
        not support all of the above features and in some cases do not
        support RTCP packets that at all. Implementers are
        generated (i.e., implementations MUST use SRTP and SRTCP). The
        RTP/SAVPF profile MUST be configured using advised to consider the cipher suites,
        DTLS-SRTP protection profiles, keying mechanisms, and other parameters
        described
        requirements for graceful degradation when interoperating with legacy
        implementations.</t>
        <t indent="0" pn="section-4.1-5">Other implementation considerations are discussed in <xref target="I-D.ietf-rtcweb-security-arch"></xref>.</t> target="sec-rtp-func" format="default" sectionFormat="of" derivedContent="Section 12"/>.</t>
      </section>
      <section anchor="sec.codecs" title="Choice anchor="sec-profile" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-choice-of-the-rtp-profile">Choice of the RTP Payload Formats">
        <t>Mandatory to implement audio codecs and Profile</name>
        <t indent="0" pn="section-4.2-1">The complete specification of RTP payload formats for a particular application
        domain requires the choice of an RTP profile. For WebRTC endpoints are defined in use, the
        <xref
        target="I-D.ietf-rtcweb-audio"></xref>. Mandatory to implement video
        codecs and target="RFC5124" format="default" sectionFormat="of" derivedContent="RFC5124">extended secure RTP payload formats profile for WebRTC endpoints are defined in
        RTCP-based feedback
        (RTP/SAVPF)</xref>, as extended by <xref target="I-D.ietf-rtcweb-video"></xref>. WebRTC endpoints MAY
        additionally implement any other codec target="RFC7007" format="default" sectionFormat="of" derivedContent="RFC7007"/>, <bcp14>MUST</bcp14> be implemented. The RTP/SAVPF profile
        is the combination of the basic <xref target="RFC3551" format="default" sectionFormat="of" derivedContent="RFC3551">RTP/AVP
        profile</xref>, the <xref target="RFC4585" format="default" sectionFormat="of" derivedContent="RFC4585">RTP profile for which an RTP payload format RTCP-based
        feedback (RTP/AVPF)</xref>, and associated signalling has been defined.</t>

        <t>WebRTC Endpoints cannot assume that the other participants in an
        RTP session understand any RTP payload format, no matter how common.
        The mapping between RTP payload type numbers and specific
        configurations of particular <xref target="RFC3711" format="default" sectionFormat="of" derivedContent="RFC3711">secure RTP payload formats MUST be agreed before
        those payload types/formats can be used. In an SDP context, this can
        be done using the "a=rtpmap:" and "a=fmtp:" attributes associated with
        an "m=" line, along with any other SDP attributes
        profile (RTP/SAVP)</xref>.</t>
        <t indent="0" pn="section-4.2-2">The RTCP-based feedback extensions <xref target="RFC4585" format="default" sectionFormat="of" derivedContent="RFC4585"/>
        are needed to configure
        the RTP payload format.</t>

        <t>Endpoints can signal support for multiple RTP payload formats, or
        multiple configurations the improved RTCP timer model. This allows more
        flexible transmission of a single RTP payload format, as long as
        each unique RTP payload format configuration uses a different RTP
        payload type number. As outlined RTCP packets in <xref target="sec-ssrc"></xref>,
        the RTP payload type number is sometimes used response to associate an RTP
        packet stream with a signalling context. This association events, rather
        than strictly according to bandwidth, and is possible
        provided unique RTP payload type numbers are used in each context. For
        example, an RTP packet stream can be associated with vital for being able to
        report congestion signals as well as media events. These extensions
        also allow saving RTCP bandwidth, and an SDP "m=" line
        by comparing endpoint will commonly only
        use the RTP payload type numbers used by full RTCP bandwidth allocation if there are many events that
        require feedback. The timer rules are also needed to make use of the
        RTP packet
        stream with payload types signalled conferencing extensions discussed in the "a=rtpmap:" lines <xref target="conf-ext" format="default" sectionFormat="of" derivedContent="Section 5.1"/>.</t>
        <aside pn="section-4.2-3">
          <t indent="0" pn="section-4.2-3.1">Note: The enhanced RTCP timer model defined in the
        media sections of the SDP. This leads to the following
        considerations:<list style="empty">
            <t>If RTP packet streams are being associated RTP/AVPF
            profile is backwards compatible with signalling
            contexts based legacy systems that implement
            only the RTP/AVP or RTP/SAVP profile, given some constraints on
            parameter configuration such as the RTP payload type, then RTCP bandwidth value and
            "trr‑int". The most important factor for interworking with
            RTP/(S)AVP endpoints via a gateway is to set the assignment "trr-int" parameter
            to a value representing 4 seconds; see <xref target="RFC8108" section="7.1.3" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8108#section-7.1.3" derivedContent="RFC8108"/>.</t>
        </aside>
        <t indent="0" pn="section-4.2-4">The secure RTP (SRTP) profile extensions <xref target="RFC3711" format="default" sectionFormat="of" derivedContent="RFC3711"/> are needed to provide media encryption,
        integrity protection, replay protection, and a limited form of source
        authentication. WebRTC endpoints <bcp14>MUST NOT</bcp14> send packets using the basic
        RTP/AVP profile or the RTP/AVPF profile; they <bcp14>MUST</bcp14> employ the full
        RTP/SAVPF profile to protect all RTP
            payload type numbers MUST and RTCP packets that are
        generated. In other words, implementations <bcp14>MUST</bcp14> use SRTP and Secure RTCP (SRTCP). The
        RTP/SAVPF profile <bcp14>MUST</bcp14> be unique across signalling
            contexts.</t>

            <t>If configured using the same cipher suites,
        DTLS-SRTP protection profiles, keying mechanisms, and other parameters
        described in <xref target="RFC8827" format="default" sectionFormat="of" derivedContent="RFC8827"/>.</t>
      </section>
      <section anchor="sec.codecs" numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-choice-of-rtp-payload-forma">Choice of RTP Payload Formats</name>
        <t indent="0" pn="section-4.3-1">Mandatory-to-implement audio codecs and RTP payload format configuration is used formats for
        WebRTC endpoints are defined in
            multiple contexts, then a different <xref target="RFC7874" format="default" sectionFormat="of" derivedContent="RFC7874"/>. Mandatory-to-implement video
        codecs and RTP payload type number has to
            be assigned formats for WebRTC endpoints are defined in each context to ensure uniqueness.</t>

            <t>If the
        <xref target="RFC7742" format="default" sectionFormat="of" derivedContent="RFC7742"/>. WebRTC endpoints <bcp14>MAY</bcp14>
        additionally implement any other codec for which an RTP payload type number is not being used to associate
            RTP packet streams with a signalling context, then format
        and associated signaling has been defined.</t>
        <t indent="0" pn="section-4.3-2">WebRTC endpoints cannot assume that the same other participants in an
        RTP
            payload type number can be used to indicate the exact same session understand any RTP payload format configuration in multiple contexts.</t>
          </list>A single format, no matter how common.
        The mapping between RTP payload type number MUST NOT be assigned to
        different RTP payload formats, or different numbers and specific
        configurations of the same particular RTP payload format, within a single RTP session (note that formats <bcp14>MUST</bcp14> be agreed before
        those payload types/formats can be used. In an SDP context, this can
        be done using the "m="
        lines in "a=rtpmap:" and "a=fmtp:" attributes associated with
        an <xref target="I-D.ietf-mmusic-sdp-bundle-negotiation">SDP
        bundle group</xref> form a single "m=" line, along with any other SDP attributes needed to configure
        the RTP session).</t>

        <t>An endpoint that has signalled payload format.</t>
        <t indent="0" pn="section-4.3-3">Endpoints can signal support for multiple RTP payload formats MUST be able to accept data in any or
        multiple configurations of those a single RTP payload formats at
        any time, unless it has previously signalled limitations on its
        decoding capability. This requirement is constrained if several types
        of media (e.g., audio and video) are sent in the same format, as long as
        each unique RTP session. In
        such a case, payload format configuration uses a source (SSRC) is restricted to switching only between
        the different RTP
        payload formats signalled for the type of media that is being
        sent by that source; see number. As outlined in <xref target="sec.session-mux"></xref>. To
        support rapid rate adaptation by changing codec, RTP does not require
        advance signalling for changes between target="sec-ssrc" format="default" sectionFormat="of" derivedContent="Section 4.8"/>,
        the RTP payload formats type number is sometimes used by to associate an RTP
        packet stream with a
        single SSRC that were signalled during session set-up.</t>

        <t>If performing changes between two signaling context. This association is possible
        provided unique RTP payload types that use
        different type numbers are used in each context. For
        example, an RTP clock rates, packet stream can be associated with an SDP "m=" line
        by comparing the RTP sender MUST follow payload type numbers used by the
        recommendations in Section 4.1 of <xref target="RFC7160"></xref>. RTP
        receivers MUST follow packet
        stream with payload types signaled in the recommendations "a=rtpmap:" lines in Section 4.3 the
        media sections of <xref
        target="RFC7160"></xref> in order the SDP. This leads to support sources that switch
        between clock rates in an the following
        considerations:</t>
        <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-4.3-4">
          <li pn="section-4.3-4.1">If RTP session (these recommendations for
        receivers packet streams are backwards compatible being associated with signaling
            contexts based on the case where senders use
        only a single clock rate).</t>
      </section>

      <section anchor="sec.session-mux" title="Use of RTP Sessions">
        <t>An association amongst a set payload type, then the assignment of endpoints communicating using RTP
        is known as an RTP session <xref target="RFC3550"></xref>. An endpoint
        can
            payload type numbers <bcp14>MUST</bcp14> be involved in several RTP sessions at unique across signaling
            contexts.</li>
          <li pn="section-4.3-4.2">If the same time. In a
        multimedia session, each type of media has typically been carried in a
        separate RTP session (e.g., using one RTP session for the audio, and a
        separate RTP session using payload format configuration is used in
            multiple contexts, then a different transport-layer flow for the
        video). WebRTC Endpoints are REQUIRED RTP payload type number has to implement support for
        multimedia sessions
            be assigned 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 networks, however, with the widespread use of network
        address/port translators (NAT/NAPT) and firewalls, it is desirable context to
        reduce ensure uniqueness.</li>
          <li pn="section-4.3-4.3">If the RTP payload type number of transport-layer flows is not being used by to associate
            RTP applications.
        This packet streams with a signaling context, then the same RTP
            payload type number can be done by sending all used to indicate the exact same RTP packet streams
            payload format configuration in a multiple contexts.</li>
        </ul>
        <t indent="0" pn="section-4.3-5">A single RTP
        session, which will comprise payload type number <bcp14>MUST NOT</bcp14> be assigned to
        different RTP payload formats, or different configurations of the same
        RTP payload format, within a single transport-layer flow (this will
        prevent RTP session (note that the use of some quality-of-service mechanisms, as discussed "m="
        lines in an <xref target="sec-differentiated"></xref>). Implementations are
        therefore also REQUIRED to support transport of all RTP packet
        streams, independent of media type, in target="RFC8843" format="default" sectionFormat="of" derivedContent="RFC8843">SDP
        BUNDLE group</xref> form a single RTP session using a
        single transport layer flow, according session).</t>
        <t indent="0" pn="section-4.3-6">An endpoint that has signaled support for multiple RTP payload
        formats <bcp14>MUST</bcp14> be able to <xref
        target="I-D.ietf-avtcore-multi-media-rtp-session"></xref> (this accept data in any of those payload formats at
        any time, unless it has previously signaled limitations on its
        decoding capability. This requirement is
        sometimes called SSRC multiplexing). If multiple 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
        be switching only between
        the RTP payload formats signaled for the type of media that is being
        sent by that source; see <xref target="sec.session-mux" format="default" sectionFormat="of" derivedContent="Section 4.4"/>. To
        support rapid rate adaptation by changing codecs, RTP does not require
        advance signaling for changes between RTP payload formats used in by a
        single SSRC that were signaled during session setup.</t>
        <t indent="0" pn="section-4.3-7">If performing changes between two RTP session, all participants in payload types that use
        different RTP session
        MUST agree to this usage. In clock rates, an SDP context, RTP sender <bcp14>MUST</bcp14> follow the
        recommendations in <xref
        target="I-D.ietf-mmusic-sdp-bundle-negotiation"></xref> can be used target="RFC7160" section="4.1" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7160#section-4.1" derivedContent="RFC7160"/>. RTP
        receivers <bcp14>MUST</bcp14> follow the recommendations in
        <xref target="RFC7160" sectionFormat="of" section="4.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7160#section-4.3" derivedContent="RFC7160"/>
        in order to
        signal such a bundle of support sources that switch
        between clock rates in an RTP packet streams forming session. These recommendations for
        receivers are backwards compatible with the case where senders use
        only a single clock rate.</t>
      </section>
      <section anchor="sec.session-mux" numbered="true" toc="include" removeInRFC="false" pn="section-4.4">
        <name slugifiedName="name-use-of-rtp-sessions">Use of RTP
        session.</t>

        <t>Further discussion about the suitability Sessions</name>
        <t indent="0" pn="section-4.4-1">An association amongst a set of different endpoints communicating using RTP
        is known as an RTP session
        structures and multiplexing methods to different scenarios <xref target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550"/>. An endpoint
        can be
        found involved in <xref
        target="I-D.ietf-avtcore-multiplex-guidelines"></xref>.</t>
      </section>

      <section anchor="sec.rtcp-mux" title="RTP and RTCP Multiplexing">
        <t>Historically, several RTP and RTCP have been run on separate transport
        layer flows (e.g., two UDP ports for sessions at the same time. In a
        multimedia session, each type of media has typically been carried in a
        separate RTP session, session (e.g., using one port for RTP and one port session for RTCP). With the increased use of Network
        Address/Port Translation (NAT/NAPT) this has become problematic, since
        maintaining multiple NAT bindings can be costly. It also complicates
        firewall administration, since multiple ports need to be opened to
        allow RTP traffic. To reduce these costs audio and a
        separate RTP session set-up times,
        implementations using a different transport-layer flow for the
        video). WebRTC endpoints are REQUIRED <bcp14>REQUIRED</bcp14> to implement support multiplexing for
        multimedia sessions in this way, separating each RTP data packets session using
        different transport-layer flows for compatibility with legacy systems
        (this is sometimes called session multiplexing).</t>
        <t indent="0" pn="section-4.4-2">In modern-day networks, however, with the widespread use of network
        address/port translators (NAT/NAPT) and RTCP control packets on a single firewalls, it is desirable to
        reduce the number of transport-layer flow <xref
        target="RFC5761"></xref>. Such flows used by RTP and RTCP multiplexing MUST applications.
        This can be
        negotiated done by sending all the RTP packet streams in a single RTP
        session, which will comprise a single transport-layer flow. This will
        prevent the signalling channel before it is used. If SDP is used
	for signalling, this negotiation MUST use the mechanism defined of some quality-of-service mechanisms, as discussed in
        <xref target="RFC5761"/>. target="sec-differentiated" format="default" sectionFormat="of" derivedContent="Section 12.1.3"/>. Implementations can are
        therefore also <bcp14>REQUIRED</bcp14> to support sending transport of all RTP and RTCP on
	separate packet
        streams, independent of media type, in a single RTP session using a
        single transport-layer flows, but this is OPTIONAL flow, according to implement. <xref target="RFC8860" format="default" sectionFormat="of" derivedContent="RFC8860"/> (this is
        sometimes called SSRC multiplexing). If
	an implementation does not support RTP and RTCP sent on separate 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="RFC8843" format="default" sectionFormat="of" derivedContent="RFC8843"/> can be used to
        signal such a bundle of RTP packet streams forming a single RTP
        session.</t>
        <t indent="0" pn="section-4.4-3">Further discussion about the suitability of different RTP session
        structures and multiplexing methods to different scenarios can be
        found in <xref target="RFC8872" format="default" sectionFormat="of" derivedContent="RFC8872"/>.</t>
      </section>
      <section anchor="sec.rtcp-mux" numbered="true" toc="include" removeInRFC="false" pn="section-4.5">
        <name slugifiedName="name-rtp-and-rtcp-multiplexing">RTP and RTCP Multiplexing</name>
        <t indent="0" pn="section-4.5-1">Historically, RTP and RTCP have been run on separate
        transport-layer flows (e.g., two UDP ports for each RTP session, one
        for RTP and one for RTCP). With the increased use of Network
        Address/Port Translation (NAT/NAPT), this has become problematic, since
        maintaining multiple NAT bindings can be costly. It also complicates
        firewall administration, since multiple ports need to be opened to
        allow RTP traffic. To reduce these costs and session setup times,
        implementations are <bcp14>REQUIRED</bcp14> to support multiplexing RTP data packets
        and RTCP control packets on a single transport-layer flow <xref target="RFC5761" format="default" sectionFormat="of" derivedContent="RFC5761"/>. Such RTP and RTCP multiplexing <bcp14>MUST</bcp14> be
        negotiated in the signaling channel before it is used. If SDP is used
        for signaling, this negotiation <bcp14>MUST</bcp14> use the mechanism defined in
        <xref target="RFC5761" format="default" sectionFormat="of" derivedContent="RFC5761"/>. Implementations can also support sending RTP and RTCP on
        separate transport-layer flows, but this is <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" sectionFormat="of" derivedContent="RFC8858"/>.
        </t>

        <t>Note
        <t indent="0" pn="section-4.5-2">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" sectionFormat="of" derivedContent="RFC6263"/>.</t>
      </section>
      <section title="Reduced numbered="true" toc="include" removeInRFC="false" pn="section-4.6">
        <name slugifiedName="name-reduced-size-rtcp">Reduced Size RTCP">
        <t>RTCP RTCP</name>
        <t indent="0" pn="section-4.6-1">RTCP packets are usually sent as compound RTCP packets, and <xref
        target="RFC3550"></xref> target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550"/> requires that those compound packets start
        with an Sender Report (SR) SR or Receiver Report (RR) RR packet. When using
        frequent RTCP feedback messages under the RTP/AVPF Profile profile <xref
        target="RFC4585"></xref> target="RFC4585" format="default" sectionFormat="of" derivedContent="RFC4585"/>, these statistics are not needed in every
        packet, and they unnecessarily increase the mean RTCP packet size. This can
        limit the frequency at which RTCP packets can be sent within the RTCP
        bandwidth share.</t>

        <t>To
        <t indent="0" pn="section-4.6-2">To avoid this problem, <xref target="RFC5506"></xref> target="RFC5506" format="default" sectionFormat="of" derivedContent="RFC5506"/> specifies how
        to reduce the mean RTCP message size and allow for more frequent
        feedback. Frequent feedback, in turn, is essential to make real-time
        applications quickly aware of changing network conditions, 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" sectionFormat="of" derivedContent="RFC5506"/>. 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" sectionFormat="of" derivedContent="RFC5506"/>. 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>
      <section title="Symmetric RTP/RTCP">
        <t>To numbered="true" toc="include" removeInRFC="false" pn="section-4.7">
        <name slugifiedName="name-symmetric-rtp-rtcp">Symmetric RTP/RTCP</name>
        <t indent="0" pn="section-4.7-1">To ease traversal of NAT and firewall devices, implementations are
        REQUIRED
        <bcp14>REQUIRED</bcp14> to implement and use <xref target="RFC4961">Symmetric target="RFC4961" format="default" sectionFormat="of" derivedContent="RFC4961">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,
        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
        unnecessary
        unnecessarily bloated. The amount of per flow per-flow QoS state kept in the
        network is also reduced.</t>
      </section>
      <section anchor="sec-ssrc"
               title="Choice numbered="true" toc="include" removeInRFC="false" pn="section-4.8">
        <name slugifiedName="name-choice-of-rtp-synchronizati">Choice of RTP Synchronisation Synchronization Source (SSRC)">
        <t>Implementations (SSRC)</name>
        <t indent="0" pn="section-4.8-1">Implementations are REQUIRED <bcp14>REQUIRED</bcp14> to support signalled signaled RTP
        synchronisation
        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 and
        Section 5 of Sections <xref target="RFC5576"></xref> target="RFC5576" sectionFormat="bare" section="4.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5576#section-4.1" derivedContent="RFC5576"/>
        and <xref target="RFC5576" sectionFormat="bare" section="5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5576#section-5" derivedContent="RFC5576"/> of <xref target="RFC5576" format="default" sectionFormat="of" derivedContent="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" derivedLink="https://rfc-editor.org/rfc/rfc5576#section-6.2" derivedContent="RFC5576"/>; other per-SSRC attributes defined in <xref
        target="RFC5576"></xref> MAY target="RFC5576" format="default" sectionFormat="of" derivedContent="RFC5576"/> <bcp14>MAY</bcp14> be supported.</t>

        <t>While
        <t indent="0" pn="section-4.8-2">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
        signalled
        signaled ahead of time. Implementations MUST <bcp14>MUST</bcp14> support random SSRC
        assignment,
        assignment and MUST <bcp14>MUST</bcp14> support SSRC collision detection and resolution,
        according to <xref target="RFC3550"></xref>. target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550"/>. 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>

        <t>It target="RFC5576" sectionFormat="of" section="5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5576#section-5" derivedContent="RFC5576"/>.</t>
        <t indent="0" pn="section-4.8-3">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" sectionFormat="of" derivedContent="Section 11"/>. 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" sectionFormat="of" derivedContent="Section 4.3"/> of this memo, the RTP
        payload types used by an RTP packet stream can be compared with values
        in SDP "a=rtpmap:" lines, which are at the media level in SDP, SDP and so
        map to an "m=" line).</t> line.</t>
      </section>
      <section anchor="sec-cname"
               title="Generation numbered="true" toc="include" removeInRFC="false" pn="section-4.9">
        <name slugifiedName="name-generation-of-the-rtcp-cano">Generation of the RTCP Canonical Name (CNAME)">
        <t>The (CNAME)</name>
        <t indent="0" pn="section-4.9-1">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" sectionFormat="of" derivedContent="W3C.WebRTC">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
        <t indent="0" pn="section-4.9-2">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
        context.</t>

        <t>Taking
        <t indent="0" pn="section-4.9-3">Taking the discussion in <xref target="sec-webrtc-api"></xref> target="sec-webrtc-api" format="default" sectionFormat="of" derivedContent="Section 11"/> 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
        MAY
        <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
        session.</t>

        <t>The
        <t indent="0" pn="section-4.9-4">The <xref target="RFC3550">RTP target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550">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" sectionFormat="of" derivedContent="Section 13">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" sectionFormat="of" derivedContent="RFC7022"/>,
        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>An
        <t indent="0" pn="section-4.9-5">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" sectionFormat="of" derivedContent="RFC3550">RTP
        specification</xref> and cannot assume that any CNAME will be chosen
        according to the form suggested above.</t>
      </section>
      <section anchor="sec-leap-sec" title="Handling numbered="true" toc="include" removeInRFC="false" pn="section-4.10">
        <name slugifiedName="name-handling-of-leap-seconds">Handling of Leap Seconds">
        <t>The Seconds</name>
        <t indent="0" pn="section-4.10-1">The guidelines given in <xref target="RFC7164" format="default" sectionFormat="of" derivedContent="RFC7164"/> 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>
    </section>
    <section anchor="sec-rtp-extn" title="WebRTC numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-webrtc-use-of-rtp-extension">WebRTC Use of RTP: Extensions">
      <t>There Extensions</name>
      <t indent="0" pn="section-5-1">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="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-conferencing-extensions-and">Conferencing Extensions and Topologies">
        <t>RTP Topologies</name>
        <t indent="0" pn="section-5.1-1">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>

        <t>While target="RFC7667" format="default" sectionFormat="of" derivedContent="RFC7667"/>.</t>
        <t indent="0" pn="section-5.1-2">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
        support
        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" sectionFormat="of" derivedContent="RFC7667"/>).
        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" sectionFormat="of" derivedContent="W3C.WebRTC">RTCPeerConnections</xref>, can be
        expected to be used in WebRTC, WebRTC and needs to be supported.</t>

        <t>WebRTC Endpoints
        <t indent="0" pn="section-5.1-3">WebRTC 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" sectionFormat="of" derivedContent="RFC7667"/> where the RTP
        endpoints send and receive unicast RTP packet streams to and from some
        peer device, provided that peer can participate in performing
        congestion control on the RTP packet streams. The peer device could be
        another RTP endpoint, or it could be an RTP middlebox that
        redistributes the RTP packet streams to other RTP endpoints. This
        limitation means that some of the RTP middlebox-based topologies are
        not suitable for use in WebRTC. Specifically: <list style="symbols">
            <t>Video switching MCUs </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1-4">
          <li pn="section-5.1-4.1">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="I-D.ietf-avtcore-rtp-topologies-update"></xref>).</t>

            <t>The target="RFC7667" section="3.8" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7667#section-3.8" derivedContent="RFC7667"/>).</li>
          <li pn="section-5.1-4.2">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>

        <t>The standardized.</li>
        </ul>
        <t indent="0" pn="section-5.1-5">The following topology can be used, however it has some issues
        worth noting:<list style="symbols">
            <t>Content modifying noting:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1-6">
          <li pn="section-5.1-6.1">Content-modifying MCUs with RTCP termination
            (Topo-RTCP-terminating-MCU) MAY <bcp14>MAY</bcp14> be used. Note that in this RTP
            Topology,
            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
            target="I-D.ietf-avtcore-rtp-topologies-update"></xref>).</t>
          </list></t>

        <t>The target="RFC7667" section="3.9" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7667#section-3.9" derivedContent="RFC7667"/>).</li>
        </ul>
        <t indent="0" pn="section-5.1-7">The RTP extensions described in Sections <xref target="sec-fir"></xref> target="sec-fir" format="counter" sectionFormat="of" derivedContent="5.1.1"/> to <xref target="sec.tmmbr"></xref> target="sec.tmmbr" format="counter" sectionFormat="of" derivedContent="5.1.6"/> are designed to be used with
        centralised
        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
        Endpoints.</t>

        <t>The
        endpoints.</t>
        <t indent="0" pn="section-5.1-8">The RTCP conferencing extensions are defined in <xref
        target="RFC4585">Extended target="RFC4585" format="default" sectionFormat="of" derivedContent="RFC4585">"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" sectionFormat="of" derivedContent="RFC5104">"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" sectionFormat="of" derivedContent="RFC5124"> secure variant of this
        profile (RTP/SAVPF)</xref>.</t>
        <section anchor="sec-fir" title="Full numbered="true" toc="include" removeInRFC="false" pn="section-5.1.1">
          <name slugifiedName="name-full-intra-request-fir">Full Intra Request (FIR)">
          <t>The (FIR)</name>
          <t indent="0" pn="section-5.1.1-1">The Full Intra Request message is defined in Sections 3.5.1 and
          4.3.1 of the <xref target="RFC5104">Codec target="RFC5104" section="3.5.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5104#section-3.5.1" derivedContent="RFC5104"/> and
          <xref target="RFC5104" section="4.3.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5104#section-4.3.1" derivedContent="RFC5104"/> of <xref target="RFC5104" format="default" sectionFormat="of" derivedContent="RFC5104">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
          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>
        <section title="Picture numbered="true" toc="include" removeInRFC="false" pn="section-5.1.2">
          <name slugifiedName="name-picture-loss-indication-pli">Picture Loss Indication (PLI)">
          <t>The (PLI)</name>
          <t indent="0" pn="section-5.1.2-1">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" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4585#section-6.3.1" derivedContent="RFC4585">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>
        <section title="Slice numbered="true" toc="include" removeInRFC="false" pn="section-5.1.3">
          <name slugifiedName="name-slice-loss-indication-sli">Slice Loss Indication (SLI)">
          <t>The (SLI)</name>
          <t indent="0" pn="section-5.1.3-1">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" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4585#section-6.3.2" derivedContent="RFC4585">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>
        <section title="Reference numbered="true" toc="include" removeInRFC="false" pn="section-5.1.4">
          <name slugifiedName="name-reference-picture-selection">Reference Picture Selection Indication (RPSI)">
          <t>Reference (RPSI)</name>
          <t indent="0" pn="section-5.1.4-1">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" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4585#section-6.3.3" derivedContent="RFC4585">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
          correct
          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
          picture
          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,
          constraints and with the codec being used.</t>
        </section>
        <section title="Temporal-Spatial Trade-off numbered="true" toc="include" removeInRFC="false" pn="section-5.1.5">
          <name slugifiedName="name-temporal-spatial-trade-off-">Temporal-Spatial Trade-Off Request (TSTR)">
          <t>The (TSTR)</name>
          <t indent="0" pn="section-5.1.5-1">The temporal-spatial trade-off request and notification are
          defined in Sections 3.5.2 and 4.3.2 of <xref
          target="RFC5104"></xref>. target="RFC5104" section="3.5.2" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5104#section-3.5.2" derivedContent="RFC5104"/> and <xref target="RFC5104" section="4.3.2" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5104#section-4.3.2" derivedContent="RFC5104"/> of <xref target="RFC5104" format="default" sectionFormat="of" derivedContent="RFC5104"/>. 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
          OPTIONAL.</t>
          <bcp14>OPTIONAL</bcp14>.</t>
        </section>
        <section anchor="sec.tmmbr"
                 title="Temporary numbered="true" toc="include" removeInRFC="false" pn="section-5.1.6">
          <name slugifiedName="name-temporary-maximum-media-str">Temporary Maximum Media Stream Bit Rate Request (TMMBR)">
          <t>The TMMBR (TMMBR)</name>
          <t indent="0" pn="section-5.1.6-1">The Temporary Maximum Media Stream Bit Rate Request (TMMBR) feedback message is defined in Sections 3.5.4 and 4.2.1
          of the <xref target="RFC5104">Codec target="RFC5104" section="3.5.4" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5104#section-3.5.4" derivedContent="RFC5104"/> and <xref target="RFC5104" section="4.2.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5104#section-4.2.1" derivedContent="RFC5104"/>
          of <xref target="RFC5104" format="default" sectionFormat="of" derivedContent="RFC5104">Codec Control Messages</xref>. This
          request and its notification corresponding Temporary Maximum Media Stream Bit
          Rate Notification (TMMBN) message <xref target="RFC5104" format="default" sectionFormat="of" derivedContent="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
          OPTIONAL.</t>
          <bcp14>OPTIONAL</bcp14>.</t>
        </section>
      </section>
      <section title="Header Extensions">
        <t>The numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-header-extensions">Header Extensions</name>
        <t indent="0" pn="section-5.2-1">The <xref target="RFC3550">RTP target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550">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" sectionFormat="of" derivedContent="RFC8285"/>, since this gives well-defined semantics to
        RTP header extensions.</t>

        <t>As
        <t indent="0" pn="section-5.2-2">As noted in <xref target="RFC5285"></xref>, target="RFC8285" format="default" sectionFormat="of" derivedContent="RFC8285"/>, 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" sectionFormat="of" derivedContent="RFC3550"/>
        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,
        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,
        information but that can safely be ignored without compromising
        interoperability.</t>
        <section anchor="rapid-sync" title="Rapid Synchronisation">
          <t>Many numbered="true" toc="include" removeInRFC="false" pn="section-5.2.1">
          <name slugifiedName="name-rapid-synchronization">Rapid Synchronization</name>
          <t indent="0" pn="section-5.2.1-1">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" sectionFormat="of" derivedContent="RFC3550">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" sectionFormat="of" derivedContent="RFC6051"/> be implemented in addition to RTCP SR-based
          synchronisation.</t>

          <t>This
          synchronization.</t>
          <t indent="0" pn="section-5.2.1-2">This header extension uses the <xref target="RFC5285"></xref>
          generic header extension framework, framework described in <xref target="RFC8285" format="default" sectionFormat="of" derivedContent="RFC8285"/> and so needs to be negotiated
          before it can be used.</t>
        </section>
        <section anchor="sec-client-to-mixer"
                 title="Client-to-Mixer numbered="true" toc="include" removeInRFC="false" pn="section-5.2.2">
          <name slugifiedName="name-client-to-mixer-audio-level">Client-to-Mixer Audio Level">
          <t>The Level</name>
          <t indent="0" pn="section-5.2.2-1">The <xref target="RFC6464">Client to Mixer Audio Level target="RFC6464" format="default" sectionFormat="of" derivedContent="RFC6464">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
          <t indent="0" pn="section-5.2.2-2">The <xref target="RFC6464">Client-to-Mixer Audio Level</xref> target="RFC6464" format="default" sectionFormat="of" derivedContent="RFC6464">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" sectionFormat="of" derivedContent="RFC6904"/>, 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>

          <t>This signaling.</t>
          <t indent="0" pn="section-5.2.2-3">This header extension uses the <xref target="RFC5285"></xref>
          generic header extension framework, framework described in <xref target="RFC8285" format="default" sectionFormat="of" derivedContent="RFC8285"/> and so needs to be negotiated
          before it can be used.</t>
        </section>
        <section anchor="sec-mixer-to-client"
                 title="Mixer-to-Client numbered="true" toc="include" removeInRFC="false" pn="section-5.2.3">
          <name slugifiedName="name-mixer-to-client-audio-level">Mixer-to-Client Audio Level">
          <t>The Level</name>
          <t indent="0" pn="section-5.2.3-1">The <xref target="RFC6465">Mixer to Client Audio Level target="RFC6465" format="default" sectionFormat="of" derivedContent="RFC6465">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
          are
          be capable of encrypting the header extension according to <xref
          target="RFC6904"></xref> target="RFC6904" format="default" sectionFormat="of" derivedContent="RFC6904"/>, since the information contained in these
          header extensions can be considered sensitive. It is further
          RECOMMENDED
          <bcp14>RECOMMENDED</bcp14> that this encryption is be used, unless the encryption has
          been explicitly disabled through API or signalling.</t>

          <t>This signaling.</t>
          <t indent="0" pn="section-5.2.3-2">This header extension uses the <xref target="RFC5285"></xref>
          generic header extension framework, framework described in <xref target="RFC8285" format="default" sectionFormat="of" derivedContent="RFC8285"/> and so needs to be negotiated
          before it can be used.</t>
        </section>
        <section anchor="sec-mid" title="Media numbered="true" toc="include" removeInRFC="false" pn="section-5.2.4">
          <name slugifiedName="name-media-stream-identification">Media Stream Identification">
          <t>WebRTC Identification</name>
          <t indent="0" pn="section-5.2.4-1">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>

          <t>This target="RFC8843" format="default" sectionFormat="of" derivedContent="RFC8843"/>.</t>
          <t indent="0" pn="section-5.2.4-2">This header extension uses the <xref target="RFC5285"></xref>
          generic header extension framework, framework described in <xref target="RFC8285" format="default" sectionFormat="of" derivedContent="RFC8285"/> and so needs to be negotiated
          before it can be used.</t>
        </section>
        <section anchor="sec-cvo" title="Coordination numbered="true" toc="include" removeInRFC="false" pn="section-5.2.5">
          <name slugifiedName="name-coordination-of-video-orien">Coordination of Video Orientation">
          <t>WebRTC Orientation</name>
          <t indent="0" pn="section-5.2.5-1">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>

          <t>This target="RFC7742" section="4" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7742#section-4" derivedContent="RFC7742"/>.</t>
          <t indent="0" pn="section-5.2.5-2">This header extension uses the <xref target="RFC5285"></xref>
          generic header extension framework, framework described in <xref target="RFC8285" format="default" sectionFormat="of" derivedContent="RFC8285"/> and so needs to be negotiated
          before it can be used.</t>
        </section>
      </section>
    </section>
    <section anchor="sec-rtp-robust"
             title="WebRTC numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-webrtc-use-of-rtp-improving">WebRTC Use of RTP: Improving Transport Robustness">
      <t>There Robustness</name>
      <t indent="0" pn="section-6-1">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" sectionFormat="of" derivedContent="Section 7"/>). 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
      loss.</t>
      <section anchor="sec-rtx"
               title="Negative numbered="true" toc="include" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-negative-acknowledgements-a">Negative Acknowledgements and RTP Retransmission">
        <t>As Retransmission</name>
        <t indent="0" pn="section-6.1-1">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" sectionFormat="of" derivedContent="RFC4585"/>. This feedback can be used
        to inform a sender of the loss of particular RTP packets, subject to
        the capacity limitations of the RTCP feedback channel. A sender can
        use this information to optimise optimize the user experience by adapting the
        media encoding to compensate for known lost packets.</t>

        <t>RTP
        <t indent="0" pn="section-6.1-2">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" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4585#section-6.2.1" derivedContent="RFC4585"/>, 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" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4585#section-4.2" derivedContent="RFC4585"/>).
        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" sectionFormat="of" derivedContent="RFC4585"/>. 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
        <t indent="0" pn="section-6.1-3">The <xref target="RFC4588">RTP Retransmission Payload Format</xref> target="RFC4588" format="default" sectionFormat="of" derivedContent="RFC4588">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" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3550#section-6.4.1" derivedContent="RFC3550"/>). 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
        <t indent="0" pn="section-6.1-4">Receivers are REQUIRED <bcp14>REQUIRED</bcp14> to implement support for RTP retransmission
        packets <xref target="RFC4588"></xref> target="RFC4588" format="default" sectionFormat="of" derivedContent="RFC4588"/> 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,
        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>
      <section anchor="sec-FEC" title="Forward numbered="true" toc="include" removeInRFC="false" pn="section-6.2">
        <name slugifiedName="name-forward-error-correction-fe">Forward Error Correction (FEC)">
        <t>The (FEC)</name>
        <t indent="0" pn="section-6.2-1">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
        <t indent="0" pn="section-6.2-2">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" sectionFormat="of" derivedContent="RFC8854"/>. 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>
    </section>
    <section anchor="sec-rate-control"
             title="WebRTC numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-webrtc-use-of-rtp-rate-cont">WebRTC Use of RTP: Rate Control and Media Adaptation">
      <t>WebRTC Adaptation</name>
      <t indent="0" pn="section-7-1">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
      <t indent="0" pn="section-7-2">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
      <t indent="0" pn="section-7-3">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" sectionFormat="of" derivedContent="RFC8836"/>.
      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="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-boundary-conditions-and-cir">Boundary Conditions and Circuit Breakers">
        <t>WebRTC Endpoints MUST Breakers</name>
        <t indent="0" pn="section-7.1-1">WebRTC 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" sectionFormat="of" derivedContent="RFC8083"/>. 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
        <t indent="0" pn="section-7.1-2">The 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
        signalling
        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" sectionFormat="of" derivedContent="Section 5.1.6"/> 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
        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>
      <section title="Congestion numbered="true" toc="include" removeInRFC="false" pn="section-7.2">
        <name slugifiedName="name-congestion-control-interope">Congestion Control Interoperability and Legacy Systems">
        <t>All Systems</name>
        <t indent="0" pn="section-7.2-1">All endpoints that wish to interwork with WebRTC MUST <bcp14>MUST</bcp14> implement
        RTCP and provide congestion feedback via the defined RTCP reporting
        mechanisms.</t>

        <t>When
        <t indent="0" pn="section-7.2-2">When interworking with legacy implementations that support RTCP
        using the <xref target="RFC3551">RTP/AVP target="RFC3551" format="default" sectionFormat="of" derivedContent="RFC3551">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" sectionFormat="of" derivedContent="RFC8083">RTP
        circuit breaker</xref> constraints to limit the
        congestion they can cause.</t>

        <t>If
        <t indent="0" pn="section-7.2-3">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" sectionFormat="of" derivedContent="RFC5104"> 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" sectionFormat="of" derivedContent="RFC8083"> 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
        <t indent="0" pn="section-7.2-4">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>
    </section>
    <section anchor="sec-perf"
             title="WebRTC numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-webrtc-use-of-rtp-performan">WebRTC Use of RTP: Performance Monitoring">
      <t>As Monitoring</name>
      <t indent="0" pn="section-8-1">As described in <xref target="sec-rtp-rtcp"></xref>, target="sec-rtp-rtcp" format="default" sectionFormat="of" derivedContent="Section 4.1"/>, implementations
      are REQUIRED <bcp14>REQUIRED</bcp14> to generate RTCP Sender Report (SR) and Reception Receiver Report
      (RR) packets relating to the RTP packet streams they send and receive.
      These RTCP reports can be used for performance monitoring purposes,
      since they include basic packet loss packet-loss and jitter statistics.</t>

      <t>A
      <t indent="0" pn="section-8-2">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" sectionFormat="of" derivedContent="RFC3611"/> and <xref target="RFC6792" format="default" sectionFormat="of" derivedContent="RFC6792"/>. At the time of
      this writing, it is not clear what extended metrics are suitable for use
      in WebRTC, so there is no requirement that implementations generate RTCP
      XR packets. However, implementations that can use detailed performance
      monitoring data MAY <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>
    <section anchor="sec-extn" title="WebRTC numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-webrtc-use-of-rtp-future-ex">WebRTC Use of RTP: Future Extensions">
      <t>It Extensions</name>
      <t indent="0" pn="section-9-1">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" sectionFormat="of" derivedContent="RFC2736">"Guidelines for Writers of RTP
      Payload Format Specifications </xref>, Specifications"</xref>, <xref
      target="I-D.ietf-payload-rtp-howto">How target="RFC8088" format="default" sectionFormat="of" derivedContent="RFC8088">"How to Write an RTP Payload
      Format</xref>
      Format"</xref>, and <xref target="RFC5968"> Guidelines target="RFC5968" format="default" sectionFormat="of" derivedContent="RFC5968">"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
      developed.</t>

      <t>Authors
      <t indent="0" pn="section-9-2">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>
    <section anchor="sec-signalling" title="Signalling Considerations">
      <t>RTP numbered="true" toc="include" removeInRFC="false" pn="section-10">
      <name slugifiedName="name-signaling-considerations">Signaling Considerations</name>
      <t indent="0" pn="section-10-1">RTP is built with the assumption that an external signalling signaling channel
      exists,
      exists and can be used to configure RTP sessions and their features.
      The basic configuration of an RTP session consists of the following
      parameters:</t>

      <t><list style="hanging">
          <t hangText="RTP Profile:">The
      <dl newline="false" spacing="normal" indent="3" pn="section-10-2">
        <dt pn="section-10-2.1">RTP profile:</dt>
        <dd pn="section-10-2.2">The name of the RTP profile to be used in the
          session. The <xref target="RFC3551">RTP/AVP</xref> target="RFC3551" format="default" sectionFormat="of" derivedContent="RFC3551">RTP/AVP</xref> and <xref
          target="RFC4585">RTP/AVPF</xref> target="RFC4585" format="default" sectionFormat="of" derivedContent="RFC4585">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" sectionFormat="of" derivedContent="RFC3711">RTP/SAVP</xref> and <xref
          target="RFC5124">RTP/SAVPF</xref>. target="RFC5124" format="default" sectionFormat="of" derivedContent="RFC5124">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
          signalled.
          signaled. Interworking functions might transform this into the
          RTP/SAVP profile for a legacy use case, case by indicating to the WebRTC
          Endpoint
          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 pn="section-10-2.3">Transport information:</dt>
        <dd pn="section-10-2.4">Source and destination IP
          address(s)
          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" sectionFormat="of" derivedContent="RFC8445">Interactive Connectivity Establishment
          (ICE)</xref> that signals candidates and
          arrives at nominated candidate address pairs. If <xref
          target="RFC5761">RTP target="RFC5761" format="default" sectionFormat="of" derivedContent="RFC5761">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
          target="sec.rtcp-mux"></xref>).</t>

          <t
          hangText="RTP Payload Types, target="sec.rtcp-mux" format="default" sectionFormat="of" derivedContent="Section 4.5"/>).</dd>
        <dt pn="section-10-2.5">RTP payload types, media formats, and format parameters:">The parameters:</dt>
        <dd pn="section-10-2.6">The
          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
          MUST
          <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" sectionFormat="of" derivedContent="Section 4.3"/> of
          this memo discusses requirements for uniqueness of payload
          types.</t>

          <t hangText="RTP Extensions:">The
          types.</dd>
        <dt pn="section-10-2.7">RTP extensions:</dt>
        <dd pn="section-10-2.8">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
          target="sec-rtp-rtcp"></xref>).</t>

          <t hangText="RTCP Bandwidth:">Support target="sec-rtp-rtcp" format="default" sectionFormat="of" derivedContent="Section 4.1"/>).</dd>
        <dt pn="section-10-2.9">RTCP bandwidth:</dt>
        <dd pn="section-10-2.10">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" sectionFormat="of" derivedContent="RFC3556">"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
          problems.</t>
        </list></t>

      <t>These
          problems.</dd>
      </dl>
      <t indent="0" pn="section-10-3">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>
    <section anchor="sec-webrtc-api" title="WebRTC numbered="true" toc="include" removeInRFC="false" pn="section-11">
      <name slugifiedName="name-webrtc-api-considerations">WebRTC API Considerations">
      <t>The Considerations</name>
      <t indent="0" pn="section-11-1">The <xref target="W3C.WD-webrtc-20130910">WebRTC target="W3C.WebRTC" format="default" sectionFormat="of" derivedContent="W3C.WebRTC">WebRTC API</xref> and the
      <xref target="W3C.WD-mediacapture-streams-20130903">Media target="W3C.WD-mediacapture-streams" format="default" sectionFormat="of" derivedContent="W3C.WD-mediacapture-streams">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>

      <t>A playback.</t>
      <t indent="0" pn="section-11-2">A MediaStreamTrack's realisation realization in RTP RTP, in the context of an
      RTCPeerConnection
      RTCPeerConnection, consists of a source packet stream stream, identified with by an
      SSRC
      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" sectionFormat="of" derivedContent="Section 6.2">Forward Error Correction</xref> or <xref
      target="sec-rtx">RTP target="sec-rtx" format="default" sectionFormat="of" derivedContent="Section 6.1">RTP retransmission</xref> to the source packet
      stream.</t>

      <t>It
      <t indent="0" pn="section-11-3">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
      needed.</t>

      <t>The
      <t indent="0" pn="section-11-4">The same MediaStreamTrack can also be included in multiple
      MediaStreams, thus
      MediaStreams; thus, multiple sets of MediaStreams can implicitly need to
      use the same synchronisation synchronization base. To ensure that this works in all
      cases,
      cases and does not force an endpoint to disrupt the media by changing
      synchronisation
      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" sectionFormat="of" derivedContent="Section 4.9"/>. </t>
      <aside pn="section-11-5">
        <t indent="0" pn="section-11-5.1">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
          CNAME.</t>
        </list></t>

      <t>Different
      </aside>
      <t indent="0" pn="section-11-6">Different CNAMEs normally need to be used for different
      RTCPeerConnection instances, as specified in <xref
      target="sec-cname"></xref>. target="sec-cname" format="default" sectionFormat="of" derivedContent="Section 4.9"/>. Having two communication sessions with the
      same CNAME could enable tracking of a user or device across different
      services (see Section 4.4.1 of <xref
      target="I-D.ietf-rtcweb-security"></xref> target="RFC8826" section="4.4.1" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8826#section-4.4.1" derivedContent="RFC8826"/> 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 pn="section-11-7">
        <t indent="0" pn="section-11-7.1">Note: This doesn't result in a tracking issue, since the creation
          of matching CNAMEs depends on existing tracking within a single
          origin.</t>
        </list>The
      </aside>
      <t indent="0" pn="section-11-8">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
      synchronisation.
      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
      <t indent="0" pn="section-11-9">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 pn="section-11-10">
        <t indent="0" pn="section-11-10.1">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
          WebRTC.</t>
        </list></t>

      <t><xref target="I-D.ietf-rtcweb-jsep">Javascript
      </aside>
      <t indent="0" pn="section-11-11"><xref target="RFC8829" format="default" sectionFormat="of" derivedContent="RFC8829">"JavaScript Session Establishment
      Protocol</xref>
      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" sectionFormat="of" derivedContent="RFC8830">"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" sectionFormat="of" derivedContent="RFC8830">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
      <t indent="0" pn="section-11-12">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" sectionFormat="of" derivedContent="Section 4.1">CSRC
      list</xref> as well as the <xref
      target="sec-mixer-to-client">Mixer-to-Client target="sec-mixer-to-client" format="default" sectionFormat="of" derivedContent="Section 5.2.3">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" sectionFormat="of" derivedContent="Section 12.2.1"/>.</t>
    </section>
    <section anchor="sec-rtp-func" title="RTP numbered="true" toc="include" removeInRFC="false" pn="section-12">
      <name slugifiedName="name-rtp-implementation-consider">RTP Implementation Considerations">
      <t>The Considerations</name>
      <t indent="0" pn="section-12-1">The following discussion provides some guidance on the implementation
      of the RTP features described in this memo. The focus is on a WebRTC
      Endpoint
      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="include" removeInRFC="false" pn="section-12.1">
        <name slugifiedName="name-configuration-and-use-of-rt">Configuration and Use of RTP Sessions">
        <t>A Sessions</name>
        <t indent="0" pn="section-12.1-1">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
        can
        include media data from multiple endpoints. In the following, some
        ways in which WebRTC Endpoints endpoints can configure and use RTP sessions are
        outlined.</t>
        <section anchor="sec.multiple-flows"
                 title="Use numbered="true" toc="include" removeInRFC="false" pn="section-12.1.1">
          <name slugifiedName="name-use-of-multiple-media-sourc">Use of Multiple Media Sources Within within an RTP Session">
          <t>RTP Session</name>
          <t indent="0" pn="section-12.1.1-1">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>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-12.1.1-2">
            <li pn="section-12.1.1-2.1">
              <t hangText="Multiple indent="0" pn="section-12.1.1-2.1.1">Multiple media types:">Outside types:</t>
              <t indent="0" pn="section-12.1.1-2.1.2">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" sectionFormat="of" derivedContent="Section 4.4"/>, using RTP
              and RTCP multiplexing (<xref target="sec.rtcp-mux"></xref>) target="sec.rtcp-mux" format="default" sectionFormat="of" derivedContent="Section 4.5"/>) 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>
            </li>
            <li pn="section-12.1.1-2.2">
              <t hangText="Multiple Capture Devices:">A indent="0" pn="section-12.1.1-2.2.1">Multiple capture devices:</t>
              <t indent="0" pn="section-12.1.1-2.2.2">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>
            </li>
            <li pn="section-12.1.1-2.3">
              <t indent="0" pn="section-12.1.1-2.3.1">Associated repair data:</t>
              <t hangText="Associated Repair Data:">An indent="0" pn="section-12.1.1-2.3.2">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>
            </li>
            <li pn="section-12.1.1-2.4">
              <t hangText="Layered indent="0" pn="section-12.1.1-2.4.1">Layered or Multiple Description Coding:">An multiple-description coding:</t>
              <t indent="0" pn="section-12.1.1-2.4.2">Within a single
              RTP session, an endpoint can use a layered media codec, codec -- for example
              example, H.264 SVC, Scalable Video Coding (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> SSRC.</t>
            </li>
            <li pn="section-12.1.1-2.5">
              <t hangText="RTP Mixers, Translators, indent="0" pn="section-12.1.1-2.5.1">RTP mixers, translators, and Other Middleboxes:">An other middleboxes:</t>
              <t indent="0" pn="section-12.1.1-2.5.2">An
              RTP session, in the WebRTC context, is a point-to-point
              association between an endpoint and some other peer device,
              where those devices share a common SSRC space. The peer device
              might be another WebRTC Endpoint, 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>
            </list></t>
            </li>
          </ul>
        </section>
        <section anchor="sec.multiple-sessions"
                 title="Use numbered="true" toc="include" removeInRFC="false" pn="section-12.1.2">
          <name slugifiedName="name-use-of-multiple-rtp-session">Use of Multiple RTP Sessions">
          <t>In Sessions</name>
          <t indent="0" pn="section-12.1.2-1">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
          endpoint might choose to do this: <list style="hanging"> </t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-12.1.2-2">
            <li pn="section-12.1.2-2.1">
              <t hangText="To indent="0" pn="section-12.1.2-2.1.1">To interoperate with legacy devices:">The devices:</t>
              <t indent="0" pn="section-12.1.2-2.1.2">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
              target="sec.session-mux"></xref>.</t> target="sec.session-mux" format="default" sectionFormat="of" derivedContent="Section 4.4"/>.</t>
            </li>
            <li pn="section-12.1.2-2.2">
              <t hangText="To indent="0" pn="section-12.1.2-2.2.1">To provide enhanced quality of service:">Some service:</t>
              <t indent="0" pn="section-12.1.2-2.2.2">Some
              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
              target="sec-differentiated"></xref>.</t> target="sec-differentiated" format="default" sectionFormat="of" derivedContent="Section 12.1.3"/>.</t>
            </li>
            <li pn="section-12.1.2-2.3">
              <t hangText="To indent="0" pn="section-12.1.2-2.3.1">To separate media with different purposes:">An purposes:</t>
              <t indent="0" pn="section-12.1.2-2.3.2">An
              endpoint might want to send RTP packet streams that have
              different purposes on different RTP sessions, to make it easy
              for the peer device to distinguish them. For example, some
              centralised
              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
              bit-rate,
              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>
            </li>
            <li pn="section-12.1.2-2.4">
              <t hangText="To indent="0" pn="section-12.1.2-2.4.1">To directly connect with multiple peers:">A
              multi-party peers:</t>
              <t indent="0" pn="section-12.1.2-2.4.2">A
              multiparty conference does not need to use an RTP middlebox.
              Rather, a multi-unicast mesh can be created, comprising several
              distinct RTP sessions, with each participant sending RTP traffic
              over a separate RTP session (that is, using an independent
              RTCPeerConnection object) to every other participant, as shown
              in <xref target="fig-mesh"></xref>. target="fig-mesh" format="default" sectionFormat="of" derivedContent="Figure 1"/>. This topology has the
              benefit of not requiring an RTP middlebox node that is trusted
              to access and manipulate the media data. The downside is that it
              increases the used bandwidth at each sender by requiring one
              copy of the RTP packet streams for each participant that are is
              part of the same session beyond the sender itself.</t>
            </list></t>
              <figure align="center" anchor="fig-mesh"
                  title="Multi-unicast using several align="left" suppress-title="false" pn="figure-1">
                <name slugifiedName="name-multi-unicast-using-several">Multi-unicast Using Several RTP sessions">
            <artwork><![CDATA[ Sessions</name>
                <artwork name="" type="" align="left" alt="" pn="section-12.1.2-2.4.3.1">

+---+     +---+
| A |<--->| |&lt;---&gt;| B |
+---+     +---+
  ^         ^
   \       /
    \     /
     v   v
     +---+
     | C |
     +---+

            ]]></artwork> </artwork>
              </figure>

          <t><list style="hanging">
              <t>The
              <t indent="0" pn="section-12.1.2-2.4.4">The multi-unicast topology could also be implemented as a
              single RTP session, spanning multiple peer-to-peer transport
              layer
              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
              objects, it is recommend <bcp14>RECOMMENDED</bcp14> 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
              power.</t>
            </li>
            <li pn="section-12.1.2-2.5">
              <t hangText="To indent="0" pn="section-12.1.2-2.5.1">To indirectly connect with multiple peers:">A peers:</t>
              <t indent="0" pn="section-12.1.2-2.5.2">A
              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" sectionFormat="of" derivedContent="Figure 2"/> 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>
            </list></t>
              <figure align="center" anchor="fig-mixerFirst"
                  title="RTP mixer align="left" suppress-title="false" pn="figure-2">
                <name slugifiedName="name-rtp-mixer-with-only-unicast">RTP Mixer with only unicast paths">
            <artwork><![CDATA[ Only Unicast Paths</name>
                <artwork name="" type="" align="left" alt="" pn="section-12.1.2-2.5.3.1">

+---+      +-------------+      +---+
| A |<---->|             |<---->| |&lt;----&gt;|             |&lt;----&gt;| B |
+---+      | RTP mixer,  |      +---+
           | translator, |
           | or other    |
+---+      | middlebox   |      +---+
| C |<---->|             |<---->| |&lt;----&gt;|             |&lt;----&gt;| D |
+---+      +-------------+      +---+

            ]]></artwork> </artwork>
              </figure>

          <t><list style="hanging">
              <t>There
              <t indent="0" pn="section-12.1.2-2.5.4">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,
              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 indent="0" pn="section-12.1.2-2.5.5">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
              <t indent="0" pn="section-12.1.2-2.5.6">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" sectionFormat="of" derivedContent="RFC4383"> Timed Efficient Stream Loss-Tolerant
              Authentication (TESLA) for SRTP</xref>, SRTP</xref> -- that are not part
              of the base WebRTC standards.</t>
            </li>
            <li pn="section-12.1.2-2.6">
              <t hangText="To indent="0" pn="section-12.1.2-2.6.1">To forward media between multiple peers:">It peers:</t>
              <t indent="0" pn="section-12.1.2-2.6.2">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
              stream.</t>

              <t>At
              <t indent="0" pn="section-12.1.2-2.6.3">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
              forwarding.</t>

              <t>The
              <t indent="0" pn="section-12.1.2-2.6.4">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,
              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>
            </list></t>
            </li>
          </ul>
        </section>
        <section anchor="sec-differentiated"
                 title="Differentiated numbered="true" toc="include" removeInRFC="false" pn="section-12.1.3">
          <name slugifiedName="name-differentiated-treatment-of">Differentiated Treatment of RTP Streams">
          <t>There Streams</name>
          <t indent="0" pn="section-12.1.3-1">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
          that
          will be sent, sent and their allocation of bit-rate bitrate out of the
          current available aggregate aggregate, as determined by the congestion
          control.</t>

          <t>It
          <t indent="0" pn="section-12.1.3-2">It is expected that the <xref
          target="W3C.WD-webrtc-20130910">WebRTC target="W3C.WebRTC" format="default" sectionFormat="of" derivedContent="W3C.WebRTC">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,
          <t indent="0" pn="section-12.1.3-3">Secondly, the network can prioritize transport-layer flows and
          sub-flows,
          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
              style="hanging">
              <t hangText="DiffServ:">The </t>
          <dl indent="3" newline="false" spacing="normal" pn="section-12.1.3-4">
            <dt pn="section-12.1.3-4.1">DiffServ:</dt>
            <dd pn="section-12.1.3-4.2">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 pn="section-12.1.3-4.3">Flow based:</dt>
            <dd pn="section-12.1.3-4.4">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 pn="section-12.1.3-4.5">Deep packet inspection:</dt>
            <dd pn="section-12.1.3-4.6">A network classifier (DPI)
              inspects the packet and tries to determine if the packet
              represents a particular application and type that is to be
              prioritized.</t>
            </list></t>

          <t>Flow-based
              prioritized.</dd>
          </dl>
          <t indent="0" pn="section-12.1.3-5">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
          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
          <t indent="0" pn="section-12.1.3-6">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
          traffic, two requirements arise in the WebRTC context: 1) The WebRTC
          Endpoint
          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" sectionFormat="of" derivedContent="RFC8837">"Differentiated Services Code Point (DSCP) Packet
	  Markings for RTCWeb WebRTC QoS"</xref>.</t>

          <t>Deep Packet Inspectors will, despite
          <t indent="0" pn="section-12.1.3-7">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
          increments, and sequence numbers, fairly reliable classifications are
          achieved.</t>

          <t>For packet based
          <t indent="0" pn="section-12.1.3-8">For 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" sectionFormat="of" derivedContent="RFC8837"/> and <xref
          target="I-D.ietf-dart-dscp-rtp"></xref> target="RFC7657" format="default" sectionFormat="of" derivedContent="RFC7657"/> 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
          <t indent="0" pn="section-12.1.3-9">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>
      </section>
      <section title="Media numbered="true" toc="include" removeInRFC="false" pn="section-12.2">
        <name slugifiedName="name-media-source-rtp-streams-an">Media Source, RTP Streams, and Participant Identification"> Identification</name>
        <section anchor="sec-media-stream-id"
                 title="Media numbered="true" toc="include" removeInRFC="false" pn="section-12.2.1">
          <name slugifiedName="name-media-source-identification">Media Source Identification">
          <t>Each Identification</name>
          <t indent="0" pn="section-12.2.1-1">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" sectionFormat="of" derivedContent="Section 4.8"/>. 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
          <t indent="0" pn="section-12.2.1-2">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" sectionFormat="of" derivedContent="Section 4.1"/>,
          implementations need to support reception of RTP data packets
          containing a CSRC list and RTCP packets that relate to sources
          present in the CSRC list. The CSRC list can change on a
          packet-by-packet basis, depending on the mixing operation being
          performed. Knowledge of what media sources contributed to a
          particular RTP packet can be important if the user interface
          indicates which participants are active in the session. Changes in
          the CSRC list included in packets 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
          applications.</t>

          <t>If
          <t indent="0" pn="section-12.2.1-3">If the mixer-to-client audio level extension <xref
          target="RFC6465"></xref> target="RFC6465" format="default" sectionFormat="of" derivedContent="RFC6465"/> is being used in the session (see <xref
          target="sec-mixer-to-client"></xref>), target="sec-mixer-to-client" format="default" sectionFormat="of" derivedContent="Section 5.2.3"/>), 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
          interface.</t>
        </section>
        <section title="SSRC numbered="true" toc="include" removeInRFC="false" pn="section-12.2.2">
          <name slugifiedName="name-ssrc-collision-detection">SSRC Collision Detection">
          <t>The Detection</name>
          <t indent="0" pn="section-12.2.2-1">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" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3550#section-8.2" derivedContent="RFC3550"/>). 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" bare="false" empty="false" indent="3" pn="section-12.2.2-2">
            <li pn="section-12.2.2-2.1">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" sectionFormat="of" derivedContent="RFC5576">source-specific SDP
              Attributes</xref>.
              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" sectionFormat="of" derivedContent="RFC5576">"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 pn="section-12.2.2-2.2">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
              to
              from the SSRC of the source RTP packet stream <xref
              target="RFC4588"></xref>. target="RFC4588" format="default" sectionFormat="of" derivedContent="RFC4588"/>. In those cases, an endpoint can create
              a new SSRC that strictly doesn't need to be announced over the
              signalling
              signaling channel to function correctly on both RTP and
              RTCPeerConnection level.</t>

              <t>Multiple level.</li>
            <li pn="section-12.2.2-2.3">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 pn="section-12.2.2-2.4">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
              input.</t>
            </list></t>

          <t>These
              input.</li>
          </ul>
          <t indent="0" pn="section-12.2.2-3">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>
        <section title="Media Synchronisation Context">
          <t>When numbered="true" toc="include" removeInRFC="false" pn="section-12.2.3">
          <name slugifiedName="name-media-synchronization-conte">Media Synchronization Context</name>
          <t indent="0" pn="section-12.2.3-1">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 streams be indicated as coming from the same
          synchronization context and logical endpoint by using the same RTCP
          CNAME identifier.</t>
          <t indent="0" pn="section-12.2.3-2">The next provision is that the internal clocks of all media
          sources -- i.e., what drives the RTP timestamp -- can be correlated to a
          system clock that is provided in RTCP Sender Reports encoded in an
          NTP format. By correlating all RTP timestamps to a common system
          clock for all sources, the timing relation of the different RTP
          packet streams, also across multiple RTP sessions, can be derived at
          the receiver and, if desired, the streams can be synchronized.
 The requirement is for the media sender to provide the correlation
          information; whether or not the information is used is up to the receiver.</t>
        </section>
      </section>
    </section>
    <section anchor="sec-security" numbered="true" toc="include" removeInRFC="false" pn="section-13">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-13-1">The overall security architecture for WebRTC is described in <xref target="RFC8827" format="default" sectionFormat="of" derivedContent="RFC8827"/>, and security
      considerations for the WebRTC framework are described in <xref target="RFC8826" format="default" sectionFormat="of" derivedContent="RFC8826"/>. These considerations also
      apply to this memo.</t>
      <t indent="0" pn="section-13-2">The security considerations of the RTP specification, the RTP/SAVPF
      profile, and the various RTP/RTCP extensions and RTP payload formats
      that form the complete protocol suite described in this memo apply. It
      is believed that there are no new security considerations resulting from
      the combination of these various protocol extensions.</t>
      <t indent="0" pn="section-13-3"><xref target="RFC5124" format="default" sectionFormat="of" derivedContent="RFC5124">"Extended Secure RTP
      Profile for Real-time Transport Control Protocol (RTCP)-Based 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 is created by combining this secured RTP
      profile and <xref target="RFC5764" format="default" sectionFormat="of" derivedContent="RFC5764">DTLS-SRTP keying</xref>, as defined by
      <xref target="RFC8827" section="5.5" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8827#section-5.5" derivedContent="RFC8827"/>.</t>
      <t indent="0" pn="section-13-4">RTCP packets convey a Canonical Name (CNAME) identifier that is used
      to associate RTP packet streams that need to be synchronized across
      related RTP sessions. Inappropriate choice of CNAME values can be a
      privacy concern, since long-term persistent CNAME identifiers can be
      used to track users across multiple WebRTC calls. <xref target="sec-cname" format="default" sectionFormat="of" derivedContent="Section 4.9"/> of this memo mandates generation of
      short-term persistent RTCP CNAMES, as specified in RFC 7022, resulting in
      untraceable CNAME values that alleviate this risk.</t>
      <t indent="0" pn="section-13-5">Some potential denial-of-service attacks exist if the RTCP reporting
      interval is configured to an inappropriate value. This could be done by
      configuring the RTCP bandwidth fraction to an excessively large or small
      value using the SDP "b=RR:" or "b=RS:" lines <xref target="RFC3556" format="default" sectionFormat="of" derivedContent="RFC3556"/> or some similar mechanism, or by choosing an
      excessively large or small value for the RTP/AVPF minimal
      receiver report interval (if using SDP, this is the
      "a=rtcp-fb:... trr-int"
      parameter) <xref target="RFC4585" format="default" sectionFormat="of" derivedContent="RFC4585"/>. The risks are as
      follows:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-13-6">
        <li pn="section-13-6.1" derivedCounter="1.">the RTCP bandwidth could be configured to make the regular
          reporting interval so large that effective congestion control cannot
          be maintained, potentially leading to denial of service due to
          congestion caused by the media traffic;</li>
        <li pn="section-13-6.2" derivedCounter="2.">the RTCP interval could be configured to a very small value,
          causing endpoints to generate high-rate RTCP traffic, potentially
          leading to denial of service due to the RTCP traffic not being
          congestion controlled; and</li>
        <li pn="section-13-6.3" derivedCounter="3.">RTCP parameters could be configured differently for each
          endpoint, with some of the endpoints using a large reporting
          interval and some using a smaller interval, leading to denial of
          service due to premature participant timeouts due to mismatched
          timeout periods that are based on the reporting interval. This is a
          particular concern if endpoints use a small but nonzero value for
          the RTP/AVPF minimal receiver report interval (trr-int) <xref target="RFC4585" format="default" sectionFormat="of" derivedContent="RFC4585"/>, as discussed in
        <xref target="RFC8108" section="6.1" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8108#section-6.1" derivedContent="RFC8108"/>.</li>
      </ol>
      <t indent="0" pn="section-13-7">Premature participant timeout can be avoided by using the fixed
      (nonreduced) minimum interval when calculating the participant timeout
      (see <xref target="sec-rtp-rtcp" format="default" sectionFormat="of" derivedContent="Section 4.1"/> of this memo and
      <xref target="RFC8108" section="7.1.2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8108#section-7.1.2" derivedContent="RFC8108"/>). To address
      the other concerns, endpoints <bcp14>SHOULD</bcp14> ignore parameters that configure
      the RTCP reporting interval to be significantly longer than the default
      five-second interval specified in <xref target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550"/> (unless
      the media data rate is so low that the longer reporting interval roughly
      corresponds to 5% of the media data rate), or that configure the RTCP
      reporting interval small enough that the RTCP bandwidth would exceed the
      media bandwidth.</t>
      <t indent="0" pn="section-13-8">The guidelines in <xref target="RFC6562" format="default" sectionFormat="of" derivedContent="RFC6562"/> apply when using
      variable bitrate (VBR) audio codecs such as Opus (see <xref target="sec.codecs" format="default" sectionFormat="of" derivedContent="Section 4.3"/> for discussion of mandated audio codecs).
      The guidelines in <xref target="RFC6562" format="default" sectionFormat="of" derivedContent="RFC6562"/> also apply, but are of
      lesser importance, when using the client-to-mixer audio level header
      extensions (<xref target="sec-client-to-mixer" format="default" sectionFormat="of" derivedContent="Section 5.2.2"/>) or the
      mixer-to-client audio level header extensions (<xref target="sec-mixer-to-client" format="default" sectionFormat="of" derivedContent="Section 5.2.3"/>). The use of the encryption of the
      header extensions are <bcp14>RECOMMENDED</bcp14>, unless there are known reasons, like
      RTP middleboxes performing voice-activity-based source selection or
      third-party monitoring that will greatly benefit from the information,
      and this has been expressed using API or signaling. If further evidence
      is produced to show that information leakage is significant from
      audio-level indications, then use of encryption needs to be mandated at
      that time.</t>
      <t indent="0" pn="section-13-9">In multiparty communication scenarios using RTP middleboxes, a lot
      of trust is placed on these middleboxes to preserve the session's
      security. The middlebox needs to maintain confidentiality and integrity
      and perform source authentication. As discussed in <xref target="sec.multiple-flows" format="default" sectionFormat="of" derivedContent="Section 12.1.1"/>, the middlebox can perform checks
      that prevent any endpoint participating in a conference from impersonating
      another. Some additional security considerations regarding multiparty
      topologies can be found in <xref target="RFC7667" format="default" sectionFormat="of" derivedContent="RFC7667"/>.</t>
    </section>
    <section anchor="sec-iana" numbered="true" toc="include" removeInRFC="false" pn="section-14">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-14-1">This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references pn="section-15">
      <name slugifiedName="name-references">References</name>
      <references pn="section-15.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC2736" target="https://www.rfc-editor.org/info/rfc2736" quoteTitle="true" derivedAnchor="RFC2736">
          <front>
            <title>Guidelines for Writers of RTP Payload Format Specifications</title>
            <author initials="M." surname="Handley" fullname="M. Handley">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Perkins" fullname="C. Perkins">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1999" month="December"/>
            <abstract>
              <t indent="0">This document provides general guidelines aimed at assisting the authors of RTP Payload Format specifications in deciding on good formats.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="36"/>
          <seriesInfo name="RFC" value="2736"/>
          <seriesInfo name="DOI" value="10.17487/RFC2736"/>
        </reference>
        <reference anchor="RFC3550" target="https://www.rfc-editor.org/info/rfc3550" quoteTitle="true" derivedAnchor="RFC3550">
          <front>
            <title>RTP: A Transport Protocol for Real-Time Applications</title>
            <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Casner" fullname="S. Casner">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Frederick" fullname="R. Frederick">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="V." surname="Jacobson" fullname="V. Jacobson">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2003" month="July"/>
            <abstract>
              <t indent="0">This memorandum describes RTP, the real-time transport protocol.  RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services.  RTP does not address resource reservation and does not guarantee quality-of- service for real-time services.  The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality.  RTP and RTCP are designed to be independent of the underlying transport and network layers.  The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes.  There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="64"/>
          <seriesInfo name="RFC" value="3550"/>
          <seriesInfo name="DOI" value="10.17487/RFC3550"/>
        </reference>
        <reference anchor="RFC3551" target="https://www.rfc-editor.org/info/rfc3551" quoteTitle="true" derivedAnchor="RFC3551">
          <front>
            <title>RTP Profile for Audio and Video Conferences with Minimal Control</title>
            <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Casner" fullname="S. Casner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2003" month="July"/>
            <abstract>
              <t indent="0">This document describes a profile called "RTP/AVP" for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control.  It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences.  In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP.  It defines a set of standard encodings and their names when used within RTP.  The descriptions provide pointers to reference implementations and the detailed standards.  This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. This memorandum obsoletes RFC 1890.  It is mostly backwards-compatible except for functions removed because two interoperable implementations were not found.  The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="65"/>
          <seriesInfo name="RFC" value="3551"/>
          <seriesInfo name="DOI" value="10.17487/RFC3551"/>
        </reference>
        <reference anchor="RFC3556" target="https://www.rfc-editor.org/info/rfc3556" quoteTitle="true" derivedAnchor="RFC3556">
          <front>
            <title>Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth</title>
            <author initials="S." surname="Casner" fullname="S. Casner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2003" month="July"/>
            <abstract>
              <t indent="0">This document defines an extension to the Session Description Protocol (SDP) to specify two additional modifiers for the bandwidth attribute. These modifiers may be used to specify the bandwidth allowed for RTP Control Protocol (RTCP) packets in a Real-time Transport Protocol (RTP) session.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3556"/>
          <seriesInfo name="DOI" value="10.17487/RFC3556"/>
        </reference>
        <reference anchor="RFC3711" target="https://www.rfc-editor.org/info/rfc3711" quoteTitle="true" derivedAnchor="RFC3711">
          <front>
            <title>The Secure Real-time Transport Protocol (SRTP)</title>
            <author initials="M." surname="Baugher" fullname="M. Baugher">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="McGrew" fullname="D. McGrew">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Naslund" fullname="M. Naslund">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Carrara" fullname="E. Carrara">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Norrman" fullname="K. Norrman">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2004" month="March"/>
            <abstract>
              <t indent="0">This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP).   [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3711"/>
          <seriesInfo name="DOI" value="10.17487/RFC3711"/>
        </reference>
        <reference anchor="RFC4566" target="https://www.rfc-editor.org/info/rfc4566" quoteTitle="true" derivedAnchor="RFC4566">
          <front>
            <title>SDP: Session Description Protocol</title>
            <author initials="M." surname="Handley" fullname="M. Handley">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="V." surname="Jacobson" fullname="V. Jacobson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Perkins" fullname="C. Perkins">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="July"/>
            <abstract>
              <t indent="0">This memo defines the Session Description Protocol (SDP).  SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4566"/>
          <seriesInfo name="DOI" value="10.17487/RFC4566"/>
        </reference>
        <reference anchor="RFC4585" target="https://www.rfc-editor.org/info/rfc4585" quoteTitle="true" derivedAnchor="RFC4585">
          <front>
            <title>Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)</title>
            <author initials="J." surname="Ott" fullname="J. Ott">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Wenger" fullname="S. Wenger">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N." surname="Sato" fullname="N. Sato">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Burmeister" fullname="C. Burmeister">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Rey" fullname="J. Rey">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="July"/>
            <abstract>
              <t indent="0">Real-time media streams that use RTP are, to some degree, resilient against packet losses.  Receivers may use the base mechanisms of the Real-time Transport Control Protocol (RTCP) to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term.  This is the sole means for feedback and feedback-based error repair (besides a few codec-specific mechanisms).  This document defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented.  This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4585"/>
          <seriesInfo name="DOI" value="10.17487/RFC4585"/>
        </reference>
        <reference anchor="RFC4588" target="https://www.rfc-editor.org/info/rfc4588" quoteTitle="true" derivedAnchor="RFC4588">
          <front>
            <title>RTP Retransmission Payload Format</title>
            <author initials="J." surname="Rey" fullname="J. Rey">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Leon" fullname="D. Leon">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Miyazaki" fullname="A. Miyazaki">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="V." surname="Varsa" fullname="V. Varsa">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Hakenberg" fullname="R. Hakenberg">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="July"/>
            <abstract>
              <t indent="0">RTP retransmission is an effective packet loss recovery technique for real-time applications with relaxed delay bounds.  This document describes an RTP payload format for performing retransmissions. Retransmitted RTP packets are sent in a separate stream from the original RTP stream.  It is assumed that feedback from receivers to senders is available.  In particular, it is assumed that Real-time Transport Control Protocol (RTCP) feedback as defined in the extended RTP profile for RTCP-based feedback (denoted RTP/AVPF) is available in this memo.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4588"/>
          <seriesInfo name="DOI" value="10.17487/RFC4588"/>
        </reference>
        <reference anchor="RFC4961" target="https://www.rfc-editor.org/info/rfc4961" quoteTitle="true" derivedAnchor="RFC4961">
          <front>
            <title>Symmetric RTP / RTP Control Protocol (RTCP)</title>
            <author initials="D." surname="Wing" fullname="D. Wing">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2007" month="July"/>
            <abstract>
              <t indent="0">This document recommends using one UDP port pair for both communication directions of bidirectional RTP and RTP Control Protocol (RTCP) sessions, commonly called "symmetric RTP" and "symmetric RTCP".  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="131"/>
          <seriesInfo name="RFC" value="4961"/>
          <seriesInfo name="DOI" value="10.17487/RFC4961"/>
        </reference>
        <reference anchor="RFC5104" target="https://www.rfc-editor.org/info/rfc5104" quoteTitle="true" derivedAnchor="RFC5104">
          <front>
            <title>Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)</title>
            <author initials="S." surname="Wenger" fullname="S. Wenger">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="U." surname="Chandra" fullname="U. Chandra">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Westerlund" fullname="M. Westerlund">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Burman" fullname="B. Burman">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="February"/>
            <abstract>
              <t indent="0">This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF).  They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use.  However, some are also usable in smaller multicast environments and point-to-point calls.</t>
              <t indent="0">The extensions discussed are messages related to the ITU-T Rec. H.271 Video Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit Rate, and Temporal-Spatial Trade-off.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5104"/>
          <seriesInfo name="DOI" value="10.17487/RFC5104"/>
        </reference>
        <reference anchor="RFC5124" target="https://www.rfc-editor.org/info/rfc5124" quoteTitle="true" derivedAnchor="RFC5124">
          <front>
            <title>Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)</title>
            <author initials="J." surname="Ott" fullname="J. Ott">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Carrara" fullname="E. Carrara">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="February"/>
            <abstract>
              <t indent="0">An RTP profile (SAVP) for secure real-time communications and another profile (AVPF) to provide timely feedback from the receivers to a sender are defined in RFC 3711 and RFC 4585, respectively.  This memo specifies the combination of both profiles to enable secure RTP communications with feedback.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5124"/>
          <seriesInfo name="DOI" value="10.17487/RFC5124"/>
        </reference>
        <reference anchor="RFC5506" target="https://www.rfc-editor.org/info/rfc5506" quoteTitle="true" derivedAnchor="RFC5506">
          <front>
            <title>Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences</title>
            <author initials="I." surname="Johansson" fullname="I. Johansson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Westerlund" fullname="M. Westerlund">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2009" month="April"/>
            <abstract>
              <t indent="0">This memo discusses benefits and issues that arise when allowing Real-time Transport Protocol (RTCP) packets to be transmitted with reduced size.  The size can be reduced if the rules on how to create compound packets outlined in RFC 3550 are removed or changed.  Based on that analysis, this memo defines certain changes to the rules to allow feedback messages to be sent as Reduced-Size RTCP packets under certain conditions when using the RTP/AVPF (Real-time Transport Protocol / Audio-Visual Profile with Feedback) profile (RFC 4585). This document updates RFC 3550, RFC 3711, and RFC 4585.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5506"/>
          <seriesInfo name="DOI" value="10.17487/RFC5506"/>
        </reference>
        <reference anchor="RFC5761" target="https://www.rfc-editor.org/info/rfc5761" quoteTitle="true" derivedAnchor="RFC5761">
          <front>
            <title>Multiplexing RTP Data and Control Packets on a Single Port</title>
            <author initials="C." surname="Perkins" fullname="C. Perkins">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Westerlund" fullname="M. Westerlund">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="April"/>
            <abstract>
              <t indent="0">This memo discusses issues that arise when multiplexing RTP data packets and RTP Control Protocol (RTCP) packets on a single UDP port. It updates RFC 3550 and RFC 3551 to describe when such multiplexing is and is not appropriate, and it explains how the Session Description Protocol (SDP) can be used to signal multiplexed sessions.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5761"/>
          <seriesInfo name="DOI" value="10.17487/RFC5761"/>
        </reference>
        <reference anchor="RFC5764" target="https://www.rfc-editor.org/info/rfc5764" quoteTitle="true" derivedAnchor="RFC5764">
          <front>
            <title>Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)</title>
            <author initials="D." surname="McGrew" fullname="D. McGrew">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="May"/>
            <abstract>
              <t indent="0">This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTP Control Protocol (SRTCP) flows.  DTLS keying happens on the media path, independent of any out-of-band signalling channel present. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5764"/>
          <seriesInfo name="DOI" value="10.17487/RFC5764"/>
        </reference>
        <reference anchor="RFC6051" target="https://www.rfc-editor.org/info/rfc6051" quoteTitle="true" derivedAnchor="RFC6051">
          <front>
            <title>Rapid Synchronisation of RTP Flows</title>
            <author initials="C." surname="Perkins" fullname="C. Perkins">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Schierl" fullname="T. Schierl">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="November"/>
            <abstract>
              <t indent="0">This memo outlines how RTP sessions are synchronised, and discusses how rapidly such synchronisation can occur.  We show that most RTP sessions can be synchronised immediately, but that the use of video switching multipoint conference units (MCUs) or large source-specific multicast (SSM) groups can greatly increase the synchronisation delay.  This increase in delay can be unacceptable to some applications that use layered and/or multi-description codecs.</t>
              <t indent="0">This memo introduces three mechanisms to reduce the synchronisation delay for such sessions.  First, it updates the RTP Control Protocol (RTCP) timing rules to reduce the initial synchronisation delay for SSM sessions.  Second, a new feedback packet is defined for use with the extended RTP profile for RTCP-based feedback (RTP/AVPF), allowing video switching MCUs to rapidly request resynchronisation.  Finally, new RTP header extensions are defined to allow rapid synchronisation of late joiners, and guarantee correct timestamp-based decoding order recovery for layered codecs in the presence of clock skew.   [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6051"/>
          <seriesInfo name="DOI" value="10.17487/RFC6051"/>
        </reference>
        <reference anchor="RFC6464" target="https://www.rfc-editor.org/info/rfc6464" quoteTitle="true" derivedAnchor="RFC6464">
          <front>
            <title>A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication</title>
            <author initials="J." surname="Lennox" fullname="J. Lennox" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Ivov" fullname="E. Ivov">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Marocco" fullname="E. Marocco">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="December"/>
            <abstract>
              <t indent="0">This document defines a mechanism by which packets of Real-time Transport Protocol (RTP) audio streams can indicate, in an RTP header extension, the audio level of the audio sample carried in the RTP packet.  In large conferences, this can reduce the load on an audio mixer or other middlebox that wants to forward only a few of the loudest audio streams, without requiring it to decode and measure every stream that is received.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6464"/>
          <seriesInfo name="DOI" value="10.17487/RFC6464"/>
        </reference>
        <reference anchor="RFC6465" target="https://www.rfc-editor.org/info/rfc6465" quoteTitle="true" derivedAnchor="RFC6465">
          <front>
            <title>A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication</title>
            <author initials="E." surname="Ivov" fullname="E. Ivov" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Marocco" fullname="E. Marocco" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Lennox" fullname="J. Lennox">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="December"/>
            <abstract>
              <t indent="0">This document describes a mechanism for RTP-level mixers in audio conferences to deliver information about the audio level of individual participants.  Such audio level indicators are transported in the same RTP packets as the audio data they pertain to. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6465"/>
          <seriesInfo name="DOI" value="10.17487/RFC6465"/>
        </reference>
        <reference anchor="RFC6562" target="https://www.rfc-editor.org/info/rfc6562" quoteTitle="true" derivedAnchor="RFC6562">
          <front>
            <title>Guidelines for the Use of Variable Bit Rate Audio with Secure RTP</title>
            <author initials="C." surname="Perkins" fullname="C. Perkins">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="JM." surname="Valin" fullname="JM. Valin">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2012" month="March"/>
            <abstract>
              <t indent="0">This memo discusses potential security issues that arise when using variable bit rate (VBR) audio with the secure RTP profile.  Guidelines to mitigate these issues are suggested.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6562"/>
          <seriesInfo name="DOI" value="10.17487/RFC6562"/>
        </reference>
        <reference anchor="RFC6904" target="https://www.rfc-editor.org/info/rfc6904" quoteTitle="true" derivedAnchor="RFC6904">
          <front>
            <title>Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP)</title>
            <author initials="J." surname="Lennox" fullname="J. Lennox">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2013" month="April"/>
            <abstract>
              <t indent="0">The Secure Real-time Transport Protocol (SRTP) provides authentication, but not encryption, of the headers of Real-time Transport Protocol (RTP) packets.  However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality.  This document provides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP header extensions in SRTP.</t>
              <t indent="0">This document updates RFC 3711, the Secure Real-time Transport Protocol specification, to require that all future SRTP encryption transforms specify how RTP header extensions are to be encrypted.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6904"/>
          <seriesInfo name="DOI" value="10.17487/RFC6904"/>
        </reference>
        <reference anchor="RFC7007" target="https://www.rfc-editor.org/info/rfc7007" quoteTitle="true" derivedAnchor="RFC7007">
          <front>
            <title>Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP)</title>
            <author initials="T." surname="Terriberry" fullname="T. Terriberry">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2013" month="August"/>
            <abstract>
              <t indent="0">The RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) is the basis for many other profiles, such as the Secure Real-time Transport Protocol (RTP/SAVP), the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF), and the Extended Secure RTP Profile for RTCP-Based Feedback (RTP/SAVPF).  This document updates RFC 3551, the RTP/AVP profile (and by extension, the profiles that build upon it), to reflect changes in audio codec usage since that document was originally published.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7007"/>
          <seriesInfo name="DOI" value="10.17487/RFC7007"/>
        </reference>
        <reference anchor="RFC7022" target="https://www.rfc-editor.org/info/rfc7022" quoteTitle="true" derivedAnchor="RFC7022">
          <front>
            <title>Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)</title>
            <author initials="A." surname="Begen" fullname="A. Begen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Perkins" fullname="C. Perkins">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Wing" fullname="D. Wing">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2013" month="September"/>
            <abstract>
              <t indent="0">The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint.  While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams.</t>
              <t indent="0">For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session.  However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard (RFC 3550) are insufficient to achieve this uniqueness.  RFC 6222 was published to update those guidelines to allow endpoints to choose unique RTCP CNAMEs.  Unfortunately, later investigations showed that some parts of the new algorithms were unnecessarily complicated and/or ineffective.  This document addresses these concerns and replaces RFC 6222.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7022"/>
          <seriesInfo name="DOI" value="10.17487/RFC7022"/>
        </reference>
        <reference anchor="RFC7160" target="https://www.rfc-editor.org/info/rfc7160" quoteTitle="true" derivedAnchor="RFC7160">
          <front>
            <title>Support for Multiple Clock Rates in an RTP Session</title>
            <author initials="M." surname="Petit-Huguenin" fullname="M. Petit-Huguenin">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Zorn" fullname="G. Zorn" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2014" month="April"/>
            <abstract>
              <t indent="0">This document clarifies the RTP specification regarding the use of different clock rates in an RTP session.  It also provides guidance on how legacy RTP implementations that use multiple clock rates can interoperate with RTP implementations that use the algorithm described in this document.  It updates RFC 3550.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7160"/>
          <seriesInfo name="DOI" value="10.17487/RFC7160"/>
        </reference>
        <reference anchor="RFC7164" target="https://www.rfc-editor.org/info/rfc7164" quoteTitle="true" derivedAnchor="RFC7164">
          <front>
            <title>RTP and Leap Seconds</title>
            <author initials="K." surname="Gross" fullname="K. Gross">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Brandenburg" fullname="R. Brandenburg">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2014" month="March"/>
            <abstract>
              <t indent="0">This document discusses issues that arise when RTP sessions span Coordinated Universal Time (UTC) leap seconds.  It updates RFC 3550 by describing how RTP senders and receivers should behave in the presence of leap seconds.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7164"/>
          <seriesInfo name="DOI" value="10.17487/RFC7164"/>
        </reference>
        <reference anchor="RFC7742" target="https://www.rfc-editor.org/info/rfc7742" quoteTitle="true" derivedAnchor="RFC7742">
          <front>
            <title>WebRTC Video Processing and Codec Requirements</title>
            <author initials="A.B." surname="Roach" fullname="A.B. Roach">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="March"/>
            <abstract>
              <t indent="0">This specification provides the requirements and considerations for WebRTC applications to send and receive video across a network.  It specifies the video processing that is required as well as video codecs and their parameters.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7742"/>
          <seriesInfo name="DOI" value="10.17487/RFC7742"/>
        </reference>
        <reference anchor="RFC7874" target="https://www.rfc-editor.org/info/rfc7874" quoteTitle="true" derivedAnchor="RFC7874">
          <front>
            <title>WebRTC Audio Codec and Processing Requirements</title>
            <author initials="JM." surname="Valin" fullname="JM. Valin">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Bran" fullname="C. Bran">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="May"/>
            <abstract>
              <t indent="0">This document outlines the audio codec and processing requirements for WebRTC endpoints.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7874"/>
          <seriesInfo name="DOI" value="10.17487/RFC7874"/>
        </reference>
        <reference anchor="RFC8083" target="https://www.rfc-editor.org/info/rfc8083" quoteTitle="true" derivedAnchor="RFC8083">
          <front>
            <title>Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions</title>
            <author initials="C." surname="Perkins" fullname="C. Perkins">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="V." surname="Singh" fullname="V. Singh">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="March"/>
            <abstract>
              <t indent="0">The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications.  Such applications are often run on best-effort UDP/IP networks.  If congestion control is not implemented in these applications, then network congestion can lead to uncontrolled packet loss and a resulting deterioration of the user's multimedia experience.  The congestion control algorithm acts as a safety measure by stopping RTP flows from using excessive resources and protecting the network from overload.  At the time of this writing, however, while there are several proprietary solutions, there is no standard algorithm for congestion control of interactive RTP flows.</t>
              <t indent="0">This document does not propose a congestion control algorithm.  It instead defines a minimal set of RTP circuit breakers: conditions under which an RTP sender needs to stop transmitting media data to protect the network from excessive congestion.  It is expected that, in the absence of long-lived excessive congestion, RTP applications running on best-effort IP networks will be able to operate without triggering these circuit breakers.  To avoid triggering the RTP circuit breaker, any Standards Track congestion control algorithms defined for RTP will need to operate within the envelope set by these RTP circuit breaker algorithms.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8083"/>
          <seriesInfo name="DOI" value="10.17487/RFC8083"/>
        </reference>
        <reference anchor="RFC8108" target="https://www.rfc-editor.org/info/rfc8108" quoteTitle="true" derivedAnchor="RFC8108">
          <front>
            <title>Sending Multiple RTP Streams in a Single RTP Session</title>
            <author initials="J." surname="Lennox" fullname="J. Lennox">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Westerlund" fullname="M. Westerlund">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Q." surname="Wu" fullname="Q. Wu">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Perkins" fullname="C. Perkins">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="March"/>
            <abstract>
              <t indent="0">This memo expands and clarifies the behavior of Real-time Transport Protocol (RTP) endpoints that use multiple synchronization sources (SSRCs).  This occurs, for example, when an endpoint sends multiple RTP streams in a single RTP session.  This memo updates RFC 3550 with regard to handling multiple SSRCs per endpoint in RTP sessions, with a particular focus on RTP Control Protocol (RTCP) behavior.  It also updates RFC 4585 to change and clarify the calculation of the timeout of SSRCs and the inclusion of feedback messages.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8108"/>
          <seriesInfo name="DOI" value="10.17487/RFC8108"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8285" target="https://www.rfc-editor.org/info/rfc8285" quoteTitle="true" derivedAnchor="RFC8285">
          <front>
            <title>A General Mechanism for RTP Header Extensions</title>
            <author initials="D." surname="Singer" fullname="D. Singer">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Desineni" fullname="H. Desineni">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Even" fullname="R. Even" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="October"/>
            <abstract>
              <t indent="0">This document provides a general mechanism to use the header extension feature of RTP (the Real-time Transport Protocol).  It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is decentralized.  The actual extensions in use in a session are signaled in the setup information for that session.  This document obsoletes RFC 5285.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8285"/>
          <seriesInfo name="DOI" value="10.17487/RFC8285"/>
        </reference>
        <reference anchor="RFC8825" target="https://www.rfc-editor.org/info/rfc8825" quoteTitle="true" derivedAnchor="RFC8825">
          <front>
            <title>Overview: Real-Time Protocols for Browser-Based Applications</title>
            <author initials="H." surname="Alvestrand" fullname="Harald T. Alvestrand">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8825"/>
          <seriesInfo name="DOI" value="10.17487/RFC8825"/>
        </reference>
        <reference anchor="RFC8826" target="https://www.rfc-editor.org/info/rfc8826" quoteTitle="true" derivedAnchor="RFC8826">
          <front>
            <title>Security Considerations for WebRTC</title>
            <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8826"/>
          <seriesInfo name="DOI" value="10.17487/RFC8826"/>
        </reference>
        <reference anchor="RFC8827" target="https://www.rfc-editor.org/info/rfc8827" quoteTitle="true" derivedAnchor="RFC8827">
          <front>
            <title>WebRTC Security Architecture</title>
            <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8827"/>
          <seriesInfo name="DOI" value="10.17487/RFC8827"/>
        </reference>
        <reference anchor="RFC8843" target="https://www.rfc-editor.org/info/rfc8843" quoteTitle="true" derivedAnchor="RFC8843">
          <front>
            <title>Negotiating Media Multiplexing Using the Session Description Protocol (SDP)</title>
            <author initials="C" surname="Holmberg" fullname="Christer Holmberg">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H" surname="Alvestrand" fullname="Harald Alvestrand">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C" surname="Jennings" fullname="Cullen Jennings">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8843"/>
          <seriesInfo name="DOI" value="10.17487/RFC8843"/>
        </reference>
        <reference anchor="RFC8854" target="https://www.rfc-editor.org/info/rfc8854" quoteTitle="true" derivedAnchor="RFC8854">
          <front>
            <title>WebRTC Forward Error Correction Requirements</title>
            <author initials="J." surname="Uberti" fullname="Justin Uberti">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8854"/>
          <seriesInfo name="DOI" value="10.17487/RFC8854"/>
        </reference>
        <reference anchor="RFC8858" target="https://www.rfc-editor.org/info/rfc8858" quoteTitle="true" derivedAnchor="RFC8858">
          <front>
            <title>Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP) Multiplexing Using the Session Description Protocol (SDP)</title>
            <author initials="C." surname="Holmberg" fullname="Christer Holmberg">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8858"/>
          <seriesInfo name="DOI" value="10.17487/RFC8858"/>
        </reference>
        <reference anchor="RFC8860" target="https://www.rfc-editor.org/info/rfc8860" quoteTitle="true" derivedAnchor="RFC8860">
          <front>
            <title>Sending Multiple Types of Media in a Single RTP Session</title>
            <author initials="M." surname="Westerlund" fullname="Magnus Westerlund">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Perkins" fullname="Colin Perkins">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Lennox" fullname="Jonathan Lennox">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8860"/>
          <seriesInfo name="DOI" value="10.17487/RFC8860"/>
        </reference>
        <reference anchor="RFC8861" target="https://www.rfc-editor.org/info/rfc8861" quoteTitle="true" derivedAnchor="RFC8861">
          <front>
            <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">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Westerlund" fullname="Magnus Westerlund">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Q." surname="Wu" fullname="Qin Wu">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Perkins" fullname="Colin Perkins">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8861"/>
          <seriesInfo name="DOI" value="10.17487/RFC8861"/>
        </reference>
        <reference anchor="W3C.WD-mediacapture-streams" target="https://www.w3.org/TR/mediacapture-streams/" quoteTitle="true" derivedAnchor="W3C.WD-mediacapture-streams">
          <front>
            <title>Media Capture and Streams</title>
            <author initials="C." surname="Jennings" fullname="Cullen Jennings">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Aboba" fullname="Bernard Aboba">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J-I." surname="Bruaroey" fullname="Jan-Ivar Bruaroey">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Boström" fullname="Henrik Boström">
              <organization showOnFrontPage="true"/>
            </author>
            <date/>
          </front>
          <refcontent>W3C Candidate Recommendation</refcontent>
        </reference>
        <reference anchor="W3C.WebRTC" target="https://www.w3.org/TR/webrtc/" quoteTitle="true" derivedAnchor="W3C.WebRTC">
          <front>
            <title>WebRTC 1.0: Real-time Communication Between Browsers</title>
            <author initials="C." surname="Jennings" fullname="Cullen Jennings">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Boström" fullname="Henrik Boström">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J-I." surname="Bruaroey" fullname="Jan-Ivar Bruaroey">
              <organization showOnFrontPage="true"/>
            </author>
            <date/>
          </front>
          <refcontent>W3C Proposed Recommendation</refcontent>
        </reference>
      </references>
      <references pn="section-15.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC3611" target="https://www.rfc-editor.org/info/rfc3611" quoteTitle="true" derivedAnchor="RFC3611">
          <front>
            <title>RTP Control Protocol Extended Reports (RTCP XR)</title>
            <author initials="T." surname="Friedman" fullname="T. Friedman" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Caceres" fullname="R. Caceres" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Clark" fullname="A. Clark" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2003" month="November"/>
            <abstract>
              <t indent="0">This document defines the Extended Report (XR) packet type for the same
          synchronisation context RTP Control Protocol (RTCP), and logical endpoint by using the same RTCP
          CNAME identifier.</t>

          <t>The next provision is that defines how the internal clocks use of all media
          sources, i.e., what drives the RTP timestamp, XR packets can be correlated to a
          system clock that is provided in RTCP Sender Reports encoded in signaled by an
          NTP format. By correlating all RTP timestamps to a common system
          clock for all sources, the timing relation of the different RTP
          packet streams, also across multiple RTP sessions can be derived at
          the receiver and, application if desired, it employs the streams can be synchronized. Session Description Protocol (SDP).  XR packets are composed of report blocks, and seven block types are defined here.  The
          requirement is for the media sender to provide purpose of the correlation
          information; it extended reporting format is up to the receiver to use it or not.</t>
        </section>
      </section>
    </section>

    <section anchor="sec-security" title="Security Considerations">
      <t>The overall security architecture for WebRTC is described in <xref
      target="I-D.ietf-rtcweb-security-arch"></xref>, and security
      considerations for convey information that supplements the WebRTC framework six statistics that are described contained in <xref
      target="I-D.ietf-rtcweb-security"></xref>. These considerations also
      apply to this memo.</t>

      <t>The security considerations the report blocks used by RTCP's Sender Report (SR) and Receiver Report (RR) packets.  Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics.  In addition to the RTP specification, block types defined here, additional block types may be defined in the RTP/SAVPF
      profile, and future by adhering to the various RTP/RTCP extensions and RTP payload formats framework that form the complete protocol suite described this document provides.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3611"/>
          <seriesInfo name="DOI" value="10.17487/RFC3611"/>
        </reference>
        <reference anchor="RFC4383" target="https://www.rfc-editor.org/info/rfc4383" quoteTitle="true" derivedAnchor="RFC4383">
          <front>
            <title>The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in this the Secure Real-time Transport Protocol (SRTP)</title>
            <author initials="M." surname="Baugher" fullname="M. Baugher">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Carrara" fullname="E. Carrara">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="February"/>
            <abstract>
              <t indent="0">This memo apply. It
      is not believed there are any new security considerations resulting from describes the combination use of these various protocol extensions.</t>

      <t>The <xref target="RFC5124">Extended the Timed Efficient Stream Loss-tolerant Authentication (RFC 4082) transform within the Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback</xref> (RTP/SAVPF) (SRTP), to provide data origin authentication for multicast and broadcast data streams.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4383"/>
          <seriesInfo name="DOI" value="10.17487/RFC4383"/>
        </reference>
        <reference anchor="RFC5576" target="https://www.rfc-editor.org/info/rfc5576" quoteTitle="true" derivedAnchor="RFC5576">
          <front>
            <title>Source-Specific Media Attributes in the Session Description Protocol (SDP)</title>
            <author initials="J." surname="Lennox" fullname="J. Lennox">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Ott" fullname="J. Ott">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Schierl" fullname="T. Schierl">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2009" month="June"/>
            <abstract>
              <t indent="0">The Session Description Protocol (SDP) provides handling mechanisms to describe attributes of fundamental issues by offering confidentiality,
      integrity multimedia sessions and partial source authentication. A mandatory of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session, but does not provide any mechanism to implement
      and use describe individual media security solution is created by combining this secured sources within a media stream.  This document defines a mechanism to describe RTP
      profile and <xref target="RFC5764">DTLS-SRTP keying</xref> as defined media sources, which are identified by
      <xref target="I-D.ietf-rtcweb-security-arch">Section 5.5 of</xref>.</t>

      <t>RTCP packets convey a Canonical Name (CNAME) identifier that is used their synchronization source (SSRC) identifiers, in SDP, to associate RTP packet streams that need attributes with these sources, and to be synchronised across
      related RTP sessions. Inappropriate choice of CNAME values can be a
      privacy concern, since long-term persistent CNAME identifiers express relationships among sources.  It also defines several source-level attributes that can be used to track users across multiple WebRTC calls. <xref
      target="sec-cname"></xref> of this memo mandates generation of
      short-term persistent RTCP CNAMES, as specified in RFC7022, resulting in
      untraceable CNAME values that alleviate this risk.</t>

      <t>Some potential denial to describe properties of service attacks exist if media sources.   [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5576"/>
          <seriesInfo name="DOI" value="10.17487/RFC5576"/>
        </reference>
        <reference anchor="RFC5968" target="https://www.rfc-editor.org/info/rfc5968" quoteTitle="true" derivedAnchor="RFC5968">
          <front>
            <title>Guidelines for Extending the RTCP reporting
      interval RTP Control Protocol (RTCP)</title>
            <author initials="J." surname="Ott" fullname="J. Ott">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Perkins" fullname="C. Perkins">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="September"/>
            <abstract>
              <t indent="0">The RTP Control Protocol (RTCP) is configured used along with the Real-time Transport Protocol (RTP) to an inappropriate value. provide a control channel between media senders and receivers.  This could be done allows constructing a feedback loop to enable application adaptation and monitoring, among other uses.  The basic reporting mechanisms offered by
      configuring the RTCP bandwidth fraction are generic, yet quite powerful and suffice to cover a range of uses.  This document provides guidelines on extending RTCP if those basic mechanisms prove insufficient.  This document is not an excessively large or small
      value using the SDP "b=RR:" or "b=RS:" lines <xref
      target="RFC3556"></xref>, or some similar mechanism, or by choosing an
      excessively large or small value Internet Standards Track  specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5968"/>
          <seriesInfo name="DOI" value="10.17487/RFC5968"/>
        </reference>
        <reference anchor="RFC6263" target="https://www.rfc-editor.org/info/rfc6263" quoteTitle="true" derivedAnchor="RFC6263">
          <front>
            <title>Application Mechanism for Keeping Alive the RTP/AVPF minimal receiver
      report interval (if NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows</title>
            <author initials="X." surname="Marjou" fullname="X. Marjou">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Sollaud" fullname="A. Sollaud">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="June"/>
            <abstract>
              <t indent="0">This document lists the different mechanisms that enable applications using SDP, this is the "a=rtcp-fb:... trr-int"
      parameter) <xref target="RFC4585"></xref>. The risks are as
      follows:<list style="numbers">
          <t>the RTCP bandwidth could be configured to make Real-time Transport Protocol (RTP) and the regular
          reporting interval so large that effective congestion control cannot
          be maintained, potentially leading RTP Control Protocol (RTCP) to denial of service due keep their RTP Network Address Translator (NAT) mappings alive.  It also makes a recommendation for a preferred mechanism.  This document is not applicable to
          congestion caused by Interactive Connectivity Establishment (ICE) agents.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6263"/>
          <seriesInfo name="DOI" value="10.17487/RFC6263"/>
        </reference>
        <reference anchor="RFC6792" target="https://www.rfc-editor.org/info/rfc6792" quoteTitle="true" derivedAnchor="RFC6792">
          <front>
            <title>Guidelines for Use of the RTP Monitoring Framework</title>
            <author initials="Q." surname="Wu" fullname="Q. Wu" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Hunt" fullname="G. Hunt">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Arden" fullname="P. Arden">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2012" month="November"/>
            <abstract>
              <t indent="0">This memo proposes an extensible Real-time Transport Protocol (RTP) monitoring framework for extending the media traffic;</t>

          <t>the RTP Control Protocol (RTCP) with a new RTCP interval could be configured Extended Reports (XR) block type to report new metrics regarding media transmission or reception quality.  In this framework, a new XR block should contain a single metric or a very small value,
          causing endpoints to generate high rate RTCP traffic, potentially
          leading to denial number of service due metrics relevant to the non-congestion controlled
          RTCP traffic; and</t>

          <t>RTCP parameters could be configured differently for each
          endpoint, with some of the endpoints using a large reporting
          interval and some using single parameter of interest or concern, rather than containing a smaller interval, leading to denial number of
          service due metrics that attempt to premature participant timeouts due provide full coverage of all those parameters of concern to mismatched
          timeout periods which are based on the reporting interval (this is a
          particular concern if endpoints use specific application.  Applications may then "mix and match" to create a small but non-zero value for
          the RTP/AVPF minimal receiver report interval (trr-int) <xref
          target="RFC4585"></xref>, as discussed in Section 6.1 set of <xref
          target="I-D.ietf-avtcore-rtp-multi-stream"></xref>).</t>
        </list>Premature participant timeout can blocks that cover their set of concerns.  Where possible, a specific block should be avoided by using the fixed
      (non-reduced) minimum interval when calculating the participant timeout
      (see <xref target="sec-rtp-rtcp"></xref> designed to be reusable across more than one application, for example, for all of this memo voice, streaming audio, and Section 6.1 of
      <xref target="I-D.ietf-avtcore-rtp-multi-stream"></xref>). To address
      the other concerns, endpoints SHOULD ignore parameters that configure video.  This document is not an Internet Standards Track  specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6792"/>
          <seriesInfo name="DOI" value="10.17487/RFC6792"/>
        </reference>
        <reference anchor="RFC7478" target="https://www.rfc-editor.org/info/rfc7478" quoteTitle="true" derivedAnchor="RFC7478">
          <front>
            <title>Web Real-Time Communication Use Cases and Requirements</title>
            <author initials="C." surname="Holmberg" fullname="C. Holmberg">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Hakansson" fullname="S. Hakansson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Eriksson" fullname="G. Eriksson">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="March"/>
            <abstract>
              <t indent="0">This document describes web-based real-time communication use cases. Requirements on the RTCP reporting interval to be significantly longer than browser functionality are derived from the default
      five second interval specified use cases.</t>
              <t indent="0">This document was developed in <xref target="RFC3550"></xref> (unless
      the media data rate is so low that the longer reporting interval roughly
      corresponds to 5% an initial phase of the media data rate), work with rather minor updates at later stages.  It has not really served as a tool in deciding features or that configure scope for the RTCP
      reporting interval small enough that WG's efforts so far.  It is being published to record the RTCP bandwidth would exceed early conclusions of the
      media bandwidth.</t>

      <t>The guidelines in <xref target="RFC6562"></xref> apply when using
      variable bit rate (VBR) audio codecs such WG.  It will not be used as Opus (see <xref
      target="sec.codecs"></xref> for discussion a set of mandated audio codecs).
      The rigid guidelines that specifications and implementations will be held to in <xref target="RFC6562"></xref> also apply, but are of
      lesser importance, when using the client-to-mixer audio level header
      extensions (<xref target="sec-client-to-mixer"></xref>) or the
      mixer-to-client audio level header extensions (<xref
      target="sec-mixer-to-client"></xref>). The use future.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7478"/>
          <seriesInfo name="DOI" value="10.17487/RFC7478"/>
        </reference>
        <reference anchor="RFC7656" target="https://www.rfc-editor.org/info/rfc7656" quoteTitle="true" derivedAnchor="RFC7656">
          <front>
            <title>A Taxonomy of the encryption Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources</title>
            <author initials="J." surname="Lennox" fullname="J. Lennox">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Gross" fullname="K. Gross">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Nandakumar" fullname="S. Nandakumar">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Salgueiro" fullname="G. Salgueiro">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Burman" fullname="B. Burman" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="November"/>
            <abstract>
              <t indent="0">The terminology about, and associations among, Real-time Transport Protocol (RTP) sources can be complex and somewhat opaque.  This document describes a number of the
      header extensions are RECOMMENDED, unless there are known reasons, like existing and proposed properties and relationships among RTP middleboxes performing voice activity based source selection or
      third party monitoring that will greatly benefit from sources and defines common terminology for discussing protocol entities and their relationships.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7656"/>
          <seriesInfo name="DOI" value="10.17487/RFC7656"/>
        </reference>
        <reference anchor="RFC7657" target="https://www.rfc-editor.org/info/rfc7657" quoteTitle="true" derivedAnchor="RFC7657">
          <front>
            <title>Differentiated Services (Diffserv) and Real-Time Communication</title>
            <author initials="D." surname="Black" fullname="D. Black" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Jones" fullname="P. Jones">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="November"/>
            <abstract>
              <t indent="0">This memo describes the information, interaction between Differentiated Services (Diffserv) network quality-of-service (QoS) functionality and this has been expressed using API or signalling. If further evidence
      are produced to show that information leakage is significant from audio
      level indications, then use of encryption needs to be mandated at that
      time.</t>

      <t>In multi-party real- time network communication, including communication scenarios using RTP Middleboxes, a lot
      of trust based on the Real-time Transport Protocol (RTP).  Diffserv is placed based on these middleboxes network nodes applying different forwarding treatments to preserve packets whose IP headers are marked with different Diffserv Codepoints (DSCPs). WebRTC applications, as well as some conferencing applications, have begun using the sessions
      security. Session Description Protocol (SDP) bundle negotiation mechanism to send multiple traffic streams with different QoS requirements using the same network 5-tuple.  The middlebox needs results of using multiple DSCPs to maintain obtain different QoS treatments within a single network 5-tuple have transport protocol interactions, particularly with congestion control functionality (e.g., reordering).  In addition, DSCP markings may be changed or removed between the confidentiality, integrity
      and perform traffic source authentication. As discussed in <xref
      target="sec.multiple-flows"></xref> and destination.  This memo covers the middlebox can perform checks
      that prevents any endpoint participating implications of these Diffserv aspects for real-time network communication, including WebRTC.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7657"/>
          <seriesInfo name="DOI" value="10.17487/RFC7657"/>
        </reference>
        <reference anchor="RFC7667" target="https://www.rfc-editor.org/info/rfc7667" quoteTitle="true" derivedAnchor="RFC7667">
          <front>
            <title>RTP Topologies</title>
            <author initials="M." surname="Westerlund" fullname="M. Westerlund">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Wenger" fullname="S. Wenger">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="November"/>
            <abstract>
              <t indent="0">This document discusses point-to-point and multi-endpoint topologies used in a conference to impersonate
      another. Some additional security considerations regarding multi-party environments based on the Real-time Transport Protocol (RTP). In particular, centralized topologies can be found commonly employed in <xref
      target="I-D.ietf-avtcore-rtp-topologies-update"></xref>.</t>
    </section>

    <section anchor="sec-iana" title="IANA Considerations">
      <t>This memo makes no request of IANA.</t>

      <t>Note the video conferencing industry are mapped to RFC Editor: this section is the RTP terminology.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7667"/>
          <seriesInfo name="DOI" value="10.17487/RFC7667"/>
        </reference>
        <reference anchor="RFC8088" target="https://www.rfc-editor.org/info/rfc8088" quoteTitle="true" derivedAnchor="RFC8088">
          <front>
            <title>How to be removed Write an RTP Payload Format</title>
            <author initials="M." surname="Westerlund" fullname="M. Westerlund">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t indent="0">This document contains information on how best to write an RTP payload format specification.  It provides reading tips, design practices, and practical tips on publication as
      an RFC.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like how 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, produce an RTP payload format specification quickly and the other members with good results.  A template is also included with instructions.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8088"/>
          <seriesInfo name="DOI" value="10.17487/RFC8088"/>
        </reference>
        <reference anchor="RFC8445" target="https://www.rfc-editor.org/info/rfc8445" quoteTitle="true" derivedAnchor="RFC8445">
          <front>
            <title>Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal</title>
            <author initials="A." surname="Keranen" fullname="A. Keranen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Holmberg" fullname="C. Holmberg">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="July"/>
            <abstract>
              <t indent="0">This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication.  This protocol is called Interactive Connectivity Establishment (ICE).  ICE makes use of the IETF RTCWEB working group Session Traversal Utilities for
      their valuable feedback.</t>
    </section>
  </middle>

  <back>
    <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'?> NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).</t>
              <t indent="0">This document obsoletes RFC 5245.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8445"/>
          <seriesInfo name="DOI" value="10.17487/RFC8445"/>
        </reference>
        <reference anchor="RFC8829" target="https://www.rfc-editor.org/info/rfc8829" quoteTitle="true" derivedAnchor="RFC8829">
          <front>
            <title>JavaScript Session Establishment Protocol (JSEP)</title>
            <author initials="J." surname="Uberti" fullname="Justin Uberti">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Jennings" fullname="Cullen Jennings">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Rescorla" fullname="Eric Rescorla" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8829"/>
          <seriesInfo name="DOI" value="10.17487/RFC8829"/>
        </reference>
        <reference anchor='W3C.WD-webrtc-20130910'
           target='http://www.w3.org/TR/2013/WD-webrtc-20130910'> anchor="RFC8830" target="https://www.rfc-editor.org/info/rfc8830" quoteTitle="true" derivedAnchor="RFC8830">
          <front>
            <title>WebRTC 1.0: Real-time Communication Between Browsers</title> MediaStream Identification in the Session Description Protocol</title>
            <author initials="H" surname="Alvestrand" fullname="Harald Alvestrand">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8830"/>
          <seriesInfo name="DOI" value="10.17487/RFC8830"/>
        </reference>
        <reference anchor="RFC8836" target="https://www.rfc-editor.org/info/rfc8836" quoteTitle="true" derivedAnchor="RFC8836">
          <front>
            <title>Congestion Control Requirements for Interactive Real-Time Media</title>
            <author initials="R" surname="Jesup" fullname="Randell Jesup">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Z" surname="Sarker" fullname="Zaheduzzaman Sarker" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8836"/>
          <seriesInfo name="DOI" value="10.17487/RFC8836"/>
        </reference>
        <reference anchor="RFC8837" target="https://www.rfc-editor.org/info/rfc8837" quoteTitle="true" derivedAnchor="RFC8837">
          <front>
            <title>Differentiated Services Code Point (DSCP) Packet Markings for WebRTC QoS</title>
            <author initials='A.' surname='Bergkvist' fullname='Adam Bergkvist'> initials="P." surname="Jones" fullname="Paul Jones">
              <organization /> showOnFrontPage="true"/>
            </author>
            <author initials='D.' surname='Burnett' fullname='Daniel Burnett'> initials="S." surname="Dhesikan" fullname="Subha Dhesikan">
              <organization /> showOnFrontPage="true"/>
            </author>
            <author initials='C.' surname='Jennings' fullname='Cullen Jennings'> initials="C." surname="Jennings" fullname="Cullen Jennings">
              <organization /> showOnFrontPage="true"/>
            </author>
            <author initials='A.' surname='Narayanan' fullname='Anant Narayanan'> initials="D." surname="Druta" fullname="Dan Druta">
              <organization /> showOnFrontPage="true"/>
            </author>
            <date month='September' day='10' year='2013' /> month="January" year="2021"/>
          </front>
          <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="8837"/>
          <seriesInfo name="DOI" value="10.17487/RFC8837"/>
        </reference>
        <reference anchor='W3C.WD-mediacapture-streams-20130903'
           target='http://www.w3.org/TR/2013/WD-mediacapture-streams-20130903'> anchor="RFC8872" target="https://www.rfc-editor.org/info/rfc8872" quoteTitle="true" derivedAnchor="RFC8872">
          <front>
<title>Media Capture and
            <title>Guidelines for Using the Multiplexing Features of RTP to Support Multiple Media Streams</title>
            <author initials='D.' surname='Burnett' fullname='Daniel Burnett'> initials="M" surname="Westerlund" fullname="Magnus Westerlund">
              <organization /> showOnFrontPage="true"/>
            </author>
            <author initials='A.' surname='Bergkvist' fullname='Adam Bergkvist'> initials="B" surname="Burman" fullname="Bo Burman">
              <organization /> showOnFrontPage="true"/>
            </author>
            <author initials='C.' surname='Jennings' fullname='Cullen Jennings'> initials="C" surname="Perkins" fullname="Colin Perkins">
              <organization /> showOnFrontPage="true"/>
            </author>
            <author initials='A.' surname='Narayanan' fullname='Anant Narayanan'> initials="H" surname="Alvestrand" fullname="Harald Alvestrand">
              <organization /> showOnFrontPage="true"/>
            </author>
            <author initials="R" surname="Even" fullname="Roni Even">
      </author>
            <date month='September' day='3' year='2013' /> month="January" year="2021"/>
          </front>
          <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="8872"/>
          <seriesInfo name="DOI" value="10.17487/RFC8872"/>
        </reference>
      </references>

    <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'?>
    </references>
    <section anchor="Acknowledgements" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">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>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Colin Perkins" initials="C." surname="Perkins">
        <organization showOnFrontPage="true">University of Glasgow</organization>
        <address>
          <postal>
            <street>School of Computing Science</street>
            <city>Glasgow</city>
            <code>G12 8QQ</code>
            <country>United Kingdom</country>
          </postal>
          <email>csp@csperkins.org</email>
          <uri>https://csperkins.org/</uri>
        </address>
      </author>
      <author fullname="Magnus Westerlund" initials="M." surname="Westerlund">
        <organization showOnFrontPage="true">Ericsson</organization>
        <address>
          <postal>
            <street>Torshamnsgatan 23</street>
            <city>Kista</city>
            <code>164 80</code>
            <country>Sweden</country>
          </postal>
          <email>magnus.westerlund@ericsson.com</email>
        </address>
      </author>
      <author fullname="Jörg Ott" initials="J." surname="Ott">
        <organization showOnFrontPage="true">Technical University Munich</organization>
        <address>
          <postal>
            <extaddr>Department of Informatics</extaddr>
            <extaddr>Chair of Connected Mobility</extaddr>
            <street>Boltzmannstrasse 3</street>
            <city>Garching</city>
            <code>85748</code>
            <country>Germany</country>
          </postal>
          <email>ott@in.tum.de</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
<!-- vim: set ts=2 sw=2 tw=78 et ai: -->