draft-ietf-mmusic-msid-06.txt   draft-ietf-mmusic-msid-07.txt 
Network Working Group H. Alvestrand Network Working Group H. Alvestrand
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track June 9, 2014 Intended status: Standards Track October 14, 2014
Expires: December 11, 2014 Expires: April 17, 2015
WebRTC MediaStream Identification in the Session Description Protocol WebRTC MediaStream Identification in the Session Description Protocol
draft-ietf-mmusic-msid-06 draft-ietf-mmusic-msid-07
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 "m-line" and the WebRTC concept of "MediaStream" /
"MediaStreamTrack" using SDP signaling. "MediaStreamTrack" using SDP signaling.
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 December 11, 2014. This Internet-Draft will expire on April 17, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 26 skipping to change at page 2, line 26
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. Application to the WEBRTC MediaStream . . . . . . . . . . 4
2. The Msid Mechanism . . . . . . . . . . . . . . . . . . . . . 4 2. The Msid Mechanism . . . . . . . . . . . . . . . . . . . . . 5
3. The Msid-Semantic Attribute . . . . . . . . . . . . . . . . . 5 3. The Msid-Semantic Attribute . . . . . . . . . . . . . . . . . 6
4. Applying Msid to WebRTC MediaStreams . . . . . . . . . . . . 6 4. Generic SDP Offer/Answer Procedures . . . . . . . . . . . . . 6
4.1. Handling of non-signalled tracks . . . . . . . . . . . . 7 4.1. Generating the Initial Offer . . . . . . . . . . . . . . 7
4.2. Detailed procedures . . . . . . . . . . . . . . . . . . . 8 4.2. Answerer Processing of the Offer . . . . . . . . . . . . 7
4.2.1. Generating the initial offer . . . . . . . . . . . . 9 4.3. Generating the Answer . . . . . . . . . . . . . . . . . . 7
4.2.2. Parsing the initial offer . . . . . . . . . . . . . . 9 4.4. Offerer Processing of the Answer . . . . . . . . . . . . 7
4.2.3. Generating the answer . . . . . . . . . . . . . . . . 9 5. Applying Msid to WebRTC MediaStreams . . . . . . . . . . . . 7
4.2.4. Offerer processing of the answer . . . . . . . . . . 9 5.1. Handling of non-signalled tracks . . . . . . . . . . . . 8
4.2.5. Modifying the session . . . . . . . . . . . . . . . . 9 5.2. Detailed Offer/Answer Procedures . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5.2.1. Generating the initial offer . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5.2.2. Parsing the initial offer . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 5.2.3. Generating the answer . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2.4. Offerer processing of the answer . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 11 5.2.5. Modifying the session . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Design considerations, rejected alternatives . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
Appendix B. Usage with multiple MediaStreams per M-line . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
B.1. Mechanism design with multiple SSRCs . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
B.2. Usage with the SSRC attribute . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 13
Appendix C. Change log . . . . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 13
C.1. Changes from alvestrand-rtcweb-msid-00 to -01 . . . . . . 14 Appendix A. Design considerations, rejected alternatives . . . . 14
C.2. Changes from alvestrand-rtcweb-msid-01 to -02 . . . . . . 15 Appendix B. Usage with multiple MediaStreams per M-line . . . . 14
C.3. Changes from alvestrand-rtcweb-msid-02 to mmusic-msid-00 15 B.1. Mechanism design with multiple SSRCs . . . . . . . . . . 15
C.4. Changes from alvestrand-mmusic-msid-00 to -01 . . . . . . 15 B.2. Usage with the SSRC attribute . . . . . . . . . . . . . . 16
C.5. Changes from alvestrand-mmusic-msid-01 to -02 . . . . . . 15 Appendix C. Change log . . . . . . . . . . . . . . . . . . . . . 16
C.6. Changes from alvestrand-mmusic-msid-02 to ietf-mmusic-00 15 C.1. Changes from alvestrand-rtcweb-msid-00 to -01 . . . . . . 16
C.7. Changes from mmusic-msid-00 to -01 . . . . . . . . . . . 16 C.2. Changes from alvestrand-rtcweb-msid-01 to -02 . . . . . . 16
C.8. Changes from mmusic-msid-01 to -02 . . . . . . . . . . . 16 C.3. Changes from alvestrand-rtcweb-msid-02 to mmusic-msid-00 16
C.9. Changes from mmusic-msid-02 to -03 . . . . . . . . . . . 16 C.4. Changes from alvestrand-mmusic-msid-00 to -01 . . . . . . 16
C.10. Changes from mmusic-msid-03 to -04 . . . . . . . . . . . 16 C.5. Changes from alvestrand-mmusic-msid-01 to -02 . . . . . . 17
C.11. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 16 C.6. Changes from alvestrand-mmusic-msid-02 to ietf-mmusic-00 17
C.12. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 17 C.7. Changes from mmusic-msid-00 to -01 . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 C.8. Changes from mmusic-msid-01 to -02 . . . . . . . . . . . 17
C.9. Changes from mmusic-msid-02 to -03 . . . . . . . . . . . 17
C.10. Changes from mmusic-msid-03 to -04 . . . . . . . . . . . 18
C.11. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 18
C.12. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 18
C.13. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
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) This document adds a new Session Description Protocol (SDP)
Grouping[RFC5888] relation between SDP m-lines [RFC4566] that can Grouping[RFC5888] relation between SDP m-lines [RFC4566] that can
associate application layer identifiers with the binding between associate application layer identifiers with the binding between
media streams, attaching identifiers to the media streams and media streams, attaching identifiers to the media streams and
attaching identifiers to the groupings they form. attaching identifiers to the groupings they form.
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 definition of the msid-semantic field, which
gives the possibility of using MSIDs with different semantics in the gives the possibility of using MSIDs with different semantics in the
same SDP message. same SDP message.
Section 4 gives the application of the new mechanism for providing Section 5 gives the application of the new mechanism for providing
necessary semantic information for the association of necessary semantic information for the association of
MediaStreamTracks to MediaStreams in the WebRTC MediaStreamTracks to MediaStreams in the WebRTC
API[W3C.WD-webrtc-20120209]. 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,
skipping to change at page 4, line 44 skipping to change at page 4, line 48
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 m-line is used to describe each MediaStreamTrack, and that
the BUNDLE mechanism [I-D.ietf-mmusic-sdp-bundle-negotiation] is used the BUNDLE mechanism [I-D.ietf-mmusic-sdp-bundle-negotiation] is used
to group MediaStreamTracks into RTP sessions. Therefore, the need is to group MediaStreamTracks into RTP sessions. Therefore, the need is
to specify the ID of a MediaStreamTrack and its associated to specify the ID of a MediaStreamTrack and its associated
MediaStream for each m-line, which can be accomplished with a media- MediaStream for each m-line, which can be accomplished with a media-
level SDP attribute. level SDP attribute.
This usage is described in Section 4. This usage is described in Section 5.
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 m-lines. The
attribute also allows application-specific information to the attribute also allows application-specific information to the
association. 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, according to the following ABNF optional application-specific data, according to the following ABNF
[RFC5234] grammar: [RFC5234] grammar:
; "attribute" is defined in RFC 4566. ; "attribute" is defined in RFC 4566.
attribute =/ msid-attr attribute =/ msid-attr
msid-attr = "msid:" identifier [ SP appdata ] msid-attr = "msid:" msid-id [ SP msid-appdata ]
identifier = 1*64token-char ; see RFC 4566 msid-id = 1*64token-char ; see RFC 4566
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. It MUST be
unique among the identifier values used in the same SDP session. It unique among the identifier values used in the same SDP session. It
is RECOMMENDED that it is generated using a random-number generator. is RECOMMENDED that it is generated using a random-number generator.
skipping to change at page 6, line 8 skipping to change at page 6, line 19
different semantics to coexist. different semantics to coexist.
This OPTIONAL attribute gives the group identifier and its group This OPTIONAL attribute gives the group identifier and its group
semantic; it carries the same meaning as the ssrc-group-attr of RFC 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 5576 section 4.2, but uses the identifier of the group rather than a
list of SSRC values. list of SSRC values.
This attribute MUST be present if "a=msid" is used. This attribute MUST be present if "a=msid" is used.
An empty list of identifiers is an indication that the sender An empty list of identifiers is an indication that the sender
understands the indicated semantic, but has no msid groupings of the supports the indicated semantic, but has no msid groupings of the
given type in the present SDP. given type in the present SDP.
An identifier of "*" is an indication that all "a=msid" lines in the An identifier of "*" is an indication that all "a=msid" lines in the
SDP have this specific semantic. SDP have this specific semantic.
The ABNF of msid-semantic is: The ABNF of msid-semantic is:
attribute =/ msid-semantic-attr attribute =/ msid-semantic-attr
msid-semantic-attr = "msid-semantic:" semantic identifier-list msid-semantic-attr = "msid-semantic:" msid-semantic msid-list
semantic = token ; see RFC 4566 msid-semantic = token ; see RFC 4566
identifier-list = (" " identifier)* / " *" msid-list = *(" " msid-id) / " *"
The semantic field holds values from the IANA registriy "Semantics The semantic field holds values from the IANA registriy "Semantics
for the msid-semantic SDP attribute" (which is defined in Section 5). 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 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 registered by IANA for the same purpose as the existing LS grouping
semantic: semantic:
a=msid-semantic:LS xyzzy forolow a=msid-semantic:LS xyzzy forolow
This means that the SDP description has two lip sync groups, with the This means that the SDP description has two lip sync groups, with the
group identifiers xyzzy and forolow, respectively. group identifiers xyzzy and forolow, respectively.
4. Applying Msid to WebRTC MediaStreams 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
it uses.
4.1. Generating the Initial Offer
An entity implmementing an MSID semantic MUST add one or more "msid-
semantic" attributes to its session level attributes, indicating the
MSID semantic it supports.
4.2. Answerer Processing of the Offer
If an "msid-semantic" attribute is present in the answer, and the
offerer supports the indicated semantic, the offerer MUST follow the
procedures described for that semantic.
4.3. Generating the Answer
An entity implmementing an MSID semantic MUST add a "msid-semantic"
attribute to its session level attributes, indicating the MSID
semantic it supports.
4.4. Offerer Processing of the Answer
If an "msid-semantic" attribute is present in the answer, and the
offerer supports the indicated semantic, the offerer MUST follow the
procedures described for that semantic.
5. Applying Msid to WebRTC MediaStreams
This section creates a new semantic for use with the framework This section creates a new semantic for use with the framework
defined in Section 2, to be used for associating m-lines representing defined in Section 2, to be used for associating m-lines representing
MediaStreamTracks within MediaStreams as defined in MediaStreamTracks within MediaStreams as defined in
[W3C.WD-webrtc-20120209]. [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
skipping to change at page 7, line 45 skipping to change at page 8, line 45
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 section is disabled by setting the
port number to zero. Changing the direction of the media section to port number to zero. Changing the direction of the media section to
"recvonly" will not close the MediaStreamTrack. "recvonly" will not close the MediaStreamTrack.
The association between SSRCs and m-lines is specified in The association between SSRCs and m-lines is specified in
[I-D.ietf-rtcweb-jsep]. [I-D.ietf-rtcweb-jsep].
4.1. Handling of non-signalled tracks 5.1. Handling of non-signalled tracks
Non-WebRTC entities will not send msid. This means that there will Entities that do not implement the WMS semantic will not send "msid-
be some incoming RTP packets that the recipient has no predefined semantic:WMS". This means that there will be some incoming RTP
MediaStream id value for. packets that the recipient has no predefined MediaStream id value
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 Handling will depend on whether or not the msid-semantic:WMS
attribute is present. There are two cases: attribute is present. There are two cases:
o No "msid-semantic:WMS" attribute is present. The SDP session is o No "msid-semantic:WMS" attribute is present. The SDP session is
assumed to be a backwards-compatible session. All incoming media, assumed to be a backwards-compatible session. All incoming media,
on all m-lines that are part of the SDP session, are assumed to on all m-lines that are part of the SDP session, are assumed to
belong to independent media streams, each with one track. The belong to independent media streams, each with one track. The
identifier of this media stream and of the media stream track is a identifier of this media stream and of the media stream track is a
randomly generated string; the WebIDL "label" attribute of this randomly generated string; the WebIDL "label" attribute of this
media stream will be set to "Non-WMS stream". media stream will be set to "Non-WMS stream".
o An "msid-semantic:WMS" attribute is present. In this case, the o An "msid-semantic:WMS" attribute is present. In this case, the
session is WebRTC compatible, and the packets are either caused by sender implements the WMS semantic, and the packets are either
a bug or by timing skew between the arrival of the media packets caused by a bug or by timing skew between the arrival of the media
and the SDP description. These packets MAY be discarded, or they packets and the SDP description. These packets MAY be discarded,
MAY be buffered for a while in order to allow immediate startup of or they MAY be buffered for a while in order to allow immediate
the media stream when the SDP description is updated. The arrival startup of the media stream when the SDP description is updated.
of media packets MUST NOT cause a new MediaStreamTrack to be The arrival of media packets MUST NOT cause a new MediaStreamTrack
signaled. to be signaled.
If a WebRTC entity sends a description, it MUST include the msid- If an entity implementing the WMS semantic sends a description, it
semantic:WMS attribute, even if no media streams are sent. This MUST include the msid-semantic:WMS attribute, even if no media
allows us to distinguish between the case of no media streams at the streams are sent. This allows us to distinguish between the case of
moment and the case of legacy SDP generation. no media streams at the moment and the case of legacy SDP generation.
It follows from the above that the WebRTC entity must have the SDP of It follows from the above that the media receiver implmementing the
the other party before it can decide correctly which of the two cases WMS semantic must have the SDP of the other party before it can
described above applies. RTP media packets that arrive before the decide correctly which of the two cases described above applies. RTP
remote party's SDP MUST be buffered or discarded, and MUST NOT cause media packets that arrive before the remote party's SDP MUST be
a new MediaStreamTrack to be signalled. buffered or discarded, and MUST NOT cause a new MediaStreamTrack to
be signalled.
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 m-line by setting its port to zero.
4.2. Detailed procedures 5.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 They are specifically applicable to the WMS semantic; other semantics
will have their own consideration. will have their own consideration.
4.2.1. Generating the initial offer 5.2.1. Generating the initial offer
For each media section in the offer, if there is an associated For each media section in the offer, if there is an associated
MediaStreamTrack, the offerer adds one "a=msid" attribute to the MediaStreamTrack, the offerer adds one "a=msid" attribute to the
section for each MediaStream with which the MediaStreamTrack is 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.
4.2.2. Parsing the initial offer The offerer adds an "msid-semantic:WMS" field to the session-level
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 section in the offer, and for each "a=msid" attribute
in the media section, the receiver of the offer will perform the in the media section, the receiver of the offer will perform the
following steps: 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
4.2.3. Generating the answer 5.2.3. Generating the answer
The answer is generated in exactly the same manner as the offer. The answer is generated in exactly the same manner as the offer.
4.2.4. Offerer processing of the answer This includes adding a "msid-semantic:WMS" attribute in the session-
level headers, independent of whether or not such a header was
present in the offer.
5.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.
4.2.5. Modifying the session 5.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, close the MediaStreamTrack. This
will set its state to "ended". will set its state to "ended".
5. IANA Considerations 6. IANA Considerations
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
skipping to change at page 11, line 22 skipping to change at page 12, line 34
o Description: WebRTC Media Stream, as given in RFC XXXX. o Description: WebRTC Media Stream, as given in RFC XXXX.
o Token: WMS o Token: WMS
o Standards track reference: RFC XXXX o Standards track reference: RFC XXXX
IANA is requested to replace "RFC XXXX" with the RFC number of this IANA is requested to replace "RFC XXXX" with the RFC number of this
document upon publication. document upon publication.
6. Security Considerations 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 4.1, the amount of If implementing buffering as mentioned in Section 5.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.
7. Acknowledgements 8. 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 and Paul Kyzivat Special thanks to Flemming Andreassen, Miguel Garcia and Paul Kyzivat
for their work in reviewing this draft, with many specific language for their work in reviewing this draft, with many specific language
suggestions. suggestions.
8. References 9. References
8.1. Normative References 9.1. Normative References
[I-D.ietf-rtcweb-jsep] [I-D.ietf-rtcweb-jsep]
Uberti, J. and C. Jennings, "Javascript Session Uberti, J., Jennings, C., and E. Rescorla, "Javascript
Establishment Protocol", draft-ietf-rtcweb-jsep-06 (work Session Establishment Protocol", draft-ietf-rtcweb-jsep-07
in progress), February 2014. (work in progress), July 2014.
[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.
skipping to change at page 12, line 29 skipping to change at page 13, line 42
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009. (SDP)", RFC 5576, June 2009.
[W3C.WD-webrtc-20120209] [W3C.WD-webrtc-20120209]
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-20120209, February 2012, webrtc-20120209, February 2012,
<http://www.w3.org/TR/2012/WD-webrtc-20120209>. <http://www.w3.org/TR/2012/WD-webrtc-20120209>.
8.2. Informative References 9.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-12 (work in progress), October 2014.
[I-D.roach-mmusic-unified-plan] [I-D.roach-mmusic-unified-plan]
Roach, A., Uberti, J., and M. Thomson, "A Unified Plan for Roach, A., Uberti, J., and M. Thomson, "A Unified Plan for
Using SDP with Large Numbers of Media Flows", draft-roach- Using SDP with Large Numbers of Media Flows", draft-roach-
mmusic-unified-plan-00 (work in progress), July 2013. mmusic-unified-plan-00 (work in progress), July 2013.
[I-D.westerlund-avtcore-multiplex-architecture] [I-D.westerlund-avtcore-multiplex-architecture]
Westerlund, M., Perkins, C., and H. Alvestrand, Westerlund, M., Perkins, C., and H. Alvestrand,
"Guidelines for using the Multiplexing Features of RTP", "Guidelines for using the Multiplexing Features of RTP",
draft-westerlund-avtcore-multiplex-architecture-03 (work draft-westerlund-avtcore-multiplex-architecture-03 (work
skipping to change at page 17, line 22 skipping to change at page 18, line 41
a-z 0-9 hyphen; tightened ABNF by adding length description to it. a-z 0-9 hyphen; tightened ABNF by adding length description to it.
Deleted discussion of abandoned alternatives, as part of preparing Deleted discussion of abandoned alternatives, as part of preparing
for publication. for publication.
Added a "detailed procedures" section to the WMS semantics Added a "detailed procedures" section to the WMS semantics
description. description.
Added IANA registration of the "msid-semantic" attribute. Added IANA registration of the "msid-semantic" attribute.
C.13. Changes from -06 to -07
Changed terminology from referring to "WebRTC device" to referring to
"entities that implement the WMS semantic".
Changed names for ABNF constructions based on a proposal by Paul
Kyzivat.
Included a section on generic offer/answer semantics.
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. 32 change blocks. 
86 lines changed or deleted 148 lines changed or added

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