rfc8830xml2.original.xml   rfc8830.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
<?rfc toc="yes"?> nsus="true" docName="draft-ietf-mmusic-msid-17" indexInclude="true" ipr="trust20
<?rfc tocompact="yes"?> 0902" number="8830" prepTime="2021-01-16T21:13:18" scripts="Common,Latin" sortRe
<?rfc tocdepth="3"?> fs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xm
<?rfc tocindent="yes"?> l:lang="en">
<?rfc symrefs="yes"?> <link href="https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid-17" rel="p
<?rfc sortrefs="yes"?> rev"/>
<?rfc comments="yes"?> <link href="https://dx.doi.org/10.17487/rfc8830" rel="alternate"/>
<?rfc inline="yes"?> <link href="urn:issn:2070-1721" rel="alternate"/>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-mmusic-msid-17" ipr="trust200902">
<front> <front>
<title abbrev="MSID in SDP">WebRTC MediaStream Identification in the <title abbrev="MSID in SDP">WebRTC MediaStream Identification in the Session
Session Description Protocol</title> Description Protocol</title>
<seriesInfo name="RFC" value="8830" stream="IETF"/>
<author fullname="Harald Alvestrand" initials="H. T." surname="Alvestrand"> <author fullname="Harald Alvestrand" initials="H." surname="Alvestrand">
<organization>Google</organization> <organization showOnFrontPage="true">Google</organization>
<address> <address>
<postal> <postal>
<street>Kungsbron 2</street> <street>Kungsbron 2</street>
<city>Stockholm</city> <city>Stockholm</city>
<region/> <region/>
<code>11122</code> <code>11122</code>
<country>Sweden</country> <country>Sweden</country>
</postal> </postal>
<email>harald@alvestrand.no</email> <email>harald@alvestrand.no</email>
</address> </address>
</author> </author>
<date month="01" year="2021"/>
<date day="13" month="December" year="2018"/> <keyword>example</keyword>
<keyword>MSID</keyword>
<abstract> <abstract pn="section-abstract">
<t>This document specifies a Session Description Protocol (SDP) Grouping <t indent="0" pn="section-abstract-1">This document specifies a Session De
scription Protocol (SDP) grouping
mechanism for RTP media streams that can be used to specify relations mechanism for RTP media streams that can be used to specify relations
between media streams.</t> between media streams.</t>
<t indent="0" pn="section-abstract-2">This mechanism is used to signal the
<t>This mechanism is used to signal the association between the SDP association between the SDP
concept of "media description" and the WebRTC concept of "MediaStream" / concept of "media description" and the Web Real-Time Communication (WebRTC
"MediaStreamTrack" using SDP signaling.</t> ) concept of
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>
</abstract> </abstract>
<boilerplate>
<note title="Requirements Language"> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "exclude" pn="section-boilerplate.1">
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this <name slugifiedName="name-status-of-this-memo">Status of This Memo</name
document are to be interpreted as described in <xref >
target="RFC2119">RFC 2119</xref>.</t> <t indent="0" pn="section-boilerplate.1-1">
</note> This is an Internet Standards Track document.
</t>
<t indent="0" pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
</t>
<t indent="0" pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc8830" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" pn="section-toc.1-1.1.1"><xref derivedContent="1" form
at="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-introduction">Introduction</xref><
/t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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-te
rminology">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-st
ructure-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-wh
y-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 derived
Content="" 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" form
at="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-the-msid-mechanism">The MSID Mecha
nism</xref></t>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-procedures">Procedures</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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 derived
Content="" format="title" sectionFormat="of" target="name-handling-of-nonsignale
d-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 derived
Content="" 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="se
ction-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 derived
Content="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 derived
Content="3.2.2" format="counter" sectionFormat="of" target="section-3.2.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-answerer-p
rocessing-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 derived
Content="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 derived
Content="3.2.4" format="counter" sectionFormat="of" target="section-3.2.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-offerer-pr
ocessing-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 derived
Content="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 derived
Content="" format="title" sectionFormat="of" target="name-example-sdp-descriptio
n">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" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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 derived
Content="" 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" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="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" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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 derived
Content="" 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 derived
Content="" 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="Appendi
x A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref d
erivedContent="" format="title" sectionFormat="of" target="name-design-considera
tions-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="" forma
t="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent=""
format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgemen
ts</xref></t>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" forma
t="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent=""
format="title" sectionFormat="of" target="name-authors-address">Author's Addres
s</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
<t/> <name slugifiedName="name-introduction">Introduction</name>
<section numbered="true" toc="include" removeInRFC="false" pn="section-1.1
<section title="Terminology"> ">
<t>This document uses terminology from <xref <name slugifiedName="name-terminology">Terminology</name>
target="I-D.ietf-rtcweb-overview"/>. In addition, the following terms <t indent="0" pn="section-1.1-1">This document uses terminology from <xr
are used as described below:</t> ef target="RFC8825" format="default" sectionFormat="of" derivedContent="RFC8825"
/>. In addition, the
<t><list style="hanging"> following terms are used as described below:</t>
<t hangText="RTP stream">Defined in <xref target="RFC7656"/> as a <dl newline="false" spacing="normal" indent="3" pn="section-1.1-2">
stream of RTP packets containing media data.</t> <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 hangText="MediaStream">Defined in <xref <xref target="RFC7656" format="default" sectionFormat="of" derivedContent="RFC7
target="W3C.CR-mediacapture-streams-20160519"/>as an assembly of 656"/>.</dd>
MediaStreamTracks. One MediaStream can contain multiple <dt pn="section-1.1-2.3">MediaStream:</dt>
MediaStreamTracks, of the same or different types.</t> <dd pn="section-1.1-2.4">An assembly of
MediaStreamTracks <xref target="W3C.CR-mediacapture-streams" format=
<t hangText="MediaStreamTrack">Defined in <xref "default" sectionFormat="of" derivedContent="W3C.CR-mediacapture-streams"/>. One
target="W3C.CR-mediacapture-streams-20160519"/>as an MediaStream can contain multiple
MediaStreamTracks, of the same or different 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" format="default" sectionFormat="of" derivedContent="W3C.CR-mediacapture
-streams"/> as a
unidirectional flow of media data (either audio or video, but not unidirectional flow of media data (either audio or video, but not
both). Corresponds to the <xref target="RFC7656"/> term "Source both). Corresponds to the <xref target="RFC7656" format="default" se
Stream". One MediaStreamTrack can be present in zero, one or ctionFormat="of" derivedContent="RFC7656"/> term "source
multiple MediaStreams.</t> stream". One MediaStreamTrack can be present in zero, one, or
multiple MediaStreams.</dd>
<t hangText="Media description">Defined in <xref <dt pn="section-1.1-2.7">Media description:</dt>
target="RFC4566"/> as a set of fields starting with an "m=" field <dd pn="section-1.1-2.8">Defined in <xref target="RFC4566" format="def
and terminated by eitehr the next "m=" field or by the end of the ault" sectionFormat="of" derivedContent="RFC4566"/> as a set of
session description.</t> fields starting with an "m=" field
</list></t> and terminated by either the next "m=" field or the end of the
session 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" s
ectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="defa
ult" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they app
ear in all capitals, as
shown here.
</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-1.2
<section title="Structure Of This Document"> ">
<t>This document adds a new Session Description Protocol (SDP) <xref <name slugifiedName="name-structure-of-this-document">Structure of This
target="RFC4566"/> mechanism that can attach identifiers to the RTP Document</name>
streams and attaching identifiers to the groupings they form. It is <t indent="0" pn="section-1.2-1">This document adds a new Session Descri
designed for use with WebRTC<xref target="I-D.ietf-rtcweb-overview"/> ption Protocol (SDP) <xref target="RFC4566" format="default" sectionFormat="of"
.</t> derivedContent="RFC4566"/> mechanism that can attach identifiers to the RTP
streams and attach identifiers to the groupings they form. It is
<t><xref target="sect-why"/> gives the background on why a new designed for use with WebRTC <xref target="RFC8825" format="default" sec
tionFormat="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> mechanism is needed.</t>
<t indent="0" pn="section-1.2-3"><xref target="sect-definition" format="
<t><xref target="sect-definition"/> gives the definition of the new default" sectionFormat="of" derivedContent="Section 2"/> gives the definition of
the new
mechanism.</t> mechanism.</t>
<t indent="0" pn="section-1.2-4"><xref target="sect-media-stream" format
<t><xref target="sect-media-stream"/> gives the necessary semantic ="default" sectionFormat="of" derivedContent="Section 3"/> gives the necessary s
information and procedures for using the msid attribute to signal the emantic
information and procedures for using the "msid" attribute to signal the
association of MediaStreamTracks to MediaStreams in support of the association of MediaStreamTracks to MediaStreams in support of the
WebRTC API <xref target="W3C.WD-webrtc-20160531"/>.</t> WebRTC API <xref target="W3C-WebRTC" format="default" sectionFormat="of" derivedContent="W3C-WebRTC"/>.</t>
</section> </section>
<section anchor="sect-why" numbered="true" toc="include" removeInRFC="fals
<section anchor="sect-why" title="Why A New Mechanism Is Needed"> e" pn="section-1.3">
<t>When media is carried by RTP <xref target="RFC3550"/>, each RTP <name slugifiedName="name-why-a-new-mechanism-is-need">Why a New Mechani
stream is distinguished inside an RTP session by its SSRC; each RTP sm Is Needed</name>
<t indent="0" pn="section-1.3-1">When media is carried by RTP <xref targ
et="RFC3550" format="default" sectionFormat="of" derivedContent="RFC3550"/>, eac
h RTP stream is distinguished inside an RTP
session by its Synchronization Source (SSRC); each RTP
session is distinguished from all other RTP sessions by being on a session is distinguished from all other RTP sessions by being on a
different transport association (strictly speaking, 2 transport different transport association (strictly speaking, two transport
associations, one used for RTP and one used for RTCP, unless RTP/RTCP associations, one used for RTP and one used for the RTP Control Protocol
multiplexing <xref target="RFC5761"/> is used).</t> (RTCP), unless RTP/RTCP multiplexing <xref target="RFC5761" format="defau
lt" sectionFormat="of" derivedContent="RFC5761"/> is used).</t>
<t>SDP <xref target="RFC4566"/> gives a format for describing an SDP <t indent="0" pn="section-1.3-2">SDP <xref target="RFC4566" format="defa
ult" sectionFormat="of" derivedContent="RFC4566"/> gives a format for describing
an SDP
session that can contain multiple media descriptions. According to the session that can contain multiple media descriptions. According to the
model used in <xref target="I-D.ietf-rtcweb-jsep"/>, each media model used in <xref target="RFC8829" format="default" sectionFormat="of"
description describes exactly one media source, and if multiple media derivedContent="RFC8829"/>, each media
sources are carried in an RTP session, this is signalled using BUNDLE description describes exactly one media source. If multiple media
<xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"/>; if BUNDLE is sources are carried in an RTP session, this is signaled using BUNDLE
<xref target="RFC8843" format="default" sectionFormat="of" derivedConten
t="RFC8843"/>; if BUNDLE is
not used, each media source is carried in its own RTP session.</t> not used, each media source is carried in its own RTP session.</t>
<t indent="0" pn="section-1.3-3">The SDP Grouping Framework <xref target
<t>The SDP grouping framework <xref target="RFC5888"/> can be used to ="RFC5888" format="default" sectionFormat="of" derivedContent="RFC5888"/> can be
used to
group media descriptions. However, for the use case of WebRTC, there group media descriptions. However, for the use case of WebRTC, there
is the need for an application to specify some application-level is the need for an application to specify some application-level
information about the association between the media description and information about the association between the media description and
the group. This is not possible using the SDP grouping framework.</t> the group. This is not possible using the SDP Grouping Framework.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-1.4
<section title="The WEBRTC MediaStream"> ">
<t>The W3C WebRTC API specification <xref <name slugifiedName="name-the-webrtc-mediastream">The WebRTC MediaStream
target="W3C.WD-webrtc-20160531"/> specifies that communication between </name>
<t indent="0" pn="section-1.4-1">The W3C WebRTC API specification <xref
target="W3C-WebRTC" format="default" sectionFormat="of" derivedContent="W3C-WebR
TC"/> specifies that communication between
WebRTC entities is done via MediaStreams, which contain WebRTC entities is done via MediaStreams, which contain
MediaStreamTracks. A MediaStreamTrack is generally carried using a MediaStreamTracks. A MediaStreamTrack is generally carried using a
single SSRC in an RTP session (forming an RTP stream. The collision of single SSRC in an RTP session, forming an RTP stream. The collision of
terminology is unfortunate.) There might possibly be additional SSRCs, terminology is unfortunate. There might possibly be additional SSRCs,
possibly within additional RTP sessions, in order to support possibly within additional RTP sessions, in order to support
functionality like forward error correction or simulcast. These functionality like forward error correction or simulcast. These
additional SSRCs are not affected by this specification.</t> additional SSRCs are not affected by this specification.</t>
<t indent="0" pn="section-1.4-2">MediaStreamTracks are unidirectional; t
<t>MediaStreamTracks are unidirectional; they carry media on one hey carry media in one
direction only.</t> direction only.</t>
<t indent="0" pn="section-1.4-3">In the RTP specification, RTP streams a
<t>In the RTP specification, RTP streams are identified using the SSRC re identified using the SSRC
field. Streams are grouped into RTP Sessions, and also carry a CNAME. field. Streams are grouped into RTP sessions and also carry a CNAME.
Neither CNAME nor RTP session correspond to a MediaStream. Therefore, Neither CNAME nor RTP session corresponds to a MediaStream. Therefore,
the association of an RTP stream to MediaStreams need to be explicitly the association of an RTP stream to MediaStreams need to be explicitly
signaled.</t> signaled.</t>
<t indent="0" pn="section-1.4-4">WebRTC defines a mapping (documented in
<t>WebRTC defines a mapping (documented in <xref <xref target="RFC8829" format="default" sectionFormat="of" derivedContent="RFC8
target="I-D.ietf-rtcweb-jsep"/>) where one SDP media description is 829"/>) where one SDP media description is
used to describe each MediaStreamTrack, and the BUNDLE mechanism <xref used to describe each MediaStreamTrack, and the BUNDLE mechanism <xref t
target="I-D.ietf-mmusic-sdp-bundle-negotiation"/> is used to group arget="RFC8843" format="default" sectionFormat="of" derivedContent="RFC8843"/> i
s
used to group
MediaStreamTracks into RTP sessions. Therefore, the need is to specify MediaStreamTracks into RTP sessions. Therefore, the need is to specify
the ID of a MediaStreamTrack and its associated MediaStream for each the identifier (ID) of the MediaStreamTrack and its associated MediaStre am for each
media description, which can be accomplished with a media-level SDP media description, which can be accomplished with a media-level SDP
attribute.</t> attribute.</t>
<t indent="0" pn="section-1.4-5">This usage is described in <xref target
<t>This usage is described in <xref target="sect-media-stream"/>.</t> ="sect-media-stream" format="default" sectionFormat="of" derivedContent="Section
3"/>.</t>
</section> </section>
</section> </section>
<section anchor="sect-definition" numbered="true" toc="include" removeInRFC=
<section anchor="sect-definition" title="The Msid Mechanism"> "false" pn="section-2">
<t>This document defines a new SDP <xref target="RFC4566"/> media-level <name slugifiedName="name-the-msid-mechanism">The MSID Mechanism</name>
"msid" attribute. This new attribute allows endpoints to associate RTP <t indent="0" pn="section-2-1">This document defines a new SDP <xref targe
streams that are described in different media descriptions with the same t="RFC4566" format="default" sectionFormat="of" derivedContent="RFC4566"/> media
MediaStreams as defined in <xref target="W3C.WD-webrtc-20160531"/>, and -level
to carry an identifier for each MediaStreamTrack in its "appdata" "msid" attribute.
field.</t> This new attribute allows endpoints to associate RTP
streams that are described in separate media descriptions with the
<t>The value of the "msid" attribute consists of an identifier and an right MediaStreams, as defined in <xref target="W3C-WebRTC" format="default"
sectionFormat="of" derivedContent="W3C-WebRTC"/>. It also allows endpoints to ca
rry an identifier for
each MediaStreamTrack in its "appdata" field.</t>
<t indent="0" pn="section-2-2">The value of the "msid" attribute consists
of an identifier and an
optional "appdata" field.</t> optional "appdata" field.</t>
<t indent="0" pn="section-2-3">The name of the attribute is "msid".</t>
<t>The name of the attribute is "msid".</t> <t indent="0" pn="section-2-4">The value of the attribute is specified by
the following ABNF <xref target="RFC5234" format="default" sectionFormat="of" de
<t>The value of the attribute is specified by the following ABNF <xref rivedContent="RFC5234"/> grammar:</t>
target="RFC5234"/> grammar:</t> <sourcecode type="abnf" markers="false" pn="section-2-5">
<t/>
<figure>
<artwork><![CDATA[
msid-value = msid-id [ SP msid-appdata ] msid-value = msid-id [ SP msid-appdata ]
msid-id = 1*64token-char ; see RFC 4566 msid-id = 1*64token-char ; see RFC 4566
msid-appdata = 1*64token-char ; see RFC 4566 msid-appdata = 1*64token-char ; see RFC 4566
</sourcecode>
]]></artwork> <t indent="0" pn="section-2-6">An example "msid" value for a group with th
</figure> e identifier "examplefoo"
<t>An example msid value for a group with the identifier "examplefoo"
and application data "examplebar" might look like this:</t> and application data "examplebar" might look like this:</t>
<sourcecode markers="false" pn="section-2-7">
<figure>
<artwork><![CDATA[
msid:examplefoo examplebar msid:examplefoo examplebar
</sourcecode>
]]></artwork> <t indent="0" pn="section-2-8">The identifier is a string of ASCII charact
</figure> ers that are legal in a
<t>The identifier is a string of ASCII characters that are legal in a
"token", consisting of between 1 and 64 characters.</t> "token", consisting of between 1 and 64 characters.</t>
<t indent="0" pn="section-2-9">Application data (msid-appdata) is carried
<t>Application data (msid-appdata) is carried on the same line as the on the same line as the
identifier, separated from the identifier by a space.</t> identifier, separated from the identifier by a space.</t>
<t indent="0" pn="section-2-10">The identifier ("msid-id") uniquely identi
<t>The identifier (msid-id) uniquely identifies a group within the scope fies a group within the scope
of an SDP description.</t> of an SDP description.</t>
<t indent="0" pn="section-2-11">There may be multiple "msid" attributes in
<t>There may be multiple msid attributes in a single media description. a single media description.
This represents the case where a single MediaStreamTrack is present in This represents the case where a single MediaStreamTrack is present in
multiple MediaStreams; the value of "msid-appdata" MUST be identical for multiple MediaStreams; the value of "msid-appdata" <bcp14>MUST</bcp14> be
all occurences.</t> identical for
all occurrences.</t>
<t>Multiple media descriptions with the same value for msid-id and <t indent="0" pn="section-2-12">Multiple media descriptions with the same
msid-appdata are not permitted.</t> value for "msid-id" and
"msid‑appdata" are not permitted.</t>
<t>Endpoints can update the associations between RTP streams as <t indent="0" pn="section-2-13">Endpoints can update the associations betw
expressed by msid attributes at any time.</t> een RTP streams as
expressed by "msid" attributes at any time.</t>
<t>The msid attributes depend on the association of RTP streams with <t indent="0" pn="section-2-14">The "msid" attributes depend on the associ
media descriptions, but does not depend on the association of RTP ation of RTP streams with
streams with RTP transports; therefore, its mux category (as defined in media descriptions but do not depend on the association of RTP
<xref target="I-D.ietf-mmusic-sdp-mux-attributes"/>) is NORMAL - the streams with RTP transports. Therefore, their Mux Category (as defined in
process of deciding on MSID attributes doesn't have to take into <xref target="RFC8859" format="default" sectionFormat="of" derivedContent=
consideration whether the RTP streams are bundled or not.</t> "RFC8859"/>) is NORMAL; the
process of deciding on "msid" attributes doesn't have to take into
consideration whether or not the RTP streams are bundled.</t>
</section> </section>
<section anchor="sect-media-stream" numbered="true" toc="include" removeInRF
<section anchor="sect-media-stream" title="Procedures"> C="false" pn="section-3">
<t>This section describes the procedures for associating media <name slugifiedName="name-procedures">Procedures</name>
descriptions representing MediaStreamTracks within MediaStreams as <t indent="0" pn="section-3-1">This section describes the procedures for a
defined in <xref target="W3C.WD-webrtc-20160531"/>.</t> ssociating media
descriptions representing MediaStreamTracks within MediaStreams, as
<t>In the Javascript API described in that specification, each defined in <xref target="W3C-WebRTC" format="default" sectionFormat="of" d
erivedContent="W3C-WebRTC"/>.</t>
<t indent="0" pn="section-3-2">In the Javascript API described in that spe
cification, each
MediaStream and MediaStreamTrack has an "id" attribute, which is a MediaStream and MediaStreamTrack has an "id" attribute, which is a
DOMString.</t> DOMString.</t>
<t indent="0" pn="section-3-3">The value of the "msid-id" field in the MSI
<t>The value of the "msid-id" field in the msid consists of the "id" D consists of the "id"
attribute of a MediaStream, as defined in the MediaStream's WebIDL attribute of a MediaStream, as defined in the MediaStream's WebIDL
specification. The special value "-" indicates "no MediaStream".</t> specification <xref target="WEBIDL" format="default" sectionFormat="of" de
rivedContent="WEBIDL"/>. The special value "-" indicates "no MediaStream".</t>
<t>The value of the "msid-appdata" field in the msid, if present, <t indent="0" pn="section-3-4">The value of the "msid-appdata" field in th
e MSID, if present,
consists of the consists of the
"id" attribute of a MediaStreamTrack, as defined in the "id" attribute of a MediaStreamTrack, as defined in the
MediaStreamTrack's WebIDL specification.</t> MediaStreamTrack's WebIDL specification.</t>
<t indent="0" pn="section-3-5">When an SDP session description is updated,
<t>When an SDP session description is updated, a specific "msid-id" a specific "msid-id"
value continues to refer to the same MediaStream, and a specific value continues to refer to the same MediaStream, and a specific
"msid-appdata" to the same MediaStreamTrack. There is no memory apart "msid-appdata" to the same MediaStreamTrack. There is no memory apart
from the currently valid SDP descriptions; if an msid "identifier" value from the currently valid SDP descriptions; if an MSID "identifier" value
disappears from the SDP and appears in a later negotiation, it will be disappears from the SDP and appears in a later negotiation, it will be
taken to refer to a new MediaStream.</t> taken to refer to a new MediaStream.</t>
<t indent="0" pn="section-3-6">If the "msid" attribute does not conform to
<t>If the MSID attribute does not conform to the ABNF given here, it the ABNF given here, it
SHOULD be ignored.</t> <bcp14>SHOULD</bcp14> be ignored.</t>
<t indent="0" pn="section-3-7">The following is a high-level description o
<t>The following is a high level description of the rules for handling f the rules for handling
SDP updates. Detailed procedures are in <xref SDP updates. Detailed procedures are located in <xref target="s-detailed-p
target="s-detailed-procedures"/>.</t> rocedures" format="default" sectionFormat="of" derivedContent="Section 3.2"/>.</
t>
<t><list style="symbols"> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-8
<t>When a new msid "identifier" value occurs in a session ">
<li pn="section-3-8.1">When a new MSID "identifier" value occurs in a se
ssion
description, and it is not "-", the recipient can signal to its description, and it is not "-", the recipient can signal to its
application that a new MediaStream has been added.</t> application that a new MediaStream has been added.</li>
<li pn="section-3-8.2">When a session description is updated to have med
<t>When a session description is updated to have media descriptions ia descriptions
with an msid "identifier" value, with one or more different with an MSID "identifier" value, with one or more different
"appdata" values, the recipient can signal to its application that "appdata" values, the recipient can signal to its application that
new MediaStreamTracks have been added, and which MediaStream it has new MediaStreamTracks have been added and note to which MediaStream
been added to. This is done for each different msid "identifier" they have
been added. This is done for each different MSID "identifier"
value, including the special value "-", which indicates that a value, including the special value "-", which indicates that a
MediaStreamTrack has been added with no corresponding MediaStreamTrack has been added with no corresponding
MediaStream.</t> MediaStream.</li>
<li pn="section-3-8.3">If an MSID "identifier" value with no "appdata" v
<t>If an msid "identifier" value with no "appdata" value appears, alue appears,
it means that the sender did not inform the recipient of the desired it means that the sender did not inform the recipient of the desired
identifier of the MediaStreamTrack, and the recipient will assign identifier of the MediaStreamTrack, and the recipient will assign
the "id" value of the created MediaStreamTrack on its own. All the "id" value of the created MediaStreamTrack on its own. All
msid in a media section that do not have an "appdata" value are MSIDs in a media section that do not have an "appdata" value are
assumed to refer to the same MediaStreamTrack.</t> assumed to refer to the same MediaStreamTrack.</li>
<li pn="section-3-8.4">When a session description is updated to no longe
<t>When a session description is updated to no longer list any msid r list any "msid"
attribute on a specific media description, the recipient can signal attribute on a specific media description, the recipient can signal
to its application that the corresponding MediaStreamTrack has to its application that the corresponding MediaStreamTrack has
ended.</t> ended.</li>
</list></t> </ul>
<t indent="0" pn="section-3-9">In addition to signaling that the track is
<t>In addition to signaling that the track is ended when its msid ended when its "msid"
attribute disappears from the SDP, the track will also be signaled as attribute disappears from the SDP, the track will also be signaled as
being ended when all associated SSRCs have disappeared by the rules of being ended when all associated SSRCs have disappeared by the rules of
<xref target="RFC3550"/> section 6.3.4 (BYE packet received) and 6.3.5 <xref target="RFC3550" format="default" sectionFormat="of" derivedContent=
(timeout), or when the corresponding media description is disabled by "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 <xref target="RFC3550" section="6.3.5" sectionF
ormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3550#se
ction-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 setting the port number to zero. Changing the direction of the media
description (by setting "sendonly", "recvonly" or "inactive" attributes) description (by setting "sendonly", "recvonly", or "inactive" attributes)
will not end the MediaStreamTrack.</t> will not end the MediaStreamTrack.</t>
<t indent="0" pn="section-3-10">The association between SSRCs and media de
<t>The association between SSRCs and media descriptions is specified in scriptions is specified in
<xref target="I-D.ietf-rtcweb-jsep"/>.</t> <xref target="RFC8829" format="default" sectionFormat="of" derivedContent=
"RFC8829"/>.</t>
<section anchor="s-nonsignal" title="Handling of non-signalled tracks"> <section anchor="s-nonsignal" numbered="true" toc="include" removeInRFC="f
<t>Entities that do not use msid will not send msid. This means that alse" pn="section-3.1">
there will be some incoming RTP packets that the recipient has no <name slugifiedName="name-handling-of-nonsignaled-tra">Handling of Nonsi
predefined MediaStream id value for.</t> gnaled Tracks</name>
<t indent="0" pn="section-3.1-1">Entities that do not use the mechanism
<t>Note that this handling is triggered by incoming RTP packets, not described in this document will not send the
by SDP negotiation.</t> "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
<t>When MSID is used, the only time this can happen is when, after the packets for which the recipient has no predefined MediaStream ID value.</t>
<t indent="0" pn="section-3.1-2">Note that the handling described below
is triggered by incoming RTP packets, not
SDP negotiation.</t>
<t indent="0" pn="section-3.1-3">When communicating with entities that u
se the MSID mechanism, the only time incoming RTP packets
can be received without an associated MediaStream ID value is when, afte
r the
initial negotiation, a negotiation is performed where the answerer initial negotiation, a negotiation is performed where the answerer
adds a MediaStreamTrack to an already established connection and adds a MediaStreamTrack to an already established connection and
starts sending data before the answer is received by the offerer. For starts sending data before the answer is received by the offerer. For
initial negotiation, packets won't flow until the ICE candidates and initial negotiation, packets won't flow until the Interactive
Connectivity Establishment (ICE) candidates and
fingerprints have been exchanged, so this is not an issue.</t> fingerprints have been exchanged, so this is not an issue.</t>
<t indent="0" pn="section-3.1-4">The recipient of those packets will per
<t>The recipient of those packets will perform the following form the following
steps:</t> steps:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3
<t><list style="symbols"> .1-5">
<t>When RTP packets are initially received, it will create an <li pn="section-3.1-5.1">When RTP packets are initially received, it w
ill create an
appropriate MediaStreamTrack based on the type of the media appropriate MediaStreamTrack based on the type of the media
(carried in PayloadType), and use the MID RTP header extension (carried in PayloadType) and use the MID RTP header extension
<xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"/> (if <xref target="RFC8843" format="default" sectionFormat="of" derivedCo
ntent="RFC8843"/> (if
present) to associate the RTP packets with a specific media present) to associate the RTP packets with a specific media
section.</t> section.</li>
<li pn="section-3.1-5.2">If the connection is not in the RTCSignalingS
<t>If the connection is not in the RTCSignalingState "stable", it tate "stable", it
will wait at this point.</t> will wait at this point.</li>
<li pn="section-3.1-5.3">When the connection is in the RTCSignalingSta
<t>When the connection is in the RTCSignalingState "stable", it te "stable", it
will assign ID values.</t> will assign ID values.</li>
</list></t> </ul>
<t indent="0" pn="section-3.1-6">The following steps are performed to as
<t>The following steps are performed to assign ID values:</t> sign ID values:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3
<t><list style="symbols"> .1-7">
<t>If there is an msid attribute, it will use that attribute to <li pn="section-3.1-7.1">If there is an "msid" attribute, it will use
that attribute to
populate the "id" field of the MediaStreamTrack and associated populate the "id" field of the MediaStreamTrack and associated
MediaStreams, as described above.</t> MediaStreams, as described above.</li>
<li pn="section-3.1-7.2">If there is no "msid" attribute, the identifi
<t>If there is no msid attribute, the identifier of the er of the
MediaStreamTrack will be set to a randomly generated string, and MediaStreamTrack will be set to a randomly generated string, and
it will be signalled as being part of a MediaStream with the it will be signaled as being part of a MediaStream with the
WebIDL "label" attribute set to "Non-WebRTC stream".</t> WebIDL "label" attribute set to "Non-WebRTC stream".</li>
<li pn="section-3.1-7.3">After deciding on the "id" field to be applie
<t>After deciding on the "id" field to be applied to the d to the
MediaStreamTrack, the track will be signalled to the user.</t> MediaStreamTrack, the track will be signaled to the user.</li>
</list></t> </ul>
<t indent="0" pn="section-3.1-8">The process above may involve a conside
<t>The process above may involve a considerable amount of buffering rable amount of buffering
before the stable state is entered. If the implementation wishes to before the "stable" state is entered. If the implementation wishes to
limit this buffering, it MUST signal to the user that media has been limit this buffering, it <bcp14>MUST</bcp14> signal to the user that med
ia has been
discarded.</t> discarded.</t>
<t indent="0" pn="section-3.1-9">It follows from the above that MediaStr
<t>It follows from the above that MediaStreamTracks in the "default" eamTracks in the "default"
MediaStream cannot be closed by removing the msid attribute; the MediaStream cannot be closed by removing the "msid" attribute; the
application must instead signal these as closed when the SSRC application must instead signal these as closed when the SSRC
disappears according to the rules of RFC 3550 section 6.3.4 and 6.3.5 disappears, either according to the rules of Sections <xref target="RFC3
or by disabling the media description by setting its port to zero.</t> 550" section="6.3.4" sectionFormat="bare" format="default" derivedLink="https://
rfc-editor.org/rfc/rfc3550#section-6.3.4" derivedContent="RFC3550"/> and <xref
target="RFC3550" section="6.3.5" sectionFormat="bare" format="default" derivedLi
nk="https://rfc-editor.org/rfc/rfc3550#section-6.3.5" derivedContent="RFC3550"/>
of <xref target="RFC3550" format="default" sectionFormat="of" derivedContent="R
FC3550"/> or by disabling the media
description by setting its port to zero.</t>
</section> </section>
<section anchor="s-detailed-procedures" numbered="true" toc="include" remo
<section anchor="s-detailed-procedures" veInRFC="false" pn="section-3.2">
title="Detailed Offer/Answer Procedures"> <name slugifiedName="name-detailed-offer-answer-proce">Detailed Offer/An
<t>These procedures are given in terms of RFC 3264-recommended swer Procedures</name>
sections. They describe the actions to be taken in terms of <t indent="0" pn="section-3.2-1">These procedures are given in terms of
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 MediaStreams and MediaStreamTracks; they do not include event
signalling inside the application, which is described in JSEP.</t> signaling inside the application, which is described in the JavaScript
Session Establishment Protocol (JSEP) <xref target="RFC8829" format="defa
<section title="Generating the initial offer"> ult" sectionFormat="of" derivedContent="RFC8829"/>.</t>
<t>For each media description in the offer, if there is an <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 o
ffer, if there is an
associated outgoing MediaStreamTrack, the offerer adds one "a=msid" associated outgoing MediaStreamTrack, the offerer adds one "a=msid"
attribute to the section for each MediaStream with which the attribute to the section for each MediaStream with which the
MediaStreamTrack is associated. The "identifier" field of the MediaStreamTrack is associated. The "identifier" field of the
attribute is set to the WebIDL "id" attribute of the MediaStream. attribute is set to the WebIDL "id" attribute of the MediaStream.
If the sender wishes to signal identifiers for the MediaStreamTracks, If the sender wishes to signal identifiers for the MediaStreamTracks,
the "appdata" field is set to the WebIDL "id" attribute of the the "appdata" field is set to the WebIDL "id" attribute of the
MediaStreamTrack; otherwise it is omitted.</t> MediaStreamTrack; otherwise, it is omitted.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-3
<section title="Answerer processing of the Offer"> .2.2">
<t>For each media description in the offer, and for each "a=msid" <name slugifiedName="name-answerer-processing-of-the-">Answerer Proces
sing of the Offer</name>
<t indent="0" pn="section-3.2.2-1">For each media description in the o
ffer and each "a=msid"
attribute in the media description, the receiver of the offer will attribute in the media description, the receiver of the offer will
perform the following steps:</t> perform the following steps:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<t><list style="symbols"> -3.2.2-2">
<t>Extract the "appdata" field of the "a=msid" attribute, <li pn="section-3.2.2-2.1">Extract the "appdata" field of the "a=msi
if present.</t> d" attribute,
if present.</li>
<t>If the "appdata" field exists: Check if a MediaStreamTrack <li pn="section-3.2.2-2.2">If the "appdata" field exists: Check if a
MediaStreamTrack
with the same WebIDL "id" with the same WebIDL "id"
attribute as the "appdata" field already exists, and is not in attribute as the "appdata" field already exists and is not in
the "ended" state. If it is not found, create it.</t> the "ended" state. If such a MediaStreamTrack is not found, create i
t.</li>
<t>If the "appdata" field does not exist, and a MediaStreamTrack is <li pn="section-3.2.2-2.3">If the "appdata" field does not exist, an
not associated with this media section, create one and associate d a MediaStreamTrack is
it with this media section for future use.</t> not associated with this media section, create a MediaStreamTrack and
associate
<t>Extract the "identifier" field of the "a=msid" attribte.</t> it with this media section for future use.</li>
<li pn="section-3.2.2-2.4">Extract the "identifier" field of the "a=
<t>Check if a MediaStream with the same WebIDL "id" attribute msid" attribute.</li>
already exists. If not, create it.</t> <li pn="section-3.2.2-2.5">Check if a MediaStream with the same WebI
DL "id" attribute
<t>Add the MediaStreamTrack to the MediaStream</t> already exists. If not, create it.</li>
<li pn="section-3.2.2-2.6">Add the MediaStreamTrack to the MediaStre
<t>Signal to the user that a new MediaStreamTrack is am.</li>
available.</t> <li pn="section-3.2.2-2.7">Signal to the user that a new MediaStream
</list></t> Track is
available.</li>
</ul>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-3
<section title="Generating the answer"> .2.3">
<t>The answer is generated in exactly the same manner as the offer. <name slugifiedName="name-generating-the-answer">Generating 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> "a=msid" values in the offer do not influence the answer.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-3
<section title="Offerer processing of the answer"> .2.4">
<t>The answer is processed in exactly the same manner as the <name slugifiedName="name-offerer-processing-of-the-a">Offerer Process
ing of 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> offer.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-3
<section title="Modifying the session"> .2.5">
<t>On subsequent exchanges, precisely the same procedure as for the <name slugifiedName="name-modifying-the-session">Modifying the 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 initial offer/answer is followed, but with one additional step in
the parsing of the offer and answer:</t> the parsing of the offer and answer:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<t><list style="symbols"> -3.2.5-2">
<t>For each MediaStreamTrack that has been created as a result <li pn="section-3.2.5-2.1">For each MediaStreamTrack that has been c
reated as a result
of previous offer/answer exchanges, and is not in the "ended" of previous offer/answer exchanges, and is not in the "ended"
state, check to see if there is still an "a=msid" attribute in 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 the present SDP whose "appdata" field is the same as the WebIDL
"id" attribute of the track.</t> "id" attribute of the track.</li>
<li pn="section-3.2.5-2.2">If no such attribute is found, stop the M
<t>If no such attribute is found, stop the MediaStreamTrack. ediaStreamTrack.
This will set its state to "ended".</t> This will set its state to "ended".</li>
</list></t> </ul>
</section> </section>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-3.3
<section title="Example SDP description"> ">
<t>The following SDP description shows the representation of a WebRTC <name slugifiedName="name-example-sdp-description">Example SDP Descripti
on</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 PeerConnection with two MediaStreams, each of which has one audio and
one video track. Only the parts relevant to the MSID are shown.</t> one video track. Only the parts relevant to the MSID are shown.</t>
<t indent="0" pn="section-3.3-2">Line wrapping, empty lines, and comment
<t>Line wrapping, empty lines and comments are added for clarity. They s are added for clarity. They
are not part of the SDP.</t> are not part of the SDP.</t>
<sourcecode type="sdp" markers="false" pn="section-3.3-3">
<t/>
<figure>
<artwork><![CDATA[
# First MediaStream - id is 4701... # First MediaStream - id is 4701...
m=audio 56500 UDP/TLS/RTP/SAVPF 96 0 8 97 98 m=audio 56500 UDP/TLS/RTP/SAVPF 96 0 8 97 98
a=msid:47017fee-b6c1-4162-929c-a25110252400 a=msid:47017fee-b6c1-4162-929c-a25110252400
f83006c5-a0ff-4e0a-9ed9-d3e6747be7d9 f83006c5-a0ff-4e0a-9ed9-d3e6747be7d9
m=video 56502 UDP/TLS/RTP/SAVPF 100 101 m=video 56502 UDP/TLS/RTP/SAVPF 100 101
a=msid:47017fee-b6c1-4162-929c-a25110252400 a=msid:47017fee-b6c1-4162-929c-a25110252400
b47bdb4a-5db8-49b5-bcdc-e0c9a23172e0 b47bdb4a-5db8-49b5-bcdc-e0c9a23172e0
# Second MediaStream - id is 6131.... # Second MediaStream - id is 6131....
m=audio 56503 UDP/TLS/RTP/SAVPF 96 0 8 97 98 m=audio 56503 UDP/TLS/RTP/SAVPF 96 0 8 97 98
a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae
b94006c5-cade-4e0a-9ed9-d3e6747be7d9 b94006c5-cade-4e0a-9ed9-d3e6747be7d9
m=video 56504 UDP/TLS/RTP/SAVPF 100 101 m=video 56504 UDP/TLS/RTP/SAVPF 100 101
a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae
f30bdb4a-1497-49b5-3198-e0c9a23172e0 f30bdb4a-1497-49b5-3198-e0c9a23172e0
</sourcecode>
]]></artwork>
</figure>
<t/>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn=
<section anchor="IANA" title="IANA Considerations"> "section-4">
<section title="Attribute registration in existing registries"> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t>This document requests IANA to register the "msid" attribute in the <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1
"att-field (media level only)" registry within the SDP parameters ">
registry, according to the procedures of <xref target="RFC4566"/></t> <name slugifiedName="name-attribute-registration-in-e">Attribute Registr
ation in Existing Registries</name>
<t>The required information for "msid" is:</t> <t indent="0" pn="section-4.1-1">IANA has registered the "msid" attribut
e in the
<t><list style="symbols"> "att-field" (media level only) registry within the "Session
<t>Contact name, email: IETF, contacted via mmusic@ietf.org, or a Description Protocol (SDP) Parameters" registry, according to the
successor address designated by IESG</t> procedures of <xref target="RFC4566" format="default" sectionFormat="of"
derivedContent="RFC4566"/>.</t>
<t>Attribute name: msid</t> <t indent="0" pn="section-4.1-2">The "msid" registration information is
as follows:</t>
<t>Long-form attribute name: MediaStream group Identifier</t> <dl indent="3" newline="false" spacing="normal" pn="section-4.1-3">
<dt pn="section-4.1-3.1">Contact name, email:</dt>
<t>Subject to charset: The attribute value contains only ASCII <dd pn="section-4.1-3.2">IETF, contacted via mmusic@ietf.org, or a
characters, and is therefore not subject to the charset successor address designated by IESG</dd>
attribute.</t> <dt pn="section-4.1-3.3">Attribute name:</dt>
<dd pn="section-4.1-3.4">msid</dd>
<t>Purpose: The attribute can be used to signal the relationship <dt pn="section-4.1-3.5">Attribute syntax:</dt>
between a WebRTC MediaStream and a set of media descriptions.</t> <dd pn="section-4.1-3.6">
<t indent="0" pn="section-4.1-3.6.1"><br/></t>
<t>Appropriate values: The details of appropriate values are given <sourcecode type="abnf" markers="false" pn="section-4.1-3.6.2">
in RFC XXXX.</t> msid-value = msid-id [ SP msid-appdata ]
msid-id = 1*64token-char ; see RFC 4566
<t>MUX category: NORMAL</t> msid-appdata = 1*64token-char ; see RFC 4566
</list>The MUX category is defined in <xref </sourcecode>
target="I-D.ietf-mmusic-sdp-mux-attributes"/>.</t> </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:</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 and is therefore not subject to the charset
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 rela
tionship
between a WebRTC MediaStream and a set of media 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 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 ta
rget="RFC8859" format="default" sectionFormat="of" derivedContent="RFC8859"/>.</
t>
</section> </section>
</section> </section>
<section anchor="Security" numbered="true" toc="include" removeInRFC="false"
<section anchor="Security" title="Security Considerations"> pn="section-5">
<t>An adversary with the ability to modify SDP descriptions has the <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 ability to switch around tracks between MediaStreams. This is a special
case of the general security consideration that modification of SDP case of the general security consideration that modification of SDP
descriptions needs to be confined to entities trusted by the descriptions needs to be confined to entities trusted by the
application.</t> application.</t>
<t indent="0" pn="section-5-2">If implementing buffering as mentioned in <
<t>If implementing buffering as mentioned in <xref xref target="s-nonsignal" format="default" sectionFormat="of" derivedContent="Se
target="s-nonsignal"/>, the amount of buffering should be limited to ction 3.1"/>, the amount of buffering should be limited to
avoid memory exhaustion attacks.</t> avoid memory exhaustion attacks.</t>
<t indent="0" pn="section-5-3">Careless generation of identifiers can leak
<t>Careless generation of identifiers can leak privacy-sensitive privacy-sensitive
information. <xref target="W3C.CR-mediacapture-streams-20160519"/> information. <xref target="W3C.CR-mediacapture-streams" format="default" s
recommends that identifiers are generated using UUID class 3 or 4 as a ectionFormat="of" derivedContent="W3C.CR-mediacapture-streams"/>
recommends that identifiers be generated using a Universally Unique
IDentifier (UUID) class 3 or 4 as a
basis, which avoids such leakage.</t> basis, which avoids such leakage.</t>
<t indent="0" pn="section-5-4">No other attacks have been identified that
<t>No other attacks have been identified that depend on this depend on this
mechanism.</t> mechanism.</t>
</section> </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> </middle>
<back> <back>
<references title="Normative References"> <references pn="section-6">
<?rfc include="reference.RFC.2119"?> <name slugifiedName="name-references">References</name>
<references pn="section-6.1">
<?rfc include='reference.RFC.3550'?> <name slugifiedName="name-normative-references">Normative References</na
me>
<?rfc include='reference.RFC.4566'?> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" quoteTitle="true" derivedAnchor="RFC2119">
<?rfc include='reference.RFC.5234'?> <front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
<?rfc include='reference.W3C.WD-webrtc-20160531'?> le>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<?rfc include='reference.W3C.CR-mediacapture-streams-20160519'?> <organization showOnFrontPage="true"/>
</author>
<?rfc include='reference.I-D.ietf-rtcweb-jsep'?> <date year="1997" month="March"/>
<abstract>
<?rfc include='reference.I-D.ietf-mmusic-sdp-mux-attributes'?> <t indent="0">In many standards track documents several words are
</references> used to signify the requirements in the specification. These words are often ca
pitalized. This document defines these words as they should be interpreted in IE
<references title="Informative References"> TF documents. This document specifies an Internet Best Current Practices for th
<?rfc include='reference.RFC.5761'?> e Internet Community, and requests discussion and suggestions for improvements.<
/t>
<?rfc include='reference.RFC.5888'?> </abstract>
</front>
<?rfc include='reference.RFC.7656'?> <seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<?rfc include='reference.I-D.ietf-mmusic-sdp-bundle-negotiation'?> <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<?rfc include='reference.I-D.ietf-rtcweb-overview'?> <reference anchor="RFC3550" target="https://www.rfc-editor.org/info/rfc3
550" quoteTitle="true" derivedAnchor="RFC3550">
<front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne
">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Casner" fullname="S. Casner">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Frederick" fullname="R. Frederick">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Jacobson" fullname="V. Jacobson">
<organization showOnFrontPage="true"/>
</author>
<date year="2003" month="July"/>
<abstract>
<t indent="0">This memorandum describes RTP, the real-time transpo
rt protocol. RTP provides end-to-end network transport functions suitable for a
pplications transmitting real-time data, such as audio, video or simulation data
, over multicast or unicast network services. RTP does not address resource res
ervation and does not guarantee quality-of- service for real-time services. The
data transport is augmented by a control protocol (RTCP) to allow monitoring of
the data delivery in a manner scalable to large multicast networks, and to prov
ide minimal control and identification functionality. RTP and RTCP are designed
to be independent of the underlying transport and network layers. The protocol
supports the use of RTP-level translators and mixers. Most of the text in this
memorandum is identical to RFC 1889 which it obsoletes. There are no changes in
the packet formats on the wire, only changes to the rules and algorithms govern
ing how the protocol is used. The biggest change is an enhancement to the scalab
le timer algorithm for calculating when to send RTCP packets in order to minimiz
e transmission in excess of the intended rate when many participants join a sess
ion 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/rfc4
566" quoteTitle="true" derivedAnchor="RFC4566">
<front>
<title>SDP: Session Description Protocol</title>
<author initials="M." surname="Handley" fullname="M. Handley">
<organization showOnFrontPage="true"/>
</author>
<author initials="V." surname="Jacobson" fullname="V. Jacobson">
<organization showOnFrontPage="true"/>
</author>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization showOnFrontPage="true"/>
</author>
<date year="2006" month="July"/>
<abstract>
<t indent="0">This memo defines the Session Description Protocol (
SDP). SDP is intended for describing multimedia sessions for the purposes of se
ssion announcement, session invitation, and other forms of multimedia session in
itiation. [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/rfc5
234" 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 defi
ne a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF
), called Augmented BNF (ABNF), has been popular among many Internet specificati
ons. The current specification documents ABNF. It balances compactness and simp
licity with reasonable representational power. The differences between standard
BNF and ABNF involve naming rules, repetition, alternatives, order-independence
, and value ranges. This specification also supplies additional rule definition
s and encoding for a core lexical analyzer of the type common to several Interne
t 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/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="May"/>
<abstract>
<t indent="0">RFC 2119 specifies common key words that may be used
in protocol specifications. This document aims to reduce the ambiguity by cla
rifying that only UPPERCASE usage of the key words have the defined special mea
nings.</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/rfc8
829" 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" ro
le="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/rfc8
859" quoteTitle="true" derivedAnchor="RFC8859">
<front>
<title>A Framework for Session Description Protocol (SDP) Attributes
When Multiplexing</title>
<author initials="S" surname="Nandakumar" fullname="Suhas Nandakumar
">
<organization showOnFrontPage="true"/>
</author>
<date month="January" year="2021"/>
</front>
<seriesInfo name="RFC" value="8859"/>
<seriesInfo name="DOI" value="10.17487/RFC8859"/>
</reference>
<reference anchor="W3C-WebRTC" target="https://www.w3.org/TR/webrtc/" qu
oteTitle="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 Bruaro
ey">
<organization showOnFrontPage="true"/>
</author>
<date/>
</front>
<refcontent>W3C Proposed Recommendation</refcontent>
</reference>
<reference anchor="W3C.CR-mediacapture-streams" target="https://www.w3.o
rg/TR/mediacapture-streams/" quoteTitle="true" derivedAnchor="W3C.CR-mediacaptur
e-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 Bruar
oey">
<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/rfc3
264" 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 which two entit
ies can make use of the Session Description Protocol (SDP) to arrive at a common
view of a multimedia session between them. In the model, one participant offer
s the other a description of the desired session from their perspective, and the
other participant answers with the desired session from their perspective. Thi
s offer/answer model is most useful in unicast sessions where information from b
oth participants is needed for the complete view of the session. The offer/answ
er model is used by protocols like the Session Initiation Protocol (SIP). [STAN
DARDS-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/rfc5
761" quoteTitle="true" derivedAnchor="RFC5761">
<front>
<title>Multiplexing RTP Data and Control Packets on a Single Port</t
itle>
<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 multiplex
ing RTP data packets and RTP Control Protocol (RTCP) packets on a single UDP por
t. It updates RFC 3550 and RFC 3551 to describe when such multiplexing is and is
not appropriate, and it explains how the Session Description Protocol (SDP) can
be used to signal multiplexed sessions. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5761"/>
<seriesInfo name="DOI" value="10.17487/RFC5761"/>
</reference>
<reference anchor="RFC5888" target="https://www.rfc-editor.org/info/rfc5
888" quoteTitle="true" derivedAnchor="RFC5888">
<front>
<title>The Session Description Protocol (SDP) Grouping Framework</ti
tle>
<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 framework to grou
p "m" lines in the Session Description Protocol (SDP) for different purposes. T
his framework uses the "group" and "mid" SDP attributes, both of which are defin
ed in this specification. Additionally, we specify how to use the framework for
two different purposes: for lip synchronization and for receiving a media flow
consisting of several media streams on different transport addresses. This docu
ment 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/rfc7
656" quoteTitle="true" derivedAnchor="RFC7656">
<front>
<title>A Taxonomy of Semantics and Mechanisms for Real-Time Transpor
t 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="ed
itor">
<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 existing and proposed properties and relationship
s among RTP sources and defines common terminology for discussing protocol entit
ies 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/rfc8
825" quoteTitle="true" derivedAnchor="RFC8825">
<front>
<title>Overview: Real-Time Protocols for Browser-Based Applications<
/title>
<author initials="H." surname="Alvestrand" fullname="Harald T. Alves
trand">
<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/rfc8
843" quoteTitle="true" derivedAnchor="RFC8843">
<front>
<title>Negotiating Media Multiplexing Using the Session Description
Protocol (SDP)</title>
<author initials="C" surname="Holmberg" fullname="Christer Holmberg"
>
<organization showOnFrontPage="true"/>
</author>
<author initials="H" surname="Alvestrand" fullname="Harald Alvestran
d">
<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/" quo
teTitle="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> </references>
<section numbered="true" toc="include" removeInRFC="false" pn="section-appen
<section title="Design considerations, rejected alternatives"> dix.a">
<t>One suggested mechanism has been to use CNAME instead of a new <name slugifiedName="name-design-considerations-rejec">Design Consideratio
ns, Rejected Alternatives</name>
<t indent="0" pn="section-appendix.a-1">One suggested mechanism has been t
o use CNAME instead of a new
attribute. This was abandoned because CNAME identifies a synchronization attribute. This was abandoned because CNAME identifies a synchronization
context; one can imagine both wanting to have tracks from the same context; one can imagine both wanting to have tracks from the same
synchronization context in multiple MediaStreams and wanting to have synchronization context in multiple MediaStreams and wanting to have
tracks from multiple synchronization contexts within one MediaStream tracks from multiple synchronization contexts within one MediaStream
(but the latter is impossible, since a MediaStream is defined to impose (but the latter is impossible, since a MediaStream is defined to impose
synchronization on its members).</t> synchronization on its members).</t>
<t indent="0" pn="section-appendix.a-2">Another suggestion has been to put
<t>Another suggestion has been to put the msid value within an attribute the "msid" value within an attribute
of RTCP SR (sender report) packets. This doesn't offer the ability to 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 know that you have seen all the tracks currently configured for a
MediaStream.</t> MediaStream.</t>
<t indent="0" pn="section-appendix.a-3">A suggestion that survived for a n
<t>A suggestion that survived for a number of drafts was to define umber of drafts of this document was to define
"msid" as a generic mechanism, where the particular semantics of this MSID as a generic mechanism, where the particular semantics of this
usage of the mechanism would be defined by an "a=wms-semantic" usage of the mechanism would be defined by an "a=wms-semantic"
attribute. This was removed in April 2015.</t> attribute. This was removed in April 2015.</t>
</section> </section>
<section anchor="Acknowledgements" numbered="false" toc="include" removeInRF
<section title="Change log"> C="false" pn="section-appendix.b">
<t>This appendix should be deleted before publication as an RFC.</t> <name slugifiedName="name-acknowledgements">Acknowledgements</name>
<t indent="0" pn="section-appendix.b-1">This note is based on sketches fro
<section title="Changes from alvestrand-rtcweb-msid-00 to -01"> m, among others, <contact fullname="Justin Uberti"/> and
<t>Added track identifier.</t> <contact fullname="Cullen Jennings"/>.</t>
<t indent="0" pn="section-appendix.b-2">Special thanks to <contact fullnam
<t>Added inclusion-by-reference of e="Flemming Andreasen"/>, <contact fullname="Ben Campbell"/>, <contact fullname=
draft-lennox-mmusic-source-selection for track muting.</t> "Miguel Garcia"/>,
<contact fullname="Martin Thomson"/>, <contact fullname="Ted Hardie"/>,
<t>Some rewording.</t> <contact fullname="Adam Roach"/>, <contact fullname="Magnus Westerlund"/>
</section> ,
<contact fullname="Alissa Cooper"/>, <contact fullname="Sue Hares"/>
<section title="Changes from alvestrand-rtcweb-msid-01 to -02"> , and <contact fullname="Paul Kyzivat"/> for their work in
<t>Split document into sections describing a generic grouping reviewing this document, with many specific language suggestions.</t>
mechanism and sections describing the application of this grouping </section>
mechanism to the WebRTC MediaStream concept.</t> <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.c">
<t>Removed the mechanism for muting tracks, since this is not central <name slugifiedName="name-authors-address">Author's Address</name>
to the MSID mechanism.</t> <author fullname="Harald Alvestrand" initials="H." surname="Alvestrand">
</section> <organization showOnFrontPage="true">Google</organization>
<address>
<section title="Changes from alvestrand-rtcweb-msid-02 to mmusic-msid-00"> <postal>
<t>Changed the draft name according to the wishes of the MMUSIC group <street>Kungsbron 2</street>
chairs.</t> <city>Stockholm</city>
<region/>
<t>Added text indicting cases where it's appropriate to have the same <code>11122</code>
appdata for multiple SSRCs.</t> <country>Sweden</country>
</postal>
<t>Minor textual updates.</t> <email>harald@alvestrand.no</email>
</section> </address>
</author>
<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 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 for "identifier" and "appdata" to be
"token".</t>
<t>Changed the registry 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 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>
<section title="Changes from mmusic-msid-00 to -01">
<t>Reworked msid mechanism to be 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 the word "ssrc" was not
changed to "M-line".</t>
<t>Added pointer to unified-plan (which should be moved to point to
-jsep)</t>
<t>Removed suggestion that ssrc-group attributes can 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 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>
<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>
<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
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 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 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
description.</t>
<t>Added IANA registration of the "msid-semantic" attribute.</t>
</section>
<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
Kyzivat.</t>
<t>Included a section on generic offer/answer semantics.</t>
</section>
<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>
<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
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 the
application.</t>
</section>
<section title="Changes from -09 to -10">
<t>Addressed review comments from Paul Kyzivat.</t>
</section>
<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
unidirectional.</t>
<t>Disallowed the option of sending multiple media sections with the
same msid (id and appdata identical).</t>
</section>
<section title="Changes from -11 to -12">
<t>Added mux-category to the IANA considerations section.</t>
</section>
<section title="Changes from -12 to -13">
<t>Modified registration description to delete dependency 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 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
ignored.</t>
<t>Various small changes based on review feedback during IESG
processing.</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" to saying
it's "ended", in accordance with WebRTC terminology.</t>
</section>
<section title="Changes from -16 to -17">
<t>Added text to allow omitting track identifiers, per JSEP PR #850
</t>
</section>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 88 change blocks. 
652 lines changed or deleted 1117 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/