Diff: rfc8830xml2.original.xml

	rfc8830xml2.original.xml	rfc8830.xml

	<?xml version="1.0" encoding="US-ASCII"?>	<?xml version='1.0' encoding='utf-8'?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd">	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<?rfc toc="yes"?>
	<?rfc tocompact="yes"?>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
	<?rfc tocdepth="3"?>	number="8830" docName="draft-ietf-mmusic-msid-17" ipr="trust200902" obsolet
	<?rfc tocindent="yes"?>	es=""
	<?rfc symrefs="yes"?>	updates="" submissionType="IETF" xml:lang="en" tocInclude="true"
	<?rfc sortrefs="yes"?>	symRefs="true" sortRefs="true" version="3" consensus="true">
	<?rfc comments="yes"?>
	<?rfc inline="yes"?>	<!-- xml2rfc v2v3 conversion 2.32.0 -->
	<?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 Description Protocol</title>	Session Description Protocol</title>

		<seriesInfo name="RFC" value="8830"/>
	<author fullname="Harald Alvestrand" initials="H. T." surname="Alvestrand">	<author fullname="Harald Alvestrand" initials="H." surname="Alvestrand">
	<organization>Google</organization>	<organization>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="August" year="2020"/>


	<date day="13" month="December" year="2018"/>	<keyword>example</keyword>
		<keyword>MSID</keyword>

	<abstract>	<abstract>

	<t>This document specifies a Session Description Protocol (SDP) Grouping	<t>This document specifies a Session Description 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>This mechanism is used to signal the association between the SDP	<t>This mechanism is used to signal the 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>


	<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>
	</note>
	</front>	</front>


	<middle>	<middle>

	<section title="Introduction">	<section numbered="true" toc="default">
	<t/>	<name>Introduction</name>
		<section numbered="true" toc="default">
	<section title="Terminology">	<name>Terminology</name>
	<t>This document uses terminology from <xref	<t>This document uses terminology from <xref

	target="I-D.ietf-rtcweb-overview"/>. In addition, the following terms	target="RFC8825" format="default"/>. In addition, the
	are used as described below:</t>	following terms are used as described below:</t>
		<dl newline="false" spacing="normal">
	<t><list style="hanging">	<dt>RTP stream:</dt> <dd>A stream of RTP packets containing media data
	<t hangText="RTP stream">Defined in <xref target="RFC7656"/> as a	<xref target="RFC7656"
	stream of RTP packets containing media data.</t>	format="default"/>.</dd>
		<dt>MediaStream:</dt>
	<t hangText="MediaStream">Defined in <xref	<dd>An assembly of
	target="W3C.CR-mediacapture-streams-20160519"/>as an assembly of	MediaStreamTracks <xref target="W3C.CR-mediacapture-streams" format=
	MediaStreamTracks. One MediaStream can contain multiple	"default"/>. One MediaStream can contain multiple
	MediaStreamTracks, of the same or different types.</t>	MediaStreamTracks, of the same or different types.</dd>
		<dt>MediaStreamTrack:</dt>
	<t hangText="MediaStreamTrack">Defined in <xref	<dd>Defined in <xref target="W3C.CR-mediacapture-streams" format="defa
	target="W3C.CR-mediacapture-streams-20160519"/>as an	ult"/> 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"/>
	Stream". One MediaStreamTrack can be present in zero, one or	term "source
	multiple MediaStreams.</t>	stream". One MediaStreamTrack can be present in zero, one, or
		multiple MediaStreams.</dd>
		<dt>Media description:</dt>
		<dd>Defined in <xref target="RFC4566" format="default"/> as a set of
		fields starting with an "m=" field
		and terminated by either the next "m=" field or the end of the
		session description.</dd>
		</dl>


	<t hangText="Media description">Defined in <xref	<t>
	target="RFC4566"/> as a set of fields starting with an "m=" field	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	and terminated by eitehr the next "m=" field or by the end of the	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
	session description.</t>	",
	</list></t>	"<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.
		</t>
	</section>	</section>


	<section title="Structure Of This Document">	<section numbered="true" toc="default">
	<t>This document adds a new Session Description Protocol (SDP) <xref	<name>Structure of This Document</name>
	target="RFC4566"/> mechanism that can attach identifiers to the RTP	<t>This document adds a new Session Description Protocol (SDP) <xref tar
	streams and attaching identifiers to the groupings they form. It is	get="RFC4566" format="default"/> mechanism that can attach identifiers to the RT
	designed for use with WebRTC<xref target="I-D.ietf-rtcweb-overview"/>	P
	.</t>	streams and attach identifiers to the groupings they form. It is
		designed for use with WebRTC <xref target="RFC8825" format="default"/>.<
	<t><xref target="sect-why"/> gives the background on why a new	/t>
		<t><xref target="sect-why" format="default"/> gives the background on wh
		y a new
	mechanism is needed.</t>	mechanism is needed.</t>

		<t><xref target="sect-definition" format="default"/> gives the definitio
	<t><xref target="sect-definition"/> gives the definition of the new	n of the new
	mechanism.</t>	mechanism.</t>

		<t><xref target="sect-media-stream" format="default"/> gives the necessa
	<t><xref target="sect-media-stream"/> gives the necessary semantic	ry semantic
	information and procedures for using the msid attribute to signal the	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"/>.</t>
	</section>	</section>

		<section anchor="sect-why" numbered="true" toc="default">
		<name>Why a New Mechanism Is Needed</name>


	<section anchor="sect-why" title="Why A New Mechanism Is Needed">	<t>When media is carried by RTP <xref target="RFC3550"
	<t>When media is carried by RTP <xref target="RFC3550"/>, each RTP	format="default"/>, each RTP stream is distinguished inside an RTP
	stream is distinguished inside an RTP session by its SSRC; each 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"/> is used).</t>


	<t>SDP <xref target="RFC4566"/> gives a format for describing an SDP	<t>SDP <xref target="RFC4566" format="default"/> gives a format for desc ribing 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"/>, each media
	description describes exactly one media source, and if multiple media	description describes exactly one media source. If multiple media
	sources are carried in an RTP session, this is signalled using BUNDLE	sources are carried in an RTP session, this is signaled using BUNDLE
	<xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"/>; if BUNDLE is	<xref target="RFC8843" format="default"/>; 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>The SDP Grouping Framework <xref target="RFC5888" format="default"/>
	<t>The SDP grouping framework <xref target="RFC5888"/> can be used to	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="default">
	<section title="The WEBRTC MediaStream">	<name>The WebRTC MediaStream</name>
	<t>The W3C WebRTC API specification <xref	<t>The W3C WebRTC API specification <xref target="W3C-WebRTC" format="de
	target="W3C.WD-webrtc-20160531"/> specifies that communication between	fault"/> 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>MediaStreamTracks are unidirectional; they carry media in one
	<t>MediaStreamTracks are unidirectional; they carry media on one
	direction only.</t>	direction only.</t>


	<t>In the RTP specification, RTP streams are identified using the SSRC	<t>In the RTP specification, RTP streams are 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>WebRTC defines a mapping (documented in <xref target="RFC8829" format
	<t>WebRTC defines a mapping (documented in <xref	="default"/>) where one SDP media description is
	target="I-D.ietf-rtcweb-jsep"/>) 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

	target="I-D.ietf-mmusic-sdp-bundle-negotiation"/> is used to group	target="RFC8843" format="default"/> is
		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>This usage is described in <xref target="sect-media-stream" format="d
	<t>This usage is described in <xref target="sect-media-stream"/>.</t>	efault"/>.</t>
	</section>	</section>
	</section>	</section>


	<section anchor="sect-definition" title="The Msid Mechanism">	<section anchor="sect-definition" numbered="true" toc="default">
	<t>This document defines a new SDP <xref target="RFC4566"/> media-level
	"msid" attribute. This new attribute allows endpoints to associate RTP
	streams that are described in different media descriptions with the same
	MediaStreams as defined in <xref target="W3C.WD-webrtc-20160531"/>, and
	to carry an identifier for each MediaStreamTrack in its "appdata"
	field.</t>


		<name>The MSID Mechanism</name>
		<t>This document defines a new SDP <xref target="RFC4566" format="default"
		/> media-level
		"msid" attribute.
		This new attribute allows endpoints to associate RTP
		streams that are described in separate media descriptions with the
		right MediaStreams, as defined in <xref 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	<t>The value of the "msid" attribute consists of an identifier and an
	optional "appdata" field.</t>	optional "appdata" field.</t>


	<t>The name of the attribute is "msid".</t>	<t>The name of the attribute is "msid".</t>


	<t>The value of the attribute is specified by the following ABNF <xref	<t>The value of the attribute is specified by the following ABNF <xref

	target="RFC5234"/> grammar:</t>	target="RFC5234" format="default"/> grammar:</t>

	<t/>


	<figure>	<sourcecode type="abnf" >
	<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>An example "msid" value for a group with the identifier "examplefoo"
	</figure>

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


	<figure>	<sourcecode>
	<artwork><![CDATA[
	msid:examplefoo examplebar	msid:examplefoo examplebar

		</sourcecode>
	]]></artwork>
	</figure>

	<t>The identifier is a string of ASCII characters 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>Application data (msid-appdata) is carried on the same line as the	<t>Application data (msid-appdata) is carried 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>The identifier ("msid-id") uniquely identifies a group within the scope
	<t>The identifier (msid-id) uniquely identifies a group within the scope
	of an SDP description.</t>	of an SDP description.</t>

		<t>There may be multiple "msid" attributes in a single media description.
	<t>There may be multiple msid attributes in 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>Multiple media descriptions with the same value for "msid-id" and
	msid-appdata are not permitted.</t>	"msid&nbhy;appdata" are not permitted.</t>

	<t>Endpoints can update the associations between RTP streams as	<t>Endpoints can update the associations between RTP streams as

	expressed by msid attributes at any time.</t>	expressed by "msid" attributes at any time.</t>
		<t>The "msid" attributes depend on the association of RTP streams with
	<t>The msid attributes depend on the association of RTP streams with	media descriptions but do not depend on the association of RTP
	media descriptions, but does not depend on the association of RTP	streams with RTP transports. Therefore, their Mux Category (as defined in
	streams with RTP transports; therefore, its mux category (as defined in	<xref target="RFC8859" format="default"/>) is NORMAL; the
	<xref target="I-D.ietf-mmusic-sdp-mux-attributes"/>) is NORMAL - the	process of deciding on "msid" attributes doesn't have to take into
	process of deciding on MSID attributes doesn't have to take into	consideration whether or not the RTP streams are bundled.</t>
	consideration whether the RTP streams are bundled or not.</t>
	</section>	</section>

		<section anchor="sect-media-stream" numbered="true" toc="default">
	<section anchor="sect-media-stream" title="Procedures">	<name>Procedures</name>
	<t>This section describes the procedures for associating media	<t>This section describes the procedures for associating media

	descriptions representing MediaStreamTracks within MediaStreams as	descriptions representing MediaStreamTracks within MediaStreams, as
	defined in <xref target="W3C.WD-webrtc-20160531"/>.</t>	defined in <xref target="W3C-WebRTC" format="default"/>.</t>

	<t>In the Javascript API described in that specification, each	<t>In the Javascript API described in that specification, 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>The value of the "msid-id" field in the msid consists of the "id"	<t>The value of the "msid-id" field in the MSID 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"/>. The special value
		"-" indicates "no MediaStream".</t>
	<t>The value of the "msid-appdata" field in the msid, if present,	<t>The value of the "msid-appdata" field in the 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>When an SDP session description is updated, a specific "msid-id"	<t>When an SDP session description is updated, 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>If the "msid" attribute does not conform to the ABNF given here, it
		<bcp14>SHOULD</bcp14> be ignored.</t>


	<t>If the MSID attribute does not conform to the ABNF given here, it	<t>The following is a high-level description of the rules for handling
	SHOULD be ignored.</t>	SDP updates. Detailed procedures are located in <xref
		target="s-detailed-procedures" format="default"/>.</t>
	<t>The following is a high level description of the rules for handling	<ul spacing="normal">
	SDP updates. Detailed procedures are in <xref	<li>When a new MSID "identifier" value occurs in a session
	target="s-detailed-procedures"/>.</t>

	<t><list style="symbols">
	<t>When a new msid "identifier" value occurs in a session
	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>When a session description is updated to have media descriptions
	<t>When a session description is updated to have media 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>If an MSID "identifier" value with no "appdata" value appears,
	<t>If an msid "identifier" value with no "appdata" value 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>When a session description is updated to no longer list any "msid"
	<t>When a session description is updated to no longer 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>In addition to signaling that the track is ended when its msid	<t>In addition to signaling that the track is 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" />, Sections <xref target="RFC3550"
	(timeout), or when the corresponding media description is disabled by	section="6.3.4" sectionFormat="bare"/>
		(BYE packet received) and <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	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>The association between SSRCs and media descriptions is specified in	<t>The association between SSRCs and media descriptions is specified in

	<xref target="I-D.ietf-rtcweb-jsep"/>.</t>	<xref target="RFC8829" format="default"/>.</t>


	<section anchor="s-nonsignal" title="Handling of non-signalled tracks">	<section anchor="s-nonsignal" numbered="true" toc="default">
	<t>Entities that do not use msid will not send msid. This means that	<name>Handling of Nonsignaled Tracks</name>
	there will be some incoming RTP packets that the recipient has no	<t>Entities that do not use the mechanism described in this document wil
	predefined MediaStream id value for.</t>	l not send 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 for which the recipient has no predefined MediaStream ID value.</t>


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


	<t>When MSID is used, the only time this can happen is when, after the	<t>When communicating with entities that use the MSID mechanism, the onl
		y 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>The recipient of those packets will perform the following	<t>The recipient of those packets will perform the following
	steps:</t>	steps:</t>

		<ul spacing="normal">


	<t><list style="symbols">	<li>When RTP packets are initially received, it will create an
	<t>When RTP packets are initially received, it will 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"/> (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>If the connection is not in the RTCSignalingState "stable", it
	<t>If the connection is not in the RTCSignalingState "stable", it	will wait at this point.</li>
	will wait at this point.</t>	<li>When the connection is in the RTCSignalingState "stable", it
		will assign ID values.</li>
	<t>When the connection is in the RTCSignalingState "stable", it	</ul>
	will assign ID values.</t>
	</list></t>

	<t>The following steps are performed to assign ID values:</t>	<t>The following steps are performed to assign ID values:</t>

		<ul spacing="normal">
	<t><list style="symbols">	<li>If there is an "msid" attribute, it will use that attribute to
	<t>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>If there is no "msid" attribute, the identifier of the
	<t>If there is no msid attribute, the identifier 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>After deciding on the "id" field to be applied to the
	<t>After deciding on the "id" field to be applied to the	MediaStreamTrack, the track will be signaled to the user.</li>
	MediaStreamTrack, the track will be signalled to the user.</t>	</ul>
	</list></t>

	<t>The process above may involve a considerable amount of buffering	<t>The process above may involve a considerable 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>It follows from the above that MediaStreamTracks in the "default"	<t>It follows from the above that MediaStreamTracks 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" /> and <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>	</section>

		<section anchor="s-detailed-procedures" numbered="true" toc="default">
		<name>Detailed Offer/Answer Procedures</name>


	<section anchor="s-detailed-procedures"	<t>These procedures are given in terms of sections recommended by
	title="Detailed Offer/Answer Procedures">	<xref target="RFC3264"/>. They describe the actions to be taken in terms
	<t>These procedures are given in terms of RFC 3264-recommended	of
	sections. 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"/>.</t>
	<section title="Generating the initial offer">	<section numbered="true" toc="default">
		<name>Generating the Initial Offer</name>
	<t>For each media description in the offer, if there is an	<t>For each media description in the offer, 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="default">
	<section title="Answerer processing of the Offer">	<name>Answerer Processing of the Offer</name>
	<t>For each media description in the offer, and for each "a=msid"	<t>For each media description in the offer 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">
	<t><list style="symbols">	<li>Extract the "appdata" field of the "a=msid" attribute,
	<t>Extract the "appdata" field of the "a=msid" attribute,	if present.</li>
	if present.</t>	<li>If the "appdata" field exists: Check if a MediaStreamTrack

	<t>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>If the "appdata" field does not exist, and a MediaStreamTrack is
	not associated with this media section, create one and associate	not associated with this media section, create a MediaStreamTrack and
	it with this media section for future use.</t>	associate
		it with this media section for future use.</li>
	<t>Extract the "identifier" field of the "a=msid" attribte.</t>	<li>Extract the "identifier" field of the "a=msid" attribute.</li>
		<li>Check if a MediaStream with the same WebIDL "id" attribute
	<t>Check if a MediaStream with the same WebIDL "id" attribute	already exists. If not, create it.</li>
	already exists. If not, create it.</t>	<li>Add the MediaStreamTrack to the MediaStream.</li>
		<li>Signal to the user that a new MediaStreamTrack is
	<t>Add the MediaStreamTrack to the MediaStream</t>	available.</li>
		</ul>
	<t>Signal to the user that a new MediaStreamTrack is
	available.</t>
	</list></t>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Generating the answer">	<name>Generating the Answer</name>
	<t>The answer is generated in exactly the same manner as the offer.	<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>	"a=msid" values in the offer do not influence the answer.</t>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Offerer processing of the answer">	<name>Offerer Processing of the Answer</name>
	<t>The answer is processed in exactly the same manner as the	<t>The answer is processed in exactly the same manner as the
	offer.</t>	offer.</t>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Modifying the session">	<name>Modifying the Session</name>
	<t>On subsequent exchanges, precisely the same procedure as for the	<t>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">
	<t><list style="symbols">	<li>For each MediaStreamTrack that has been created as a result
	<t>For each MediaStreamTrack that has been created 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>If no such attribute is found, stop the MediaStreamTrack.
	<t>If no such attribute is found, stop the MediaStreamTrack.	This will set its state to "ended".</li>
	This will set its state to "ended".</t>	</ul>
	</list></t>
	</section>	</section>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Example SDP description">	<name>Example SDP Description</name>
	<t>The following SDP description shows the representation of a WebRTC	<t>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>Line wrapping, empty lines, and comments are added for clarity. They
	<t>Line wrapping, empty lines and comments are added for clarity. They
	are not part of the SDP.</t>	are not part of the SDP.</t>


	<t/>	<sourcecode type="sdp">

	<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="default">
		<name>IANA Considerations</name>
		<section numbered="true" toc="default">
		<name>Attribute Registration in Existing Registries</name>


	<section anchor="IANA" title="IANA Considerations">	<t>IANA has registered the "msid" attribute in the
	<section title="Attribute registration in existing registries">	"att-field" (media level only) registry within the "Session
	<t>This document requests IANA to register the "msid" attribute in the	Description Protocol (SDP) Parameters" registry, according to the
	"att-field (media level only)" registry within the SDP parameters	procedures of <xref target="RFC4566" format="default"/>.</t>
	registry, according to the procedures of <xref target="RFC4566"/></t>	<t>The "msid" registration information is as follows:</t>
		<dl>
	<t>The required information for "msid" is:</t>	<dt>Contact name, email:</dt> <dd>IETF, contacted via mmusic@ietf.org,
		or a
	<t><list style="symbols">	successor address designated by IESG</dd>
	<t>Contact name, email: IETF, contacted via mmusic@ietf.org, or a	<dt>Attribute name:</dt> <dd>msid</dd>
	successor address designated by IESG</t>

	<t>Attribute name: msid</t>

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

	<t>Subject to charset: The attribute value contains only ASCII
	characters, and is therefore not subject to the charset
	attribute.</t>

	<t>Purpose: The attribute can be used to signal the relationship
	between a WebRTC MediaStream and a set of media descriptions.</t>

	<t>Appropriate values: The details of appropriate values are given
	in RFC XXXX.</t>


	<t>MUX category: NORMAL</t>	<dt>Attribute syntax:</dt> <dd>
	</list>The MUX category is defined in <xref	<t><br/></t>
	target="I-D.ietf-mmusic-sdp-mux-attributes"/>.</t>	<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 ]]>
		</sourcecode></dd>
		<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:</dt> <dd>The attribute value contains only ASC
		II
		characters and is therefore not subject to the charset
		attribute.</dd>
		<dt>Purpose:</dt> <dd>The attribute can be used to signal the relation
		ship
		between a WebRTC MediaStream and a set of media 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 8830 (this document).</dd>
		<dt>Mux Category:</dt> <dd>NORMAL</dd>
		</dl>
		<t>The Mux Category is defined in <xref target="RFC8859" format="default
		"/>.</t>
	</section>	</section>
	</section>	</section>

		<section anchor="Security" numbered="true" toc="default">
	<section anchor="Security" title="Security Considerations">	<name>Security Considerations</name>
	<t>An adversary with the ability to modify SDP descriptions has the	<t>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>If implementing buffering as mentioned in <xref target="s-nonsignal" fo
	<t>If implementing buffering as mentioned in <xref	rmat="default"/>, the amount of buffering should be limited to
	target="s-nonsignal"/>, the amount of buffering should be limited to
	avoid memory exhaustion attacks.</t>	avoid memory exhaustion attacks.</t>


	<t>Careless generation of identifiers can leak privacy-sensitive	<t>Careless generation of identifiers can leak privacy-sensitive

	information. <xref target="W3C.CR-mediacapture-streams-20160519"/>	information. <xref target="W3C.CR-mediacapture-streams" format="default"/>
	recommends that identifiers are generated using UUID class 3 or 4 as a	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>No other attacks have been identified that depend on this	<t>No other attacks have been identified that 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">
	<?rfc include="reference.RFC.2119"?>


	<?rfc include='reference.RFC.3550'?>	<references>
		<name>References</name>


	<?rfc include='reference.RFC.4566'?>	<references>
		<name>Normative References</name>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.2119.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.8174.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.3550.xml"/>


	<?rfc include='reference.RFC.5234'?>	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.4566.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.5234.xml"/>


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


	<?rfc include='reference.W3C.CR-mediacapture-streams-20160519'?>	<reference anchor="W3C.CR-mediacapture-streams"
		target="https://www.w3.org/TR/2019/CR-mediacapture-streams-201
		90702/">
		<front>
		<title>Media Capture and Streams</title>
		<author initials="D." surname="Burnett" fullname="Daniel Burnett">
		<organization/>
		</author>
		<author initials="A." surname="Bergkvist" fullname="Adam Bergkvist">
		<organization/>
		</author>
		<author initials="C." surname="Jennings" fullname="Cullen Jennings">
		<organization/>
		</author>
		<author initials="A." surname="Narayanan" fullname="Anant Narayanan"
		>
		<organization/>
		</author>
		<author initials="B." surname="Aboba" fullname="Bernard Aboba">
		<organization/>
		</author>
		<author initials="J.-I." surname="Bruaroey" fullname="Jan-Ivar Bruar
		oey">
		<organization/>
		</author>
		<author initials="H" surname="Boström" fullname="Henrik Boström">
		<organization/>
		</author>
		<date month="July" day="2" year="2019"/>
		</front>
		<refcontent>W3C Candidate Recommendation</refcontent>
		</reference>


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


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


	<references title="Informative References">	</references>
	<?rfc include='reference.RFC.5761'?>	<references>
		<name>Informative References</name>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.3264.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.5761.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.5888.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.7656.xml"/>


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


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


	<?rfc include='reference.I-D.ietf-mmusic-sdp-bundle-negotiation'?>	<reference anchor="WEBIDL" target="https://heycam.github.io/webidl/">
		<front>
		<title>Web IDL</title>
		<author initials="E." surname="Chen" fullname="Edgar Chen">
		<organization />
		</author>
		<author initials="T." surname="Gu" fullname="Tiancheng Gu">
		<organization />
		</author>
		<date month="August" year="2020" />
		</front>
		<refcontent>W3C Editor's Draft</refcontent>
		</reference>


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

		<section numbered="true" toc="default">
	<section title="Design considerations, rejected alternatives">	<name>Design Considerations, Rejected Alternatives</name>
	<t>One suggested mechanism has been to use CNAME instead of a new	<t>One suggested mechanism has been to 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>Another suggestion has been to put the "msid" value within an attribute
	<t>Another suggestion has been to put 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>A suggestion that survived for a number of drafts of this document was
	<t>A suggestion that survived for a number of drafts was to define	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 title="Change log">	<section anchor="Acknowledgements" numbered="false" toc="default">
	<t>This appendix should be deleted before publication as an RFC.</t>	<name>Acknowledgements</name>
		<t>This note is based on sketches from, among others, <contact fullname="J
	<section title="Changes from alvestrand-rtcweb-msid-00 to -01">	ustin Uberti"/> and
	<t>Added track identifier.</t>	<contact fullname="Cullen Jennings"/>.</t>
		<t>Special thanks to <contact fullname="Flemming Andreassen"/>, <contact
	<t>Added inclusion-by-reference of	fullname="Ben Campbell"/>, <contact fullname="Miguel Garcia"/>,
	draft-lennox-mmusic-source-selection for track muting.</t>	<contact fullname="Martin Thomson"/>, <contact fullname="Ted Hardie"/>,
		<contact fullname="Adam Roach"/>, <contact fullname="Magnus Westerlund"/>
	<t>Some rewording.</t>	,
	</section>	<contact fullname="Alissa Cooper"/>, <contact fullname="Sue
		Hares"/>, and <contact fullname="Paul Kyzivat"/> for their work in
	<section title="Changes from alvestrand-rtcweb-msid-01 to -02">	reviewing this document, with many specific language suggestions.</t>
	<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 is not central
	to the MSID mechanism.</t>
	</section>

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

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

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

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

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

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

	<section title="Changes from alvestrand-mmusic-msid-01 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. 131 change blocks.
	583 lines changed or deleted	489 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/