idnits 2.17.1 draft-engelbart-rtp-over-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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. 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 (12 July 2021) is 1018 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-quic-datagram-02 == Outdated reference: A later version (-08) exists of draft-huitema-quic-ts-05 ** Obsolete normative reference: RFC 8843 (Obsoleted by RFC 9143) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Ott 3 Internet-Draft M. Engelbart 4 Intended status: Informational Technical University Munich 5 Expires: 13 January 2022 12 July 2021 7 RTP over QUIC 8 draft-engelbart-rtp-over-quic-00 10 Abstract 12 This document specifies a minimal mapping for encapsulating RTP and 13 RTCP packets within QUIC. It also discusses how to leverage state 14 from the QUIC implementation in the endpoints to reduce the exchange 15 of RTCP packets. 17 Discussion Venues 19 This note is to be removed before publishing as an RFC. 21 Discussion of this document takes place on the mailing list (), which 22 is archived at . 24 Source for this draft and an issue tracker can be found at 25 https://github.com/mengelbart/rtp-over-quic-draft. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 13 January 2022. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 62 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Local Interfaces . . . . . . . . . . . . . . . . . . . . . . 5 64 4.1. QUIC Interface . . . . . . . . . . . . . . . . . . . . . 5 65 4.2. Congestion Controller Interface . . . . . . . . . . . . . 5 66 4.3. Codec Interface . . . . . . . . . . . . . . . . . . . . . 6 67 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 6 68 6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7 69 7. SDP Signalling . . . . . . . . . . . . . . . . . . . . . . . 9 70 8. Used RTP/RTCP packet types . . . . . . . . . . . . . . . . . 11 71 9. Enhancements . . . . . . . . . . . . . . . . . . . . . . . . 12 72 10. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 10.1. Impact of Connection Migration . . . . . . . . . . . . . 12 74 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 13.1. Normative References . . . . . . . . . . . . . . . . . . 12 78 13.2. Informative References . . . . . . . . . . . . . . . . . 15 79 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 82 1. Introduction 84 The Real-time Transport Protocol (RTP) [RFC3550] is generally used to 85 carry real-time media for conversational media sessions, such as 86 video conferences, across the Internet. Since RTP requires real-time 87 delivery and is tolerant to packet losses, the default underlying 88 transport protocol has been UDP, recently with DTLS on top to secure 89 the media exchange and occasionallly TCP (and possibly TLS) as 90 fallback. With the advent of QUIC and, most notably, its unreliable 91 DATAGRAM extension, another secure transport protocol becomes 92 avaialble. QUIC and its DATAGRAMs combine desirable properties for 93 real-time traffic (e.g., no unnecessary retransmissions, avoiding 94 head-of-line blocking) with a secure end-to-end transport that is 95 also expected to work well through NATs and firewalls. 97 Moreover, with QUIC's multiplexing capabilities, reliable and 98 unreliable transport connections as, e.g., needed for WebRTC, can be 99 established with only a single port used at either end of the 100 connection. This document defines a mapping of how to carry RTP over 101 QUIC. The focus is on RTP and RTCP packet mapping and on reducing 102 the amount of RTCP traffic by leveraging state information readily 103 available within a QUIC endpoint. This document also briefly touches 104 upon how to signal media over QUIC using the Session Description 105 Protocol (SDP) [RFC8866]. 107 The scope of this document is limited to unicast RTP/RTCP. 109 Note that this draft is similar in spirit to but differs in numerous 110 ways from [QRT]. 112 2. Terminology and Notation 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in BCP 117 14 [RFC2119] [RFC8174] when, and only when, they appear in all 118 capitals, as shown here. 120 The following terms are used: 122 Congestion Controller: QUIC specifies a congestion controller in 123 Section 7 of [RFC9002] but the specific requirements for 124 interactive real-time media, lead to the development of dedicated 125 congestion control algorithms. The term congestion controller in 126 this document refers to these alorithms which are dedicated to 127 real-time applications and may be used next to or instead of the 128 congestion controller specified by [RFC9002]. 130 Datagram: Datagrams exist in UDP as well as in QUICs unreliable 131 datagram extension. If not explicitly noted differently, the term 132 datagram in this document refers to a QUIC Datagram as defined in 133 [QUIC-DATAGRAM]. 135 Endpoint: A QUIC server or client that participates in an RTP over 136 QUIC session. 138 Frame: A QUIC frame as defined in [RFC9000]. 140 Media Encoder: An entity that is used by an application to produce a 141 stream of encoded media, which can be packetized in RTP packets to 142 be transmitted over QUIC. 144 Receiver: An endpoint that receives media in RTP packets and may 145 send or receive RTCP packets. 147 Sender: An endpoint sends media in RTP packets and may send or 148 receive RTCP packets. 150 Packet diagrams in this document use the format defined in 151 Section 1.3 of [RFC9000] to illustrate the order and size of fields. 153 3. Protocol Overview 155 This document introduces a mapping of the Real-time Transport 156 Protocol (RTP) to the QUIC transport protocol. QUIC supports two 157 transport methods: reliable streams and unreliable datagrams 158 [RFC9000], [QUIC-DATAGRAM]. RTP over QUIC uses unreliable QUIC 159 datagrams to transport real-time data. 161 [RFC3550] specifies that RTP sessions need to be transmitted on 162 different transport addresses to allow multiplexing between them. 163 RTP over QUIC uses a different approach, in order to leverage the 164 advantages of QUIC connections without managing a separate QUIC 165 connection per RTP session. QUIC does not provide demultiplexing 166 between different flows on datagrams, but suggests that an 167 application implements a demultiplexing mechanism if it is required. 168 An example of such a mechanism are flow identifiers prepended to each 169 datagram frame as described in [H3-DATAGRAM]. RTP over QUIC uses a 170 flow identifier as a replacement for network address and port number, 171 to multiplex many RTP sessions over the same QUIC connection. 173 A congestion controller can be plugged in, to adapt the media bitrate 174 to the available bandwidth. This document does not mandate any 175 congestion control algorithm, some examples include Network-Assisted 176 Dynamic Adaptation (NADA) [RFC8698] and Self-Clocked Rate Adaptation 177 for Multimedia (SCReAM) [RFC8298]. These congestion control 178 algorithms require some feedback about the performance of the network 179 in order to calculate target bitrates. Traditionally this feedback 180 is generated at the receiver and sent back to the sender via RTCP. 181 Since QUIC also collects some metrics about the networks performance, 182 these metrics can be used to generate the required feedback at the 183 sender-side and provide it to the congestion controller, to avoid the 184 additional overhead of the RTCP stream. 186 *Editor's note:* Should the congestion controller work 187 independently from the congestion controller used in QUIC, because 188 the QUIC connection can simultaneously be used for other data 189 streams, that need to be congestion controlled, too? 191 4. Local Interfaces 193 RTP over QUIC requires different components like QUIC 194 implementations, congestion controllers and media encoders to work 195 together. The interfaces of these components have to fulfill certain 196 requirements which are described in this section. 198 4.1. QUIC Interface 200 If the used QUIC implementation is not directly incorporated into the 201 RTP over QUIC mapping implementation, it has to fulfill the following 202 interface requirements. The QUIC implementation MUST support QUICs 203 unreliable datagram extension and it MUST provide a way to signal 204 acknowledgements or losses of QUIC datagrams to the application. 205 Since datagram frames cannot be fragmented, the QUIC implementation 206 MUST provide a way to query the maximum datagram size, so that an 207 application can create RTP packets that always fit into a QUIC 208 datagram frame. 210 Additionally, a QUIC implementation MUST expose the recorded RTT 211 statistics as described in Section 5 of [RFC9002] to the application. 212 These statistics include the minium observed RTT over a period of 213 time ("min_rtt"), exponentially-weighted moving average 214 ("smoothed_rtt") and the mean deviation ("rtt_var"). These values 215 are necessary to perform congestion control as explained in 216 Section 4.2. 218 Section 7.1 of [RFC9002] also specifies how QUIC treats Explicit 219 Congestion Notifications (ECN) if it is supported by the network 220 path. If ECN counts can be exported from a QUIC implementation, 221 these may be used to improve congestion control, too. 223 4.2. Congestion Controller Interface 225 There are different congestion control algorithms proposed by RMCAT 226 to implement application layer congestion control for real-time 227 communications. To estimate the currently available bandwidth, these 228 algorithms keep track of the sent packets and typically require a 229 list of successfully delivered packets together with the timestamps 230 at which they were received by a receiver. The bandwidth estimation 231 can then be used to decide, whether the media encoder can be 232 configured to produce output at a higher or lower rate. 234 A congestion controller used for RTP over QUIC should be able to 235 compute an adequate bandwidth estimation using the following inputs: 237 * "t_current": A current timestamp 238 * "pkt_status_list": A list of RTP packets that were acknowledged by 239 the receiver 241 * "pkt_delay_list": For each acknowledged RTP packet, a delay 242 between the sent- and receive-timestamps of the packet 244 * The RTT estimations calculated by QUIC as described in Section 5 245 of [RFC9002]: 247 - "min_rtt": The miminum RTT observed by QUIC over a period of 248 time 250 - "smoothed_rtt": An exponentially-weighted moving average of the 251 observed RTT values 253 - "rtt_var": The mean deviation in the observed RTT values 255 * "ecn": Optionally ECN marks may be used, if supported by the 256 network and exposed by the QUIC implementation. 258 A congestion controller MUST expose a "target_bitrate" to which the 259 encoder should be configured to fully utilize the available 260 bandwidth. 262 It is assumed that the congestion controller provides a pacing 263 mechanism to determine when a packet can be send and to avoid bursts. 264 All of the currently proposed congestion control algorithms for real- 265 time communications provide such a pacing mechanism. The use of 266 congestion controllers which don't provide a pacing mechanism is out 267 of scope of this document. 269 4.3. Codec Interface 271 An application is expected to adapt the media bitrate to the observed 272 available bandwidth by setting the media encoder to the 273 "target_bitrate" that is computed by the congestion controller. 274 Thus, the media encoder needs to offer a way to update its bitrate 275 accordingly. An RTP over QUIC implementation can either expose the 276 most recent "target_bitrate" produced by the congestion controller to 277 the application, or accept a callback from the application, which 278 updates the encoder bitrate whenever the congestion controller 279 updates the "target_bitrate". 281 5. Packet Format 283 All RTP and RTCP packets MUST be sent in QUIC datagram frames with 284 the following format: 286 Datagram Payload { 287 Flow Identifier (i), 288 RTP/RTCP Packet (..) 289 } 291 Figure 1: Datagram Payload Format 293 For multiplexing RTP sessions on the same QUIC connection, each RTP/ 294 RTCP packet is prefixed with a flow identifier. This flow identifier 295 serves as a replacement for using different transport addresses per 296 session. A flow identifier is a QUIC variable length integer which 297 must be unique per stream. 299 RTP and RTCP packets of a single RTP session MAY be sent using the 300 same flow identifier (following the procedures defined in [RFC5761], 301 or they MAY be sent using different flow identifiers. The respective 302 mode of operation MUST be indicated using the appropriate signaling, 303 e.g., when using SDP as discussed in Section 7. 305 RTP and RTCP packets of different RTP sessions MUST be sent using 306 different flow identifiers. 308 Differentiating RTP/RTCP datagrams of different RTP sessions from 309 non-RTP/RTCP datagrams is the responsibility of the application by 310 means of appropriate use of flow identifiers and the corresponding 311 signaling. 313 Senders SHOULD consider the header overhead associated with QUIC 314 datagrams and ensure that the RTP/RTCP packets including their 315 payloads, QUIC, and IP headers will fit into path MTU. 317 6. Protocol Operation 319 This section describes how senders and receivers can exchange RTP and 320 RTCP packets using QUIC. While the receiver side is very simple, the 321 sender side has to keep track of sent packets and corresponding 322 acknowledgements to implement congestion control. 324 RTP/RTCP packets that are submitted to an RTP over QUIC 325 implementation are buffered in a queue. The congestion controller 326 defines the rate at which the next packet is dequeued and sent over 327 the QUIC connection. Before a packet is sent, it is prefixed with 328 the flow identifier described in Section 5 and encapsulated in a QUIC 329 datagram. 331 The implementation has to keep track of sent RTP packets in order to 332 build the feedback for a congestion controller described in 333 Section 4.2. Each sent RTP packet is mapped to the datagram in which 334 it was sent over QUIC. When the QUIC implementation signals an 335 acknowledgement for a specific datagram, the packet that was sent in 336 this datagram is marked as received. Together with the received 337 mark, an estimation of the delay at which the packet was received by 338 the peer can be stored. Assuming the RTT is divided equally between 339 the link from the sender to the receiver and the link back to the 340 sender, this estimation can be calculated using the RTT exposed by 341 QUIC divided by two. This mapping can later be used to create the 342 "pkt_status_list" and the "pkt_delay_list" as described in 343 Section 4.2. 345 In a regular interval, the "pkt_status_list" and the "pkt_delay_list" 346 MUST be passed to the congestion controller together with the current 347 timestamp "t_current" and the RTT statistics "min_rtt", 348 "smoothed_rtt" and "rtt_var". If available, the feedback MAY also 349 contain the ECN marks. 351 The feedback report can be passed to the congestion controller at a 352 frequency specified by the used algorithm. 354 The congestion controller regularly outputs the "target_bitrate", 355 which is forwarded to the encoder using the interface described in 356 Section 4.3. 358 +------------+ Media +-------------+ 359 | Encoder |------->| Application | 360 | | | | 361 +------------+ +-------------+ 362 ^ | 363 | | 364 | Set RTP/ | 365 | Target RTCP | 366 | bitrate | 367 | v Target 368 | +-------------+ Bitrate +-------------+ 369 +---------------| RTP over |<----------| Congestion | 370 | QUIC | Feedback | Controller | 371 +-------------+---------->+-------------+ 372 | ^ 373 Flow ID | | Datagram 374 prefixed | | ACK/Lost- 375 RTP/RTCP | | notification 376 packets | | + 377 | | RTT 378 v | 379 +-------------+ 380 | QUIC | 381 | | 382 +-------------+ 384 Figure 2: RTP over QUIC send flow 386 On receiving a datagram, an RTP over QUIC implementation strips off 387 and parses the flow identifier to identify the stream to which the 388 received RTP or RTCP packet belongs. The remaining content of the 389 datagram is then passed to the RTP session which was assigned the 390 given flow identifier. 392 7. SDP Signalling 394 QUIC is a connection-based protocol that supports connectionless 395 transmissions of DATAGRAM frames within an established connection. 396 As noted above, demultiplexing DATAGRAMS intended for different 397 purposes is up to the application using QUIC. 399 There are several necessary steps to carry out jointly between the 400 communicating peers to enable RTP over QUIC: 402 1. The protocol identifier for the m= lines MUST be "QUIC/RTP", 403 combined as per [RFC8866] with the respective audiovisual 404 profile: for example, "QUIC/RTP/AVP". 406 2. The peers need to decide whether to establish a new QUIC 407 connection or whether to re-use an existing one. In case of 408 establishing a new connection, the initiator and the responder 409 (client and server) need to be determined. Signaling for this 410 step MUST follow [RFC8122] on SDP attributes for connection- 411 oriented media for the a=setup, a=connection, and a=fingerprint 412 attributes. They MUST use the appropriate protocol 413 identification as per 1. 415 3. The peers must provide a means for identifying RTP sessions 416 carried in QUIC DATAGRAMS. To enable using a common transport 417 connection for one, two, or more media sessions in the first 418 place, the BUNDLE grouping framework MUST be used [RFC8843]. All 419 media sections belonging to a bundle group, except the first one, 420 MUST set the port in the m= line to zero and MUST include the 421 a=bundle-only attribute. 423 For disambiguating different RTP session, a reference needs to be 424 provided for each m= line to allow associating this specific 425 media session with a flow identifier. This could be achieved 426 following different approaches: 428 * Simply reusing the a=extmap attribute [RFC8285] and relying on 429 RTP header extensions for demultiplexing different media 430 packets carried in QUIC DATAGRAM frames. 432 * Defining a variant or different flavor of the a=extmap 433 attribute [RFC8285] that binds media sessions to flow 434 identifiers used in QUIC DATAGRAMS. 436 *Editor's note:* It is likely preferable to use multiplexing 437 using QUIC DATAGRAM flow identifiers because this multiplexing 438 mechanisms will also work across RTP and non-RTP media 439 streams. 441 In either case, the corresponding identifiers MUST be treated 442 independently for each direction of transmission, so that an 443 endpoint MAY choose its own identifies and only uses SDP to 444 inform its peer which RTP sessions use which identifiers. 446 To this end, SDP MUST be used to indicate the repsective flow 447 identifiers for RTP and RTCP of the different RTP sessions (for 448 which we borrow inspiration from [RFC3605]). 450 4. The peers MUST agree, for each RTP session, whether or not to 451 apply RTP/RTCP multiplexing. If multiplexing RTP and RTCP shall 452 take place on the same flow identifier, this MUST be indicated 453 using the attribute a=rtcp-mux. 455 A sample session setup offer (liberally borrowed and extended from 456 [RFC8843] and [RFC8122] could look as follows: 458 v=0 459 o=alice 2890844526 2890844526 IN IP6 2001:db8::3 460 s= 461 c=IN IP6 2001:db8::3 462 t=0 0 463 a=group:BUNDLE abc xyz 465 m=audio 10000 QUIC/RTP/AVP 0 8 97 466 a=setup:actpass 467 a=connection:new 468 a=fingerprint:SHA-256 \ 469 12:DF:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF: \ 470 3E:5D:49:6B:19:E5:7C:AB:4A:AD 471 b=AS:200 472 a=mid:abc 473 a=rtcp-mux 474 a=rtpmap:0 PCMU/8000 475 a=rtpmap:8 PCMA/8000 476 a=rtpmap:97 iLBC/8000 477 a=extmap:1 urn:ietf:params: 479 m=video 0 QUIC/RTP/AVP 31 32 480 b=AS:1000 481 a=bundle-only 482 a=mid:bar 483 a=rtcp-mux 484 a=rtpmap:31 H261/90000 485 a=rtpmap:32 MPV/90000 486 a=extmap:2 urn:ietf:params: 488 Figure 3: SDP Offer 490 Signaling details to be worked out. 492 8. Used RTP/RTCP packet types 494 Any RTP packet can be sent over QUIC and no RTCP packets are used by 495 default. Since QUIC already includes some features which are usually 496 implemented by certain RTCP messages, RTP over QUIC implementations 497 should not need to implement the following RTCP messages: 499 * PT=205, FMT=1, Name=Generic NACK: Provides Negative 500 Acknowledgements [RFC4585]. Acknowledgement and loss 501 notifications are already provided by the QUIC connection. 503 * PT=205, FMT=8, Name=RTCP-ECN-FB: Provides RTCP ECN Feedback 504 [RFC6679]. If supported, ECN may directly be exposed by the used 505 QUIC implementation. 507 * PT=205, FMT=11, Name=CCFB: RTP Congestion Control Feedback which 508 contains receive marks, timestamps and ECN notifications for each 509 received packet [RFC8888]. This can be inferred from QUIC as 510 described in Section 6. 512 * PT=210, FMT=all, Name=Token, [RFC6284] specifies a way to 513 dynamically assign ports for RTP receivers. Since QUIC 514 connections manage ports on their own, this is not required for 515 RTP over QUIC. 517 9. Enhancements 519 The RTT statistics collected by QUIC may not be very precise because 520 it can be influenced by delayed ACKs. An alternative the RTT is to 521 explicitly measure a one way delay. [QUIC-TS] suggests an extension 522 for QUIC to implement one way delay measurements using a timestamp 523 carried in a special QUIC frame. The new frame carries the time at 524 which a packet was sent. This timestamp can be used by the receiver 525 to estimate a one way delay as the difference between the time at 526 which a packet was received and the timestamp in the received packet. 527 The one way delay can then be used as a replacement for the receive 528 time estimation derived from the RTT as described in Section 6 to 529 create the "pkt_delay_list". 531 *Editor's note:* Even with one-way delay measurements it is still 532 not possible to identify exact timestamps for individual packets, 533 since the timestamp may be sent with an ACK that acks more than 534 one earlier packet. 536 10. Discussion 538 10.1. Impact of Connection Migration 540 11. Security Considerations 542 TBD 544 12. IANA Considerations 546 This document has no IANA actions. 548 13. References 550 13.1. Normative References 552 [H3-DATAGRAM] 553 Schinazi, D., Ed., "Using QUIC Datagrams with HTTP/3", 554 Work in Progress, Internet-Draft, draft-schinazi-quic-h3- 555 datagram-05, . 558 [QUIC-DATAGRAM] 559 Pauly, T., Ed., Kinnear, E., Ed., and D. Schinazi, Ed., 560 "An Unreliable Datagram Extension to QUIC", Work in 561 Progress, Internet-Draft, draft-ietf-quic-datagram-02, 562 . 565 [QUIC-TS] Huitema, C., Ed., "Quic Timestamps For Measuring One-Way 566 Delays", Work in Progress, Internet-Draft, draft-huitema- 567 quic-ts-05, . 570 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 571 Requirement Levels", BCP 14, RFC 2119, 572 DOI 10.17487/RFC2119, March 1997, 573 . 575 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 576 Jacobson, "RTP: A Transport Protocol for Real-Time 577 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 578 July 2003, . 580 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 581 in Session Description Protocol (SDP)", RFC 3605, 582 DOI 10.17487/RFC3605, October 2003, 583 . 585 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 586 "Extended RTP Profile for Real-time Transport Control 587 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 588 DOI 10.17487/RFC4585, July 2006, 589 . 591 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 592 Control Packets on a Single Port", RFC 5761, 593 DOI 10.17487/RFC5761, April 2010, 594 . 596 [RFC6284] Begen, A., Wing, D., and T. Van Caenegem, "Port Mapping 597 between Unicast and Multicast RTP Sessions", RFC 6284, 598 DOI 10.17487/RFC6284, June 2011, 599 . 601 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 602 and K. Carlberg, "Explicit Congestion Notification (ECN) 603 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 604 2012, . 606 [RFC8122] Lennox, J. and C. Holmberg, "Connection-Oriented Media 607 Transport over the Transport Layer Security (TLS) Protocol 608 in the Session Description Protocol (SDP)", RFC 8122, 609 DOI 10.17487/RFC8122, March 2017, 610 . 612 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 613 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 614 May 2017, . 616 [RFC8285] Singer, D., Desineni, H., and R. Even, Ed., "A General 617 Mechanism for RTP Header Extensions", RFC 8285, 618 DOI 10.17487/RFC8285, October 2017, 619 . 621 [RFC8298] Johansson, I. and Z. Sarker, "Self-Clocked Rate Adaptation 622 for Multimedia", RFC 8298, DOI 10.17487/RFC8298, December 623 2017, . 625 [RFC8698] Zhu, X., Pan, R., Ramalho, M., and S. Mena, "Network- 626 Assisted Dynamic Adaptation (NADA): A Unified Congestion 627 Control Scheme for Real-Time Media", RFC 8698, 628 DOI 10.17487/RFC8698, February 2020, 629 . 631 [RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings, 632 "Negotiating Media Multiplexing Using the Session 633 Description Protocol (SDP)", RFC 8843, 634 DOI 10.17487/RFC8843, January 2021, 635 . 637 [RFC8866] Begen, A., Kyzivat, P., Perkins, C., and M. Handley, "SDP: 638 Session Description Protocol", RFC 8866, 639 DOI 10.17487/RFC8866, January 2021, 640 . 642 [RFC8888] Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP 643 Control Protocol (RTCP) Feedback for Congestion Control", 644 RFC 8888, DOI 10.17487/RFC8888, January 2021, 645 . 647 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 648 Multiplexed and Secure Transport", RFC 9000, 649 DOI 10.17487/RFC9000, May 2021, 650 . 652 [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 653 and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, 654 May 2021, . 656 13.2. Informative References 658 [QRT] Hurst, S., Ed., "QRT: QUIC RTP Tunnelling", Work in 659 Progress, Internet-Draft, draft-hurst-quic-rtp-tunnelling- 660 01, . 663 Acknowledgments 665 TODO acknowledge. 667 Authors' Addresses 669 Jörg Ott 670 Technical University Munich 672 Email: ott@in.tum.de 674 Mathis Engelbart 675 Technical University Munich 677 Email: mathis.engelbart@gmail.com