idnits 2.17.1 draft-alvestrand-mmusic-simulcast-ssrc-01.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 (July 06, 2019) is 1757 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5888' is defined on line 283, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWEB Working Group H. Alvestrand 3 Internet-Draft Google 4 Intended status: Informational July 06, 2019 5 Expires: January 7, 2020 7 Using SSRC with WebRTC Simulcast 8 draft-alvestrand-mmusic-simulcast-ssrc-01 10 Abstract 12 This document describes a convention for sending "a=ssrc" attributes 13 in SDP together with "a=simulcast" attributes. This allows SFUs that 14 need SSRC information to have this info easily accessible. 16 Given that it is intended as an interim measure, it does not aim for 17 being published as an RFC. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 7, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 55 3. How to represent SSRC information . . . . . . . . . . . . . . 3 56 4. How to request that SSRC information be included . . . . . . 3 57 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 6. Sunsetting the interim measure . . . . . . . . . . . . . . . 4 59 7. Open questions . . . . . . . . . . . . . . . . . . . . . . . 4 60 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 64 10.2. Informative References . . . . . . . . . . . . . . . . . 7 65 Change log . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 A.1. Changes from version -00 to -01 . . . . . . . . . . . . . 7 67 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 In developing the WebRTC specification, the IETF decided on a form of 73 simulcast that doesn't require fixed SSRC allocation, but rather used 74 a combination of SDP tags (a=rid) [I-D.ietf-mmusic-rid] and RTP 75 header extensions (RTPStreamId) [I-D.ietf-avtext-rid] to describe the 76 mapping between simulcast layers and RTP streams. 78 The SDP format is described in [I-D.ietf-mmusic-sdp-simulcast]. 80 This posed a problem for some SFUs, which required information on 81 what SSRCs the incoming streams were going to appear on in order to 82 be configured correctly. 84 This document gives a convention for adding information about SSRCs 85 to the SDP produced by conformant WebRTC implementations in order to 86 make this information available. 88 This document does not specify an Internet standard. It is an 89 interim measure, intended to be useful in the time between the 90 introduction of RID-based simulcast in browsers and the full support 91 of RID-based simulcast by SFUs. 93 2. Conventions and Definitions 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in BCP 98 14 [RFC2119] [RFC8174] when, and only when, they appear in all 99 capitals, as shown here. 101 3. How to represent SSRC information 103 The syntax for representing SSRC information is taken from [RFC5576]. 105 Each media section in the SDP contains one a=ssrc attribute per 106 simulcast stream, formatted as "a=ssrc: cname:". The 107 cname is the sender's single cname as defined in 108 [I-D.ietf-rtcweb-rtp-usage]; carrying some attribute is required by 109 the "a=ssrc" syntax, and sending the cname is compatible with what 110 has been done in other instances. 112 The list of SSRCs used is declared in an attribute with the SIM 113 (Simulcast) semantic, which is registered by this memo. 115 The order of SSRCs in the a=ssrc-group attribute MUST match the order 116 of the rid attributes in the corresponding streams in the "send" part 117 of the a=simulcast: attribute. 119 It is RECOMMENDED that both the a=rid: attributes and the a=ssrc: 120 attributes appear in the same order as the order in the a=simulcast 121 and a=ssrc-group attributes. 123 It is RECOMMENDED not to use RTX with this configuration, since the 124 inclusion of the required declarations for associating RTX SSRCs with 125 their main SSRCs would make the SDP unwieldy and hard to interpret 126 correctly. 128 4. How to request that SSRC information be included 130 If an SFU wishes to request that a browser send SSRC information, it 131 should send an offer containing the line "a=x-please-send-ssrcs", 132 together with a line requesting simulcast: 134 m=video 135 a=simulcast:recv a,b,c 136 a=please-send-ssrcs 138 The SFU can detect whether the request has been honored by looking 139 for a=ssrc attributes in the responding answer. 141 If a Javascript application wishes to request that the browser 142 generate offers containing SSRC, it can include the non-standard 143 attribute "showSsrcInSimulcastOffer" in the RTCPeerConnection 144 constructor: 146 pc = new RTCPeerConnection({showSsrcInSimulcastOffer: true}) 148 It is possible to verify that the request is understood by checking 149 for the presence of this attribute in the RTCPeerConnection 150 parameters: 152 if ('showSsrcInSimulcastOffer' in pc.getConfiguration()) { 153 // the request has been understood correctly 154 } 156 Formally, this amounts to changing the API of a W3C specification, 157 but adding nonstandard attributes to an initialization dictionary has 158 been done before in other contexts; it seems like a relatively 159 harmless thing to do, but should be reviewed in the W3C WEBRTC WG 160 anyway. Publishing a separate extension document in the W3C seems 161 like bureaucratic overkill. 163 5. Example 165 m=video 166 a=simulcast:send hi,mid,low 167 a=rid:hi send 168 a=rid:mid send 169 a=rid:low send 170 a=ssrc-group:SIM 123 456 789 171 a=ssrc:123 cname:foo 172 a=ssrc:456 cname:foo 173 a=ssrc:789 cname:foo 175 6. Sunsetting the interim measure 177 This specification is intended to give SFU authors time to convert to 178 the new mechanism. Since the invocation of this mechanism is 179 explicit, it is easy to check on what the usage is, and emit 180 deprecation warnings; those should probably be emitted from day 1. 182 Once enough time has passed, this mechanism can be removed. 184 7. Open questions 186 NOTE IN DRAFT: The goal is to make this section empty. 188 It's been suggested that it's better to replace the a=ssrc-group: 189 line with new tag fields either on the a=ssrc: lines or the a=rid: 190 lines, thus giving explicit correlation. This, however, breaks the 191 standard format of those lines. Inventing new syntax for an interim 192 solution seems like a Bad Thing. 194 People have asked whether and how this document should be published. 195 If it makes sense to publish it as a historical record, it might make 196 sense to publish as an RFC; it does not make sense to the author to 197 ask for standards track publication. At the moment, it claims that 198 publication is not sought. 200 8. Security Considerations 202 This document describes two existing mechanisms: a=simulcast and 203 a=ssrc-group. Each of these is defined in an RFC with security 204 considerations. 206 The only added attack surface here is the ability to create 207 mismatches between the two lists of simulcast RTP streams, causing 208 different implementations to choose different streams to display. 209 This is a special instance of the general rule that "people who can 210 modify your SDP can mess things up"; normal precautions when passing 211 SDP around should be adequate. 213 9. IANA Considerations 215 This document registers the "SIM" value of "ssrc-group" in the 216 registry titled "Semantics for the "ssrc-group" SDP Attribute", 217 according to the procedures of [RFC5576] section 12.3. That document 218 specifies that registration requires a standards-track document. 220 o Semantics: Simulcast group 222 o Token: SIM 224 o Reference: RFC XXXX 226 This document registers the "please-send-ssrc" attribute in the 227 registry titled "att-field (media level only)" according to the 228 procedures of [RFC4566] section 8.2.4. That document specifies that 229 the registry is of type "specification required". 231 o Contact: Harald Alvestrand, harald@alvestrand.no, +47 73 53 43 26 233 o Attribute name: please-send-ssrc 235 o Long-form attribute name: Please send SSRC 236 o Type of attribute: Media level 238 o Subject to the charset attribute: No 240 o Purpose: Indicates that the sender wishes to receive SSRC 241 information in the form specified in RFC XXXX 243 o Appropriate values: Not relevant 245 RFC Editor: Please replace "RFC XXXX" with the RFC number of this 246 document, if published, and delete this paragraph. 248 If the document succeeds in being transitory in nature, registration 249 may not be needed. 251 10. References 253 10.1. Normative References 255 [I-D.ietf-avtext-rid] 256 Roach, A., Nandakumar, S., and P. Thatcher, "RTP Stream 257 Identifier Source Description (SDES)", draft-ietf-avtext- 258 rid-09 (work in progress), October 2016. 260 [I-D.ietf-mmusic-rid] 261 Roach, A., "RTP Payload Format Restrictions", draft-ietf- 262 mmusic-rid-15 (work in progress), May 2018. 264 [I-D.ietf-mmusic-sdp-simulcast] 265 Burman, B., Westerlund, M., Nandakumar, S., and M. Zanaty, 266 "Using Simulcast in SDP and RTP Sessions", draft-ietf- 267 mmusic-sdp-simulcast-14 (work in progress), March 2019. 269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 270 Requirement Levels", BCP 14, RFC 2119, 271 DOI 10.17487/RFC2119, March 1997, 272 . 274 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 275 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 276 July 2006, . 278 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 279 Media Attributes in the Session Description Protocol 280 (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, 281 . 283 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 284 Protocol (SDP) Grouping Framework", RFC 5888, 285 DOI 10.17487/RFC5888, June 2010, 286 . 288 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 289 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 290 May 2017, . 292 10.2. Informative References 294 [I-D.ietf-rtcweb-rtp-usage] 295 Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time 296 Communication (WebRTC): Media Transport and Use of RTP", 297 draft-ietf-rtcweb-rtp-usage-26 (work in progress), March 298 2016. 300 Change log 302 A.1. Changes from version -00 to -01 304 o Corrected example JS code 306 o Changed group semantic name from FID to SIM 308 o Added IANA registration information for SIM and please-send-ssrc 310 Acknowledgments 312 Many thanks to Amit Hilbuch, Adam Roach, Bernard Aboba, Philipp 313 Hancke and many others who have given input to the design of this 314 mechanism. 316 Author's Address 318 Harald Alvestrand 319 Google 321 Email: harald@alvestrand.no