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

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-mmusic-sdp-simulcast-14"
     ipr="trust200902" submissionType="IETF"> submissionType="IETF" number="8853" consensus="true"
     obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="true"
     sortRefs="true" version="3" docName="draft-ietf-mmusic-sdp-simulcast-14">

  <!-- xml2rfc v2v3 conversion 2.31.0 -->
  <front>
    <title abbrev="Simulcast">Using Simulcast in SDP Session Description Protocol (SDP) and RTP Sessions</title>

    <seriesInfo name="RFC" value="8853"/>
    <author fullname="Bo Burman" initials="B." surname="Burman">
      <organization>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>
      <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>
      <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>
      <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"/> month="May" year="2020"/>

<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>

      <t>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>
  </front>
  <middle>
    <section anchor="sec-intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>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 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">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 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 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"> numbered="true" toc="default">
      <name>Definitions</name>
      <section numbered="true" toc="default">
        <name>Terminology</name>
        <t>This document makes use of the terminology defined in <xref
        target="RFC7656">RTP Taxonomy</xref>,
	target="RFC7656" format="default">"A Taxonomy of Semantics and
	Mechanisms for Real-Time
	Transport Protocol (RTP) Sources"</xref> and <xref target="RFC7667">RTP
        Topologies</xref>. target="RFC7667"
	format="default">"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">
          <dt>RTP mixer:</dt>
          <dd>An RTP middle node, defined middlebox, in the wide sense of the term, encompassing
          Sections <xref target="RFC7667" section="3.6" sectionFormat="bare"/>
          to <xref target="RFC7667" section="3.9" sectionFormat="bare"/> of
          <xref
            target="RFC7667"/> (Section 3.6 to 3.9).</t>

            <t hangText="RTP Session:">An target="RFC7667" format="default"/>.</dd>
          <dt>RTP session:</dt>
          <dd>An association among a group of
            participants communicating with RTP, as defined in <xref
            target="RFC3550"/> target="RFC3550" format="default"/> and amended by <xref target="RFC7656"/>.</t>

            <t hangText="RTP Stream:">A target="RFC7656" format="default"/>.</dd>
          <dt>RTP stream:</dt>
          <dd>A stream of RTP packets containing media
            data, as defined in <xref target="RFC7656"/>.</t>

            <t hangText="RTP Switch:">A target="RFC7656" format="default"/>.</dd>
          <dt>RTP switch:</dt>
          <dd>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"/>.</dd>
          <dt>Simulcast stream:</dt>
          <dd>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"/>. 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>Simulcast format:</dt>
          <dd>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">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="default">
        <name>Requirements Language</name>
        <t>
    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 BCP&nbsp;14 <xref target="RFC2119"/> target="RFC2119" format="default"/> <xref target="RFC8174"/>
    target="RFC8174" format="default"/>
    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"> numbered="true" toc="default">
      <name>Use Cases</name>
      <t>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 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">
        <li>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>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>
          mixer.</li>
      </ul>
      <t>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="default">
        <name>Reaching a Diverse Set of Receivers"> Receivers</name>
        <t>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">
          <dt>Codec:</dt>
          <dd>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>Sampling:</dt>
          <dd>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>Bitrate:</dt>
          <dd>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>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 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 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="default">
        <name>Application-Specific Media Source Handling"> Handling</name>
        <t>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 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"/>)
        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"> numbered="true" toc="default">
        <name>Receiver Media-Source Preferences</name>
        <t>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"/>.
        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"> numbered="true" toc="default">
      <name>Overview</name>
      <t>This memo defines <xref target="RFC4566">SDP</xref> target="RFC4566" format="default">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> target="sec-requirements" format="default"/>.</t>

      <t>The RID Restriction Identifier (RID) mechanism, as defined in <xref
      target="I-D.ietf-mmusic-rid"/>, target="RFC8851" format="default"/>, 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 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"/>.</t>
      <!-- DO NOT EDIT -->
<sourcecode type="sdp">
a=simulcast:send 1;2,3 recv 4
]]></artwork>
      </figure>
