<?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-mmusic-sdp-simulcast-14" indexInclude="true" ipr="trust200902" submissionType="IETF"> number="8853" prepTime="2021-01-17T00:22:15" 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-mmusic-sdp-simulcast-14" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc8853" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Simulcast">Using Simulcast in SDP Session Description Protocol (SDP) and RTP Sessions</title>
    <seriesInfo name="RFC" value="8853" stream="IETF"/>
    <author fullname="Bo Burman" initials="B." surname="Burman">
      <organization>Ericsson</organization>
      <organization showOnFrontPage="true">Ericsson</organization>
      <address>
        <postal>
          <street>Gronlandsgatan 31</street>
          <city>SE-164 60 Stockholm</city>
          <region/>
          <code/>
          <country>Sweden</country>
        </postal>
        <phone/>

        <facsimile/>
        <email>bo.burman@ericsson.com</email>
        <uri/>
      </address>
    </author>
    <author fullname="Magnus Westerlund" initials="M." surname="Westerlund">
      <organization>Ericsson</organization>
      <organization showOnFrontPage="true">Ericsson</organization>
      <address>
        <postal>
          <street>Torshamnsgatan 23</street>
          <city>SE-164 83 Stockholm</city>
          <country>Sweden</country>
        </postal>

        <phone>+46 10 714 82 87</phone>
        <email>magnus.westerlund@ericsson.com</email>
      </address>
    </author>
    <author fullname="Suhas Nandakumar" initials="S." surname="Nandakumar">
      <organization>Cisco</organization>
      <organization showOnFrontPage="true">Cisco</organization>
      <address>
        <postal>
          <street>170 West Tasman Drive</street>
          <city>San Jose</city>
          <region>CA</region>
          <code>95134</code>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <phone/>

        <facsimile/>
        <email>snandaku@cisco.com</email>
        <uri/>
      </address>
    </author>
    <author fullname="Mo Zanaty" initials="M." surname="Zanaty">
      <organization>Cisco</organization>
      <organization showOnFrontPage="true">Cisco</organization>
      <address>
        <postal>
          <street>170 West Tasman Drive</street>
          <city>San Jose</city>
          <region>CA</region>
          <code>95134</code>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <phone/>

        <facsimile/>
        <email>mzanaty@cisco.com</email>
        <uri/>
      </address>
    </author>
    <date day="5" month="March" year="2019"/>

    <abstract>
      <t>In month="01" year="2021"/>
    <keyword>Conference</keyword>
    <keyword>multi-party</keyword>
    <keyword>middlebox</keyword>
    <keyword>MCU</keyword>
    <keyword>SFU</keyword>
    <keyword>media</keyword>
    <keyword>video</keyword>
    <keyword>restrictions</keyword>
    <keyword>RTCP</keyword>
    <keyword>RID</keyword>
    <keyword>RtpStreamId</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">In some application scenarios scenarios, it may be desirable to send multiple
      differently encoded versions of the same media source in different RTP
      streams. This is called simulcast. This document describes how to
      accomplish simulcast in RTP and how to signal it in SDP. the Session
      Description Protocol (SDP).  The described solution uses an RTP/RTCP
      identification method to identify RTP streams
      belonging to the same media source, source and makes an extension to SDP to
      relate
      indicate that those RTP streams as being are different simulcast formats of that
      media source. The SDP extension consists of a new media level media-level SDP
      attribute that expresses capability to send and/or receive simulcast RTP
      streams.</t>
    </abstract>
    <boilerplate>
      <section 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 product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc8853" 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 persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.
        </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" 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-definitions">Definitions</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" 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-use-cases">Use Cases</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-reaching-a-diverse-set-of-r">Reaching a Diverse Set of Receivers</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-application-specific-media-">Application-Specific Media Source Handling</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-receiver-media-source-prefe">Receiver Media-Source Preferences</xref></t>
              </li>
            </ul>
          </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-overview">Overview</xref></t>
          </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-detailed-description">Detailed Description</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-simulcast-attribute">Simulcast Attribute</xref></t>
              </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-simulcast-capability">Simulcast Capability</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-offer-answer-use">Offer/Answer Use</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.3.2">
                  <li pn="section-toc.1-1.5.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.3.2.1.1"><xref derivedContent="5.3.1" format="counter" sectionFormat="of" target="section-5.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-generating-the-initial-sdp-">Generating the Initial SDP Offer</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.3.2.2.1"><xref derivedContent="5.3.2" format="counter" sectionFormat="of" target="section-5.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-creating-the-sdp-answer">Creating the SDP Answer</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.3.2.3">
                    <t indent="0" pn="section-toc.1-1.5.2.3.2.3.1"><xref derivedContent="5.3.3" format="counter" sectionFormat="of" target="section-5.3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-offerer-processing-the-sdp-">Offerer Processing the SDP Answer</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.3.2.4">
                    <t indent="0" pn="section-toc.1-1.5.2.3.2.4.1"><xref derivedContent="5.3.4" format="counter" sectionFormat="of" target="section-5.3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-modifying-the-session">Modifying the Session</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.5.2.4">
                <t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent="5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-use-with-declarative-sdp">Use with Declarative SDP</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.5">
                <t indent="0" pn="section-toc.1-1.5.2.5.1"><xref derivedContent="5.5" format="counter" sectionFormat="of" target="section-5.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-relating-simulcast-streams">Relating Simulcast Streams</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.6">
                <t indent="0" pn="section-toc.1-1.5.2.6.1"><xref derivedContent="5.6" format="counter" sectionFormat="of" target="section-5.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-signaling-examples">Signaling Examples</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.6.2">
                  <li pn="section-toc.1-1.5.2.6.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.6.2.1.1"><xref derivedContent="5.6.1" format="counter" sectionFormat="of" target="section-5.6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-single-source-client">Single-Source Client</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.6.2.2">
                    <t indent="0" pn="section-toc.1-1.5.2.6.2.2.1"><xref derivedContent="5.6.2" format="counter" sectionFormat="of" target="section-5.6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-multisource-client">Multisource Client</xref></t>
                  </li>
                  <li pn="section-toc.1-1.5.2.6.2.3">
                    <t indent="0" pn="section-toc.1-1.5.2.6.2.3.1"><xref derivedContent="5.6.3" format="counter" sectionFormat="of" target="section-5.6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-simulcast-and-redundancy">Simulcast and Redundancy</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-rtp-aspects">RTP Aspects</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-outgoing-from-endpoint-with">Outgoing from Endpoint with Media Source</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-rtp-middlebox-to-receiver">RTP Middlebox to Receiver</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.2.2">
                  <li pn="section-toc.1-1.6.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.6.2.2.2.1.1"><xref derivedContent="6.2.1" format="counter" sectionFormat="of" target="section-6.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-media-switching-mixer">Media-Switching Mixer</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.6.2.2.2.2.1"><xref derivedContent="6.2.2" format="counter" sectionFormat="of" target="section-6.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-selective-forwarding-middle">Selective Forwarding Middlebox</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-rtp-middlebox-to-rtp-middle">RTP Middlebox to RTP Middlebox</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-network-aspects">Network Aspects</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-bitrate-adaptation">Bitrate Adaptation</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-limitation">Limitation</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-iana-considerations">IANA Considerations</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-security-considerations">Security 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-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.11.2">
              <li pn="section-toc.1-1.11.2.1">
                <t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent="11.1" format="counter" sectionFormat="of" target="section-11.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.2">
                <t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent="11.2" format="counter" sectionFormat="of" target="section-11.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements">Requirements</xref></t>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.14">
            <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.15">
            <t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="sec-intro" title="Introduction">
      <t>Most numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">Most of today's multiparty video conference video-conference solutions make use of
      centralized servers to reduce the bandwidth and CPU consumption in the
      endpoints. Those servers receive RTP streams from each participant and
      send some suitable set of possibly modified RTP streams to the rest of
      the participants, which usually have heterogeneous capabilities (screen
      size, CPU, bandwidth, codec, etc). etc.). One of the biggest issues is how to
      perform RTP stream adaptation to different participants' constraints
      with the minimum possible impact on both video quality and server
      performance.</t>

      <t>Simulcast
      <t indent="0" pn="section-1-2">Simulcast is defined in this memo as the act of simultaneously
      sending multiple different encoded streams of the same media source,
      e.g. source --
      e.g., the same video source encoded with different video encoder video-encoder types or
      image resolutions. This can be done in several ways and for different
      purposes. This document focuses on the case where it is desirable to
      provide a media source as multiple encoded streams over <xref
      target="RFC3550">RTP</xref> target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550">RTP</xref> towards an intermediary so that the
      intermediary can provide the wanted functionality by selecting which RTP
      stream(s) to forward to other participants in the session, and more
      specifically how the identification and grouping of the involved RTP
      streams are done.</t>

      <t>The
      <t indent="0" pn="section-1-3">The intended scope of the defined mechanism is to support negotiation
      and usage of simulcast when using SDP offer/answer and media transport
      over RTP. The media transport topologies considered are point to point point-to-point
      RTP sessions sessions, as well as centralized multi-party multiparty RTP sessions, where a
      media sender will provide the simulcasted streams to an RTP middlebox or
      endpoint, and middleboxes may further distribute the simulcast streams
      to other middleboxes or endpoints. Simulcast could, could be used point to point between
      middleboxes as part of a distributed multi-party scenario, be used point-to-point between
      middleboxes. multiparty scenario. Usage of
      multicast or broadcast transport is out of scope
      and left for future extensions.</t>

      <t>This
      <t indent="0" pn="section-1-4">This document describes a few scenarios that motivate the use of
      simulcast,
      simulcast and also defines the needed RTP/RTCP and SDP signaling for
      it.</t>
    </section>
    <section anchor="sec-definitions" title="Definitions">
      <t/>

      <section title="Terminology">
        <t>This numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-definitions">Definitions</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-2.1">
        <name slugifiedName="name-terminology">Terminology</name>
        <t indent="0" pn="section-2.1-1">This document makes use of the terminology defined in <xref
        target="RFC7656">RTP Taxonomy</xref>, and <xref target="RFC7667">RTP
        Topologies</xref>. target="RFC7656" format="default" sectionFormat="of" derivedContent="RFC7656">"A Taxonomy of Semantics and
	Mechanisms for Real-Time
	Transport Protocol (RTP) Sources"</xref> and <xref target="RFC7667" format="default" sectionFormat="of" derivedContent="RFC7667">"RTP Topologies"</xref>. The following terms are
	especially noted or here
        defined:<list style="hanging">
            <t hangText="RTP Mixer:">An defined:</t>
        <dl newline="false" spacing="normal" indent="3" pn="section-2.1-2">
          <dt pn="section-2.1-2.1">RTP mixer:</dt>
          <dd pn="section-2.1-2.2">An RTP middle node, defined middlebox, in the wide sense of the term, encompassing
          Sections <xref
            target="RFC7667"/> (Section 3.6 to 3.9).</t>

            <t hangText="RTP Session:">An target="RFC7667" section="3.6" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7667#section-3.6" derivedContent="RFC7667"/>
          to <xref target="RFC7667" section="3.9" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7667#section-3.9" derivedContent="RFC7667"/> of
          <xref target="RFC7667" format="default" sectionFormat="of" derivedContent="RFC7667"/>.</dd>
          <dt pn="section-2.1-2.3">RTP session:</dt>
          <dd pn="section-2.1-2.4">An association among a group of
            participants communicating with RTP, as defined in <xref
            target="RFC3550"/> target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550"/> and amended by <xref target="RFC7656"/>.</t>

            <t hangText="RTP Stream:">A target="RFC7656" format="default" sectionFormat="of" derivedContent="RFC7656"/>.</dd>
          <dt pn="section-2.1-2.5">RTP stream:</dt>
          <dd pn="section-2.1-2.6">A stream of RTP packets containing media
            data, as defined in <xref target="RFC7656"/>.</t>

            <t hangText="RTP Switch:">A target="RFC7656" format="default" sectionFormat="of" derivedContent="RFC7656"/>.</dd>
          <dt pn="section-2.1-2.7">RTP switch:</dt>
          <dd pn="section-2.1-2.8">A common short term for the terms
            "switching RTP mixer", "source projecting middlebox", and "video
            switching MCU" Multipoint Control Unit (MCU)", as discussed in <xref target="RFC7667"/>.</t>

            <t hangText="Simulcast Stream:">One target="RFC7667" format="default" sectionFormat="of" derivedContent="RFC7667"/>.</dd>
          <dt pn="section-2.1-2.9">Simulcast stream:</dt>
          <dd pn="section-2.1-2.10">One encoded stream or dependent
            stream from a set of concurrently transmitted encoded streams and
            optional dependent streams, all sharing a common media source, as
            defined in <xref target="RFC7656"/>. target="RFC7656" format="default" sectionFormat="of" derivedContent="RFC7656"/>. For example, HD and thumbnail
            video simulcast versions of a single media source sent
            concurrently as separate RTP Streams.</t>

            <t hangText="Simulcast Format:">Different streams.</dd>
          <dt pn="section-2.1-2.11">Simulcast format:</dt>
          <dd pn="section-2.1-2.12">Different formats of a simulcast
            stream serve the same purpose as alternative RTP payload types in
            non-simulcast
            nonsimulcast SDP: to allow multiple alternative media formats for
            a given RTP stream. As for multiple RTP payload types on the
            m-line
            "m=" line in <xref target="RFC3264">offer/answer</xref>, target="RFC3264" format="default" sectionFormat="of" derivedContent="RFC3264">offer/answer</xref>, any one of
            the negotiated alternative formats can be used in a single RTP
            stream at a given point in time, but not more than one (based on
            RTP timestamp). What format is used can change dynamically from
            one RTP packet to another.</t>
          </list></t> another.</dd>
        </dl>
      </section>
      <section title="Requirements Language">
        <t>The numbered="true" toc="include" removeInRFC="false" pn="section-2.2">
        <name slugifiedName="name-requirements-language">Requirements Language</name>
        <t indent="0" pn="section-2.2-1">
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
        "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as
    described in BCP
        14 <xref target="RFC2119"/> BCP 14 <xref target="RFC8174"/> 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 capitals, as shown here.</t> here.
        </t>
      </section>
    </section>
    <section anchor="sec-use-cases" title="Use Cases">
      <t>The numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-use-cases">Use Cases</name>
      <t indent="0" pn="section-3-1">The use cases of simulcast described in this document relate to a
      multi-party
      multiparty communication session where one or more central nodes are
      used to adapt the view of the communication session towards individual
      participants,
      participants and facilitate the media transport between participants.
      Thus, these cases target the RTP Mixer mixer type of topology.</t>

      <t>There
      <t indent="0" pn="section-3-2">There are two principal approaches for an RTP Mixer mixer to provide this
      adapted view of the communication session to each receiving
      participant:<list style="symbols">
          <t>Transcoding
      participant:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-3">
        <li pn="section-3-3.1">Transcoding (decoding and re-encoding) received RTP streams with
          characteristics adapted to each receiving participant. This often
          include
          includes mixing or composition of media sources from multiple
          participants into a mixed media source originated by the RTP Mixer. mixer.
          The main advantage of this approach is that it achieves close to
          optimal
	  close-to-optimal adaptation to individual receiving
	  participants. The main
          disadvantages are that it can be very computationally expensive to
          the RTP Mixer, mixer, typically degrades media Quality of Experience (QoE)
          such as creating end-to-end delay for the receiving participants, and
          requires the RTP Mixer mixer to have access to media content.</t>

          <t>Switching content.</li>
        <li pn="section-3-3.2">Switching a subset of all received RTP streams or sub-streams substreams to
          each receiving participant, where the used subset is typically
          specific to each receiving participant. The main advantages of this
          approach are that it is computationally cheap to the RTP Mixer, mixer, has
          very limited impact on media QoE, and does not require the RTP Mixer mixer
	  to have (full) access to media content. The main disadvantage is
	  that it can be difficult to combine a subset of received RTP streams into a
          perfect fit to for the resource situation of a receiving participant. It
          is also a disadvantage that sending multiple RTP streams consumes
          more network resources from the sending participant to the RTP
          Mixer.</t>
        </list></t>

      <t>The
          mixer.</li>
      </ul>
      <t indent="0" pn="section-3-4">The use of simulcast relates to the latter approach, where it is more
      important to reduce the load on the RTP Mixer mixer and/or minimize QoE impact
      than to achieve an optimal adaptation of resource usage.</t>
      <section anchor="sec-diverse-receivers"
               title="Reaching numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-reaching-a-diverse-set-of-r">Reaching a Diverse Set of Receivers">
        <t>The Receivers</name>
        <t indent="0" pn="section-3.1-1">The media sources provided by a sending participant potentially
        need to reach several receiving participants that differ in terms of
        available resources. The receiver resources that typically differ
        include, but are not limited to:<list style="hanging">
            <t hangText="Codec:">This to:</t>
        <dl newline="false" spacing="normal" indent="3" pn="section-3.1-2">
          <dt pn="section-3.1-2.1">Codec:</dt>
          <dd pn="section-3.1-2.2">This includes codec type (such as RTP payload
            format MIME type) and can include codec configuration. A couple of
            codec resources that differ only in codec configuration will be
            "different" if they are somehow not "compatible", like such as if they
            differ in video codec profile, profile or the transport packetization
            configuration.</t>

            <t hangText="Sampling:">This
            configuration.</dd>
          <dt pn="section-3.1-2.3">Sampling:</dt>
          <dd pn="section-3.1-2.4">This relates to how the media source is
            sampled, in spatial as well as in temporal domain. For video
            streams, spatial sampling affects image resolution resolution, and temporal
            sampling affects video frame rate. For audio, spatial sampling
            relates to the number of audio channels channels, and temporal sampling
            affects audio bandwidth. This may be used to suit different
            rendering capabilities or needs at the receiving endpoints.</t>

            <t hangText="Bitrate:">This endpoints.</dd>
          <dt pn="section-3.1-2.5">Bitrate:</dt>
          <dd pn="section-3.1-2.6">This relates to the number of bits sent per
            second to transmit the media source as an RTP stream, which
            typically also affects the QoE for the receiving user.</t>
          </list>Letting user.</dd>
        </dl>
        <t indent="0" pn="section-3.1-3">Letting the sending participant create a simulcast of a few
        differently configured RTP streams per media source can be a good
        tradeoff
        trade-off when using an RTP switch as middlebox, instead of sending a
        single RTP stream and using an RTP mixer to create individual
        transcodings to each receiving participant.</t>

        <t>This
        <t indent="0" pn="section-3.1-4">This requires that the receiving participants can be categorized in
        terms of available resources and that the sending participant can
        choose a matching configuration for a single RTP stream per category
        and media source. For example, a set of receiving participants differ
        only in screen resolution; some are able to display video with at most
        360p resolution resolution, and some support 720p resolution. A sending
        participant can then reach all receivers with best possible resolution
        by creating a simulcast of RTP streams with 360p and 720p resolution
        for each sent video media source.</t>

        <t>The
        <t indent="0" pn="section-3.1-5">The maximum number of simulcasted RTP streams that can be sent is
        mainly limited by the amount of processing and uplink network
        resources available to the sending participant.</t>
      </section>
      <section anchor="sec-application-specific"
               title="Application Specific numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-application-specific-media-">Application-Specific Media Source Handling">
        <t>The Handling</name>
        <t indent="0" pn="section-3.2-1">The application logic that controls the communication session may
        include special handling of some media sources. It is, for example,
        commonly the case that the media from a sending participant is not
        sent back to itself.</t>

        <t>It
        <t indent="0" pn="section-3.2-2">It is also common that a currently active speaker participant is
        shown in larger size or higher quality than other participants (the
        sampling or bitrate aspects of <xref target="sec-diverse-receivers"/>) target="sec-diverse-receivers" format="default" sectionFormat="of" derivedContent="Section 3.1"/>)
        in a receiving client. Many conferencing systems do not send the
        active speaker's media back to the sender itself, which means there is
        some other participant's media that instead is forwarded to the active
        speaker;
        speaker -- typically the previous active speaker. This way, the
        previously active speaker is needed both in larger size (to current
        active speaker) and in small size (to the rest of the participants),
        which can be solved with a simulcast from the previously active
        speaker to the RTP switch.</t>
      </section>
      <section anchor="sec-receiver-preferences"
               title="Receiver Media Source Preferences">
        <t>The numbered="true" toc="include" removeInRFC="false" pn="section-3.3">
        <name slugifiedName="name-receiver-media-source-prefe">Receiver Media-Source Preferences</name>
        <t indent="0" pn="section-3.3-1">The application logic that controls the communication session may
        allow receiving participants to state preferences on the
        characteristics of the RTP stream they like to receive, for example in
        terms of the aspects listed in <xref target="sec-diverse-receivers"/>. target="sec-diverse-receivers" format="default" sectionFormat="of" derivedContent="Section 3.1"/>.
        Sending a simulcast of RTP streams is one way of accommodating
        receivers with conflicting or otherwise incompatible preferences.</t>
      </section>
    </section>
    <section anchor="sec-overview" title="Overview">
      <t>This numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-overview">Overview</name>
      <t indent="0" pn="section-4-1">This memo defines <xref target="RFC4566">SDP</xref> target="RFC4566" format="default" sectionFormat="of" derivedContent="RFC4566">SDP</xref> signaling that
      covers the above described simulcast use cases and functionalities. A
      number of requirements for such signaling are elaborated in <xref
      target="sec-requirements"/>.</t>

      <t>The RID target="sec-requirements" format="default" sectionFormat="of" derivedContent="Appendix A"/>.</t>
      <t indent="0" pn="section-4-2">The Restriction Identifier (RID) mechanism, as defined in <xref
      target="I-D.ietf-mmusic-rid"/>, target="RFC8851" format="default" sectionFormat="of" derivedContent="RFC8851"/>, enables an SDP offerer or answerer to
      specify a number of different RTP stream restrictions for a rid-id by
      using the "a=rid" line. Examples of such restrictions are maximum
      bitrate, maximum spatial video resolution (width and height), maximum
      video framerate, frame rate, etc. Each rid-id may also be restricted to use only a
      subset of the RTP payload types in the associated SDP media description.
      Those RTP payload types can have their own configurations and parameters
      affecting what can be sent or received, using the "a=fmtp" line as well
      as other SDP attributes.</t>

      <t>A
      <t indent="0" pn="section-4-3">A new SDP media level attribute "a=simulcast" media-level attribute, "a=simulcast", is defined. The
      attribute describes, independently for send "send" and receive "receive" directions, the
      number of simulcast RTP streams as well as potential alternative formats
      for each simulcast RTP stream. Each simulcast RTP stream, including
      alternatives, is identified using the RID identifier (rid-id), defined
      in <xref target="I-D.ietf-mmusic-rid"/>.</t>

      <figure align="left">
        <artwork align="left"><![CDATA[a=simulcast:send target="RFC8851" format="default" sectionFormat="of" derivedContent="RFC8851"/>.</t>
      <sourcecode type="sdp" markers="false" pn="section-4-4">
a=simulcast:send 1;2,3 recv 4
]]></artwork>
      </figure>

      <t>If the above
