idnits 2.17.1 draft-ietf-mmusic-msid-13.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 (April 5, 2016) is 2942 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 April 5, 2016 5 Expires: October 7, 2016 7 WebRTC MediaStream Identification in the Session Description Protocol 8 draft-ietf-mmusic-msid-13 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 October 7, 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 . . . . . . . . . . . . . . . . . 11 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 . . . . . . 12 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 13 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 . . . . . . . . . . . . . . . . . 14 97 B.12. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . 15 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 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 107 1. Introduction 109 1.1. Structure Of This Document 111 This document adds a new Session Description Protocol (SDP) [RFC4566] 112 mechanism that can associate application layer identifiers with the 113 binding between media streams, attaching identifiers to the media 114 streams and attaching identifiers to the groupings they form. It is 115 designed for use with WebRTC[I-D.ietf-rtcweb-overview] . 117 Section 1.2 gives the background on why a new mechanism is needed. 119 Section 2 gives the definition of the new mechanism. 121 Section 3 gives the necessary semantic information and procedures for 122 using the msid attribute to signal the association of 123 MediaStreamTracks to MediaStreams in support of the WebRTC API 124 [W3C.WD-webrtc-20150210]. 126 1.2. Why A New Mechanism Is Needed 128 When media is carried by RTP [RFC3550], each RTP media stream is 129 distinguished inside an RTP session by its SSRC; each RTP session is 130 distinguished from all other RTP sessions by being on a different 131 transport association (strictly speaking, 2 transport associations, 132 one used for RTP and one used for RTCP, unless RTP/RTCP multiplexing 133 [RFC5761] is used). 135 SDP gives a description based on media descriptions. According to 136 the model used in [I-D.ietf-rtcweb-jsep], each media description 137 describes exactly one media source, and if mulitple media sources are 138 carried in an RTP session, this is signalled using BUNDLE 139 [I-D.ietf-mmusic-sdp-bundle-negotiation]; if BUNDLE is not used, each 140 media source is carried in its own RTP session. 142 The SDP grouping framework [RFC5888] can be used to group media 143 descriptions. However, for the use case of WebRTC, there is the need 144 for an application to specify some application-level information 145 about the association between the media description and the group. 146 This is not possible using the SDP grouping framework. 148 1.3. The WEBRTC MediaStream 150 The W3C WebRTC API specification [W3C.WD-webrtc-20150210] specifies 151 that communication between WebRTC entities is done via MediaStreams, 152 which contain MediaStreamTracks. A MediaStreamTrack is generally 153 carried using a single SSRC in an RTP session (forming an RTP media 154 stream. The collision of terminology is unfortunate.) There might 155 possibly be additional SSRCs, possibly within additional RTP 156 sessions, in order to support functionality like forward error 157 correction or simulcast. This complication is ignored below. 159 MediaStreamTracks are unidirectional; they carry media on one 160 direction only. 162 In the RTP specification, media streams are identified using the SSRC 163 field. Streams are grouped into RTP Sessions, and also carry a 164 CNAME. Neither CNAME nor RTP session correspond to a MediaStream. 165 Therefore, the association of an RTP media stream to MediaStreams 166 need to be explicitly signaled. 168 WebRTC defines a mapping (documented in [I-D.ietf-rtcweb-jsep]) where 169 one SDP media description is used to describe each MediaStreamTrack, 170 and the BUNDLE mechanism [I-D.ietf-mmusic-sdp-bundle-negotiation] is 171 used to group MediaStreamTracks into RTP sessions. Therefore, the 172 need is to specify the ID of a MediaStreamTrack and its associated 173 MediaStream for each media description, which can be accomplished 174 with a media-level SDP attribute. 176 This usage is described in Section 3. 178 2. The Msid Mechanism 180 This document defines a new SDP [RFC4566] media-level "msid" 181 attribute. This new attribute allows endpoints to associate RTP 182 media streams that are described in different media descriptions with 183 the same MediaStreams as defined in [W3C.WD-webrtc-20150210]., and to 184 carry an identifier for each MediaStreamTrack in its "appdata" field. 186 The value of the "msid" attribute consists of an identifier and an 187 optional "appdata" field. 189 The name of the attribute is "msid". 191 The value of the attribute is specified by the following ABNF 192 [RFC5234] grammar: 194 msid-value = msid-id [ SP msid-appdata ] 195 msid-id = 1*64token-char ; see RFC 4566 196 msid-appdata = 1*64token-char ; see RFC 4566 198 An example msid value for a group with the identifier "examplefoo" 199 and application data "examplebar" might look like this: 201 msid:examplefoo examplebar 203 The identifier is a string of ASCII characters that are legal in a 204 "token", consisting of between 1 and 64 characters. 206 Application data (msid-appdata) is carried on the same line as the 207 identifier, separated from the identifier by a space. 209 The identifier (msid-id) uniquely identifies a group within the scope 210 of an SDP description. 212 There may be multiple msid attributes in a single media description. 213 This represents the case where a single MediaStreamTrack is present 214 in multiple MediaStreams; the value of "msid-appdata" MUST be 215 identical for all occurences. 217 Multiple media descriptions with the same value for msid-id and msid- 218 appdata is not permitted. 220 Endpoints can update the associations between RTP media streams as 221 expressed by msid attributes at any time. 223 The msid attributes depend on the association of RTP media streams 224 with media descriptions, but does not depend on the association of 225 RTP media streams with RTP transports; therefore, its mux category is 226 NORMAL - the process of deciding on MSID attributes doesn't have to 227 take into consideration whether the media streams are bundled or not. 229 3. Procedures 231 This section describes the procedures for associating media 232 descriptions representing MediaStreamTracks within MediaStreams as 233 defined in [W3C.WD-webrtc-20150210]. 235 In the Javascript API, each MediaStream and MediaStreamTrack has an 236 "id" attribute, which is a DOMString. 238 The value of the "msid-id" field in the msid consists of the "id" 239 attribute of a MediaStream, as defined in its WebIDL specification. 241 The value of the "msid-appdata" field in the msid consists of the 242 "id" attribute of a MediaStreamTrack, as defined in its WebIDL 243 specification. 245 When an SDP session description is updated, a specific "msid-id" 246 continues to refer to the same MediaStream, and a specific "msid- 247 appdata" to the same MediaStreamTrack. There is no memory apart from 248 the currently valid SDP descriptions; if an msid "identifier" value 249 disappears from the SDP and appears in a later negotiation, it will 250 be taken to refer to a new MediaStream. 252 The following is a high level description of the rules for handling 253 SDP updates. Detailed procedures are in Section 3.2. 255 o When a new msid "identifier" value occurs in a session 256 description, the recipient can signal to its application that a 257 new MediaStream has been added. 259 o When a session description is updated to have media descriptions 260 with an msid "identifier" value, with one or more different 261 "appdata" values, the recipient can signal to its application that 262 new MediaStreamTracks have been added to the MediaStream. This is 263 done for each different msid "identifier" value. 265 o When a session description is updated to no longer list any msid 266 attribute on a specific media description, the recipient can 267 signal to its application that the corresponding MediaStreamTrack 268 has ended. 270 In addition to signaling that the track is closed when its msid 271 attribute disappears from the SDP, the track will also be signaled as 272 being closed when all associated SSRCs have disappeared by the rules 273 of [RFC3550] section 6.3.4 (BYE packet received) and 6.3.5 (timeout), 274 and when the corresponding media description is disabled by setting 275 the port number to zero. Changing the direction of the media 276 description (by setting "sendonly", "recvonly" or "inactive" 277 attributes) will not close the MediaStreamTrack. 279 The association between SSRCs and media descriptions is specified in 280 [I-D.ietf-rtcweb-jsep]. 282 3.1. Handling of non-signalled tracks 284 Entities that do not use msid will not send msid. This means that 285 there will be some incoming RTP packets that the recipient has no 286 predefined MediaStream id value for. 288 Note that this handling is triggered by incoming RTP packets, not by 289 SDP negotiation. 291 When MSID is used, the only time this can happen is when, at a time 292 subsequent to the initial negotiation, a negotiation is performed 293 where the answerer adds a MediaStreamTrack to an already established 294 connection and starts sending data before the answer is received by 295 the offerer. For initial negotiation, packets won't flow until the 296 ICE candidates and fingerprints have been exchanged, so this is not 297 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-02 483 (work in progress), July 2014. 485 [I-D.ietf-rtcweb-jsep] 486 Uberti, J., Jennings, C., and E. Rescorla, "Javascript 487 Session Establishment Protocol", draft-ietf-rtcweb-jsep-07 488 (work in progress), July 2014. 490 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 491 Requirement Levels", BCP 14, RFC 2119, March 1997. 493 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 494 Jacobson, "RTP: A Transport Protocol for Real-Time 495 Applications", STD 64, RFC 3550, July 2003. 497 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 498 Description Protocol", RFC 4566, July 2006. 500 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 501 Specifications: ABNF", STD 68, RFC 5234, January 2008. 503 [W3C.WD-webrtc-20150210] 504 Bergkvist, A., Burnett, D., Jennings, C., and A. 505 Narayanan, "WebRTC 1.0: Real-time Communication Between 506 Browsers", World Wide Web Consortium WD WD- 507 webrtc-20150210, February 2015, 508 . 510 7.2. Informative References 512 [I-D.ietf-mmusic-sdp-bundle-negotiation] 513 Holmberg, C., Alvestrand, H., and C. Jennings, 514 "Negotiating Media Multiplexing Using the Session 515 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 516 negotiation-07 (work in progress), April 2014. 518 [I-D.ietf-rtcweb-overview] 519 Alvestrand, H., "Overview: Real Time Protocols for 520 Browser-based Applications", draft-ietf-rtcweb-overview-10 521 (work in progress), June 2014. 523 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 524 Control Packets on a Single Port", RFC 5761, April 2010. 526 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 527 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 529 Appendix A. Design considerations, rejected alternatives 531 One suggested mechanism has been to use CNAME instead of a new 532 attribute. This was abandoned because CNAME identifies a 533 synchronization context; one can imagine both wanting to have tracks 534 from the same synchronization context in multiple MediaStreams and 535 wanting to have tracks from multiple synchronization contexts within 536 one MediaStream (but the latter is impossible, since a MediaStream is 537 defined to impose synchronization on its members). 539 Another suggestion has been to put the msid value within an attribute 540 of RTCP SR (sender report) packets. This doesn't offer the ability 541 to know that you have seen all the tracks currently configured for a 542 media stream. 544 A suggestion that survived for a number of drafts was to define 545 "msid" as a generic mechanism, where the particular semantics of this 546 usage of the mechanism would be defined by an "a=wms-semantic" 547 attribute. This was removed in April 2015. 549 Appendix B. Change log 551 This appendix should be deleted before publication as an RFC. 553 B.1. Changes from alvestrand-rtcweb-msid-00 to -01 555 Added track identifier. 557 Added inclusion-by-reference of draft-lennox-mmusic-source-selection 558 for track muting. 560 Some rewording. 562 B.2. Changes from alvestrand-rtcweb-msid-01 to -02 564 Split document into sections describing a generic grouping mechanism 565 and sections describing the application of this grouping mechanism to 566 the WebRTC MediaStream concept. 568 Removed the mechanism for muting tracks, since this is not central to 569 the MSID mechanism. 571 B.3. Changes from alvestrand-rtcweb-msid-02 to mmusic-msid-00 573 Changed the draft name according to the wishes of the MMUSIC group 574 chairs. 576 Added text indicting cases where it's appropriate to have the same 577 appdata for multiple SSRCs. 579 Minor textual updates. 581 B.4. Changes from alvestrand-mmusic-msid-00 to -01 583 Increased the amount of explanatory text, much based on a review by 584 Miguel Garcia. 586 Removed references to BUNDLE, since that spec is under active 587 discussion. 589 Removed distinguished values of the MSID identifier. 591 B.5. Changes from alvestrand-mmusic-msid-01 to -02 593 Changed the order of the "msid-semantic: " attribute's value fields 594 and allowed multiple identifiers. This makes the attribute useful as 595 a marker for "I understand this semantic". 597 Changed the syntax for "identifier" and "appdata" to be "token". 599 Changed the registry for the "msid-semantic" attribute values to be a 600 new registry, based on advice given in Atlanta. 602 B.6. Changes from alvestrand-mmusic-msid-02 to ietf-mmusic-00 604 Updated terminology to refer to m-lines rather than RTP sessions when 605 discussing SDP formats and the ability of other linking mechanisms to 606 refer to SSRCs. 608 Changed the "default" mechanism to return independent streams after 609 considering the synchronization problem. 611 Removed the space from between "msid-semantic" and its value, to be 612 consistent with RFC 5576. 614 B.7. Changes from mmusic-msid-00 to -01 616 Reworked msid mechanism to be a per-m-line attribute, to align with 617 draft-roach-mmusic-unified-plan. 619 B.8. Changes from mmusic-msid-01 to -02 621 Corrected several missed cases where the word "ssrc" was not changed 622 to "M-line". 624 Added pointer to unified-plan (which should be moved to point to 625 -jsep) 627 Removed suggestion that ssrc-group attributes can be used with "msid- 628 semantic", it is now only the msid-semantic registry. 630 B.9. Changes from mmusic-msid-02 to -03 632 Corrected even more cases where the word "ssrc" was not changed to 633 "M-line". 635 Added the functionality of using an asterisk (*) in the msid-semantic 636 line, in order to remove the need for listing all msids in the msid- 637 semantic line whne only one msid-semantic is in use. 639 Removed some now-unnecessary text. 641 B.10. Changes from mmusic-msid-03 to -04 643 Changed title to reflect focus on WebRTC MediaStreams 645 Added a section on receiver-side media stream control, using the 646 "msid-control" attribute. 648 B.11. Changes from -04 to -05 650 Removed the msid-control section after WG discussion. 652 Removed some text that seemed only to pertain to resolved issues. 654 B.12. Changes from -05 to -06 656 Addressed issues found in Fleming Andreassen's review 658 Referenced JSEP rather than unified-plan for the M-line mapping model 659 Relaxed MSID definition to allow "token-char" in values rather than 660 a-z 0-9 hyphen; tightened ABNF by adding length description to it. 662 Deleted discussion of abandoned alternatives, as part of preparing 663 for publication. 665 Added a "detailed procedures" section to the WMS semantics 666 description. 668 Added IANA registration of the "msid-semantic" attribute. 670 B.13. Changes from -06 to -07 672 Changed terminology from referring to "WebRTC device" to referring to 673 "entities that implement the WMS semantic". 675 Changed names for ABNF constructions based on a proposal by Paul 676 Kyzivat. 678 Included a section on generic offer/answer semantics. 680 B.14. Changes from -07 to -08 682 Removed Appendix B that described the (now obsolete) ssrc-specific 683 usage of MSID. 685 Adopted a restructuring of the IANA section based on a suggestion 686 from Martin Thomson. 688 A number of text and ABNF clarifications based on suggestions from 689 Ted Hardie, Paul Kyzivat and Adam Roach. 691 Changed the "non-signalled track handling" to create a single stream 692 with multiple tracks again, according to discussions at TPAC in 693 November 2014 695 B.15. Changes from -08 to -09 697 Removed "wms-semantic" and all mention of multiple semantics for 698 msid, as agreed at the Dallas IETF, March 2015. 700 Addressed a number of review comments from Fleming Andresen and 701 others. 703 Changed the term "m-line" to "media description", since that is the 704 term used in RFC 4566. 706 Tried to make sure this document does not describe the API to the 707 application. 709 B.16. Changes from -09 to -10 711 Addressed review comments from Paul Kyzivat. 713 B.17. Changes from -10 to -11 715 Defined the semantics of multiple MSIDs in a media section to be a 716 MediaStreamTrack present in multiple MediaStreams. 718 Made an explicit note that MediaStreamTracks are unidirectional. 720 Disallowed the option of sending multiple media sections with the 721 same msid (id and appdata identical). 723 B.18. Changes from -11 to -12 725 Added mux-category to the IANA considerations section. 727 B.19. Changes from -12 to -13 729 Modified registration description to delete dependency on -4566-bis 731 Author's Address 733 Harald Alvestrand 734 Google 735 Kungsbron 2 736 Stockholm 11122 737 Sweden 739 Email: harald@alvestrand.no