draft-ietf-mmusic-msid-03.txt   draft-ietf-mmusic-msid-04.txt 
Network Working Group H. Alvestrand Network Working Group H. Alvestrand
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track January 6, 2014 Intended status: Standards Track February 13, 2014
Expires: July 10, 2014 Expires: August 17, 2014
Cross Session Stream Identification in the Session Description Protocol WebRTC MediaStream Identification in the Session Description Protocol
draft-ietf-mmusic-msid-03 draft-ietf-mmusic-msid-04
Abstract Abstract
This document specifies a grouping mechanism for RTP media streams This document specifies a grouping mechanism for RTP media streams
that can be used to specify relations between 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.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 July 10, 2014. This Internet-Draft will expire on August 17, 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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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 5. WebRTC MediaStream Control . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Design considerations, open questions and and Appendix A. Design considerations, open questions and and
alternatives . . . . . . . . . . . . . . . . . . . . 11 alternatives . . . . . . . . . . . . . . . . . . . . 12
Appendix B. Usage with multiple MediaStreams per M-line . . . . . 12 Appendix B. Usage with multiple MediaStreams per M-line . . . . . 13
B.1. Mechanism design with multiple SSRCs . . . . . . . . . . . 12 B.1. Mechanism design with multiple SSRCs . . . . . . . . . . . 13
B.2. Usage with the SSRC attribute . . . . . . . . . . . . . . 13 B.2. Usage with the SSRC attribute . . . . . . . . . . . . . . 14
Appendix C. Change log . . . . . . . . . . . . . . . . . . . . . 13 Appendix C. Change log . . . . . . . . . . . . . . . . . . . . . 14
C.1. Changes from alvestrand-rtcweb-msid-00 to -01 . . . . . . 13 C.1. Changes from alvestrand-rtcweb-msid-00 to -01 . . . . . . 14
C.2. Changes from alvestrand-rtcweb-msid-01 to -02 . . . . . . 13 C.2. Changes from alvestrand-rtcweb-msid-01 to -02 . . . . . . 15
C.3. Changes from alvestrand-rtcweb-msid-02 to C.3. Changes from alvestrand-rtcweb-msid-02 to
mmusic-msid-00 . . . . . . . . . . . . . . . . . . . . . . 13 mmusic-msid-00 . . . . . . . . . . . . . . . . . . . . . . 15
C.4. Changes from alvestrand-mmusic-msid-00 to -01 . . . . . . 14 C.4. Changes from alvestrand-mmusic-msid-00 to -01 . . . . . . 15
C.5. Changes from alvestrand-mmusic-msid-01 to -02 . . . . . . 14 C.5. Changes from alvestrand-mmusic-msid-01 to -02 . . . . . . 15
C.6. Changes from alvestrand-mmusic-msid-02 to C.6. Changes from alvestrand-mmusic-msid-02 to
ietf-mmusic-00 . . . . . . . . . . . . . . . . . . . . . . 14 ietf-mmusic-00 . . . . . . . . . . . . . . . . . . . . . . 15
C.7. Changes from mmusic-msid-00 to -01 . . . . . . . . . . . . 14 C.7. Changes from mmusic-msid-00 to -01 . . . . . . . . . . . . 16
C.8. Changes from mmusic-msid-01 to -02 . . . . . . . . . . . . 14 C.8. Changes from mmusic-msid-01 to -02 . . . . . . . . . . . . 16
C.9. Changes from mmusic-msid-02 to -03 . . . . . . . . . . . . 15 C.9. Changes from mmusic-msid-02 to -03 . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 C.10. Changes from mmusic-msid-03 to -04 . . . . . . . . . . . . 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 grouping relation between M-lines that can This document adds a new grouping relation between M-lines 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.
skipping to change at page 8, line 40 skipping to change at page 8, line 40
discussion - including whether it's necessary to do so. Using the discussion - including whether it's necessary to do so. Using the
stream label seems like an easy thing to do for debuggability - it's stream label seems like an easy thing to do for debuggability - it's
not signalled, and is intended for human consumption anyway. not signalled, and is intended for human consumption anyway.
Another alternative is to group the incoming media streams based on Another alternative is to group the incoming media streams based on
CNAME; this preseerves the synchronization semantics of CNAME, but CNAME; this preseerves the synchronization semantics of CNAME, but
means that one cannot signal the MediaStreamTrack before the CNAME of means that one cannot signal the MediaStreamTrack before the CNAME of
the SSRC is known (which will happen only on arrival of the relevant the SSRC is known (which will happen only on arrival of the relevant
RTCP packet). RTCP packet).
5. IANA Considerations 5. WebRTC MediaStream Control
This document requests IANA to register the "msid" attribute in the A need has been identified for signalling from a receiver to a sender
"att-field (media level only)" registry within the SDP parameters some information about the receiver's desires for the sender to take
registry, according to the procedures of [RFC4566] action on a MediaStream track.
The required information is: This section describes such a mechanism. It is intended to be used
for streams that are signalled using the semantics in section
Section 4.
This mechanism consists of a single new field, "msid-control", which
can have the following values:
o msid-control: enable - the receiver positively acknowledges that
it wants the content of this media stream track. This has the
same semantics as leaving out the field altogether, but is
specified for completeness.
o msid-control: disable - the receiver desires that the sender stops
sending media on this track, but allows for a later round of
negotiation to resume transmission. The sender and receiver are
expected to continue including the corresponding SSRCs in RTCP
reports, keeping the information on the SSRCs from timing out.
o msid-control: stop - the receiver desires that the sender stops
sending media on this track, and guarantees that it will never ask
for data to be sent on this track again. The sender is expected
to stop reporting on the corresponding SSRCs, and MAY send a BYE
message when it stops sending.
o msid-control: reject - the exact same semantics as for msid-
control: stop apply, but this form is only used if the stream has
never been enabled. The intended use is for support of rejecting
a MediaStream, rather than stopping it (such a function has not
been specified so far).
The msid-control field is significant only for the direction from the
receiver to the sender; if a single m-line is used for MediaStreams
in both directions, only the streams sent by the receiver of the SDP
message will be affected.
If the MediaStream in both directions is cancelled by msid-control:
stop or msid-control: reject, the m-line MAY be disabled by setting
its port number to 0. If there is a MediaStream in use in either
direction, whether it's enabled or disabled, the m-line port number
MUST NOT be set to 0.
6. IANA Considerations
This document requests IANA to register the "msid" attribute and the
"msid-control" attribute in the "att-field (media level only)"
registry within the SDP parameters registry, according to the
procedures of [RFC4566]
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 The attribute value contains only ASCII characters, and is
therefore not subject to the charset attribute. therefore not subject to the charset attribute.
o The attribute gives an association over a set of m-lines. It can o The attribute gives an association over a set of m-lines. It can
be used to signal the relationship between a WebRTC MediaStream be used to signal the relationship between a WebRTC MediaStream
and a set of m-lines. and a set of m-lines.
o The details of appropriate values are given in RFC XXXX. o The details of appropriate values are given in RFC XXXX.
The required information for "msid-control" is:
o Contact name, email: IETF, contacted via mmusic@ietf.org, or a
successor address designated by IESG
o Attribute name: msid-control
o Long-form attribute name: Media stream control
o The attribute value contains only ASCII characters, and is
therefore not subject to the charset attribute.
o The attribute states the desires of a recipient with regards to a
WebRTC MediaStream in the context of an m-line.
o The details of appropriate values 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.
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 Section 4.1, the If implementing buffering as mentioned in section Section 4.1, the
amount of buffering should be limited to avoid memory exhaustion amount of 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 that are relevant to the browser's security have
been identified that depend on this mechanism. 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 Miguel Garcia and Paul Kyzivat for their work in Special thanks to Miguel Garcia and Paul Kyzivat for their work in
reviewing this draft, with many specific language suggestions. reviewing this draft, with many specific language suggestions.
8. References 9. References
8.1. Normative References 9.1. Normative References
[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 10, line 41 skipping to change at page 12, line 12
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-webrtc-
20120209, February 2012, 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,
"Multiplexing Negotiation Using Session Description "Multiplexing Negotiation Using Session Description
Protocol (SDP) Port Numbers", Protocol (SDP) Port Numbers",
draft-ietf-mmusic-sdp-bundle-negotiation-04 (work in draft-ietf-mmusic-sdp-bundle-negotiation-04 (work in
progress), June 2013. progress), June 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
skipping to change at page 15, line 20 skipping to change at page 16, line 38
Corrected even more cases where the word "ssrc" was not changed to Corrected even more cases where the word "ssrc" was not changed to
"M-line". "M-line".
Added the functionality of using an asterisk (*) in the msid-semantic Added the functionality of using an asterisk (*) in the msid-semantic
line, in order to remove the need for listing all msids in the msid- line, in order to remove the need for listing all msids in the msid-
semantic line whne only one msid-semantic is in use. semantic line whne only one msid-semantic is in use.
Removed some now-unnecessary text. Removed some now-unnecessary text.
C.10. Changes from mmusic-msid-03 to -04
Changed title to reflect focus on WebRTC MediaStreams
Added a section on receiver-side media stream control, using the
"msid-control" 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. 17 change blocks. 
36 lines changed or deleted 110 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/