idnits 2.17.1 draft-ietf-mmusic-msid-14.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 (June 6, 2016) is 2881 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-12 == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-jsep-14 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-29 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-15 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 June 6, 2016 5 Expires: December 8, 2016 7 WebRTC MediaStream Identification in the Session Description Protocol 8 draft-ietf-mmusic-msid-14 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 December 8, 2016. 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. Structure Of This Document . . . . . . . . . . . . . . . 3 65 1.2. Why A New Mechanism Is Needed . . . . . . . . . . . . . . 3 66 1.3. The WEBRTC MediaStream . . . . . . . . . . . . . . . . . 4 67 2. The Msid Mechanism . . . . . . . . . . . . . . . . . . . . . 4 68 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Handling of non-signalled tracks . . . . . . . . . . . . 7 70 3.2. Detailed Offer/Answer Procedures . . . . . . . . . . . . 8 71 3.2.1. Generating the initial offer . . . . . . . . . . . . 8 72 3.2.2. Answerer processing of the Offer . . . . . . . . . . 8 73 3.2.3. Generating the answer . . . . . . . . . . . . . . . . 8 74 3.2.4. Offerer processing of the answer . . . . . . . . . . 9 75 3.2.5. Modifying the session . . . . . . . . . . . . . . . . 9 76 3.3. Example SDP description . . . . . . . . . . . . . . . . . 9 77 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 4.1. Attribute registration in existing registries . . . . . . 10 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 80 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 83 7.2. Informative References . . . . . . . . . . . . . . . . . 12 84 Appendix A. Design considerations, rejected alternatives . . . . 12 85 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 12 86 B.1. Changes from alvestrand-rtcweb-msid-00 to -01 . . . . . . 13 87 B.2. Changes from alvestrand-rtcweb-msid-01 to -02 . . . . . . 13 88 B.3. Changes from alvestrand-rtcweb-msid-02 to mmusic-msid-00 13 89 B.4. Changes from alvestrand-mmusic-msid-00 to -01 . . . . . . 13 90 B.5. Changes from alvestrand-mmusic-msid-01 to -02 . . . . . . 13 91 B.6. Changes from alvestrand-mmusic-msid-02 to ietf-mmusic-00 14 92 B.7. Changes from mmusic-msid-00 to -01 . . . . . . . . . . . 14 93 B.8. Changes from mmusic-msid-01 to -02 . . . . . . . . . . . 14 94 B.9. Changes from mmusic-msid-02 to -03 . . . . . . . . . . . 14 95 B.10. Changes from mmusic-msid-03 to -04 . . . . . . . . . . . 14 96 B.11. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 15 97 B.12. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 15 98 B.13. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 15 99 B.14. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 15 100 B.15. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 16 101 B.16. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 16 102 B.17. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 16 103 B.18. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 16 104 B.19. Changes from -12 to -13 . . . . . . . . . . . . . . . . . 16 105 B.20. Changes from -13 to -14 . . . . . . . . . . . . . . . . . 16 106 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 108 1. Introduction 110 1.1. Structure Of This Document 112 This document adds a new Session Description Protocol (SDP) [RFC4566] 113 mechanism that can associate application layer identifiers with the 114 binding between media streams, attaching identifiers to the media 115 streams and attaching identifiers to the groupings they form. It is 116 designed for use with WebRTC[I-D.ietf-rtcweb-overview] . 118 Section 1.2 gives the background on why a new mechanism is needed. 120 Section 2 gives the definition of the new mechanism. 122 Section 3 gives the necessary semantic information and procedures for 123 using the msid attribute to signal the association of 124 MediaStreamTracks to MediaStreams in support of the WebRTC API 125 [W3C.WD-webrtc-20160531]. 127 1.2. Why A New Mechanism Is Needed 129 When media is carried by RTP [RFC3550], each RTP media stream is 130 distinguished inside an RTP session by its SSRC; each RTP session is 131 distinguished from all other RTP sessions by being on a different 132 transport association (strictly speaking, 2 transport associations, 133 one used for RTP and one used for RTCP, unless RTP/RTCP multiplexing 134 [RFC5761] is used). 136 SDP gives a description based on media descriptions. According to 137 the model used in [I-D.ietf-rtcweb-jsep], each media description 138 describes exactly one media source, and if mulitple media sources are 139 carried in an RTP session, this is signalled using BUNDLE 140 [I-D.ietf-mmusic-sdp-bundle-negotiation]; if BUNDLE is not used, each 141 media source is carried in its own RTP session. 143 The SDP grouping framework [RFC5888] can be used to group media 144 descriptions. However, for the use case of WebRTC, there is the need 145 for an application to specify some application-level information 146 about the association between the media description and the group. 147 This is not possible using the SDP grouping framework. 149 1.3. The WEBRTC MediaStream 151 The W3C WebRTC API specification [W3C.WD-webrtc-20160531] specifies 152 that communication between WebRTC entities is done via MediaStreams, 153 which contain MediaStreamTracks. A MediaStreamTrack is generally 154 carried using a single SSRC in an RTP session (forming an RTP media 155 stream. The collision of terminology is unfortunate.) There might 156 possibly be additional SSRCs, possibly within additional RTP 157 sessions, in order to support functionality like forward error 158 correction or simulcast. This complication is ignored below. 160 MediaStreamTracks are unidirectional; they carry media on one 161 direction only. 163 In the RTP specification, media streams are identified using the SSRC 164 field. Streams are grouped into RTP Sessions, and also carry a 165 CNAME. Neither CNAME nor RTP session correspond to a MediaStream. 166 Therefore, the association of an RTP media stream to MediaStreams 167 need to be explicitly signaled. 169 WebRTC defines a mapping (documented in [I-D.ietf-rtcweb-jsep]) where 170 one SDP media description is used to describe each MediaStreamTrack, 171 and the BUNDLE mechanism [I-D.ietf-mmusic-sdp-bundle-negotiation] is 172 used to group MediaStreamTracks into RTP sessions. Therefore, the 173 need is to specify the ID of a MediaStreamTrack and its associated 174 MediaStream for each media description, which can be accomplished 175 with a media-level SDP attribute. 177 This usage is described in Section 3. 179 2. The Msid Mechanism 181 This document defines a new SDP [RFC4566] media-level "msid" 182 attribute. This new attribute allows endpoints to associate RTP 183 media streams that are described in different media descriptions with 184 the same MediaStreams as defined in [W3C.WD-webrtc-20160531], and to 185 carry an identifier for each MediaStreamTrack in its "appdata" field. 187 The value of the "msid" attribute consists of an identifier and an 188 optional "appdata" field. 190 The name of the attribute is "msid". 192 The value of the attribute is specified by the following ABNF 193 [RFC5234] grammar: 195 msid-value = msid-id [ SP msid-appdata ] 196 msid-id = 1*64token-char ; see RFC 4566 197 msid-appdata = 1*64token-char ; see RFC 4566 199 An example msid value for a group with the identifier "examplefoo" 200 and application data "examplebar" might look like this: 202 msid:examplefoo examplebar 204 The identifier is a string of ASCII characters that are legal in a 205 "token", consisting of between 1 and 64 characters. 207 Application data (msid-appdata) is carried on the same line as the 208 identifier, separated from the identifier by a space. 210 The identifier (msid-id) uniquely identifies a group within the scope 211 of an SDP description. 213 There may be multiple msid attributes in a single media description. 214 This represents the case where a single MediaStreamTrack is present 215 in multiple MediaStreams; the value of "msid-appdata" MUST be 216 identical for all occurences. 218 Multiple media descriptions with the same value for msid-id and msid- 219 appdata is not permitted. 221 Endpoints can update the associations between RTP media streams as 222 expressed by msid attributes at any time. 224 The msid attributes depend on the association of RTP media streams 225 with media descriptions, but does not depend on the association of 226 RTP media streams with RTP transports; therefore, its mux category is 227 NORMAL - the process of deciding on MSID attributes doesn't have to 228 take into consideration whether the media streams are bundled or not. 230 3. Procedures 232 This section describes the procedures for associating media 233 descriptions representing MediaStreamTracks within MediaStreams as 234 defined in [W3C.WD-webrtc-20160531]. 236 In the Javascript API, each MediaStream and MediaStreamTrack has an 237 "id" attribute, which is a DOMString. 239 The value of the "msid-id" field in the msid consists of the "id" 240 attribute of a MediaStream, as defined in its WebIDL specification. 242 The value of the "msid-appdata" field in the msid consists of the 243 "id" attribute of a MediaStreamTrack, as defined in its WebIDL 244 specification. 246 When an SDP session description is updated, a specific "msid-id" 247 continues to refer to the same MediaStream, and a specific "msid- 248 appdata" to the same MediaStreamTrack. There is no memory apart from 249 the currently valid SDP descriptions; if an msid "identifier" value 250 disappears from the SDP and appears in a later negotiation, it will 251 be taken to refer to a new MediaStream. 253 The following is a high level description of the rules for handling 254 SDP updates. Detailed procedures are in Section 3.2. 256 o When a new msid "identifier" value occurs in a session 257 description, the recipient can signal to its application that a 258 new MediaStream has been added. 260 o When a session description is updated to have media descriptions 261 with an msid "identifier" value, with one or more different 262 "appdata" values, the recipient can si2gnal to its application 263 that new MediaStreamTracks have been added to the MediaStream. 264 This is done for each different msid "identifier" value. 266 o When a session description is updated to no longer list any msid 267 attribute on a specific media description, the recipient can 268 signal to its application that the corresponding MediaStreamTrack 269 has ended. 271 In addition to signaling that the track is closed when its msid 272 attribute disappears from the SDP, the track will also be signaled as 273 being closed when all associated SSRCs have disappeared by the rules 274 of [RFC3550] section 6.3.4 (BYE packet received) and 6.3.5 (timeout), 275 and when the corresponding media description is disabled by setting 276 the port number to zero. Changing the direction of the media 277 description (by setting "sendonly", "recvonly" or "inactive" 278 attributes) will not close the MediaStreamTrack. 280 The association between SSRCs and media descriptions is specified in 281 [I-D.ietf-rtcweb-jsep]. 283 3.1. Handling of non-signalled tracks 285 Entities that do not use msid will not send msid. This means that 286 there will be some incoming RTP packets that the recipient has no 287 predefined MediaStream id value for. 289 Note that this handling is triggered by incoming RTP packets, not by 290 SDP negotiation. 292 When MSID is used, the only time this can happen is when, after the 293 initial negotiation, a negotiation is performed where the answerer 294 adds a MediaStreamTrack to an already established connection and 295 starts sending data before the answer is received by the offerer. 296 For initial negotiation, packets won't flow until the ICE candidates 297 and fingerprints have been exchanged, so this is not an issue. 299 The recipient of those packets will perform the following steps: 301 o When RTP packets are initially received, it will create an 302 appropriate MediaStreamTrack based on the type of the media 303 (carried in PayloadType), and use the MID RTP header extension 304 [I-D.ietf-mmusic-sdp-bundle-negotiation] (if present) to associate 305 the RTP packets with a specific media section. If the connection 306 is not in the RTCSignalingState "stable", it will wait at this 307 point. 309 o When the connection is in the RTCSignalingState "stable", it will 310 look at the relevant media section to find the msid attribute. 312 o If there is an msid attribute, it will use that attribute to 313 populate the "id" field of the MediaStreamTrack and associated 314 MediaStreams, as described above. 316 o If there is no msid attribute, the identifier of the 317 MediaStreamTrack will be set to a randomly generated string, and 318 it will be signalled as being part of a MediaStream with the 319 WebIDL "label" attribute set to "Non-WebRTC stream". 321 o After deciding on the "id" field to be applied to the 322 MediaStreamTrack, the track will be signalled to the user. 324 The process above may involve a considerable amount of buffering 325 before the stable state is entered. If the implementation wishes to 326 limit this buffering, it MUST signal to the user that media has been 327 discarded. 329 It follows from the above that media stream tracks in the "default" 330 media stream cannot be closed by removing the msid attribute; the 331 application must instead signal these as closed when the SSRC 332 disappears according to the rules of RFC 3550 section 6.3.4 and 6.3.5 333 or by disabling the media description by setting its port to zero. 335 3.2. Detailed Offer/Answer Procedures 337 These procedures are given in terms of RFC 3264-recommended sections. 338 They describe the actions to be taken in terms of MediaStreams and 339 MediaStreamTracks; they do not include event signalling inside the 340 application, which is described in JSEP. 342 3.2.1. Generating the initial offer 344 For each media description in the offer, if there is an associated 345 outgoing MediaStreamTrack, the offerer adds one "a=msid" attribute to 346 the section for each MediaStream with which the MediaStreamTrack is 347 associated. The "identifier" field of the attribute is set to the 348 WebIDL "id" attribute of the MediaStream, and the "appdata" field is 349 set to the WebIDL "id" attribute of the MediaStreamTrack. 351 3.2.2. Answerer processing of the Offer 353 For each media description in the offer, and for each "a=msid" 354 attribute in the media description, the receiver of the offer will 355 perform the following steps: 357 o Extract the "appdata" field of the "a=msid" attribute 359 o Check if a MediaStreamTrack with the same WebIDL "id" attribute as 360 the "appdata" field already exists, and is not in the "ended" 361 state. If it is not found, create it. 363 o Extract the "identifier" field of the "a=msid" attribte. 365 o Check if a MediaStream with the same WebIDL "id" attribute already 366 exists. If not, create it. 368 o Add the MediaStreamTrack to the MediaStream 370 o Signal to the user that a new MediaStreamTrack is available. 372 3.2.3. Generating the answer 374 The answer is generated in exactly the same manner as the offer. 375 "a=msid" values in the offer do not influence the answer. 377 3.2.4. Offerer processing of the answer 379 The answer is processed in exactly the same manner as the offer. 381 3.2.5. Modifying the session 383 On subsequent exchanges, precisely the same procedure as for the 384 initial offer/answer is followed, but with one additional step in the 385 parsing of the offer and answer: 387 o For each MediaStreamTrack that has been created as a result of 388 previous offer/answer exchanges, and is not in the "ended" state, 389 check to see if there is still an "a=msid" attribute in the 390 present SDP whose "appdata" field is the same as the WebIDL "id" 391 attribute of the track. 393 o If no such attribute is found, stop the MediaStreamTrack. This 394 will set its state to "ended". 396 3.3. Example SDP description 398 The following SDP description shows the representation of a WebRTC 399 PeerConnection with two MediaStreams, each of which has one audio and 400 one video track. Only the parts relevant to the MSID are shown. 402 Line wrapping, empty lines and comments are added for clarity. They 403 are not part of the SDP. 405 # First MediaStream - id is 4701... 406 m=audio 56500 UDP/TLS/RTP/SAVPF 96 0 8 97 98 407 a=msid:47017fee-b6c1-4162-929c-a25110252400 408 f83006c5-a0ff-4e0a-9ed9-d3e6747be7d9 410 m=video 56502 UDP/TLS/RTP/SAVPF 100 101 411 a=msid:47017fee-b6c1-4162-929c-a25110252400 412 b47bdb4a-5db8-49b5-bcdc-e0c9a23172e0 414 # Second MediaStream - id is 6131.... 415 m=audio 56503 UDP/TLS/RTP/SAVPF 96 0 8 97 98 416 a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae 417 b94006c5-cade-4e0a-9ed9-d3e6747be7d9 419 m=video 56504 UDP/TLS/RTP/SAVPF 100 101 420 a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae 421 f30bdb4a-1497-49b5-3198-e0c9a23172e0 423 4. IANA Considerations 425 4.1. Attribute registration in existing registries 427 This document requests IANA to register the "msid" attribute in the 428 "att-field (media level only)" registry within the SDP parameters 429 registry, according to the procedures of [RFC4566] 431 The required information for "msid" is: 433 o Contact name, email: IETF, contacted via mmusic@ietf.org, or a 434 successor address designated by IESG 436 o Attribute name: msid 438 o Long-form attribute name: Media stream group Identifier 440 o Subject to charset: The attribute value contains only ASCII 441 characters, and is therefore not subject to the charset attribute. 443 o Purpose: The attribute can be used to signal the relationship 444 between a WebRTC MediaStream and a set of media descriptions. 446 o Appropriate values: The details of appropriate values are given in 447 RFC XXXX. 449 o MUX category: NORMAL 451 The MUX category is defined in [I-D.ietf-mmusic-sdp-mux-attributes]. 453 5. Security Considerations 455 An adversary with the ability to modify SDP descriptions has the 456 ability to switch around tracks between media streams. This is a 457 special case of the general security consideration that modification 458 of SDP descriptions needs to be confined to entities trusted by the 459 application. 461 If implementing buffering as mentioned in Section 3.1, the amount of 462 buffering should be limited to avoid memory exhaustion attacks. 464 No other attacks have been identified that depend on this mechanism. 466 6. Acknowledgements 468 This note is based on sketches from, among others, Justin Uberti and 469 Cullen Jennings. 471 Special thanks to Flemming Andreassen, Miguel Garcia, Martin Thomson, 472 Ted Hardie, Adam Roach, Magnus Westerlund and Paul Kyzivat for their 473 work in reviewing this draft, with many specific language 474 suggestions. 476 7. References 478 7.1. Normative References 480 [I-D.ietf-mmusic-sdp-mux-attributes] 481 Nandakumar, S., "A Framework for SDP Attributes when 482 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12 483 (work in progress), January 2016. 485 [I-D.ietf-rtcweb-jsep] 486 Uberti, J., Jennings, C., and E. Rescorla, "Javascript 487 Session Establishment Protocol", draft-ietf-rtcweb-jsep-14 488 (work in progress), March 2016. 490 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 491 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 492 RFC2119, March 1997, 493 . 495 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 496 Jacobson, "RTP: A Transport Protocol for Real-Time 497 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 498 July 2003, . 500 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 501 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 502 July 2006, . 504 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 505 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 506 RFC5234, January 2008, 507 . 509 [W3C.WD-webrtc-20160531] 510 Wilson, C. and J. Kalliokoski, "WebRTC 1.0: Real-time 511 Communication Between Browsers", World Wide Web Consortium 512 WD WD-webrtc-20160531, May 2016, 513 . 515 7.2. Informative References 517 [I-D.ietf-mmusic-sdp-bundle-negotiation] 518 Holmberg, C., Alvestrand, H., and C. Jennings, 519 "Negotiating Media Multiplexing Using the Session 520 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 521 negotiation-29 (work in progress), April 2016. 523 [I-D.ietf-rtcweb-overview] 524 Alvestrand, H., "Overview: Real Time Protocols for 525 Browser-based Applications", draft-ietf-rtcweb-overview-15 526 (work in progress), January 2016. 528 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 529 Control Packets on a Single Port", RFC 5761, DOI 10.17487/ 530 RFC5761, April 2010, 531 . 533 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 534 Protocol (SDP) Grouping Framework", RFC 5888, DOI 535 10.17487/RFC5888, June 2010, 536 . 538 Appendix A. Design considerations, rejected alternatives 540 One suggested mechanism has been to use CNAME instead of a new 541 attribute. This was abandoned because CNAME identifies a 542 synchronization context; one can imagine both wanting to have tracks 543 from the same synchronization context in multiple MediaStreams and 544 wanting to have tracks from multiple synchronization contexts within 545 one MediaStream (but the latter is impossible, since a MediaStream is 546 defined to impose synchronization on its members). 548 Another suggestion has been to put the msid value within an attribute 549 of RTCP SR (sender report) packets. This doesn't offer the ability 550 to know that you have seen all the tracks currently configured for a 551 media stream. 553 A suggestion that survived for a number of drafts was to define 554 "msid" as a generic mechanism, where the particular semantics of this 555 usage of the mechanism would be defined by an "a=wms-semantic" 556 attribute. This was removed in April 2015. 558 Appendix B. Change log 560 This appendix should be deleted before publication as an RFC. 562 B.1. Changes from alvestrand-rtcweb-msid-00 to -01 564 Added track identifier. 566 Added inclusion-by-reference of draft-lennox-mmusic-source-selection 567 for track muting. 569 Some rewording. 571 B.2. Changes from alvestrand-rtcweb-msid-01 to -02 573 Split document into sections describing a generic grouping mechanism 574 and sections describing the application of this grouping mechanism to 575 the WebRTC MediaStream concept. 577 Removed the mechanism for muting tracks, since this is not central to 578 the MSID mechanism. 580 B.3. Changes from alvestrand-rtcweb-msid-02 to mmusic-msid-00 582 Changed the draft name according to the wishes of the MMUSIC group 583 chairs. 585 Added text indicting cases where it's appropriate to have the same 586 appdata for multiple SSRCs. 588 Minor textual updates. 590 B.4. Changes from alvestrand-mmusic-msid-00 to -01 592 Increased the amount of explanatory text, much based on a review by 593 Miguel Garcia. 595 Removed references to BUNDLE, since that spec is under active 596 discussion. 598 Removed distinguished values of the MSID identifier. 600 B.5. Changes from alvestrand-mmusic-msid-01 to -02 602 Changed the order of the "msid-semantic: " attribute's value fields 603 and allowed multiple identifiers. This makes the attribute useful as 604 a marker for "I understand this semantic". 606 Changed the syntax for "identifier" and "appdata" to be "token". 608 Changed the registry for the "msid-semantic" attribute values to be a 609 new registry, based on advice given in Atlanta. 611 B.6. Changes from alvestrand-mmusic-msid-02 to ietf-mmusic-00 613 Updated terminology to refer to m-lines rather than RTP sessions when 614 discussing SDP formats and the ability of other linking mechanisms to 615 refer to SSRCs. 617 Changed the "default" mechanism to return independent streams after 618 considering the synchronization problem. 620 Removed the space from between "msid-semantic" and its value, to be 621 consistent with RFC 5576. 623 B.7. Changes from mmusic-msid-00 to -01 625 Reworked msid mechanism to be a per-m-line attribute, to align with 626 draft-roach-mmusic-unified-plan. 628 B.8. Changes from mmusic-msid-01 to -02 630 Corrected several missed cases where the word "ssrc" was not changed 631 to "M-line". 633 Added pointer to unified-plan (which should be moved to point to 634 -jsep) 636 Removed suggestion that ssrc-group attributes can be used with "msid- 637 semantic", it is now only the msid-semantic registry. 639 B.9. Changes from mmusic-msid-02 to -03 641 Corrected even more cases where the word "ssrc" was not changed to 642 "M-line". 644 Added the functionality of using an asterisk (*) in the msid-semantic 645 line, in order to remove the need for listing all msids in the msid- 646 semantic line whne only one msid-semantic is in use. 648 Removed some now-unnecessary text. 650 B.10. Changes from mmusic-msid-03 to -04 652 Changed title to reflect focus on WebRTC MediaStreams 654 Added a section on receiver-side media stream control, using the 655 "msid-control" attribute. 657 B.11. Changes from -04 to -05 659 Removed the msid-control section after WG discussion. 661 Removed some text that seemed only to pertain to resolved issues. 663 B.12. Changes from -05 to -06 665 Addressed issues found in Fleming Andreassen's review 667 Referenced JSEP rather than unified-plan for the M-line mapping model 669 Relaxed MSID definition to allow "token-char" in values rather than 670 a-z 0-9 hyphen; tightened ABNF by adding length description to it. 672 Deleted discussion of abandoned alternatives, as part of preparing 673 for publication. 675 Added a "detailed procedures" section to the WMS semantics 676 description. 678 Added IANA registration of the "msid-semantic" attribute. 680 B.13. Changes from -06 to -07 682 Changed terminology from referring to "WebRTC device" to referring to 683 "entities that implement the WMS semantic". 685 Changed names for ABNF constructions based on a proposal by Paul 686 Kyzivat. 688 Included a section on generic offer/answer semantics. 690 B.14. Changes from -07 to -08 692 Removed Appendix B that described the (now obsolete) ssrc-specific 693 usage of MSID. 695 Adopted a restructuring of the IANA section based on a suggestion 696 from Martin Thomson. 698 A number of text and ABNF clarifications based on suggestions from 699 Ted Hardie, Paul Kyzivat and Adam Roach. 701 Changed the "non-signalled track handling" to create a single stream 702 with multiple tracks again, according to discussions at TPAC in 703 November 2014 705 B.15. Changes from -08 to -09 707 Removed "wms-semantic" and all mention of multiple semantics for 708 msid, as agreed at the Dallas IETF, March 2015. 710 Addressed a number of review comments from Fleming Andresen and 711 others. 713 Changed the term "m-line" to "media description", since that is the 714 term used in RFC 4566. 716 Tried to make sure this document does not describe the API to the 717 application. 719 B.16. Changes from -09 to -10 721 Addressed review comments from Paul Kyzivat. 723 B.17. Changes from -10 to -11 725 Defined the semantics of multiple MSIDs in a media section to be a 726 MediaStreamTrack present in multiple MediaStreams. 728 Made an explicit note that MediaStreamTracks are unidirectional. 730 Disallowed the option of sending multiple media sections with the 731 same msid (id and appdata identical). 733 B.18. Changes from -11 to -12 735 Added mux-category to the IANA considerations section. 737 B.19. Changes from -12 to -13 739 Modified registration description to delete dependency on -4566-bis 741 B.20. Changes from -13 to -14 743 Addressed nits found in Gen-ART review 745 Author's Address 746 Harald Alvestrand 747 Google 748 Kungsbron 2 749 Stockholm 11122 750 Sweden 752 Email: harald@alvestrand.no