idnits 2.17.1 draft-ietf-mmusic-msid-08.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 (February 11, 2015) is 3359 days in the past. Is this intentional? 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 (-26) exists of draft-ietf-rtcweb-jsep-08 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-07 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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 February 11, 2015 5 Expires: August 15, 2015 7 WebRTC MediaStream Identification in the Session Description Protocol 8 draft-ietf-mmusic-msid-08 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 "m-line" and the WebRTC concept of "MediaStream" / 18 "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 August 15, 2015. 46 Copyright Notice 48 Copyright (c) 2015 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. Application to the WEBRTC MediaStream . . . . . . . . . . 4 67 2. The Msid Mechanism . . . . . . . . . . . . . . . . . . . . . 5 68 3. The Msid-Semantic Attribute . . . . . . . . . . . . . . . . . 6 69 4. Generic SDP Offer/Answer Procedures . . . . . . . . . . . . . 7 70 4.1. Generating the Initial Offer . . . . . . . . . . . . . . 7 71 4.2. Answerer Processing of the Offer . . . . . . . . . . . . 7 72 4.3. Generating the Answer . . . . . . . . . . . . . . . . . . 7 73 4.4. Offerer Processing of the Answer . . . . . . . . . . . . 7 74 5. Applying Msid to WebRTC MediaStreams . . . . . . . . . . . . 7 75 5.1. Handling of non-signalled tracks . . . . . . . . . . . . 9 76 5.2. Detailed Offer/Answer Procedures . . . . . . . . . . . . 10 77 5.2.1. Generating the initial offer . . . . . . . . . . . . 10 78 5.2.2. Parsing the initial offer . . . . . . . . . . . . . . 10 79 5.2.3. Generating the answer . . . . . . . . . . . . . . . . 11 80 5.2.4. Offerer processing of the answer . . . . . . . . . . 11 81 5.2.5. Modifying the session . . . . . . . . . . . . . . . . 11 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 83 6.1. Attribute registration in existing registries . . . . . . 11 84 6.2. New registry creation . . . . . . . . . . . . . . . . . . 12 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 89 9.2. Informative References . . . . . . . . . . . . . . . . . 14 90 Appendix A. Design considerations, rejected alternatives . . . . 14 91 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 14 92 B.1. Changes from alvestrand-rtcweb-msid-00 to -01 . . . . . . 15 93 B.2. Changes from alvestrand-rtcweb-msid-01 to -02 . . . . . . 15 94 B.3. Changes from alvestrand-rtcweb-msid-02 to mmusic-msid-00 15 95 B.4. Changes from alvestrand-mmusic-msid-00 to -01 . . . . . . 15 96 B.5. Changes from alvestrand-mmusic-msid-01 to -02 . . . . . . 15 97 B.6. Changes from alvestrand-mmusic-msid-02 to ietf-mmusic-00 16 98 B.7. Changes from mmusic-msid-00 to -01 . . . . . . . . . . . 16 99 B.8. Changes from mmusic-msid-01 to -02 . . . . . . . . . . . 16 100 B.9. Changes from mmusic-msid-02 to -03 . . . . . . . . . . . 16 101 B.10. Changes from mmusic-msid-03 to -04 . . . . . . . . . . . 16 102 B.11. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 17 103 B.12. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 17 104 B.13. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 17 105 B.14. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 17 106 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 108 1. Introduction 110 1.1. Structure Of This Document 112 This document adds a new Session Description Protocol (SDP) [RFC4566] 113 mechanism that can associate application layer identifiers with the 114 binding between media streams, attaching identifiers to the media 115 streams and attaching identifiers to the groupings they form. 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 definition of the msid-semantic field, which 122 gives the possibility of using MSIDs with different semantics in the 123 same SDP message. 125 Section 5 gives the application of the new mechanism for providing 126 necessary semantic information for the association of 127 MediaStreamTracks to MediaStreams in the WebRTC API 128 [W3C.WD-webrtc-20120209]. 130 1.2. Why A New Mechanism Is Needed 132 When media is carried by RTP [RFC3550], each RTP media stream is 133 distinguished inside an RTP session by its SSRC; each RTP session is 134 distinguished from all other RTP sessions by being on a different 135 transport association (strictly speaking, 2 transport associations, 136 one used for RTP and one used for RTCP, unless RTP/RTCP multiplexing 137 [RFC5761] is used). 139 SDP gives a description based on m-lines. According to the model 140 used in [I-D.ietf-rtcweb-jsep], each m-line describes exactly one 141 media source, and if mulitple media sources are carried in an RTP 142 session, this is signalled using BUNDLE 143 [I-D.ietf-mmusic-sdp-bundle-negotiation]; if BUNDLE is not used, each 144 media source is carried in its own RTP session. 146 There exist cases where an application using RTP and SDP needs to 147 signal some relationship between RTP media streams that may be 148 carried in either the same RTP session or different RTP sessions. 149 For instance, there may be a need to signal a relationship between a 150 video track and an audio track, and where the generator of the SDP 151 does not yet know if they will be carried in the same RTP session or 152 different RTP sessions. 154 The SDP grouping framework [RFC5888] can be used to group m-lines. 155 However, there is sometimes the need for an application to specify 156 some application-level information about the association between the 157 m-line and the group. This is not possible using the SDP grouping 158 framework. 160 1.3. Application to the WEBRTC MediaStream 162 The W3C WebRTC API specification [W3C.WD-webrtc-20120209] specifies 163 that communication between WebRTC entities is done via MediaStreams, 164 which contain MediaStreamTracks. A MediaStreamTrack is generally 165 carried using a single SSRC in an RTP session (forming an RTP media 166 stream. The collision of terminology is unfortunate.) There might 167 possibly be additional SSRCs, possibly within additional RTP 168 sessions, in order to support functionality like forward error 169 correction or simulcast. This complication is ignored below. 171 In the RTP specification, media streams are identified using the SSRC 172 field. Streams are grouped into RTP Sessions, and also carry a 173 CNAME. Neither CNAME nor RTP session correspond to a MediaStream. 174 Therefore, the association of an RTP media stream to MediaStreams 175 need to be explicitly signaled. 177 WebRTC defines a mapping (documented in [I-D.ietf-rtcweb-jsep]) where 178 one SDP m-line is used to describe each MediaStreamTrack, and that 179 the BUNDLE mechanism [I-D.ietf-mmusic-sdp-bundle-negotiation] is used 180 to group MediaStreamTracks into RTP sessions. Therefore, the need is 181 to specify the ID of a MediaStreamTrack and its associated 182 MediaStream for each m-line, which can be accomplished with a media- 183 level SDP attribute. 185 This usage is described in Section 5. 187 2. The Msid Mechanism 189 This document defines a new SDP [RFC4566] media-level "msid" 190 attribute. This new attribute allows endpoints to associate RTP 191 media streams that are carried in the same or different m-lines. The 192 attribute also allows application-specific information to the 193 association. 195 The value of the "msid" attribute consists of an identifier and 196 optional application-specific data. 198 The name of the attribute is "msid". 200 The value of the attribute is specified by the following ABNF 201 [RFC5234] grammar: 203 msid-value = msid-id [ SP msid-appdata ] 204 msid-id = 1*64token-char ; see RFC 4566 205 msid-appdata = 1*64token-char ; see RFC 4566 207 An example msid value for a group with the identifier "examplefoo" 208 and application data "examplebar" might look like this: 210 msid:examplefoo examplebar 212 The identifier is a string of ASCII characters that are legal in a 213 "token", consisting of between 1 and 64 characters. It MUST be 214 unique among the identifier values used in the same SDP session. It 215 is RECOMMENDED that it is generated using a random-number generator. 217 Application data is carried on the same line as the identifier, 218 separated from the identifier by a space. 220 The identifier uniquely identifies a group within the scope of an SDP 221 description. 223 There may be multiple msid attributes in a single media description. 224 There may also be multiple media descriptions that have the same 225 value for identifier and application data. 227 Endpoints can update the associations between RTP media streams as 228 expressed by msid attributes at any time; the semantics and 229 restrictions of such grouping and ungrouping are application 230 dependent. 232 3. The Msid-Semantic Attribute 234 A session-level attribute is defined for signaling the semantics 235 associated with an msid grouping. This allows msid groupings with 236 different semantics to coexist. 238 This OPTIONAL attribute gives the group identifier and its group 239 semantic; it carries the same meaning as the ssrc-group-attr of RFC 240 5576 section 4.2, but uses the identifier of the group rather than a 241 list of SSRC values. 243 This attribute MUST be present if "a=msid" is used. 245 An empty list of identifiers is an indication that the sender 246 supports the indicated semantic, but has no msid groupings of the 247 given type in the present SDP. 249 An identifier of "*" is an indication that all "a=msid" lines in the 250 SDP have this specific semantic. If "*" is not used, each msid-id in 251 the SDP MUST appear in one and only one "msid-semantic" line. 253 The name of the attribute is "msid-semantic". 255 The value of the attribute is given by the following ABNF: 257 msid-semantic-value = msid-semantic msid-list 258 msid-semantic = token ; see RFC 4566 259 msid-list = *(" " msid-id) / " *" 261 The semantic field holds values from the IANA registriy "Semantics 262 for the msid-semantic SDP attribute" (which is defined in Section 6). 264 An example msid-semantic might look like this, if a semantic LS was 265 registered by IANA for the same purpose as the existing LS grouping 266 semantic: 268 a=msid-semantic:LS xyzzy forolow 270 This means that the SDP description has two lip sync groups, with the 271 group identifiers xyzzy and forolow, respectively. 273 The msid-semantic attribute can occur more than once, but MUST NOT 274 occur more than once with the same msid-semantic value. 276 4. Generic SDP Offer/Answer Procedures 278 In accordance with guidance on definitions of SDP extensions, this 279 section gives the generic procedures that have to be followed by all 280 implementations of Msid, independent of which semantics they support. 282 Note that the use of msid is not negotiated; each side declares what 283 semantics it uses. This means that an offerer has to be willing and 284 able to take appropriate action if the other side does not wish to 285 use the semantic, and an answerer adding new semantics to an answer 286 has to be willing and able to deal with the offerer not wishing to 287 use that semantic. 289 4.1. Generating the Initial Offer 291 An entity wishing to use an MSID semantic MUST add one or more "msid- 292 semantic" attributes to its session level attributes, indicating the 293 MSID semantic it wishes to have available.. 295 4.2. Answerer Processing of the Offer 297 If an "msid-semantic" attribute is present in the offer, and the 298 answerer wishes to use the indicated semantic, the offerer MUST 299 follow the procedures described for that semantic. 301 4.3. Generating the Answer 303 An entity wishing to use an MSID semantic MUST add one or more "msid- 304 semantic" attributes to its session level attributes, indicating the 305 MSID semantic it wishes to have available. If the answerer does not 306 wish to use one or more of the semantics indicated in the offer, the 307 answerer MUST NOT include "msid-semantic" lines indicating these 308 semantics in the answer. 310 4.4. Offerer Processing of the Answer 312 If an "msid-semantic" attribute is present in the answer, and the 313 offerer wishes to use the indicated semantic, the offerer MUST follow 314 the procedures described for that semantic. The offerer MUST follow 315 the procedures for all semantics that were indicated in its offer and 316 were also present in the answer. 318 5. Applying Msid to WebRTC MediaStreams 320 This section creates a new semantic for use with the framework 321 defined in Section 2, to be used for associating m-lines representing 322 MediaStreamTracks within MediaStreams as defined in 323 [W3C.WD-webrtc-20120209]. 325 In the Javascript API, each MediaStream and MediaStreamTrack has an 326 "id" attribute, which is a DOMString. 328 The semantic token for this semantic is "WMS" (short for WebRTC Media 329 Stream). 331 The value of the "identifier" field in the msid consists of the "id" 332 attribute of a MediaStream, as defined in its WebIDL specification. 334 The value of the "appdata" field in the msid consists of the "id" 335 attribute of a MediaStreamTrack, as defined in its WebIDL 336 specification. 338 If two different m-lines have MSID attributes with the same value for 339 identifier and appdata, it means that these two m-lines are both 340 intended for the same MediaStreamTrack. So far, no semantic for such 341 a mixture have been defined, but this specification does not forbid 342 the practice. 344 When an SDP description is updated, a specific msid "identifier" 345 continues to refer to the same MediaStream, and a specific "appdata" 346 to the same MediaStreamTrack. Once negotiation has completed on a 347 session, there is no memory apart from the currently valid SDP 348 descriptions; if an msid "identifier" value disappears from the SDP 349 and appears in a later negotiation, it will be taken to refer to a 350 new MediaStream. 352 The following are the rules for handling updates of the list of 353 m-lines and their msid values. 355 o When a new msid "identifier" value occurs in the description, the 356 recipient can signal to its application that a new MediaStream has 357 been added. 359 o When a description is updated to have more media sections with the 360 same msid "identifier" value, but different "appdata" values, the 361 recipient can signal to its application that new MediaStreamTracks 362 have been added to the MediaStream. 364 o When a description is updated to no longer list the msid attribute 365 on a specific media description, the recipient can signal to its 366 application that the corresponding MediaStreamTrack has ended. 368 In addition to signaling that the track is closed when its msid 369 attribute disappears from the SDP, the track will also be signaled as 370 being closed when all associated SSRCs have disappeared by the rules 371 of [RFC3550] section 6.3.4 (BYE packet received) and 6.3.5 (timeout), 372 and when the corresponding media section is disabled by setting the 373 port number to zero. Changing the direction of the media section (by 374 setting "sendonly", "recvonly" or "inactive" attributes) will not 375 close the MediaStreamTrack. 377 The association between SSRCs and m-lines is specified in 378 [I-D.ietf-rtcweb-jsep]. 380 5.1. Handling of non-signalled tracks 382 Entities that do not use the WMS semantic will not send "msid- 383 semantic:WMS". This means that there will be some incoming RTP 384 packets that the recipient has no predefined MediaStream id value 385 for. 387 Note that this handling is triggered by incoming RTP packets, not by 388 SDP negotiation. 390 Handling will depend on whether or not the msid-semantic:WMS 391 attribute is present. There are two cases: 393 o No "msid-semantic:WMS" attribute is present. The SDP session is 394 assumed to be a backwards-compatible session. All incoming media, 395 on all m-lines that are part of the SDP session, are assumed to 396 belong to tracks of the same media stream (the "default media 397 stream"). The identifier of this media stream and of the media 398 stream track is a randomly generated string; the WebIDL "label" 399 attribute of this media stream will be set to "Non-WMS stream". 401 o An "msid-semantic:WMS" attribute is present. In this case, the 402 sender implements the WMS semantic, and the packets are either 403 caused by a bug or by timing skew between the arrival of the media 404 packets and the SDP description. These packets MAY be discarded, 405 or they MAY be buffered for a while in order to allow immediate 406 startup of the media stream when the SDP description is updated. 407 The arrival of media packets MUST NOT cause a new MediaStreamTrack 408 to be signaled. 410 If an entity wishing to use the WMS semantic sends a description, it 411 MUST include the msid-semantic:WMS attribute, even if no media 412 streams are sent. This allows us to distinguish between the case of 413 no media streams at the moment and the case of SDP generated by an 414 entity that wishes to use the backwards-compatible mechanism. 416 It follows from the above that the media receiver implmementing the 417 WMS semantic must have the SDP of the other party before it can 418 decide correctly which of the two cases described above applies. RTP 419 media packets that arrive before the remote party's SDP MUST be 420 buffered or discarded, and MUST NOT cause a new MediaStreamTrack to 421 be signalled. 423 It follows from the above that media stream tracks in the "default" 424 media stream cannot be closed by removing the msid attribute; the 425 application must instead signal these as closed when the SSRC 426 disappears according to the rules of RFC 3550 section 6.3.4 and 6.3.5 427 or by disabling the m-line by setting its port to zero. 429 5.2. Detailed Offer/Answer Procedures 431 These procedures are given in terms of RFC 3264-recommended sections. 432 They describe the actions to be taken in terms of MediaStreams and 433 MediaStreamTracks; they do not include event signalling inside the 434 application, which is described in JSEP. 436 They are specifically applicable to the WMS semantic; other semantics 437 will have their own consideration. 439 5.2.1. Generating the initial offer 441 For each media section in the offer, if there is an associated 442 MediaStreamTrack, the offerer adds one "a=msid" attribute to the 443 section for each MediaStream with which the MediaStreamTrack is 444 associated. The "identifier" field of the attribute is set to the 445 WebIDL "id" attribute of the MediaStream, and the "appdata" field is 446 set to the WebIDL "id" attribute of the MediaStreamTrack. 448 The offerer adds an "msid-semantic:WMS" field to the session-level 449 headers, and appends to it either a list of all the identifiers used 450 in the offer, or the single character "*". 452 5.2.2. Parsing the initial offer 454 For each media section in the offer, and for each "a=msid" attribute 455 in the media section where the "msid-id" is associated with the "WMS" 456 semantic, the receiver of the offer will perform the following steps: 458 o Extract the "appdata" field of the "a=msid" attribute 460 o Check if a MediaStreamTrack with the same WebIDL "id" attribute as 461 the "appdata" field already exists, and is not in the "ended" 462 state. If it is not found, create it. 464 o Extract the "identifier" field of the "a=msid" attribte. 466 o Check if a MediaStream with the same WebIDL "id" attribute already 467 exists. If not, create it. 469 o Add the MediaStreamTrack to the MediaStream 471 5.2.3. Generating the answer 473 The answer is generated in exactly the same manner as the offer. 475 This includes adding a "msid-semantic:WMS" attribute in the session- 476 level headers, independent of whether or not such a header was 477 present in the offer. 479 5.2.4. Offerer processing of the answer 481 The answer is processed in exactly the same manner as the offer. 483 5.2.5. Modifying the session 485 On subsequent exchanges, precisely the same procedure as for the 486 initial offer/answer is followed, but with one additional step in the 487 parsing of the offer and answer: 489 o For each MediaStreamTrack that has been created as a result of 490 previous offer/answer exchanges, and is not in the "ended" state, 491 check to see if there is still an "a=msid" attribute in the 492 present SDP whose "appdata" field is the same as the WebIDL "id" 493 attribute of the track. 495 o If no such attribute is found, close the MediaStreamTrack. This 496 will set its state to "ended". 498 6. IANA Considerations 500 6.1. Attribute registration in existing registries 502 This document requests IANA to register the "msid" attribute in the 503 "att-field (media level only)" registry within the SDP parameters 504 registry, according to the procedures of [RFC4566] 506 The required information for "msid" is: 508 o Contact name, email: IETF, contacted via mmusic@ietf.org, or a 509 successor address designated by IESG 511 o Attribute name: msid 513 o Long-form attribute name: Media stream group Identifier 515 o Subject to charset: The attribute value contains only ASCII 516 characters, and is therefore not subject to the charset attribute. 518 o Purpose: The attribute gives an association over a set of m-lines. 519 For example, it can be used to signal the relationship between a 520 WebRTC MediaStream and a set of m-lines. 522 o Appropriate values: The details of appropriate values are given in 523 RFC XXXX. 525 This document requests IANA to register the "msid-semantic" attribute 526 in the "att-field (session level) registry within the SDP parameters 527 registry, according to the same procedures. 529 The required information is: 531 o Contact name, email: IETF, contacted via mmusic@ietf.org, or a 532 successor address designated by IESG 534 o Attribute name: msid-semantic 536 o Long-form attribute name: Msid group semantic identifier 538 o Subject to charset: The attribute value contains only ASCII 539 characters, and is therefore not subject to the charset attribute. 541 o Purpose: The attribute gives the semantics of an association over 542 a set of m-lines. 544 o Appropriate values: The details are given in RFC XXXX. 546 6.2. New registry creation 548 This document requests IANA to create a new registry called 549 "Semantics for the msid-semantic SDP attribute" in the "Session 550 Description Protocol (SDP) Parameters" group. This registry operates 551 on the Expert Review policy [RFC5226]. Usage of the registry is 552 expected to be low, so the expert should feel free to consult widely 553 if a new request ever comes in. 555 This document requests IANA to register the "WMS" semantic within 556 this new registry. 558 The required information is: 560 o Description: WebRTC Media Stream, as given in RFC XXXX. 562 o Token: WMS 564 o Standards track reference: RFC XXXX 565 IANA is requested to replace "RFC XXXX" with the RFC number of this 566 document upon publication. 568 7. Security Considerations 570 An adversary with the ability to modify SDP descriptions has the 571 ability to switch around tracks between media streams. This is a 572 special case of the general security consideration that modification 573 of SDP descriptions needs to be confined to entities trusted by the 574 application. 576 If implementing buffering as mentioned in Section 5.1, the amount of 577 buffering should be limited to avoid memory exhaustion attacks. 579 No other attacks have been identified that depend on this mechanism. 581 8. Acknowledgements 583 This note is based on sketches from, among others, Justin Uberti and 584 Cullen Jennings. 586 Special thanks to Flemming Andreassen, Miguel Garcia, Martin Thomson, 587 Ted Hardie, Adam Roach and Paul Kyzivat for their work in reviewing 588 this draft, with many specific language suggestions. 590 9. References 592 9.1. Normative References 594 [I-D.ietf-rtcweb-jsep] 595 Uberti, J., Jennings, C., and E. Rescorla, "Javascript 596 Session Establishment Protocol", draft-ietf-rtcweb-jsep-08 597 (work in progress), October 2014. 599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 600 Requirement Levels", BCP 14, RFC 2119, March 1997. 602 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 603 Jacobson, "RTP: A Transport Protocol for Real-Time 604 Applications", STD 64, RFC 3550, July 2003. 606 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 607 Description Protocol", RFC 4566, July 2006. 609 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 610 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 611 May 2008. 613 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 614 Specifications: ABNF", STD 68, RFC 5234, January 2008. 616 [W3C.WD-webrtc-20120209] 617 Bergkvist, A., Burnett, D., Jennings, C., and A. 618 Narayanan, "WebRTC 1.0: Real-time Communication Between 619 Browsers", World Wide Web Consortium WD WD- 620 webrtc-20120209, February 2012, 621 . 623 9.2. Informative References 625 [I-D.ietf-mmusic-sdp-bundle-negotiation] 626 Holmberg, C., Alvestrand, H., and C. Jennings, 627 "Negotiating Media Multiplexing Using the Session 628 Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- 629 negotiation-07 (work in progress), April 2014. 631 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 632 Control Packets on a Single Port", RFC 5761, April 2010. 634 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 635 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 637 Appendix A. Design considerations, rejected alternatives 639 This appendix should be deleted before publication as an RFC. 641 One suggested mechanism has been to use CNAME instead of a new 642 attribute. This was abandoned because CNAME identifies a 643 synchronization context; one can imagine both wanting to have tracks 644 from the same synchronization context in multiple MediaStreams and 645 wanting to have tracks from multiple synchronization contexts within 646 one MediaStream (but the latter is impossible, since a MediaStream is 647 defined to impose synchronization on its members). 649 Another suggestion has been to put the msid value within an attribute 650 of RTCP SR (sender report) packets. This doesn't offer the ability 651 to know that you have seen all the tracks currently configured for a 652 media stream. 654 Appendix B. Change log 656 This appendix should be deleted before publication as an RFC. 658 B.1. Changes from alvestrand-rtcweb-msid-00 to -01 660 Added track identifier. 662 Added inclusion-by-reference of draft-lennox-mmusic-source-selection 663 for track muting. 665 Some rewording. 667 B.2. Changes from alvestrand-rtcweb-msid-01 to -02 669 Split document into sections describing a generic grouping mechanism 670 and sections describing the application of this grouping mechanism to 671 the WebRTC MediaStream concept. 673 Removed the mechanism for muting tracks, since this is not central to 674 the MSID mechanism. 676 B.3. Changes from alvestrand-rtcweb-msid-02 to mmusic-msid-00 678 Changed the draft name according to the wishes of the MMUSIC group 679 chairs. 681 Added text indicting cases where it's appropriate to have the same 682 appdata for multiple SSRCs. 684 Minor textual updates. 686 B.4. Changes from alvestrand-mmusic-msid-00 to -01 688 Increased the amount of explanatory text, much based on a review by 689 Miguel Garcia. 691 Removed references to BUNDLE, since that spec is under active 692 discussion. 694 Removed distinguished values of the MSID identifier. 696 B.5. Changes from alvestrand-mmusic-msid-01 to -02 698 Changed the order of the "msid-semantic: " attribute's value fields 699 and allowed multiple identifiers. This makes the attribute useful as 700 a marker for "I understand this semantic". 702 Changed the syntax for "identifier" and "appdata" to be "token". 704 Changed the registry for the "msid-semantic" attribute values to be a 705 new registry, based on advice given in Atlanta. 707 B.6. Changes from alvestrand-mmusic-msid-02 to ietf-mmusic-00 709 Updated terminology to refer to m-lines rather than RTP sessions when 710 discussing SDP formats and the ability of other linking mechanisms to 711 refer to SSRCs. 713 Changed the "default" mechanism to return independent streams after 714 considering the synchronization problem. 716 Removed the space from between "msid-semantic" and its value, to be 717 consistent with RFC 5576. 719 B.7. Changes from mmusic-msid-00 to -01 721 Reworked msid mechanism to be a per-m-line attribute, to align with 722 draft-roach-mmusic-unified-plan. 724 B.8. Changes from mmusic-msid-01 to -02 726 Corrected several missed cases where the word "ssrc" was not changed 727 to "M-line". 729 Added pointer to unified-plan (which should be moved to point to 730 -jsep) 732 Removed suggestion that ssrc-group attributes can be used with "msid- 733 semantic", it is now only the msid-semantic registry. 735 B.9. Changes from mmusic-msid-02 to -03 737 Corrected even more cases where the word "ssrc" was not changed to 738 "M-line". 740 Added the functionality of using an asterisk (*) in the msid-semantic 741 line, in order to remove the need for listing all msids in the msid- 742 semantic line whne only one msid-semantic is in use. 744 Removed some now-unnecessary text. 746 B.10. Changes from mmusic-msid-03 to -04 748 Changed title to reflect focus on WebRTC MediaStreams 750 Added a section on receiver-side media stream control, using the 751 "msid-control" attribute. 753 B.11. Changes from -04 to -05 755 Removed the msid-control section after WG discussion. 757 Removed some text that seemed only to pertain to resolved issues. 759 B.12. Changes from -05 to -06 761 Addressed issues found in Fleming Andreassen's review 763 Referenced JSEP rather than unified-plan for the M-line mapping model 765 Relaxed MSID definition to allow "token-char" in values rather than 766 a-z 0-9 hyphen; tightened ABNF by adding length description to it. 768 Deleted discussion of abandoned alternatives, as part of preparing 769 for publication. 771 Added a "detailed procedures" section to the WMS semantics 772 description. 774 Added IANA registration of the "msid-semantic" attribute. 776 B.13. Changes from -06 to -07 778 Changed terminology from referring to "WebRTC device" to referring to 779 "entities that implement the WMS semantic". 781 Changed names for ABNF constructions based on a proposal by Paul 782 Kyzivat. 784 Included a section on generic offer/answer semantics. 786 B.14. Changes from -07 to -08 788 Removed Appendix B that described the (now obsolete) ssrc-specific 789 usage of MSID. 791 Adopted a restructuring of the IANA section based on a suggestion 792 from Martin Thomson. 794 A number of text and ABNF clarifications based on suggestions from 795 Ted Hardie, Paul Kyzivat and Adam Roach. 797 Changed the "non-signalled track handling" to create a single stream 798 with multiple tracks again, according to discussions at TPAC in 799 November 2014 801 Author's Address 803 Harald Alvestrand 804 Google 805 Kungsbron 2 806 Stockholm 11122 807 Sweden 809 Email: harald@alvestrand.no