</sourcecode>
      <t indent="0" pn="section-4-5">If this line is included in an SDP offer, the "send" part
      indicates the offerer's capability and proposal to send two simulcast
      RTP streams. Each simulcast stream is described by one or more RTP
      stream identifiers (rid-id), (rid-ids), and each group of rid-ids for a simulcast
      stream is separated by a semicolon (";"). When a simulcast stream has
      multiple rid-ids that are separated by a comma (","), they describe
      alternative representations for that particular simulcast RTP stream.
      Thus, the above "send" part shown above is interpreted as an intention to send two
      simulcast RTP streams. The first simulcast RTP stream is identified and
      restricted according to rid-id 1. The second simulcast RTP stream can be
      sent as two alternatives, identified and restricted according to rid-ids
      2 and 3. The "recv" part of the above line shown here indicates that the offerer
      desires to receive a single RTP stream (no simulcast) according to
      rid-id 4.</t>

      <t>A
      <t indent="0" pn="section-4-6">A more complete example SDP offer SDP-offer media description is provided
      below:</t>
      in <xref target="fig-md-offer" format="default" sectionFormat="of" derivedContent="Figure 1"/>.</t>
      <figure align="center" anchor="fig-md-offer"
              title="Example align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-example-simulcast-media-des">Example Simulcast Media Description in Offer">
        <artwork align="left"><![CDATA[ Offer</name>
        <sourcecode type="sdp" markers="false" pn="section-4-7.1">
m=video 49300 RTP/AVP 97 98 99
a=rtpmap:97 H264/90000
a=rtpmap:98 H264/90000
a=rtpmap:99 VP8/90000
a=fmtp:97 profile-level-id=42c01f;max-fs=3600;max-mbps=108000
a=fmtp:98 profile-level-id=42c00b;max-fs=240;max-mbps=3600
a=fmtp:99 max-fs=240; max-fr=30
a=rid:1 send pt=97;max-width=1280;max-height=720
a=rid:2 send pt=98;max-width=320;max-height=180
a=rid:3 send pt=99;max-width=320;max-height=180
a=rid:4 recv pt=97
a=simulcast:send 1;2,3 recv 4
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
]]></artwork>
</sourcecode>
      </figure>

      <t>The above
      <t indent="0" pn="section-4-8">The SDP media description in <xref target="fig-md-offer" format="default" sectionFormat="of" derivedContent="Figure 1"/> can be
      interpreted at a high level to
      say that the offerer is capable of sending two simulcast RTP streams, streams:
      one H.264 encoded stream in up to 720p resolution, and one additional
      stream encoded as either H.264 or VP8 with a maximum resolution of
      320x180 pixels. The offerer can receive one H.264 stream with maximum
      720p resolution.</t>

      <t>The
      <t indent="0" pn="section-4-9">The receiver of this SDP offer can generate an SDP answer that
      indicates what it accepts. It uses the "a=simulcast" attribute to
      indicate simulcast capability and specify what simulcast RTP streams and
      alternatives to receive and/or send. An example of such an answering
      "a=simulcast" attribute, corresponding to the above offer, is:</t>

      <figure align="left">
        <artwork align="left"><![CDATA[a=simulcast:recv
      <sourcecode type="sdp" markers="false" pn="section-4-10">
a=simulcast:recv 1;2 send 4
]]></artwork>
      </figure>

      <t>With
