idnits 2.17.1 draft-ietf-mmusic-msid-12.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 (March 18, 2016) is 2954 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 (-37) exists of draft-ietf-mmusic-rfc4566bis-16 == 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-08 ** 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-13 Summary: 1 error (**), 0 flaws (~~), 6 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 March 18, 2016 5 Expires: September 19, 2016 7 WebRTC MediaStream Identification in the Session Description Protocol 8 draft-ietf-mmusic-msid-12 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 September 19, 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 . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . 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 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 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 106 1. Introduction 108 1.1. Structure Of This Document 110 This document adds a new Session Description Protocol (SDP) [RFC4566] 111 mechanism that can associate application layer identifiers with the 112 binding between media streams, attaching identifiers to the media 113 streams and attaching identifiers to the groupings they form. It is 114 designed for use with WebRTC[I-D.ietf-rtcweb-overview] . 116 Section 1.2 gives the background on why a new mechanism is needed. 118 Section 2 gives the definition of the new mechanism. 120 Section 3 gives the necessary semantic information and procedures for 121 using the msid attribute to signal the association of 122 MediaStreamTracks to MediaStreams in support of the WebRTC API 123 [W3C.WD-webrtc-20150210]. 125 1.2. Why A New Mechanism Is Needed 127 When media is carried by RTP [RFC3550], each RTP media stream is 128 distinguished inside an RTP session by its SSRC; each RTP session is 129 distinguished from all other RTP sessions by being on a different 130 transport association (strictly speaking, 2 transport associations, 131 one used for RTP and one used for RTCP, unless RTP/RTCP multiplexing 132 [RFC5761] is used). 134 SDP gives a description based on media descriptions. According to 135 the model used in [I-D.ietf-rtcweb-jsep], each media description 136 describes exactly one media source, and if mulitple media sources are 137 carried in an RTP session, this is signalled using BUNDLE 138 [I-D.ietf-mmusic-sdp-bundle-negotiation]; if BUNDLE is not used, each 139 media source is carried in its own RTP session. 141 The SDP grouping framework [RFC5888] can be used to group media 142 descriptions. However, for the use case of WebRTC, there is the need 143 for an application to specify some application-level information 144 about the association between the media description and the group. 145 This is not possible using the SDP grouping framework. 147 1.3. The WEBRTC MediaStream 149 The W3C WebRTC API specification [W3C.WD-webrtc-20150210] specifies 150 that communication between WebRTC entities is done via MediaStreams, 151 which contain MediaStreamTracks. A MediaStreamTrack is generally 152 carried using a single SSRC in an RTP session (forming an RTP media 153 stream. The collision of terminology is unfortunate.) There might 154 possibly be additional SSRCs, possibly within additional RTP 155 sessions, in order to support functionality like forward error 156 correction or simulcast. This complication is ignored below. 158 MediaStreamTracks are unidirectional; they carry media on one 159 direction only. 161 In the RTP specification, media streams are identified using the SSRC 162 field. Streams are grouped into RTP Sessions, and also carry a 163 CNAME. Neither CNAME nor RTP session correspond to a MediaStream. 164 Therefore, the association of an RTP media stream to MediaStreams 165 need to be explicitly signaled. 167 WebRTC defines a mapping (documented in [I-D.ietf-rtcweb-jsep]) where 168 one SDP media description is used to describe each MediaStreamTrack, 169 and the BUNDLE mechanism [I-D.ietf-mmusic-sdp-bundle-negotiation] is 170 used to group MediaStreamTracks into RTP sessions. Therefore, the 171 need is to specify the ID of a MediaStreamTrack and its associated 172 MediaStream for each media description, which can be accomplished 173 with a media-level SDP attribute. 175 This usage is described in Section 3. 177 2. The Msid Mechanism 179 This document defines a new SDP [RFC4566] media-level "msid" 180 attribute. This new attribute allows endpoints to associate RTP 181 media streams that are described in different media descriptions with 182 the same MediaStreams as defined in [W3C.WD-webrtc-20150210]., and to 183 carry an identifier for each MediaStreamTrack in its "appdata" field. 185 The value of the "msid" attribute consists of an identifier and an 186 optional "appdata" field. 188 The name of the attribute is "msid". 190 The value of the attribute is specified by the following ABNF 191 [RFC5234] grammar: 193 msid-value = msid-id [ SP msid-appdata ] 194 msid-id = 1*64token-char ; see RFC 4566 195 msid-appdata = 1*64token-char ; see RFC 4566 197 An example msid value for a group with the identifier "examplefoo" 198 and application data "examplebar" might look like this: 200 msid:examplefoo examplebar 202 The identifier is a string of ASCII characters that are legal in a 203 "token", consisting of between 1 and 64 characters. 205 Application data (msid-appdata) is carried on the same line as the 206 identifier, separated from the identifier by a space. 208 The identifier (msid-id) uniquely identifies a group within the scope 209 of an SDP description. 211 There may be multiple msid attributes in a single media description. 212 This represents the case where a single MediaStreamTrack is present 213 in multiple MediaStreams; the value of "msid-appdata" MUST be 214 identical for all occurences. 216 Multiple media descriptions with the same value for msid-id and msid- 217 appdata is not permitted. 219 Endpoints can update the associations between RTP media streams as 220 expressed by msid attributes at any time. 222 The msid attributes depend on the association of RTP media streams 223 with media descriptions, but does not depend on the association of 224 RTP media streams with RTP transports; therefore, its mux category is 225 NORMAL - the process of deciding on MSID attributes doesn't have to 226 take into consideration whether the media streams are bundled or not. 228 3. Procedures 230 This section describes the procedures for associating media 231 descriptions representing MediaStreamTracks within MediaStreams as 232 defined in [W3C.WD-webrtc-20150210]. 234 In the Javascript API, each MediaStream and MediaStreamTrack has an 235 "id" attribute, which is a DOMString. 237 The value of the "msid-id" field in the msid consists of the "id" 238 attribute of a MediaStream, as defined in its WebIDL specification. 240 The value of the "msid-appdata" field in the msid consists of the 241 "id" attribute of a MediaStreamTrack, as defined in its WebIDL 242 specification. 244 When an SDP session description is updated, a specific "msid-id" 245 continues to refer to the same MediaStream, and a specific "msid- 246 appdata" to the same MediaStreamTrack. There is no memory apart from 247 the currently valid SDP descriptions; if an msid "identifier" value 248 disappears from the SDP and appears in a later negotiation, it will 249 be taken to refer to a new MediaStream. 251 The following is a high level description of the rules for handling 252 SDP updates. Detailed procedures are in Section 3.2. 254 o When a new msid "identifier" value occurs in a session 255 description, the recipient can signal to its application that a 256 new MediaStream has been added. 258 o When a session description is updated to have media descriptions 259 with an msid "identifier" value, with one or more different 260 "appdata" values, the recipient can signal to its application that 261 new MediaStreamTracks have been added to the MediaStream. This is 262 done for each different msid "identifier" value. 264 o When a session description is updated to no longer list any msid 265 attribute on a specific media description, the recipient can 266 signal to its application that the corresponding MediaStreamTrack 267 has ended. 269 In addition to signaling that the track is closed when its msid 270 attribute disappears from the SDP, the track will also be signaled as 271 being closed when all associated SSRCs have disappeared by the rules 272 of [RFC3550] section 6.3.4 (BYE packet received) and 6.3.5 (timeout), 273 and when the corresponding media description is disabled by setting 274 the port number to zero. Changing the direction of the media 275 description (by setting "sendonly", "recvonly" or "inactive" 276 attributes) will not close the MediaStreamTrack. 278 The association between SSRCs and media descriptions is specified in 279 [I-D.ietf-rtcweb-jsep]. 281 3.1. Handling of non-signalled tracks 283 Entities that do not use msid will not send msid. This means that 284 there will be some incoming RTP packets that the recipient has no 285 predefined MediaStream id value for. 287 Note that this handling is triggered by incoming RTP packets, not by 288 SDP negotiation. 290 When MSID is used, the only time this can happen is when, at a time 291 subsequent to the initial negotiation, a negotiation is performed 292 where the answerer adds a MediaStreamTrack to an already established 293 connection and starts sending data before the answer is received by 294 the offerer. For initial negotiation, packets won't flow until the 295 ICE candidates and fingerprints have been exchanged, so this is not 296 an issue. 298 The recipient of those packets will perform the following steps: 300 o When RTP packets are initially received, it will create an 301 appropriate MediaStreamTrack based on the type of the media 302 (carried in PayloadType), and use the MID RTP header extension 303 [I-D.ietf-mmusic-sdp-bundle-negotiation] (if present) to associate 304 the RTP packets with a specific media section. If the connection 305 is not in the RTCSignalingState "stable", it will wait at this 306 point. 308 o When the connection is in the RTCSignalingState "stable", it will 309 look at the relevant media section to find the msid attribute. 311 o If there is an msid attribute, it will use that attribute to 312 populate the "id" field of the MediaStreamTrack and associated 313 MediaStreams, as described above. 315 o If there is no msid attribute, the identifier of the 316 MediaStreamTrack will be set to a randomly generated string, and 317 it will be signalled as being part of a MediaStream with the 318 WebIDL "label" attribute set to "Non-WebRTC stream". 320 o After deciding on the "id" field to be applied to the 321 MediaStreamTrack, the track will be signalled to the user. 323 The process above may involve a considerable amount of buffering 324 before the stable state is entered, If the implementation wishes to 325 limit this buffering, it MUST signal to the user that media has been 326 discarded. 328 It follows from the above that media stream tracks in the "default" 329 media stream cannot be closed by removing the msid attribute; the 330 application must instead signal these as closed when the SSRC 331 disappears according to the rules of RFC 3550 section 6.3.4 and 6.3.5 332 or by disabling the media description by setting its port to zero. 334 3.2. Detailed Offer/Answer Procedures 336 These procedures are given in terms of RFC 3264-recommended sections. 337 They describe the actions to be taken in terms of MediaStreams and 338 MediaStreamTracks; they do not include event signalling inside the 339 application, which is described in JSEP. 341 3.2.1. Generating the initial offer 343 For each media description in the offer, if there is an associated 344 outgoing MediaStreamTrack, the offerer adds one "a=msid" attribute to 345 the section for each MediaStream with which the MediaStreamTrack is 346 associated. The "identifier" field of the attribute is set to the 347 WebIDL "id" attribute of the MediaStream, and the "appdata" field is 348 set to the WebIDL "id" attribute of the MediaStreamTrack. 350 3.2.2. Answerer processing of the Offer 352 For each media description in the offer, and for each "a=msid" 353 attribute in the media description, the receiver of the offer will 354 perform the following steps: 356 o Extract the "appdata" field of the "a=msid" attribute 358 o Check if a MediaStreamTrack with the same WebIDL "id" attribute as 359 the "appdata" field already exists, and is not in the "ended" 360 state. If it is not found, create it. 362 o Extract the "identifier" field of the "a=msid" attribte. 364 o Check if a MediaStream with the same WebIDL "id" attribute already 365 exists. If not, create it. 367 o Add the MediaStreamTrack to the MediaStream 369 o Signal to the user that a new MediaStreamTrack is available. 371 3.2.3. Generating the answer 373 The answer is generated in exactly the same manner as the offer. 374 "a=msid" values in the offer do not influence the answer. 376 3.2.4. Offerer processing of the answer 378 The answer is processed in exactly the same manner as the offer. 380 3.2.5. Modifying the session 382 On subsequent exchanges, precisely the same procedure as for the 383 initial offer/answer is followed, but with one additional step in the 384 parsing of the offer and answer: 386 o For each MediaStreamTrack that has been created as a result of 387 previous offer/answer exchanges, and is not in the "ended" state, 388 check to see if there is still an "a=msid" attribute in the 389 present SDP whose "appdata" field is the same as the WebIDL "id" 390 attribute of the track. 392 o If no such attribute is found, stop the MediaStreamTrack. This 393 will set its state to "ended". 395 3.3. Example SDP description 397 The following SDP description shows the representation of a WebRTC 398 PeerConnection with two MediaStreams, each of which has one audio and 399 one video track. Only the parts relevant to the MSID are shown. 401 Line wrapping, empty lines and comments are added for clarity. They 402 are not part of the SDP. 404 # First MediaStream - id is 4701... 405 m=audio 56500 UDP/TLS/RTP/SAVPF 96 0 8 97 98 406 a=msid:47017fee-b6c1-4162-929c-a25110252400 407 f83006c5-a0ff-4e0a-9ed9-d3e6747be7d9 409 m=video 56502 UDP/TLS/RTP/SAVPF 100 101 410 a=msid:47017fee-b6c1-4162-929c-a25110252400 411 b47bdb4a-5db8-49b5-bcdc-e0c9a23172e0 413 # Second MediaStream - id is 6131.... 414 m=audio 56503 UDP/TLS/RTP/SAVPF 96 0 8 97 98 415 a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae 416 b94006c5-cade-4e0a-9ed9-d3e6747be7d9 418 m=video 56504 UDP/TLS/RTP/SAVPF 100 101 419 a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae 420 f30bdb4a-1497-49b5-3198-e0c9a23172e0 422 4. IANA Considerations 424 4.1. Attribute registration in existing registries 426 This document requests IANA to register the "msid" attribute in the 427 "att-field (media level only)" registry within the SDP parameters 428 registry, according to the procedures of [RFC4566] 430 The required information for "msid" is: 432 o Contact name, email: IETF, contacted via mmusic@ietf.org, or a 433 successor address designated by IESG 435 o Attribute name: msid 437 o Long-form attribute name: Media stream group Identifier 439 o Subject to charset: The attribute value contains only ASCII 440 characters, and is therefore not subject to the charset attribute. 442 o Purpose: The attribute can be used to signal the relationship 443 between a WebRTC MediaStream and a set of media descriptions. 445 o Appropriate values: The details of appropriate values are given in 446 RFC XXXX. 448 o MUX category: NORMAL 450 The MUX category is defined in [I-D.ietf-mmusic-sdp-mux-attributes] 451 with registration procedures in [I-D.ietf-mmusic-rfc4566bis]. 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-rfc4566bis] 481 Handley, M., Jacobson, V., Perkins, C., and A. Begen, 482 "SDP: Session Description Protocol", draft-ietf-mmusic- 483 rfc4566bis-16 (work in progress), November 2015. 485 [I-D.ietf-mmusic-sdp-mux-attributes] 486 Nandakumar, S., "A Framework for SDP Attributes when 487 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12 488 (work in progress), January 2016. 490 [I-D.ietf-rtcweb-jsep] 491 Uberti, J., Jennings, C., and E. Rescorla, "Javascript 492 Session Establishment Protocol", draft-ietf-rtcweb-jsep-08 493 (work in progress), October 2014. 495 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 496 Requirement Levels", BCP 14, RFC 2119, March 1997. 498 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 499 Jacobson, "RTP: A Transport Protocol for Real-Time 500 Applications", STD 64, RFC 3550, July 2003. 502 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 503 Description Protocol", RFC 4566, July 2006. 505 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 506 Specifications: ABNF", STD 68, RFC 5234, January 2008. 508 [W3C.WD-webrtc-20150210] 509 Bergkvist, A., Burnett, D., Jennings, C., and A. 510 Narayanan, "WebRTC 1.0: Real-time Communication Between 511 Browsers", World Wide Web Consortium WD WD- 512 webrtc-20150210, February 2015, 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-07 (work in progress), April 2014. 523 [I-D.ietf-rtcweb-overview] 524 Alvestrand, H., "Overview: Real Time Protocols for 525 Browser-based Applications", draft-ietf-rtcweb-overview-13 526 (work in progress), November 2014. 528 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 529 Control Packets on a Single Port", RFC 5761, April 2010. 531 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 532 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 534 Appendix A. Design considerations, rejected alternatives 536 One suggested mechanism has been to use CNAME instead of a new 537 attribute. This was abandoned because CNAME identifies a 538 synchronization context; one can imagine both wanting to have tracks 539 from the same synchronization context in multiple MediaStreams and 540 wanting to have tracks from multiple synchronization contexts within 541 one MediaStream (but the latter is impossible, since a MediaStream is 542 defined to impose synchronization on its members). 544 Another suggestion has been to put the msid value within an attribute 545 of RTCP SR (sender report) packets. This doesn't offer the ability 546 to know that you have seen all the tracks currently configured for a 547 media stream. 549 A suggestion that survived for a number of drafts was to define 550 "msid" as a generic mechanism, where the particular semantics of this 551 usage of the mechanism would be defined by an "a=wms-semantic" 552 attribute. This was removed in April 2015. 554 Appendix B. Change log 556 This appendix should be deleted before publication as an RFC. 558 B.1. Changes from alvestrand-rtcweb-msid-00 to -01 560 Added track identifier. 562 Added inclusion-by-reference of draft-lennox-mmusic-source-selection 563 for track muting. 565 Some rewording. 567 B.2. Changes from alvestrand-rtcweb-msid-01 to -02 569 Split document into sections describing a generic grouping mechanism 570 and sections describing the application of this grouping mechanism to 571 the WebRTC MediaStream concept. 573 Removed the mechanism for muting tracks, since this is not central to 574 the MSID mechanism. 576 B.3. Changes from alvestrand-rtcweb-msid-02 to mmusic-msid-00 578 Changed the draft name according to the wishes of the MMUSIC group 579 chairs. 581 Added text indicting cases where it's appropriate to have the same 582 appdata for multiple SSRCs. 584 Minor textual updates. 586 B.4. Changes from alvestrand-mmusic-msid-00 to -01 588 Increased the amount of explanatory text, much based on a review by 589 Miguel Garcia. 591 Removed references to BUNDLE, since that spec is under active 592 discussion. 594 Removed distinguished values of the MSID identifier. 596 B.5. Changes from alvestrand-mmusic-msid-01 to -02 598 Changed the order of the "msid-semantic: " attribute's value fields 599 and allowed multiple identifiers. This makes the attribute useful as 600 a marker for "I understand this semantic". 602 Changed the syntax for "identifier" and "appdata" to be "token". 604 Changed the registry for the "msid-semantic" attribute values to be a 605 new registry, based on advice given in Atlanta. 607 B.6. Changes from alvestrand-mmusic-msid-02 to ietf-mmusic-00 609 Updated terminology to refer to m-lines rather than RTP sessions when 610 discussing SDP formats and the ability of other linking mechanisms to 611 refer to SSRCs. 613 Changed the "default" mechanism to return independent streams after 614 considering the synchronization problem. 616 Removed the space from between "msid-semantic" and its value, to be 617 consistent with RFC 5576. 619 B.7. Changes from mmusic-msid-00 to -01 621 Reworked msid mechanism to be a per-m-line attribute, to align with 622 draft-roach-mmusic-unified-plan. 624 B.8. Changes from mmusic-msid-01 to -02 626 Corrected several missed cases where the word "ssrc" was not changed 627 to "M-line". 629 Added pointer to unified-plan (which should be moved to point to 630 -jsep) 632 Removed suggestion that ssrc-group attributes can be used with "msid- 633 semantic", it is now only the msid-semantic registry. 635 B.9. Changes from mmusic-msid-02 to -03 637 Corrected even more cases where the word "ssrc" was not changed to 638 "M-line". 640 Added the functionality of using an asterisk (*) in the msid-semantic 641 line, in order to remove the need for listing all msids in the msid- 642 semantic line whne only one msid-semantic is in use. 644 Removed some now-unnecessary text. 646 B.10. Changes from mmusic-msid-03 to -04 648 Changed title to reflect focus on WebRTC MediaStreams 650 Added a section on receiver-side media stream control, using the 651 "msid-control" attribute. 653 B.11. Changes from -04 to -05 655 Removed the msid-control section after WG discussion. 657 Removed some text that seemed only to pertain to resolved issues. 659 B.12. Changes from -05 to -06 661 Addressed issues found in Fleming Andreassen's review 663 Referenced JSEP rather than unified-plan for the M-line mapping model 665 Relaxed MSID definition to allow "token-char" in values rather than 666 a-z 0-9 hyphen; tightened ABNF by adding length description to it. 668 Deleted discussion of abandoned alternatives, as part of preparing 669 for publication. 671 Added a "detailed procedures" section to the WMS semantics 672 description. 674 Added IANA registration of the "msid-semantic" attribute. 676 B.13. Changes from -06 to -07 678 Changed terminology from referring to "WebRTC device" to referring to 679 "entities that implement the WMS semantic". 681 Changed names for ABNF constructions based on a proposal by Paul 682 Kyzivat. 684 Included a section on generic offer/answer semantics. 686 B.14. Changes from -07 to -08 688 Removed Appendix B that described the (now obsolete) ssrc-specific 689 usage of MSID. 691 Adopted a restructuring of the IANA section based on a suggestion 692 from Martin Thomson. 694 A number of text and ABNF clarifications based on suggestions from 695 Ted Hardie, Paul Kyzivat and Adam Roach. 697 Changed the "non-signalled track handling" to create a single stream 698 with multiple tracks again, according to discussions at TPAC in 699 November 2014 701 B.15. Changes from -08 to -09 703 Removed "wms-semantic" and all mention of multiple semantics for 704 msid, as agreed at the Dallas IETF, March 2015. 706 Addressed a number of review comments from Fleming Andresen and 707 others. 709 Changed the term "m-line" to "media description", since that is the 710 term used in RFC 4566. 712 Tried to make sure this document does not describe the API to the 713 application. 715 B.16. Changes from -09 to -10 717 Addressed review comments from Paul Kyzivat. 719 B.17. Changes from -10 to -11 721 Defined the semantics of multiple MSIDs in a media section to be a 722 MediaStreamTrack present in multiple MediaStreams. 724 Made an explicit note that MediaStreamTracks are unidirectional. 726 Disallowed the option of sending multiple media sections with the 727 same msid (id and appdata identical). 729 B.18. Changes from -11 to -12 731 Added mux-category to the IANA considerations section. 733 Author's Address 735 Harald Alvestrand 736 Google 737 Kungsbron 2 738 Stockholm 11122 739 Sweden 741 Email: harald@alvestrand.no