<?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"
     number="8830" docName="draft-ietf-mmusic-msid-17" ipr="trust200902"> ipr="trust200902" obsoletes=""
     updates="" submissionType="IETF" xml:lang="en" tocInclude="true"
     symRefs="true" sortRefs="true" version="3" consensus="true">

  <!-- xml2rfc v2v3 conversion 2.32.0 -->
    <title abbrev="MSID in SDP">WebRTC MediaStream Identification in the
    Session Description Protocol</title>
    <seriesInfo name="RFC" value="8830"/>
    <author fullname="Harald Alvestrand" initials="H. T." initials="H." surname="Alvestrand">
          <street>Kungsbron 2</street>
    <date day="13" month="December" year="2018"/> month="August" year="2020"/>


      <t>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 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" /
      MediaStream/MediaStreamTrack using SDP signaling.</t>

      <t>This document is a work item of the MMUSIC WG, whose discussion list
      is mmusic@ietf.org.</t>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119">RFC 2119</xref>.</t>
    <section title="Introduction">

      <section title="Terminology"> numbered="true" toc="default">
      <section numbered="true" toc="default">
        <t>This document uses terminology from <xref
	target="RFC8825" format="default"/>. 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">
          <dt>RTP stream:</dt> <dd>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"
          <dd>An assembly of
            MediaStreamTracks <xref target="W3C.CR-mediacapture-streams" format="default"/>. One MediaStream can contain multiple
            MediaStreamTracks, of the same or different types.</t>

            <t hangText="MediaStreamTrack">Defined types.</dd>
          <dd>Defined in <xref
            target="W3C.CR-mediacapture-streams-20160519"/>as an target="W3C.CR-mediacapture-streams" format="default"/> as a
            unidirectional flow of media data (either audio or video, but not
            both). Corresponds to the <xref target="RFC7656"/> target="RFC7656" format="default"/> 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>Media description:</dt>
          <dd>Defined in <xref
            target="RFC4566"/> target="RFC4566" format="default"/> 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>

    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"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.

       <section title="Structure Of numbered="true" toc="default">
        <name>Structure of This Document"> Document</name>
        <t>This document adds a new Session Description Protocol (SDP) <xref
        target="RFC4566"/> target="RFC4566" format="default"/> 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> WebRTC <xref target="RFC8825" format="default"/>.</t>
        <t><xref target="sect-why"/> target="sect-why" format="default"/> gives the background on why a new
        mechanism is needed.</t>
        <t><xref target="sect-definition"/> target="sect-definition" format="default"/> gives the definition of the new
        <t><xref target="sect-media-stream"/> target="sect-media-stream" format="default"/> 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"/>.</t>
      <section anchor="sect-why" title="Why A numbered="true" toc="default">
        <name>Why a New Mechanism Is Needed"> Needed</name>

        <t>When media is carried by RTP <xref target="RFC3550"/>, target="RFC3550"
	format="default"/>, 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"/> is used).</t>

        <t>SDP <xref target="RFC4566"/> target="RFC4566" format="default"/> 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"/>, 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"/>; if BUNDLE is
        not used, each media source is carried in its own RTP session.</t>
        <t>The SDP grouping framework Grouping Framework <xref target="RFC5888"/> target="RFC5888" format="default"/> 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 title="The WEBRTC MediaStream"> numbered="true" toc="default">
        <name>The WebRTC MediaStream</name>
        <t>The W3C WebRTC API specification <xref
        target="W3C.WD-webrtc-20160531"/> target="W3C-WebRTC" format="default"/> 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 are unidirectional; they carry media on in one
        direction only.</t>
        <t>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
        <t>WebRTC defines a mapping (documented in <xref
        target="I-D.ietf-rtcweb-jsep"/>) target="RFC8829" format="default"/>) where one SDP media description is
        used to describe each MediaStreamTrack, and the BUNDLE mechanism <xref
	target="RFC8843" format="default"/> 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
        <t>This usage is described in <xref target="sect-media-stream"/>.</t> target="sect-media-stream" format="default"/>.</t>

    <section anchor="sect-definition" title="The Msid Mechanism"> numbered="true" toc="default">

      <name>The MSID Mechanism</name>
      <t>This document defines a new SDP <xref target="RFC4566"/> target="RFC4566" format="default"/> media-level
      "msid" attribute.
   This new attribute allows endpoints to associate RTP
   streams that are described in different separate media descriptions with the same
   right MediaStreams, as defined in <xref target="W3C.WD-webrtc-20160531"/>, and target="W3C-WebRTC"
      format="default"/>. It also allows endpoints to carry an identifier for
      each MediaStreamTrack in its "appdata" field.</t>
      <t>The value of the "msid" attribute consists of an identifier and an
      optional "appdata" field.</t>
      <t>The name of the attribute is "msid".</t>
      <t>The value of the attribute is specified by the following ABNF <xref
      target="RFC5234" format="default"/> grammar:</t>