</sourcecode>
      <t indent="0" pn="section-4-11">With this SDP answer, the answerer indicates in the "recv" part that
      it wants to receive the two simulcast RTP streams. It has removed an
      alternative that it doesn't support (rid-id 3). The send "send" part confirms
      to the offerer that it will receive one stream for this media source
      according to rid-id 4. The corresponding, more complete example SDP
      answer media description could look like:</t> like <xref target="fig-md-answer" format="default" sectionFormat="of" derivedContent="Figure 2"/>.</t>
      <figure align="center" anchor="fig-md-answer"
              title="Example align="left" suppress-title="false" pn="figure-2">
        <name slugifiedName="name-example-simulcast-media-desc">Example Simulcast Media Description in Answer">
        <artwork align="left"><![CDATA[ Answer</name>
        <sourcecode type="sdp" markers="false" pn="section-4-12.1">
m=video 49674 RTP/AVP 97 98
a=rtpmap:97 H264/90000
a=rtpmap:98 H264/90000
a=fmtp:97 profile-level-id=42c01f;max-fs=3600;max-mbps=108000
a=fmtp:98 profile-level-id=42c00b;max-fs=240;max-mbps=3600
a=rid:1 recv pt=97;max-width=1280;max-height=720
a=rid:2 recv pt=98;max-width=320;max-height=180
a=rid:4 send pt=97
a=simulcast:recv 1;2 send 4
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
]]></artwork>
</sourcecode>
      </figure>

      <t>It
      <t indent="0" pn="section-4-13">It is assumed that a single SDP media description is used to describe
      a single media source. This is aligned with the concepts defined in
      <xref target="RFC7656"/> target="RFC7656" format="default" sectionFormat="of" derivedContent="RFC7656"/> and will work in a WebRTC context, both with
      and without <xref
      target="I-D.ietf-mmusic-sdp-bundle-negotiation">BUNDLE</xref> BUNDLE grouping of media descriptions.</t>

      <t>To descriptions <xref target="RFC8843" format="default" sectionFormat="of" derivedContent="RFC8843"/>.</t>
      <t indent="0" pn="section-4-14">To summarize, the "a=simulcast" line describes send "send"- and receive
      direction
      "receive"-direction simulcast streams separately. Each direction can in
      turn describe one or more simulcast streams, separated by semicolon. semicolons. The
      identifiers describing simulcast streams on the "a=simulcast" line are
      rid-id,
      rid-ids, as defined by "a=rid" lines in <xref
      target="I-D.ietf-mmusic-rid"/>. target="RFC8851" format="default" sectionFormat="of" derivedContent="RFC8851"/>. Each simulcast stream can be offered as
      a list of alternative rid-id, rid-ids, with each alternative separated by a comma
      (not
      as shown in the examples above). example offer in <xref target="fig-md-offer" format="default" sectionFormat="of" derivedContent="Figure 1"/>. A detailed specification can be found in
      <xref target="sec-details"/> target="sec-details" format="default" sectionFormat="of" derivedContent="Section 5"/>, and more detailed examples are outlined in
      <xref target="sec-ex"/>.</t> target="sec-ex" format="default" sectionFormat="of" derivedContent="Section 5.6"/>.</t>
    </section>
    <section anchor="sec-details" title="Detailed Description">
      <t>This numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-detailed-description">Detailed Description</name>
      <t indent="0" pn="section-5-1">This section provides further details to the overview in <xref
      target="sec-overview">above</xref>. target="sec-overview" format="default" sectionFormat="of" derivedContent="Section 4"/>. First, formal syntax is <xref
      target="sec-attr">provided</xref>, target="sec-attr" format="default" sectionFormat="of" derivedContent="Section 5.1">provided</xref>, followed by the rest of the SDP
      attribute definition in <xref target="sec-cap"/>. <xref
      target="sec-relating">Relating target="sec-cap" format="default" sectionFormat="of" derivedContent="Section 5.2"/>. <xref target="sec-relating" format="default" sectionFormat="of" derivedContent="Section 5.5">"Relating Simulcast Streams </xref> Streams"</xref> provides the
      definition of the RTP/RTCP mechanisms used. The section is concluded concludes
      with a number of examples.</t>
      <section anchor="sec-attr" title="Simulcast Attribute">
        <t>This numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-simulcast-attribute">Simulcast Attribute</name>
        <t indent="0" pn="section-5.1-1">This document defines a new SDP media-level "a=simulcast"
        attribute, with value according to the following <xref
        target="RFC5234">ABNF</xref> syntax in <xref target="fig-abnf" format="default" sectionFormat="of" derivedContent="Figure 3"/>, which uses <xref target="RFC5234" format="default" sectionFormat="of" derivedContent="RFC5234">ABNF</xref> and its update for update, <xref
        target="RFC7405">Case-Sensitive target="RFC7405" format="default" sectionFormat="of" derivedContent="RFC7405">"Case-Sensitive String Support in ABNF</xref>:</t> ABNF"</xref>:</t>
        <figure align="center" anchor="fig-abnf"
                title="ABNF align="left" suppress-title="false" pn="figure-3">
          <name slugifiedName="name-abnf-for-simulcast-value">ABNF for Simulcast Value">
          <artwork align="center"><![CDATA[ Value</name>
          <sourcecode type="abnf" markers="false" pn="section-5.1-2.1">
sc-value     = ( sc-send [SP sc-recv] ) / ( sc-recv [SP sc-send] )
sc-send      = %s"send" SP sc-str-list
sc-recv      = %s"recv" SP sc-str-list
sc-str-list  = sc-alt-list *( ";" sc-alt-list )
sc-alt-list  = sc-id *( "," sc-id )
sc-id-paused = "~"
sc-id        = [sc-id-paused] rid-id
; SP defined in [RFC5234]
; rid-id defined in [I-D.ietf-mmusic-rid]
]]></artwork> [RFC8851]
</sourcecode>
        </figure>

        <t><list style="empty">
            <t>Note to RFC Editor: Replace "I-D.ietf-mmusic-rid" in the above
            figure with RFC number of draft-ietf-mmusic-rid before publication
            of this document.</t>
          </list></t>

        <t>The
        <t indent="0" pn="section-5.1-3">The "a=simulcast" attribute has a parameter in the form of one or
        two simulcast stream descriptions, each consisting of a direction
        ("send" or "recv"), followed by a list of one or more simulcast
        streams. Each simulcast stream consists of one or more alternative
        simulcast formats. Each simulcast format is identified by a simulcast
        stream identifier (rid-id). The rid-id MUST <bcp14>MUST</bcp14> have the form of an RTP
        stream identifier, as described by <xref
        target="I-D.ietf-mmusic-rid">RTP target="RFC8851" format="default" sectionFormat="of" derivedContent="RFC8851">"RTP Payload Format
        Restrictions</xref>.</t>

        <t>In Restrictions"</xref>.</t>
        <t indent="0" pn="section-5.1-4">In the list of simulcast streams, each simulcast stream is
        separated by a semicolon (";"). Each simulcast stream can can, in turn turn, be
        offered in one or more alternative formats, represented by rid-ids,
        separated by a comma commas (","). Each rid-id can also be specified as
        initially <xref target="RFC7728">paused</xref>, target="RFC7728" format="default" sectionFormat="of" derivedContent="RFC7728">paused</xref>, indicated by
        prepending a "~" to the rid-id. The reason to allow separate initial
        pause states for each rid-id is that pause capability can be specified
        individually for each RTP payload type referenced by an a rid-id. Since
        pause capability specified via the "a=rtcp-fb" attribute applies only
        to specified payload types types, and a rid-id specified by "a=rid" can refer
        to multiple different payload types, it is unfeasible to pause streams
        with rid-id where any of the related RTP payload type(s) do not have
        pause capability.</t>
      </section>
      <section anchor="sec-cap" title="Simulcast Capability">
        <t>Simulcast numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-simulcast-capability">Simulcast Capability</name>
        <t indent="0" pn="section-5.2-1">Simulcast capability is expressed through a new media level media-level <xref
        target="sec-attr">SDP target="sec-attr" format="default" sectionFormat="of" derivedContent="Section 5.1">SDP attribute, "a=simulcast"</xref>. The use of this
        attribute at the session level is undefined. Implementations of this
        specification MUST NOT <bcp14>MUST NOT</bcp14> use it at the session level and MUST <bcp14>MUST</bcp14> ignore it
        if received at the session level. Extensions to this specification may
        define such session level session-level usage. Each SDP media description MUST <bcp14>MUST</bcp14>
        contain at most one "a=simulcast" line.</t>

        <t>There
        <t indent="0" pn="section-5.2-2">There are separate and independent sets of simulcast streams in
        send the
        "send" and receive "receive" directions. When listing multiple directions, each
        direction MUST NOT <bcp14>MUST NOT</bcp14> occur more than once on the same line.</t>

        <t>Simulcast
        <t indent="0" pn="section-5.2-3">Simulcast streams using undefined rid-id MUST NOT rid-ids <bcp14>MUST NOT</bcp14> be used as valid
        simulcast streams by an RTP stream receiver. The direction for an a
        rid-id MUST <bcp14>MUST</bcp14> be aligned with the direction specified for the
        corresponding RTP stream identifier on the "a=rid" line.</t>

        <t>The
        <t indent="0" pn="section-5.2-4">The listed number of simulcast streams for a direction sets a limit
        to the number of supported simulcast streams in that direction. The
        order of the listed simulcast streams in the "send" direction suggests
        a proposed order of preference, in decreasing order: the rid-id listed
        first is the most preferred preferred, and subsequent streams have progressively
        lower preference. The order of the listed rid-id rid-ids in the "recv"
        direction expresses which simulcast streams that are preferred, with
        the leftmost being most preferred. This can be of importance if the
        number of actually sent simulcast streams have has to be reduced for some
        reason.</t>

        <t>rid-id
        <t indent="0" pn="section-5.2-5">rid-ids that have explicit <xref
        target="RFC5583">dependencies</xref> <xref
        target="I-D.ietf-mmusic-rid"/> target="RFC5583" format="default" sectionFormat="of" derivedContent="RFC5583">dependencies</xref> <xref target="RFC8851" format="default" sectionFormat="of" derivedContent="RFC8851"/> to other rid-id rid-ids (even in the same media
        description) MAY <bcp14>MAY</bcp14> be used.</t>

        <t>Use
        <t indent="0" pn="section-5.2-6">Use of more than a single, alternative simulcast format for a
	simulcast stream MAY <bcp14>MAY</bcp14> be specified as part of the
	attribute parameters by expressing the simulcast stream as a
	comma-separated list of alternative rid-id. rid-ids. The order of the rid-id
	alternatives within a simulcast stream is significant; the rid-id
	alternatives are listed from (left) most preferred to (right) least
	preferred. For the use of simulcast, this overrides the normal codec
	preference as expressed by
        format type format-type ordering on the "m=" line,
	using regular SDP rules. This is to enable a separation of general
	codec preferences and simulcast
        stream simulcast-stream configuration
	preferences. However, the choice of which alternative to use per
	simulcast stream is independent, and there is currently no mechanism
	for the offerer to align force the choice between answerer to choose the same alternative rid-ids
        between different
	for multiple simulcast streams.</t>

        <t>A streams.
        </t>
        <t indent="0" pn="section-5.2-7">A simulcast stream can use a codec defined such that the same RTP
        SSRC
        synchronization source (SSRC) can change RTP payload type multiple
        times during a session, possibly even on a per-packet basis. A typical
        example can be is a speech codec that makes use of formats for <xref target="RFC3389">Comfort target="RFC3389" format="default" sectionFormat="of" derivedContent="RFC3389">Comfort Noise</xref> and/or <xref target="RFC4733">DTMF</xref> formats.</t>

        <t>If <xref target="RFC7728">RTP target="RFC4733" format="default" sectionFormat="of" derivedContent="RFC4733">dual-tone multifrequency
        (DTMF)</xref>.</t>
        <t indent="0" pn="section-5.2-8">If <xref target="RFC7728" format="default" sectionFormat="of" derivedContent="RFC7728">RTP stream
        pause/resume</xref> is supported, any rid-id MAY <bcp14>MAY</bcp14> be
        prefixed by a "~" character to indicate that the corresponding
        simulcast stream is initially paused already from the start of the RTP
        session. In this case, support for RTP stream pause/resume MUST
        <bcp14>MUST</bcp14> also be included under the same "m=" line where
        "a=simulcast" is included. All RTP payload types related to such an
        initially paused simulcast stream MUST <bcp14>MUST</bcp14> be listed in the
        SDP as pause/resume capable as specified by <xref target="RFC7728"/>, e.g. target="RFC7728" format="default" sectionFormat="of" derivedContent="RFC7728"/> -- e.g., by using the "*" wildcard format for
        "a=rtcp-fb".</t>

        <t>An
        <t indent="0" pn="section-5.2-9">An initially paused simulcast stream in the "send" direction for the
        endpoint sending the SDP MUST <bcp14>MUST</bcp14> be considered equivalent to an
        unsolicited locally paused stream, stream and be handled accordingly.
        Initially paused simulcast streams are resumed as described by the RTP
        pause/resume specification. An RTP stream receiver that wishes to
        resume an unsolicited locally paused stream needs to know the SSRC of
        that stream.

	The SSRC of an initially paused simulcast stream can be obtained from
	an RTP stream sender RTCP Sender Report (SR) including or Receiver Report (RR)
	that includes both the desired SSRC as "SSRC of sender", initial SSRC in the source
	description (SDES) chunk, optionally a <xref target="RFC8843" format="default" sectionFormat="of" derivedContent="RFC8843">MID SDES item</xref> (if used and if rid-ids are not
	unique across "m=" lines), and the rid-id value in an <xref target="I-D.ietf-avtext-rid">RtpStreamId target="RFC8852" format="default" sectionFormat="of" derivedContent="RFC8852">RtpStreamId RTCP SDES
	item</xref>.</t>

        <t>If
        <t indent="0" pn="section-5.2-10">If the endpoint sending the SDP includes an "recv" direction a "recv"-direction
        simulcast stream that is initially paused, then the remote RTP sender
        receiving the SDP SHOULD <bcp14>SHOULD</bcp14> put its RTP stream in a an unsolicited locally
        paused state. The simulcast stream sender does not put the stream in
        the locally paused state if there are other RTP stream receivers in
        the session that do not mark the simulcast stream as initially paused.
        However, in centralized conferencing conferencing, the RTP sender usually does not
        see the SDP signalling signaling from RTP receivers and cannot make this
        determination. The reason to require for requiring that an initially paused "recv" stream
        to
        be considered locally paused by the remote RTP sender, sender instead of
        making it equivalent to implicitly sending a pause request, request is because that
        the pausing RTP sender cannot know which receiving SSRC owns the
        restriction when Temporary Maximum Media Stream Bit Rate Request
        (TMMBR) and Temporary Maximum Media Stream Bit Rate Notification
        (TMMBN) are used for pause/resume signaling (<xref
        target="RFC7728">Section 5.6 of </xref>) since target="RFC7728" sectionFormat="of" section="5.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7728#section-5.6" derivedContent="RFC7728"/>); this is because the RTP
	receiver's SSRC
        in send the "send" direction is sometimes not yet known.</t>

        <t>Use
        <t indent="0" pn="section-5.2-11">Use of the <xref target="RFC2198">redundant redundant audio data</xref> data format <xref target="RFC2198" format="default" sectionFormat="of" derivedContent="RFC2198"/>
	could be seen as a form of simulcast for loss protection loss-protection
        purposes, but it is not considered conflicting with the mechanisms
        described in this memo and MAY <bcp14>MAY</bcp14> therefore be used as any other format.
        In this case case, the "red" format, rather than the carried formats, SHOULD <bcp14>SHOULD</bcp14>
        be the one to list as a simulcast stream on the "a=simulcast"
        line.</t>

        <t>The
        <t indent="0" pn="section-5.2-12">The media formats and corresponding characteristics of simulcast
        streams SHOULD <bcp14>SHOULD</bcp14> be chosen such that they are different, e.g. different -- e.g., as
        different SDP formats with differing "a=rtpmap" and/or "a=fmtp" lines,
        or as differently defined RTP payload format restrictions. If this
        difference is not required, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to use <xref
        target="RFC7104">RTP duplication</xref> RTP duplication
	procedures <xref target="RFC7104" format="default" sectionFormat="of" derivedContent="RFC7104"/> instead of simulcast. To avoid
	complications in implementations, a single rid-id
        MUST NOT
        <bcp14>MUST NOT</bcp14> occur more than once per "a=simulcast" line. Note that this
        does not eliminate use of simulcast as an RTP duplication mechanism,
        since it is possible to define multiple different rid-id rid-ids that are
        effectively equivalent.</t>
      </section>
      <section anchor="sec-offer-answer" title="Offer/Answer Use">
        <t><list style="empty">
            <t>Note: The numbered="true" toc="include" removeInRFC="false" pn="section-5.3">
        <name slugifiedName="name-offer-answer-use">Offer/Answer Use</name>
        <dl indent="3" newline="false" spacing="normal" pn="section-5.3-1">
          <dt pn="section-5.3-1.1">Note:</dt>
          <dd pn="section-5.3-1.2">The inclusion of "a=simulcast" or the use of simulcast
            does not change any of the interpretation or Offer/Answer
            procedures for other SDP attributes, like such as "a=fmtp" or "a=rid".</t>
          </list></t> "a=rid".</dd>
        </dl>
        <section title="Generating numbered="true" toc="include" removeInRFC="false" pn="section-5.3.1">
          <name slugifiedName="name-generating-the-initial-sdp-">Generating the Initial SDP Offer">
          <t>An Offer</name>
          <t indent="0" pn="section-5.3.1-1">An offerer wanting to use simulcast for a media description SHALL <bcp14>SHALL</bcp14>
          include one "a=simulcast" attribute in that media description in the
          offer. An offerer listing a set of receive simulcast streams and/or
          alternative formats as rid-id rid-ids in the offer MUST <bcp14>MUST</bcp14> be prepared to
          receive RTP streams for any of those simulcast streams and/or
          alternative formats from the answerer.</t>
        </section>
        <section title="Creating numbered="true" toc="include" removeInRFC="false" pn="section-5.3.2">
          <name slugifiedName="name-creating-the-sdp-answer">Creating the SDP Answer">
          <t>An Answer</name>
          <t indent="0" pn="section-5.3.2-1">An answerer that does not understand the concept of simulcast
          will also not know the attribute and will remove it in the SDP
          answer, as defined in existing SDP offer/answer procedures <xref target="RFC3264">SDP
          Offer/Answer</xref> procedures. target="RFC3264" format="default" sectionFormat="of" derivedContent="RFC3264"/>. Since SDP session level session-level simulcast is
          undefined in this memo, an answerer that receives an offer with the
          "a=simulcast" attribute on the SDP session level SHALL <bcp14>SHALL</bcp14> remove it in the
          answer. An answerer that understands the attribute but receives
          multiple "a=simulcast" attributes in the same media description
          SHALL
          <bcp14>SHALL</bcp14> disable use of simulcast by removing all "a=simulcast" lines
          for that media description in the answer.</t>

          <t>An
          <t indent="0" pn="section-5.3.2-2">An answerer that does understand the attribute and that wants to
          support simulcast in an indicated direction SHALL <bcp14>SHALL</bcp14> reverse
          directionality of the unidirectional direction parameters; parameters -- "send"
          becomes "recv" and vice versa, versa -- and include it in the answer.</t>

          <t>An
          <t indent="0" pn="section-5.3.2-3">An answerer that receives an offer with simulcast containing an
          "a=simulcast" attribute listing alternative rid-id MAY rid-ids <bcp14>MAY</bcp14> keep all the
          alternative rid-id rid-ids in the answer, but it MAY <bcp14>MAY</bcp14> also choose to remove
          any non-desirable nondesirable alternative rid-id rid-ids in the answer. The answerer
          MUST NOT
          <bcp14>MUST NOT</bcp14> add any alternative rid-id rid-ids in send the "send" direction in the answer
          that were not present in the offer receive direction. The answerer
          MUST
          <bcp14>MUST</bcp14> be prepared to receive any of the receive direction receive-direction rid-id
          alternatives and MAY <bcp14>MAY</bcp14> send any of the send direction "send"-direction alternatives
          that are part of the answer.</t>

          <t>An
          <t indent="0" pn="section-5.3.2-4">An answerer that receives an offer with simulcast that lists a
          number of simulcast streams, MAY streams <bcp14>MAY</bcp14> reduce the number of simulcast
          streams in the answer, but MUST NOT it <bcp14>MUST NOT</bcp14> add simulcast streams.</t>

          <t>An
          <t indent="0" pn="section-5.3.2-5">An answerer that receives an offer without RTP stream
          pause/resume capability MUST NOT <bcp14>MUST NOT</bcp14> mark any simulcast streams as
          initially paused in the answer.</t>

          <t>An
          <t indent="0" pn="section-5.3.2-6">An RTP stream pause/resume capable answerer capable of pause/resume that receives an
          offer with RTP stream pause/resume capability MAY <bcp14>MAY</bcp14> mark any rid-id rid-ids
          that refer to pause/resume capable formats as initially paused in
          the answer.</t>

          <t>An
          <t indent="0" pn="section-5.3.2-7">An answerer that receives indication in an offer of an a rid-id
          being initially paused SHOULD <bcp14>SHOULD</bcp14> mark that rid-id as initially paused
          also in the answer, regardless of direction, unless it has good
          reason for the rid-id not being initially paused. One reason to
          remove an initial pause in the answer compared to the offer could, could be,
          for example, be that all receive direction "receive"-direction simulcast streams for a
          media source the answerer accepts in the answer would otherwise be
          paused.</t>
        </section>
        <section title="Offerer numbered="true" toc="include" removeInRFC="false" pn="section-5.3.3">
          <name slugifiedName="name-offerer-processing-the-sdp-">Offerer Processing the SDP Answer">
          <t>An Answer</name>
          <t indent="0" pn="section-5.3.3-1">An offerer that receives an answer without "a=simulcast" MUST NOT <bcp14>MUST NOT</bcp14>
          use simulcast towards the answerer. An offerer that receives an
          answer with "a=simulcast" without any rid-id in a specified
          direction MUST NOT <bcp14>MUST NOT</bcp14> use simulcast in that direction.</t>

          <t>An
          <t indent="0" pn="section-5.3.3-2">An offerer that receives an answer where some rid-id alternatives
          are kept MUST <bcp14>MUST</bcp14> be prepared to receive any of the kept send direction "send"-direction
          rid-id alternatives, alternatives and MAY <bcp14>MAY</bcp14> send any of the kept receive direction "receive"-direction
          rid-id alternatives.</t>

          <t>An
          <t indent="0" pn="section-5.3.3-3">An offerer that receives an answer where some of the rid-id rid-ids are
          removed compared to the offer MAY <bcp14>MAY</bcp14> release the corresponding
          resources (codec, transport, etc) in its receive "receive" direction and MUST
          NOT <bcp14>MUST NOT</bcp14> send any RTP packets corresponding to the removed rid-id.</t>

          <t>An rid-ids.</t>
          <t indent="0" pn="section-5.3.3-4">An offerer that offered some of its rid-id rid-ids as initially paused
          and that receives an answer that does not indicate RTP stream
          pause/resume capability, MUST NOT capability <bcp14>MUST NOT</bcp14> initially pause any simulcast
          streams.</t>

          <t>An
          <t indent="0" pn="section-5.3.3-5">An offerer with RTP stream pause/resume capability that receives
          an answer where some rid-id rid-ids are marked as initially paused, SHOULD paused <bcp14>SHOULD</bcp14>
          initially pause those RTP streams regardless streams, even if they were marked as
          initially paused also in the offer, unless it has good reason for
          those RTP streams not being initially paused. One such reason could, could be,
          for example, be that the answerer would otherwise initially not
          receive any media of that type at all.</t>
        </section>
        <section title="Modifying numbered="true" toc="include" removeInRFC="false" pn="section-5.3.4">
          <name slugifiedName="name-modifying-the-session">Modifying the Session">
          <t>Offers Session</name>
          <t indent="0" pn="section-5.3.4-1">Offers inside an existing session follow the same rules as for
          initial SDP offer, with these additions:<list style="numbers">
              <t>rid-id additions:</t>
          <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-5.3.4-2">
            <li pn="section-5.3.4-2.1" derivedCounter="1.">rid-ids marked as initially paused in the offerer's send "send"
              direction SHALL <bcp14>SHALL</bcp14> reflect the offerer's opinion of the current
              pause state at the time of creating the offer. This is purely
              informational, and <xref target="RFC7728">RTP RTP stream
              pause/resume</xref>
              pause/resume signaling <xref target="RFC7728" format="default" sectionFormat="of" derivedContent="RFC7728"/> in the ongoing
	      session SHALL <bcp14>SHALL</bcp14> take precedence in case of any conflict or ambiguity.</t>

              <t>rid-id
	      ambiguity.</li>
            <li pn="section-5.3.4-2.2" derivedCounter="2.">rid-ids marked as initially paused in the offerer's receive "receive"
              direction SHALL <bcp14>SHALL</bcp14> (as in an initial offer) reflect the offerer's
              desired rid-id pause state. Except for the case where the
              offerer already paused the corresponding RTP stream through
              <xref target="RFC7728">RTP target="RFC7728" format="default" sectionFormat="of" derivedContent="RFC7728">RTP stream pause/resume</xref> signaling
              , signaling,
	      this is identical to the conditions at an initial offer.</t>
            </list></t>

          <t>Creation offer.</li>
          </ol>
          <t indent="0" pn="section-5.3.4-3">Creation of SDP answers and processing of SDP answers inside an
          existing session follow the same rules as described above for
          initial SDP offer/answer.</t>

          <t>Session
          <t indent="0" pn="section-5.3.4-4">Session modification restrictions in section 6.5 of <xref
          target="I-D.ietf-mmusic-rid">RTP payload format restrictions</xref> target="RFC8851" sectionFormat="of" section="6.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8851#section-6.5" derivedContent="RFC8851">"RTP Payload Format
	  Restrictions"</xref>
          also apply.</t>
        </section>
      </section>
      <section title="Use numbered="true" toc="include" removeInRFC="false" pn="section-5.4">
        <name slugifiedName="name-use-with-declarative-sdp">Use with Declarative SDP">
        <t>This SDP</name>
        <t indent="0" pn="section-5.4-1">This document does not define the use of "a=simulcast" in
        declarative SDP, partly motivated by because use of the <xref
        target="I-D.ietf-mmusic-rid">simulcast target="RFC8851" format="default" sectionFormat="of" derivedContent="RFC8851">simulcast format identification</xref>
        is not being defined for use in declarative SDP. If concrete use cases
        for simulcast in declarative SDP are identified in the future, the
        authors of this memo expect that additional specifications will
        address such use.</t>
      </section>
      <section anchor="sec-relating" title="Relating numbered="true" toc="include" removeInRFC="false" pn="section-5.5">
        <name slugifiedName="name-relating-simulcast-streams">Relating Simulcast Streams">
        <t>Simulcast Streams</name>
        <t indent="0" pn="section-5.5-1">Simulcast RTP streams MUST <bcp14>MUST</bcp14> be related on the RTP
	level through <xref
        target="I-D.ietf-avtext-rid">RtpStreamId</xref>, target="RFC8852" format="default" sectionFormat="of" derivedContent="RFC8852">RtpStreamId</xref>, as specified in the
        SDP <xref target="sec-cap">"a=simulcast" target="sec-cap" format="default" sectionFormat="of" derivedContent="Section 5.2">"a=simulcast" attribute
          </xref> parameters.
        This is sufficient as long as there is only a single media source per
        SDP media description. When using <xref
        target="I-D.ietf-mmusic-sdp-bundle-negotiation">BUNDLE</xref>, target="RFC8843" format="default" sectionFormat="of" derivedContent="RFC8843">BUNDLE</xref>, where
        multiple SDP media descriptions jointly specify a single RTP session,
        the SDES MID identification (Media Identification) mechanism in BUNDLE allows relating RTP
        streams back to individual media descriptions, after which the above
        described
	RtpStreamId relations described above can be used.

	Use of the <xref
        target="RFC8285">RTP RTP header extension</xref> extension for the <xref target="RFC7941" format="default" sectionFormat="of" derivedContent="RFC7941">RTCP
	source description items</xref> for both MID
	and RtpStreamId identifications can be important to ensure rapid
	initial reception, required to correctly interpret and process the RTP
	streams. Implementers of this specification MUST <bcp14>MUST</bcp14>
	support the RTCP source description (SDES) item method and SHOULD
	<bcp14>SHOULD</bcp14> support RTP header extension method to signal
	RtpStreamId on the RTP level.<list
            style="hanging">
            <t hangText="NOTE:">For level.</t>
        <dl newline="false" spacing="normal" indent="3" pn="section-5.5-2">
          <dt pn="section-5.5-2.1">NOTE:</dt>
          <dd pn="section-5.5-2.2">For the case where it is clear from SDP that the
            RTP PT uniquely maps to a corresponding RtpStreamId, an RTP receiver
            can use RTP PT to relate simulcast streams. This can sometimes
            enable decoding even in advance to of receiving RtpStreamId
            information in RTCP SDES and/or RTP header extensions.</t>
          </list></t>

        <t>RTP extensions.</dd>
        </dl>
        <t indent="0" pn="section-5.5-3">RTP streams MUST <bcp14>MUST</bcp14> only use a single alternative rid-id at a time
        (based on RTP timestamps), timestamps) but MAY <bcp14>MAY</bcp14> change format (and rid-id) on a
        per-RTP packet basis. This corresponds to the existing (non-simulcast) (nonsimulcast)
        SDP offer/answer case when multiple formats are included on the "m="
        line in the SDP answer, enabling per-RTP packet change of RTP payload
        type.</t>
      </section>
      <section anchor="sec-ex" title="Signaling Examples">
        <t>These numbered="true" toc="include" removeInRFC="false" pn="section-5.6">
        <name slugifiedName="name-signaling-examples">Signaling Examples</name>
        <t indent="0" pn="section-5.6-1">These examples describe a client to video conference client-to-video-conference service, using
        a centralized media topology with an RTP mixer.</t>
        <figure align="center" anchor="fig-mixer-four-party"
                title="Four-party Mixer-based Conference"> align="left" suppress-title="false" pn="figure-4">
          <name slugifiedName="name-four-party-mixer-based-conf">Four-Party Mixer-Based Conference</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt="" pn="section-5.6-2.1">
