draft-ietf-mmusic-msid-05.txt   draft-ietf-mmusic-msid-06.txt 
Network Working Group H. Alvestrand Network Working Group H. Alvestrand
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track March 6, 2014 Intended status: Standards Track June 9, 2014
Expires: September 7, 2014 Expires: December 11, 2014
WebRTC MediaStream Identification in the Session Description Protocol WebRTC MediaStream Identification in the Session Description Protocol
draft-ietf-mmusic-msid-05 draft-ietf-mmusic-msid-06
Abstract Abstract
This document specifies a grouping mechanism for RTP media streams This document specifies a Session Description Protocol (SDP) Grouping
that can be used to specify relations between media streams. mechanism for RTP media streams that can be used to specify relations
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.
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].
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 September 7, 2014. This Internet-Draft will expire on December 11, 2014.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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. Application to the WEBRTC MediaStream . . . . . . . . . . 4
2. The Msid Mechanism . . . . . . . . . . . . . . . . . . . . . . 4 2. The Msid Mechanism . . . . . . . . . . . . . . . . . . . . . 4
3. The Msid-Semantic Attribute . . . . . . . . . . . . . . . . . 5 3. The Msid-Semantic Attribute . . . . . . . . . . . . . . . . . 5
4. Applying Msid to WebRTC MediaStreams . . . . . . . . . . . . . 6 4. Applying Msid to WebRTC MediaStreams . . . . . . . . . . . . 6
4.1. Handling of non-signalled tracks . . . . . . . . . . . . . 7 4.1. Handling of non-signalled tracks . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4.2. Detailed procedures . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4.2.1. Generating the initial offer . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.2. Parsing the initial offer . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.3. Generating the answer . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 4.2.4. Offerer processing of the answer . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 10 4.2.5. Modifying the session . . . . . . . . . . . . . . . . 9
Appendix A. Design considerations, rejected alternatives . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
Appendix B. Usage with multiple MediaStreams per M-line . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
B.1. Mechanism design with multiple SSRCs . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
B.2. Usage with the SSRC attribute . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
Appendix C. Change log . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 11
C.1. Changes from alvestrand-rtcweb-msid-00 to -01 . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 12
C.2. Changes from alvestrand-rtcweb-msid-01 to -02 . . . . . . 13 Appendix A. Design considerations, rejected alternatives . . . . 13
C.3. Changes from alvestrand-rtcweb-msid-02 to Appendix B. Usage with multiple MediaStreams per M-line . . . . 13
mmusic-msid-00 . . . . . . . . . . . . . . . . . . . . . . 13 B.1. Mechanism design with multiple SSRCs . . . . . . . . . . 13
C.4. Changes from alvestrand-mmusic-msid-00 to -01 . . . . . . 13 B.2. Usage with the SSRC attribute . . . . . . . . . . . . . . 14
C.5. Changes from alvestrand-mmusic-msid-01 to -02 . . . . . . 14 Appendix C. Change log . . . . . . . . . . . . . . . . . . . . . 14
C.6. Changes from alvestrand-mmusic-msid-02 to C.1. Changes from alvestrand-rtcweb-msid-00 to -01 . . . . . . 14
ietf-mmusic-00 . . . . . . . . . . . . . . . . . . . . . . 14 C.2. Changes from alvestrand-rtcweb-msid-01 to -02 . . . . . . 15
C.7. Changes from mmusic-msid-00 to -01 . . . . . . . . . . . . 14 C.3. Changes from alvestrand-rtcweb-msid-02 to mmusic-msid-00 15
C.8. Changes from mmusic-msid-01 to -02 . . . . . . . . . . . . 14 C.4. Changes from alvestrand-mmusic-msid-00 to -01 . . . . . . 15
C.9. Changes from mmusic-msid-02 to -03 . . . . . . . . . . . . 14 C.5. Changes from alvestrand-mmusic-msid-01 to -02 . . . . . . 15
C.10. Changes from mmusic-msid-03 to -04 . . . . . . . . . . . . 15 C.6. Changes from alvestrand-mmusic-msid-02 to ietf-mmusic-00 15
C.11. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 15 C.7. Changes from mmusic-msid-00 to -01 . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 C.8. Changes from mmusic-msid-01 to -02 . . . . . . . . . . . 16
C.9. Changes from mmusic-msid-02 to -03 . . . . . . . . . . . 16
C.10. Changes from mmusic-msid-03 to -04 . . . . . . . . . . . 16
C.11. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 16
C.12. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
1.1. Structure Of This Document 1.1. Structure Of This Document
This document adds a new grouping relation between M-lines that can This document adds a new Session Description Protocol (SDP)
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
gives the possibility of using MSIDs with different semantics in the
same SDP message.
Section 4 gives the application of the new mechanism for providing Section 4 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 API . 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 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 m-lines. According to the model
used in [I-D.roach-mmusic-unified-plan], each m-line describes used in [I-D.ietf-rtcweb-jsep], each m-line describes exactly one
exactly one media source, and if mulitple media sources are carried media source, and if mulitple media sources are carried in an RTP
in an RTP session, this is signalled using BUNDLE 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 There exist cases where an application using RTP and SDP needs to
signal some relationship between RTP media streams that may be signal some relationship between RTP media streams that may be
carried in either the same RTP session or different RTP sessions. carried in either the same RTP session or different RTP sessions.
For instance, there may be a need to signal a relationship between a For instance, there may be a need to signal a relationship between a
video track and an audio track, and where the generator of the SDP video track and an audio track, and where the generator of the SDP
does not yet know if they will be carried in the same RTP session or does not yet know if they will be carried in the same RTP session or
different RTP sessions. different RTP sessions.
skipping to change at page 4, line 22 skipping to change at page 4, line 36
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.
The WebRTC work has come to agreement (documented in WebRTC defines a mapping (documented in [I-D.ietf-rtcweb-jsep]) where
[I-D.roach-mmusic-unified-plan]) that one M-line is used to describe one SDP m-line is used to describe each MediaStreamTrack, and that
each MediaStreamTrack, and that the BUNDLE mechanism the BUNDLE mechanism [I-D.ietf-mmusic-sdp-bundle-negotiation] is used
[I-D.ietf-mmusic-sdp-bundle-negotiation] is used to group to group MediaStreamTracks into RTP sessions. Therefore, the need is
MediaStreamTracks into RTP sessions. Therefore, the need is to to specify the ID of a MediaStreamTrack and its associated
specify the ID of a MediaStreamTrack and its containing MediaStream MediaStream for each m-line, which can be accomplished with a media-
for each M-line, which can be accomplished with a media-level level SDP attribute.
attribute.
This usage is described in Section 4. This usage is described in Section 4.
2. The Msid Mechanism 2. The Msid Mechanism
This document registers 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, as media streams that are carried in the same or different m-lines. The
well as allowing application-specific information to the association. attribute also allows application-specific 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, 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 [ " " appdata ] msid-attr = "msid:" identifier [ SP appdata ]
identifier = token identifier = 1*64token-char ; see RFC 4566
appdata = token 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 chosen from 0-9, a-z, The identifier is a string of ASCII characters that are legal in a
A-Z and - (hyphen), consisting of between 1 and 64 characters. It "token", consisting of between 1 and 64 characters. It MUST be
MUST be unique among the identifier values used in the same SDP unique among the identifier values used in the same SDP session. It
session. It is RECOMMENDED that is generated using a random-number is RECOMMENDED that it is generated using a random-number generator.
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 on a single m-line. There may There may be multiple msid attributes in a single media description.
also be multiple m-lines that have the same value for identifier and There may also be multiple media descriptions that have the same
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. The Msid-Semantic Attribute
A session-level attribute is defined for signaling the semantics A session-level attribute is defined for signaling the semantics
associated with an msid grouping. This allows msid groupings with associated with an msid grouping. This allows msid groupings with
skipping to change at page 6, line 8 skipping to change at page 6, line 17
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 understands 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:" token identifier-list msid-semantic-attr = "msid-semantic:" semantic identifier-list
semantic = token ; see RFC 4566
identifier-list = (" " identifier)* / " *" identifier-list = (" " identifier)* / " *"
token = <as defined in RFC 4566>
The semantic field may hold 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 by this memo). for the msid-semantic SDP attribute" (which is defined in Section 5).
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 4. 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
"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 msid corresponds to the "id" attribute of a The value of the "identifier" field in the msid consists of the "id"
MediaStream. attribute of a MediaStream, as defined in its WebIDL specification.
The appdata for a WebRTC MediaStreamTrack consists of the "id" The value of the "appdata" field in the msid consists of the "id"
attribute of a MediaStreamTrack. attribute of a MediaStreamTrack, as defined in its WebIDL
specification.
If two different m-lines have MSID attributes with the same value for If two different m-lines have MSID attributes with the same value for
identifier and appdata, it means that these two m-lines are both identifier and appdata, it means that these two m-lines are both
intended for the same MediaStreamTrack. So far, no semantic for such intended for the same MediaStreamTrack. So far, no semantic for such
a mixture have been defined, but this specification does not forbid a mixture have been defined, but this specification does not forbid
the practice. the practice.
When an SDP description is updated, a specific msid continues to When an SDP description is updated, a specific msid "identifier"
refer to the same MediaStream. Once negotiation has completed on a continues to refer to the same MediaStream, and a specific "appdata"
session, there is no memory; an msid value that appears in a later to the same MediaStreamTrack. Once negotiation has completed on a
session, there is no memory apart from the currently valid SDP
descriptions; an msid "identifier" value that appears in a later
negotiation will be taken to refer to a new MediaStream. negotiation will be taken to refer to a 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
m-lines and their msid values. m-lines and their msid values.
o When a new msid value occurs in the description, the recipient can o When a new msid "identifier" value occurs in the description, the
signal to its application that a new MediaStream has been added. recipient can signal to its application that a new MediaStream has
been added.
o When a description is updated to have more m-lines with the same
msid value, but different appdata values, the recipient can signal
to its application that new MediaStreamTracks have been added to
the media stream.
o When a description is updated to no longer list the msid value on o When a description is updated to have more media sections with the
a specific m-line, the recipient can signal to its application same msid "identifier" value, but different "appdata" values, the
that the corresponding media stream track has been closed. recipient can signal to its application that new MediaStreamTracks
have been added to the MediaStream.
o When a description is updated to no longer list the msid value on o When a description is updated to no longer list the msid attribute
any m-line, the recipient can signal to its application that the on a specific media description, the recipient can signal to its
media stream has been closed. application that the corresponding MediaStreamTrack has ended.
In addition to signaling that the track is closed when it disappears In addition to signaling that the track is closed when its msid
from the SDP, the track will also be signaled as being closed when attribute disappears from the SDP, the track will also be signaled as
all associated SSRCs have disappeared by the rules of [RFC3550] being closed when all associated SSRCs have disappeared by the rules
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
port number to zero. Changing the direction of the media section to
"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.roach-mmusic-unified-plan]. [I-D.ietf-rtcweb-jsep].
4.1. Handling of non-signalled tracks 4.1. Handling of non-signalled tracks
Non-WebRTC entities will not send msid. This means that there will Non-WebRTC entities will not send msid. This means that there will
be some incoming RTP packets that the recipient has no predefined be some incoming RTP packets that the recipient has no predefined
MediaStream id value for. MediaStream id value for.
Handling will depend on whether or not any MSIDs are signaled in the Note that this handling is triggered by incoming RTP packets, not by
relevant m-line(s). There are two cases: SDP negotiation.
o No msid-semantic:WMS attribute is present. The SDP session is Handling will depend on whether or not the msid-semantic:WMS
attribute is present. There are two cases:
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 label of this media stream will be randomly generated string; the WebIDL "label" attribute of this
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 session is WebRTC compatible, and the packets are either caused by
a bug or by timing skew between the arrival of the media packets a bug or by timing skew between the arrival of the media packets
and the SDP description. These packets MAY be discarded, or they and the SDP description. These packets MAY be discarded, or they
MAY be buffered for a while in order to allow immediate startup of MAY be buffered for a while in order to allow immediate startup of
the media stream when the SDP description is updated. The arrival the media stream when the SDP description is updated. The arrival
of media packets MUST NOT cause a new MediaStreamTrack to be of media packets MUST NOT cause a new MediaStreamTrack to be
signaled. signaled.
If a WebRTC entity sends a description, it MUST include the msid- If a WebRTC entity sends a description, it MUST include the msid-
semantic:WMS attribute, even if no media streams are sent. This semantic:WMS attribute, even if no media streams are sent. This
allows us to distinguish between the case of no media streams at the allows us to distinguish between the case of no media streams at the
moment and the case of legacy SDP generation. 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 WebRTC entity must have the SDP of
the other party before it can decide correctly whether or not a the other party before it can decide correctly which of the two cases
"default" MediaStream should be created. RTP media packets that described above applies. RTP media packets that arrive before the
arrive before the remote party's SDP MUST be buffered or discarded, remote party's SDP MUST be buffered or discarded, and MUST NOT cause
and MUST NOT cause a new MediaStreamTrack to be signalled. 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 signaling; the application must media stream cannot be closed by removing the msid attribute; the
instead signal these as closed when the SSRC disappears according to application must instead signal these as closed when the SSRC
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.
NOTE IN DRAFT: Previous versions of this memo suggested adding all 4.2. Detailed procedures
incoming SSRCs to a single MediaStream. This is problematic because
we do not know if the SSRCs are synchronized or not before we learn
the CNAME of the SSRCs, which only happens when an RTCP packet
arrives. How to identify a non-WMS stream is still open for
discussion - including whether it's necessary to do so. Using the
stream label seems like an easy thing to do for debuggability - it's
not signalled, and is intended for human consumption anyway.
Another alternative is to group the incoming media streams based on These procedures are given in terms of RFC 3264-recommended sections.
CNAME; this preseerves the synchronization semantics of CNAME, but They describe the actions to be taken in terms of MediaStreams and
means that one cannot signal the MediaStreamTrack before the CNAME of MediaStreamTracks; they do not include event signalling inside the
the SSRC is known (which will happen only on arrival of the relevant application, which is described in JSEP.
RTCP packet).
They are specifically applicable to the WMS semantic; other semantics
will have their own consideration.
4.2.1. Generating the initial offer
For each media section in the offer, if there is an associated
MediaStreamTrack, the offerer adds one "a=msid" attribute to the
section for each MediaStream with which the MediaStreamTrack is
associated. The "identifier" field of the attribute is set to the
WebIDL "id" attribute of the MediaStream, and the "appdata" field is
set to the WebIDL "id" attribute of the MediaStreamTrack.
4.2.2. Parsing the initial offer
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
following steps:
o Extract the "appdata" field of the "a=msid" attribute
o Check if a MediaStreamTrack with the same WebIDL "id" attribute as
the "appdata" field already exists, and is not in the "ended"
state. If it is not found, create it.
o Extract the "identifier" field of the "a=msid" attribte.
o Check if a MediaStream with the same WebIDL "id" attribute already
exists. If not, create it.
o Add the MediaStreamTrack to the MediaStream
4.2.3. Generating the answer
The answer is generated in exactly the same manner as the offer.
4.2.4. Offerer processing of the answer
The answer is processed in exactly the same manner as the offer.
4.2.5. Modifying the session
On subsequent exchanges, precisely the same procedure as for the
initial offer/answer is followed, but with one additional step in the
parsing of the offer and answer:
o For each MediaStreamTrack that has been created as a result of
previous offer/answer exchanges, and is not in the "ended" state,
check to see if there is still an "a=msid" attribute in the
present SDP whose "appdata" field is the same as the WebIDL "id"
attribute of the track.
o If no such attribute is found, close the MediaStreamTrack. This
will set its state to "ended".
5. IANA Considerations 5. IANA Considerations
This document requests IANA to register the "msid" attribute and the This document requests IANA to register the "msid" attribute in the
"msid-control" attribute in the "att-field (media level only)" "att-field (media level only)" registry within the SDP parameters
registry within the SDP parameters registry, according to the registry, according to the procedures of [RFC4566]
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 The attribute value contains only ASCII characters, and is o Subject to charset: The attribute value contains only ASCII
therefore not subject to the charset attribute. characters, and is therefore not subject to the charset attribute.
o The attribute gives an association over a set of m-lines. It can o Purpose: The attribute gives an association over a set of m-lines.
be used to signal the relationship between a WebRTC MediaStream It can be used to signal the relationship between a WebRTC
and a set of m-lines. MediaStream and a set of m-lines.
o The details of appropriate values are given in RFC XXXX. o Appropriate values: The details of appropriate values are given in
RFC XXXX.
This document requests IANA to register the "msid-semantic" attribute
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.
This document requests IANA to create a new registry called This document requests IANA to create a new registry called
"Semantics for the msid-semantic SDP attribute", which should have "Semantics for the msid-semantic SDP attribute", which should have
exactly the same rules as for the "Semantics for the ssrc-group SDP exactly the same rules as for the "Semantics for the ssrc-group SDP
attribute" registry (Expert Review), and to register the "WMS" attribute" registry (Expert Review), and to register the "WMS"
semantic within this new registry. semantic within this new registry.
The required information is: The required information is:
o Description: WebRTC Media Stream, as given in RFC XXXX. o Description: WebRTC Media Stream, as given in RFC XXXX.
skipping to change at page 9, line 46 skipping to change at page 11, line 30
document upon publication. document upon publication.
6. Security Considerations 6. 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 Section 4.1, the If implementing buffering as mentioned in Section 4.1, the amount of
amount of buffering should be limited to avoid memory exhaustion buffering should be limited to avoid memory exhaustion attacks.
attacks.
No other attacks that are relevant to the browser's security have No other attacks have been identified that depend on this mechanism.
been identified that depend on this mechanism.
7. Acknowledgements 7. 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 Miguel Garcia and Paul Kyzivat for their work in Special thanks to Flemming Andreassen, Miguel Garcia and Paul Kyzivat
reviewing this draft, with many specific language suggestions. for their work in reviewing this draft, with many specific language
suggestions.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-rtcweb-jsep]
Uberti, J. and C. Jennings, "Javascript Session
Establishment Protocol", draft-ietf-rtcweb-jsep-06 (work
in progress), February 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.
[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.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
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-webrtc- Browsers", World Wide Web Consortium WD WD-
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 8.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,
"Multiplexing Negotiation Using Session Description "Negotiating Media Multiplexing Using the Session
Protocol (SDP) Port Numbers", Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
draft-ietf-mmusic-sdp-bundle-negotiation-05 (work in negotiation-07 (work in progress), April 2014.
progress), October 2013.
[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", Using SDP with Large Numbers of Media Flows", draft-roach-
draft-roach-mmusic-unified-plan-00 (work in progress), mmusic-unified-plan-00 (work in progress), July 2013.
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
in progress), February 2013. in progress), February 2013.
[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.
skipping to change at page 15, line 24 skipping to change at page 17, line 5
Added a section on receiver-side media stream control, using the Added a section on receiver-side media stream control, using the
"msid-control" attribute. "msid-control" attribute.
C.11. Changes from -04 to -05 C.11. Changes from -04 to -05
Removed the msid-control section after WG discussion. Removed the msid-control section after WG discussion.
Removed some text that seemed only to pertain to resolved issues. Removed some text that seemed only to pertain to resolved issues.
C.12. Changes from -05 to -06
Addressed issues found in Fleming Andreassen's review
Referenced JSEP rather than unified-plan for the M-line mapping model
Relaxed MSID definition to allow "token-char" in values rather than
a-z 0-9 hyphen; tightened ABNF by adding length description to it.
Deleted discussion of abandoned alternatives, as part of preparing
for publication.
Added a "detailed procedures" section to the WMS semantics
description.
Added IANA registration of the "msid-semantic" attribute.
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. 51 change blocks. 
151 lines changed or deleted 258 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/