<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-mmusic-msid-17" ipr="trust200902"> indexInclude="true" ipr="trust200902" number="8830" prepTime="2021-01-16T21:13:18" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid-17" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc8830" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="MSID in SDP">WebRTC MediaStream Identification in the Session Description Protocol</title>
    <seriesInfo name="RFC" value="8830" stream="IETF"/>
    <author fullname="Harald Alvestrand" initials="H. T." initials="H." surname="Alvestrand">
      <organization>Google</organization>
      <organization showOnFrontPage="true">Google</organization>
      <address>
        <postal>
          <street>Kungsbron 2</street>
          <city>Stockholm</city>
          <region/>
          <code>11122</code>
          <country>Sweden</country>
        </postal>
        <email>harald@alvestrand.no</email>
      </address>
    </author>
    <date day="13" month="December" year="2018"/>

    <abstract>
      <t>This month="01" year="2021"/>
    <keyword>example</keyword>
    <keyword>MSID</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document specifies a Session Description Protocol (SDP) Grouping grouping
      mechanism for RTP media streams that can be used to specify relations
      between media streams.</t>

      <t>This
      <t indent="0" pn="section-abstract-2">This mechanism is used to signal the association between the SDP
      concept of "media description" and the WebRTC Web Real-Time Communication (WebRTC) concept of "MediaStream" /
      "MediaStreamTrack"
      MediaStream/MediaStreamTrack using SDP signaling.</t>

      <t>This
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a work item product of the MMUSIC WG, whose discussion list Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is mmusic@ietf.org.</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", available in Section 2 of
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc8830" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and "OPTIONAL" the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are to be interpreted provided without
            warranty as described in <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note> the Simplified BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-structure-of-this-document">Structure of This Document</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.3">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.3.1"><xref derivedContent="1.3" format="counter" sectionFormat="of" target="section-1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-why-a-new-mechanism-is-need">Why a New Mechanism Is Needed</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.4">
                <t indent="0" pn="section-toc.1-1.1.2.4.1"><xref derivedContent="1.4" format="counter" sectionFormat="of" target="section-1.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-webrtc-mediastream">The WebRTC MediaStream</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-msid-mechanism">The MSID Mechanism</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-procedures">Procedures</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-handling-of-nonsignaled-tra">Handling of Nonsignaled Tracks</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-detailed-offer-answer-proce">Detailed Offer/Answer Procedures</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.2.2">
                  <li pn="section-toc.1-1.3.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.1.1"><xref derivedContent="3.2.1" format="counter" sectionFormat="of" target="section-3.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-generating-the-initial-offe">Generating the Initial Offer</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.2.1"><xref derivedContent="3.2.2" format="counter" sectionFormat="of" target="section-3.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-answerer-processing-of-the-">Answerer Processing of the Offer</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.3.1"><xref derivedContent="3.2.3" format="counter" sectionFormat="of" target="section-3.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-generating-the-answer">Generating the Answer</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.4">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.4.1"><xref derivedContent="3.2.4" format="counter" sectionFormat="of" target="section-3.2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-offerer-processing-of-the-a">Offerer Processing of the Answer</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.2.2.5">
                    <t indent="0" pn="section-toc.1-1.3.2.2.2.5.1"><xref derivedContent="3.2.5" format="counter" sectionFormat="of" target="section-3.2.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-modifying-the-session">Modifying the Session</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-example-sdp-description">Example SDP Description</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-attribute-registration-in-e">Attribute Registration in Existing Registries</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-design-considerations-rejec">Design Considerations, Rejected Alternatives</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section title="Introduction">
      <t/>

      <section title="Terminology">
        <t>This numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-terminology">Terminology</name>
        <t indent="0" pn="section-1.1-1">This document uses terminology from <xref
        target="I-D.ietf-rtcweb-overview"/>. target="RFC8825" format="default" sectionFormat="of" derivedContent="RFC8825"/>. In addition, the
	following terms are used as described below:</t>

        <t><list style="hanging">
            <t hangText="RTP stream">Defined in <xref target="RFC7656"/> as a
        <dl newline="false" spacing="normal" indent="3" pn="section-1.1-2">
          <dt pn="section-1.1-2.1">RTP stream:</dt>
          <dd pn="section-1.1-2.2">A stream of RTP packets containing media data.</t>

            <t hangText="MediaStream">Defined in data <xref
            target="W3C.CR-mediacapture-streams-20160519"/>as an target="RFC7656" format="default" sectionFormat="of" derivedContent="RFC7656"/>.</dd>
          <dt pn="section-1.1-2.3">MediaStream:</dt>
          <dd pn="section-1.1-2.4">An assembly of
            MediaStreamTracks.
            MediaStreamTracks <xref target="W3C.CR-mediacapture-streams" format="default" sectionFormat="of" derivedContent="W3C.CR-mediacapture-streams"/>. One MediaStream can contain multiple
            MediaStreamTracks, of the same or different types.</t>

            <t hangText="MediaStreamTrack">Defined types.</dd>
          <dt pn="section-1.1-2.5">MediaStreamTrack:</dt>
          <dd pn="section-1.1-2.6">Defined in <xref
            target="W3C.CR-mediacapture-streams-20160519"/>as an target="W3C.CR-mediacapture-streams" format="default" sectionFormat="of" derivedContent="W3C.CR-mediacapture-streams"/> as a
            unidirectional flow of media data (either audio or video, but not
            both). Corresponds to the <xref target="RFC7656"/> target="RFC7656" format="default" sectionFormat="of" derivedContent="RFC7656"/> term "Source
            Stream". "source
            stream". One MediaStreamTrack can be present in zero, one one, or
            multiple MediaStreams.</t>

            <t hangText="Media description">Defined MediaStreams.</dd>
          <dt pn="section-1.1-2.7">Media description:</dt>
          <dd pn="section-1.1-2.8">Defined in <xref
            target="RFC4566"/> target="RFC4566" format="default" sectionFormat="of" derivedContent="RFC4566"/> as a set of
	  fields starting with an "m=" field
            and terminated by eitehr either the next "m=" field or by the end of the
            session description.</t>
          </list></t> description.</dd>
        </dl>
        <t indent="0" pn="section-1.1-3">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>
      </section>
      <section title="Structure Of numbered="true" toc="include" removeInRFC="false" pn="section-1.2">
        <name slugifiedName="name-structure-of-this-document">Structure of This Document">
        <t>This Document</name>
        <t indent="0" pn="section-1.2-1">This document adds a new Session Description Protocol (SDP) <xref
        target="RFC4566"/> target="RFC4566" format="default" sectionFormat="of" derivedContent="RFC4566"/> mechanism that can attach identifiers to the RTP
        streams and attaching attach identifiers to the groupings they form. It is
        designed for use with WebRTC<xref target="I-D.ietf-rtcweb-overview"/>
        .</t>

        <t><xref target="sect-why"/> WebRTC <xref target="RFC8825" format="default" sectionFormat="of" derivedContent="RFC8825"/>.</t>
        <t indent="0" pn="section-1.2-2"><xref target="sect-why" format="default" sectionFormat="of" derivedContent="Section 1.3"/> gives the background on why a new
        mechanism is needed.</t>

        <t><xref target="sect-definition"/>
        <t indent="0" pn="section-1.2-3"><xref target="sect-definition" format="default" sectionFormat="of" derivedContent="Section 2"/> gives the definition of the new
        mechanism.</t>

        <t><xref target="sect-media-stream"/>
        <t indent="0" pn="section-1.2-4"><xref target="sect-media-stream" format="default" sectionFormat="of" derivedContent="Section 3"/> gives the necessary semantic
        information and procedures for using the msid "msid" attribute to signal the
        association of MediaStreamTracks to MediaStreams in support of the
        WebRTC API <xref target="W3C.WD-webrtc-20160531"/>.</t> target="W3C-WebRTC" format="default" sectionFormat="of" derivedContent="W3C-WebRTC"/>.</t>
      </section>
      <section anchor="sect-why" title="Why A numbered="true" toc="include" removeInRFC="false" pn="section-1.3">
        <name slugifiedName="name-why-a-new-mechanism-is-need">Why a New Mechanism Is Needed">
        <t>When Needed</name>
        <t indent="0" pn="section-1.3-1">When media is carried by RTP <xref target="RFC3550"/>, target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550"/>, each RTP stream is distinguished inside an RTP
	session by its SSRC; Synchronization Source (SSRC); each RTP
        session is distinguished from all other RTP sessions by being on a
        different transport association (strictly speaking, 2 two transport
        associations, one used for RTP and one used for RTCP, the RTP Control Protocol
	(RTCP), unless RTP/RTCP multiplexing <xref target="RFC5761"/> target="RFC5761" format="default" sectionFormat="of" derivedContent="RFC5761"/> is used).</t>

        <t>SDP
        <t indent="0" pn="section-1.3-2">SDP <xref target="RFC4566"/> target="RFC4566" format="default" sectionFormat="of" derivedContent="RFC4566"/> gives a format for describing an SDP
        session that can contain multiple media descriptions. According to the
        model used in <xref target="I-D.ietf-rtcweb-jsep"/>, target="RFC8829" format="default" sectionFormat="of" derivedContent="RFC8829"/>, each media
        description describes exactly one media source, and if source. If multiple media
        sources are carried in an RTP session, this is signalled signaled using BUNDLE
        <xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"/>; target="RFC8843" format="default" sectionFormat="of" derivedContent="RFC8843"/>; if BUNDLE is
        not used, each media source is carried in its own RTP session.</t>

        <t>The
        <t indent="0" pn="section-1.3-3">The SDP grouping framework Grouping Framework <xref target="RFC5888"/> target="RFC5888" format="default" sectionFormat="of" derivedContent="RFC5888"/> can be used to
        group media descriptions. However, for the use case of WebRTC, there
        is the need for an application to specify some application-level
        information about the association between the media description and
        the group. This is not possible using the SDP grouping framework.</t> Grouping Framework.</t>
      </section>
      <section title="The WEBRTC MediaStream">
        <t>The numbered="true" toc="include" removeInRFC="false" pn="section-1.4">
        <name slugifiedName="name-the-webrtc-mediastream">The WebRTC MediaStream</name>
        <t indent="0" pn="section-1.4-1">The W3C WebRTC API specification <xref
        target="W3C.WD-webrtc-20160531"/> target="W3C-WebRTC" format="default" sectionFormat="of" derivedContent="W3C-WebRTC"/> specifies that communication between
        WebRTC entities is done via MediaStreams, which contain
        MediaStreamTracks. A MediaStreamTrack is generally carried using a
        single SSRC in an RTP session (forming session, forming an RTP stream. The collision of
        terminology is unfortunate.) unfortunate. There might possibly be additional SSRCs,
        possibly within additional RTP sessions, in order to support
        functionality like forward error correction or simulcast. These
        additional SSRCs are not affected by this specification.</t>

        <t>MediaStreamTracks
        <t indent="0" pn="section-1.4-2">MediaStreamTracks are unidirectional; they carry media on in one
        direction only.</t>

        <t>In
        <t indent="0" pn="section-1.4-3">In the RTP specification, RTP streams are identified using the SSRC
        field. Streams are grouped into RTP Sessions, sessions and also carry a CNAME.
        Neither CNAME nor RTP session correspond corresponds to a MediaStream. Therefore,
        the association of an RTP stream to MediaStreams need to be explicitly
        signaled.</t>

        <t>WebRTC
        <t indent="0" pn="section-1.4-4">WebRTC defines a mapping (documented in <xref
        target="I-D.ietf-rtcweb-jsep"/>) target="RFC8829" format="default" sectionFormat="of" derivedContent="RFC8829"/>) where one SDP media description is
        used to describe each MediaStreamTrack, and the BUNDLE mechanism <xref
        target="I-D.ietf-mmusic-sdp-bundle-negotiation"/> target="RFC8843" format="default" sectionFormat="of" derivedContent="RFC8843"/> is
	used to group
        MediaStreamTracks into RTP sessions. Therefore, the need is to specify
        the ID identifier (ID) of a the MediaStreamTrack and its associated MediaStream for each
        media description, which can be accomplished with a media-level SDP
        attribute.</t>

        <t>This
        <t indent="0" pn="section-1.4-5">This usage is described in <xref target="sect-media-stream"/>.</t> target="sect-media-stream" format="default" sectionFormat="of" derivedContent="Section 3"/>.</t>
      </section>
    </section>
    <section anchor="sect-definition" title="The Msid Mechanism">
      <t>This numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-the-msid-mechanism">The MSID Mechanism</name>
      <t indent="0" pn="section-2-1">This document defines a new SDP <xref target="RFC4566"/> target="RFC4566" format="default" sectionFormat="of" derivedContent="RFC4566"/> media-level
      "msid" attribute.
   This new attribute allows endpoints to associate RTP
   streams that are described in different separate media descriptions with the same
      MediaStreams
   right MediaStreams, as defined in <xref target="W3C.WD-webrtc-20160531"/>, and target="W3C-WebRTC" format="default" sectionFormat="of" derivedContent="W3C-WebRTC"/>. It also allows endpoints to carry an identifier for
      each MediaStreamTrack in its "appdata" field.</t>

      <t>The
      <t indent="0" pn="section-2-2">The value of the "msid" attribute consists of an identifier and an
      optional "appdata" field.</t>

      <t>The
      <t indent="0" pn="section-2-3">The name of the attribute is "msid".</t>

      <t>The
      <t indent="0" pn="section-2-4">The value of the attribute is specified by the following ABNF <xref
      target="RFC5234"/> target="RFC5234" format="default" sectionFormat="of" derivedContent="RFC5234"/> grammar:</t>

      <t/>

      <figure>
        <artwork><![CDATA[
      <sourcecode type="abnf" markers="false" pn="section-2-5">
  msid-value = msid-id [ SP msid-appdata ]
  msid-id = 1*64token-char ; see RFC 4566
  msid-appdata = 1*64token-char  ; see RFC 4566

]]></artwork>
      </figure>

      <t>An
