idnits 2.17.1 draft-ietf-mmusic-msid-04.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 13, 2014) is 3725 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) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-54) exists of draft-ietf-mmusic-sdp-bundle-negotiation-04 Summary: 1 error (**), 0 flaws (~~), 2 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 13, 2014 5 Expires: August 17, 2014 7 WebRTC MediaStream Identification in the Session Description Protocol 8 draft-ietf-mmusic-msid-04 10 Abstract 12 This document specifies a grouping mechanism for RTP media streams 13 that can be used to specify relations between media streams. 15 This mechanism is used to signal the association between the SDP 16 concept of "m-line" and the WebRTC concept of "MediaStream" / 17 "MediaStreamTrack" using SDP signaling. 19 This document is a work item of the MMUSIC WG, whose discussion list 20 is mmusic@ietf.org. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 17, 2014. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Structure Of This Document . . . . . . . . . . . . . . . . 3 64 1.2. Why A New Mechanism Is Needed . . . . . . . . . . . . . . 3 65 1.3. Application to the WEBRTC MediaStream . . . . . . . . . . 4 66 2. The Msid Mechanism . . . . . . . . . . . . . . . . . . . . . . 4 67 3. The Msid-Semantic Attribute . . . . . . . . . . . . . . . . . 5 68 4. Applying Msid to WebRTC MediaStreams . . . . . . . . . . . . . 6 69 4.1. Handling of non-signalled tracks . . . . . . . . . . . . . 7 70 5. WebRTC MediaStream Control . . . . . . . . . . . . . . . . . . 8 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 76 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 77 Appendix A. Design considerations, open questions and and 78 alternatives . . . . . . . . . . . . . . . . . . . . 12 79 Appendix B. Usage with multiple MediaStreams per M-line . . . . . 13 80 B.1. Mechanism design with multiple SSRCs . . . . . . . . . . . 13 81 B.2. Usage with the SSRC attribute . . . . . . . . . . . . . . 14 82 Appendix C. Change log . . . . . . . . . . . . . . . . . . . . . 14 83 C.1. Changes from alvestrand-rtcweb-msid-00 to -01 . . . . . . 14 84 C.2. Changes from alvestrand-rtcweb-msid-01 to -02 . . . . . . 15 85 C.3. Changes from alvestrand-rtcweb-msid-02 to 86 mmusic-msid-00 . . . . . . . . . . . . . . . . . . . . . . 15 87 C.4. Changes from alvestrand-mmusic-msid-00 to -01 . . . . . . 15 88 C.5. Changes from alvestrand-mmusic-msid-01 to -02 . . . . . . 15 89 C.6. Changes from alvestrand-mmusic-msid-02 to 90 ietf-mmusic-00 . . . . . . . . . . . . . . . . . . . . . . 15 91 C.7. Changes from mmusic-msid-00 to -01 . . . . . . . . . . . . 16 92 C.8. Changes from mmusic-msid-01 to -02 . . . . . . . . . . . . 16 93 C.9. Changes from mmusic-msid-02 to -03 . . . . . . . . . . . . 16 94 C.10. Changes from mmusic-msid-03 to -04 . . . . . . . . . . . . 16 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 97 1. Introduction 99 1.1. Structure Of This Document 101 This document adds a new grouping relation between M-lines that can 102 associate application layer identifiers with the binding between 103 media streams, attaching identifiers to the media streams and 104 attaching identifiers to the groupings they form. 106 Section 1.2 gives the background on why a new mechanism is needed. 108 Section 2 gives the definition of the new mechanism. 110 Section 4 gives the application of the new mechanism for providing 111 necessary semantic information for the association of 112 MediaStreamTracks to MediaStreams in the WebRTC API . 114 1.2. Why A New Mechanism Is Needed 116 When media is carried by RTP [RFC3550], each RTP media stream is 117 distinguished inside an RTP session by its SSRC; each RTP session is 118 distinguished from all other RTP sessions by being on a different 119 transport association (strictly speaking, 2 transport associations, 120 one used for RTP and one used for RTCP, unless RTCP multiplexing 121 [RFC5761] is used). 123 SDP gives a description based on m-lines. According to the model 124 used in [I-D.roach-mmusic-unified-plan], each m-line describes 125 exactly one media source, and if mulitple media sources are carried 126 in an RTP session, this is signalled using BUNDLE 127 [I-D.ietf-mmusic-sdp-bundle-negotiation]; if BUNDLE is not used, each 128 media source is carried in its own RTP session. 130 There exist cases where an application using RTP and SDP needs to 131 signal some relationship between RTP media streams that may be 132 carried in either the same RTP session or different RTP sessions. 133 For instance, there may be a need to signal a relationship between a 134 video track and an audio track, and where the generator of the SDP 135 does not yet know if they will be carried in the same RTP session or 136 different RTP sessions. 138 The SDP grouping framework [RFC5888] can be used to group m-lines. 139 However, there is sometimes the need for an application to specify 140 some application-level information about the association between the 141 m-line and the group. This is not possible using the SDP grouping 142 framework. 144 1.3. Application to the WEBRTC MediaStream 146 The W3C WebRTC API specification [W3C.WD-webrtc-20120209] specifies 147 that communication between WebRTC entities is done via MediaStreams, 148 which contain MediaStreamTracks. A MediaStreamTrack is generally 149 carried using a single SSRC in an RTP session (forming an RTP media 150 stream. The collision of terminology is unfortunate.) There might 151 possibly be additional SSRCs, possibly within additional RTP 152 sessions, in order to support functionality like forward error 153 correction or simulcast. This complication is ignored below. 155 In the RTP specification, media streams are identified using the SSRC 156 field. Streams are grouped into RTP Sessions, and also carry a 157 CNAME. Neither CNAME nor RTP session correspond to a MediaStream. 158 Therefore, the association of an RTP media stream to MediaStreams 159 need to be explicitly signaled. 161 The WebRTC work has come to agreement (documented in 162 [I-D.roach-mmusic-unified-plan]) that one M-line is used to describe 163 each MediaStreamTrack, and that the BUNDLE mechanism 164 [I-D.ietf-mmusic-sdp-bundle-negotiation] is used to group 165 MediaStreamTracks into RTP sessions. Therefore, the need is to 166 specify the ID of a MediaStreamTrack and its containing MediaStream 167 for each M-line, which can be accomplished with a media-level 168 attribute. 170 This usage is described in Section 4. 172 2. The Msid Mechanism 174 This document registers a new SDP [RFC4566] media-level "msid" 175 attribute. This new attribute allows endpoints to associate RTP 176 media streams that are carried in the same or different m-lines, as 177 well as allowing application-specific information to the association. 179 The value of the "msid" attribute consists of an identifier and 180 optional application-specific data, according to the following ABNF 181 [RFC5234] grammar: 183 ; "attribute" is defined in RFC 4566. 184 attribute =/ msid-attr 185 msid-attr = "msid:" identifier [ " " appdata ] 186 identifier = token 187 appdata = token 189 An example MSID value for a group with the identifier "examplefoo" 190 and application data "examplebar" might look like this: 192 msid:examplefoo examplebar 194 The identifier is a string of ASCII characters chosen from 0-9, a-z, 195 A-Z and - (hyphen), consisting of between 1 and 64 characters. It 196 MUST be unique among the identifier values used in the same SDP 197 session. It is RECOMMENDED that is generated using a random-number 198 generator. 200 Application data is carried on the same line as the identifier, 201 separated from the identifier by a space. 203 The identifier uniquely identifies a group within the scope of an SDP 204 description. 206 There may be multiple msid attributes on a single m-line. There may 207 also be multiple m-lines that have the same value for identifier and 208 application data. 210 Endpoints can update the associations between RTP media streams as 211 expressed by msid attributes at any time; the semantics and 212 restrictions of such grouping and ungrouping are application 213 dependent. 215 3. The Msid-Semantic Attribute 217 A session-level attribute is defined for signaling the semantics 218 associated with an msid grouping. This allows msid groupings with 219 different semantics to coexist. 221 This OPTIONAL attribute gives the group identifier and its group 222 semantic; it carries the same meaning as the ssrc-group-attr of RFC 223 5576 section 4.2, but uses the identifier of the group rather than a 224 list of SSRC values. 226 This attribute MUST be present if "a=msid" is used. 228 An empty list of identifiers is an indication that the sender 229 understands the indicated semantic, but has no msid groupings of the 230 given type in the present SDP. 232 An identifier of "*" is an indication that all "a=msid" lines in the 233 SDP have this specific semantic. 235 The ABNF of msid-semantic is: 237 attribute =/ msid-semantic-attr 238 msid-semantic-attr = "msid-semantic:" token identifier-list 239 identifier-list = (" " identifier)* / " *" 240 token = 242 The semantic field may hold values from the IANA registriy "Semantics 243 for the msid-semantic SDP attribute" (which is defined by this memo). 245 An example msid-semantic might look like this, if a semantic LS was 246 registered by IANA for the same purpose as the existing LS grouping 247 semantic: 249 a=msid-semantic:LS xyzzy forolow 251 This means that the SDP description has two lip sync groups, with the 252 group identifiers xyzzy and forolow, respectively. 254 4. Applying Msid to WebRTC MediaStreams 256 This section creates a new semantic for use with the framework 257 defined in Section 2, to be used for associating m-lines representing 258 MediaStreamTracks within MediaStreams as defined in 259 [W3C.WD-webrtc-20120209]. 261 The semantic token for this semantic is "WMS" (short for WebRTC Media 262 Stream). 264 The value of the msid corresponds to the "id" attribute of a 265 MediaStream. 267 The appdata for a WebRTC MediaStreamTrack consists of the "id" 268 attribute of a MediaStreamTrack. 270 If two different m-lines have MSID attributes with the same value for 271 identifier and appdata, it means that these two m-lines are both 272 intended for the same MediaStreamTrack. So far, no semantic for such 273 a mixture have been defined, but this specification does not forbid 274 the practice. 276 When an SDP description is updated, a specific msid continues to 277 refer to the same MediaStream. Once negotiation has completed on a 278 session, there is no memory; an msid value that appears in a later 279 negotiation will be taken to refer to a new MediaStream. 281 The following are the rules for handling updates of the list of 282 m-lines and their msid values. 284 o When a new msid value occurs in the description, the recipient can 285 signal to its application that a new MediaStream has been added. 287 o When a description is updated to have more m-lines with the same 288 msid value, but different appdata values, the recipient can signal 289 to its application that new MediaStreamTracks have been added to 290 the media stream. 292 o When a description is updated to no longer list the msid value on 293 a specific m-line, the recipient can signal to its application 294 that the corresponding media stream track has been closed. 296 o When a description is updated to no longer list the msid value on 297 any m-line, the recipient can signal to its application that the 298 media stream has been closed. 300 In addition to signaling that the track is closed when it disappears 301 from the SDP, the track will also be signaled as being closed when 302 all associated SSRCs have disappeared by the rules of [RFC3550] 303 section 6.3.4 (BYE packet received) and 6.3.5 (timeout). 305 The association between SSRCs and m-lines is specified in 306 [I-D.roach-mmusic-unified-plan]. 308 4.1. Handling of non-signalled tracks 310 Non-WebRTC entities will not send msid. This means that there will 311 be some incoming RTP packets that the recipient has no predefined 312 MediaStream id value for. 314 Handling will depend on whether or not any MSIDs are signaled in the 315 relevant m-line(s). There are two cases: 317 o No msid-semantic:WMS attribute is present. The SDP session is 318 assumed to be a backwards-compatible session. All incoming media, 319 on all m-lines that are part of the SDP session, are assumed to 320 belong to independent media streams, each with one track. The 321 identifier of this media stream and of the media stream track is a 322 randomly generated string; the label of this media stream will be 323 set to "Non-WMS stream". 325 o An msid-semantic:WMS attribute is present. In this case, the 326 session is WebRTC compatible, and the packets are either caused by 327 a bug or by timing skew between the arrival of the media packets 328 and the SDP description. These packets MAY be discarded, or they 329 MAY be buffered for a while in order to allow immediate startup of 330 the media stream when the SDP description is updated. The arrival 331 of media packets MUST NOT cause a new MediaStreamTrack to be 332 signaled. 334 If a WebRTC entity sends a description, it MUST include the msid- 335 semantic:WMS attribute, even if no media streams are sent. This 336 allows us to distinguish between the case of no media streams at the 337 moment and the case of legacy SDP generation. 339 It follows from the above that the WebRTC entity must have the SDP of 340 the other party before it can decide correctly whether or not a 341 "default" MediaStream should be created. RTP media packets that 342 arrive before the remote party's SDP MUST be buffered or discarded, 343 and MUST NOT cause a new MediaStreamTrack to be signalled. 345 It follows from the above that media stream tracks in the "default" 346 media stream cannot be closed by signaling; the application must 347 instead signal these as closed when the SSRC disappears according to 348 the rules of RFC 3550 section 6.3.4 and 6.3.5. 350 NOTE IN DRAFT: Previous versions of this memo suggested adding all 351 incoming SSRCs to a single MediaStream. This is problematic because 352 we do not know if the SSRCs are synchronized or not before we learn 353 the CNAME of the SSRCs, which only happens when an RTCP packet 354 arrives. How to identify a non-WMS stream is still open for 355 discussion - including whether it's necessary to do so. Using the 356 stream label seems like an easy thing to do for debuggability - it's 357 not signalled, and is intended for human consumption anyway. 359 Another alternative is to group the incoming media streams based on 360 CNAME; this preseerves the synchronization semantics of CNAME, but 361 means that one cannot signal the MediaStreamTrack before the CNAME of 362 the SSRC is known (which will happen only on arrival of the relevant 363 RTCP packet). 365 5. WebRTC MediaStream Control 367 A need has been identified for signalling from a receiver to a sender 368 some information about the receiver's desires for the sender to take 369 action on a MediaStream track. 371 This section describes such a mechanism. It is intended to be used 372 for streams that are signalled using the semantics in section 373 Section 4. 375 This mechanism consists of a single new field, "msid-control", which 376 can have the following values: 378 o msid-control: enable - the receiver positively acknowledges that 379 it wants the content of this media stream track. This has the 380 same semantics as leaving out the field altogether, but is 381 specified for completeness. 383 o msid-control: disable - the receiver desires that the sender stops 384 sending media on this track, but allows for a later round of 385 negotiation to resume transmission. The sender and receiver are 386 expected to continue including the corresponding SSRCs in RTCP 387 reports, keeping the information on the SSRCs from timing out. 389 o msid-control: stop - the receiver desires that the sender stops 390 sending media on this track, and guarantees that it will never ask 391 for data to be sent on this track again. The sender is expected 392 to stop reporting on the corresponding SSRCs, and MAY send a BYE 393 message when it stops sending. 395 o msid-control: reject - the exact same semantics as for msid- 396 control: stop apply, but this form is only used if the stream has 397 never been enabled. The intended use is for support of rejecting 398 a MediaStream, rather than stopping it (such a function has not 399 been specified so far). 401 The msid-control field is significant only for the direction from the 402 receiver to the sender; if a single m-line is used for MediaStreams 403 in both directions, only the streams sent by the receiver of the SDP 404 message will be affected. 406 If the MediaStream in both directions is cancelled by msid-control: 407 stop or msid-control: reject, the m-line MAY be disabled by setting 408 its port number to 0. If there is a MediaStream in use in either 409 direction, whether it's enabled or disabled, the m-line port number 410 MUST NOT be set to 0. 412 6. IANA Considerations 414 This document requests IANA to register the "msid" attribute and the 415 "msid-control" attribute in the "att-field (media level only)" 416 registry within the SDP parameters registry, according to the 417 procedures of [RFC4566] 419 The required information for "msid" is: 421 o Contact name, email: IETF, contacted via mmusic@ietf.org, or a 422 successor address designated by IESG 424 o Attribute name: msid 426 o Long-form attribute name: Media stream group Identifier 428 o The attribute value contains only ASCII characters, and is 429 therefore not subject to the charset attribute. 431 o The attribute gives an association over a set of m-lines. It can 432 be used to signal the relationship between a WebRTC MediaStream 433 and a set of m-lines. 435 o The details of appropriate values are given in RFC XXXX. 437 The required information for "msid-control" is: 439 o Contact name, email: IETF, contacted via mmusic@ietf.org, or a 440 successor address designated by IESG 442 o Attribute name: msid-control 444 o Long-form attribute name: Media stream control 446 o The attribute value contains only ASCII characters, and is 447 therefore not subject to the charset attribute. 449 o The attribute states the desires of a recipient with regards to a 450 WebRTC MediaStream in the context of an m-line. 452 o The details of appropriate values are given in RFC XXXX. 454 This document requests IANA to create a new registry called 455 "Semantics for the msid-semantic SDP attribute", which should have 456 exactly the same rules as for the "Semantics for the ssrc-group SDP 457 attribute" registry (Expert Review), and to register the "WMS" 458 semantic within this new registry. 460 The required information is: 462 o Description: WebRTC Media Stream, as given in RFC XXXX. 464 o Token: WMS 466 o Standards track reference: RFC XXXX 468 IANA is requested to replace "RFC XXXX" with the RFC number of this 469 document upon publication. 471 7. Security Considerations 473 An adversary with the ability to modify SDP descriptions has the 474 ability to switch around tracks between media streams. This is a 475 special case of the general security consideration that modification 476 of SDP descriptions needs to be confined to entities trusted by the 477 application. 479 If implementing buffering as mentioned in section Section 4.1, the 480 amount of buffering should be limited to avoid memory exhaustion 481 attacks. 483 No other attacks that are relevant to the browser's security have 484 been identified that depend on this mechanism. 486 8. Acknowledgements 488 This note is based on sketches from, among others, Justin Uberti and 489 Cullen Jennings. 491 Special thanks to Miguel Garcia and Paul Kyzivat for their work in 492 reviewing this draft, with many specific language suggestions. 494 9. References 496 9.1. Normative References 498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 499 Requirement Levels", BCP 14, RFC 2119, March 1997. 501 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 502 Jacobson, "RTP: A Transport Protocol for Real-Time 503 Applications", STD 64, RFC 3550, July 2003. 505 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 506 Description Protocol", RFC 4566, July 2006. 508 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 509 Specifications: ABNF", STD 68, RFC 5234, January 2008. 511 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 512 Media Attributes in the Session Description Protocol 513 (SDP)", RFC 5576, June 2009. 515 [W3C.WD-webrtc-20120209] 516 Bergkvist, A., Burnett, D., Jennings, C., and A. 517 Narayanan, "WebRTC 1.0: Real-time Communication Between 518 Browsers", World Wide Web Consortium WD WD-webrtc- 519 20120209, February 2012, 520 . 522 9.2. Informative References 524 [I-D.ietf-mmusic-sdp-bundle-negotiation] 525 Holmberg, C., Alvestrand, H., and C. Jennings, 526 "Multiplexing Negotiation Using Session Description 527 Protocol (SDP) Port Numbers", 528 draft-ietf-mmusic-sdp-bundle-negotiation-04 (work in 529 progress), June 2013. 531 [I-D.roach-mmusic-unified-plan] 532 Roach, A., Uberti, J., and M. Thomson, "A Unified Plan for 533 Using SDP with Large Numbers of Media Flows", 534 draft-roach-mmusic-unified-plan-00 (work in progress), 535 July 2013. 537 [I-D.westerlund-avtcore-multiplex-architecture] 538 Westerlund, M., Perkins, C., and H. Alvestrand, 539 "Guidelines for using the Multiplexing Features of RTP", 540 draft-westerlund-avtcore-multiplex-architecture-03 (work 541 in progress), February 2013. 543 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 544 Control Packets on a Single Port", RFC 5761, April 2010. 546 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 547 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 549 Appendix A. Design considerations, open questions and and alternatives 551 This appendix should be deleted before publication as an RFC. 553 One suggested mechanism has been to use CNAME instead of a new 554 attribute. This was abandoned because CNAME identifies a 555 synchronization context; one can imagine both wanting to have tracks 556 from the same synchronization context in multiple MediaStreams and 557 wanting to have tracks from multiple synchronization contexts within 558 one MediaStream (but the latter is impossible, since a MediaStream is 559 defined to impose synchronization on its members). 561 Another suggestion has been to put the msid value within an attribute 562 of RTCP SR (sender report) packets. This doesn't offer the ability 563 to know that you have seen all the tracks currently configured for a 564 media stream. 566 There has been a suggestion that this mechanism could be used to mute 567 tracks too. This is not done at the moment. 569 Discarding of incoming data when the SDP description isn't updated 570 yet (section 3) may cause clipping. However, the same issue exists 571 when crypto keys aren't available. Input sought. 573 There's been a suggestion that acceptable SSRCs should be signaled in 574 a response, giving a recipient the ability to say "no" to certain 575 SSRCs. This is not supported in the current version of this 576 document. 578 Appendix B. Usage with multiple MediaStreams per M-line 580 This appendix is included to document the usage of msid as a source- 581 specific attribute. Prior to the acceptance of the Unified Plan 582 document, some implementations used this mechanism to distinguish 583 between multiple MediaStreamTracks that were carried in the same 584 M-line. 586 It reproduces some of the original justification text for this 587 mechanism that is not relevant when Unified Plan is used. 589 B.1. Mechanism design with multiple SSRCs 591 When media is carried by RTP [RFC3550], each RTP media stream is 592 distinguished inside an RTP session by its SSRC; each RTP session is 593 distinguished from all other RTP sessions by being on a different 594 transport association (strictly speaking, 2 transport associations, 595 one used for RTP and one used for RTCP, unless RTCP multiplexing 596 [RFC5761] is used). 598 There exist cases where an application using RTP and SDP needs to 599 signal some relationship between RTP media streams that may be 600 carried in either the same RTP session or different RTP sessions. 601 For instance, there may be a need to signal a relationship between a 602 video track in one RTP session and an audio track in another RTP 603 session. In traditional SDP, it is not possible to signal that these 604 two tracks should be carried in one session, so they are carried in 605 different RTP sessions. 607 Traditionally, SDP was used to describe the RTP sessions, with one 608 m-line being used to describe each RTP session. With the advent of 609 extensions like BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation], this 610 association may be more complex, with multiple m-lines being used to 611 describe one RTP session; the rest of this document therefore talks 612 about m-lines, not RTP sessions, when describing the signalling 613 mechanism. 615 The SSRC grouping mechanism ("a=ssrc-group") [RFC5576] can be used to 616 associate RTP media streams when those RTP media streams are 617 described by the same m-line. The semantics of this mechanism 618 prevent the association of RTP media streams that are spread across 619 different m-lines. 621 The SDP grouping framework [RFC5888] can be used to group m-lines. 622 When an m-line describes one and only one RTP media stream, it is 623 possible to associate RTP media streams across different m-lines. 624 However, if an m-line has multiple RTP media streams, using multiple 625 SSRCs, the SDP grouping framework cannot be used for this purpose. 627 There are use cases (some of which are discussed in 628 [I-D.westerlund-avtcore-multiplex-architecture] ) where neither of 629 these approaches is appropriate; In those cases, a new mechanism is 630 needed. 632 In addition, there is sometimes the need for an application to 633 specify some application-level information about the association 634 between the SSRC and the group. This is not possible using either of 635 the frameworks above. 637 B.2. Usage with the SSRC attribute 639 When the MSID attribute was used with the SSRC attribute, it had to 640 be registered in the "Attribute names (source level)" registry rather 641 than the "Attribute names (media level only)" registry, and the msid 642 line was prefixed with "a=ssrc: ". Apart from that, usage of 643 the attribute with SSRC-bound flows was identical with the current 644 proposal. 646 Appendix C. Change log 648 This appendix should be deleted before publication as an RFC. 650 C.1. Changes from alvestrand-rtcweb-msid-00 to -01 652 Added track identifier. 654 Added inclusion-by-reference of draft-lennox-mmusic-source-selection 655 for track muting. 657 Some rewording. 659 C.2. Changes from alvestrand-rtcweb-msid-01 to -02 661 Split document into sections describing a generic grouping mechanism 662 and sections describing the application of this grouping mechanism to 663 the WebRTC MediaStream concept. 665 Removed the mechanism for muting tracks, since this is not central to 666 the MSID mechanism. 668 C.3. Changes from alvestrand-rtcweb-msid-02 to mmusic-msid-00 670 Changed the draft name according to the wishes of the MMUSIC group 671 chairs. 673 Added text indicting cases where it's appropriate to have the same 674 appdata for multiple SSRCs. 676 Minor textual updates. 678 C.4. Changes from alvestrand-mmusic-msid-00 to -01 680 Increased the amount of explanatory text, much based on a review by 681 Miguel Garcia. 683 Removed references to BUNDLE, since that spec is under active 684 discussion. 686 Removed distinguished values of the MSID identifier. 688 C.5. Changes from alvestrand-mmusic-msid-01 to -02 690 Changed the order of the "msid-semantic: " attribute's value fields 691 and allowed multiple identifiers. This makes the attribute useful as 692 a marker for "I understand this semantic". 694 Changed the syntax for "identifier" and "appdata" to be "token". 696 Changed the registry for the "msid-semantic" attribute values to be a 697 new registry, based on advice given in Atlanta. 699 C.6. Changes from alvestrand-mmusic-msid-02 to ietf-mmusic-00 701 Updated terminology to refer to m-lines rather than RTP sessions when 702 discussing SDP formats and the ability of other linking mechanisms to 703 refer to SSRCs. 705 Changed the "default" mechanism to return independent streams after 706 considering the synchronization problem. 708 Removed the space from between "msid-semantic" and its value, to be 709 consistent with RFC 5576. 711 C.7. Changes from mmusic-msid-00 to -01 713 Reworked msid mechanism to be a per-m-line attribute, to align with 714 [I-D.roach-mmusic-unified-plan] 716 C.8. Changes from mmusic-msid-01 to -02 718 Corrected several missed cases where the word "ssrc" was not changed 719 to "M-line". 721 Added pointer to unified-plan (which should be moved to point to 722 -jsep) 724 Removed suggestion that ssrc-group attributes can be used with "msid- 725 semantic", it is now only the msid-semantic registry. 727 C.9. Changes from mmusic-msid-02 to -03 729 Corrected even more cases where the word "ssrc" was not changed to 730 "M-line". 732 Added the functionality of using an asterisk (*) in the msid-semantic 733 line, in order to remove the need for listing all msids in the msid- 734 semantic line whne only one msid-semantic is in use. 736 Removed some now-unnecessary text. 738 C.10. Changes from mmusic-msid-03 to -04 740 Changed title to reflect focus on WebRTC MediaStreams 742 Added a section on receiver-side media stream control, using the 743 "msid-control" attribute. 745 Author's Address 747 Harald Alvestrand 748 Google 749 Kungsbron 2 750 Stockholm, 11122 751 Sweden 753 Email: harald@alvestrand.no