+---+      +-----------+      +---+
| A |<---->|           |<---->| |&lt;----&gt;|           |&lt;----&gt;| B |
+---+      |           |      +---+
           |   Mixer   |
+---+      |           |      +---+
| F |<---->|           |<---->| |&lt;----&gt;|           |&lt;----&gt;| J |
+---+      +-----------+      +---+]]></artwork>      +---+</artwork>
        </figure>
        <section anchor="sec-ex-single-source" title="Single-Source Client">
          <t>Alice numbered="true" toc="include" removeInRFC="false" pn="section-5.6.1">
          <name slugifiedName="name-single-source-client">Single-Source Client</name>
          <t indent="0" pn="section-5.6.1-1">Alice is calling in to the mixer with a simulcast-enabled client
          capable of a single media source per media type. The client can send
          a simulcast of 2 video resolutions and frame rates: HD 1280x720p
          30fps and thumbnail 320x180p 15fps. This is defined below using the
          <xref target="RFC6236">"imageattr"</xref>. target="RFC6236" format="default" sectionFormat="of" derivedContent="RFC6236">"imageattr"</xref>. In this example, only the
          "pt" "a=rid" parameter is used, used to
          describe simulcast stream formats, effectively achieving a 1:1 mapping
          between RtpStreamId and media formats (RTP payload types), to
          describe simulcast stream formats. types). Alice's Offer:</t>
          <figure align="center" anchor="fig-up-offer"
                  title="Single-Source align="left" suppress-title="false" pn="figure-5">
            <name slugifiedName="name-single-source-simulcast-off">Single-Source Simulcast Offer">
            <artwork align="left"><![CDATA[ Offer</name>
            <sourcecode type="sdp" markers="false" pn="section-5.6.1-2.1">
v=0
o=alice 2362969037 2362969040 IN IP4 192.0.2.156
s=Simulcast Enabled
s=Simulcast-Enabled Client
c=IN IP4 192.0.2.156
t=0 0
m=audio 49200 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 49300 RTP/AVP 97 98
a=rtpmap:97 H264/90000
a=rtpmap:98 H264/90000
a=fmtp:97 profile-level-id=42c01f;max-fs=3600;max-mbps=108000
a=fmtp:98 profile-level-id=42c00b;max-fs=240;max-mbps=3600
a=imageattr:97 send [x=1280,y=720] recv [x=1280,y=720]
a=imageattr:98 send [x=320,y=180] recv [x=320,y=180]
a=rid:1 send pt=97
a=rid:2 send pt=98
a=rid:3 recv pt=97
a=simulcast:send 1;2 recv 3
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
]]></artwork>
</sourcecode>
          </figure>

          <t>The
          <t indent="0" pn="section-5.6.1-3">The only thing in the SDP that indicates simulcast capability is
          the line in the video media description containing the "simulcast"
          attribute. The included "a=fmtp" and "a=imageattr" parameters
          indicates
          indicate that sent simulcast streams can differ in video
          resolution. The RTP header extension for RtpStreamId is offered to
          avoid issues with the initial binding between RTP streams (SSRCs)
          and the RtpStreamId identifying the simulcast stream and its
          format.</t>

          <t>The Answer
          <t indent="0" pn="section-5.6.1-4">The answer from the server indicates that it too it, too, is simulcast
          capable. Should it not have been simulcast capable, the
          "a=simulcast" line would not have been present present, and communication
          would have started with the media negotiated in the SDP. Also Also, the
          usage of the RtpStreamId RTP header extension is accepted.</t>
          <figure align="center" anchor="fig-up-answer"
                  title="Single-Source align="left" suppress-title="false" pn="figure-6">
            <name slugifiedName="name-single-source-simulcast-ans">Single-Source Simulcast Answer">
            <artwork align="left"><![CDATA[ Answer</name>
            <sourcecode type="sdp" markers="false" pn="section-5.6.1-5.1">
v=0
o=server 823479283 1209384938 IN IP4 192.0.2.2
s=Answer to Simulcast Enabled Simulcast-Enabled Client
c=IN IP4 192.0.2.43
t=0 0
m=audio 49672 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 49674 RTP/AVP 97 98
a=rtpmap:97 H264/90000
a=rtpmap:98 H264/90000
a=fmtp:97 profile-level-id=42c01f;max-fs=3600;max-mbps=108000
a=fmtp:98 profile-level-id=42c00b;max-fs=240;max-mbps=3600
a=imageattr:97 send [x=1280,y=720] recv [x=1280,y=720]
a=imageattr:98 send [x=320,y=180] recv [x=320,y=180]
a=rid:1 recv pt=97
a=rid:2 recv pt=98
a=rid:3 send pt=97
a=simulcast:recv 1;2 send 3
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
]]></artwork>
</sourcecode>
          </figure>

          <t>Since
          <t indent="0" pn="section-5.6.1-6">Since the server is the simulcast media receiver, it reverses the
          direction of the "simulcast" and "rid" attribute parameters.</t>
        </section>
        <section anchor="sec-ex-multi-source" title="Multi-Source Client">
          <t>Fred numbered="true" toc="include" removeInRFC="false" pn="section-5.6.2">
          <name slugifiedName="name-multisource-client">Multisource Client</name>
          <t indent="0" pn="section-5.6.2-1">Fred is calling in to the same conference as in the example above
          with a two-camera, two-display system, thus capable of handling two
          separate media sources in each direction, where each media source is
          simulcast-enabled
          simulcast enabled in the send "send" direction. Fred's client is restricted
          to a single media source per media description.</t>

          <t>The
          <t indent="0" pn="section-5.6.2-2">The first two simulcast streams for the first media source use
          different codecs, <xref target="RFC6190">H264-SVC</xref> target="RFC6190" format="default" sectionFormat="of" derivedContent="RFC6190">H264-SVC</xref> and <xref
          target="RFC6184">H264</xref>. target="RFC6184" format="default" sectionFormat="of" derivedContent="RFC6184">H264</xref>. These two simulcast streams also have
          a temporal dependency. Two different video codecs, <xref
          target="RFC7741">VP8</xref> target="RFC7741" format="default" sectionFormat="of" derivedContent="RFC7741">VP8</xref> and H264, are offered as alternatives
          for the third simulcast stream for the first media source. Only the
          highest fidelity
          highest-fidelity simulcast stream is sent from start, the lower
          fidelity
	  lower-fidelity streams being initially paused.</t>

          <t>The
          <t indent="0" pn="section-5.6.2-3">The second media source is offered with three different simulcast
          streams. All video streams of this second media source are loss
          protected by <xref target="RFC4588">RTP target="RFC4588" format="default" sectionFormat="of" derivedContent="RFC4588">RTP retransmission</xref>. Also
          here, In
	  addition, all but the highest fidelity highest-fidelity simulcast stream are
	  initially paused. Note that the lower resolution is more prioritized
	  than the
          medium resolution medium-resolution simulcast stream.</t>

          <t>Fred's
          <t indent="0" pn="section-5.6.2-4">Fred's client is also using BUNDLE to send all RTP streams from
          all media descriptions in the same RTP session on a single media
          transport. Although using many different simulcast streams in this
          example, the use of RtpStreamId as simulcast stream identification
          enables use of a low number of RTP payload types.

	  Note that the use
          of when using both <xref
          target="I-D.ietf-mmusic-sdp-bundle-negotiation">BUNDLE</xref> target="RFC8843" format="default" sectionFormat="of" derivedContent="RFC8843">BUNDLE</xref> and <xref target="I-D.ietf-mmusic-rid">"a=rid"</xref> recommends using target="RFC8851" format="default" sectionFormat="of" derivedContent="RFC8851">"a=rid"</xref>, it is recommended to use the <xref target="RFC8285">RTP RTP
	  header extension</xref> extension for the <xref target="RFC7941" format="default" sectionFormat="of" derivedContent="RFC7941">RTCP
	  source descriptions items</xref> for carrying
	  these RTP stream identification stream-identification fields, which is consequently also
	  included in the SDP.