</sourcecode>
      <t indent="0" pn="section-2-6">An example msid "msid" value for a group with the identifier "examplefoo"
      and application data "examplebar" might look like this:</t>

      <figure>
        <artwork><![CDATA[
      <sourcecode markers="false" pn="section-2-7">
  msid:examplefoo examplebar

]]></artwork>
      </figure>

      <t>The
</sourcecode>
      <t indent="0" pn="section-2-8">The identifier is a string of ASCII characters that are legal in a
      "token", consisting of between 1 and 64 characters.</t>

      <t>Application
      <t indent="0" pn="section-2-9">Application data (msid-appdata) is carried on the same line as the
      identifier, separated from the identifier by a space.</t>

      <t>The
      <t indent="0" pn="section-2-10">The identifier (msid-id) ("msid-id") uniquely identifies a group within the scope
      of an SDP description.</t>

      <t>There
      <t indent="0" pn="section-2-11">There may be multiple msid "msid" attributes in a single media description.
      This represents the case where a single MediaStreamTrack is present in
      multiple MediaStreams; the value of "msid-appdata" MUST <bcp14>MUST</bcp14> be identical for
      all occurences.</t>

      <t>Multiple occurrences.</t>
      <t indent="0" pn="section-2-12">Multiple media descriptions with the same value for msid-id "msid-id" and
      msid-appdata
      "msid‑appdata" are not permitted.</t>

      <t>Endpoints
      <t indent="0" pn="section-2-13">Endpoints can update the associations between RTP streams as
      expressed by msid "msid" attributes at any time.</t>

      <t>The msid
      <t indent="0" pn="section-2-14">The "msid" attributes depend on the association of RTP streams with
      media descriptions, descriptions but does do not depend on the association of RTP
      streams with RTP transports; therefore, its mux category transports. Therefore, their Mux Category (as defined in
      <xref target="I-D.ietf-mmusic-sdp-mux-attributes"/>) target="RFC8859" format="default" sectionFormat="of" derivedContent="RFC8859"/>) is NORMAL - NORMAL; the
      process of deciding on MSID "msid" attributes doesn't have to take into
      consideration whether or not the RTP streams are bundled or not.</t> bundled.</t>
    </section>
    <section anchor="sect-media-stream" title="Procedures">
      <t>This numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-procedures">Procedures</name>
      <t indent="0" pn="section-3-1">This section describes the procedures for associating media
      descriptions representing MediaStreamTracks within MediaStreams MediaStreams, as
      defined in <xref target="W3C.WD-webrtc-20160531"/>.</t>

      <t>In target="W3C-WebRTC" format="default" sectionFormat="of" derivedContent="W3C-WebRTC"/>.</t>
      <t indent="0" pn="section-3-2">In the Javascript API described in that specification, each
      MediaStream and MediaStreamTrack has an "id" attribute, which is a
      DOMString.</t>

      <t>The
      <t indent="0" pn="section-3-3">The value of the "msid-id" field in the msid MSID consists of the "id"
      attribute of a MediaStream, as defined in the MediaStream's WebIDL
      specification.
      specification <xref target="WEBIDL" format="default" sectionFormat="of" derivedContent="WEBIDL"/>. The special value "-" indicates "no MediaStream".</t>

      <t>The
      <t indent="0" pn="section-3-4">The value of the "msid-appdata" field in the msid, MSID, if present,
      consists of the
      "id" attribute of a MediaStreamTrack, as defined in the
      MediaStreamTrack's WebIDL specification.</t>

      <t>When
      <t indent="0" pn="section-3-5">When an SDP session description is updated, a specific "msid-id"
      value continues to refer to the same MediaStream, and a specific
      "msid-appdata" to the same MediaStreamTrack. There is no memory apart
      from the currently valid SDP descriptions; if an msid MSID "identifier" value
      disappears from the SDP and appears in a later negotiation, it will be
      taken to refer to a new MediaStream.</t>

      <t>If
      <t indent="0" pn="section-3-6">If the MSID "msid" attribute does not conform to the ABNF given here, it
      SHOULD
      <bcp14>SHOULD</bcp14> be ignored.</t>

      <t>The
      <t indent="0" pn="section-3-7">The following is a high level high-level description of the rules for handling
      SDP updates. Detailed procedures are located in <xref
      target="s-detailed-procedures"/>.</t>

      <t><list style="symbols">
          <t>When target="s-detailed-procedures" format="default" sectionFormat="of" derivedContent="Section 3.2"/>.</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-8">
        <li pn="section-3-8.1">When a new msid MSID "identifier" value occurs in a session
          description, and it is not "-", the recipient can signal to its
          application that a new MediaStream has been added.</t>

          <t>When added.</li>
        <li pn="section-3-8.2">When a session description is updated to have media descriptions
          with an msid MSID "identifier" value, with one or more different
          "appdata" values, the recipient can signal to its application that
          new MediaStreamTracks have been added, added and note to which MediaStream it has
	  they have
          been added to. added. This is done for each different msid MSID "identifier"
          value, including the special value "-", which indicates that a
          MediaStreamTrack has been added with no corresponding
          MediaStream.</t>

	  <t>If
          MediaStream.</li>
        <li pn="section-3-8.3">If an msid MSID "identifier" value with no "appdata" value appears,
	  it means that the sender did not inform the recipient of the desired
	  identifier of the MediaStreamTrack, and the recipient will assign
	  the "id" value of the created MediaStreamTrack on its own. All
	  msid
	  MSIDs in a media section that do not have an "appdata" value are
	  assumed to refer to the same MediaStreamTrack.</t>

          <t>When MediaStreamTrack.</li>
        <li pn="section-3-8.4">When a session description is updated to no longer list any msid "msid"
          attribute on a specific media description, the recipient can signal
          to its application that the corresponding MediaStreamTrack has
          ended.</t>
        </list></t>

      <t>In
          ended.</li>
      </ul>
      <t indent="0" pn="section-3-9">In addition to signaling that the track is ended when its msid "msid"
   attribute disappears from the SDP, the track will also be signaled as
      being ended when all associated SSRCs have disappeared by the rules of
      <xref target="RFC3550"/> section 6.3.4 target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550"/>, Sections <xref target="RFC3550" section="6.3.4" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3550#section-6.3.4" derivedContent="RFC3550"/>
       (BYE packet received) and 6.3.5 <xref target="RFC3550" section="6.3.5" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3550#section-6.3.5" derivedContent="RFC3550"/>
       (timeout), or when the corresponding media description is disabled by
      setting the port number to zero. Changing the direction of the media
      description (by setting "sendonly", "recvonly" "recvonly", or "inactive" attributes)
      will not end the MediaStreamTrack.</t>

      <t>The
      <t indent="0" pn="section-3-10">The association between SSRCs and media descriptions is specified in
      <xref target="I-D.ietf-rtcweb-jsep"/>.</t> target="RFC8829" format="default" sectionFormat="of" derivedContent="RFC8829"/>.</t>
      <section anchor="s-nonsignal" title="Handling numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-handling-of-nonsignaled-tra">Handling of non-signalled tracks">
        <t>Entities Nonsignaled Tracks</name>
        <t indent="0" pn="section-3.1-1">Entities that do not use msid the mechanism described in this document will not send the
	"msid" attribute and thus will not send msid. information allowing the mapping of RTP packets to MediaStreams. This means that there will be some incoming RTP packets that for which the recipient has no predefined MediaStream id value for.</t>

        <t>Note ID value.</t>
        <t indent="0" pn="section-3.1-2">Note that this the handling described below is triggered by incoming RTP packets, not
        by
        SDP negotiation.</t>

        <t>When
        <t indent="0" pn="section-3.1-3">When communicating with entities that use the MSID is used, mechanism, the only time this incoming RTP packets
        can happen be received without an associated MediaStream ID value is when, after the
        initial negotiation, a negotiation is performed where the answerer
        adds a MediaStreamTrack to an already established connection and
        starts sending data before the answer is received by the offerer. For
        initial negotiation, packets won't flow until the ICE Interactive
	Connectivity Establishment (ICE) candidates and
        fingerprints have been exchanged, so this is not an issue.</t>

        <t>The
        <t indent="0" pn="section-3.1-4">The recipient of those packets will perform the following
        steps:</t>

        <t><list style="symbols">
            <t>When
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.1-5">
          <li pn="section-3.1-5.1">When RTP packets are initially received, it will create an
            appropriate MediaStreamTrack based on the type of the media
            (carried in PayloadType), PayloadType) and use the MID RTP header extension
            <xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"/> target="RFC8843" format="default" sectionFormat="of" derivedContent="RFC8843"/> (if
            present) to associate the RTP packets with a specific media
            section.</t>

            <t>If
            section.</li>
          <li pn="section-3.1-5.2">If the connection is not in the RTCSignalingState "stable", it
            will wait at this point.</t>

            <t>When point.</li>
          <li pn="section-3.1-5.3">When the connection is in the RTCSignalingState "stable", it
            will assign ID values.</t>
          </list></t>

        <t>The values.</li>
        </ul>
        <t indent="0" pn="section-3.1-6">The following steps are performed to assign ID values:</t>

        <t><list style="symbols">
            <t>If
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.1-7">
          <li pn="section-3.1-7.1">If there is an msid "msid" attribute, it will use that attribute to
            populate the "id" field of the MediaStreamTrack and associated
            MediaStreams, as described above.</t>

            <t>If above.</li>
          <li pn="section-3.1-7.2">If there is no msid "msid" attribute, the identifier of the
            MediaStreamTrack will be set to a randomly generated string, and
            it will be signalled signaled as being part of a MediaStream with the
            WebIDL "label" attribute set to "Non-WebRTC stream".</t>

            <t>After stream".</li>
          <li pn="section-3.1-7.3">After deciding on the "id" field to be applied to the
            MediaStreamTrack, the track will be signalled signaled to the user.</t>
          </list></t>

        <t>The user.</li>
        </ul>
        <t indent="0" pn="section-3.1-8">The process above may involve a considerable amount of buffering
        before the stable "stable" state is entered. If the implementation wishes to
        limit this buffering, it MUST <bcp14>MUST</bcp14> signal to the user that media has been
        discarded.</t>

        <t>It
        <t indent="0" pn="section-3.1-9">It follows from the above that MediaStreamTracks in the "default"
        MediaStream cannot be closed by removing the msid "msid" attribute; the
        application must instead signal these as closed when the SSRC
        disappears
        disappears, either according to the rules of RFC 3550 section 6.3.4 Sections <xref target="RFC3550" section="6.3.4" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3550#section-6.3.4" derivedContent="RFC3550"/> and 6.3.5  <xref target="RFC3550" section="6.3.5" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3550#section-6.3.5" derivedContent="RFC3550"/> of <xref target="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550"/> or by disabling the media
	description by setting its port to zero.</t>
      </section>
      <section anchor="s-detailed-procedures"
               title="Detailed numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-detailed-offer-answer-proce">Detailed Offer/Answer Procedures">
        <t>These Procedures</name>
        <t indent="0" pn="section-3.2-1">These procedures are given in terms of RFC 3264-recommended
        sections. sections recommended by
	<xref target="RFC3264" format="default" sectionFormat="of" derivedContent="RFC3264"/>. They describe the actions to be taken in terms of
        MediaStreams and MediaStreamTracks; they do not include event
        signalling
        signaling inside the application, which is described in JSEP.</t>

        <section title="Generating the initial offer">
          <t>For JavaScript
	Session Establishment Protocol (JSEP) <xref target="RFC8829" format="default" sectionFormat="of" derivedContent="RFC8829"/>.</t>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-3.2.1">
          <name slugifiedName="name-generating-the-initial-offe">Generating the Initial Offer</name>
          <t indent="0" pn="section-3.2.1-1">For each media description in the offer, if there is an
          associated outgoing MediaStreamTrack, the offerer adds one "a=msid"
          attribute to the section for each MediaStream with which the
          MediaStreamTrack is associated. The "identifier" field of the
          attribute is set to the WebIDL "id" attribute of the MediaStream.
	  If the sender wishes to signal identifiers for the MediaStreamTracks,
          the "appdata" field is set to the WebIDL "id" attribute of the
          MediaStreamTrack; otherwise otherwise, it is omitted.</t>
        </section>
        <section title="Answerer processing numbered="true" toc="include" removeInRFC="false" pn="section-3.2.2">
          <name slugifiedName="name-answerer-processing-of-the-">Answerer Processing of the Offer">
          <t>For Offer</name>
          <t indent="0" pn="section-3.2.2-1">For each media description in the offer, offer and for each "a=msid"
          attribute in the media description, the receiver of the offer will
          perform the following steps:</t>

          <t><list style="symbols">
            <t>Extract
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.2.2-2">
            <li pn="section-3.2.2-2.1">Extract the "appdata" field of the "a=msid" attribute,
	    if present.</t>

            <t>If present.</li>
            <li pn="section-3.2.2-2.2">If the "appdata" field exists: Check if a MediaStreamTrack
	    with the same WebIDL "id"
            attribute as the "appdata" field already exists, exists and is not in
            the "ended" state. If it such a MediaStreamTrack is not found, create it.</t>

	    <t>If it.</li>
            <li pn="section-3.2.2-2.3">If the "appdata" field does not exist, and a MediaStreamTrack is
	    not associated with this media section, create one a MediaStreamTrack and associate
	    it with this media section for future use.</t>

              <t>Extract use.</li>
            <li pn="section-3.2.2-2.4">Extract the "identifier" field of the "a=msid" attribte.</t>

              <t>Check attribute.</li>
            <li pn="section-3.2.2-2.5">Check if a MediaStream with the same WebIDL "id" attribute
              already exists. If not, create it.</t>

              <t>Add it.</li>
            <li pn="section-3.2.2-2.6">Add the MediaStreamTrack to the MediaStream</t>

              <t>Signal MediaStream.</li>
            <li pn="section-3.2.2-2.7">Signal to the user that a new MediaStreamTrack is
              available.</t>
            </list></t>
              available.</li>
          </ul>
        </section>
        <section title="Generating numbered="true" toc="include" removeInRFC="false" pn="section-3.2.3">
          <name slugifiedName="name-generating-the-answer">Generating the answer">
          <t>The Answer</name>
          <t indent="0" pn="section-3.2.3-1">The answer is generated in exactly the same manner as the offer.
          "a=msid" values in the offer do not influence the answer.</t>
        </section>
        <section title="Offerer processing numbered="true" toc="include" removeInRFC="false" pn="section-3.2.4">
          <name slugifiedName="name-offerer-processing-of-the-a">Offerer Processing of the answer">
          <t>The Answer</name>
          <t indent="0" pn="section-3.2.4-1">The answer is processed in exactly the same manner as the
          offer.</t>
        </section>
        <section title="Modifying numbered="true" toc="include" removeInRFC="false" pn="section-3.2.5">
          <name slugifiedName="name-modifying-the-session">Modifying the session">
          <t>On Session</name>
          <t indent="0" pn="section-3.2.5-1">On subsequent exchanges, precisely the same procedure as for the
          initial offer/answer is followed, but with one additional step in
          the parsing of the offer and answer:</t>

          <t><list style="symbols">
              <t>For
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.2.5-2">
            <li pn="section-3.2.5-2.1">For each MediaStreamTrack that has been created as a result
              of previous offer/answer exchanges, and is not in the "ended"
              state, check to see if there is still an "a=msid" attribute in
              the present SDP whose "appdata" field is the same as the WebIDL
              "id" attribute of the track.</t>

              <t>If track.</li>
            <li pn="section-3.2.5-2.2">If no such attribute is found, stop the MediaStreamTrack.
              This will set its state to "ended".</t>
            </list></t> "ended".</li>
          </ul>
        </section>
      </section>
      <section title="Example numbered="true" toc="include" removeInRFC="false" pn="section-3.3">
        <name slugifiedName="name-example-sdp-description">Example SDP description">
        <t>The Description</name>
        <t indent="0" pn="section-3.3-1">The following SDP description shows the representation of a WebRTC
        PeerConnection with two MediaStreams, each of which has one audio and
        one video track. Only the parts relevant to the MSID are shown.</t>

        <t>Line
        <t indent="0" pn="section-3.3-2">Line wrapping, empty lines lines, and comments are added for clarity. They
        are not part of the SDP.</t>

        <t/>

        <figure>
          <artwork><![CDATA[
        <sourcecode type="sdp" markers="false" pn="section-3.3-3">
# First MediaStream - id is 4701...
m=audio 56500 UDP/TLS/RTP/SAVPF 96 0 8 97 98
a=msid:47017fee-b6c1-4162-929c-a25110252400
       f83006c5-a0ff-4e0a-9ed9-d3e6747be7d9

m=video 56502 UDP/TLS/RTP/SAVPF 100 101
a=msid:47017fee-b6c1-4162-929c-a25110252400
       b47bdb4a-5db8-49b5-bcdc-e0c9a23172e0

# Second MediaStream - id is 6131....
m=audio 56503 UDP/TLS/RTP/SAVPF 96 0 8 97 98
a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae
       b94006c5-cade-4e0a-9ed9-d3e6747be7d9

m=video 56504 UDP/TLS/RTP/SAVPF 100 101
a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae
       f30bdb4a-1497-49b5-3198-e0c9a23172e0

]]></artwork>
        </figure>

        <t/>
