idnits 2.17.1 draft-ietf-mmusic-msid-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 13, 2018) is 1961 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 December 13, 2018 5 Expires: June 16, 2019 7 WebRTC MediaStream Identification in the Session Description Protocol 8 draft-ietf-mmusic-msid-17 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 June 16, 2019. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. Structure Of This Document . . . . . . . . . . . . . . . 3 66 1.3. Why A New Mechanism Is Needed . . . . . . . . . . . . . . 4 67 1.4. The WEBRTC MediaStream . . . . . . . . . . . . . . . . . 4 68 2. The Msid Mechanism . . . . . . . . . . . . . . . . . . . . . 5 69 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.1. Handling of non-signalled tracks . . . . . . . . . . . . 7 71 3.2. Detailed Offer/Answer Procedures . . . . . . . . . . . . 9 72 3.2.1. Generating the initial offer . . . . . . . . . . . . 9 73 3.2.2. Answerer processing of the Offer . . . . . . . . . . 9 74 3.2.3. Generating the answer . . . . . . . . . . . . . . . . 10 75 3.2.4. Offerer processing of the answer . . . . . . . . . . 10 76 3.2.5. Modifying the session . . . . . . . . . . . . . . . . 10 77 3.3. Example SDP description . . . . . . . . . . . . . . . . . 10 78 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 79 4.1. Attribute registration in existing registries . . . . . . 11 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 81 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 84 7.2. Informative References . . . . . . . . . . . . . . . . . 13 85 Appendix A. Design considerations, rejected alternatives . . . . 14 86 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 14 87 B.1. Changes from alvestrand-rtcweb-msid-00 to -01 . . . . . . 14 88 B.2. Changes from alvestrand-rtcweb-msid-01 to -02 . . . . . . 15 89 B.3. Changes from alvestrand-rtcweb-msid-02 to mmusic-msid-00 15 90 B.4. Changes from alvestrand-mmusic-msid-00 to -01 . . . . . . 15 91 B.5. Changes from alvestrand-mmusic-msid-01 to -02 . . . . . . 15 92 B.6. Changes from alvestrand-mmusic-msid-02 to ietf-mmusic-00 15 93 B.7. Changes from mmusic-msid-00 to -01 . . . . . . . . . . . 16 94 B.8. Changes from mmusic-msid-01 to -02 . . . . . . . . . . . 16 95 B.9. Changes from mmusic-msid-02 to -03 . . . . . . . . . . . 16 96 B.10. Changes from mmusic-msid-03 to -04 . . . . . . . . . . . 16 97 B.11. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 16 98 B.12. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 16 99 B.13. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 17 100 B.14. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 17 101 B.15. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 17 102 B.16. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 18 103 B.17. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 18 104 B.18. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 18 105 B.19. Changes from -12 to -13 . . . . . . . . . . . . . . . . . 18 106 B.20. Changes from -13 to -14 . . . . . . . . . . . . . . . . . 18 107 B.21. Changes from -14 to -15 . . . . . . . . . . . . . . . . . 18 108 B.22. Changes from -15 to -16 . . . . . . . . . . . . . . . . . 19 109 B.23. Changes from -16 to -17 . . . . . . . . . . . . . . . . . 19 110 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 112 1. Introduction 114 1.1. Terminology 116 This document uses terminology from [I-D.ietf-rtcweb-overview]. In 117 addition, the following terms are used as described below: 119 RTP stream Defined in [RFC7656] as a stream of RTP packets 120 containing media data. 122 MediaStream Defined in [W3C.CR-mediacapture-streams-20160519]as an 123 assembly of MediaStreamTracks. One MediaStream can contain 124 multiple MediaStreamTracks, of the same or different types. 126 MediaStreamTrack Defined in [W3C.CR-mediacapture-streams-20160519]as 127 an unidirectional flow of media data (either audio or video, but 128 not both). Corresponds to the [RFC7656] term "Source Stream". 129 One MediaStreamTrack can be present in zero, one or multiple 130 MediaStreams. 132 Media description Defined in [RFC4566] as a set of fields starting 133 with an "m=" field and terminated by eitehr the next "m=" field or 134 by the end of the session description. 136 1.2. Structure Of This Document 138 This document adds a new Session Description Protocol (SDP) [RFC4566] 139 mechanism that can attach identifiers to the RTP streams and 140 attaching identifiers to the groupings they form. It is designed for 141 use with WebRTC[I-D.ietf-rtcweb-overview] . 143 Section 1.3 gives the background on why a new mechanism is needed. 145 Section 2 gives the definition of the new mechanism. 147 Section 3 gives the necessary semantic information and procedures for 148 using the msid attribute to signal the association of 149 MediaStreamTracks to MediaStreams in support of the WebRTC API 150 [W3C.WD-webrtc-20160531]. 152 1.3. Why A New Mechanism Is Needed 154 When media is carried by RTP [RFC3550], each RTP stream is 155 distinguished inside an RTP session by its SSRC; each RTP session is 156 distinguished from all other RTP sessions by being on a different 157 transport association (strictly speaking, 2 transport associations, 158 one used for RTP and one used for RTCP, unless RTP/RTCP multiplexing 159 [RFC5761] is used). 161 SDP [RFC4566] gives a format for describing an SDP session that can 162 contain multiple media descriptions. According to the model used in 163 [I-D.ietf-rtcweb-jsep], each media description describes exactly one 164 media source, and if multiple media sources are carried in an RTP 165 session, this is signalled using BUNDLE 166 [I-D.ietf-mmusic-sdp-bundle-negotiation]; if BUNDLE is not used, each 167 media source is carried in its own RTP session. 169 The SDP grouping framework [RFC5888] can be used to group media 170 descriptions. However, for the use case of WebRTC, there is the need 171 for an application to specify some application-level information 172 about the association between the media description and the group. 173 This is not possible using the SDP grouping framework. 175 1.4. The WEBRTC MediaStream 177 The W3C WebRTC API specification [W3C.WD-webrtc-20160531] specifies 178 that communication between WebRTC entities is done via MediaStreams, 179 which contain MediaStreamTracks. A MediaStreamTrack is generally 180 carried using a single SSRC in an RTP session (forming an RTP stream. 181 The collision of terminology is unfortunate.) There might possibly 182 be additional SSRCs, possibly within additional RTP sessions, in 183 order to support functionality like forward error correction or 184 simulcast. These additional SSRCs are not affected by this 185 specification. 187 MediaStreamTracks are unidirectional; they carry media on one 188 direction only. 190 In the RTP specification, RTP streams are identified using the SSRC 191 field. Streams are grouped into RTP Sessions, and also carry a 192 CNAME. Neither CNAME nor RTP session correspond to a MediaStream. 193 Therefore, the association of an RTP stream to MediaStreams need to 194 be explicitly signaled. 196 WebRTC defines a mapping (documented in [I-D.ietf-rtcweb-jsep]) where 197 one SDP media description is used to describe each MediaStreamTrack, 198 and the BUNDLE mechanism [I-D.ietf-mmusic-sdp-bundle-negotiation] is 199 used to group MediaStreamTracks into RTP sessions. Therefore, the 200 need is to specify the ID of a MediaStreamTrack and its associated 201 MediaStream for each media description, which can be accomplished 202 with a media-level SDP attribute. 204 This usage is described in Section 3. 206 2. The Msid Mechanism 208 This document defines a new SDP [RFC4566] media-level "msid" 209 attribute. This new attribute allows endpoints to associate RTP 210 streams that are described in different media descriptions with the 211 same MediaStreams as defined in [W3C.WD-webrtc-20160531], and to 212 carry an identifier for each MediaStreamTrack in its "appdata" field. 214 The value of the "msid" attribute consists of an identifier and an 215 optional "appdata" field. 217 The name of the attribute is "msid". 219 The value of the attribute is specified by the following ABNF 220 [RFC5234] grammar: 222 msid-value = msid-id [ SP msid-appdata ] 223 msid-id = 1*64token-char ; see RFC 4566 224 msid-appdata = 1*64token-char ; see RFC 4566 226 An example msid value for a group with the identifier "examplefoo" 227 and application data "examplebar" might look like this: 229 msid:examplefoo examplebar 231 The identifier is a string of ASCII characters that are legal in a 232 "token", consisting of between 1 and 64 characters. 234 Application data (msid-appdata) is carried on the same line as the 235 identifier, separated from the identifier by a space. 237 The identifier (msid-id) uniquely identifies a group within the scope 238 of an SDP description. 240 There may be multiple msid attributes in a single media description. 241 This represents the case where a single MediaStreamTrack is present 242 in multiple MediaStreams; the value of "msid-appdata" MUST be 243 identical for all occurences. 245 Multiple media descriptions with the same value for msid-id and msid- 246 appdata are not permitted. 248 Endpoints can update the associations between RTP streams as 249 expressed by msid attributes at any time. 251 The msid attributes depend on the association of RTP streams with 252 media descriptions, but does not depend on the association of RTP 253 streams with RTP transports; therefore, its mux category (as defined 254 in [I-D.ietf-mmusic-sdp-mux-attributes]) is NORMAL - the process of 255 deciding on MSID attributes doesn't have to take into consideration 256 whether the RTP streams are bundled or not. 258 3. Procedures 260 This section describes the procedures for associating media 261 descriptions representing MediaStreamTracks within MediaStreams as 262 defined in [W3C.WD-webrtc-20160531]. 264 In the Javascript API described in that specification, each 265 MediaStream and MediaStreamTrack has an "id" attribute, which is a 266 DOMString. 268 The value of the "msid-id" field in the msid consists of the "id" 269 attribute of a MediaStream, as defined in the MediaStream's WebIDL 270 specification. The special value "-" indicates "no MediaStream". 272 The value of the "msid-appdata" field in the msid, if present, 273 consists of the "id" attribute of a MediaStreamTrack, as defined in 274 the MediaStreamTrack's WebIDL specification. 276 When an SDP session description is updated, a specific "msid-id" 277 value continues to refer to the same MediaStream, and a specific 278 "msid-appdata" to the same MediaStreamTrack. There is no memory 279 apart from the currently valid SDP descriptions; if an msid 280 "identifier" value disappears from the SDP and appears in a later 281 negotiation, it will be taken to refer to a new MediaStream. 283 If the MSID attribute does not conform to the ABNF given here, it 284 SHOULD be ignored. 286 The following is a high level description of the rules for handling 287 SDP updates. Detailed procedures are in Section 3.2. 289 o When a new msid "identifier" value occurs in a session 290 description, and it is not "-", the recipient can signal to its 291 application that a new MediaStream has been added. 293 o When a session description is updated to have media descriptions 294 with an msid "identifier" value, with one or more different 295 "appdata" values, the recipient can signal to its application that 296 new MediaStreamTracks have been added, and which MediaStream it 297 has been added to. This is done for each different msid 298 "identifier" value, including the special value "-", which 299 indicates that a MediaStreamTrack has been added with no 300 corresponding MediaStream. 302 o If an msid "identifier" value with no "appdata" value appears, it 303 means that the sender did not inform the recipient of the desired 304 identifier of the MediaStreamTrack, and the recipient will assign 305 the "id" value of the created MediaStreamTrack on its own. All 306 msid in a media section that do not have an "appdata" value are 307 assumed to refer to the same MediaStreamTrack. 309 o When a session description is updated to no longer list any msid 310 attribute on a specific media description, the recipient can 311 signal to its application that the corresponding MediaStreamTrack 312 has ended. 314 In addition to signaling that the track is ended when its msid 315 attribute disappears from the SDP, the track will also be signaled as 316 being ended when all associated SSRCs have disappeared by the rules 317 of [RFC3550] section 6.3.4 (BYE packet received) and 6.3.5 (timeout), 318 or when the corresponding media description is disabled by setting 319 the port number to zero. Changing the direction of the media 320 description (by setting "sendonly", "recvonly" or "inactive" 321 attributes) will not end the MediaStreamTrack. 323 The association between SSRCs and media descriptions is specified in 324 [I-D.ietf-rtcweb-jsep]. 326 3.1. Handling of non-signalled tracks 328 Entities that do not use msid will not send msid. This means that 329 there will be some incoming RTP packets that the recipient has no 330 predefined MediaStream id value for. 332 Note that this handling is triggered by incoming RTP packets, not by 333 SDP negotiation. 335 When MSID is used, the only time this can happen is when, after the 336 initial negotiation, a negotiation is performed where the answerer 337 adds a MediaStreamTrack to an already established connection and 338 starts sending data before the answer is received by the offerer. 339 For initial negotiation, packets won't flow until the ICE candidates 340 and fingerprints have been exchanged, so this is not an issue. 342 The recipient of those packets will perform the following steps: 344 o When RTP packets are initially received, it will create an 345 appropriate MediaStreamTrack based on the type of the media 346 (carried in PayloadType), and use the MID RTP header extension 347 [I-D.ietf-mmusic-sdp-bundle-negotiation] (if present) to associate 348 the RTP packets with a specific media section. 350 o If the connection is not in the RTCSignalingState "stable", it 351 will wait at this point. 353 o When the connection is in the RTCSignalingState "stable", it will 354 assign ID values. 356 The following steps are performed to assign ID values: 358 o If there is an msid attribute, it will use that attribute to 359 populate the "id" field of the MediaStreamTrack and associated 360 MediaStreams, as described above. 362 o If there is no msid attribute, the identifier of the 363 MediaStreamTrack will be set to a randomly generated string, and 364 it will be signalled as being part of a MediaStream with the 365 WebIDL "label" attribute set to "Non-WebRTC stream". 367 o After deciding on the "id" field to be applied to the 368 MediaStreamTrack, the track will be signalled to the user. 370 The process above may involve a considerable amount of buffering 371 before the stable state is entered. If the implementation wishes to 372 limit this buffering, it MUST signal to the user that media has been 373 discarded. 375 It follows from the above that MediaStreamTracks in the "default" 376 MediaStream cannot be closed by removing the msid attribute; the 377 application must instead signal these as closed when the SSRC 378 disappears according to the rules of RFC 3550 section 6.3.4 and 6.3.5 379 or by disabling the media description by setting its port to zero. 381 3.2. Detailed Offer/Answer Procedures 383 These procedures are given in terms of RFC 3264-recommended sections. 384 They describe the actions to be taken in terms of MediaStreams and 385 MediaStreamTracks; they do not include event signalling inside the 386 application, which is described in JSEP. 388 3.2.1. Generating the initial offer 390 For each media description in the offer, if there is an associated 391 outgoing MediaStreamTrack, the offerer adds one "a=msid" attribute to 392 the section for each MediaStream with which the MediaStreamTrack is 393 associated. The "identifier" field of the attribute is set to the 394 WebIDL "id" attribute of the MediaStream. If the sender wishes to 395 signal identifiers for the MediaStreamTracks, the "appdata" field is 396 set to the WebIDL "id" attribute of the MediaStreamTrack; otherwise 397 it is omitted. 399 3.2.2. Answerer processing of the Offer 401 For each media description in the offer, and for each "a=msid" 402 attribute in the media description, the receiver of the offer will 403 perform the following steps: 405 o Extract the "appdata" field of the "a=msid" attribute, if present. 407 o If the "appdata" field exists: Check if a MediaStreamTrack with 408 the same WebIDL "id" attribute as the "appdata" field already 409 exists, and is not in the "ended" state. If it is not found, 410 create it. 412 o If the "appdata" field does not exist, and a MediaStreamTrack is 413 not associated with this media section, create one and associate 414 it with this media section for future use. 416 o Extract the "identifier" field of the "a=msid" attribte. 418 o Check if a MediaStream with the same WebIDL "id" attribute already 419 exists. If not, create it. 421 o Add the MediaStreamTrack to the MediaStream 423 o Signal to the user that a new MediaStreamTrack is available. 425 3.2.3. Generating the answer 427 The answer is generated in exactly the same manner as the offer. 428 "a=msid" values in the offer do not influence the answer. 430 3.2.4. Offerer processing of the answer 432 The answer is processed in exactly the same manner as the offer. 434 3.2.5. Modifying the session 436 On subsequent exchanges, precisely the same procedure as for the 437 initial offer/answer is followed, but with one additional step in the 438 parsing of the offer and answer: 440 o For each MediaStreamTrack that has been created as a result of 441 previous offer/answer exchanges, and is not in the "ended" state, 442 check to see if there is still an "a=msid" attribute in the 443 present SDP whose "appdata" field is the same as the WebIDL "id" 444 attribute of the track. 446 o If no such attribute is found, stop the MediaStreamTrack. This 447 will set its state to "ended". 449 3.3. Example SDP description 451 The following SDP description shows the representation of a WebRTC 452 PeerConnection with two MediaStreams, each of which has one audio and 453 one video track. Only the parts relevant to the MSID are shown. 455 Line wrapping, empty lines and comments are added for clarity. They 456 are not part of the SDP. 458 # First MediaStream - id is 4701... 459 m=audio 56500 UDP/TLS/RTP/SAVPF 96 0 8 97 98 460 a=msid:47017fee-b6c1-4162-929c-a25110252400 461 f83006c5-a0ff-4e0a-9ed9-d3e6747be7d9 463 m=video 56502 UDP/TLS/RTP/SAVPF 100 101 464 a=msid:47017fee-b6c1-4162-929c-a25110252400 465 b47bdb4a-5db8-49b5-bcdc-e0c9a23172e0 467 # Second MediaStream - id is 6131.... 468 m=audio 56503 UDP/TLS/RTP/SAVPF 96 0 8 97 98 469 a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae 470 b94006c5-cade-4e0a-9ed9-d3e6747be7d9 472 m=video 56504 UDP/TLS/RTP/SAVPF 100 101 473 a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae 474 f30bdb4a-1497-49b5-3198-e0c9a23172e0 476 4. IANA Considerations 478 4.1. Attribute registration in existing registries 480 This document requests IANA to register the "msid" attribute in the 481 "att-field (media level only)" registry within the SDP parameters 482 registry, according to the procedures of [RFC4566] 484 The required information for "msid" is: 486 o Contact name, email: IETF, contacted via mmusic@ietf.org, or a 487 successor address designated by IESG 489 o Attribute name: msid 491 o Long-form attribute name: MediaStream group Identifier 493 o Subject to charset: The attribute value contains only ASCII 494 characters, and is therefore not subject to the charset attribute. 496 o Purpose: The attribute can be used to signal the relationship 497 between a WebRTC MediaStream and a set of media descriptions. 499 o Appropriate values: The details of appropriate values are given in 500 RFC XXXX. 502 o MUX category: NORMAL 503 The MUX category is defined in [I-D.ietf-mmusic-sdp-mux-attributes]. 505 5. Security Considerations 507 An adversary with the ability to modify SDP descriptions has the 508 ability to switch around tracks between MediaStreams. This is a 509 special case of the general security consideration that modification 510 of SDP descriptions needs to be confined to entities trusted by the 511 application. 513 If implementing buffering as mentioned in Section 3.1, the amount of 514 buffering should be limited to avoid memory exhaustion attacks. 516 Careless generation of identifiers can leak privacy-sensitive 517 information. [W3C.CR-mediacapture-streams-20160519] recommends that 518 identifiers are generated using UUID class 3 or 4 as a basis, which 519 avoids such leakage. 521 No other attacks have been identified that depend on this mechanism. 523 6. Acknowledgements 525 This note is based on sketches from, among others, Justin Uberti and 526 Cullen Jennings. 528 Special thanks to Flemming Andreassen, Ben Campbell, Miguel Garcia, 529 Martin Thomson, Ted Hardie, Adam Roach, Magnus Westerlund, Alissa 530 Cooper, Sue Hares and Paul Kyzivat for their work in reviewing this 531 draft, with many specific language suggestions. 533 7. References 535 7.1. Normative References 537 [I-D.ietf-mmusic-sdp-mux-attributes] 538 Nandakumar, S., "A Framework for SDP Attributes when 539 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12 540 (work in progress), January 2016. 542 [I-D.ietf-rtcweb-jsep] 543 Uberti, J., Jennings, C., and E. Rescorla, "Javascript 544 Session Establishment Protocol", draft-ietf-rtcweb-jsep-14 545 (work in progress), March 2016. 547 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 548 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 549 RFC2119, March 1997, 550 . 552 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 553 Jacobson, "RTP: A Transport Protocol for Real-Time 554 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 555 July 2003, . 557 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 558 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 559 July 2006, . 561 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 562 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 563 RFC5234, January 2008, 564 . 566 [W3C.CR-mediacapture-streams-20160519] 567 Burnett, D., Bergkvist, A., Jennings, C., Narayanan, A., 568 and B. Aboba, "Media Capture and Streams", World Wide Web 569 Consortium CR CR-mediacapture-streams-20160519, May 2016, 570 . 573 [W3C.WD-webrtc-20160531] 574 Wilson, C. and J. Kalliokoski, "WebRTC 1.0: Real-time 575 Communication Between Browsers", World Wide Web Consortium 576 WD WD-webrtc-20160531, May 2016, 577 . 579 7.2. Informative References 581 [I-D.ietf-mmusic-sdp-bundle-negotiation] 582 Holmberg, C., Alvestrand, H., and C. Jennings, 583 "Negotiating Media Multiplexing Using the Session 584 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 585 negotiation-29 (work in progress), April 2016. 587 [I-D.ietf-rtcweb-overview] 588 Alvestrand, H., "Overview: Real Time Protocols for 589 Browser-based Applications", draft-ietf-rtcweb-overview-15 590 (work in progress), January 2016. 592 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 593 Control Packets on a Single Port", RFC 5761, DOI 10.17487/ 594 RFC5761, April 2010, 595 . 597 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 598 Protocol (SDP) Grouping Framework", RFC 5888, DOI 599 10.17487/RFC5888, June 2010, 600 . 602 [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and 603 B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms 604 for Real-Time Transport Protocol (RTP) Sources", RFC 7656, 605 DOI 10.17487/RFC7656, November 2015, 606 . 608 Appendix A. Design considerations, rejected alternatives 610 One suggested mechanism has been to use CNAME instead of a new 611 attribute. This was abandoned because CNAME identifies a 612 synchronization context; one can imagine both wanting to have tracks 613 from the same synchronization context in multiple MediaStreams and 614 wanting to have tracks from multiple synchronization contexts within 615 one MediaStream (but the latter is impossible, since a MediaStream is 616 defined to impose synchronization on its members). 618 Another suggestion has been to put the msid value within an attribute 619 of RTCP SR (sender report) packets. This doesn't offer the ability 620 to know that you have seen all the tracks currently configured for a 621 MediaStream. 623 A suggestion that survived for a number of drafts was to define 624 "msid" as a generic mechanism, where the particular semantics of this 625 usage of the mechanism would be defined by an "a=wms-semantic" 626 attribute. This was removed in April 2015. 628 Appendix B. Change log 630 This appendix should be deleted before publication as an RFC. 632 B.1. Changes from alvestrand-rtcweb-msid-00 to -01 634 Added track identifier. 636 Added inclusion-by-reference of draft-lennox-mmusic-source-selection 637 for track muting. 639 Some rewording. 641 B.2. Changes from alvestrand-rtcweb-msid-01 to -02 643 Split document into sections describing a generic grouping mechanism 644 and sections describing the application of this grouping mechanism to 645 the WebRTC MediaStream concept. 647 Removed the mechanism for muting tracks, since this is not central to 648 the MSID mechanism. 650 B.3. Changes from alvestrand-rtcweb-msid-02 to mmusic-msid-00 652 Changed the draft name according to the wishes of the MMUSIC group 653 chairs. 655 Added text indicting cases where it's appropriate to have the same 656 appdata for multiple SSRCs. 658 Minor textual updates. 660 B.4. Changes from alvestrand-mmusic-msid-00 to -01 662 Increased the amount of explanatory text, much based on a review by 663 Miguel Garcia. 665 Removed references to BUNDLE, since that spec is under active 666 discussion. 668 Removed distinguished values of the MSID identifier. 670 B.5. Changes from alvestrand-mmusic-msid-01 to -02 672 Changed the order of the "msid-semantic: " attribute's value fields 673 and allowed multiple identifiers. This makes the attribute useful as 674 a marker for "I understand this semantic". 676 Changed the syntax for "identifier" and "appdata" to be "token". 678 Changed the registry for the "msid-semantic" attribute values to be a 679 new registry, based on advice given in Atlanta. 681 B.6. Changes from alvestrand-mmusic-msid-02 to ietf-mmusic-00 683 Updated terminology to refer to m-lines rather than RTP sessions when 684 discussing SDP formats and the ability of other linking mechanisms to 685 refer to SSRCs. 687 Changed the "default" mechanism to return independent streams after 688 considering the synchronization problem. 690 Removed the space from between "msid-semantic" and its value, to be 691 consistent with RFC 5576. 693 B.7. Changes from mmusic-msid-00 to -01 695 Reworked msid mechanism to be a per-m-line attribute, to align with 696 draft-roach-mmusic-unified-plan. 698 B.8. Changes from mmusic-msid-01 to -02 700 Corrected several missed cases where the word "ssrc" was not changed 701 to "M-line". 703 Added pointer to unified-plan (which should be moved to point to 704 -jsep) 706 Removed suggestion that ssrc-group attributes can be used with "msid- 707 semantic", it is now only the msid-semantic registry. 709 B.9. Changes from mmusic-msid-02 to -03 711 Corrected even more cases where the word "ssrc" was not changed to 712 "M-line". 714 Added the functionality of using an asterisk (*) in the msid-semantic 715 line, in order to remove the need for listing all msids in the msid- 716 semantic line whne only one msid-semantic is in use. 718 Removed some now-unnecessary text. 720 B.10. Changes from mmusic-msid-03 to -04 722 Changed title to reflect focus on WebRTC MediaStreams 724 Added a section on receiver-side media stream control, using the 725 "msid-control" attribute. 727 B.11. Changes from -04 to -05 729 Removed the msid-control section after WG discussion. 731 Removed some text that seemed only to pertain to resolved issues. 733 B.12. Changes from -05 to -06 735 Addressed issues found in Fleming Andreassen's review 737 Referenced JSEP rather than unified-plan for the M-line mapping model 738 Relaxed MSID definition to allow "token-char" in values rather than 739 a-z 0-9 hyphen; tightened ABNF by adding length description to it. 741 Deleted discussion of abandoned alternatives, as part of preparing 742 for publication. 744 Added a "detailed procedures" section to the WMS semantics 745 description. 747 Added IANA registration of the "msid-semantic" attribute. 749 B.13. Changes from -06 to -07 751 Changed terminology from referring to "WebRTC device" to referring to 752 "entities that implement the WMS semantic". 754 Changed names for ABNF constructions based on a proposal by Paul 755 Kyzivat. 757 Included a section on generic offer/answer semantics. 759 B.14. Changes from -07 to -08 761 Removed Appendix B that described the (now obsolete) ssrc-specific 762 usage of MSID. 764 Adopted a restructuring of the IANA section based on a suggestion 765 from Martin Thomson. 767 A number of text and ABNF clarifications based on suggestions from 768 Ted Hardie, Paul Kyzivat and Adam Roach. 770 Changed the "non-signalled track handling" to create a single stream 771 with multiple tracks again, according to discussions at TPAC in 772 November 2014 774 B.15. Changes from -08 to -09 776 Removed "wms-semantic" and all mention of multiple semantics for 777 msid, as agreed at the Dallas IETF, March 2015. 779 Addressed a number of review comments from Fleming Andresen and 780 others. 782 Changed the term "m-line" to "media description", since that is the 783 term used in RFC 4566. 785 Tried to make sure this document does not describe the API to the 786 application. 788 B.16. Changes from -09 to -10 790 Addressed review comments from Paul Kyzivat. 792 B.17. Changes from -10 to -11 794 Defined the semantics of multiple MSIDs in a media section to be a 795 MediaStreamTrack present in multiple MediaStreams. 797 Made an explicit note that MediaStreamTracks are unidirectional. 799 Disallowed the option of sending multiple media sections with the 800 same msid (id and appdata identical). 802 B.18. Changes from -11 to -12 804 Added mux-category to the IANA considerations section. 806 B.19. Changes from -12 to -13 808 Modified registration description to delete dependency on -4566-bis 810 B.20. Changes from -13 to -14 812 Addressed nits found in Gen-ART review 814 B.21. Changes from -14 to -15 816 Added the terminology section. Switched from "(RTP) media stream" to 817 "RTP stream" per RFC 7656. 819 Added a mention of random ID generation to the security 820 considerations section. 822 Moved definition pointers for MediaStream and MediaStreamTrack to the 823 "mediacapture-streams" document. 825 Added note that syntactically invalid MSID fields SHOULD be ignored. 827 Various small changes based on review feedback during IESG 828 processing. 830 B.22. Changes from -15 to -16 832 Added the special "-" value that means "no MediaStream". 834 Changed instances of a MediaStreamTrack being "closed" to saying it's 835 "ended", in accordance with WebRTC terminology. 837 B.23. Changes from -16 to -17 839 Added text to allow omitting track identifiers, per JSEP PR #850 841 Author's Address 843 Harald Alvestrand 844 Google 845 Kungsbron 2 846 Stockholm 11122 847 Sweden 849 Email: harald@alvestrand.no