<sourcecode type="abnf" >
  msid-value = msid-id [ SP msid-appdata ]
  msid-id = 1*64token-char ; see RFC 4566
  msid-appdata = 1*64token-char  ; see RFC 4566

      <t>An example msid "msid" value for a group with the identifier "examplefoo"
      and application data "examplebar" might look like this:</t>


  msid:examplefoo examplebar


      <t>The identifier is a string of ASCII characters that are legal in a
      "token", consisting of between 1 and 64 characters.</t>
      <t>Application data (msid-appdata) is carried on the same line as the
      identifier, separated from the identifier by a space.</t>
      <t>The identifier (msid-id) ("msid-id") uniquely identifies a group within the scope
      of an SDP description.</t>
      <t>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> occurrences.</t>
      <t>Multiple media descriptions with the same value for msid-id "msid-id" and
      "msid&nbhy;appdata" are not permitted.</t>
      <t>Endpoints can update the associations between RTP streams as
      expressed by msid "msid" attributes at any time.</t>
      <t>The msid "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"/>) 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 anchor="sect-media-stream" title="Procedures"> numbered="true" toc="default">
      <t>This section describes the procedures for associating media
      descriptions representing MediaStreamTracks within MediaStreams MediaStreams, as
      defined in <xref target="W3C.WD-webrtc-20160531"/>.</t> target="W3C-WebRTC" format="default"/>.</t>

      <t>In the Javascript API described in that specification, each
      MediaStream and MediaStreamTrack has an "id" attribute, which is a

      <t>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 <xref target="WEBIDL" format="default"/>. The special value "-" indicates "no MediaStream".</t>
      <t>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 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 the MSID "msid" attribute does not conform to the ABNF given here, it
      <bcp14>SHOULD</bcp14> be ignored.</t>

      <t>The following is a high level high-level description of the rules for handling
      SDP updates. Detailed procedures are located in <xref

      <t><list style="symbols">
      target="s-detailed-procedures" format="default"/>.</t>
      <ul spacing="normal">
        <li>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>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

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

      <t>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" />, Sections <xref target="RFC3550"
      section="6.3.4" sectionFormat="bare"/>
       (BYE packet received) and 6.3.5 <xref
       target="RFC3550" section="6.3.5" sectionFormat="bare"/>
       (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 association between SSRCs and media descriptions is specified in
      <xref target="I-D.ietf-rtcweb-jsep"/>.</t> target="RFC8829" format="default"/>.</t>

      <section anchor="s-nonsignal" title="Handling numbered="true" toc="default">
        <name>Handling of non-signalled tracks"> Nonsignaled Tracks</name>
        <t>Entities that do not use msid the mechanism described in this document will not send msid. the
	"msid" attribute and thus will not send 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> ID value.</t>

        <t>Note that this the handling described below is triggered by incoming RTP packets, not
        SDP negotiation.</t>

        <t>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 recipient of those packets will perform the following

        <t><list style="symbols">
        <ul spacing="normal">

          <li>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"/> (if
            present) to associate the RTP packets with a specific media

          <li>If the connection is not in the RTCSignalingState "stable", it
            will wait at this point.</t>

            <t>When point.</li>
          <li>When the connection is in the RTCSignalingState "stable", it
            will assign ID values.</t>
          </list></t> values.</li>
        <t>The following steps are performed to assign ID values:</t>

        <t><list style="symbols">
        <ul spacing="normal">
          <li>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>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>After deciding on the "id" field to be applied to the
            MediaStreamTrack, the track will be signalled signaled to the user.</t>
          </list></t> user.</li>
        <t>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
        <t>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, either according to the rules of RFC 3550 section 6.3.4 Sections <xref target="RFC3550" section="6.3.4"
	sectionFormat="bare" /> and 6.3.5  <xref target="RFC3550" section="6.3.5"
	sectionFormat="bare" /> of <xref target="RFC3550"
	/> or by disabling the media
	description by setting its port to zero.</t>
      <section anchor="s-detailed-procedures"
               title="Detailed numbered="true" toc="default">
        <name>Detailed Offer/Answer Procedures"> Procedures</name>

        <t>These procedures are given in terms of RFC 3264-recommended
        sections. sections recommended by
	<xref target="RFC3264"/>. They describe the actions to be taken in terms of
        MediaStreams and MediaStreamTracks; they do not include event
        signaling inside the application, which is described in JSEP.</t> the JavaScript
	Session Establishment Protocol (JSEP) <xref target="RFC8829"/>.</t>
        <section title="Generating numbered="true" toc="default">
          <name>Generating the initial offer"> Initial Offer</name>
          <t>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 title="Answerer processing numbered="true" toc="default">
          <name>Answerer Processing of the Offer"> Offer</name>
          <t>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">
          <ul spacing="normal">
            <li>Extract the "appdata" field of the "a=msid" attribute,
	    if present.</t>

            <t>If present.</li>
            <li>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>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>Extract the "identifier" field of the "a=msid" attribte.</t>

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

              <t>Add it.</li>
            <li>Add the MediaStreamTrack to the MediaStream</t>

              <t>Signal MediaStream.</li>
            <li>Signal to the user that a new MediaStreamTrack is
        <section title="Generating numbered="true" toc="default">
          <name>Generating the answer"> Answer</name>
          <t>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 title="Offerer processing numbered="true" toc="default">
          <name>Offerer Processing of the answer"> Answer</name>
          <t>The answer is processed in exactly the same manner as the
        <section title="Modifying numbered="true" toc="default">
          <name>Modifying the session"> Session</name>
          <t>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">
          <ul spacing="normal">
            <li>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>If no such attribute is found, stop the MediaStreamTrack.
              This will set its state to "ended".</t>
            </list></t> "ended".</li>
      <section title="Example numbered="true" toc="default">
        <name>Example SDP description"> Description</name>
        <t>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 wrapping, empty lines lines, and comments are added for clarity. They
        are not part of the SDP.</t>