</sourcecode>
      </section>
    </section>
    <section anchor="IANA" title="IANA Considerations">
      <section title="Attribute registration numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-attribute-registration-in-e">Attribute Registration in existing registries">
        <t>This document requests IANA to register Existing Registries</name>
        <t indent="0" pn="section-4.1-1">IANA has registered the "msid" attribute in the
        "att-field
        "att-field" (media level only)" only) registry within the SDP parameters "Session
	Description Protocol (SDP) Parameters" registry, according to the
	procedures of <xref target="RFC4566"/></t>

        <t>The required information for target="RFC4566" format="default" sectionFormat="of" derivedContent="RFC4566"/>.</t>
        <t indent="0" pn="section-4.1-2">The "msid" is:</t>

        <t><list style="symbols">
            <t>Contact registration information is as follows:</t>
        <dl indent="3" newline="false" spacing="normal" pn="section-4.1-3">
          <dt pn="section-4.1-3.1">Contact name, email: IETF, email:</dt>
          <dd pn="section-4.1-3.2">IETF, contacted via mmusic@ietf.org, or a
            successor address designated by IESG</t>

            <t>Attribute name: msid</t>

            <t>Long-form IESG</dd>
          <dt pn="section-4.1-3.3">Attribute name:</dt>
          <dd pn="section-4.1-3.4">msid</dd>
          <dt pn="section-4.1-3.5">Attribute syntax:</dt>
          <dd pn="section-4.1-3.6">
            <t indent="0" pn="section-4.1-3.6.1"><br/></t>
            <sourcecode type="abnf" markers="false" pn="section-4.1-3.6.2">
          msid-value = msid-id [ SP msid-appdata ]
          msid-id = 1*64token-char ; see RFC 4566
          msid-appdata = 1*64token-char  ; see RFC 4566