</sourcecode>
      <!-- End DNE -->
      <t>If the above 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 more complete example SDP offer SDP-offer media description is provided
      below:</t>
      in <xref target="fig-md-offer" format="default"/>.</t>
      <!-- DO NOT EDIT -->

      <figure align="center" anchor="fig-md-offer"
              title="Example anchor="fig-md-offer">
        <name>Example Simulcast Media Description in Offer">
        <artwork align="left"><![CDATA[ Offer</name>
<sourcecode type="sdp">
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>
      <!-- End DNE -->
      <t>The above SDP media description in <xref target="fig-md-offer" format="default"/> 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 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
      <!-- DO NOT EDIT -->
<sourcecode type="sdp">
a=simulcast:recv 1;2 send 4
]]></artwork>
      </figure>
</sourcecode>
      <!-- End DNE -->
      <t>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"/>.</t>
      <!-- DO NOT EDIT -->
      <figure align="center" anchor="fig-md-answer"
              title="Example anchor="fig-md-answer">
        <name>Example Simulcast Media Description in Answer">
        <artwork align="left"><![CDATA[ Answer</name>
<sourcecode type="sdp">
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>
      <!-- End DNE -->
      <t>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"/> 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> descriptions <xref target="RFC8843" format="default"/>.</t>
      <t>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"/>. 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"/>. A detailed specification can be found in
      <xref target="sec-details"/> target="sec-details" format="default"/>, and more detailed examples are outlined in
      <xref target="sec-ex"/>.</t> target="sec-ex" format="default"/>.</t>
    </section>
    <section anchor="sec-details" title="Detailed Description"> numbered="true" toc="default">
      <name>Detailed Description</name>
      <t>This section provides further details to the overview in <xref
      target="sec-overview">above</xref>. target="sec-overview" format="default"/>. First, formal syntax is <xref
      target="sec-attr">provided</xref>, target="sec-attr" format="default">provided</xref>, followed by the rest of the SDP
      attribute definition in <xref target="sec-cap"/>. target="sec-cap" format="default"/>. <xref
      target="sec-relating">Relating target="sec-relating" format="default">"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"> numbered="true" toc="default">
        <name>Simulcast Attribute</name>
        <t>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"/>, which uses <xref target="RFC5234" format="default">ABNF</xref> and its update for update, <xref
        target="RFC7405">Case-Sensitive target="RFC7405" format="default">"Case-Sensitive String Support in ABNF</xref>:</t> ABNF"</xref>:</t>

        <!-- DO NOT EDIT -->
        <figure align="center" anchor="fig-abnf"
                title="ABNF anchor="fig-abnf">
          <name>ABNF for Simulcast Value">
          <artwork align="center"><![CDATA[ Value</name>
<sourcecode type="abnf">
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>
        <!-- End DNE -->
        <t>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">"RTP Payload Format
        Restrictions</xref>.</t> Restrictions"</xref>.</t>
        <t>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">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"> numbered="true" toc="default">
        <name>Simulcast Capability</name>
        <t>Simulcast capability is expressed through a new media level media-level <xref
        target="sec-attr">SDP target="sec-attr" format="default">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 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 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 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>rid-ids that have explicit <xref
        target="RFC5583">dependencies</xref> target="RFC5583"
        format="default">dependencies</xref> <xref
        target="I-D.ietf-mmusic-rid"/> target="RFC8851"
        format="default"/> to other rid-id rid-ids (even in the same media
        description) MAY <bcp14>MAY</bcp14> be used.</t>

	<t>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> streams.
	</t>

        <t>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">Comfort Noise</xref> and/or <xref target="RFC4733">DTMF</xref> formats.</t>
        target="RFC4733" format="default">dual-tone multifrequency
        (DTMF)</xref>.</t>

        <t>If <xref target="RFC7728">RTP target="RFC7728" format="default">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"/> -- e.g., by using the "*" wildcard format for
        "a=rtcp-fb".</t>
        <t>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">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">RtpStreamId RTCP SDES
	item</xref>.</t>

        <t>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" />); this is because the RTP
	receiver's SSRC
        in send the "send" direction is sometimes not yet known.</t>
        <t>Use of the <xref target="RFC2198">redundant redundant audio data</xref> data format <xref target="RFC2198" format="default"/>
	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 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"/> 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="default">
        <name>Offer/Answer Use</name>
<dl>
<dt>Note:</dt> <dd>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="default">
          <name>Generating the Initial SDP Offer"> Offer</name>
          <t>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="default">
          <name>Creating the SDP Answer"> Answer</name>
          <t>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"/>. 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 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 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 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 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 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 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="default">
          <name>Offerer Processing the SDP Answer"> Answer</name>
          <t>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 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 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> rid-ids.</t>
          <t>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 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="default">
          <name>Modifying the Session"> Session</name>
          <t>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">
            <li>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"/> in the ongoing
	      session SHALL <bcp14>SHALL</bcp14> take precedence in case of any conflict or ambiguity.</t>

              <t>rid-id
	      ambiguity.</li>
            <li>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">RTP stream pause/resume</xref> signaling
              , signaling,
	      this is identical to the conditions at an initial offer.</t>
            </list></t> offer.</li>
          </ol>
          <t>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 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">"RTP Payload Format
	  Restrictions"</xref>
          also apply.</t>
        </section>
      </section>
      <section title="Use numbered="true" toc="default">
        <name>Use with Declarative SDP"> SDP</name>
        <t>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">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="default">
        <name>Relating Simulcast Streams"> Streams</name>
        <t>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">RtpStreamId</xref>, as specified in the
        SDP <xref target="sec-cap">"a=simulcast" target="sec-cap" format="default">"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">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">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">
          <dt>NOTE:</dt>
          <dd>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> extensions.</dd>
        </dl>
        <t>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"> numbered="true" toc="default">
        <name>Signaling Examples</name>
        <t>These examples describe a client to video conference client-to-video-conference service, using
        a centralized media topology with an RTP mixer.</t>
        <!-- DO NOT EDIT -->
        <figure align="center" anchor="fig-mixer-four-party"
                title="Four-party Mixer-based Conference"> anchor="fig-mixer-four-party">
          <name>Four-Party Mixer-Based Conference</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
+---+      +-----------+      +---+
| A |<---->|           |<---->| B |
+---+      |           |      +---+
           |   Mixer   |
+---+      |           |      +---+
| F |<---->|           |<---->| J |
+---+      +-----------+      +---+]]></artwork>
        </figure>
        <!-- End DNE -->
        <section anchor="sec-ex-single-source" title="Single-Source Client"> numbered="true" toc="default">
          <name>Single-Source Client</name>
          <t>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">"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 anchor="fig-up-offer">
            <name>Single-Source Simulcast Offer">
            <artwork align="left"><![CDATA[ Offer</name>
<sourcecode type="sdp">
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>
          <!-- End DNE -->
          <t>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 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>
          <!-- DO NOT EDIT -->
          <figure align="center" anchor="fig-up-answer"
                  title="Single-Source anchor="fig-up-answer">
            <name>Single-Source Simulcast Answer">
            <artwork align="left"><![CDATA[ Answer</name>
<sourcecode type="sdp">
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>
          </figure>
</sourcecode></figure>
          <!-- End DNE -->
          <t>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"> numbered="true" toc="default">
          <name>Multisource Client</name>
          <t>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 first two simulcast streams for the first media source use
          different codecs, <xref target="RFC6190">H264-SVC</xref> target="RFC6190" format="default">H264-SVC</xref> and <xref
          target="RFC6184">H264</xref>. target="RFC6184" format="default">H264</xref>. These two simulcast streams also have
          a temporal dependency. Two different video codecs, <xref
          target="RFC7741">VP8</xref> target="RFC7741" format="default">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 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">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 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">BUNDLE</xref> and <xref target="I-D.ietf-mmusic-rid">"a=rid"</xref> recommends using target="RFC8851"
	  format="default">"a=rid"</xref>, it is recommended to use the <xref target="RFC8285">RTP RTP
	  header extension</xref> extension for carrying
          these RTP stream identification the <xref target="RFC7941" format="default">RTCP
	  source descriptions items</xref> for carrying
	  these RTP 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">rtp-stream-id</xref>.</t>
          <!-- DO NOT EDIT -->
          <figure anchor="fig-ms-offer"
                  title="Fred's Multi-Source anchor="fig-ms-offer">
            <name>Fred's Multisource Simulcast Offer">
            <artwork><![CDATA[ Offer</name>
<sourcecode type="sdp">
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>
          <!-- End DNE -->
        </section>
        <section title="Simulcast numbered="true" toc="default">
          <name>Simulcast and Redundancy"> Redundancy</name>
          <t>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">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">flexible
       FEC</xref> and <xref target="RFC4588">RTP Retransmission</xref>.</t>

          <t>The target="RFC4588" format="default">RTP
       retransmission</xref>.</t>

	  <t>
	    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>
	    quality.
	  </t>

          <t>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>
          <!-- DO NOT EDIT -->
          <figure anchor="fig-sim-red"
                  title="Simulcast anchor="fig-sim-red">
            <name>Simulcast and Redundancy Example">
            <artwork><![CDATA[v=0 Example</name>
<sourcecode type="sdp">
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/>
          <!-- End DNE -->

        </section>
      </section>
    </section>
    <section anchor="sec-rtp-aspects" title="RTP Aspects"> numbered="true" toc="default">
      <name>RTP Aspects</name>
      <t>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="default">
        <name>Outgoing from Endpoint with Media Source"> Source</name>
        <t>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"/>) 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">BUNDLE</xref> is used,
        also the MID SDES item will also be sent
	sent, similarly to the RtpStreamId.</t>
        <t>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">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="default">
        <name>RTP Middlebox to Receiver"> Receiver</name>
        <t>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> (<xref target="sec-rtp-box-box" format="default"/>).</t>
        <t>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 for Client-to-Mixer Audio Level Indication</xref>.</t> target="RFC6464" format="default">RTP header
        extension for client-to-mixer audio level indication</xref>.</t>
        <t>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">Full Intra Requests</xref> to request switching
        points from the endpoint performing the encoding of the media
        source.</t>
        <t>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"> numbered="true" toc="default">
          <name>Media-Switching Mixer</name>
          <t>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"/>). 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 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 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 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 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 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="default">
          <name>Selective Forwarding Middlebox"> Middlebox</name>
          <t>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"/>). 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 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 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>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 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">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="default">
        <name>RTP Middlebox to RTP Middlebox"> Middlebox</name>
        <t>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 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"> numbered="true" toc="default">
      <name>Network Aspects</name>
      <t>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="I-D.ietf-avtcore-multiplex-guidelines" format="default">"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> target="RFC8108" format="default"/>.</t>
      <t>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">
        <dt>Quality of Service (QoS):</dt>
        <dd>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>NAT/FW Traversal (Network Address Translator / Firewall Traversal):</dt>
        <dd>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">multiplexing negotiation using SDP Port Numbers</xref>.</t>
        </list></t> port
	  numbers</xref>.</dd>
      </dl>
      <t/>
      <section title="Bitrate Adaptation"> numbered="true" toc="default">
        <name>Bitrate Adaptation</name>
        <t>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"/>). 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"> numbered="true" toc="default">
      <name>Limitation</name>
      <t>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 is not possible to use different simulcast streams on different
      media transports, limiting which limits the possibilities to apply 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 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"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>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"/> target="RFC4566" format="default"/> and <xref
      target="I-D.ietf-mmusic-sdp-mux-attributes"/>.<list style="hanging">
          <t hangText="Contact target="RFC8859" format="default"/>.</t>
      <dl newline="false" spacing="normal">
        <dt>Contact name, email:">The email:</dt>
        <dd>The IESG (iesg@ietf.org)</t>

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

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

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

          <t hangText="Attribute value:">sc-value; description</dd>
        <dt>Charset dependent:</dt>
        <dd>No</dd>
        <dt>Attribute value:</dt>
        <dd>sc-value; see <xref
          target="sec-attr"/> target="sec-attr" format="default"/> of RFC XXXX.</t>

          <t hangText="Purpose:">Signals
	8853.</dd>
        <dt>Purpose:</dt>
        <dd>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>Mux category:</dt>
        <dd>NORMAL</dd>
      </dl>
    </section>
    <section anchor="sec-security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The simulcast capability, configuration attributes, and parameters
      are vulnerable to attacks in signaling.</t>
      <t>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 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>
	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> alter signaling.
      </t>
      <t>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"/>
      and <xref target="I-D.ietf-avtext-rid"/>. target="RFC8852" format="default"/>. 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'?>

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

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include
	    href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3264.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4566.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7405.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7728.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

<!-- draft-ietf-mmusic-rid in C238 -->
        <reference anchor="RFC8851" target="https://www.rfc-editor.org/info/rfc8851">
          <front>
            <title>RTP Payload Format Restrictions</title>
            <author initials="A.B." surname="Roach" fullname="Adam Roach" role="editor">
              <organization/>
            </author>
            <date month="April" year="2020"/>
          </front>
            <seriesInfo name="DOI" value="10.17487/RFC8851"/>
            <seriesInfo name="RFC" value="8851"/>
        </reference>

<!-- draft-ietf-avtext-rid-09 in C238 -->
        <reference anchor="RFC8852" target="https://www.rfc-editor.org/info/rfc8852">
          <front>
            <title>RTP Stream Identifier Source Description (SDES)</title>
            <author initials="A.B." surname="Roach" fullname="Adam Roach">
              <organization/>
            </author>
            <author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar">
              <organization/>
            </author>
            <author initials="P" surname="Thatcher" fullname="Peter Thatcher">
              <organization/>
            </author>
            <date month="April" year="2020"/>
          </front>
            <seriesInfo name="DOI" value="10.17487/RFC8852"/>
            <seriesInfo name="RFC" value="8852"/>
        </reference>

<!-- draft-ietf-mmusic-sdp-mux-attributes-17 in C238 -->
        <reference anchor="RFC8859" target="https://www.rfc-editor.org/info/rfc8859">
          <front>
            <title>A Framework for SDP Attributes when Multiplexing</title>
            <seriesInfo name="DOI" value="10.17487/RFC8859"/>
            <seriesInfo name="RFC" value="8859"/>
            <author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar">
              <organization/>
            </author>
            <date month="April" year="2020"/>
          </front>
        </reference>

<!-- draft-ietf-mmusic-sdp-bundle-negotiation in C238 -->
        <reference anchor="RFC8843" target="https://www.rfc-editor.org/info/rfc8843">
          <front>
            <title>Negotiating Media Multiplexing Using the Session Description Protocol (SDP)</title>
            <seriesInfo name="DOI" value="10.17487/RFC8843"/>
            <seriesInfo name="RFC" value="8843"/>
            <author initials="C" surname="Holmberg" fullname="">
              <organization/>
            </author>
            <author initials="H" surname="Alvestrand" fullname="">
              <organization/>
            </author>
            <author initials="C" surname="Jennings" fullname="">
              <organization/>
            </author>
            <date month="April" year="2020"/>
          </front>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2198.xml"/>

        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3389.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4588.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4733.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5104.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5109.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5583.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6184.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6190.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6236.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6464.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7104.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7656.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7667.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7741.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8108.xml"/>
        <xi:include
	    href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7941.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8627.xml"/>

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

      </references>

    <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"> numbered="true" toc="default">
      <name>Requirements</name>
      <t>The following requirements are met by the defined solution 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">
              <t anchor="req-1.1" hangText="REQ-1.1:">It target="sec-use-cases" format="default">use cases</xref>:</t>

      <dl newline="false" spacing="normal">
        <dt>REQ-1:</dt>
        <dd anchor="req-1">
          <t>Identification:</t>
          <dl newline="false" spacing="normal">
            <dt>REQ-1.1:</dt>
            <dd anchor="req-1.1">It must be possible to
              identify a set of simulcasted RTP streams as originating from
              the same media source in SDP signaling.</t>

              <t anchor="req-1.2" hangText="REQ-1.2:">An signaling.</dd>
            <dt>REQ-1.2:</dt>
            <dd anchor="req-1.2">An RTP endpoint must be
              capable of identifying the simulcast stream that a received RTP
              stream is associated with, knowing the content of the SDP
              signalling.</t>
            </list></t>

          <t anchor="req-2" hangText="REQ-2:">Transport
              signaling.</dd>
          </dl>
        </dd>
        <dt>REQ-2:</dt>
        <dd anchor="req-2">
          <t>Transport usage. The solution
          must work when using:<list style="hanging">
              <t anchor="req-2.1" hangText="REQ-2.1:">Legacy using:</t>
          <dl newline="false" spacing="normal">
            <dt>REQ-2.1:</dt>
            <dd anchor="req-2.1">Legacy SDP with separate
              media transports per SDP media description.</t>

              <t anchor="req-2.2" hangText="REQ-2.2:"><xref
              target="I-D.ietf-mmusic-sdp-bundle-negotiation">Bundled</xref>
              SDP media descriptions.</t>
            </list></t>

          <t anchor="req-3" hangText="REQ-3:">Capability description.</dd>
            <dt>REQ-2.2:</dt>
            <dd anchor="req-2.2">
              <xref target="RFC8843" format="default">Bundled</xref>
              SDP media descriptions.</dd>
          </dl>
        </dd>

        <dt>REQ-3:</dt>
        <dd anchor="req-3">
          <t>Capability negotiation. It The
	  following must be possible that:<list style="hanging">
              <t anchor="req-3.1" hangText="REQ-3.1:">Sender possible:</t>
          <dl newline="false" spacing="normal">
            <dt>REQ-3.1:</dt>
            <dd anchor="req-3.1">The sender can express
              capability of sending simulcast.</t>

              <t anchor="req-3.2" hangText="REQ-3.2:">Receiver simulcast.</dd>
            <dt>REQ-3.2:</dt>
            <dd anchor="req-3.2">The receiver can express
              capability of receiving simulcast.</t>

              <t anchor="req-3.3" hangText="REQ-3.3:">Sender simulcast.</dd>
            <dt>REQ-3.3:</dt>
            <dd anchor="req-3.3">The sender can express
	      the maximum number of simulcast streams that can be provided.</t>

              <t anchor="req-3.4" hangText="REQ-3.4:">Receiver
	      provided.</dd>
            <dt>REQ-3.4:</dt>
            <dd anchor="req-3.4">The receiver can express the
              maximum number of simulcast streams that can be received.</t>

              <t anchor="req-3.5" hangText="REQ-3.5:">Sender received.</dd>
            <dt>REQ-3.5:</dt>
            <dd anchor="req-3.5">The sender can detail the
              characteristics of the simulcast streams that can be
              provided.</t>

              <t anchor="req-3.6" hangText="REQ-3.6:">Receiver
              provided.</dd>
            <dt>REQ-3.6:</dt>
            <dd anchor="req-3.6">The receiver can detail the
              characteristics of the simulcast streams that it prefers to
              receive.</t>
            </list></t>

          <t anchor="req-4" hangText="REQ-4:">Distinguishing
              receive.</dd>
          </dl>
        </dd>
        <dt>REQ-4:</dt>
        <dd anchor="req-4">Distinguishing features. It must
          be possible to have different simulcast streams use different codec
          parameters, as can be expressed by SDP format values and RTP payload
          types.</t>

          <t anchor="req-5" hangText="REQ-5:">Compatibility.
          types.</dd>
        <dt>REQ-5:</dt>
        <dd anchor="req-5">
          <t>Compatibility. It must be
          possible to use simulcast in combination with other RTP mechanisms
          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 streams:</t>
          <dl newline="false" spacing="normal">
            <dt>REQ-5.1:</dt>
            <dd anchor="req-5.1">
              <xref target="RFC4588" format="default">RTP retransmission</xref>.</dd>
            <dt>REQ-5.2:</dt>
            <dd anchor="req-5.2">
              <xref target="RFC5109" format="default">RTP Forward Error Correction</xref>.</t>

              <t anchor="req-5.3" hangText="REQ-5.3:">Related Correction</xref>.</dd>
            <dt>REQ-5.3:</dt>
            <dd anchor="req-5.3">Related payload types
              such as audio Comfort Noise and/or DTMF.</t>

              <t hangText="REQ-5.4:">A DTMF.</dd>
            <dt>REQ-5.4:</dt>
            <dd>A single simulcast stream can consist of
              multiple RTP streams, to support codecs where a dependent stream
              is dependent on a set of encoded and dependent streams, each
              potentially carried in their own RTP stream.</t>
            </list></t>

          <t anchor="req-6" hangText="REQ-6:">Interoperability. stream.</dd>
          </dl>
        </dd>
        <dt>REQ-6:</dt>
        <dd anchor="req-6">
          <t>Interoperability. The solution
          must be possible to use in:<list style="hanging">
              <t anchor="req-6.1" hangText="REQ-6.1:">Interworking in:</t>
          <dl newline="false" spacing="normal">
            <dt>REQ-6.1:</dt>
            <dd anchor="req-6.1">Interworking with
              non-simulcast
              nonsimulcast legacy clients using a single media source per
              media type.</t>

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

    </section>
    <section title="Changes From Earlier Versions">
      <t>NOTE TO RFC EDITOR: Please remove this section prior anchor="sec-ack" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors would like to
      publication.</t>

      <section title="Modifications Between WG Version -13 and -14">
        <t><list style="symbols">
            <t>c= and t= line order corrected in SDP examples</t>
          </list></t> 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 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
            for second media source.</t>

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

            <t>Added urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id in
            examples anchor="sec-contributors" numbered="false" toc="default">
      <name>Contributors</name>

      <t><contact fullname="Morgan Lindqvist"/> and <contact fullname="Fredrik
      Jansson"/>, both from Ericsson, have contributed with RTX.</t>

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

            <t>Various minor editorials the first draft versions of this document. <contact fullname="Robert
      Hanton"/> and <contact fullname="Cullen Jennings"/> from Cisco, <contact
      fullname="Peter Thatcher"/> from Google, 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
            in Section 5.2.</t>

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

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

            <t>Clarified explanation of syntax for simulcast attribute in
            Section 4.</t>

            <t>Editorial clarification in Section 5.2 and 5.3.2.</t>

            <t>Various minor editorials 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 and Redundancy,
            including both RED (RFC2198), RTP RTX (RFC4588), and FEC
            (draft-ietf-payload-flexible-fec-scheme).</t>

            <t>Removed restriction that "related" payload formats in an RTP
            stream (such as CN and DTMF) must not have their own rid-id, since
            there is no reason to forbid this and corresponding clarification
            is made in draft-ietf-mmusic-rid.</t>

            <t>Removed any mention of source-specific signaling and 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 the obsoleted RFC 5285 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 an rid-id alternative 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 it to follow actual RFC 7728 pause state to
            an informational offerer's opinion at the time of offer creation,
            not in any way overriding or amending RFC 7728 signaling.</t>

            <t>Replaced text on ignoring all but the first 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 case it is clear from the
            SDP that RTP PT uniquely maps to RtpStreamId, 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 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 to newly published RFC 8108.</t>

            <t>Adding list of modifications between -06 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 the discussion with Roni
            Even.</t>

            <t>A reformulation of the identification requirements 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 multiple instances of the
            same SCID within 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 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 RTP Aspects</t>

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

            <t>Added extmap attribute also on first signalling example as it
            is a recommended to use mechanism.</t>

            <t>Clarified the definition of the simulcast attribute and how
            simulcast streams relates to simulcast 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 the SDP offer/answer section to follow the generally
            accepted structure, also adding a brief text on modifying the
            session that is aligned with draft-ietf-mmusic-rid.</t>

            <t>Improved text around simulcast stream identification (as
            opposed to the simulcast stream itself) to consistently use the
            acronym SCID and defined that in the Terminology section.</t>

            <t>Changed references for RTP-level pause/resume and VP8 payload
            format 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 and corrections.</t>
          </list></t>
      </section>

      <section title="Modifications Between WG Version -03 and -04">
        <t><list style="symbols">
            <t>Changed 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 for RTP topologies and RTP taxonomy
            documents that are now published as RFC.</t>

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

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

            <t>Added a sub-section 7.1 with a discussion 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 <contact fullname="Adam
      Roach"/> 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 in paused
            mode.</t>

            <t>Enabled an offerer to offer multiple stream identification (pt
            or rid) methods and have the answerer choose which to use.</t>

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

            <t>Added a section on limitations of 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 the new RID solution for codec constraints and
            configuration identification. This has resulted in changes in
            syntax to identify if pt or RID is used to describe the simulcast
            stream.</t>

            <t>Renamed simulcast version and simulcast version alternative to
            simulcast stream and simulcast format respectively, and improved
            definitions for them.</t>

            <t>Clarification that it is possible Mozilla contributed significantly to switch between simulcast
            version alternatives, but that only a single one be used at any
            point in time.</t>

            <t>Changed the definition so that ordering of simulcast formats
            for a specific simulcast stream do have a preference order.</t>
          </list></t>
      </section>

      <section title="Modifications Between WG Version -00 and -01">
        <t><list style="symbols">
            <t>No changes. Only preventing expiry.</t>
          </list></t>
      </section>

      <section title="Modifications Between Individual Version -00 and WG Version -00">
        <t><list style="symbols">
            <t>Added this appendix.</t>
          </list></t>
      </section> subsequent
      versions.</t>
    </section>

  </back>
</rfc>