<sourcecode type="sdp">
# First MediaStream - id is 4701...
m=audio 56500 UDP/TLS/RTP/SAVPF 96 0 8 97 98

m=video 56502 UDP/TLS/RTP/SAVPF 100 101

# Second MediaStream - id is 6131....
m=audio 56503 UDP/TLS/RTP/SAVPF 96 0 8 97 98

m=video 56504 UDP/TLS/RTP/SAVPF 100 101



    <section anchor="IANA" title="IANA Considerations">
      <section title="Attribute registration in existing registries">
        <t>This document requests IANA to register numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section numbered="true" toc="default">
        <name>Attribute Registration in Existing Registries</name>

        <t>IANA has registered the "msid" attribute in the
        "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> target="RFC4566" format="default"/>.</t>
        <t>The required information for "msid" is:</t>

        <t><list style="symbols">
            <t>Contact registration information is as follows:</t>
          <dt>Contact name, email: IETF, email:</dt> <dd>IETF, contacted via mmusic@ietf.org, or a
            successor address designated by IESG</t>

            <t>Attribute name: msid</t>

            <t>Long-form attribute name: MediaStream group Identifier</t>

            <t>Subject IESG</dd>
          <dt>Attribute name:</dt> <dd>msid</dd>

          <dt>Attribute syntax:</dt> <dd>
          <sourcecode type="abnf"><![CDATA[
          msid-value = msid-id [ SP msid-appdata ]
          msid-id = 1*64token-char ; see RFC 4566
          msid-appdata = 1*64token-char  ; see RFC 4566 ]]>
          <dt>Attribute semantics:</dt><dd> Described in RFC 8830</dd>
          <dt>Attribute value:</dt><dd> msid-value</dd>
          <dt>Long-form attribute name:</dt> <dd>MediaStream Identifier</dd>
          <dt>Usage level:</dt> <dd>media</dd>
          <dt>Subject to charset: The charset:</dt> <dd>The attribute value contains only ASCII
            characters and is therefore not subject to the charset

            <t>Purpose: The
          <dt>Purpose:</dt> <dd>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>O/A Procedures:</dt><dd> Described in RFC 8830</dd>
          <dt>Appropriate values:</dt> <dd>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>Mux Category:</dt> <dd>NORMAL</dd>
        <t>The Mux Category is defined in <xref
        target="I-D.ietf-mmusic-sdp-mux-attributes"/>.</t> target="RFC8859" format="default"/>.</t>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>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
      <t>If implementing buffering as mentioned in <xref
      target="s-nonsignal"/>, target="s-nonsignal" format="default"/>, the amount of buffering should be limited to
      avoid memory exhaustion attacks.</t>
      <t>Careless generation of identifiers can leak privacy-sensitive
      information. <xref target="W3C.CR-mediacapture-streams-20160519"/> target="W3C.CR-mediacapture-streams" format="default"/>
      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 other attacks have been identified that depend on this

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

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


        <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.8174.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"/>

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

        <reference anchor="W3C.CR-mediacapture-streams"
            <title>Media Capture and Streams</title>
            <author initials="D." surname="Burnett" fullname="Daniel Burnett">
            <author initials="A." surname="Bergkvist" fullname="Adam Bergkvist">
            <author initials="C." surname="Jennings" fullname="Cullen Jennings">
            <author initials="A." surname="Narayanan" fullname="Anant Narayanan">
            <author initials="B." surname="Aboba" fullname="Bernard Aboba">
            <author initials="J.-I." surname="Bruaroey" fullname="Jan-Ivar Bruaroey">
            <author initials="H" surname="Boström" fullname="Henrik Boström">
            <date month="July" day="2" year="2019"/>
            <refcontent>W3C Candidate Recommendation</refcontent>