</sourcecode>
          </dd>
          <dt pn="section-4.1-3.7">Attribute semantics:</dt>
          <dd pn="section-4.1-3.8"> Described in RFC 8830</dd>
          <dt pn="section-4.1-3.9">Attribute value:</dt>
          <dd pn="section-4.1-3.10"> msid-value</dd>
          <dt pn="section-4.1-3.11">Long-form attribute name: MediaStream group Identifier</t>

            <t>Subject to charset: The name:</dt>
          <dd pn="section-4.1-3.12">MediaStream Identifier</dd>
          <dt pn="section-4.1-3.13">Usage level:</dt>
          <dd pn="section-4.1-3.14">media</dd>
          <dt pn="section-4.1-3.15">Subject to charset:</dt>
          <dd pn="section-4.1-3.16">The attribute value contains only ASCII
            characters,
            characters and is therefore not subject to the charset
            attribute.</t>

            <t>Purpose: The
            attribute.</dd>
          <dt pn="section-4.1-3.17">Purpose:</dt>
          <dd pn="section-4.1-3.18">The attribute can be used to signal the relationship
            between a WebRTC MediaStream and a set of media descriptions.</t>

            <t>Appropriate values: The descriptions.</dd>
          <dt pn="section-4.1-3.19">O/A Procedures:</dt>
          <dd pn="section-4.1-3.20"> Described in RFC 8830</dd>
          <dt pn="section-4.1-3.21">Appropriate values:</dt>
          <dd pn="section-4.1-3.22">The details of appropriate values are given
            in RFC XXXX.</t>

            <t>MUX category: NORMAL</t>
          </list>The MUX category 8830 (this document).</dd>
          <dt pn="section-4.1-3.23">Mux Category:</dt>
          <dd pn="section-4.1-3.24">NORMAL</dd>
        </dl>
        <t indent="0" pn="section-4.1-4">The Mux Category is defined in <xref
        target="I-D.ietf-mmusic-sdp-mux-attributes"/>.</t> target="RFC8859" format="default" sectionFormat="of" derivedContent="RFC8859"/>.</t>
      </section>
    </section>
    <section anchor="Security" title="Security Considerations">
      <t>An numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-5-1">An adversary with the ability to modify SDP descriptions has the
      ability to switch around tracks between MediaStreams. This is a special
      case of the general security consideration that modification of SDP
      descriptions needs to be confined to entities trusted by the
      application.</t>

      <t>If
      <t indent="0" pn="section-5-2">If implementing buffering as mentioned in <xref
      target="s-nonsignal"/>, target="s-nonsignal" format="default" sectionFormat="of" derivedContent="Section 3.1"/>, the amount of buffering should be limited to
      avoid memory exhaustion attacks.</t>

      <t>Careless
      <t indent="0" pn="section-5-3">Careless generation of identifiers can leak privacy-sensitive
      information. <xref target="W3C.CR-mediacapture-streams-20160519"/> target="W3C.CR-mediacapture-streams" format="default" sectionFormat="of" derivedContent="W3C.CR-mediacapture-streams"/>
      recommends that identifiers are be generated using UUID a Universally Unique
      IDentifier (UUID) class 3 or 4 as a
      basis, which avoids such leakage.</t>

      <t>No
      <t indent="0" pn="section-5-4">No other attacks have been identified that depend on this
      mechanism.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>This note is based on sketches from, among others, Justin Uberti and
      Cullen Jennings.</t>

      <t>Special thanks to Flemming Andreassen, Ben Campbell, Miguel Garcia,
      Martin Thomson, Ted Hardie, Adam Roach, Magnus Westerlund, Alissa
      Cooper, Sue Hares and Paul Kyzivat for their work in reviewing this
      draft, with many specific language suggestions.</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.W3C.WD-webrtc-20160531'?>

      <?rfc include='reference.W3C.CR-mediacapture-streams-20160519'?>

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

      <?rfc include='reference.I-D.ietf-mmusic-sdp-mux-attributes'?>
    </references> pn="section-6">
      <name slugifiedName="name-references">References</name>
      <references title="Informative References">
      <?rfc include='reference.RFC.5761'?>

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

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

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

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

    <section title="Design considerations, rejected alternatives">
      <t>One suggested mechanism has been to pn="section-6.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use CNAME instead of a new
      attribute. This was abandoned because CNAME identifies a synchronization
      context; one can imagine both wanting to have tracks from the same
      synchronization context in multiple MediaStreams and wanting to have
      tracks from multiple synchronization contexts within one MediaStream
      (but the latter is impossible, since a MediaStream is defined RFCs to impose
      synchronization on its members).</t>

      <t>Another suggestion has been Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to put signify the msid value within an attribute
      of RTCP SR (sender report) packets. requirements in the specification.  These words are often capitalized. This doesn't offer document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the ability to
      know that you have seen all Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC3550" target="https://www.rfc-editor.org/info/rfc3550" quoteTitle="true" derivedAnchor="RFC3550">
          <front>
            <title>RTP: A Transport Protocol for Real-Time Applications</title>
            <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Casner" fullname="S. Casner">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Frederick" fullname="R. Frederick">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="V." surname="Jacobson" fullname="V. Jacobson">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2003" month="July"/>
            <abstract>
              <t indent="0">This memorandum describes RTP, the tracks currently configured real-time transport protocol.  RTP provides end-to-end network transport functions suitable for a
      MediaStream.</t>

      <t>A suggestion that survived applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services.  RTP does not address resource reservation and does not guarantee quality-of- service for real-time services.  The data transport is augmented by a number of drafts was control protocol (RTCP) to define
      "msid" as a generic mechanism, where the particular semantics of this
      usage allow monitoring of the mechanism would be defined by an "a=wms-semantic"
      attribute. This was removed data delivery in April 2015.</t>
    </section>

    <section title="Change log">
      <t>This appendix should be deleted before publication as an RFC.</t>

      <section title="Changes from alvestrand-rtcweb-msid-00 a manner scalable to -01">
        <t>Added track identifier.</t>

        <t>Added inclusion-by-reference of
        draft-lennox-mmusic-source-selection for track muting.</t>

        <t>Some rewording.</t>
      </section>

      <section title="Changes from alvestrand-rtcweb-msid-01 large multicast networks, and to -02">
        <t>Split document into sections describing a generic grouping
        mechanism provide minimal control and sections describing identification functionality.  RTP and RTCP are designed to be independent of the application underlying transport and network layers.  The protocol supports the use of RTP-level translators and mixers. Most of the text in this grouping
        mechanism to the WebRTC MediaStream concept.</t>

        <t>Removed the mechanism for muting tracks, since this is not central memorandum is identical to RFC 1889 which it obsoletes.  There are no changes in the MSID mechanism.</t>
      </section>

      <section title="Changes from alvestrand-rtcweb-msid-02 to mmusic-msid-00">
        <t>Changed packet formats on the draft name according wire, only changes to the wishes of rules and algorithms governing how the MMUSIC group
        chairs.</t>

        <t>Added text indicting cases where it's appropriate protocol is used. The biggest change is an enhancement to have the same
        appdata scalable timer algorithm for multiple SSRCs.</t>

        <t>Minor textual updates.</t>
      </section>

      <section title="Changes from alvestrand-mmusic-msid-00 to -01">
        <t>Increased the amount of explanatory text, much based on a review by
        Miguel Garcia.</t>

        <t>Removed references to BUNDLE, since that spec is under active
        discussion.</t>

        <t>Removed distinguished values of the MSID identifier.</t>
      </section>

      <section title="Changes from alvestrand-mmusic-msid-01 calculating when to -02">
        <t>Changed the send RTCP packets in order to minimize transmission in excess of the "msid-semantic: " attribute's value fields
        and allowed multiple identifiers. This makes the attribute useful as intended rate when many participants join a
        marker for "I understand this semantic".</t>

        <t>Changed the syntax for "identifier" and "appdata" to be
        "token".</t>

        <t>Changed session simultaneously.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="64"/>
          <seriesInfo name="RFC" value="3550"/>
          <seriesInfo name="DOI" value="10.17487/RFC3550"/>
        </reference>
        <reference anchor="RFC4566" target="https://www.rfc-editor.org/info/rfc4566" quoteTitle="true" derivedAnchor="RFC4566">
          <front>
            <title>SDP: Session Description Protocol</title>
            <author initials="M." surname="Handley" fullname="M. Handley">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="V." surname="Jacobson" fullname="V. Jacobson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Perkins" fullname="C. Perkins">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="July"/>
            <abstract>
              <t indent="0">This memo defines the registry Session Description Protocol (SDP).  SDP is intended for the "msid-semantic" attribute values to be
        a new registry, based on advice given in Atlanta.</t>
      </section>

      <section title="Changes from alvestrand-mmusic-msid-02 to ietf-mmusic-00">
        <t>Updated terminology to refer to m-lines rather than RTP describing multimedia sessions
        when discussing SDP formats and for the ability purposes of session announcement, session invitation, and other linking
        mechanisms to refer to SSRCs.</t>

        <t>Changed the "default" mechanism forms of multimedia session initiation.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4566"/>
          <seriesInfo name="DOI" value="10.17487/RFC4566"/>
        </reference>
        <reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5234" quoteTitle="true" derivedAnchor="RFC5234">
          <front>
            <title>Augmented BNF for Syntax Specifications: ABNF</title>
            <author initials="D." surname="Crocker" fullname="D. Crocker" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Overell" fullname="P. Overell">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="January"/>
            <abstract>
              <t indent="0">Internet technical specifications often need to return independent streams after
        considering the synchronization problem.</t>

        <t>Removed the space from between "msid-semantic" define a formal syntax.  Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications.  The current specification documents ABNF. It balances compactness and its value, to be
        consistent simplicity with RFC 5576.</t>
      </section>

      <section title="Changes from mmusic-msid-00 to -01">
        <t>Reworked msid mechanism to be reasonable representational power.  The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges.  This specification also supplies additional rule definitions and encoding for a per-m-line attribute, to align with
        draft-roach-mmusic-unified-plan.</t>
      </section>

      <section title="Changes from mmusic-msid-01 to -02">
        <t>Corrected several missed cases where core lexical analyzer of the word "ssrc" was not
        changed to "M-line".</t>

        <t>Added pointer to unified-plan (which should be moved to point type common to
        -jsep)</t>

        <t>Removed suggestion several Internet specifications.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="68"/>
          <seriesInfo name="RFC" value="5234"/>
          <seriesInfo name="DOI" value="10.17487/RFC5234"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that ssrc-group attributes can may be used with
        "msid-semantic", it is now only the msid-semantic registry.</t>
      </section>

      <section title="Changes from mmusic-msid-02 to -03">
        <t>Corrected even more cases where the word "ssrc" was not changed to
        "M-line".</t>

        <t>Added the functionality of using an asterisk (*) in the
        msid-semantic line, in order protocol  specifications.  This document aims to remove reduce the need for listing all msids
        in the msid-semantic line whne ambiguity by clarifying that only one msid-semantic is in use.</t>

        <t>Removed some now-unnecessary text.</t>
      </section>

      <section title="Changes from mmusic-msid-03 to -04">
        <t>Changed title to reflect focus on WebRTC MediaStreams</t>

        <t>Added a section on receiver-side media stream control, using UPPERCASE usage of the
        "msid-control" attribute.</t>
      </section>

      <section title="Changes from -04 to -05">
        <t>Removed key words have the msid-control section after WG discussion.</t>

        <t>Removed some text that seemed only to pertain to resolved
        issues.</t>
      </section>

      <section title="Changes from -05 to -06">
        <t>Addressed issues found in Fleming Andreassen's review</t>

        <t>Referenced JSEP rather than unified-plan  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8829" target="https://www.rfc-editor.org/info/rfc8829" quoteTitle="true" derivedAnchor="RFC8829">
          <front>
            <title>JavaScript Session Establishment Protocol (JSEP)</title>
            <author initials="J." surname="Uberti" fullname="Justin Uberti">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Jennings" fullname="Cullen Jennings">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Rescorla" fullname="Eric Rescorla" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8829"/>
          <seriesInfo name="DOI" value="10.17487/RFC8829"/>
        </reference>
        <reference anchor="RFC8859" target="https://www.rfc-editor.org/info/rfc8859" quoteTitle="true" derivedAnchor="RFC8859">
          <front>
            <title>A Framework for the M-line mapping
        model</t>

        <t>Relaxed MSID definition to allow "token-char" in values rather than
        a-z 0-9 hyphen; tightened ABNF Session Description Protocol (SDP) Attributes When Multiplexing</title>
            <author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8859"/>
          <seriesInfo name="DOI" value="10.17487/RFC8859"/>
        </reference>
        <reference anchor="W3C-WebRTC" target="https://www.w3.org/TR/webrtc/" quoteTitle="true" derivedAnchor="W3C-WebRTC">
          <front>
            <title>WebRTC 1.0: Real-time Communication Between Browsers</title>
            <author initials="C." surname="Jennings" fullname="Cullen Jennings">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Boström" fullname="Henrik Boström">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J-I." surname="Bruaroey" fullname="Jan-Ivar Bruaroey">
              <organization showOnFrontPage="true"/>
            </author>
            <date/>
          </front>
          <refcontent>W3C Proposed Recommendation</refcontent>
        </reference>
        <reference anchor="W3C.CR-mediacapture-streams" target="https://www.w3.org/TR/mediacapture-streams/" quoteTitle="true" derivedAnchor="W3C.CR-mediacapture-streams">
          <front>
            <title>Media Capture and Streams</title>
            <author initials="C." surname="Jennings" fullname="Cullen Jennings">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Aboba" fullname="Bernard Aboba">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J.-I." surname="Bruaroey" fullname="Jan-Ivar Bruaroey">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H" surname="Boström" fullname="Henrik Boström">
              <organization showOnFrontPage="true"/>
            </author>
            <date/>
          </front>
          <refcontent>W3C Candidate Recommendation</refcontent>
        </reference>
      </references>
      <references pn="section-6.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC3264" target="https://www.rfc-editor.org/info/rfc3264" quoteTitle="true" derivedAnchor="RFC3264">
          <front>
            <title>An Offer/Answer Model with Session Description Protocol (SDP)</title>
            <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2002" month="June"/>
            <abstract>
              <t indent="0">This document defines a mechanism by adding length description to it.</t>

        <t>Deleted discussion which two entities can make use of abandoned alternatives, as part the Session Description Protocol (SDP) to arrive at a common view of preparing
        for publication.</t>

        <t>Added a "detailed procedures" section to multimedia session between them.  In the WMS semantics
        description.</t>

        <t>Added IANA registration model, one participant offers the other a description of the "msid-semantic" attribute.</t>
      </section>

      <section title="Changes from -06 to -07">
        <t>Changed terminology desired session from referring to "WebRTC device" to referring
        to "entities that implement their perspective, and the WMS semantic".</t>

        <t>Changed names for ABNF constructions based on a proposal by Paul
        Kyzivat.</t>

        <t>Included a section on generic other participant answers with the desired session from their perspective.  This offer/answer semantics.</t>
      </section>

      <section title="Changes model is most useful in unicast sessions where information from -07 to -08">
        <t>Removed Appendix B that described both participants is needed for the (now obsolete) ssrc-specific
        usage of MSID.</t>

        <t>Adopted a restructuring complete view of the IANA section based session.  The offer/answer model is used by protocols like the Session Initiation Protocol (SIP).  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3264"/>
          <seriesInfo name="DOI" value="10.17487/RFC3264"/>
        </reference>
        <reference anchor="RFC5761" target="https://www.rfc-editor.org/info/rfc5761" quoteTitle="true" derivedAnchor="RFC5761">
          <front>
            <title>Multiplexing RTP Data and Control Packets on a suggestion
        from Martin Thomson.</t>

        <t>A number of text Single Port</title>
            <author initials="C." surname="Perkins" fullname="C. Perkins">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Westerlund" fullname="M. Westerlund">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="April"/>
            <abstract>
              <t indent="0">This memo discusses issues that arise when multiplexing RTP data packets and ABNF clarifications based RTP Control Protocol (RTCP) packets on suggestions from
        Ted Hardie, Paul Kyzivat and Adam Roach.</t>

        <t>Changed a single UDP port. It updates RFC 3550 and RFC 3551 to describe when such multiplexing is and is not appropriate, and it explains how the "non-signalled track handling" Session Description Protocol (SDP) can be used to create signal multiplexed sessions.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5761"/>
          <seriesInfo name="DOI" value="10.17487/RFC5761"/>
        </reference>
        <reference anchor="RFC5888" target="https://www.rfc-editor.org/info/rfc5888" quoteTitle="true" derivedAnchor="RFC5888">
          <front>
            <title>The Session Description Protocol (SDP) Grouping Framework</title>
            <author initials="G." surname="Camarillo" fullname="G. Camarillo">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="June"/>
            <abstract>
              <t indent="0">In this specification, we define a single
        stream with multiple tracks again, according framework to discussions at TPAC group "m" lines in
        November 2014</t>
      </section>

      <section title="Changes from -08 the Session Description Protocol (SDP) for different purposes.  This framework uses the "group" and "mid" SDP attributes, both of which are defined in this specification.  Additionally, we specify how to -09">
        <t>Removed "wms-semantic" use the framework for two different purposes: for lip synchronization and all mention for receiving a media flow consisting of multiple semantics several media streams on different transport addresses.  This document obsoletes RFC 3388. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5888"/>
          <seriesInfo name="DOI" value="10.17487/RFC5888"/>
        </reference>
        <reference anchor="RFC7656" target="https://www.rfc-editor.org/info/rfc7656" quoteTitle="true" derivedAnchor="RFC7656">
          <front>
            <title>A Taxonomy of Semantics and Mechanisms for
        msid, as agreed at the Dallas IETF, March 2015.</t>

        <t>Addressed Real-Time Transport Protocol (RTP) Sources</title>
            <author initials="J." surname="Lennox" fullname="J. Lennox">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Gross" fullname="K. Gross">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Nandakumar" fullname="S. Nandakumar">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Salgueiro" fullname="G. Salgueiro">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Burman" fullname="B. Burman" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="November"/>
            <abstract>
              <t indent="0">The terminology about, and associations among, Real-time Transport Protocol (RTP) sources can be complex and somewhat opaque.  This document describes a number of review comments from Fleming Andresen existing and
        others.</t>

        <t>Changed the term "m-line" to "media description", since that is the
        term used in RFC 4566.</t>

        <t>Tried to make sure this document does not describe the API to proposed properties and relationships among RTP sources and defines common terminology for discussing protocol entities and their relationships.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7656"/>
          <seriesInfo name="DOI" value="10.17487/RFC7656"/>
        </reference>
        <reference anchor="RFC8825" target="https://www.rfc-editor.org/info/rfc8825" quoteTitle="true" derivedAnchor="RFC8825">
          <front>
            <title>Overview: Real-Time Protocols for Browser-Based Applications</title>
            <author initials="H." surname="Alvestrand" fullname="Harald T. Alvestrand">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8825"/>
          <seriesInfo name="DOI" value="10.17487/RFC8825"/>
        </reference>
        <reference anchor="RFC8843" target="https://www.rfc-editor.org/info/rfc8843" quoteTitle="true" derivedAnchor="RFC8843">
          <front>
            <title>Negotiating Media Multiplexing Using the
        application.</t>
      </section>

      <section title="Changes from -09 to -10">
        <t>Addressed review comments from Paul Kyzivat.</t>
      </section> Session Description Protocol (SDP)</title>
            <author initials="C" surname="Holmberg" fullname="Christer Holmberg">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H" surname="Alvestrand" fullname="Harald Alvestrand">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C" surname="Jennings" fullname="Cullen Jennings">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2021"/>
          </front>
          <seriesInfo name="RFC" value="8843"/>
          <seriesInfo name="DOI" value="10.17487/RFC8843"/>
        </reference>
        <reference anchor="WEBIDL" target="https://heycam.github.io/webidl/" quoteTitle="true" derivedAnchor="WEBIDL">
          <front>
            <title>Web IDL</title>
            <author initials="E." surname="Chen" fullname="Edgar Chen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Gu" fullname="Tiancheng Gu">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="August" year="2020"/>
          </front>
          <refcontent>W3C Editor's Draft</refcontent>
        </reference>
      </references>
    </references>
    <section title="Changes from -10 numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-design-considerations-rejec">Design Considerations, Rejected Alternatives</name>
      <t indent="0" pn="section-appendix.a-1">One suggested mechanism has been to -11">
        <t>Defined the semantics use CNAME instead of multiple MSIDs in a media section to be new
      attribute. This was abandoned because CNAME identifies a
        MediaStreamTrack present in multiple MediaStreams.</t>

        <t>Made an explicit note that MediaStreamTracks are
        unidirectional.</t>

        <t>Disallowed the option of sending multiple media sections with synchronization
      context; one can imagine both wanting to have tracks from the same msid (id
      synchronization context in multiple MediaStreams and appdata identical).</t>
      </section>

      <section title="Changes from -11 to -12">
        <t>Added mux-category wanting to the IANA considerations section.</t>
      </section>

      <section title="Changes have
      tracks from -12 to -13">
        <t>Modified registration description multiple synchronization contexts within one MediaStream
      (but the latter is impossible, since a MediaStream is defined to delete dependency impose
      synchronization on
        -4566-bis</t>
      </section>

      <section title="Changes from -13 to -14">
        <t>Addressed nits found in Gen-ART review</t>
      </section>

      <section title="Changes from -14 its members).</t>
      <t indent="0" pn="section-appendix.a-2">Another suggestion has been to -15">
        <t>Added put the terminology section. Switched from "(RTP) media stream"
        to "RTP stream" per RFC 7656.</t>

        <t>Added a mention "msid" value within an attribute
      of random ID generation to RTCP SR (sender report) packets. This doesn't offer the security
        considerations section.</t>

        <t>Moved definition pointers for MediaStream and MediaStreamTrack ability to
      know that you have seen all the "mediacapture-streams" document.</t>

        <t>Added note tracks currently configured for a
      MediaStream.</t>
      <t indent="0" pn="section-appendix.a-3">A suggestion that syntactically invalid survived for a number of drafts of this document was to define
      MSID fields SHOULD as a generic mechanism, where the particular semantics of this
      usage of the mechanism would be
        ignored.</t>

        <t>Various small changes based on review feedback during IESG
        processing.</t> defined by an "a=wms-semantic"
      attribute. This was removed in April 2015.</t>
    </section>
    <section title="Changes from -15 to -16">
        <t>Added the special "-" value that means "no MediaStream".</t>

        <t>Changed instances of a MediaStreamTrack being "closed" anchor="Acknowledgements" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.b-1">This note is based on sketches from, among others, <contact fullname="Justin Uberti"/> and
      <contact fullname="Cullen Jennings"/>.</t>
      <t indent="0" pn="section-appendix.b-2">Special thanks to saying
        it's "ended", <contact fullname="Flemming Andreasen"/>, <contact fullname="Ben Campbell"/>, <contact fullname="Miguel Garcia"/>,
      <contact fullname="Martin Thomson"/>, <contact fullname="Ted Hardie"/>,
	<contact fullname="Adam Roach"/>, <contact fullname="Magnus Westerlund"/>,
	  <contact fullname="Alissa Cooper"/>, <contact fullname="Sue    Hares"/>, and <contact fullname="Paul Kyzivat"/> for their work in accordance
	  reviewing this document, with WebRTC terminology.</t> many specific language suggestions.</t>
    </section>
    <section title="Changes from -16 to -17">
	<t>Added text to allow omitting track identifiers, per JSEP PR #850
	</t>
      </section> anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-address">Author's Address</name>
      <author fullname="Harald Alvestrand" initials="H." surname="Alvestrand">
        <organization showOnFrontPage="true">Google</organization>
        <address>
          <postal>
            <street>Kungsbron 2</street>
            <city>Stockholm</city>
            <region/>
            <code>11122</code>
            <country>Sweden</country>
          </postal>
          <email>harald@alvestrand.no</email>
        </address>
      </author>
    </section>
  </back>
</rfc>