idnits 2.17.1 draft-dawkins-avtcore-sdp-rtp-quic-00.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (28 January 2022) is 819 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'MOQ' ** Downref: Normative reference to an Informational RFC: RFC 7667 ** Downref: Normative reference to an Experimental RFC: RFC 8298 ** Obsolete normative reference: RFC 8843 (Obsoleted by RFC 9143) -- Possible downref: Non-RFC (?) normative reference: ref. 'SDP-attribute-name' -- Possible downref: Non-RFC (?) normative reference: ref. 'SDP-parameters' == Outdated reference: A later version (-04) exists of draft-engelbart-rtp-over-quic-01 == Outdated reference: A later version (-08) exists of draft-huitema-quic-ts-06 == Outdated reference: A later version (-18) exists of draft-ietf-avtcore-rtp-vvc-13 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVTCORE Working Group S. Dawkins 3 Internet-Draft Tencent America LLC 4 Intended status: Standards Track 28 January 2022 5 Expires: 1 August 2022 7 SDP Offer/Answer for RTP using QUIC as Transport 8 draft-dawkins-avtcore-sdp-rtp-quic-00 10 Abstract 12 This document describes these new SDP "proto" attribute values: 13 "QUIC", "QUIC/RTP/SAVP", "QUIC/RTP/AVPF", and "QUIC/RTP/SAVPF", and 14 describes how SDP Offer/Answer can be used to set up an RTP 15 connection using QUIC as a transport protocol. 17 These proto values are necessary to allow the use of QUIC as an 18 underlying transport protocol for applications such as SIP and WebRTC 19 that commonly use SDP as a session signaling protocol to set up RTP 20 connections. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 1 August 2022. 39 Copyright Notice 41 Copyright (c) 2022 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Notes for Readers . . . . . . . . . . . . . . . . . . . . 2 57 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.3. Scope of this document . . . . . . . . . . . . . . . . . 3 59 1.4. Contribution and Discussion Venues for this draft. . . . 3 60 1.5. Assumptions for this document . . . . . . . . . . . . . . 4 61 1.5.1. An Aside on Secure AVP Profiles in an RTP Over QUIC 62 Context . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.6. Open Questions . . . . . . . . . . . . . . . . . . . . . 5 64 2. Identifiers and Attributes . . . . . . . . . . . . . . . . . 6 65 2.1. Protocol Identifiers . . . . . . . . . . . . . . . . . . 6 66 2.1.1. The QUIC proto . . . . . . . . . . . . . . . . . . . 6 67 2.1.2. The QUIC/RTP/SAVP proto . . . . . . . . . . . . . . . 6 68 2.1.3. The QUIC/RTP/AVPF proto . . . . . . . . . . . . . . . 7 69 2.1.4. The QUIC/RTP/SAVPF proto . . . . . . . . . . . . . . 7 70 2.2. A QUIC/RTP/AVPF Offer . . . . . . . . . . . . . . . . . . 7 71 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 3.1. Proto Registrations . . . . . . . . . . . . . . . . . . . 9 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 75 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 6.1. Normative References . . . . . . . . . . . . . . . . . . 10 77 6.2. Informative References . . . . . . . . . . . . . . . . . 12 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 This document describes these new SDP "proto" attribute values: 83 "QUIC", "QUIC/RTP/SAVP", "QUIC/RTP/AVPF", and "QUIC/RTP/SAVPF", and 84 describes how SDP Offer/Answer ([RFC3264]) can be used to set up an 85 RTP ([RFC3550]) connection using QUIC ([RFC9000] and related 86 specifications) as a transport protocol. 88 These proto values are necessary to allow the use of QUIC as an 89 underlying transport protocol for applications such as SIP 90 ([RFC3261]) and WebRTC ([RFC8825]) that commonly use SDP as a session 91 signaling protocol to set up RTP connections. 93 1.1. Notes for Readers 95 (Note to RFC Editor - if this document ever reaches you, please 96 remove this section) 97 This document is intended for publication as a standards-track RFC in 98 the IETF stream, but has not been adopted by any IETF working group, 99 and does not carry any special status within the IETF. 101 1.2. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 ([RFC2119]) ([RFC8174]) when, and only when, they appear in all 107 capitals, as shown here. 109 1.3. Scope of this document 111 This document focuses on the IANA registration and description of the 112 RTP sessions using SDP Offer/Answer, as would be the case for many 113 current RTP applications in common use, such as SIP ([RFC3261]) and 114 WebRTC ([RFC8825]). 116 This document is intended as complementary to drafts such as 117 [I-D.engelbart-rtp-over-quic], which largely focus on RTP/RTCP 118 encapsulation in QUIC, so that the SDP experts can focus on SDP 119 offer/answer aspects, and the RTP experts can focus on RTP/RTCP 120 encapsulation aspects. 122 1.4. Contribution and Discussion Venues for this draft. 124 (Note to RFC Editor - if this document ever reaches you, please 125 remove this section) 127 With the concurrence of the AVTCORE and MMUSIC working group co- 128 chairs, this document should be discussed in the AVTCORE working 129 group, in the same venue where RTP over QUIC proposals are being 130 discussed. When proposals for RTP over SIP have stablized in 131 AVTCORE, this document will be sent to the MMUSIC working group for 132 review by SDP experts, but SDP-specific comments are welcomed at any 133 time. 135 Readers are also invited to open issues and send pull requests with 136 contributed text for this document in the GitHub repository at 137 https://github.com/SpencerDawkins/sdp-rtp-quic. The direct link to 138 the list of issues is https://github.com/SpencerDawkins/sdp-rtp-quic/ 139 issues. 141 1.5. Assumptions for this document 143 This document assumes that for RTP-over-QUIC, it is useful to 144 register these AVP profiles using QUIC, in order to allow existing 145 SIP and RTCWEB RTP applications to migrate more easily to QUIC: 147 * RTP/SAVP ("The Secure Real-time Transport Protocol (SRTP)"), as 148 defined in [RFC3711]. 150 * RTP/AVPF ("Extended RTP Profile for Real-time Transport Control 151 Protocol (RTCP)-Based Feedback (RTP/AVPF)"), as defined in 152 [RFC4585]. 154 * RTP/SAVPF ("Extended Secure RTP Profile for Real-time Transport 155 Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)"), as defined 156 in [RFC5124]. 158 This document assumes that any implementation adding support for RTP- 159 over-QUIC could reasonably also add support for BUNDLE ([RFC8843]) 160 and "rtcp-mux" ([RFC5761]), so these capabiilities are not mentioned 161 further in this document. 163 1.5.1. An Aside on Secure AVP Profiles in an RTP Over QUIC Context 165 Existing RTP implementations have the choice for any given RTP 166 connection to exchange either unencrypted RTP streams (using AVP 167 profiles such as RTP/AVPF) or encrypted RTP streams (using AVP 168 profiles such as RTP/SAVPF). 170 An RTP implementation that uses QUIC as its underlying transport 171 protocol will always send an RTP stream that is encrypted between the 172 two QUIC endpoints, so some RTP implementations may be tempted to 173 exchange unencrypted RTP as an encrypted QUIC payload, reasoning that 174 QUIC protection will be sufficient. 176 One nuance here is that QUIC is heavily encrypted between two QUIC 177 endpoints, with the very minimal exception of the invariant header 178 fields described in [RFC8999], but as described in [RFC7667], many 179 RTP applications use middleboxes for a variety of reasons, and some 180 of these topologies (for example, media translation) require that the 181 middlebox understand the RTP payload. 183 These middleboxes are explictly addressed, and the QUIC cryptographic 184 handshake described in [RFC9001] takes place between the RTP endpoint 185 and the RTP middlebox. After the QUIC cryptographic handshake has 186 succeeded, the RTP middlebox has access to the RTP in the QUIC 187 payload, and can perform whatever translations are appropriate before 188 forwarding the RTP steam to another RTP endpoint. However, if the 189 RTP sender uses one of the "insecure" AVPs, the middlebox does not 190 have any indication that the RTP sender wants the translated RTP 191 stream to be protected by encryption when the middlebox forwards it. 192 That might be fine if the middlebox and RTP endpoint are both using 193 RTP over QUIC, but if the middlebox is performing transport 194 translation as well, the middlebox may also be translating an RTP- 195 over-QUIC stream to RTP-over-UDP. 197 This specification tries to provide that indication by supporting 198 both "secure" and "insecure" AVPs for RTP over QUIC, so the middlebox 199 that is providing back-to-back RTP sessions as described in [RFC7667] 200 can be aware of the sender's desire that a translated RTP stream is 201 encypted regardless of the underlying transport protocol, without 202 always requiring both SRTP and QUIC encryption between each pair of 203 QUIC endpoints for all RTP traffic. That's one strategy, and it's 204 certainly possible that other strategies might be safer, cleaner, 205 and/or more useful. 207 1.6. Open Questions 209 The current contents of Section 2 and Section 3 would allow an 210 existing RTP/RTCP implementation to make a relatively straightforward 211 transition from "RTP over UDP" to "RTP over QUIC datagrams over UDP", 212 and likewise from "RTCP over UDP" to "RTCP over QUIC datagrams over 213 UDP". 215 Although it is still early days for RTP over QUIC, things may not be 216 that straightforward. Just limiting our attention to various 217 proposals for "RTP over QUIC" that have already been discussed on the 218 Media Over QUIC IETF mailing list [MOQ] and in various IETF side 219 meetings, we have seen 221 * a desire to make use of QUIC connection migration in case of path 222 failure between two endpoints 224 * a desire to replace RTP Round Trip Time (RTT) measurement with 225 something like a proposed QUIC extension for timestamps 226 ([I-D.huitema-quic-ts]) that could be used to measure one-way 227 delays 229 * a desire to make use of QUIC streams, potentially with QUIC 230 datagrams in the same QUIC connection 232 * a desire to decouple the RTP state machine and the QUIC state 233 machine, which currently assume they are solely responsible for 234 managing sending rates, without any knowledge of what the other 235 plans to do 237 * a desire to select a media-focused congestion control mechanism 238 such as "Self-Clocked Rate Adaptation for Multimedia", or SCReAM 239 ([RFC8298]), that can be included in QUIC implementations 241 * a desire to use RTP over QUIC in peer-to-peer applications, which 242 likely would require extensions to the QUIC protocol for NAT 243 traversal, at a bare minimum 245 Changes to the SDP signaling in Section 2 and Section 3 may be (and 246 likely would be) needed in order to support any of these desires (or 247 other desires that may surface in the future). 249 2. Identifiers and Attributes 251 As much as possible, these are reused from other specifications, with 252 references to the original definitions. 254 2.1. Protocol Identifiers 256 2.1.1. The QUIC proto 258 The 'QUIC' protocol identifier is similar to the 'UDP' and 'TCP' 259 protocol identifiers in that it only describes the transport 260 protocol, and not the upper-layer protocol. 262 An 'm' line that specifies 'QUIC' MUST further qualify the 263 application-layer protocol using an fmt identifier, such as 264 "QUIC/RTP/AVPF". Media described using an 'm' line containing the 265 'QUIC' protocol identifier are carried using QUIC ([RFC9000]). 267 The following is an update to the ABNF for an 'm' line, as specified 268 by [RFC8866], that defines a new value for the QUIC protocol. 270 media-field = %s"m" "=" media SP port \["/" integer\] 271 SP proto 1*(SP fmt) CRLF 273 m= line parameter parameter value(s) 274 ------------------------------------------------------------------ 275 : (unchanged from {{RFC8866}}) 276 : 'QUIC' 277 : UDP port number 278 : (unchanged from {{RFC8866}}) 280 2.1.2. The QUIC/RTP/SAVP proto 282 The following is an update to the ABNF for an 'm' line, as specified 283 by [RFC8866], that defines a new value for the QUIC/RTP/SAVP 284 protocol. 286 media-field = %s"m" "=" media SP port \["/" integer\] 287 SP proto 1*(SP fmt) CRLF 289 m= line parameter parameter value(s) 290 ------------------------------------------------------------------ 291 : (unchanged from {{RFC8866}}) 292 : 'QUIC/RTP/SAVP' 293 : UDP port number 294 : (unchanged from {{RFC8866}}) 296 2.1.3. The QUIC/RTP/AVPF proto 298 The following is an update to the ABNF for an 'm' line, as specified 299 by [RFC8866], that defines a new value for the QUIC/RTP/AVPF 300 protocol. 302 media-field = %s"m" "=" media SP port \["/" integer\] 303 SP proto 1*(SP fmt) CRLF 305 m= line parameter parameter value(s) 306 ------------------------------------------------------------------ 307 : (unchanged from {{RFC8866}}) 308 : 'QUIC/RTP/AVPF' 309 : UDP port number 310 : (unchanged from {{RFC8866}}) 312 2.1.4. The QUIC/RTP/SAVPF proto 314 The following is an update to the ABNF for an 'm' line, as specified 315 by [RFC8866], that defines a new value for the QUIC/RTP/SAVPF 316 protocol. 318 media-field = %s"m" "=" media SP port \["/" integer\] 319 SP proto 1*(SP fmt) CRLF 321 m= line parameter parameter value(s) 322 ------------------------------------------------------------------ 323 : (unchanged from {{RFC8866}}) 324 : 'QUIC/RTP/SAVPF' 325 : UDP port number 326 : (unchanged from {{RFC8866}}) 328 2.2. A QUIC/RTP/AVPF Offer 330 A complete example of an SDP offer using QUIC/RTP/AVPF might look 331 like: 333 +================================+=================================+ 334 | SDP line | Notes | 335 +================================+=================================+ 336 | v=0 | Same as [RFC8866] | 337 +--------------------------------+---------------------------------+ 338 | o=jdoe 3724394400 3724394405 | Same as [RFC8866] | 339 | IN IP4 198.51.100.1 | | 340 +--------------------------------+---------------------------------+ 341 | s=Call to John Smith | Same as [RFC8866] | 342 +--------------------------------+---------------------------------+ 343 | i=SDP Offer #1 | Same as [RFC8866] | 344 +--------------------------------+---------------------------------+ 345 | u=http://www.jdoe.example.com/ | Same as [RFC8866] | 346 | home.html | | 347 +--------------------------------+---------------------------------+ 348 | e=Jane Doe | Same as [RFC8866] | 349 | jane@jdoe.example.com | | 350 | (mailto:jane@jdoe.example.com) | | 351 +--------------------------------+---------------------------------+ 352 | p=+1 617 555-6011 | Same as [RFC8866] | 353 +--------------------------------+---------------------------------+ 354 | c=IN IP4 198.51.100.1 | Same as [RFC8866] | 355 +--------------------------------+---------------------------------+ 356 | t=0 0 | Same as [RFC8866] | 357 +--------------------------------+---------------------------------+ 358 | m=audio 49170 RTP/AVP 0 | Same as [RFC8866] | 359 +--------------------------------+---------------------------------+ 360 | m=audio 49180 RTP/AVP 0 | Same as [RFC8866] | 361 +--------------------------------+---------------------------------+ 362 | m=video 51372 QUIC/RTP/AVPF 99 | QUIC transport | 363 +--------------------------------+---------------------------------+ 364 | a=setup:passive | will wait for QUIC handshake | 365 | | (setup attribute from | 366 | | [RFC4145]) | 367 +--------------------------------+---------------------------------+ 368 | a=connection:new | don't want to reuse an existing | 369 | | QUIC connection (connection | 370 | | attribute from [RFC4145]) | 371 +--------------------------------+---------------------------------+ 372 | c=IN IP6 2001:db8::2 | Same as [RFC8866] | 373 +--------------------------------+---------------------------------+ 374 | a=rtpmap:99 h266/90000 | H.266 VVC codec | 375 | | [I-D.ietf-avtcore-rtp-vvc] | 376 +--------------------------------+---------------------------------+ 378 Table 1 380 This example is largely based on an example appearing in [RFC8866], 381 Section 5, but is using QUIC/RTP/AVPF to support a newer codec. 383 Because QUIC uses connections for both streams and datagrams, we are 384 reusing two session- and media-level SDP attributes from 385 [SDP-attribute-name] that were defined in [RFC4145] for use with TCP: 386 setup and connection. 388 This example SDP offer might be included in a SIP Invite. 390 3. IANA Considerations 392 This document registers these protocols in the proto registry 393 ([SDP-parameters]). 395 * QUIC (Section 2.1.1) 397 * QUIC/RTP/SAVP (Section 2.1.2) 399 * QUIC/RTP/AVPF (Section 2.1.3) 401 * QUIC/RTP/SAVPF (Section 2.1.4) 403 3.1. Proto Registrations 405 IANA is requested to add these protocols to the Session Description 406 Protocol (SDP) Parameters proto registry ([SDP-parameters]). 408 +=======+================+===========+ 409 | Type | SDP Name | Reference | 410 +=======+================+===========+ 411 | proto | QUIC | RFCXXXX | 412 +-------+----------------+-----------+ 413 | proto | QUIC/RTP/SAVP | RFCXXXX | 414 +-------+----------------+-----------+ 415 | proto | QUIC/RTP/AVPF | RFCXXXX | 416 +-------+----------------+-----------+ 417 | proto | QUIC/RTP/SAVPF | RFCXXXX | 418 +-------+----------------+-----------+ 420 Table 2 422 *Note to the RFC Editor* 424 Please replace "RFCXXXX" with the assigned RFC number, when that is 425 available, and remove this note. 427 4. Security Considerations 429 Security considerations for the QUIC protocol are described in the 430 corresponding section in [RFC9000]. 432 Security considerations for the TLS handshake used to secure QUIC are 433 described in [RFC9001]. 435 Security considerations for SDP are described in the corresponding 436 section in [RFC8866]. 438 Security considerations for SDP offer/answer are described in the 439 cooresponding section in [RFC3264]. 441 5. Acknowledgments 443 My appreciation to the authors of [RFC4145], which served as a model 444 for the initial structure of this document. 446 Thanks to these folks for helping to improve this draft: 448 * Colin Perkins 450 (Your name also could appear here. Please comment and contribute, as 451 per Section 1.4). 453 6. References 455 6.1. Normative References 457 [MOQ] "Moq -- Media over QUIC", n.d., 458 . 460 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 461 Requirement Levels", BCP 14, RFC 2119, 462 DOI 10.17487/RFC2119, March 1997, 463 . 465 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 466 A., Peterson, J., Sparks, R., Handley, M., and E. 467 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 468 DOI 10.17487/RFC3261, June 2002, 469 . 471 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 472 with Session Description Protocol (SDP)", RFC 3264, 473 DOI 10.17487/RFC3264, June 2002, 474 . 476 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 477 Jacobson, "RTP: A Transport Protocol for Real-Time 478 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 479 July 2003, . 481 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 482 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 483 RFC 3711, DOI 10.17487/RFC3711, March 2004, 484 . 486 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 487 "Extended RTP Profile for Real-time Transport Control 488 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 489 DOI 10.17487/RFC4585, July 2006, 490 . 492 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 493 Real-time Transport Control Protocol (RTCP)-Based Feedback 494 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 495 2008, . 497 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 498 Control Packets on a Single Port", RFC 5761, 499 DOI 10.17487/RFC5761, April 2010, 500 . 502 [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, 503 DOI 10.17487/RFC7667, November 2015, 504 . 506 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 507 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 508 May 2017, . 510 [RFC8298] Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation 511 for Multimedia", RFC 8298, DOI 10.17487/RFC8298, December 512 2017, . 514 [RFC8825] Alvestrand, H., "Overview: Real-Time Protocols for 515 Browser-Based Applications", RFC 8825, 516 DOI 10.17487/RFC8825, January 2021, 517 . 519 [RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings, 520 "Negotiating Media Multiplexing Using the Session 521 Description Protocol (SDP)", RFC 8843, 522 DOI 10.17487/RFC8843, January 2021, 523 . 525 [RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: 526 Session Description Protocol", RFC 8866, 527 DOI 10.17487/RFC8866, January 2021, 528 . 530 [RFC8999] Thomson, M., "Version-Independent Properties of QUIC", 531 RFC 8999, DOI 10.17487/RFC8999, May 2021, 532 . 534 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 535 Multiplexed and Secure Transport", RFC 9000, 536 DOI 10.17487/RFC9000, May 2021, 537 . 539 [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 540 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 541 . 543 [SDP-attribute-name] 544 "SDP Parameters - attribute-name", September 2021, 545 . 548 [SDP-parameters] 549 "SDP Parameters - Proto", September 2021, 550 . 553 6.2. Informative References 555 [I-D.engelbart-rtp-over-quic] 556 Ott, J. and M. Engelbart, "RTP over QUIC", Work in 557 Progress, Internet-Draft, draft-engelbart-rtp-over-quic- 558 01, 25 October 2021, 559 . 562 [I-D.huitema-quic-ts] 563 Huitema, C., "Quic Timestamps For Measuring One-Way 564 Delays", Work in Progress, Internet-Draft, draft-huitema- 565 quic-ts-06, 12 September 2021, 566 . 569 [I-D.ietf-avtcore-rtp-vvc] 570 Zhao, S., Wenger, S., Sanchez, Y., Wang, Y., and M. M. 571 Hannuksela, "RTP Payload Format for Versatile Video Coding 572 (VVC)", Work in Progress, Internet-Draft, draft-ietf- 573 avtcore-rtp-vvc-13, 18 November 2021, 574 . 577 [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in 578 the Session Description Protocol (SDP)", RFC 4145, 579 DOI 10.17487/RFC4145, September 2005, 580 . 582 Author's Address 584 Spencer Dawkins 585 Tencent America LLC 586 United States of America 588 Email: spencerdawkins.ietf@gmail.com