<!-- draft-ietf-rtcweb-jsep; RFC 8829 -->
 <reference anchor="RFC8829" target="https://www.rfc-editor.org/info/rfc8829">
 <title>JavaScript Session Establishment Protocol (JSEP)</title>
 <author initials='J.' surname='Uberti' fullname='Justin Uberti'>
 <author initials="C." surname="Jennings" fullname="Cullen Jennings">
 <author initials="E." surname="Rescorla" fullname="Eric Rescorla"
 <date month='July' year='2020'/>
 <seriesInfo name="RFC" value="8829"/>
 <seriesInfo name="DOI" value="10.17487/RFC8829"/>

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

        <name>Informative References</name>
        <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.5761.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5888.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7656.xml"/>

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

<!-- draft-ietf-rtcweb-overview: RFC 8825 -->
<reference anchor="RFC8825" target="https://www.rfc-editor.org/info/rfc8825">
    <title>Overview: Real-Time Protocols for Browser-Based Applications</title>
    <author initials="H." surname="Alvestrand" fullname="Harald T. Alvestrand">
      <organization />
    <date month="July" year="2020" />
  <seriesInfo name="RFC" value="8825" />
  <seriesInfo name="DOI" value="10.17487/RFC8825"/>

<reference anchor="WEBIDL" target="https://heycam.github.io/webidl/">
    <title>Web IDL</title>
    <author initials="E." surname="Chen" fullname="Edgar Chen">
      <organization />
    <author initials="T." surname="Gu" fullname="Tiancheng Gu">
      <organization />
    <date month="August" year="2020" />
  <refcontent>W3C Editor's Draft</refcontent>


    <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'?>
    <section title="Design considerations, rejected alternatives"> numbered="true" toc="default">
      <name>Design Considerations, Rejected Alternatives</name>
      <t>One suggested mechanism has been to 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 to impose
      synchronization on its members).</t>
      <t>Another suggestion has been to put the msid "msid" value within an attribute
      of RTCP SR (sender report) packets. This doesn't offer the ability to
      know that you have seen all the tracks currently configured for a
      <t>A suggestion that survived for a number of drafts of this document was to define
      MSID as a generic mechanism, where the particular semantics of this
      usage of the mechanism would be defined by an "a=wms-semantic"
      attribute. This was removed in April 2015.</t>

    <section title="Change log"> anchor="Acknowledgements" numbered="false" toc="default">
      <t>This appendix should be deleted before publication as an RFC.</t>

      <section title="Changes from alvestrand-rtcweb-msid-00 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 title="Changes from alvestrand-rtcweb-msid-01 to -02">
        <t>Split document into sections describing a generic grouping
        mechanism and sections describing the application of this grouping
        mechanism to the WebRTC MediaStream concept.</t>

        <t>Removed the mechanism for muting tracks, since this note is not central
        to the MSID mechanism.</t>

      <section title="Changes from alvestrand-rtcweb-msid-02 to mmusic-msid-00">
        <t>Changed the draft name according to the wishes of the MMUSIC group

        <t>Added text indicting cases where it's appropriate to have the same
        appdata for multiple SSRCs.</t>

        <t>Minor textual updates.</t>

      <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 sketches from, among others, <contact fullname="Justin Uberti"/> and
      <contact fullname="Cullen Jennings"/>.</t>
      <t>Special thanks to BUNDLE, since that spec is under active

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

      <section title="Changes from alvestrand-mmusic-msid-01 to -02">
        <t>Changed the order of the "msid-semantic: " attribute's value fields
        and allowed multiple identifiers. This makes the attribute useful as a
        marker for "I understand this semantic".</t>

        <t>Changed the syntax <contact fullname="Flemming Andreassen"/>, <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 "identifier" and "appdata" to be

        <t>Changed the registry for the "msid-semantic" attribute values to be
        a new registry, based on advice given in Atlanta.</t>

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

        <t>Changed the "default" mechanism to return independent streams after
        considering the synchronization problem.</t>

        <t>Removed the space from between "msid-semantic" and its value, to be
        consistent with RFC 5576.</t>

      <section title="Changes from mmusic-msid-00 to -01">
        <t>Reworked msid mechanism to be a per-m-line attribute, to align with

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

        <t>Added pointer to unified-plan (which should be moved to point to

        <t>Removed suggestion that ssrc-group attributes can be used with
        "msid-semantic", it is now only the msid-semantic registry.</t>

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

        <t>Added the functionality of using an asterisk (*) in the
        msid-semantic line, in order to remove the need for listing all msids
        in the msid-semantic line whne only one msid-semantic is in use.</t>

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

      <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 the
        "msid-control" attribute.</t>

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

        <t>Removed some text that seemed only to pertain to resolved

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

        <t>Referenced JSEP rather than unified-plan for the M-line mapping

        <t>Relaxed MSID definition to allow "token-char" in values rather than
        a-z 0-9 hyphen; tightened ABNF by adding length description to it.</t>

        <t>Deleted discussion of abandoned alternatives, as part of preparing
        for publication.</t>

        <t>Added a "detailed procedures" section to the WMS semantics

        <t>Added IANA registration of the "msid-semantic" attribute.</t>

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

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

        <t>Included a section on generic offer/answer semantics.</t>

      <section title="Changes from -07 to -08">
        <t>Removed Appendix B that described the (now obsolete) ssrc-specific
        usage of MSID.</t>

        <t>Adopted a restructuring of the IANA section based on a suggestion
        from Martin Thomson.</t>

        <t>A number of text and ABNF clarifications based on suggestions from
        Ted Hardie, Paul Kyzivat and Adam Roach.</t>

        <t>Changed the "non-signalled track handling" to create a single
        stream with multiple tracks again, according to discussions at TPAC in
        November 2014</t>

      <section title="Changes from -08 to -09">
        <t>Removed "wms-semantic" and all mention of multiple semantics for
        msid, as agreed at the Dallas IETF, March 2015.</t>

        <t>Addressed a number of review comments from Fleming Andresen and

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

        <t>Tried to make sure
	  reviewing this document does not describe the API to the

      <section title="Changes from -09 to -10">
        <t>Addressed review comments from Paul Kyzivat.</t>

      <section title="Changes from -10 to -11">
        <t>Defined the semantics of multiple MSIDs in a media section to be a
        MediaStreamTrack present in multiple MediaStreams.</t>

        <t>Made an explicit note that MediaStreamTracks are

        <t>Disallowed the option of sending multiple media sections document, with the
        same msid (id and appdata identical).</t>

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

      <section title="Changes from -12 to -13">
        <t>Modified registration description to delete dependency on

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

      <section title="Changes from -14 to -15">
        <t>Added the terminology section. Switched from "(RTP) media stream"
        to "RTP stream" per RFC 7656.</t>

        <t>Added a mention of random ID generation to the security
        considerations section.</t>

        <t>Moved definition pointers for MediaStream and MediaStreamTrack to
        the "mediacapture-streams" document.</t>

        <t>Added note that syntactically invalid MSID fields SHOULD be

        <t>Various small changes based on review feedback during IESG

      <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" to saying
        it's "ended", in accordance with WebRTC terminology.</t>
      <section title="Changes from -16 to -17">
	<t>Added text to allow omitting track identifiers, per JSEP PR #850
      </section> many specific language suggestions.</t>