Note also that for "a=rid",
	  the corresponding RtpStreamId SDES attribute RTP header extension is
	  named <xref
          target="I-D.ietf-avtext-rid">rtp-stream-id</xref>.</t> target="RFC8852" format="default" sectionFormat="of" derivedContent="RFC8852">rtp-stream-id</xref>.</t>
          <figure anchor="fig-ms-offer"
                  title="Fred's Multi-Source align="left" suppress-title="false" pn="figure-7">
            <name slugifiedName="name-freds-multisource-simulcast">Fred's Multisource Simulcast Offer">
            <artwork><![CDATA[ Offer</name>
            <sourcecode type="sdp" markers="false" pn="section-5.6.2-5.1">
v=0
o=fred 238947129 823479223 IN IP6 2001:db8::c000:27d
s=Offer from Simulcast Enabled Simulcast-Enabled Multi-Source Client
c=IN IP6 2001:db8::c000:27d
t=0 0
a=group:BUNDLE foo bar zen
m=audio 49200 RTP/AVP 99
a=mid:foo
a=rtpmap:99 G722/8000
m=video 49600 RTP/AVPF 100 101 103
a=mid:bar
a=rtpmap:100 H264-SVC/90000
a=rtpmap:101 H264/90000
a=rtpmap:103 VP8/90000
a=fmtp:100 profile-level-id=42400d;max-fs=3600;max-mbps=216000; \
    mst-mode=NI-TC
a=fmtp:101 profile-level-id=42c00d;max-fs=3600;max-mbps=108000
a=fmtp:103 max-fs=900; max-fr=30
a=rid:1 send pt=100;max-width=1280;max-height=720;max-fps=60;depend=2
a=rid:2 send pt=101;max-width=1280;max-height=720;max-fps=30
a=rid:3 send pt=101;max-width=640;max-height=360
a=rid:4 send pt=103;max-width=640;max-height=360
a=depend:100 lay bar:101
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=rtcp-fb:* ccm pause nowait
a=simulcast:send 1;2;~4,3
m=video 49602 RTP/AVPF 96 104
a=mid:zen
a=rtpmap:96 VP8/90000
a=fmtp:96 max-fs=3600; max-fr=30
a=rtpmap:104 rtx/90000
a=fmtp:104 apt=96;rtx-time=200
a=rid:1 send max-fs=921600;max-fps=30
a=rid:2 send max-fs=614400;max-fps=15
a=rid:3 send max-fs=230400;max-fps=30
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=rtcp-fb:* ccm pause nowait
a=simulcast:send 1;~3;~2
]]></artwork>
</sourcecode>
          </figure>
        </section>
        <section title="Simulcast numbered="true" toc="include" removeInRFC="false" pn="section-5.6.3">
          <name slugifiedName="name-simulcast-and-redundancy">Simulcast and Redundancy">
          <t>The Redundancy</name>
          <t indent="0" pn="section-5.6.3-1">The example in this section looks at applying simulcast with
          audio and video redundancy formats.

       The audio media description uses codec and bitrate restrictions, combining it
       combined with the <xref
          target="RFC2198">RTP Payload target="RFC2198" format="default" sectionFormat="of" derivedContent="RFC2198">RTP
       payload for Redundant Audio Data</xref> redundant audio data</xref> for enhanced packet loss packet-loss
       resilience. The video media description applies both resolution and
       bitrate restrictions, combining it combined with FEC Forward Error Correction (FEC)
       in the form of <xref
          target="I-D.ietf-payload-flexible-fec-scheme">Flexible target="RFC8627" format="default" sectionFormat="of" derivedContent="RFC8627">flexible
       FEC</xref> and <xref target="RFC4588">RTP Retransmission</xref>.</t>

          <t>The target="RFC4588" format="default" sectionFormat="of" derivedContent="RFC4588">RTP
       retransmission</xref>.</t>
          <t indent="0" pn="section-5.6.3-2">
	    The audio source is offered to be sent as two simulcast
	    streams. The first simulcast stream is encoded with Opus,
	    restricted to 50 64 kbps (rid-id=5), (rid-id=1), and the second simulcast stream
	    (rid-id=2) is encoded either with G.711 (rid-id=7) either G.711, or with G.711 combined with LPC
	    linear predictive coding (LPC) for redundancy
          (rid-id=6). and explicit comfort
	    noise (CN). Both simulcast streams include telephone-event
	    capability. In this example, stand-alone LPC is not offered as an a
	    possible payload type for the second simulcast stream's RID, which
	    could e.g. be motivated by by, for example, not providing sufficient quality.</t>

          <t>The
	    quality.
          </t>
          <t indent="0" pn="section-5.6.3-3">The video source is offered to be sent as two simulcast streams,
          both with two alternative simulcast formats. Redundancy and repair
          are offered in the form of both Flexible flexible FEC and RTP Retransmission. retransmission.
          The Flexible flexible FEC is not bound to any particular RTP streams and is
          therefore possible able to use be used across all RTP streams that are being sent
          as part of this media description.</t>
          <figure anchor="fig-sim-red"
                  title="Simulcast align="left" suppress-title="false" pn="figure-8">
            <name slugifiedName="name-simulcast-and-redundancy-ex">Simulcast and Redundancy Example">
            <artwork><![CDATA[v=0 Example</name>
            <sourcecode type="sdp" markers="false" pn="section-5.6.3-4.1">
o=fred 238947129 823479223 IN IP6 2001:db8::c000:27d
s=Offer from Simulcast Enabled Simulcast-Enabled Client using Redundancy
c=IN IP6 2001:db8::c000:27d
t=0 0
a=group:BUNDLE foo bar
m=audio 49200 RTP/AVP 97 98 99 100 101 102
a=mid:foo
a=rtpmap:97 G711/8000
a=rtpmap:98 LPC/8000
a=rtpmap:99 OPUS/48000/1
a=rtpmap:100 RED/8000/1
a=rtpmap:101 CN/8000
a=rtpmap:102 telephone-event/8000
a=fmtp:99 useinbandfec=1;usedtx=0
a=fmtp:100 97/98
a=fmtp:102 0-15
a=ptime:20
a=maxptime:40
a=rid:1 send pt=99,102;max-br=64000
a=rid:2 send pt=100,97,101,102
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=simulcast:send 1;2
m=video 49600 RTP/AVPF 103 104 105 106 107
a=mid:bar
a=rtpmap:103 H264/90000
a=rtpmap:104 VP8/90000
a=rtpmap:105 rtx/90000
a=rtpmap:106 rtx/90000
a=rtpmap:107 flexfec/90000
a=fmtp:103 profile-level-id=42c00d;max-fs=3600;max-mbps=108000
a=fmtp:104 max-fs=3600; max-fr=30
a=fmtp:105 apt=103;rtx-time=200
a=fmtp:106 apt=104;rtx-time=200
a=fmtp:107 repair-window=2000 repair-window=100000
a=rid:1 send pt=103;max-width=1280;max-height=720;max-fps=30
a=rid:2 send pt=104;max-width=1280;max-height=720;max-fps=30
a=rid:3 send pt=103;max-width=640;max-height=360;max-br=300000
a=rid:4 send pt=104;max-width=640;max-height=360;max-br=300000
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=rtcp-fb:* ccm pause nowait
a=simulcast:send 1,2;3,4
]]></artwork>
</sourcecode>
          </figure>

          <t/>
        </section>
      </section>
    </section>
    <section anchor="sec-rtp-aspects" title="RTP Aspects">
      <t>This numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-rtp-aspects">RTP Aspects</name>
      <t indent="0" pn="section-6-1">This section discusses what the different entities in a simulcast
      media path can expect to happen on the RTP level. This is explored from
      source to sink by starting in an endpoint with a media source that is
      simulcasted to an RTP middlebox. That RTP middlebox sends media sources
      both
      to other RTP middleboxes (cascaded middleboxes), as well as
      selecting some simulcast format of the media source and sending it to
      receiving endpoints. Different types of RTP middleboxes and their usage
      of the different simulcast formats results in several different
      behaviors.</t>
      <section title="Outgoing numbered="true" toc="include" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-outgoing-from-endpoint-with">Outgoing from Endpoint with Media Source">
        <t>The Source</name>
        <t indent="0" pn="section-6.1-1">The most straightforward simulcast case is the RTP streams being
        emitted from the endpoint that originates a media source. When
        simulcast has been negotiated in the sending direction, the endpoint
        can transmit up to the number of RTP streams needed for the negotiated
        simulcast streams for that media source. Each RTP stream (SSRC) is
        identified by <xref target="sec-relating">associating</xref> associating it (<xref target="sec-relating" format="default" sectionFormat="of" derivedContent="Section 5.5"/>) with
        an RtpStreamId SDES item, transmitted in RTCP and possibly also as an
        RTP header extension. In cases where multiple media sources have been
        negotiated for the same RTP session and thus <xref
        target="I-D.ietf-mmusic-sdp-bundle-negotiation">BUNDLE</xref> target="RFC8843" format="default" sectionFormat="of" derivedContent="RFC8843">BUNDLE</xref> is used,
        also the MID SDES item will also be sent
	sent, similarly to the RtpStreamId.</t>

        <t>Each
        <t indent="0" pn="section-6.1-2">Each RTP stream might not be continuously transmitted due to any of
        the following reasons; reasons: temporarily paused using <xref
        target="RFC7728">Pause/Resume</xref>, sender side target="RFC7728" format="default" sectionFormat="of" derivedContent="RFC7728">Pause/Resume</xref>, sender-side application logic
        temporarily pausing it, or lack of network resources to transmit this
        simulcast stream. However, all simulcast streams that have been
        negotiated have active and maintained SSRC SSRCs (at least in regular RTCP
        reports), even if no RTP packets are currently transmitted. The
        relation between an RTP Stream stream (SSRC) and a particular simulcast
        stream is not expected to change, except in exceptional situations
        such as SSRC collisions. At SSRC changes, the usage of MID and
        RtpStreamId should enable the receiver to correctly identify the RTP
        streams even after an SSRC change.</t>
      </section>
      <section title="RTP numbered="true" toc="include" removeInRFC="false" pn="section-6.2">
        <name slugifiedName="name-rtp-middlebox-to-receiver">RTP Middlebox to Receiver">
        <t>RTP Receiver</name>
        <t indent="0" pn="section-6.2-1">RTP streams in a multi-party multiparty RTP session can be used in multiple
        different ways, ways when the session utilizes simulcast at least on the
        media source to middlebox
        media-source-to-middlebox legs. This is to a large degree due to the
        different RTP middlebox behaviors, but also the needs of the
        application. This text assumes that the RTP middlebox will select a
        media source and choose which simulcast stream for that media source
        to deliver to a specific receiver. In many cases, at most one
        simulcast stream per media source will be forwarded to a particular
        receiver at any instant in time, even if the selected simulcast stream
        may vary. For cases where this does not hold due to application needs,
        then
        the RTP stream aspects will fall under the middlebox to middlebox middlebox-to-middlebox
        case <xref target="sec-rtp-box-box"/>.</t>

        <t>The (<xref target="sec-rtp-box-box" format="default" sectionFormat="of" derivedContent="Section 6.3"/>).</t>
        <t indent="0" pn="section-6.2-2">The selection of which simulcast streams to forward towards the
        receiver,
        receiver is application specific. However, in conferencing
        applications, active speaker selection is common. In case the number
        of media sources possible to forward, N, is less than the total amount number
        of media sources available in an multi-media a multimedia session, the current and
        previous speakers (up to N in total) are often the ones forwarded. To
        avoid the need for media specific media-specific processing to determine the current
        speaker(s) in the RTP middlebox, the endpoint providing a media source
        may include meta data, metadata, such as the <xref target="RFC6464">RTP Header
        Extension target="RFC6464" format="default" sectionFormat="of" derivedContent="RFC6464">RTP header
        extension for Client-to-Mixer Audio Level Indication</xref>.</t>

        <t>The client-to-mixer audio level indication</xref>.</t>
        <t indent="0" pn="section-6.2-3">The possibilities for stream switching are media type specific, but
        for media types with significant interframe dependencies in the
        encoding, like most video coding, the switching needs to be made at
        suitable switching points in the media stream that breaks or otherwise
        deals with the dependency structure. Even if switching points can be
        included periodically, it is common to use mechanisms like <xref
        target="RFC5104">Full target="RFC5104" format="default" sectionFormat="of" derivedContent="RFC5104">Full Intra Requests</xref> to request switching
        points from the endpoint performing the encoding of the media
        source.</t>

        <t>Inclusion
        <t indent="0" pn="section-6.2-4">Inclusion of the RtpStreamId SDES item for an SSRC in the middlebox
        to receiver
	middlebox-to-receiver direction should only occur when use of
	RtpStreamId has
        been negotiated in that direction. It is worth noting that one can
        signal multiple RtpStreamIds when simulcast signalling signaling indicates only
        a single simulcast stream, allowing one to use all of the RtpStreamIds
        as alternatives for that simulcast stream. One reason for including
        the RtpStreamId in the middlebox to receiver middlebox-to-receiver direction for an RTP
        stream is to let the receiver know which restrictions apply to the
        currently delivered RTP stream. In case the RtpStreamId is negotiated
        to be used, it is important to remember that the used identifiers will
        be specific to each signalling signaling session. Even if the central entity can
        attempt to coordinate, it is likely that the RtpStreamIds need to be
        translated to the leg specific leg-specific values. The below cases will have as
        base line assume
	that RtpStreamId is not used in the mixer to receiver
        direction.</t>
        <section title="Media-Switching Mixer">
          <t>This numbered="true" toc="include" removeInRFC="false" pn="section-6.2.1">
          <name slugifiedName="name-media-switching-mixer">Media-Switching Mixer</name>
          <t indent="0" pn="section-6.2.1-1">This section discusses the behavior in cases where the RTP
          middlebox behaves like the Media-Switching Mixer (Section 3.6.2) media-switching mixer in
          <xref target="RFC7667">RTP Topologies</xref>.
          RTP topologies (<xref target="RFC7667" sectionFormat="of" section="3.6.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7667#section-3.6.2" derivedContent="RFC7667"/>). The
	  fundamental aspect
          here is that the media sources delivered from the middlebox will be
          the mixer's conceptual or functional ones. For example, one media
          source may be the main speaker in high resolution high-resolution video, while a
          number of other media sources are thumbnails of each
          participant.</t>

          <t>The
          <t indent="0" pn="section-6.2.1-2">The above results in that the RTP stream produced by the mixer is being
          one that switches between a number of received incoming RTP streams
          for different media sources and in different simulcast versions. The
          mixer selects the media source to be sent as one of the RTP streams, streams
          and then selects among the available simulcast streams for the most
          appropriate one. The selection criteria include available bandwidth
          on the mixer to receiver mixer-to-receiver path and restrictions based on the
          functional usage of the RTP stream delivered to the receiver. As an
          example of the latter, it is unnecessary to forward a full HD video
          to a receiver if the display area is just a thumbnail. Thus,
          restrictions may exist to not allow some simulcast streams to be
          forwarded for some of the mixer's media sources.</t>

          <t>This
          <t indent="0" pn="section-6.2.1-3">This will result in a single RTP stream being used for each of
          the RTP mixer's media sources. This RTP stream is at At any point in
          time time, this RTP stream
	  is a selection of one particular RTP stream arriving to the mixer,
          where the RTP header field header-field values are rewritten to provide a
          consistent, single RTP stream. If the RTP mixer doesn't receive any
          incoming stream matched to this media source, the SSRC will not
          transmit,
          transmit but be kept alive using RTCP. The SSRC and thus RTP stream
          for the mixer's media source is expected to be long term long-term stable. It
          will only be changed by signalling signaling or other disruptive events. Note
          that although the above talks about a single RTP stream, there can
          in some cases be multiple RTP streams carrying the selected
          simulcast stream for the originating media source, including
          redundancy or other auxiliary RTP streams.</t>

          <t>The
          <t indent="0" pn="section-6.2.1-4">The mixer may communicate the identity of the originating media
          source to the receiver by including the CSRC Contributing Source (CSRC) field with the
          originating media source's SSRC value. Note that due to the
          possibility that the RTP mixer switches between simulcast versions
          of the media source, the CSRC value may change, even if the media
          source is kept the same.</t>

          <t>It
          <t indent="0" pn="section-6.2.1-5">It is important to note that any MID SDES item from the
          originating media source needs to be removed and not be associated
          with the RTP stream's SSRC. That is, there is nothing in the
          signalling
          signaling between the mixer and the receiver that is structured
          around the originating media sources, only the mixer's media
          sources. If they would be were associated with the SSRC, the receiver
          would likely believe that there has been an SSRC collision, collision and that
          the RTP stream is spurious as spurious, because it doesn't carry the identifiers used
          to relate it to the correct context. However, this is not true for
          CSRC values, as long as they are never used as an SSRC. In these cases cases,
          one could provide CNAME and MID as SDES items. A receiver could use
          this to determine which CSRC values that are associated with the
          same originating media source.</t>

          <t>If
          <t indent="0" pn="section-6.2.1-6">If RtpStreamIds are used in the scenario described by this
          section, it should be noted that the RtpStreamId on a particular
          SSRC will change based on the actual simulcast stream selected for
          switching. These RtpStreamId identifiers will be local to this leg's
          signalling
          signaling context. In addition, the defined RtpStreamIds and their
          parameters need to cover all the media sources and simulcast streams
          received by the RTP mixer that can be switched into this media
          source, sent by the RTP mixer.</t>
        </section>
        <section title="Selective numbered="true" toc="include" removeInRFC="false" pn="section-6.2.2">
          <name slugifiedName="name-selective-forwarding-middle">Selective Forwarding Middlebox">
          <t>This Middlebox</name>
          <t indent="0" pn="section-6.2.2-1">This section discusses the behavior in cases where the RTP
          middlebox behaves like the Selective Forwarding Middlebox (Section
          3.7) in <xref target="RFC7667">RTP Topologies</xref>. RTP
	  topologies (<xref target="RFC7667" sectionFormat="of" section="3.7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7667#section-3.7" derivedContent="RFC7667"/>). Applications
          for this type of RTP middlebox results result in that each originating
          media source will have having a corresponding media source on the leg
          between the middlebox and the receiver. A Selective Forwarding
          Middlebox (SFM) could go as far as exposing all the simulcast
          streams for an a media source, however source; however, this section will focus on
          having a single simulcast stream that can contain any of the
          simulcast formats. This section will assume that the SFM projection
          mechanism works on media source level, the media-source level and maps one of the media
          source's simulcast streams onto one RTP stream from the SFM to the
          receiver.</t>

          <t>This
          <t indent="0" pn="section-6.2.2-2">This usage will result in that the individual RTP stream(s) for
          one media source can being able to switch between being active to and
	  paused, based on
          the subset of media sources the SFM wants to provide the receiver
          for the moment. With SFMs SFMs, there exist no reasons to use CSRC to
          indicate the originating stream, as there is a one to one media
          source one-to-one
	  media-source mapping. If the application requires knowing the
	  simulcast
          version received to function well, then RtpStreamId should be
          negotiated on the SFM to receiver leg. Which simulcast stream that
          is being forwarded is not made explicit unless RtpStreamId is used
          on the leg.</t>

          <t>Any
          <t indent="0" pn="section-6.2.2-3">Any MID SDES items being sent by the SFM to the receiver are only
          those agreed between the SFM and the receiver, and no MID values
          from the originating side of the SFM are to be forwarded.</t>

          <t>A
          <t indent="0" pn="section-6.2.2-4">An SFM could expose corresponding RTP streams for all the media
          sources and their simulcast streams, streams and then then, for any media source
          that is to be provided provided, forward one selected simulcast stream.
          However, this is not recommended recommended, as it would unnecessarily increase
          the number of RTP streams and require the receiver to timely detect
          switching between simulcast streams. The above usage requires the
          same SFM functionality for switching, while avoiding the
          uncertainties of timely detecting that a an RTP stream ends. The
          benefit would be that the received simulcast stream would be
          implicitly provided by which RTP stream would be active for a media
          source. However, using RtpStreamId to make this explicit also
          exposes which alternative format is used. The conclusion is that
          using one RTP stream per simulcast stream is unnecessary. The issue
          with timely detecting end of streams, independent if of whether they are
          stopped temporarily or long term, is that there is no explicit
          indication that the transmission has intentionally been stopped. The
          RTCP based
          RTCP-based <xref target="RFC7728">Pause target="RFC7728" format="default" sectionFormat="of" derivedContent="RFC7728">pause and Resume resume
	  mechanism</xref>
          includes a PAUSED indication that provides the last RTP sequence
          number transmitted prior to the pause. Due to usage, the timeliness
          of this solution depends on when delivery using RTCP can occur in
          relation to the transmission of the last RTP packet. If no explicit
          information is provided at all, then detection based on non
          increasing
	  nonincreasing RTCP SR field values and timers need to be used to
          determine pause in RTP packet delivery. This results in that one can
          usually not determine As a result, when the last
	  RTP packet arrives (if it
          arrives) arrives), one usually
	  cannot determine that this will be the last. That it was the last is
          something that one learns later.</t>
        </section>
      </section>
      <section anchor="sec-rtp-box-box" title="RTP numbered="true" toc="include" removeInRFC="false" pn="section-6.3">
        <name slugifiedName="name-rtp-middlebox-to-rtp-middle">RTP Middlebox to RTP Middlebox">
        <t>This Middlebox</name>
        <t indent="0" pn="section-6.3-1">This relates to the transmission of simulcast streams between RTP
        middleboxes or other usages where one wants to enable the delivery of
        multiple simultaneous simulcast streams per media source, but the
        transmitting entity is not the originating endpoint. For a particular
        direction between middlebox middleboxes A and B, this looks very similar to the
        originating to middlebox
        originating-to-middlebox case on a media source media-source basis. However, in
        this case case, there is are usually multiple media sources, originating from
        multiple endpoints. This can create situations where limitations in
        the number of simultaneously received media streams can arise, arise -- for
        example
        example, due to limitation in network bandwidth. In this case, a subset
        of not only the simulcast streams, streams but also media sources can be
        selected. This results in that As a result, individual RTP streams can be become
        paused at any point and later being be resumed based on various criteria.</t>

        <t>The
        <t indent="0" pn="section-6.3-2">The MIDs used between A and B are the ones agreed between these two
        identities in signalling. signaling. The RtpStreamId values will also be provided
        to ensure explicit information about which simulcast stream they are.
        The RTP stream to MID RTP-stream-to-MID and RtpStreamId -RtpStreamId associations should here be long
        term
	long-term stable.</t>
      </section>
    </section>
    <section anchor="sec-network-aspects" title="Network Aspects">
      <t>Simulcast numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-network-aspects">Network Aspects</name>
      <t indent="0" pn="section-7-1">Simulcast is in this memo defined as the act of sending multiple
      alternative encoded streams of the same underlying media
      source. When
      transmitting Transmitting multiple independent streams that originate from
      the same
      source, it
      source could potentially be done in several different ways using
      RTP. A general discussion on considerations for use of the different RTP
      multiplexing alternatives can be found in <xref
      target="I-D.ietf-avtcore-multiplex-guidelines">Guidelines target="RFC8872" format="default" sectionFormat="of" derivedContent="RFC8872">"Guidelines for Using the Multiplexing in RTP</xref>. Features of
      RTP to Support Multiple Media Streams"</xref>. Discussion and
      clarification on how to handle multiple streams in an RTP session can be
      found in <xref
      target="RFC8108"/>.</t>

      <t>The target="RFC8108" format="default" sectionFormat="of" derivedContent="RFC8108"/>.</t>
      <t indent="0" pn="section-7-2">The network aspects that are relevant for simulcast are:<list
          style="hanging">
          <t hangText="Quality of Service:">When are:</t>
      <dl newline="false" spacing="normal" indent="3" pn="section-7-3">
        <dt pn="section-7-3.1">Quality of Service (QoS):</dt>
        <dd pn="section-7-3.2">When using simulcast simulcast, it might be
          of interest to prioritize a particular simulcast stream, rather than
          applying equal treatment to all streams. For example, lower bitrate lower-bitrate
          streams may be prioritized over higher bitrate higher-bitrate streams to minimize
          congestion or packet losses in the low bitrate low-bitrate streams. Thus, there
          is a benefit to use using a simulcast solution with good QoS support.</t>

          <t hangText="NAT/FW Traversal:">Using support.</dd>
        <dt pn="section-7-3.3">NAT/FW Traversal (Network Address Translator / Firewall Traversal):</dt>
        <dd pn="section-7-3.4">Using multiple RTP sessions incurs
          more cost for NAT/FW traversal unless they can re-use reuse the same
          transport flow, which can be achieved by <xref
          target="I-D.ietf-mmusic-sdp-bundle-negotiation">Multiplexing
          Negotiation Using target="RFC8843" format="default" sectionFormat="of" derivedContent="RFC8843">multiplexing negotiation using SDP Port Numbers</xref>.</t>
        </list></t>

      <t/>

      <section title="Bitrate Adaptation">
        <t>Use port
	  numbers</xref>.</dd>
      </dl>
      <t indent="0" pn="section-7-4"/>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-bitrate-adaptation">Bitrate Adaptation</name>
        <t indent="0" pn="section-7.1-1">Use of multiple simulcast streams can require a significant amount
        of network resources. The aggregate bandwidth for all simulcast
        streams for a media source (and thus SDP media description) is bounded
        by any SDP "b=" line applicable to that media source. It is assumed
        that a suitable congestion control congestion-control mechanism is used by the
        application to ensure that it doesn't cause persistent congestion. If
        the amount of available network resources varies during an RTP session
        such that it does not match what is negotiated in SDP, the bitrate
        used by the different simulcast streams may have to be reduced
        dynamically. When a simulcasting media source uses a single media
        transport for all of the simulcast streams, it is likely that a joint
        congestion control across all simulcast streams is used for that media
        source. What simulcast streams to prioritize when allocating available
        bitrate among the simulcast streams in such adaptation SHOULD <bcp14>SHOULD</bcp14> be taken
        from the simulcast stream order on the "a=simulcast" line and ordering
        of alternative simulcast formats <xref target="sec-cap"/>. (<xref target="sec-cap" format="default" sectionFormat="of" derivedContent="Section 5.2"/>). Simulcast
        streams that have pause/resume capability and that would be given such
        low bitrate by the adaptation process that they are considered not
        really useful can be temporarily paused until the limiting condition
        clears.</t>
      </section>
    </section>
    <section anchor="sec-limitation" title="Limitation">
      <t>The numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-limitation">Limitation</name>
      <t indent="0" pn="section-8-1">The chosen approach has a limitation that relates to the use of a
      single RTP session for all simulcast formats of a media source, which
      comes from sending all simulcast streams related to a media source under
      the same SDP media description.</t>

      <t>It
      <t indent="0" pn="section-8-2">It is not possible to use different simulcast streams on different
      media transports, limiting which limits the possibilities to apply different for applying different QoS to
      different simulcast streams. When using unicast, QoS mechanisms based on
      individual packet marking are feasible, since they do not require
      separation of simulcast streams into different RTP sessions to apply
      different QoS.</t>

      <t>It
      <t indent="0" pn="section-8-3">It is also not possible to separate different simulcast streams into
      different multicast groups to allow a multicast receiver to pick the
      stream it wants, rather than receive all of them. In this case, the only
      reasonable implementation is to use different RTP sessions for each
      multicast group so that reporting and other RTCP functions operate as
      intended. Such simulcast usage in a multicast context is out of scope for
      the current document and would require additional specification.</t>
    </section>
    <section anchor="sec-iana" title="IANA Considerations">
      <t>This numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-9-1">This document requests to register registers a new media-level SDP attribute,
      "simulcast", in the "att-field (media level only)" registry within the
      SDP parameters
      "Session Description Protocol (SDP) Parameters" registry, according to the
      procedures of <xref
      target="RFC4566"/> and <xref
      target="I-D.ietf-mmusic-sdp-mux-attributes"/>.<list style="hanging">
          <t hangText="Contact target="RFC4566" format="default" sectionFormat="of" derivedContent="RFC4566"/> and <xref target="RFC8859" format="default" sectionFormat="of" derivedContent="RFC8859"/>.</t>
      <dl newline="false" spacing="normal" indent="3" pn="section-9-2">
        <dt pn="section-9-2.1">Contact name, email:">The email:</dt>
        <dd pn="section-9-2.2">The IESG (iesg@ietf.org)</t>

          <t hangText="Attribute name:">simulcast</t>

          <t hangText="Long-form (iesg@ietf.org)</dd>
        <dt pn="section-9-2.3">Attribute name:</dt>
        <dd pn="section-9-2.4">simulcast</dd>
        <dt pn="section-9-2.5">Long-form attribute name:">Simulcast stream
          description</t>

          <t hangText="Charset dependent:">No</t>

          <t hangText="Attribute value:">sc-value; name:</dt>
        <dd pn="section-9-2.6">Simulcast stream description</dd>
        <dt pn="section-9-2.7">Charset dependent:</dt>
        <dd pn="section-9-2.8">No</dd>
        <dt pn="section-9-2.9">Attribute value:</dt>
        <dd pn="section-9-2.10">sc-value; see <xref
          target="sec-attr"/> target="sec-attr" format="default" sectionFormat="of" derivedContent="Section 5.1"/> of RFC XXXX.</t>

          <t hangText="Purpose:">Signals
	8853.</dd>
        <dt pn="section-9-2.11">Purpose:</dt>
        <dd pn="section-9-2.12">Signals simulcast capability for a set of RTP
          streams</t>

          <t hangText="MUX category:">NORMAL</t>
        </list>Note to RFC Editor: Please replace "RFC XXXX" with the assigned
      number of this RFC.</t>
          streams</dd>
        <dt pn="section-9-2.13">Mux category:</dt>
        <dd pn="section-9-2.14">NORMAL</dd>
      </dl>
    </section>
    <section anchor="sec-security" title="Security Considerations">
      <t>The numbered="true" toc="include" removeInRFC="false" pn="section-10">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-10-1">The simulcast capability, configuration attributes, and parameters
      are vulnerable to attacks in signaling.</t>

      <t>A
      <t indent="0" pn="section-10-2">A false inclusion of the "a=simulcast" attribute may result in
      simultaneous transmission of multiple RTP streams that would otherwise
      not be generated. The impact is limited by the media description joint
      bandwidth, shared by all simulcast streams irrespective of their number.
      There
      However, there may however be a large number of unwanted RTP streams that will
      impact the share of bandwidth allocated for the originally wanted RTP
      stream.</t>

      <t>A
      <t indent="0" pn="section-10-3">A hostile removal of the "a=simulcast" attribute will result in
      simulcast not being used.</t>

      <t>Neither of the above will likely have any major consequences
      <t indent="0" pn="section-10-4">
	Integrity protection and source authentication of all SDP signaling,
	including simulcast attributes, can
      be mitigated by signaling mitigate the risks of such attacks
	that is at least integrity and source
      authenticated to prevent an attacker attempt to change it.</t>

      <t>Security alter signaling.
      </t>
      <t indent="0" pn="section-10-5">Security considerations related to the use of "a=rid" and the
      RtpStreamId SDES item is are covered in <xref target="I-D.ietf-mmusic-rid"/> target="RFC8851" format="default" sectionFormat="of" derivedContent="RFC8851"/>
      and <xref target="I-D.ietf-avtext-rid"/>. target="RFC8852" format="default" sectionFormat="of" derivedContent="RFC8852"/>. There are no additional
      security concerns related to their use in this specification.</t>
    </section>

    <section anchor="sec-contributors" title="Contributors">
      <t>Morgan Lindqvist and Fredrik Jansson, both from Ericsson, have
      contributed with important material to the first versions of this
      document. Robert Hansen and Cullen Jennings, from Cisco, Peter Thatcher,
      from Google, and Adam Roach, from Mozilla, contributed significantly to
      subsequent versions.</t>
    </section>

    <section anchor="sec-ack" title="Acknowledgements">
      <t>The authors would like to thank Bernard Aboba, Thomas Belling, Roni
      Even, Adam Roach, Inaki Baz Castillo, Paul Kyzivat, and Arun Arunachalam
      for the feedback they provided during the development of this
      document.</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

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

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

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

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

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

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

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

      <?rfc include='reference.I-D.ietf-avtext-rid'?>

      <?rfc include='reference.I-D.ietf-mmusic-sdp-mux-attributes'?>

      <?rfc include='reference.I-D.ietf-mmusic-sdp-bundle-negotiation'?>
    </references> pn="section-11">
      <name slugifiedName="name-references">References</name>
      <references title="Informative References">
      <?rfc include='reference.RFC.2198'?>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      <?rfc include='reference.I-D.ietf-payload-flexible-fec-scheme'?>
    </references>

    <section anchor="sec-requirements" title="Requirements">
      <t>The following requirements are met by the defined solution pn="section-11.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 support
      the <xref target="sec-use-cases">use cases</xref>:<list style="hanging">
          <t anchor="req-1" hangText="REQ-1:">Identification:<list
              style="hanging"> Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t anchor="req-1.1" hangText="REQ-1.1:">It must be possible indent="0">In many standards track documents several words are used to
              identify a set of simulcasted RTP streams as originating from signify the same media source requirements in SDP signaling.</t>

              <t anchor="req-1.2" hangText="REQ-1.2:">An RTP endpoint must the specification.  These words are often capitalized. This document defines these words as they should be
              capable of identifying interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the simulcast stream 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="RFC3264" target="https://www.rfc-editor.org/info/rfc3264" quoteTitle="true" derivedAnchor="RFC3264">
          <front>
            <title>An Offer/Answer Model with Session Description Protocol (SDP)</title>
            <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2002" month="June"/>
            <abstract>
              <t indent="0">This document defines a received RTP
              stream is associated with, knowing mechanism by which two entities can make use of the content Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them.  In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective.  This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session.  The offer/answer model is used by protocols like the Session Initiation Protocol (SIP).  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3264"/>
          <seriesInfo name="DOI" value="10.17487/RFC3264"/>
        </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="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
              signalling.</t>
            </list></t> 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="RFC5234" target="https://www.rfc-editor.org/info/rfc5234" quoteTitle="true" derivedAnchor="RFC5234">
          <front>
            <title>Augmented BNF for Syntax Specifications: ABNF</title>
            <author initials="D." surname="Crocker" fullname="D. Crocker" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Overell" fullname="P. Overell">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="January"/>
            <abstract>
              <t indent="0">Internet technical specifications often need to define a formal syntax.  Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications.  The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power.  The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges.  This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="68"/>
          <seriesInfo name="RFC" value="5234"/>
          <seriesInfo name="DOI" value="10.17487/RFC5234"/>
        </reference>
        <reference anchor="RFC7405" target="https://www.rfc-editor.org/info/rfc7405" quoteTitle="true" derivedAnchor="RFC7405">
          <front>
            <title>Case-Sensitive String Support in ABNF</title>
            <author initials="P." surname="Kyzivat" fullname="P. Kyzivat">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2014" month="December"/>
            <abstract>
              <t indent="0">This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7405"/>
          <seriesInfo name="DOI" value="10.17487/RFC7405"/>
        </reference>
        <reference anchor="RFC7728" target="https://www.rfc-editor.org/info/rfc7728" quoteTitle="true" derivedAnchor="RFC7728">
          <front>
            <title>RTP Stream Pause and Resume</title>
            <author initials="B." surname="Burman" fullname="B. Burman">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Akram" fullname="A. Akram">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Even" fullname="R. Even">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Westerlund" fullname="M. Westerlund">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="February"/>
            <abstract>
              <t indent="0">With the increased popularity of real-time multimedia applications, it is desirable to provide good control of resource usage, and users also demand more control over communication sessions.  This document describes how a receiver in a multimedia conversation can pause and resume incoming data from a sender by sending real-time feedback messages when using the Real-time Transport Protocol (RTP) for real- time data transport.  This document extends the Codec Control Message (CCM) RTP Control Protocol (RTCP) feedback package by explicitly allowing and describing specific use of existing CCMs and adding a group of new real-time feedback messages used to pause and resume RTP data streams.  This document updates RFC 5104.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7728"/>
          <seriesInfo name="DOI" value="10.17487/RFC7728"/>
        </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="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="RFC8851" target="https://www.rfc-editor.org/info/rfc8851" quoteTitle="true" derivedAnchor="RFC8851">
          <front>
            <title>RTP Payload Format Restrictions</title>
            <author initials="A.B." surname="Roach" fullname="Adam Roach" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8851"/>
          <seriesInfo name="DOI" value="10.17487/RFC8851"/>
        </reference>
        <reference anchor="RFC8852" target="https://www.rfc-editor.org/info/rfc8852" quoteTitle="true" derivedAnchor="RFC8852">
          <front>
            <title>RTP Stream Identifier Source Description (SDES)</title>
            <author initials="A.B." surname="Roach" fullname="Adam Roach"/>
            <author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar"/>
            <author initials="P" surname="Thatcher" fullname="Peter Thatcher"/>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8852"/>
          <seriesInfo name="DOI" value="10.17487/RFC8852"/>
        </reference>
        <reference anchor="RFC8859" target="https://www.rfc-editor.org/info/rfc8859" quoteTitle="true" derivedAnchor="RFC8859">
          <front>
            <title>A Framework for Session Description Protocol (SDP) Attributes When Multiplexing</title>
            <author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8859"/>
          <seriesInfo name="DOI" value="10.17487/RFC8859"/>
        </reference>
      </references>
      <references pn="section-11.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC2198" target="https://www.rfc-editor.org/info/rfc2198" quoteTitle="true" derivedAnchor="RFC2198">
          <front>
            <title>RTP Payload for Redundant Audio Data</title>
            <author initials="C." surname="Perkins" fullname="C. Perkins">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="I." surname="Kouvelas" fullname="I. Kouvelas">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="O." surname="Hodson" fullname="O. Hodson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="V." surname="Hardman" fullname="V. Hardman">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Handley" fullname="M. Handley">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J.C." surname="Bolot" fullname="J.C. Bolot">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Vega-Garcia" fullname="A. Vega-Garcia">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Fosse-Parisis" fullname="S. Fosse-Parisis">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="September"/>
            <abstract>
              <t indent="0">This document describes a payload format for use with the real-time transport protocol (RTP), version 2, for encoding redundant audio data. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2198"/>
          <seriesInfo name="DOI" value="10.17487/RFC2198"/>
        </reference>
        <reference anchor="RFC3389" target="https://www.rfc-editor.org/info/rfc3389" quoteTitle="true" derivedAnchor="RFC3389">
          <front>
            <title>Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)</title>
            <author initials="R." surname="Zopf" fullname="R. Zopf">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2002" month="September"/>
          </front>
          <seriesInfo name="RFC" value="3389"/>
          <seriesInfo name="DOI" value="10.17487/RFC3389"/>
        </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="RFC4733" target="https://www.rfc-editor.org/info/rfc4733" quoteTitle="true" derivedAnchor="RFC4733">
          <front>
            <title>RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals</title>
            <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Taylor" fullname="T. Taylor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="December"/>
            <abstract>
              <t indent="0">This memo describes how to carry dual-tone multifrequency (DTMF) signalling, other tone signals, and telephony events in RTP packets. It obsoletes RFC 2833.</t>
              <t indent="0">This memo captures and expands upon the basic framework defined in RFC 2833, but retains only the most basic event codes.  It sets up an IANA registry to which other event code assignments may be added. Companion documents add event codes to this registry relating to modem, fax, text telephony, and channel-associated signalling events. The remainder of the event codes defined in RFC 2833 are conditionally reserved in case other documents revive their use.</t>
              <t anchor="req-2" hangText="REQ-2:">Transport usage. indent="0">This document provides a number of clarifications to the original document.  However, it specifically differs from RFC 2833 by removing the requirement that all compliant implementations support the DTMF events.  Instead, compliant implementations taking part in out-of-band negotiations of media stream content indicate what events they support.  This memo adds three new procedures to the RFC 2833 framework: subdivision of long events into segments, reporting of multiple events in a single packet, and the concept and reporting of state events.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4733"/>
          <seriesInfo name="DOI" value="10.17487/RFC4733"/>
        </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="RFC5109" target="https://www.rfc-editor.org/info/rfc5109" quoteTitle="true" derivedAnchor="RFC5109">
          <front>
            <title>RTP Payload Format for Generic Forward Error Correction</title>
            <author initials="A." surname="Li" fullname="A. Li" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2007" month="December"/>
            <abstract>
              <t indent="0">This document specifies a payload format for generic Forward Error Correction (FEC) for media data encapsulated in RTP.  It is based on the exclusive-or (parity) operation.  The solution
          must payload format described in this document allows end systems to apply protection using various protection lengths and levels, in addition to using various protection group sizes to adapt to different media and channel characteristics. It enables complete recovery of the protected packets or partial recovery of the critical parts of the payload depending on the packet loss situation.  This scheme is completely compatible with non-FEC-capable hosts, so the receivers in a multicast group that do not implement FEC can still work when using:<list style="hanging"> by simply ignoring the protection data.  This specification obsoletes RFC 2733 and RFC 3009.  The FEC specified in this document is not backward compatible with RFC 2733 and RFC 3009.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5109"/>
          <seriesInfo name="DOI" value="10.17487/RFC5109"/>
        </reference>
        <reference anchor="RFC5583" target="https://www.rfc-editor.org/info/rfc5583" quoteTitle="true" derivedAnchor="RFC5583">
          <front>
            <title>Signaling Media Decoding Dependency in the Session Description Protocol (SDP)</title>
            <author initials="T." surname="Schierl" fullname="T. Schierl">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Wenger" fullname="S. Wenger">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2009" month="July"/>
            <abstract>
              <t anchor="req-2.1" hangText="REQ-2.1:">Legacy SDP indent="0">This memo defines semantics that allow for signaling the decoding dependency of different media descriptions with separate the same media transports per SDP type in the Session Description Protocol (SDP).  This is required, for example, if media description.</t>

              <t anchor="req-2.2" hangText="REQ-2.2:"><xref
              target="I-D.ietf-mmusic-sdp-bundle-negotiation">Bundled</xref>
              SDP data is separated and transported in different network streams as a result of the use of a layered or multiple descriptive media descriptions.</t>
            </list></t> coding process.</t>
              <t anchor="req-3" hangText="REQ-3:">Capability negotiation. It must indent="0">A new grouping type "DDP" -- decoding dependency -- is defined, to be possible that:<list style="hanging">
              <t anchor="req-3.1" hangText="REQ-3.1:">Sender can express
              capability used in conjunction with RFC 3388 entitled "Grouping of sending simulcast.</t> Media Lines in the Session Description Protocol".  In addition, an attribute is specified describing the relationship of the media streams in a "DDP" group indicated by media identification attribute(s) and media format description(s).  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5583"/>
          <seriesInfo name="DOI" value="10.17487/RFC5583"/>
        </reference>
        <reference anchor="RFC6184" target="https://www.rfc-editor.org/info/rfc6184" quoteTitle="true" derivedAnchor="RFC6184">
          <front>
            <title>RTP Payload Format for H.264 Video</title>
            <author initials="Y.-K." surname="Wang" fullname="Y.-K. Wang">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Even" fullname="R. Even">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Kristensen" fullname="T. Kristensen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Jesup" fullname="R. Jesup">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="May"/>
            <abstract>
              <t anchor="req-3.2" hangText="REQ-3.2:">Receiver can express
              capability indent="0">This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec, excluding the Scalable Video Coding (SVC) extension and the Multiview Video Coding extension, for which the RTP payload formats are defined elsewhere. The RTP payload format allows for packetization of receiving simulcast.</t> one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload.  The payload format has wide applicability, as it supports applications from simple low bitrate conversational usage, to Internet video streaming with interleaved transmission, to high bitrate video-on-demand.</t>
              <t anchor="req-3.3" hangText="REQ-3.3:">Sender can express
              maximum number indent="0">This memo obsoletes RFC 3984.  Changes from RFC 3984 are summarized in Section 14.  Issues on backward compatibility to RFC 3984 are discussed in Section 15.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6184"/>
          <seriesInfo name="DOI" value="10.17487/RFC6184"/>
        </reference>
        <reference anchor="RFC6190" target="https://www.rfc-editor.org/info/rfc6190" quoteTitle="true" derivedAnchor="RFC6190">
          <front>
            <title>RTP Payload Format for Scalable Video Coding</title>
            <author initials="S." surname="Wenger" fullname="S. Wenger">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Y.-K." surname="Wang" fullname="Y.-K. Wang">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Schierl" fullname="T. Schierl">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Eleftheriadis" fullname="A. Eleftheriadis">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="May"/>
            <abstract>
              <t indent="0">This memo describes an RTP payload format for Scalable Video Coding (SVC) as defined in Annex G of ITU-T Recommendation H.264, which is technically identical to Amendment 3 of ISO/IEC International Standard 14496-10.  The RTP payload format allows for packetization of simulcast streams that can be provided.</t>

              <t anchor="req-3.4" hangText="REQ-3.4:">Receiver can express
              maximum number one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of simulcast streams that can be received.</t>

              <t anchor="req-3.5" hangText="REQ-3.5:">Sender can detail the
              characteristics a NAL unit in multiple RTP packets. Furthermore, it supports transmission of an SVC stream over a single as well as multiple RTP sessions.  The payload format defines a new media subtype name "H264-SVC", but is still backward compatible to RFC 6184 since the simulcast streams that can be
              provided.</t>

              <t anchor="req-3.6" hangText="REQ-3.6:">Receiver can detail base layer, when encapsulated in its own RTP stream, must use the
              characteristics H.264 media subtype name ("H264") and the packetization method specified in RFC 6184.  The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6190"/>
          <seriesInfo name="DOI" value="10.17487/RFC6190"/>
        </reference>
        <reference anchor="RFC6236" target="https://www.rfc-editor.org/info/rfc6236" quoteTitle="true" derivedAnchor="RFC6236">
          <front>
            <title>Negotiation of Generic Image Attributes in the simulcast streams that it prefers to
              receive.</t>
            </list></t> Session Description Protocol (SDP)</title>
            <author initials="I." surname="Johansson" fullname="I. Johansson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Jung" fullname="K. Jung">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="May"/>
            <abstract>
              <t anchor="req-4" hangText="REQ-4:">Distinguishing features. It must
          be indent="0">This document proposes a new generic session setup attribute to make it possible to have different simulcast streams use negotiate different codec
          parameters, image attributes such as can be expressed by SDP format values and RTP payload
          types.</t>

          <t anchor="req-5" hangText="REQ-5:">Compatibility. It must be image size.  A possible to use simulcast in combination with other RTP mechanisms case is to make it possible for a \%low-end \%hand- held terminal to display video without the need to rescale the image, something that generate additional RTP streams:<list style="hanging">
              <t anchor="req-5.1" hangText="REQ-5.1:"><xref
              target="RFC4588">RTP Retransmission</xref>.</t>

              <t anchor="req-5.2" hangText="REQ-5.2:"><xref
              target="RFC5109">RTP Forward Error Correction</xref>.</t>

              <t anchor="req-5.3" hangText="REQ-5.3:">Related payload types
              such may consume large amounts of memory and processing power.  The document also helps to maintain an optimal bitrate for video as audio Comfort Noise and/or DTMF.</t> only the image size that is desired by the receiver is transmitted.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6236"/>
          <seriesInfo name="DOI" value="10.17487/RFC6236"/>
        </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 hangText="REQ-5.4:">A single simulcast stream indent="0">This document defines a mechanism by which packets of Real-time Transport Protocol (RTP) audio streams can consist indicate, in an RTP header extension, the audio level of
              multiple the audio sample carried in the RTP streams, to support codecs where a dependent stream
              is dependent packet.  In large conferences, this can reduce the load on an audio mixer or other middlebox that wants to forward only a set few of encoded and dependent the loudest audio streams, each
              potentially carried 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="RFC7104" target="https://www.rfc-editor.org/info/rfc7104" quoteTitle="true" derivedAnchor="RFC7104">
          <front>
            <title>Duplication Grouping Semantics in their own RTP stream.</t>
            </list></t> the Session Description Protocol</title>
            <author initials="A." surname="Begen" fullname="A. Begen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Y." surname="Cai" fullname="Y. Cai">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Ou" fullname="H. Ou">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2014" month="January"/>
            <abstract>
              <t anchor="req-6" hangText="REQ-6:">Interoperability. The solution
          must indent="0">Packet loss is undesirable for real-time multimedia sessions, but it can occur due to congestion or other unplanned network outages.  This is especially true for IP multicast networks, where packet loss patterns can vary greatly between receivers.  One technique that can be possible used to use in:<list style="hanging">
              <t anchor="req-6.1" hangText="REQ-6.1:">Interworking with
              non-simulcast legacy clients using a single media source per
              media type.</t>

              <t anchor="req-6.2" hangText="REQ-6.2:">WebRTC environment with
              a single media source per SDP media description.</t>
            </list></t>
        </list></t>
    </section>

    <section title="Changes From Earlier Versions">
      <t>NOTE TO RFC EDITOR: Please remove this section prior recover from packet loss without incurring unbounded delay for all the receivers is to
      publication.</t>

      <section title="Modifications Between WG Version -13 and -14">
        <t><list style="symbols">
            <t>c= duplicate the packets and t= line order corrected send them in SDP examples</t>
          </list></t>
      </section>

      <section title="Modifications Between WG Version -12 and -13">
        <t><list style="symbols">
            <t>Examples corrected to follow RID ABNF</t>

            <t>Example <xref target="fig-ms-offer"/> now comments on priority separate redundant streams.  This document defines the semantics for second media source.</t>

            <t>Clarified a SHOULD limitation.</t>

            <t>Added urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id grouping redundant streams in
            examples with RTX.</t>

            <t>ABNF now uses RFC 7405 to indicate case sensitivity</t>

            <t>Various minor editorials and nits.</t>
          </list></t>
      </section>

      <section title="Modifications Between WG Version -11 and -12">
        <t><list style="symbols">
            <t>Modified Normative statement regarding RTP stream duplication the Session Description Protocol (SDP). The semantics defined in Section 5.2.</t>

            <t>Clarified assumption about use of congestion control by
            applications.</t>

            <t>Changed this document are to use RFC 8174 boilerplate instead of RFC 2119.</t>

            <t>Clarified explanation be used with the SDP Grouping Framework.  Grouping semantics at the Synchronization Source (SSRC) level are also defined in this document for RTP streams using SSRC multiplexing.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7104"/>
          <seriesInfo name="DOI" value="10.17487/RFC7104"/>
        </reference>
        <reference anchor="RFC7656" target="https://www.rfc-editor.org/info/rfc7656" quoteTitle="true" derivedAnchor="RFC7656">
          <front>
            <title>A Taxonomy of syntax Semantics and Mechanisms for simulcast attribute in
            Section 4.</t>

            <t>Editorial clarification in Section 5.2 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 5.3.2.</t>

            <t>Various minor editorials associations among, Real-time Transport Protocol (RTP) sources can be complex and nits.</t>
          </list></t>
      </section>

      <section title="Modifications Between WG Version -10 and -11">
        <t><list style="symbols">
            <t>Added new SDP example section on Simulcast somewhat opaque.  This document describes a number of existing and Redundancy,
            including both RED (RFC2198), RTP RTX (RFC4588), proposed properties and FEC
            (draft-ietf-payload-flexible-fec-scheme).</t>

            <t>Removed restriction that "related" payload formats in an relationships among RTP
            stream (such as CN sources and defines common terminology for discussing protocol entities and DTMF) must not have their own rid-id, since
            there is no reason to forbid this relationships.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7656"/>
          <seriesInfo name="DOI" value="10.17487/RFC7656"/>
        </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 corresponding clarification
            is made multi-endpoint topologies used in draft-ietf-mmusic-rid.</t>

            <t>Removed any mention of source-specific signaling and environments based on the
            reference to RFC5576, since draft-ietf-mmusic-rid is not defined
            for source-specific signaling.</t>

            <t>Changed some SDP examples to use a=rid restrictions instead of
            a=imageattr.</t>

            <t>Changed reference from Real-time Transport Protocol (RTP). In particular, centralized topologies commonly employed in the obsoleted RFC 5285 video conferencing industry are mapped to RFC 8285.</t>
          </list></t>
      </section>

      <section title="Modifications Between WG Version -09 and -10">
        <t><list style="symbols">
            <t>Amended overview section with a bit more explanation on the
            examples, and added RTP terminology.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7667"/>
          <seriesInfo name="DOI" value="10.17487/RFC7667"/>
        </reference>
        <reference anchor="RFC7741" target="https://www.rfc-editor.org/info/rfc7741" quoteTitle="true" derivedAnchor="RFC7741">
          <front>
            <title>RTP Payload Format for VP8 Video</title>
            <author initials="P." surname="Westin" fullname="P. Westin">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Lundin" fullname="H. Lundin">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Glover" fullname="M. Glover">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Uberti" fullname="J. Uberti">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="F." surname="Galligan" fullname="F. Galligan">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="March"/>
            <abstract>
              <t indent="0">This memo describes an rid-id alternative RTP payload format for one of the
            streams.</t>

            <t>Removed SCID also from the Terminology section, which was
            forgotten in -09 when changing SCID to rid-id.</t>
          </list></t>
      </section>

      <section title="Modifications Between WG Version -08 and -09">
        <t><list style="symbols">
            <t>Changed SCID to rid-id, to align with ietf-draft-mmusic-rid
            naming.</t>

            <t>Changed Overview to be based on examples and shortened it.</t>

            <t>Changed semantics of initially paused rid-id in modified SDP
            offers from requiring VP8 video codec. The payload format has wide applicability, as it supports applications from low-bitrate peer-to-peer usage to follow actual RFC 7728 pause state to
            an informational offerer's opinion at high-bitrate video conferences.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7741"/>
          <seriesInfo name="DOI" value="10.17487/RFC7741"/>
        </reference>
        <reference anchor="RFC7941" target="https://www.rfc-editor.org/info/rfc7941" quoteTitle="true" derivedAnchor="RFC7941">
          <front>
            <title>RTP Header Extension for the time of offer creation,
            not RTP Control Protocol (RTCP) Source Description Items</title>
            <author initials="M." surname="Westerlund" fullname="M. Westerlund">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Burman" fullname="B. Burman">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Even" fullname="R. Even">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Zanaty" fullname="M. Zanaty">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="August"/>
            <abstract>
              <t indent="0">Source Description (SDES) items are normally transported in any way overriding or amending RFC 7728 signaling.</t>

            <t>Replaced text on ignoring all but the first RTP Control Protocol (RTCP).  In some cases, it can be beneficial to speed up the delivery of multiple
            "a=simulcast" lines in a media description with mandating that at
            most one "a=simulcast" line is included.</t>

            <t>Clarified with a note that, for the these items.  The main case it is clear from the
            SDP that RTP PT uniquely maps to RtpStreamId, when a new synchronization source (SSRC) joins an RTP receiver can
            use RTP PT to relate simulcast streams.</t>

            <t>Moved Section 4 Requirements to become Appendix A.</t>

            <t>Editorial corrections session and clarifications.</t>
          </list></t>
      </section>

      <section title="Modifications Between WG Version -07 and -08">
        <t><list style="symbols">
            <t>Correcting syntax of SDP examples in section 6.6.1, as found by
            Inaki Baz Castillo.</t>

            <t>Changing ABNF to only define the sc-value, not the SDP
            attribute itself, as suggested by Paul Kyzivat.</t>

            <t>Changing I-D reference receivers need this source's identity, relation to newly published RFC 8108.</t>

            <t>Adding list other sources, or its synchronization context, all of modifications between -06 which may be fully or partially identified using SDES items.  To enable this optimization, this document specifies a new RTP header extension that can carry SDES items.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7941"/>
          <seriesInfo name="DOI" value="10.17487/RFC7941"/>
        </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 -07.</t>
          </list></t>
      </section>

      <section title="Modifications Between WG Version -06 and -07">
        <t><list style="symbols">
            <t>A scope clarification, as result of clarifies the discussion with Roni
            Even.</t>

            <t>A reformulation behavior of the identification requirements Real-time Transport Protocol (RTP) endpoints that use multiple synchronization sources (SSRCs).  This occurs, for
            simulcast stream.</t>

            <t>Correcting the statement related to source specific signalling
            (RFC 5576) to address Roni Even's comment.</t>

            <t>Update of the last paragraph in Section 6.2 regarding simulcast
            stream differences as well as forbidding example, when an endpoint sends multiple instances of the
            same SCID within RTP streams in a single a=simulcast line.</t>

            <t>Removal of note in Section 6.4 as result of issue raised by
            Roni Even.</t>

            <t>Use of "m=" has been changed RTP session.  This memo updates RFC 3550 with regard to media description and a few
            other editorial improvements and clarifications.</t>
          </list></t>
      </section>

      <section title="Modifications Between WG Version -05 and -06">
        <t><list style="symbols">
            <t>Added section on handling multiple SSRCs per endpoint in RTP Aspects</t>

            <t>Added sessions, with a requirement (5-4) particular focus on that capability exchange must be
            capable of handling multi RTP stream cases.</t>

            <t>Added extmap attribute Control Protocol (RTCP) behavior.  It also on first signalling example as it
            is a recommended updates RFC 4585 to use mechanism.</t>

            <t>Clarified change and clarify the definition calculation of the simulcast attribute timeout of SSRCs and how
            simulcast streams relates to simulcast the inclusion of feedback messages.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8108"/>
          <seriesInfo name="DOI" value="10.17487/RFC8108"/>
        </reference>
        <reference anchor="RFC8627" target="https://www.rfc-editor.org/info/rfc8627" quoteTitle="true" derivedAnchor="RFC8627">
          <front>
            <title>RTP Payload Format for Flexible Forward Error Correction (FEC)</title>
            <author initials="M." surname="Zanaty" fullname="M. Zanaty">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="V." surname="Singh" fullname="V. Singh">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Begen" fullname="A. Begen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Mandyam" fullname="G. Mandyam">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2019" month="July"/>
            <abstract>
              <t indent="0">This document defines new RTP payload formats and SCIDs.</t>

            <t>Updated References list and moved around some references
            between informative and normative categories.</t>

            <t>Editorial improvements and corrections.</t>
          </list></t>
      </section>

      <section title="Modifications Between WG Version -04 and -05">
        <t><list style="symbols">
            <t>Aligned with recent changes in draft-ietf-mmusic-rid and
            draft-ietf-avtext-rid.</t>

            <t>Modified for the SDP offer/answer section to follow Forward Error Correction (FEC) packets that are generated by the generally
            accepted structure, also adding non-interleaved and interleaved parity codes from source media encapsulated in RTP. These parity codes are systematic codes (Flexible FEC, or "FLEX                         FEC"), where a brief text on modifying number of FEC repair packets are generated from a set of source packets from one or more source RTP streams.  These FEC repair packets are sent in a redundancy RTP stream separate from the
            session source RTP stream(s) that is aligned with draft-ietf-mmusic-rid.</t>

            <t>Improved text around simulcast stream identification (as
            opposed to carries the simulcast stream itself) to consistently use source packets.  RTP source packets that were lost in transmission can be reconstructed using the
            acronym SCID source and defined repair packets that were received.  The non-interleaved and interleaved parity codes that are defined in the Terminology section.</t>

            <t>Changed references for RTP-level pause/resume this specification offer a good protection against random and VP8 bursty packet losses, respectively, at a cost of complexity.  The RTP payload
            format formats that are now published as RFC.</t>

            <t>Improved IANA registration text.</t>

            <t>Removed unused reference to
            draft-ietf-payload-flexible-fec-scheme.</t>

            <t>Editorial improvements defined in this document address scalability issues experienced with the earlier specifications and corrections.</t>
          </list></t>
      </section>

      <section title="Modifications Between WG Version -03 and -04">
        <t><list style="symbols">
            <t>Changed offer several improvements.  Due to only use RID identification, as was consensus during
            IETF 94.</t>

            <t>ABNF improvements.</t>

            <t>Clarified offer-answer rules for initially paused streams.</t>

            <t>Changed references these changes, the new payload formats are not backward compatible with earlier specifications; however, endpoints that do not implement this specification can still work by simply ignoring the FEC repair packets.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8627"/>
          <seriesInfo name="DOI" value="10.17487/RFC8627"/>
        </reference>
        <reference anchor="RFC8872" target="https://www.rfc-editor.org/info/rfc8872" quoteTitle="true" derivedAnchor="RFC8872">
          <front>
            <title>Guidelines for Using the Multiplexing Features of RTP topologies and RTP taxonomy
            documents that to Support Multiple Media Streams</title>
            <author initials="M" surname="Westerlund" fullname="Magnus Westerlund">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B" surname="Burman" fullname="Bo Burman">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C" surname="Perkins" fullname="Colin Perkins">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H" surname="Alvestrand" fullname="Harald Alvestrand">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R" surname="Even" fullname="Roni Even">
      </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8872"/>
          <seriesInfo name="DOI" value="10.17487/RFC8872"/>
        </reference>
      </references>
    </references>
    <section anchor="sec-requirements" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-requirements">Requirements</name>
      <t indent="0" pn="section-appendix.a-1">The following requirements are now published as RFC.</t>

            <t>Added reference to met by the new RID draft in AVTEXT.</t>

            <t>Re-structured section 6 defined solution to provide an easy reference by support
      the
            updated IANA section.</t>

            <t>Added a sub-section 7.1 with <xref target="sec-use-cases" format="default" sectionFormat="of" derivedContent="Section 3">use cases</xref>:</t>
      <dl newline="false" spacing="normal" indent="3" pn="section-appendix.a-2">
        <dt pn="section-appendix.a-2.1">REQ-1:</dt>
        <dd anchor="req-1" pn="section-appendix.a-2.2">
          <t indent="0" pn="section-appendix.a-2.2.1">Identification:</t>
          <dl newline="false" spacing="normal" indent="3" pn="section-appendix.a-2.2.2">
            <dt pn="section-appendix.a-2.2.2.1">REQ-1.1:</dt>
            <dd anchor="req-1.1" pn="section-appendix.a-2.2.2.2">It must be possible to
              identify a discussion set of bitrate
            adaptation.</t>

            <t>Editorial improvements.</t>
          </list></t>
      </section>

      <section title="Modifications Between WG Version -02 and -03">
        <t><list style="symbols">
            <t>Removed text on multicast / broadcast simulcasted RTP streams as originating from use cases, since it
            is not supported by
              the solution.</t>

            <t>Removed explicit references to unified plan draft.</t>

            <t>Added possibility to initiate simulcast streams same media source in paused
            mode.</t>

            <t>Enabled an offerer to offer multiple stream identification (pt
            or rid) methods and have SDP signaling.</dd>
            <dt pn="section-appendix.a-2.2.2.3">REQ-1.2:</dt>
            <dd anchor="req-1.2" pn="section-appendix.a-2.2.2.4">An RTP endpoint must be
              capable of identifying the answerer choose which to use.</t>

            <t>Added a preference indication also in send direction
            offers.</t>

            <t>Added simulcast stream that a section on limitations of received RTP
              stream is associated with, knowing the current proposal,
            including identification method specific limitations.</t>
          </list></t>
      </section>

      <section title="Modifications Between WG Version -01 and -02">
        <t><list style="symbols">
            <t>Relying on content of the new RID SDP
              signaling.</dd>
          </dl>
        </dd>
        <dt pn="section-appendix.a-2.3">REQ-2:</dt>
        <dd anchor="req-2" pn="section-appendix.a-2.4">
          <t indent="0" pn="section-appendix.a-2.4.1">Transport usage. The solution for codec constraints and
            configuration identification. This has resulted in changes in
            syntax to identify if pt or RID is used to describe
          must work when using:</t>
          <dl newline="false" spacing="normal" indent="3" pn="section-appendix.a-2.4.2">
            <dt pn="section-appendix.a-2.4.2.1">REQ-2.1:</dt>
            <dd anchor="req-2.1" pn="section-appendix.a-2.4.2.2">Legacy SDP with separate
              media transports per SDP media description.</dd>
            <dt pn="section-appendix.a-2.4.2.3">REQ-2.2:</dt>
            <dd anchor="req-2.2" pn="section-appendix.a-2.4.2.4">
              <xref target="RFC8843" format="default" sectionFormat="of" derivedContent="RFC8843">Bundled</xref>
              SDP media descriptions.</dd>
          </dl>
        </dd>
        <dt pn="section-appendix.a-2.5">REQ-3:</dt>
        <dd anchor="req-3" pn="section-appendix.a-2.6">
          <t indent="0" pn="section-appendix.a-2.6.1">Capability negotiation. The
	  following must be possible:</t>
          <dl newline="false" spacing="normal" indent="3" pn="section-appendix.a-2.6.2">
            <dt pn="section-appendix.a-2.6.2.1">REQ-3.1:</dt>
            <dd anchor="req-3.1" pn="section-appendix.a-2.6.2.2">The sender can express
              capability of sending simulcast.</dd>
            <dt pn="section-appendix.a-2.6.2.3">REQ-3.2:</dt>
            <dd anchor="req-3.2" pn="section-appendix.a-2.6.2.4">The receiver can express
              capability of receiving simulcast.</dd>
            <dt pn="section-appendix.a-2.6.2.5">REQ-3.3:</dt>
            <dd anchor="req-3.3" pn="section-appendix.a-2.6.2.6">The sender can express
	      the maximum number of simulcast
            stream.</t>

            <t>Renamed streams that can be
	      provided.</dd>
            <dt pn="section-appendix.a-2.6.2.7">REQ-3.4:</dt>
            <dd anchor="req-3.4" pn="section-appendix.a-2.6.2.8">The receiver can express the
              maximum number of simulcast version and streams that can be received.</dd>
            <dt pn="section-appendix.a-2.6.2.9">REQ-3.5:</dt>
            <dd anchor="req-3.5" pn="section-appendix.a-2.6.2.10">The sender can detail the
              characteristics of the simulcast version alternative to streams that can be
              provided.</dd>
            <dt pn="section-appendix.a-2.6.2.11">REQ-3.6:</dt>
            <dd anchor="req-3.6" pn="section-appendix.a-2.6.2.12">The receiver can detail the
              characteristics of the simulcast stream and streams that it prefers to
              receive.</dd>
          </dl>
        </dd>
        <dt pn="section-appendix.a-2.7">REQ-4:</dt>
        <dd anchor="req-4" pn="section-appendix.a-2.8">Distinguishing features. It must
          be possible to have different simulcast streams use different codec
          parameters, as can be expressed by SDP format respectively, values and improved
            definitions for them.</t>

            <t>Clarification that it is RTP payload
          types.</dd>
        <dt pn="section-appendix.a-2.9">REQ-5:</dt>
        <dd anchor="req-5" pn="section-appendix.a-2.10">
          <t indent="0" pn="section-appendix.a-2.10.1">Compatibility. It must be
          possible to switch between use simulcast
            version alternatives, but that only a single one be used at any
            point in time.</t>

            <t>Changed the definition so combination with other RTP mechanisms
          that ordering of generate additional RTP streams:</t>
          <dl newline="false" spacing="normal" indent="3" pn="section-appendix.a-2.10.2">
            <dt pn="section-appendix.a-2.10.2.1">REQ-5.1:</dt>
            <dd anchor="req-5.1" pn="section-appendix.a-2.10.2.2">
              <xref target="RFC4588" format="default" sectionFormat="of" derivedContent="RFC4588">RTP retransmission</xref>.</dd>
            <dt pn="section-appendix.a-2.10.2.3">REQ-5.2:</dt>
            <dd anchor="req-5.2" pn="section-appendix.a-2.10.2.4">
              <xref target="RFC5109" format="default" sectionFormat="of" derivedContent="RFC5109">RTP Forward Error Correction</xref>.</dd>
            <dt pn="section-appendix.a-2.10.2.5">REQ-5.3:</dt>
            <dd anchor="req-5.3" pn="section-appendix.a-2.10.2.6">Related payload types
              such as audio Comfort Noise and/or DTMF.</dd>
            <dt pn="section-appendix.a-2.10.2.7">REQ-5.4:</dt>
            <dd pn="section-appendix.a-2.10.2.8">A single simulcast formats
            for stream can consist of
              multiple RTP streams, to support codecs where a specific simulcast dependent stream do have
              is dependent on a preference order.</t>
          </list></t> set of encoded and dependent streams, each
              potentially carried in their own RTP stream.</dd>
          </dl>
        </dd>
        <dt pn="section-appendix.a-2.11">REQ-6:</dt>
        <dd anchor="req-6" pn="section-appendix.a-2.12">
          <t indent="0" pn="section-appendix.a-2.12.1">Interoperability. The solution
          must be possible to use in:</t>
          <dl newline="false" spacing="normal" indent="3" pn="section-appendix.a-2.12.2">
            <dt pn="section-appendix.a-2.12.2.1">REQ-6.1:</dt>
            <dd anchor="req-6.1" pn="section-appendix.a-2.12.2.2">Interworking with
              nonsimulcast legacy clients using a single media source per
              media type.</dd>
            <dt pn="section-appendix.a-2.12.2.3">REQ-6.2:</dt>
            <dd anchor="req-6.2" pn="section-appendix.a-2.12.2.4">WebRTC environment with
              a single media source per SDP media description.</dd>
          </dl>
        </dd>
      </dl>
    </section>
    <section title="Modifications Between WG Version -00 and -01">
        <t><list style="symbols">
            <t>No changes. Only preventing expiry.</t>
          </list></t> anchor="sec-ack" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.b-1">The authors would like to thank <contact fullname="Bernard Aboba"/>, <contact fullname="Thomas Belling"/>, <contact fullname="Roni Even"/>, <contact fullname="Adam Roach"/>, <contact fullname="Iñaki Baz Castillo"/>,
      <contact fullname="Paul Kyzivat"/>, and <contact fullname="Arun       Arunachalam"/> for the feedback they provided during the development of
      this document.</t>
    </section>
    <section title="Modifications Between Individual Version -00 and WG Version -00">
        <t><list style="symbols">
            <t>Added anchor="sec-contributors" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.c">
      <name slugifiedName="name-contributors">Contributors</name>
      <t indent="0" pn="section-appendix.c-1"><contact fullname="Morgan Lindqvist"/> and <contact fullname="Fredrik       Jansson"/>, both from Ericsson, have contributed with important material
      to the first draft versions of this appendix.</t>
          </list></t> document. <contact fullname="Robert       Hanton"/> and <contact fullname="Cullen Jennings"/> from Cisco, <contact fullname="Peter Thatcher"/> from Google, and <contact fullname="Adam       Roach"/> from Mozilla contributed significantly to subsequent
      versions.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.d">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Bo Burman" initials="B." surname="Burman">
        <organization showOnFrontPage="true">Ericsson</organization>
        <address>
          <postal>
            <street>Gronlandsgatan 31</street>
            <city>SE-164 60 Stockholm</city>
            <region/>
            <code/>
            <country>Sweden</country>
          </postal>
          <phone/>
          <email>bo.burman@ericsson.com</email>
          <uri/>
        </address>
      </author>
      <author fullname="Magnus Westerlund" initials="M." surname="Westerlund">
        <organization showOnFrontPage="true">Ericsson</organization>
        <address>
          <postal>
            <street>Torshamnsgatan 23</street>
            <city>SE-164 83 Stockholm</city>
            <country>Sweden</country>
          </postal>
          <email>magnus.westerlund@ericsson.com</email>
        </address>
      </author>
      <author fullname="Suhas Nandakumar" initials="S." surname="Nandakumar">
        <organization showOnFrontPage="true">Cisco</organization>
        <address>
          <postal>
            <street>170 West Tasman Drive</street>
            <city>San Jose</city>
            <region>CA</region>
            <code>95134</code>
            <country>United States of America</country>
          </postal>
          <phone/>
          <email>snandaku@cisco.com</email>
          <uri/>
        </address>
      </author>
      <author fullname="Mo Zanaty" initials="M." surname="Zanaty">
        <organization showOnFrontPage="true">Cisco</organization>
        <address>
          <postal>
            <street>170 West Tasman Drive</street>
            <city>San Jose</city>
            <region>CA</region>
            <code>95134</code>
            <country>United States of America</country>
          </postal>
          <phone/>
          <email>mzanaty@cisco.com</email>
          <uri/>
        </address>
      </author>
    </section>
  </back>
</rfc>