draft-ietf-mmusic-msid-10.txt   draft-ietf-mmusic-msid-11.txt 
Network Working Group H. Alvestrand Network Working Group H. Alvestrand
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track April 28, 2015 Intended status: Standards Track October 1, 2015
Expires: October 30, 2015 Expires: April 3, 2016
WebRTC MediaStream Identification in the Session Description Protocol WebRTC MediaStream Identification in the Session Description Protocol
draft-ietf-mmusic-msid-10 draft-ietf-mmusic-msid-11
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 "media description" and the WebRTC concept of concept of "media description" and the WebRTC concept of
"MediaStream" / "MediaStreamTrack" using SDP signaling. "MediaStream" / "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 October 30, 2015. This Internet-Draft will expire on April 3, 2016.
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 3, line 11 skipping to change at page 3, line 11
B.6. Changes from alvestrand-mmusic-msid-02 to ietf-mmusic-00 13 B.6. Changes from alvestrand-mmusic-msid-02 to ietf-mmusic-00 13
B.7. Changes from mmusic-msid-00 to -01 . . . . . . . . . . . 13 B.7. Changes from mmusic-msid-00 to -01 . . . . . . . . . . . 13
B.8. Changes from mmusic-msid-01 to -02 . . . . . . . . . . . 13 B.8. Changes from mmusic-msid-01 to -02 . . . . . . . . . . . 13
B.9. Changes from mmusic-msid-02 to -03 . . . . . . . . . . . 14 B.9. Changes from mmusic-msid-02 to -03 . . . . . . . . . . . 14
B.10. Changes from mmusic-msid-03 to -04 . . . . . . . . . . . 14 B.10. Changes from mmusic-msid-03 to -04 . . . . . . . . . . . 14
B.11. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 14 B.11. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 14
B.12. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 14 B.12. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 14
B.13. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 15 B.13. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 15
B.14. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 15 B.14. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 15
B.15. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 15 B.15. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 B.16. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 15
B.17. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
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. It is streams and attaching identifiers to the groupings they form. It is
designed for use with WebRTC[I-D.ietf-rtcweb-overview] . designed for use with WebRTC[I-D.ietf-rtcweb-overview] .
skipping to change at page 4, line 18 skipping to change at page 4, line 19
The W3C WebRTC API specification [W3C.WD-webrtc-20150210] 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.
MediaStreamTracks are unidirectional; they carry media on one
direction only.
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 media description is used to describe each MediaStreamTrack, one SDP media description is used to describe each MediaStreamTrack,
and that the BUNDLE mechanism and the BUNDLE mechanism [I-D.ietf-mmusic-sdp-bundle-negotiation] is
[I-D.ietf-mmusic-sdp-bundle-negotiation] is used to group used to group MediaStreamTracks into RTP sessions. Therefore, the
MediaStreamTracks into RTP sessions. Therefore, the need is to need is to specify the ID of a MediaStreamTrack and its associated
specify the ID of a MediaStreamTrack and its associated MediaStream MediaStream for each media description, which can be accomplished
for each media description, which can be accomplished with a media- with a media-level SDP attribute.
level SDP attribute.
This usage is described in Section 3. 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 described in different media descriptions. media streams that are described in different media descriptions with
The attribute also allows application-specific information to the the same MediaStreams as defined in [W3C.WD-webrtc-20150210]., and to
association. carry an identifier for each MediaStreamTrack in its "appdata" field.
The value of the "msid" attribute consists of an identifier and The value of the "msid" attribute consists of an identifier and an
optional application-specific data. optional "appdata" field.
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. "token", consisting of between 1 and 64 characters.
Application data is carried on the same line as the identifier, Application data (msid-appdata) is carried on the same line as the
separated from the identifier by a space. identifier, separated from the identifier by a space.
The identifier uniquely identifies a group within the scope of an SDP The identifier (msid-id) uniquely identifies a group within the scope
description. of an SDP 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 This represents the case where a single MediaStreamTrack is present
value for identifier and application data. in multiple MediaStreams; the value of "msid-appdata" MUST be
identical for all occurences.
Multiple media descriptions with the same value for msid-id and msid-
appdata is not permitted.
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.
restrictions of such grouping and ungrouping are application
dependent.
3. Procedures 3. Procedures
This section describes how to use the msid-semantic attribute for This section describes the procedures for associating media
associating media descriptions representing MediaStreamTracks within descriptions representing MediaStreamTracks within MediaStreams as
MediaStreams as defined in [W3C.WD-webrtc-20150210]. defined in [W3C.WD-webrtc-20150210].
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 value of the "msid-id" 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 "msid-appdata" field in the msid consists of the The value of the "msid-appdata" field in the msid consists of the
"id" attribute of a MediaStreamTrack, as defined in its WebIDL "id" attribute of a MediaStreamTrack, as defined in its WebIDL
specification. specification.
If two different media descriptions have MSID attributes with the
same values for "msid-id" and "msid-appdata", it means that these two
media descriptions are both intended for the same MediaStreamTrack.
So far, no semantic for such a mixture have been defined, but this
specification does not forbid the practice.
When an SDP session description is updated, a specific "msid-id" When an SDP session description is updated, a specific "msid-id"
continues to refer to the same MediaStream, and a specific "msid- continues to refer to the same MediaStream, and a specific "msid-
appdata" to the same MediaStreamTrack. There is no memory apart from appdata" to the same MediaStreamTrack. There is no memory apart from
the currently valid SDP descriptions; if an msid "identifier" value the currently valid SDP descriptions; if an msid "identifier" value
disappears from the SDP and appears in a later negotiation, it will disappears from the SDP and appears in a later negotiation, it will
be taken to refer to a new MediaStream. be taken to refer to a new MediaStream.
The following is a high level description of the rules for handling The following is a high level description of the rules for handling
SDP updates. Detailed procedures are in Section 3.2. SDP updates. Detailed procedures are in Section 3.2.
skipping to change at page 6, line 40 skipping to change at page 6, line 41
signal to its application that the corresponding MediaStreamTrack signal to its application that the corresponding MediaStreamTrack
has ended. 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 description is disabled by setting and when the corresponding media description is disabled by setting
the port number to zero. Changing the direction of the media the port number to zero. Changing the direction of the media
description (by setting "sendonly", "recvonly" or "inactive" description (by setting "sendonly", "recvonly" or "inactive"
attributes) will not close the MediaStreamTrack. (This mechanism may attributes) will not close the MediaStreamTrack.
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 media descriptions is specified in The association between SSRCs and media descriptions is specified in
[I-D.ietf-rtcweb-jsep]. [I-D.ietf-rtcweb-jsep].
3.1. Handling of non-signalled tracks 3.1. Handling of non-signalled tracks
Entities that do not use msid will not send msid. This means that Entities that do not use msid will not send msid. This means that
there will be some incoming RTP packets that the recipient has no there will be some incoming RTP packets that the recipient has no
predefined MediaStream id value for. predefined MediaStream id value for.
skipping to change at page 7, line 20 skipping to change at page 7, line 20
where the answerer adds a MediaStreamTrack to an already established where the answerer adds a MediaStreamTrack to an already established
connection and starts sending data before the answer is received by connection and starts sending data before the answer is received by
the offerer. For initial negotiation, packets won't flow until the the offerer. For initial negotiation, packets won't flow until the
ICE candidates and fingerprints have been exchanged, so this is not ICE candidates and fingerprints have been exchanged, so this is not
an issue. an issue.
The recipient of those packets will perform the following steps: The recipient of those packets will perform the following steps:
o When RTP packets are initially received, it will create an o When RTP packets are initially received, it will create an
appropriate MediaStreamTrack based on the type of the media appropriate MediaStreamTrack based on the type of the media
(carried in PayloadType), and use the mid RTP attribute (if (carried in PayloadType), and use the MID RTP header extension
present) to associate the RTP packets with a specific media [I-D.ietf-mmusic-sdp-bundle-negotiation] (if present) to associate
section. If the connection is not in the RTCSignalingState the RTP packets with a specific media section. If the connection
"stable", it will wait at this point. is not in the RTCSignalingState "stable", it will wait at this
point.
o When the connection is in the RTCSignalingState "stable", it will o When the connection is in the RTCSignalingState "stable", it will
look at the relevant media section to find the msid attribute. look at the relevant media section to find the msid attribute.
o If there is an msid attribute, it will use that attribute to o If there is an msid attribute, it will use that attribute to
populate the "id" field of the MediaStreamTrack and associated populate the "id" field of the MediaStreamTrack and associated
MediaStreams, as described above. MediaStreams, as described above.
o If there is no msid attribute, the identifier of the o If there is no msid attribute, the identifier of the
MediaStreamTrack will be set to a randomly generated string, and MediaStreamTrack will be set to a randomly generated string, and
skipping to change at page 10, line 50 skipping to change at page 10, line 50
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.
6. 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, Magnus Westerlund and Paul Kyzivat for their
this draft, with many specific language suggestions. work in reviewing this draft, with many specific language
suggestions.
7. References 7. References
7.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-09 Session Establishment Protocol", draft-ietf-rtcweb-jsep-07
(work in progress), March 2015. (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.
[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-20150210] [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-webrtc- Browsers", World Wide Web Consortium WD WD-
20150210, February 2015, webrtc-20150210, February 2015,
<http://www.w3.org/TR/2015/WD-webrtc-20150210>. <http://www.w3.org/TR/2015/WD-webrtc-20150210>.
7.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-19 (work in progress), March 2015. negotiation-07 (work in progress), April 2014.
[I-D.ietf-rtcweb-overview] [I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", draft-ietf-rtcweb-overview-13 Browser-based Applications", draft-ietf-rtcweb-overview-10
(work in progress), November 2014. (work in progress), June 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
One suggested mechanism has been to use CNAME instead of a new One suggested mechanism has been to use CNAME instead of a new
skipping to change at page 15, line 44 skipping to change at page 15, line 44
Addressed a number of review comments from Fleming Andresen and Addressed a number of review comments from Fleming Andresen and
others. others.
Changed the term "m-line" to "media description", since that is the Changed the term "m-line" to "media description", since that is the
term used in RFC 4566. term used in RFC 4566.
Tried to make sure this document does not describe the API to the Tried to make sure this document does not describe the API to the
application. application.
B.16. Changes from -09 to -10
Language clarifications.
Removed more leftover traces of wms-semantic.
B.17. Changes from -10 to -11
Defined the semantics of multiple MSIDs in a media section to be a
MediaStreamTrack present in multiple MediaStreams.
Made an explicit note that MediaStreamTracks are unidirectional.
Disallowed the option of sending multiple media sections with the
same msid (id and appdata identical).
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. 22 change blocks. 
51 lines changed or deleted 66 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/