idnits 2.17.1 draft-alvestrand-mmusic-msid-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 12, 2012) is 4151 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-03) exists of draft-westerlund-avtcore-multiplex-architecture-02 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Alvestrand 3 Internet-Draft Google 4 Intended status: Standards Track December 12, 2012 5 Expires: June 15, 2013 7 Cross Session Stream Identification in the Session Description Protocol 8 draft-alvestrand-mmusic-msid-02 10 Abstract 12 This document specifies a grouping mechanism for RTP media streams 13 that can be used to specify relations between media streams within 14 different RTP sessions as well as within a single RTP session. 16 This mechanism is used to signal the association between the RTP 17 concept of SSRC and the WebRTC concept of "media stream" / "media 18 stream track" using SDP signaling. 20 This document is an input document for discussion. It should be 21 discussed in the MMUSIC WG list, mmusic@ietf.org. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on June 15, 2013. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Structure Of This Document . . . . . . . . . . . . . . . . 3 65 1.2. Why A New Mechanism Is Needed . . . . . . . . . . . . . . 3 66 1.3. Application to the WEBRTC MediaStream . . . . . . . . . . 4 67 2. The Msid Mechanism . . . . . . . . . . . . . . . . . . . . . . 4 68 3. The Msid-Semantic Attribute . . . . . . . . . . . . . . . . . 5 69 4. Applying Msid to WebRTC MediaStreams . . . . . . . . . . . . . 6 70 4.1. Handling of non-signalled tracks . . . . . . . . . . . . . 7 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 77 Appendix A. Design considerations, open questions and and 78 alternatives . . . . . . . . . . . . . . . . . . . . 10 79 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 11 80 B.1. Changes from rtcweb-msid-00 to -01 . . . . . . . . . . . . 11 81 B.2. Changes from rtcweb-msid-01 to -02 . . . . . . . . . . . . 11 82 B.3. Changes from rtcweb-msid-02 to mmusic-msid-00 . . . . . . 11 83 B.4. Changes from mmusic-msid-00 to -01 . . . . . . . . . . . . 12 84 B.5. Changes from mmusic-msid-01 to -02 . . . . . . . . . . . . 12 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Introduction 89 1.1. Structure Of This Document 91 This document extends the SSRC grouping framework [RFC5888] by adding 92 a new grouping relation that can cross RTP session boundaries if 93 needed. 95 Section 1.2 gives the background on why a new mechanism is needed. 97 Section 2 gives the definition of the new mechanism. 99 Section 4 gives the application of the new mechanism for providing 100 necessary semantic information for the association of 101 MediaStreamTracks to MediaStreams in the WebRTC API . 103 1.2. Why A New Mechanism Is Needed 105 When media is carried by RTP [RFC3550], each RTP media stream is 106 distinguished inside an RTP session by its SSRC; each RTP session is 107 distinguished from all other RTP sessions by being on a different 108 transport association (strictly speaking, 2 transport associations, 109 one used for RTP and one used for RTCP, unless RTCP multiplexing 110 [RFC5761] is used). 112 There exist cases where an application using RTP and SDP needs to 113 signal some relationship between RTP media streams that may be 114 carried in either the same RTP session or different RTP sessions. 115 For instance, there may be a need to signal a relationship between a 116 video track in one RTP session and an audio track in another RTP 117 session. In traditional SDP, it is not possible to signal that these 118 two tracks should be carried in one session, so they are carried in 119 different RTP sessions. 121 The SSRC grouping mechanism ("a=ssrc-group") [RFC5576] can be used to 122 associate RTP media streams when those RTP media streams are part of 123 the same RTP session. The semantics of this mechanism prevent the 124 association of RTP media streams that are spread across different RTP 125 sessions. 127 The SDP grouping framework [RFC5888] can be used to group RTP 128 sessions. When an RTP session carries one and only one RTP media 129 stream, it is possible to associate RTP media streams across 130 different RTP sessions. However, if an RTP session has multiple RTP 131 media streams, using multiple SSRCs, the SDP grouping framework 132 cannot be used for this purpose. 134 There are use cases (some of which are discussed in 136 [I-D.westerlund-avtcore-multiplex-architecture] ) where neither of 137 these approaches is appropriate; In those cases, a new mechanism is 138 needed. 140 In addition, there is sometimes the need for an application to 141 specify some application-level information about the association 142 between the SSRC and the group. This is not possible using either of 143 the frameworks above. 145 1.3. Application to the WEBRTC MediaStream 147 The W3C WebRTC API specification [W3C.WD-webrtc-20120209] specifies 148 that communication between WebRTC entities is done via MediaStreams, 149 which contain MediaStreamTracks. A MediaStreamTrack is generally 150 carried using a single SSRC in an RTP session (forming an RTP media 151 stream. The collision of terminology is unfortunate.) There might 152 possibly be additional SSRCs, possibly within additional RTP 153 sessions, in order to support functionality like forward error 154 correction or simulcast. This complication is ignored below. 156 In the RTP specification, media streams are identified using the SSRC 157 field. Streams are grouped into RTP Sessions, and also carry a 158 CNAME. Neither CNAME nor RTP session correspond to a MediaStream. 159 Therefore, the association of an RTP media stream to MediaStreams 160 need to be explicitly signaled. 162 The marking needs to be on a per-SSRC basis, since one RTP session 163 can carry media from multiple MediaStreams, and one MediaStream can 164 have media in multiple RTP sessions. This means that the [RFC4574] 165 "label" attribute, which is used to label RTP sessions, is not usable 166 for this purpose. 168 The marking needs to also carry the unique identifier of the RTP 169 media stream as a MediaStreamTrack within the media stream; this is 170 done using a single letter to identify whether it belongs in the 171 video or audio track list, and the MediaStreamTrack's position within 172 that array. 174 This usage is described in Section 4. 176 2. The Msid Mechanism 178 This document extends the Source-Specific Media Attributes framework 179 [RFC5576] by adding a new "msid" attribute that can be used with the 180 "a=ssrc" SDP attribute. This new attribute allows endpoints to 181 associate RTP media streams that are carried in the same or different 182 RTP sessions, as well as allowing application-specific information to 183 the association. 185 The value of the "msid" attribute consists of an identifier and 186 optional application-specific data, according to the following ABNF 187 [RFC5234] grammar: 189 ; "attribute" is defined in RFC 4566. 190 ; This attribute should be used with the ssrc-attr from RFC 5576. 191 attribute =/ msid-attr 192 msid-attr = "msid:" identifier [ " " appdata ] 193 identifier = token 194 appdata = token 196 An example MSID value for the SSRC 1234 might look like this: 197 a=ssrc:1234 msid:examplefoo v1 199 The identifier is a string of ASCII characters chosen from 0-9, a-z, 200 A-Z and - (hyphen), consisting of between 1 and 64 characters. It 201 MUST be unique among the identifier values used in the same SDP 202 session. It is RECOMMENDED that is generated using a random-number 203 generator. 205 Application data is carried on the same line as the identifier, 206 separated from the identifier by a space. 208 The identifier uniquely identifies a group within the scope of an SDP 209 description. 211 There may be multiple msid attributes on a single SSRC. There may 212 also be multiple SSRCs that have the same value for identifier and 213 application data. 215 Endpoints can update the associations between SSRCs as expressed by 216 msid attributes at any time; the semantics and restrictions of such 217 grouping and ungrouping are application dependent. 219 3. The Msid-Semantic Attribute 221 In order to fully reproduce the semantics of the SDP and SSRC 222 grouping frameworks, a session-level attribute is defined for 223 signaling the semantics associated with an msid grouping. 225 This OPTIONAL attribute gives the group identifier and its group 226 semantic; it carries the same meaning as the ssrc-group-attr of RFC 227 5576 section 4.2, but uses the identifier of the group rather than a 228 list of SSRC values. 230 An empty list of identifiers is an indication that the sender 231 understands the indicated semantic, but has no msid groupings of the 232 given type in the present SDP. 234 The ABNF of msid-semantic is: 236 attribute =/ msid-semantic-attr 237 msid-semantic-attr = "msid-semantic:" " " token (" " identifier)* 238 token = 240 The semantic field may hold values from the IANA registries 241 "Semantics for the "ssrc-group" SDP Attribute" and "Semantics for the 242 "group" SDP Attribute". 244 An example msid-semantic might look like this: 245 a=msid-semantic: LS xyzzy forolow 247 This means that the SDP description has two lip sync groups, with the 248 group identifiers xyzzy and forolow, respectively. 250 4. Applying Msid to WebRTC MediaStreams 252 This section creates a new semantic for use with the framework 253 defined in Section 2, to be used for associating SSRCs representing 254 MediaStreamTracks within MediaStreams as defined in 255 [W3C.WD-webrtc-20120209]. 257 The semantic token for this semantic is "WMS" (short for WebRTC Media 258 Stream). 260 The value of the msid corresponds to the "id" attribute of a 261 MediaStream. 263 In a WebRTC-compatible SDP description, all SSRCs intending to be 264 sent from one peer will be identified in the SDP generated by that 265 entity. 267 The appdata for a WebRTC MediaStreamTrack consists of the "id" 268 attribute of a MediaStreamTrack. 270 If two different SSRCs have the same value for identifier and 271 appdata, it means that these two SSRCs are both intended for the same 272 MediaStreamTrack. This may occur if the sender wishes to use 273 simulcast or forward error correction, or if the sender intends to 274 switch between multiple codecs on the same MediaStreamTrack. 276 When an SDP description is updated, a specific msid continues to 277 refer to the same MediaStream. Once negotiation has completed on a 278 session, there is no memory; an msid value that appears in a later 279 negotiation will be taken to refer to a new MediaStream. 281 The following are the rules for handling updates of the list of SSRCs 282 and their msid values. 284 o When a new msid value occurs in the description, the recipient can 285 signal to its application that a new MediaStream has been added. 287 o When a description is updated to have more SSRCs with the same 288 msid value, but different appdata values, the recipient can signal 289 to its application that new media stream tracks have been added to 290 the media stream. 292 o When a description is updated to no longer list the msid value on 293 a specific ssrc, the recipient can signal to its application that 294 the corresponding media stream track has been closed. 296 o When a description is updated to no longer list the msid value on 297 any ssrc, the recipient can signal to its application that the 298 media stream has been closed. 300 In addition to signaling that the track is closed when it disappears 301 from the SDP, the track will also be signaled as being closed when 302 the SSRC disappears by the rules of [RFC3550] section 6.3.4 (BYE 303 packet received) and 6.3.5 (timeout). 305 4.1. Handling of non-signalled tracks 307 Pre-WebRTC entities will not send msid. This means that there will 308 be some incoming RTP packets with SSRCs where the recipient does not 309 know about a corresponding MediaStream id. 311 Handling will depend on whether or not any SSRCs are signaled in the 312 relevant RTP session. There are two cases: 314 o No SSRC is signaled with an msid attribute. The SDP session is 315 assumed to be a backwards-compatible session. All incoming SSRCs, 316 on all RTP sessions that are part of the SDP session, are assumed 317 to belong to a single media stream. The identifier of this media 318 stream is "default". 320 o Some SSRCs are signaled with an msid attribute. In this case, the 321 session is WebRTC compatible, and the newly arrived SSRCs are 322 either caused by a bug or by timing skew between the arrival of 323 the media packets and the SDP description. These packets MAY be 324 discarded, or they MAY be buffered for a while in order to allow 325 immediate startup of the media stream when the SDP description is 326 updated. The arrival of media packets MUST NOT cause a new 327 MediaStreamTrack to be signaled. 329 If a WebRTC entity sends a description, it MUST include the msid- 330 semantic: WMS attribute, even if no media streams are sent. This 331 allows us to distinguish between the case of no media streams at the 332 moment and the case of legacy SDP generation. 334 It follows from the above that media stream tracks in the "default" 335 media stream cannot be closed by signaling; the application must 336 instead signal these as closed when the SSRC disappears according to 337 the rules of RFC 3550 section 6.3.4 and 6.3.5. 339 5. IANA Considerations 341 This document requests IANA to register the "msid" attribute in the 342 "att-field (source level)" registry within the SDP parameters 343 registry, according to the procedures of [RFC5576] 345 The required information is: 347 o Contact name, email: IETF, contacted via rtcweb@ietf.org, or a 348 successor address designated by IESG 350 o Attribute name: msid 352 o Long-form attribute name: Media stream group Identifier 354 o The attribute value contains only ASCII characters, and is 355 therefore not subject to the charset attribute. 357 o The attribute gives an association over a set of SSRCs, 358 potentially in different RTP sessions. It can be used to signal 359 the relationship between a WebRTC MediaStream and a set of SSRCs. 361 o The details of appropriate values are given in RFC XXXX. 363 This document requests IANA to create a new registry called 364 "Semantics for the msid-semantic SDP attribute", which should have 365 exactly the same rules as for the "Semantics for the ssrc-group SDP 366 attribute" registry, and to register the "WMS" semantic within this 367 new registry. 369 The required information is: 371 o Description: WebRTC Media Stream, as given in RFC XXXX. 373 o Token: WMS 375 o Standards track reference: RFC XXXX 377 IANA is requested to replace "RFC XXXX" with the RFC number of this 378 document upon publication. 380 6. Security Considerations 382 An adversary with the ability to modify SDP descriptions has the 383 ability to switch around tracks between media streams. This is a 384 special case of the general security consideration that modification 385 of SDP descriptions needs to be confined to entities trusted by the 386 application. 388 No attacks that are relevant to the browser's security have been 389 identified that depend on this mechanism. 391 7. Acknowledgements 393 This note is based on sketches from, among others, Justin Uberti and 394 Cullen Jennings. 396 Special thanks to Miguel Garcia and Paul Kyzivat for their work in 397 reviewing this draft, with many specific language suggestions. 399 8. References 401 8.1. Normative References 403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 404 Requirement Levels", BCP 14, RFC 2119, March 1997. 406 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 407 Jacobson, "RTP: A Transport Protocol for Real-Time 408 Applications", STD 64, RFC 3550, July 2003. 410 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 411 Specifications: ABNF", STD 68, RFC 5234, January 2008. 413 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 414 Media Attributes in the Session Description Protocol 415 (SDP)", RFC 5576, June 2009. 417 [W3C.WD-webrtc-20120209] 418 Bergkvist, A., Burnett, D., Narayanan, A., and C. 419 Jennings, "WebRTC 1.0: Real-time Communication Between 420 Browsers", World Wide Web Consortium WD WD-webrtc- 421 20120209, February 2012, 422 . 424 8.2. Informative References 426 [I-D.westerlund-avtcore-multiplex-architecture] 427 Westerlund, M., Burman, B., Perkins, C., and H. 428 Alvestrand, "Guidelines for using the Multiplexing 429 Features of RTP", 430 draft-westerlund-avtcore-multiplex-architecture-02 (work 431 in progress), July 2012. 433 [RFC4574] Levin, O. and G. Camarillo, "The Session Description 434 Protocol (SDP) Label Attribute", RFC 4574, August 2006. 436 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 437 Control Packets on a Single Port", RFC 5761, April 2010. 439 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 440 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 442 Appendix A. Design considerations, open questions and and alternatives 444 This appendix should be deleted before publication as an RFC. 446 One suggested mechanism has been to use CNAME instead of a new 447 attribute. This was abandoned because CNAME identifies a 448 synchronization context; one can imagine both wanting to have tracks 449 from the same synchronization context in multiple media streams and 450 wanting to have tracks from multiple synchronization contexts within 451 one media stream. 453 Another suggestion has been to put the msid value within an attribute 454 of RTCP SR (sender report) packets. This doesn't offer the ability 455 to know that you have seen all the tracks currently configured for a 456 media stream. 458 There has been a suggestion that this mechanism could be used to mute 459 tracks too. This is not done at the moment. 461 An alternative to the "default" media stream is to let each new media 462 stream track without a msid attribute create its own media stream. 463 Input on this question is sought. 465 Discarding of incoming data when the SDP description isn't updated 466 yet (section 3) may cause clipping. However, the same issue exists 467 when crypto keys aren't available. Input sought. 469 There's been a suggestion that acceptable SSRCs should be signaled in 470 a response, giving a recipient the ability to say "no" to certain 471 SSRCs. This is not supported in the current version of this 472 document. 474 Appendix B. Change log 476 This appendix should be deleted before publication as an RFC. 478 B.1. Changes from rtcweb-msid-00 to -01 480 Added track identifier. 482 Added inclusion-by-reference of draft-lennox-mmusic-source-selection 483 for track muting. 485 Some rewording. 487 B.2. Changes from rtcweb-msid-01 to -02 489 Split document into sections describing a generic grouping mechanism 490 and sections describing the application of this grouping mechanism to 491 the WebRTC MediaStream concept. 493 Removed the mechanism for muting tracks, since this is not central to 494 the MSID mechanism. 496 B.3. Changes from rtcweb-msid-02 to mmusic-msid-00 498 Changed the draft name according to the wishes of the MMUSIC group 499 chairs. 501 Added text indicting cases where it's appropriate to have the same 502 appdata for multiple SSRCs. 504 Minor textual updates. 506 B.4. Changes from mmusic-msid-00 to -01 508 Increased the amount of explanatory text, much based on a review by 509 Miguel Garcia. 511 Removed references to BUNDLE, since that spec is under active 512 discussion. 514 Removed distinguished values of the MSID identifier. 516 B.5. Changes from mmusic-msid-01 to -02 518 Changed the order of the "msid-semantic: " attribute's value fields 519 and allowed multiple identifiers. This makes the attribute useful as 520 a marker for "I understand this semantic". 522 Changed the syntax for "identifier" and "appdata" to be "token". 524 Changed the registry for the "msid-semantic" attribute values to be a 525 new registry, based on advice given in Atlanta. 527 Author's Address 529 Harald Alvestrand 530 Google 531 Kungsbron 2 532 Stockholm, 11122 533 Sweden 535 Email: harald@alvestrand.no