draft-ietf-mmusic-msid-04.txt   draft-ietf-mmusic-msid-05.txt 
Network Working Group H. Alvestrand Network Working Group H. Alvestrand
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track February 13, 2014 Intended status: Standards Track March 6, 2014
Expires: August 17, 2014 Expires: September 7, 2014
WebRTC MediaStream Identification in the Session Description Protocol WebRTC MediaStream Identification in the Session Description Protocol
draft-ietf-mmusic-msid-04 draft-ietf-mmusic-msid-05
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 August 17, 2014. This Internet-Draft will expire on September 7, 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. WebRTC MediaStream Control . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 12 Appendix A. Design considerations, rejected alternatives . . . . 11
Appendix A. Design considerations, open questions and and Appendix B. Usage with multiple MediaStreams per M-line . . . . . 11
alternatives . . . . . . . . . . . . . . . . . . . . 12 B.1. Mechanism design with multiple SSRCs . . . . . . . . . . . 12
Appendix B. Usage with multiple MediaStreams per M-line . . . . . 13 B.2. Usage with the SSRC attribute . . . . . . . . . . . . . . 13
B.1. Mechanism design with multiple SSRCs . . . . . . . . . . . 13 Appendix C. Change log . . . . . . . . . . . . . . . . . . . . . 13
B.2. Usage with the SSRC attribute . . . . . . . . . . . . . . 14 C.1. Changes from alvestrand-rtcweb-msid-00 to -01 . . . . . . 13
Appendix C. Change log . . . . . . . . . . . . . . . . . . . . . 14 C.2. Changes from alvestrand-rtcweb-msid-01 to -02 . . . . . . 13
C.1. Changes from alvestrand-rtcweb-msid-00 to -01 . . . . . . 14
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 . . . . . . . . . . . . . . . . . . . . . . 15 mmusic-msid-00 . . . . . . . . . . . . . . . . . . . . . . 13
C.4. Changes from alvestrand-mmusic-msid-00 to -01 . . . . . . 15 C.4. Changes from alvestrand-mmusic-msid-00 to -01 . . . . . . 13
C.5. Changes from alvestrand-mmusic-msid-01 to -02 . . . . . . 15 C.5. Changes from alvestrand-mmusic-msid-01 to -02 . . . . . . 14
C.6. Changes from alvestrand-mmusic-msid-02 to C.6. Changes from alvestrand-mmusic-msid-02 to
ietf-mmusic-00 . . . . . . . . . . . . . . . . . . . . . . 15 ietf-mmusic-00 . . . . . . . . . . . . . . . . . . . . . . 14
C.7. Changes from mmusic-msid-00 to -01 . . . . . . . . . . . . 16 C.7. Changes from mmusic-msid-00 to -01 . . . . . . . . . . . . 14
C.8. Changes from mmusic-msid-01 to -02 . . . . . . . . . . . . 16 C.8. Changes from mmusic-msid-01 to -02 . . . . . . . . . . . . 14
C.9. Changes from mmusic-msid-02 to -03 . . . . . . . . . . . . 16 C.9. Changes from mmusic-msid-02 to -03 . . . . . . . . . . . . 14
C.10. Changes from mmusic-msid-03 to -04 . . . . . . . . . . . . 16 C.10. Changes from mmusic-msid-03 to -04 . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 C.11. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
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. WebRTC MediaStream Control 5. IANA Considerations
A need has been identified for signalling from a receiver to a sender
some information about the receiver's desires for the sender to take
action on a MediaStream track.
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 This document requests IANA to register the "msid" attribute and the
"msid-control" attribute in the "att-field (media level only)" "msid-control" attribute in the "att-field (media level only)"
registry within the SDP parameters registry, according to the registry within the SDP parameters 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
skipping to change at page 10, line 21 skipping to change at page 9, line 21
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.
7. 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 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.
8. 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 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.
9. References 8. References
9.1. Normative References 8.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 12, line 12 skipping to change at page 10, line 41
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>.
9.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 "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-05 (work in
progress), June 2013. 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-mmusic-unified-plan-00 (work in progress), draft-roach-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.
[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, open questions and and alternatives Appendix A. Design considerations, rejected alternatives
This appendix should be deleted before publication as an RFC. This appendix should be deleted before publication as an RFC.
One suggested mechanism has been to use CNAME instead of a new One suggested mechanism has been to use CNAME instead of a new
attribute. This was abandoned because CNAME identifies a attribute. This was abandoned because CNAME identifies a
synchronization context; one can imagine both wanting to have tracks synchronization context; one can imagine both wanting to have tracks
from the same synchronization context in multiple MediaStreams and from the same synchronization context in multiple MediaStreams and
wanting to have tracks from multiple synchronization contexts within wanting to have tracks from multiple synchronization contexts within
one MediaStream (but the latter is impossible, since a MediaStream is one MediaStream (but the latter is impossible, since a MediaStream is
defined to impose synchronization on its members). defined to impose synchronization on its members).
Another suggestion has been to put the msid value within an attribute Another suggestion has been to put the msid value within an attribute
of RTCP SR (sender report) packets. This doesn't offer the ability of RTCP SR (sender report) packets. This doesn't offer the ability
to know that you have seen all the tracks currently configured for a to know that you have seen all the tracks currently configured for a
media stream. media stream.
There has been a suggestion that this mechanism could be used to mute
tracks too. This is not done at the moment.
Discarding of incoming data when the SDP description isn't updated
yet (section 3) may cause clipping. However, the same issue exists
when crypto keys aren't available. Input sought.
There's been a suggestion that acceptable SSRCs should be signaled in
a response, giving a recipient the ability to say "no" to certain
SSRCs. This is not supported in the current version of this
document.
Appendix B. Usage with multiple MediaStreams per M-line Appendix B. Usage with multiple MediaStreams per M-line
This appendix is included to document the usage of msid as a source- This appendix is included to document the usage of msid as a source-
specific attribute. Prior to the acceptance of the Unified Plan specific attribute. Prior to the acceptance of the Unified Plan
document, some implementations used this mechanism to distinguish document, some implementations used this mechanism to distinguish
between multiple MediaStreamTracks that were carried in the same between multiple MediaStreamTracks that were carried in the same
M-line. M-line.
It reproduces some of the original justification text for this It reproduces some of the original justification text for this
mechanism that is not relevant when Unified Plan is used. mechanism that is not relevant when Unified Plan is used.
skipping to change at page 17, line 5 skipping to change at page 15, line 18
Removed some now-unnecessary text. Removed some now-unnecessary text.
C.10. Changes from mmusic-msid-03 to -04 C.10. Changes from mmusic-msid-03 to -04
Changed title to reflect focus on WebRTC MediaStreams Changed title to reflect focus on WebRTC MediaStreams
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
Removed the msid-control section after WG discussion.
Removed some text that seemed only to pertain to resolved issues.
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. 
113 lines changed or deleted 42 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/