draft-ietf-mmusic-msid-08.txt   draft-ietf-mmusic-msid-09.txt 
Network Working Group H. Alvestrand Network Working Group H. Alvestrand
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track February 11, 2015 Intended status: Standards Track April 21, 2015
Expires: August 15, 2015 Expires: October 23, 2015
WebRTC MediaStream Identification in the Session Description Protocol WebRTC MediaStream Identification in the Session Description Protocol
draft-ietf-mmusic-msid-08 draft-ietf-mmusic-msid-09
Abstract Abstract
This document specifies a Session Description Protocol (SDP) Grouping 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. between media streams.
This mechanism is used to signal the association between the SDP This mechanism is used to signal the association between the SDP
concept of "m-line" and the WebRTC concept of "MediaStream" / concept of "media description" and the WebRTC concept of
"MediaStreamTrack" using SDP signaling. "MediaStream" / "MediaStreamTrack" using SDP signaling.
This document is a work item of the MMUSIC WG, whose discussion list This document is a work item of the MMUSIC WG, whose discussion list
is mmusic@ietf.org. is mmusic@ietf.org.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 15, 2015. This Internet-Draft will expire on October 23, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Structure Of This Document . . . . . . . . . . . . . . . 3 1.1. Structure Of This Document . . . . . . . . . . . . . . . 3
1.2. Why A New Mechanism Is Needed . . . . . . . . . . . . . . 3 1.2. Why A New Mechanism Is Needed . . . . . . . . . . . . . . 3
1.3. Application to the WEBRTC MediaStream . . . . . . . . . . 4 1.3. The WEBRTC MediaStream . . . . . . . . . . . . . . . . . 4
2. The Msid Mechanism . . . . . . . . . . . . . . . . . . . . . 5 2. The Msid Mechanism . . . . . . . . . . . . . . . . . . . . . 4
3. The Msid-Semantic Attribute . . . . . . . . . . . . . . . . . 6 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Generic SDP Offer/Answer Procedures . . . . . . . . . . . . . 7 3.1. Handling of non-signalled tracks . . . . . . . . . . . . 6
4.1. Generating the Initial Offer . . . . . . . . . . . . . . 7 3.2. Detailed Offer/Answer Procedures . . . . . . . . . . . . 8
4.2. Answerer Processing of the Offer . . . . . . . . . . . . 7 3.2.1. Generating the initial offer . . . . . . . . . . . . 8
4.3. Generating the Answer . . . . . . . . . . . . . . . . . . 7 3.2.2. Answerer processing of the Offer . . . . . . . . . . 8
4.4. Offerer Processing of the Answer . . . . . . . . . . . . 7 3.2.3. Generating the answer . . . . . . . . . . . . . . . . 8
5. Applying Msid to WebRTC MediaStreams . . . . . . . . . . . . 7 3.2.4. Offerer processing of the answer . . . . . . . . . . 8
5.1. Handling of non-signalled tracks . . . . . . . . . . . . 9 3.2.5. Modifying the session . . . . . . . . . . . . . . . . 9
5.2. Detailed Offer/Answer Procedures . . . . . . . . . . . . 10 3.3. Example SDP description . . . . . . . . . . . . . . . . . 9
5.2.1. Generating the initial offer . . . . . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5.2.2. Parsing the initial offer . . . . . . . . . . . . . . 10 4.1. Attribute registration in existing registries . . . . . . 10
5.2.3. Generating the answer . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5.2.4. Offerer processing of the answer . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
5.2.5. Modifying the session . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . 11
6.1. Attribute registration in existing registries . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 11
6.2. New registry creation . . . . . . . . . . . . . . . . . . 12 Appendix A. Design considerations, rejected alternatives . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 B.1. Changes from alvestrand-rtcweb-msid-00 to -01 . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 B.2. Changes from alvestrand-rtcweb-msid-01 to -02 . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 B.3. Changes from alvestrand-rtcweb-msid-02 to mmusic-msid-00 12
9.2. Informative References . . . . . . . . . . . . . . . . . 14 B.4. Changes from alvestrand-mmusic-msid-00 to -01 . . . . . . 13
Appendix A. Design considerations, rejected alternatives . . . . 14 B.5. Changes from alvestrand-mmusic-msid-01 to -02 . . . . . . 13
Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 14 B.6. Changes from alvestrand-mmusic-msid-02 to ietf-mmusic-00 13
B.1. Changes from alvestrand-rtcweb-msid-00 to -01 . . . . . . 15 B.7. Changes from mmusic-msid-00 to -01 . . . . . . . . . . . 13
B.2. Changes from alvestrand-rtcweb-msid-01 to -02 . . . . . . 15 B.8. Changes from mmusic-msid-01 to -02 . . . . . . . . . . . 13
B.3. Changes from alvestrand-rtcweb-msid-02 to mmusic-msid-00 15 B.9. Changes from mmusic-msid-02 to -03 . . . . . . . . . . . 14
B.4. Changes from alvestrand-mmusic-msid-00 to -01 . . . . . . 15 B.10. Changes from mmusic-msid-03 to -04 . . . . . . . . . . . 14
B.5. Changes from alvestrand-mmusic-msid-01 to -02 . . . . . . 15 B.11. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 14
B.6. Changes from alvestrand-mmusic-msid-02 to ietf-mmusic-00 16 B.12. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 14
B.7. Changes from mmusic-msid-00 to -01 . . . . . . . . . . . 16 B.13. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 15
B.8. Changes from mmusic-msid-01 to -02 . . . . . . . . . . . 16 B.14. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 15
B.9. Changes from mmusic-msid-02 to -03 . . . . . . . . . . . 16 B.15. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 15
B.10. Changes from mmusic-msid-03 to -04 . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
B.11. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 17
B.12. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 17
B.13. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 17
B.14. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
1.1. Structure Of This Document 1.1. Structure Of This Document
This document adds a new Session Description Protocol (SDP) [RFC4566] This document adds a new Session Description Protocol (SDP) [RFC4566]
mechanism that can associate application layer identifiers with the mechanism that can associate application layer identifiers with the
binding between media streams, attaching identifiers to the media binding between media streams, attaching identifiers to the media
streams and attaching identifiers to the groupings they form. streams and attaching identifiers to the groupings they form. It is
designed for use with WebRTC[I-D.ietf-rtcweb-overview] .
Section 1.2 gives the background on why a new mechanism is needed. Section 1.2 gives the background on why a new mechanism is needed.
Section 2 gives the definition of the new mechanism. Section 2 gives the definition of the new mechanism.
Section 3 gives the definition of the msid-semantic field, which Section 3 gives the necessary semantic information and procedures for
gives the possibility of using MSIDs with different semantics in the using the msid attribute to signal the association of
same SDP message. MediaStreamTracks to MediaStreams in support of the WebRTC API
[W3C.WD-webrtc-20150210].
Section 5 gives the application of the new mechanism for providing
necessary semantic information for the association of
MediaStreamTracks to MediaStreams in the WebRTC API
[W3C.WD-webrtc-20120209].
1.2. Why A New Mechanism Is Needed 1.2. Why A New Mechanism Is Needed
When media is carried by RTP [RFC3550], each RTP media stream is When media is carried by RTP [RFC3550], each RTP media stream is
distinguished inside an RTP session by its SSRC; each RTP session is distinguished inside an RTP session by its SSRC; each RTP session is
distinguished from all other RTP sessions by being on a different distinguished from all other RTP sessions by being on a different
transport association (strictly speaking, 2 transport associations, transport association (strictly speaking, 2 transport associations,
one used for RTP and one used for RTCP, unless RTP/RTCP multiplexing one used for RTP and one used for RTCP, unless RTP/RTCP multiplexing
[RFC5761] is used). [RFC5761] is used).
SDP gives a description based on m-lines. According to the model SDP gives a description based on media descriptions. According to
used in [I-D.ietf-rtcweb-jsep], each m-line describes exactly one the model used in [I-D.ietf-rtcweb-jsep], each media description
media source, and if mulitple media sources are carried in an RTP describes exactly one media source, and if mulitple media sources are
session, this is signalled using BUNDLE carried in an RTP session, this is signalled using BUNDLE
[I-D.ietf-mmusic-sdp-bundle-negotiation]; if BUNDLE is not used, each [I-D.ietf-mmusic-sdp-bundle-negotiation]; if BUNDLE is not used, each
media source is carried in its own RTP session. media source is carried in its own RTP session.
There exist cases where an application using RTP and SDP needs to The SDP grouping framework [RFC5888] can be used to group media
signal some relationship between RTP media streams that may be descriptions. However, for the use case of WebRTC, there is the need
carried in either the same RTP session or different RTP sessions. for an application to specify some application-level information
For instance, there may be a need to signal a relationship between a about the association between the media description and the group.
video track and an audio track, and where the generator of the SDP This is not possible using the SDP grouping framework.
does not yet know if they will be carried in the same RTP session or
different RTP sessions.
The SDP grouping framework [RFC5888] can be used to group m-lines.
However, there is sometimes the need for an application to specify
some application-level information about the association between the
m-line and the group. This is not possible using the SDP grouping
framework.
1.3. Application to the WEBRTC MediaStream 1.3. The WEBRTC MediaStream
The W3C WebRTC API specification [W3C.WD-webrtc-20120209] specifies The W3C WebRTC API specification [W3C.WD-webrtc-20150210] specifies
that communication between WebRTC entities is done via MediaStreams, that communication between WebRTC entities is done via MediaStreams,
which contain MediaStreamTracks. A MediaStreamTrack is generally which contain MediaStreamTracks. A MediaStreamTrack is generally
carried using a single SSRC in an RTP session (forming an RTP media carried using a single SSRC in an RTP session (forming an RTP media
stream. The collision of terminology is unfortunate.) There might stream. The collision of terminology is unfortunate.) There might
possibly be additional SSRCs, possibly within additional RTP possibly be additional SSRCs, possibly within additional RTP
sessions, in order to support functionality like forward error sessions, in order to support functionality like forward error
correction or simulcast. This complication is ignored below. correction or simulcast. This complication is ignored below.
In the RTP specification, media streams are identified using the SSRC In the RTP specification, media streams are identified using the SSRC
field. Streams are grouped into RTP Sessions, and also carry a field. Streams are grouped into RTP Sessions, and also carry a
CNAME. Neither CNAME nor RTP session correspond to a MediaStream. CNAME. Neither CNAME nor RTP session correspond to a MediaStream.
Therefore, the association of an RTP media stream to MediaStreams Therefore, the association of an RTP media stream to MediaStreams
need to be explicitly signaled. need to be explicitly signaled.
WebRTC defines a mapping (documented in [I-D.ietf-rtcweb-jsep]) where WebRTC defines a mapping (documented in [I-D.ietf-rtcweb-jsep]) where
one SDP m-line is used to describe each MediaStreamTrack, and that one SDP media description is used to describe each MediaStreamTrack,
the BUNDLE mechanism [I-D.ietf-mmusic-sdp-bundle-negotiation] is used and that the BUNDLE mechanism
to group MediaStreamTracks into RTP sessions. Therefore, the need is [I-D.ietf-mmusic-sdp-bundle-negotiation] is used to group
to specify the ID of a MediaStreamTrack and its associated MediaStreamTracks into RTP sessions. Therefore, the need is to
MediaStream for each m-line, which can be accomplished with a media- specify the ID of a MediaStreamTrack and its associated MediaStream
for each media description, which can be accomplished with a media-
level SDP attribute. level SDP attribute.
This usage is described in Section 5. This usage is described in Section 3.
2. The Msid Mechanism 2. The Msid Mechanism
This document defines a new SDP [RFC4566] media-level "msid" This document defines a new SDP [RFC4566] media-level "msid"
attribute. This new attribute allows endpoints to associate RTP attribute. This new attribute allows endpoints to associate RTP
media streams that are carried in the same or different m-lines. The media streams that are carried in the same or different media
attribute also allows application-specific information to the descriptions. The attribute also allows application-specific
association. information to the association.
The value of the "msid" attribute consists of an identifier and The value of the "msid" attribute consists of an identifier and
optional application-specific data. optional application-specific data.
The name of the attribute is "msid". The name of the attribute is "msid".
The value of the attribute is specified by the following ABNF The value of the attribute is specified by the following ABNF
[RFC5234] grammar: [RFC5234] grammar:
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
An example msid value for a group with the identifier "examplefoo" An example msid value for a group with the identifier "examplefoo"
and application data "examplebar" might look like this: and application data "examplebar" might look like this:
msid:examplefoo examplebar msid:examplefoo examplebar
The identifier is a string of ASCII characters that are legal in a The identifier is a string of ASCII characters that are legal in a
"token", consisting of between 1 and 64 characters. It MUST be "token", consisting of between 1 and 64 characters.
unique among the identifier values used in the same SDP session. It
is RECOMMENDED that it is generated using a random-number generator.
Application data is carried on the same line as the identifier, Application data is carried on the same line as the identifier,
separated from the identifier by a space. separated from the identifier by a space.
The identifier uniquely identifies a group within the scope of an SDP The identifier uniquely identifies a group within the scope of an SDP
description. description.
There may be multiple msid attributes in a single media description. There may be multiple msid attributes in a single media description.
There may also be multiple media descriptions that have the same There may also be multiple media descriptions that have the same
value for identifier and application data. value for identifier and application data.
Endpoints can update the associations between RTP media streams as Endpoints can update the associations between RTP media streams as
expressed by msid attributes at any time; the semantics and expressed by msid attributes at any time; the semantics and
restrictions of such grouping and ungrouping are application restrictions of such grouping and ungrouping are application
dependent. dependent.
3. The Msid-Semantic Attribute 3. Procedures
A session-level attribute is defined for signaling the semantics
associated with an msid grouping. This allows msid groupings with
different semantics to coexist.
This OPTIONAL attribute gives the group identifier and its group
semantic; it carries the same meaning as the ssrc-group-attr of RFC
5576 section 4.2, but uses the identifier of the group rather than a
list of SSRC values.
This attribute MUST be present if "a=msid" is used.
An empty list of identifiers is an indication that the sender
supports the indicated semantic, but has no msid groupings of the
given type in the present SDP.
An identifier of "*" is an indication that all "a=msid" lines in the
SDP have this specific semantic. If "*" is not used, each msid-id in
the SDP MUST appear in one and only one "msid-semantic" line.
The name of the attribute is "msid-semantic".
The value of the attribute is given by the following ABNF:
msid-semantic-value = msid-semantic msid-list
msid-semantic = token ; see RFC 4566
msid-list = *(" " msid-id) / " *"
The semantic field holds values from the IANA registriy "Semantics
for the msid-semantic SDP attribute" (which is defined in Section 6).
An example msid-semantic might look like this, if a semantic LS was
registered by IANA for the same purpose as the existing LS grouping
semantic:
a=msid-semantic:LS xyzzy forolow
This means that the SDP description has two lip sync groups, with the
group identifiers xyzzy and forolow, respectively.
The msid-semantic attribute can occur more than once, but MUST NOT
occur more than once with the same msid-semantic value.
4. Generic SDP Offer/Answer Procedures
In accordance with guidance on definitions of SDP extensions, this
section gives the generic procedures that have to be followed by all
implementations of Msid, independent of which semantics they support.
Note that the use of msid is not negotiated; each side declares what
semantics it uses. This means that an offerer has to be willing and
able to take appropriate action if the other side does not wish to
use the semantic, and an answerer adding new semantics to an answer
has to be willing and able to deal with the offerer not wishing to
use that semantic.
4.1. Generating the Initial Offer
An entity wishing to use an MSID semantic MUST add one or more "msid-
semantic" attributes to its session level attributes, indicating the
MSID semantic it wishes to have available..
4.2. Answerer Processing of the Offer
If an "msid-semantic" attribute is present in the offer, and the
answerer wishes to use the indicated semantic, the offerer MUST
follow the procedures described for that semantic.
4.3. Generating the Answer
An entity wishing to use an MSID semantic MUST add one or more "msid-
semantic" attributes to its session level attributes, indicating the
MSID semantic it wishes to have available. If the answerer does not
wish to use one or more of the semantics indicated in the offer, the
answerer MUST NOT include "msid-semantic" lines indicating these
semantics in the answer.
4.4. Offerer Processing of the Answer
If an "msid-semantic" attribute is present in the answer, and the
offerer wishes to use the indicated semantic, the offerer MUST follow
the procedures described for that semantic. The offerer MUST follow
the procedures for all semantics that were indicated in its offer and
were also present in the answer.
5. Applying Msid to WebRTC MediaStreams
This section creates a new semantic for use with the framework This section describes how to use the msid-semantic attribute for
defined in Section 2, to be used for associating m-lines representing associating media descriptions representing MediaStreamTracks within
MediaStreamTracks within MediaStreams as defined in MediaStreams as defined in [W3C.WD-webrtc-20150210].
[W3C.WD-webrtc-20120209].
In the Javascript API, each MediaStream and MediaStreamTrack has an In the Javascript API, each MediaStream and MediaStreamTrack has an
"id" attribute, which is a DOMString. "id" attribute, which is a DOMString.
The semantic token for this semantic is "WMS" (short for WebRTC Media The semantic token for this semantic is "WMS" (short for WebRTC Media
Stream). Stream).
The value of the "identifier" field in the msid consists of the "id" The value of the "msid-id" field in the msid consists of the "id"
attribute of a MediaStream, as defined in its WebIDL specification. attribute of a MediaStream, as defined in its WebIDL specification.
The value of the "appdata" field in the msid consists of the "id" The value of the "msid-appdata" field in the msid consists of the
attribute of a MediaStreamTrack, as defined in its WebIDL "id" attribute of a MediaStreamTrack, as defined in its WebIDL
specification. specification.
If two different m-lines have MSID attributes with the same value for If two different media descriptions have MSID attributes with the
identifier and appdata, it means that these two m-lines are both same values for "msid-id" and "msid-appdata", it means that these two
intended for the same MediaStreamTrack. So far, no semantic for such media descriptions are both intended for the same MediaStreamTrack.
a mixture have been defined, but this specification does not forbid So far, no semantic for such a mixture have been defined, but this
the practice. specification does not forbid the practice.
When an SDP description is updated, a specific msid "identifier" When an SDP description is updated, a specific "msid-id" continues to
continues to refer to the same MediaStream, and a specific "appdata" refer to the same MediaStream, and a specific "msid-appdata" to the
to the same MediaStreamTrack. Once negotiation has completed on a same MediaStreamTrack. There is no memory apart from the currently
session, there is no memory apart from the currently valid SDP valid SDP descriptions; if an msid "identifier" value disappears from
descriptions; if an msid "identifier" value disappears from the SDP the SDP and appears in a later negotiation, it will be taken to refer
and appears in a later negotiation, it will be taken to refer to a to a new MediaStream.
new MediaStream.
The following are the rules for handling updates of the list of The following are the rules for handling updates of the list of media
m-lines and their msid values. descriptions and their msid values.
o When a new msid "identifier" value occurs in the description, the o When a new msid "identifier" value occurs in the description, the
recipient can signal to its application that a new MediaStream has recipient can signal to its application that a new MediaStream has
been added. been added.
o When a description is updated to have more media sections with the o When a description is updated to have more media descriptions with
same msid "identifier" value, but different "appdata" values, the the same msid "identifier" value, but different "appdata" values,
recipient can signal to its application that new MediaStreamTracks the recipient can signal to its application that new
have been added to the MediaStream. MediaStreamTracks have been added to the MediaStream.
o When a description is updated to no longer list the msid attribute o When a description is updated to no longer list any msid attribute
on a specific media description, the recipient can signal to its on a specific media description, the recipient can signal to its
application that the corresponding MediaStreamTrack has ended. application that the corresponding MediaStreamTrack has ended.
In addition to signaling that the track is closed when its msid In addition to signaling that the track is closed 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 closed when all associated SSRCs have disappeared by the rules being closed when all associated SSRCs have disappeared by the rules
of [RFC3550] section 6.3.4 (BYE packet received) and 6.3.5 (timeout), of [RFC3550] section 6.3.4 (BYE packet received) and 6.3.5 (timeout),
and when the corresponding media section is disabled by setting the and when the corresponding media description is disabled by setting
port number to zero. Changing the direction of the media section (by the port number to zero. Changing the direction of the media
setting "sendonly", "recvonly" or "inactive" attributes) will not description (by setting "sendonly", "recvonly" or "inactive"
close the MediaStreamTrack. attributes) will not close the MediaStreamTrack. (This mechanism may
be used to signal that a particular MediaStreamTrack should be put on
temporary hold, but that usage is not specified in this memo.)
The association between SSRCs and m-lines is specified in The association between SSRCs and media descriptions is specified in
[I-D.ietf-rtcweb-jsep]. [I-D.ietf-rtcweb-jsep].
5.1. Handling of non-signalled tracks 3.1. Handling of non-signalled tracks
Entities that do not use the WMS semantic will not send "msid- Entities that do not use msid will not send msid. This means that
semantic:WMS". This means that there will be some incoming RTP there will be some incoming RTP packets that the recipient has no
packets that the recipient has no predefined MediaStream id value predefined MediaStream id value for.
for.
Note that this handling is triggered by incoming RTP packets, not by Note that this handling is triggered by incoming RTP packets, not by
SDP negotiation. SDP negotiation.
Handling will depend on whether or not the msid-semantic:WMS When MSID is used, the only time this can happen is when, at a time
attribute is present. There are two cases: subsequent to the initial negotiation, a negotiation is performed
where the answerer adds a MediaStreamTrack to an already established
connection and starts sending data before the answer is received by
the offerer. For initial negotiation, packets won't flow until the
ICE candidates and fingerprints have been exchanged, so this is not
an issue.
o No "msid-semantic:WMS" attribute is present. The SDP session is The recipient of those packets will perform the following steps:
assumed to be a backwards-compatible session. All incoming media,
on all m-lines that are part of the SDP session, are assumed to
belong to tracks of the same media stream (the "default media
stream"). The identifier of this media stream and of the media
stream track is a randomly generated string; the WebIDL "label"
attribute of this media stream will be set to "Non-WMS stream".
o An "msid-semantic:WMS" attribute is present. In this case, the o When RTP packets are initially received, it will create an
sender implements the WMS semantic, and the packets are either appropriate MediaStreamTrack based on the type of the media
caused by a bug or by timing skew between the arrival of the media (carried in PayloadType), and use the mid RTP attribute (if
packets and the SDP description. These packets MAY be discarded, present) to associate the RTP packets with a specific media
or they MAY be buffered for a while in order to allow immediate section. If the connection is not in the RTCSignalingState
startup of the media stream when the SDP description is updated. "stable", it will wait at this point.
The arrival of media packets MUST NOT cause a new MediaStreamTrack
to be signaled.
If an entity wishing to use the WMS semantic sends a description, it o When the connection is in the RTCSignalingState "stable", it will
MUST include the msid-semantic:WMS attribute, even if no media look at the relevant media section to find the msid attribute.
streams are sent. This allows us to distinguish between the case of
no media streams at the moment and the case of SDP generated by an
entity that wishes to use the backwards-compatible mechanism.
It follows from the above that the media receiver implmementing the o If there is an msid attribute, it will use that attribute to
WMS semantic must have the SDP of the other party before it can populate the "id" field of the MediaStreamTrack and associated
decide correctly which of the two cases described above applies. RTP MediaStreams, as described above.
media packets that arrive before the remote party's SDP MUST be
buffered or discarded, and MUST NOT cause a new MediaStreamTrack to o If there is no msid attribute, the identifier of the
be signalled. MediaStreamTrack will be set to a randomly generated string, and
it will be signalled as being part of a MediaStream with the
WebIDL "label" attribute set to "Non-WebRTC stream".
o After deciding on the "id" field to be applied to the
MediaStreamTrack, the track will be signalled to the user.
The process above may involve a considerable amount of buffering
before the stable state is entered, If the implementation wishes to
limit this buffering, it MUST signal to the user that media has been
discarded.
It follows from the above that media stream tracks in the "default" It follows from the above that media stream tracks in the "default"
media stream cannot be closed by removing the msid attribute; the media stream 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 according to the rules of RFC 3550 section 6.3.4 and 6.3.5
or by disabling the m-line by setting its port to zero. or by disabling the media description by setting its port to zero.
5.2. Detailed Offer/Answer Procedures 3.2. Detailed Offer/Answer Procedures
These procedures are given in terms of RFC 3264-recommended sections. These procedures are given in terms of RFC 3264-recommended sections.
They describe the actions to be taken in terms of MediaStreams and They describe the actions to be taken in terms of MediaStreams and
MediaStreamTracks; they do not include event signalling inside the MediaStreamTracks; they do not include event signalling inside the
application, which is described in JSEP. application, which is described in JSEP.
They are specifically applicable to the WMS semantic; other semantics 3.2.1. Generating the initial offer
will have their own consideration.
5.2.1. Generating the initial offer
For each media section in the offer, if there is an associated For each media description in the offer, if there is an associated
MediaStreamTrack, the offerer adds one "a=msid" attribute to the outgoing MediaStreamTrack, the offerer adds one "a=msid" attribute to
section for each MediaStream with which the MediaStreamTrack is the section for each MediaStream with which the MediaStreamTrack is
associated. The "identifier" field of the attribute is set to the associated. The "identifier" field of the attribute is set to the
WebIDL "id" attribute of the MediaStream, and the "appdata" field is WebIDL "id" attribute of the MediaStream, and the "appdata" field is
set to the WebIDL "id" attribute of the MediaStreamTrack. set to the WebIDL "id" attribute of the MediaStreamTrack.
The offerer adds an "msid-semantic:WMS" field to the session-level 3.2.2. Answerer processing of the Offer
headers, and appends to it either a list of all the identifiers used
in the offer, or the single character "*".
5.2.2. Parsing the initial offer
For each media section in the offer, and for each "a=msid" attribute For each media description in the offer, and for each "a=msid"
in the media section where the "msid-id" is associated with the "WMS" attribute in the media description where the "msid-id" is associated
semantic, the receiver of the offer will perform the following steps: with the "WMS" semantic, the receiver of the offer will perform the
following steps:
o Extract the "appdata" field of the "a=msid" attribute o Extract the "appdata" field of the "a=msid" attribute
o Check if a MediaStreamTrack with the same WebIDL "id" attribute as o Check if a MediaStreamTrack with the same WebIDL "id" attribute as
the "appdata" field already exists, and is not in the "ended" the "appdata" field already exists, and is not in the "ended"
state. If it is not found, create it. state. If it is not found, create it.
o Extract the "identifier" field of the "a=msid" attribte. o Extract the "identifier" field of the "a=msid" attribte.
o Check if a MediaStream with the same WebIDL "id" attribute already o Check if a MediaStream with the same WebIDL "id" attribute already
exists. If not, create it. exists. If not, create it.
o Add the MediaStreamTrack to the MediaStream o Add the MediaStreamTrack to the MediaStream
5.2.3. Generating the answer o Signal to the user that a new MediaStreamTrack is available.
The answer is generated in exactly the same manner as the offer. 3.2.3. Generating the answer
This includes adding a "msid-semantic:WMS" attribute in the session- The answer is generated in exactly the same manner as the offer.
level headers, independent of whether or not such a header was "a=msid" values in the offer do not influence the answer.
present in the offer.
5.2.4. Offerer processing of the answer 3.2.4. Offerer processing of the answer
The answer is processed in exactly the same manner as the offer. The answer is processed in exactly the same manner as the offer.
5.2.5. Modifying the session 3.2.5. Modifying the session
On subsequent exchanges, precisely the same procedure as for the On subsequent exchanges, precisely the same procedure as for the
initial offer/answer is followed, but with one additional step in the initial offer/answer is followed, but with one additional step in the
parsing of the offer and answer: parsing of the offer and answer:
o For each MediaStreamTrack that has been created as a result of o For each MediaStreamTrack that has been created as a result of
previous offer/answer exchanges, and is not in the "ended" state, previous offer/answer exchanges, and is not in the "ended" state,
check to see if there is still an "a=msid" attribute in the check to see if there is still an "a=msid" attribute in the
present SDP whose "appdata" field is the same as the WebIDL "id" present SDP whose "appdata" field is the same as the WebIDL "id"
attribute of the track. attribute of the track.
o If no such attribute is found, close the MediaStreamTrack. This o If no such attribute is found, stop the MediaStreamTrack. This
will set its state to "ended". will set its state to "ended".
6. IANA Considerations 3.3. Example SDP description
6.1. Attribute registration in existing registries The following SDP description shows the representation of a WebRTC
PeerConnection with two MediaStreams, each of which has one audio and
one video track. Only the parts relevant to the MSID are shown.
Line wrapping, empty lines and comments are added for clarity. They
are not part of the SDP.
# First MediaStream - id is 4701...
m=audio 56500 UDP/TLS/RTP/SAVPF 96 0 8 97 98
a=msid:47017fee-b6c1-4162-929c-a25110252400
f83006c5-a0ff-4e0a-9ed9-d3e6747be7d9
m=video 56502 UDP/TLS/RTP/SAVPF 100 101
a=msid:47017fee-b6c1-4162-929c-a25110252400
b47bdb4a-5db8-49b5-bcdc-e0c9a23172e0
# Second MediaStream - id is 6131....
m=audio 56503 UDP/TLS/RTP/SAVPF 96 0 8 97 98
a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae
b94006c5-cade-4e0a-9ed9-d3e6747be7d9
m=video 56504 UDP/TLS/RTP/SAVPF 100 101
a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae
f30bdb4a-1497-49b5-3198-e0c9a23172e0
4. IANA Considerations
4.1. Attribute registration in existing registries
This document requests IANA to register the "msid" attribute in the This document requests IANA to register the "msid" attribute in the
"att-field (media level only)" registry within the SDP parameters "att-field (media level only)" registry within the SDP parameters
registry, according to the procedures of [RFC4566] registry, according to the procedures of [RFC4566]
The required information for "msid" is: The required information for "msid" is:
o Contact name, email: IETF, contacted via mmusic@ietf.org, or a o Contact name, email: IETF, contacted via mmusic@ietf.org, or a
successor address designated by IESG successor address designated by IESG
o Attribute name: msid o Attribute name: msid
o Long-form attribute name: Media stream group Identifier o Long-form attribute name: Media stream group Identifier
o Subject to charset: The attribute value contains only ASCII o Subject to charset: The attribute value contains only ASCII
characters, and is therefore not subject to the charset attribute. characters, and is therefore not subject to the charset attribute.
o Purpose: The attribute gives an association over a set of m-lines. o Purpose: The attribute can be used to signal the relationship
For example, it can be used to signal the relationship between a between a WebRTC MediaStream and a set of media descriptions.
WebRTC MediaStream and a set of m-lines.
o Appropriate values: The details of appropriate values are given in o Appropriate values: The details of appropriate values are given in
RFC XXXX. RFC XXXX.
This document requests IANA to register the "msid-semantic" attribute 5. Security Considerations
in the "att-field (session level) registry within the SDP parameters
registry, according to the same procedures.
The required information is:
o Contact name, email: IETF, contacted via mmusic@ietf.org, or a
successor address designated by IESG
o Attribute name: msid-semantic
o Long-form attribute name: Msid group semantic identifier
o Subject to charset: The attribute value contains only ASCII
characters, and is therefore not subject to the charset attribute.
o Purpose: The attribute gives the semantics of an association over
a set of m-lines.
o Appropriate values: The details are given in RFC XXXX.
6.2. New registry creation
This document requests IANA to create a new registry called
"Semantics for the msid-semantic SDP attribute" in the "Session
Description Protocol (SDP) Parameters" group. This registry operates
on the Expert Review policy [RFC5226]. Usage of the registry is
expected to be low, so the expert should feel free to consult widely
if a new request ever comes in.
This document requests IANA to register the "WMS" semantic within
this new registry.
The required information is:
o Description: WebRTC Media Stream, as given in RFC XXXX.
o Token: WMS
o Standards track reference: RFC XXXX
IANA is requested to replace "RFC XXXX" with the RFC number of this
document upon publication.
7. Security Considerations
An adversary with the ability to modify SDP descriptions has the An adversary with the ability to modify SDP descriptions has the
ability to switch around tracks between media streams. This is a ability to switch around tracks between media streams. This is a
special case of the general security consideration that modification special case of the general security consideration that modification
of SDP descriptions needs to be confined to entities trusted by the of SDP descriptions needs to be confined to entities trusted by the
application. application.
If implementing buffering as mentioned in Section 5.1, the amount of If implementing buffering as mentioned in Section 3.1, the amount of
buffering should be limited to avoid memory exhaustion attacks. buffering should be limited to avoid memory exhaustion attacks.
No other attacks have been identified that depend on this mechanism. No other attacks have been identified that depend on this mechanism.
8. Acknowledgements 6. Acknowledgements
This note is based on sketches from, among others, Justin Uberti and This note is based on sketches from, among others, Justin Uberti and
Cullen Jennings. Cullen Jennings.
Special thanks to Flemming Andreassen, Miguel Garcia, Martin Thomson, Special thanks to Flemming Andreassen, Miguel Garcia, Martin Thomson,
Ted Hardie, Adam Roach and Paul Kyzivat for their work in reviewing Ted Hardie, Adam Roach and Paul Kyzivat for their work in reviewing
this draft, with many specific language suggestions. this draft, with many specific language suggestions.
9. References 7. References
9.1. Normative References 7.1. Normative References
[I-D.ietf-rtcweb-jsep] [I-D.ietf-rtcweb-jsep]
Uberti, J., Jennings, C., and E. Rescorla, "Javascript Uberti, J., Jennings, C., and E. Rescorla, "Javascript
Session Establishment Protocol", draft-ietf-rtcweb-jsep-08 Session Establishment Protocol", draft-ietf-rtcweb-jsep-09
(work in progress), October 2014. (work in progress), March 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[W3C.WD-webrtc-20120209] [W3C.WD-webrtc-20150210]
Bergkvist, A., Burnett, D., Jennings, C., and A. Bergkvist, A., Burnett, D., Jennings, C., and A.
Narayanan, "WebRTC 1.0: Real-time Communication Between Narayanan, "WebRTC 1.0: Real-time Communication Between
Browsers", World Wide Web Consortium WD WD- Browsers", World Wide Web Consortium WD WD-webrtc-
webrtc-20120209, February 2012, 20150210, February 2015,
<http://www.w3.org/TR/2012/WD-webrtc-20120209>. <http://www.w3.org/TR/2015/WD-webrtc-20150210>.
9.2. Informative References 7.2. Informative References
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-07 (work in progress), April 2014. negotiation-19 (work in progress), March 2015.
[I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", draft-ietf-rtcweb-overview-13
(work in progress), November 2014.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010. Control Packets on a Single Port", RFC 5761, April 2010.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010. Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
Appendix A. Design considerations, rejected alternatives Appendix A. Design considerations, rejected alternatives
This appendix should be deleted before publication as an RFC.
One suggested mechanism has been to use CNAME instead of a new One suggested mechanism has been to use CNAME instead of a new
attribute. This was abandoned because CNAME identifies a attribute. This was abandoned because CNAME identifies a
synchronization context; one can imagine both wanting to have tracks synchronization context; one can imagine both wanting to have tracks
from the same synchronization context in multiple MediaStreams and from the same synchronization context in multiple MediaStreams and
wanting to have tracks from multiple synchronization contexts within wanting to have tracks from multiple synchronization contexts within
one MediaStream (but the latter is impossible, since a MediaStream is one MediaStream (but the latter is impossible, since a MediaStream is
defined to impose synchronization on its members). defined to impose synchronization on its members).
Another suggestion has been to put the msid value within an attribute Another suggestion has been to put the msid value within an attribute
of RTCP SR (sender report) packets. This doesn't offer the ability 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 to know that you have seen all the tracks currently configured for a
media stream. media stream.
A suggestion that survived for a number of drafts was to define
"msid" as a generic mechanism, where the particular semantics of this
usage of the mechanism would be defined by an "a=wms-semantic"
attribute. This was removed in April 2015.
Appendix B. Change log Appendix B. Change log
This appendix should be deleted before publication as an RFC. This appendix should be deleted before publication as an RFC.
B.1. Changes from alvestrand-rtcweb-msid-00 to -01 B.1. Changes from alvestrand-rtcweb-msid-00 to -01
Added track identifier. Added track identifier.
Added inclusion-by-reference of draft-lennox-mmusic-source-selection Added inclusion-by-reference of draft-lennox-mmusic-source-selection
for track muting. for track muting.
skipping to change at page 18, line 5 skipping to change at page 15, line 30
Adopted a restructuring of the IANA section based on a suggestion Adopted a restructuring of the IANA section based on a suggestion
from Martin Thomson. from Martin Thomson.
A number of text and ABNF clarifications based on suggestions from A number of text and ABNF clarifications based on suggestions from
Ted Hardie, Paul Kyzivat and Adam Roach. Ted Hardie, Paul Kyzivat and Adam Roach.
Changed the "non-signalled track handling" to create a single stream Changed the "non-signalled track handling" to create a single stream
with multiple tracks again, according to discussions at TPAC in with multiple tracks again, according to discussions at TPAC in
November 2014 November 2014
B.15. Changes from -08 to -09
Removed "wms-semantic" and all mention of multiple semantics for
msid, as agreed at the Dallas IETF, March 2015.
Addressed a number of review comments from Fleming Andresen and
others.
Changed the term "m-line" to "media description", since that is the
term used in RFC 4566.
Tried to make sure this document does not describe the API to the
application.
Author's Address Author's Address
Harald Alvestrand Harald Alvestrand
Google Google
Kungsbron 2 Kungsbron 2
Stockholm 11122 Stockholm 11122
Sweden Sweden
Email: harald@alvestrand.no Email: harald@alvestrand.no
 End of changes. 62 change blocks. 
330 lines changed or deleted 224 lines changed or added

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