idnits 2.17.1 draft-ietf-mmusic-msid-15.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 (July 7, 2016) is 2821 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 (-19) exists of draft-ietf-mmusic-sdp-mux-attributes-02 == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-jsep-07 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-07 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-10 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). 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 July 7, 2016 5 Expires: January 8, 2017 7 WebRTC MediaStream Identification in the Session Description Protocol 8 draft-ietf-mmusic-msid-15 10 Abstract 12 This document specifies a Session Description Protocol (SDP) Grouping 13 mechanism for RTP media streams that can be used to specify relations 14 between media streams. 16 This mechanism is used to signal the association between the SDP 17 concept of "media description" and the WebRTC concept of 18 "MediaStream" / "MediaStreamTrack" using SDP signaling. 20 This document is a work item of the MMUSIC WG, whose discussion list 21 is 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 January 8, 2017. 46 Copyright Notice 48 Copyright (c) 2016 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. Structure Of This Document . . . . . . . . . . . . . . . 3 66 1.3. Why A New Mechanism Is Needed . . . . . . . . . . . . . . 4 67 1.4. The WEBRTC MediaStream . . . . . . . . . . . . . . . . . 4 68 2. The Msid Mechanism . . . . . . . . . . . . . . . . . . . . . 5 69 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.1. Handling of non-signalled tracks . . . . . . . . . . . . 7 71 3.2. Detailed Offer/Answer Procedures . . . . . . . . . . . . 8 72 3.2.1. Generating the initial offer . . . . . . . . . . . . 8 73 3.2.2. Answerer processing of the Offer . . . . . . . . . . 9 74 3.2.3. Generating the answer . . . . . . . . . . . . . . . . 9 75 3.2.4. Offerer processing of the answer . . . . . . . . . . 9 76 3.2.5. Modifying the session . . . . . . . . . . . . . . . . 9 77 3.3. Example SDP description . . . . . . . . . . . . . . . . . 10 78 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 4.1. Attribute registration in existing registries . . . . . . 10 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 84 7.2. Informative References . . . . . . . . . . . . . . . . . 12 85 Appendix A. Design considerations, rejected alternatives . . . . 13 86 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 13 87 B.1. Changes from alvestrand-rtcweb-msid-00 to -01 . . . . . . 13 88 B.2. Changes from alvestrand-rtcweb-msid-01 to -02 . . . . . . 14 89 B.3. Changes from alvestrand-rtcweb-msid-02 to mmusic-msid-00 14 90 B.4. Changes from alvestrand-mmusic-msid-00 to -01 . . . . . . 14 91 B.5. Changes from alvestrand-mmusic-msid-01 to -02 . . . . . . 14 92 B.6. Changes from alvestrand-mmusic-msid-02 to ietf-mmusic-00 14 93 B.7. Changes from mmusic-msid-00 to -01 . . . . . . . . . . . 15 94 B.8. Changes from mmusic-msid-01 to -02 . . . . . . . . . . . 15 95 B.9. Changes from mmusic-msid-02 to -03 . . . . . . . . . . . 15 96 B.10. Changes from mmusic-msid-03 to -04 . . . . . . . . . . . 15 97 B.11. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 15 98 B.12. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 15 99 B.13. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 16 100 B.14. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 16 101 B.15. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 16 102 B.16. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 17 103 B.17. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 17 104 B.18. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 17 105 B.19. Changes from -12 to -13 . . . . . . . . . . . . . . . . . 17 106 B.20. Changes from -13 to -14 . . . . . . . . . . . . . . . . . 17 107 B.21. Changes from -14 to -15 . . . . . . . . . . . . . . . . . 17 108 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 110 1. Introduction 112 1.1. Terminology 114 This document uses terminology from [I-D.ietf-rtcweb-overview]. In 115 addition, the following terms are used as described below: 117 RTP stream Defined in [RFC7656] as a stream of RTP packets 118 containing media data. 120 MediaStream Defined in [W3C.CR-mediacapture-streams-20160519]as an 121 assembly of MediaStreamTracks. One MediaStream can contain 122 multiple MediaStreamTracks, of the same or different types. 124 MediaStreamTrack Defined in [W3C.CR-mediacapture-streams-20160519]as 125 an unidirectional flow of media data (either audio or video, but 126 not both). Corresponds to the [RFC7656] term "Source Stream". 127 One MediaStreamTrack can be present in zero, one or multiple 128 MediaStreams. 130 Media description Defined in [RFC4566] as a set of fields starting 131 with an "m=" field and terminated by eitehr the next "m=" field or 132 by the end of the session description. 134 1.2. Structure Of This Document 136 This document adds a new Session Description Protocol (SDP) [RFC4566] 137 mechanism that can attach identifiers to the RTP streams and 138 attaching identifiers to the groupings they form. It is designed for 139 use with WebRTC[I-D.ietf-rtcweb-overview] . 141 Section 1.3 gives the background on why a new mechanism is needed. 143 Section 2 gives the definition of the new mechanism. 145 Section 3 gives the necessary semantic information and procedures for 146 using the msid attribute to signal the association of 147 MediaStreamTracks to MediaStreams in support of the WebRTC API 148 [W3C.WD-webrtc-20160531]. 150 1.3. Why A New Mechanism Is Needed 152 When media is carried by RTP [RFC3550], each RTP stream is 153 distinguished inside an RTP session by its SSRC; each RTP session is 154 distinguished from all other RTP sessions by being on a different 155 transport association (strictly speaking, 2 transport associations, 156 one used for RTP and one used for RTCP, unless RTP/RTCP multiplexing 157 [RFC5761] is used). 159 SDP [RFC4566] gives a format for describing an SDP session that can 160 contain multiple media descriptions. According to the model used in 161 [I-D.ietf-rtcweb-jsep], each media description describes exactly one 162 media source, and if multiple media sources are carried in an RTP 163 session, this is signalled using BUNDLE 164 [I-D.ietf-mmusic-sdp-bundle-negotiation]; if BUNDLE is not used, each 165 media source is carried in its own RTP session. 167 The SDP grouping framework [RFC5888] can be used to group media 168 descriptions. However, for the use case of WebRTC, there is the need 169 for an application to specify some application-level information 170 about the association between the media description and the group. 171 This is not possible using the SDP grouping framework. 173 1.4. The WEBRTC MediaStream 175 The W3C WebRTC API specification [W3C.WD-webrtc-20160531] specifies 176 that communication between WebRTC entities is done via MediaStreams, 177 which contain MediaStreamTracks. A MediaStreamTrack is generally 178 carried using a single SSRC in an RTP session (forming an RTP stream. 179 The collision of terminology is unfortunate.) There might possibly 180 be additional SSRCs, possibly within additional RTP sessions, in 181 order to support functionality like forward error correction or 182 simulcast. These additional SSRCs are not affected by this 183 specification. 185 MediaStreamTracks are unidirectional; they carry media on one 186 direction only. 188 In the RTP specification, RTP streams are identified using the SSRC 189 field. Streams are grouped into RTP Sessions, and also carry a 190 CNAME. Neither CNAME nor RTP session correspond to a MediaStream. 192 Therefore, the association of an RTP stream to MediaStreams need to 193 be explicitly signaled. 195 WebRTC defines a mapping (documented in [I-D.ietf-rtcweb-jsep]) where 196 one SDP media description is used to describe each MediaStreamTrack, 197 and the BUNDLE mechanism [I-D.ietf-mmusic-sdp-bundle-negotiation] is 198 used to group MediaStreamTracks into RTP sessions. Therefore, the 199 need is to specify the ID of a MediaStreamTrack and its associated 200 MediaStream for each media description, which can be accomplished 201 with a media-level SDP attribute. 203 This usage is described in Section 3. 205 2. The Msid Mechanism 207 This document defines a new SDP [RFC4566] media-level "msid" 208 attribute. This new attribute allows endpoints to associate RTP 209 streams that are described in different media descriptions with the 210 same MediaStreams as defined in [W3C.WD-webrtc-20160531], and to 211 carry an identifier for each MediaStreamTrack in its "appdata" field. 213 The value of the "msid" attribute consists of an identifier and an 214 optional "appdata" field. 216 The name of the attribute is "msid". 218 The value of the attribute is specified by the following ABNF 219 [RFC5234] grammar: 221 msid-value = msid-id [ SP msid-appdata ] 222 msid-id = 1*64token-char ; see RFC 4566 223 msid-appdata = 1*64token-char ; see RFC 4566 225 An example msid value for a group with the identifier "examplefoo" 226 and application data "examplebar" might look like this: 228 msid:examplefoo examplebar 230 The identifier is a string of ASCII characters that are legal in a 231 "token", consisting of between 1 and 64 characters. 233 Application data (msid-appdata) is carried on the same line as the 234 identifier, separated from the identifier by a space. 236 The identifier (msid-id) uniquely identifies a group within the scope 237 of an SDP description. 239 There may be multiple msid attributes in a single media description. 240 This represents the case where a single MediaStreamTrack is present 241 in multiple MediaStreams; the value of "msid-appdata" MUST be 242 identical for all occurences. 244 Multiple media descriptions with the same value for msid-id and msid- 245 appdata are not permitted. 247 Endpoints can update the associations between RTP streams as 248 expressed by msid attributes at any time. 250 The msid attributes depend on the association of RTP streams with 251 media descriptions, but does not depend on the association of RTP 252 streams with RTP transports; therefore, its mux category (as defined 253 in [I-D.ietf-mmusic-sdp-mux-attributes]) is NORMAL - the process of 254 deciding on MSID attributes doesn't have to take into consideration 255 whether the RTP streams are bundled or not. 257 3. Procedures 259 This section describes the procedures for associating media 260 descriptions representing MediaStreamTracks within MediaStreams as 261 defined in [W3C.WD-webrtc-20160531]. 263 In the Javascript API described in that specification, each 264 MediaStream and MediaStreamTrack has an "id" attribute, which is a 265 DOMString. 267 The value of the "msid-id" field in the msid consists of the "id" 268 attribute of a MediaStream, as defined in the MediaStream's WebIDL 269 specification. 271 The value of the "msid-appdata" field in the msid consists of the 272 "id" attribute of a MediaStreamTrack, as defined in the 273 MediaStreamTrack's WebIDL specification. 275 When an SDP session description is updated, a specific "msid-id" 276 value continues to refer to the same MediaStream, and a specific 277 "msid-appdata" to the same MediaStreamTrack. There is no memory 278 apart from the currently valid SDP descriptions; if an msid 279 "identifier" value disappears from the SDP and appears in a later 280 negotiation, it will be taken to refer to a new MediaStream. 282 If the MSID attribute does not conform to the ABNF given here, it 283 SHOULD be ignored. 285 The following is a high level description of the rules for handling 286 SDP updates. Detailed procedures are in Section 3.2. 288 o When a new msid "identifier" value occurs in a session 289 description, the recipient can signal to its application that a 290 new MediaStream has been added. 292 o When a session description is updated to have media descriptions 293 with an msid "identifier" value, with one or more different 294 "appdata" values, the recipient can siggnal to its application 295 that new MediaStreamTracks have been added to the MediaStream. 296 This is done for each different msid "identifier" value. 298 o When a session description is updated to no longer list any msid 299 attribute on a specific media description, the recipient can 300 signal to its application that the corresponding MediaStreamTrack 301 has ended. 303 In addition to signaling that the track is closed when its msid 304 attribute disappears from the SDP, the track will also be signaled as 305 being closed when all associated SSRCs have disappeared by the rules 306 of [RFC3550] section 6.3.4 (BYE packet received) and 6.3.5 (timeout), 307 or when the corresponding media description is disabled by setting 308 the port number to zero. Changing the direction of the media 309 description (by setting "sendonly", "recvonly" or "inactive" 310 attributes) will not close the MediaStreamTrack. 312 The association between SSRCs and media descriptions is specified in 313 [I-D.ietf-rtcweb-jsep]. 315 3.1. Handling of non-signalled tracks 317 Entities that do not use msid will not send msid. This means that 318 there will be some incoming RTP packets that the recipient has no 319 predefined MediaStream id value for. 321 Note that this handling is triggered by incoming RTP packets, not by 322 SDP negotiation. 324 When MSID is used, the only time this can happen is when, after the 325 initial negotiation, a negotiation is performed where the answerer 326 adds a MediaStreamTrack to an already established connection and 327 starts sending data before the answer is received by the offerer. 328 For initial negotiation, packets won't flow until the ICE candidates 329 and fingerprints have been exchanged, so this is not an issue. 331 The recipient of those packets will perform the following steps: 333 o When RTP packets are initially received, it will create an 334 appropriate MediaStreamTrack based on the type of the media 335 (carried in PayloadType), and use the MID RTP header extension 337 [I-D.ietf-mmusic-sdp-bundle-negotiation] (if present) to associate 338 the RTP packets with a specific media section. 340 o If the connection is not in the RTCSignalingState "stable", it 341 will wait at this point. 343 o When the connection is in the RTCSignalingState "stable", it will 344 assign ID values. 346 The following steps are performed to assign ID values: 348 o If there is an msid attribute, it will use that attribute to 349 populate the "id" field of the MediaStreamTrack and associated 350 MediaStreams, as described above. 352 o If there is no msid attribute, the identifier of the 353 MediaStreamTrack will be set to a randomly generated string, and 354 it will be signalled as being part of a MediaStream with the 355 WebIDL "label" attribute set to "Non-WebRTC stream". 357 o After deciding on the "id" field to be applied to the 358 MediaStreamTrack, the track will be signalled to the user. 360 The process above may involve a considerable amount of buffering 361 before the stable state is entered. If the implementation wishes to 362 limit this buffering, it MUST signal to the user that media has been 363 discarded. 365 It follows from the above that MediaStreamTracks in the "default" 366 MediaStream cannot be closed by removing the msid attribute; the 367 application must instead signal these as closed when the SSRC 368 disappears according to the rules of RFC 3550 section 6.3.4 and 6.3.5 369 or by disabling the media description by setting its port to zero. 371 3.2. Detailed Offer/Answer Procedures 373 These procedures are given in terms of RFC 3264-recommended sections. 374 They describe the actions to be taken in terms of MediaStreams and 375 MediaStreamTracks; they do not include event signalling inside the 376 application, which is described in JSEP. 378 3.2.1. Generating the initial offer 380 For each media description in the offer, if there is an associated 381 outgoing MediaStreamTrack, the offerer adds one "a=msid" attribute to 382 the section for each MediaStream with which the MediaStreamTrack is 383 associated. The "identifier" field of the attribute is set to the 384 WebIDL "id" attribute of the MediaStream, and the "appdata" field is 385 set to the WebIDL "id" attribute of the MediaStreamTrack. 387 3.2.2. Answerer processing of the Offer 389 For each media description in the offer, and for each "a=msid" 390 attribute in the media description, the receiver of the offer will 391 perform the following steps: 393 o Extract the "appdata" field of the "a=msid" attribute 395 o Check if a MediaStreamTrack with the same WebIDL "id" attribute as 396 the "appdata" field already exists, and is not in the "ended" 397 state. If it is not found, create it. 399 o Extract the "identifier" field of the "a=msid" attribte. 401 o Check if a MediaStream with the same WebIDL "id" attribute already 402 exists. If not, create it. 404 o Add the MediaStreamTrack to the MediaStream 406 o Signal to the user that a new MediaStreamTrack is available. 408 3.2.3. Generating the answer 410 The answer is generated in exactly the same manner as the offer. 411 "a=msid" values in the offer do not influence the answer. 413 3.2.4. Offerer processing of the answer 415 The answer is processed in exactly the same manner as the offer. 417 3.2.5. Modifying the session 419 On subsequent exchanges, precisely the same procedure as for the 420 initial offer/answer is followed, but with one additional step in the 421 parsing of the offer and answer: 423 o For each MediaStreamTrack that has been created as a result of 424 previous offer/answer exchanges, and is not in the "ended" state, 425 check to see if there is still an "a=msid" attribute in the 426 present SDP whose "appdata" field is the same as the WebIDL "id" 427 attribute of the track. 429 o If no such attribute is found, stop the MediaStreamTrack. This 430 will set its state to "ended". 432 3.3. Example SDP description 434 The following SDP description shows the representation of a WebRTC 435 PeerConnection with two MediaStreams, each of which has one audio and 436 one video track. Only the parts relevant to the MSID are shown. 438 Line wrapping, empty lines and comments are added for clarity. They 439 are not part of the SDP. 441 # First MediaStream - id is 4701... 442 m=audio 56500 UDP/TLS/RTP/SAVPF 96 0 8 97 98 443 a=msid:47017fee-b6c1-4162-929c-a25110252400 444 f83006c5-a0ff-4e0a-9ed9-d3e6747be7d9 446 m=video 56502 UDP/TLS/RTP/SAVPF 100 101 447 a=msid:47017fee-b6c1-4162-929c-a25110252400 448 b47bdb4a-5db8-49b5-bcdc-e0c9a23172e0 450 # Second MediaStream - id is 6131.... 451 m=audio 56503 UDP/TLS/RTP/SAVPF 96 0 8 97 98 452 a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae 453 b94006c5-cade-4e0a-9ed9-d3e6747be7d9 455 m=video 56504 UDP/TLS/RTP/SAVPF 100 101 456 a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae 457 f30bdb4a-1497-49b5-3198-e0c9a23172e0 459 4. IANA Considerations 461 4.1. Attribute registration in existing registries 463 This document requests IANA to register the "msid" attribute in the 464 "att-field (media level only)" registry within the SDP parameters 465 registry, according to the procedures of [RFC4566] 467 The required information for "msid" is: 469 o Contact name, email: IETF, contacted via mmusic@ietf.org, or a 470 successor address designated by IESG 472 o Attribute name: msid 474 o Long-form attribute name: MediaStream group Identifier 475 o Subject to charset: The attribute value contains only ASCII 476 characters, and is therefore not subject to the charset attribute. 478 o Purpose: The attribute can be used to signal the relationship 479 between a WebRTC MediaStream and a set of media descriptions. 481 o Appropriate values: The details of appropriate values are given in 482 RFC XXXX. 484 o MUX category: NORMAL 486 The MUX category is defined in [I-D.ietf-mmusic-sdp-mux-attributes]. 488 5. Security Considerations 490 An adversary with the ability to modify SDP descriptions has the 491 ability to switch around tracks between MediaStreams. This is a 492 special case of the general security consideration that modification 493 of SDP descriptions needs to be confined to entities trusted by the 494 application. 496 If implementing buffering as mentioned in Section 3.1, the amount of 497 buffering should be limited to avoid memory exhaustion attacks. 499 Careless generation of identifiers can leak privacy-sensitive 500 information. [W3C.CR-mediacapture-streams-20160519] recommends that 501 identifiers are generated using UUID class 3 or 4 as a basis, which 502 avoids such leakage. 504 No other attacks have been identified that depend on this mechanism. 506 6. Acknowledgements 508 This note is based on sketches from, among others, Justin Uberti and 509 Cullen Jennings. 511 Special thanks to Flemming Andreassen, Ben Campbell, Miguel Garcia, 512 Martin Thomson, Ted Hardie, Adam Roach, Magnus Westerlund, Alissa 513 Cooper, Sue Hares and Paul Kyzivat for their work in reviewing this 514 draft, with many specific language suggestions. 516 7. References 518 7.1. Normative References 520 [I-D.ietf-mmusic-sdp-mux-attributes] 521 Nandakumar, S., "A Framework for SDP Attributes when 522 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-02 523 (work in progress), July 2014. 525 [I-D.ietf-rtcweb-jsep] 526 Uberti, J., Jennings, C., and E. Rescorla, "Javascript 527 Session Establishment Protocol", draft-ietf-rtcweb-jsep-07 528 (work in progress), July 2014. 530 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 531 Requirement Levels", BCP 14, RFC 2119, March 1997. 533 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 534 Jacobson, "RTP: A Transport Protocol for Real-Time 535 Applications", STD 64, RFC 3550, July 2003. 537 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 538 Description Protocol", RFC 4566, July 2006. 540 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 541 Specifications: ABNF", STD 68, RFC 5234, January 2008. 543 [W3C.CR-mediacapture-streams-20160519] 544 Burnett, D., Bergkvist, A., Jennings, C., Narayanan, A., 545 and B. Aboba, "Media Capture and Streams", World Wide Web 546 Consortium CR CR-mediacapture-streams-20160519, May 2016, 547 . 550 [W3C.WD-webrtc-20160531] 551 Wilson, C. and J. Kalliokoski, "WebRTC 1.0: Real-time 552 Communication Between Browsers", World Wide Web Consortium 553 WD WD-webrtc-20160531, May 2016, 554 . 556 7.2. Informative References 558 [I-D.ietf-mmusic-sdp-bundle-negotiation] 559 Holmberg, C., Alvestrand, H., and C. Jennings, 560 "Negotiating Media Multiplexing Using the Session 561 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 562 negotiation-07 (work in progress), April 2014. 564 [I-D.ietf-rtcweb-overview] 565 Alvestrand, H., "Overview: Real Time Protocols for 566 Browser-based Applications", draft-ietf-rtcweb-overview-10 567 (work in progress), June 2014. 569 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 570 Control Packets on a Single Port", RFC 5761, April 2010. 572 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 573 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 575 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 576 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 577 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 578 DOI 10.17487/RFC7656, November 2015, 579 . 581 Appendix A. Design considerations, rejected alternatives 583 One suggested mechanism has been to use CNAME instead of a new 584 attribute. This was abandoned because CNAME identifies a 585 synchronization context; one can imagine both wanting to have tracks 586 from the same synchronization context in multiple MediaStreams and 587 wanting to have tracks from multiple synchronization contexts within 588 one MediaStream (but the latter is impossible, since a MediaStream is 589 defined to impose synchronization on its members). 591 Another suggestion has been to put the msid value within an attribute 592 of RTCP SR (sender report) packets. This doesn't offer the ability 593 to know that you have seen all the tracks currently configured for a 594 MediaStream. 596 A suggestion that survived for a number of drafts was to define 597 "msid" as a generic mechanism, where the particular semantics of this 598 usage of the mechanism would be defined by an "a=wms-semantic" 599 attribute. This was removed in April 2015. 601 Appendix B. Change log 603 This appendix should be deleted before publication as an RFC. 605 B.1. Changes from alvestrand-rtcweb-msid-00 to -01 607 Added track identifier. 609 Added inclusion-by-reference of draft-lennox-mmusic-source-selection 610 for track muting. 612 Some rewording. 614 B.2. Changes from alvestrand-rtcweb-msid-01 to -02 616 Split document into sections describing a generic grouping mechanism 617 and sections describing the application of this grouping mechanism to 618 the WebRTC MediaStream concept. 620 Removed the mechanism for muting tracks, since this is not central to 621 the MSID mechanism. 623 B.3. Changes from alvestrand-rtcweb-msid-02 to mmusic-msid-00 625 Changed the draft name according to the wishes of the MMUSIC group 626 chairs. 628 Added text indicting cases where it's appropriate to have the same 629 appdata for multiple SSRCs. 631 Minor textual updates. 633 B.4. Changes from alvestrand-mmusic-msid-00 to -01 635 Increased the amount of explanatory text, much based on a review by 636 Miguel Garcia. 638 Removed references to BUNDLE, since that spec is under active 639 discussion. 641 Removed distinguished values of the MSID identifier. 643 B.5. Changes from alvestrand-mmusic-msid-01 to -02 645 Changed the order of the "msid-semantic: " attribute's value fields 646 and allowed multiple identifiers. This makes the attribute useful as 647 a marker for "I understand this semantic". 649 Changed the syntax for "identifier" and "appdata" to be "token". 651 Changed the registry for the "msid-semantic" attribute values to be a 652 new registry, based on advice given in Atlanta. 654 B.6. Changes from alvestrand-mmusic-msid-02 to ietf-mmusic-00 656 Updated terminology to refer to m-lines rather than RTP sessions when 657 discussing SDP formats and the ability of other linking mechanisms to 658 refer to SSRCs. 660 Changed the "default" mechanism to return independent streams after 661 considering the synchronization problem. 663 Removed the space from between "msid-semantic" and its value, to be 664 consistent with RFC 5576. 666 B.7. Changes from mmusic-msid-00 to -01 668 Reworked msid mechanism to be a per-m-line attribute, to align with 669 draft-roach-mmusic-unified-plan. 671 B.8. Changes from mmusic-msid-01 to -02 673 Corrected several missed cases where the word "ssrc" was not changed 674 to "M-line". 676 Added pointer to unified-plan (which should be moved to point to 677 -jsep) 679 Removed suggestion that ssrc-group attributes can be used with "msid- 680 semantic", it is now only the msid-semantic registry. 682 B.9. Changes from mmusic-msid-02 to -03 684 Corrected even more cases where the word "ssrc" was not changed to 685 "M-line". 687 Added the functionality of using an asterisk (*) in the msid-semantic 688 line, in order to remove the need for listing all msids in the msid- 689 semantic line whne only one msid-semantic is in use. 691 Removed some now-unnecessary text. 693 B.10. Changes from mmusic-msid-03 to -04 695 Changed title to reflect focus on WebRTC MediaStreams 697 Added a section on receiver-side media stream control, using the 698 "msid-control" attribute. 700 B.11. Changes from -04 to -05 702 Removed the msid-control section after WG discussion. 704 Removed some text that seemed only to pertain to resolved issues. 706 B.12. Changes from -05 to -06 708 Addressed issues found in Fleming Andreassen's review 710 Referenced JSEP rather than unified-plan for the M-line mapping model 711 Relaxed MSID definition to allow "token-char" in values rather than 712 a-z 0-9 hyphen; tightened ABNF by adding length description to it. 714 Deleted discussion of abandoned alternatives, as part of preparing 715 for publication. 717 Added a "detailed procedures" section to the WMS semantics 718 description. 720 Added IANA registration of the "msid-semantic" attribute. 722 B.13. Changes from -06 to -07 724 Changed terminology from referring to "WebRTC device" to referring to 725 "entities that implement the WMS semantic". 727 Changed names for ABNF constructions based on a proposal by Paul 728 Kyzivat. 730 Included a section on generic offer/answer semantics. 732 B.14. Changes from -07 to -08 734 Removed Appendix B that described the (now obsolete) ssrc-specific 735 usage of MSID. 737 Adopted a restructuring of the IANA section based on a suggestion 738 from Martin Thomson. 740 A number of text and ABNF clarifications based on suggestions from 741 Ted Hardie, Paul Kyzivat and Adam Roach. 743 Changed the "non-signalled track handling" to create a single stream 744 with multiple tracks again, according to discussions at TPAC in 745 November 2014 747 B.15. Changes from -08 to -09 749 Removed "wms-semantic" and all mention of multiple semantics for 750 msid, as agreed at the Dallas IETF, March 2015. 752 Addressed a number of review comments from Fleming Andresen and 753 others. 755 Changed the term "m-line" to "media description", since that is the 756 term used in RFC 4566. 758 Tried to make sure this document does not describe the API to the 759 application. 761 B.16. Changes from -09 to -10 763 Addressed review comments from Paul Kyzivat. 765 B.17. Changes from -10 to -11 767 Defined the semantics of multiple MSIDs in a media section to be a 768 MediaStreamTrack present in multiple MediaStreams. 770 Made an explicit note that MediaStreamTracks are unidirectional. 772 Disallowed the option of sending multiple media sections with the 773 same msid (id and appdata identical). 775 B.18. Changes from -11 to -12 777 Added mux-category to the IANA considerations section. 779 B.19. Changes from -12 to -13 781 Modified registration description to delete dependency on -4566-bis 783 B.20. Changes from -13 to -14 785 Addressed nits found in Gen-ART review 787 B.21. Changes from -14 to -15 789 Added the terminology section. Switched from "(RTP) media stream" to 790 "RTP stream" per RFC 7656. 792 Added a mention of random ID generation to the security 793 considerations section. 795 Moved definition pointers for MediaStream and MediaStreamTrack to the 796 "mediacapture-streams" document. 798 Added note that syntactically invalid MSID fields SHOULD be ignored. 800 Various small changes based on review feedback during IESG 801 processing. 803 Author's Address 805 Harald Alvestrand 806 Google 807 Kungsbron 2 808 Stockholm 11122 809 Sweden 811 Email: harald@alvestrand.no