]> Technical University Munich

ott@in.tum.de

Technical University Munich

mathis.engelbart@gmail.com

Tencent America LLC

spencerdawkins.ietf@gmail.com

Applications and Real-Time Audio/Video Transport Core Maintenance Internet-Draft This document specifies a minimal mapping for encapsulating Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) packets within the QUIC protocol. This mapping is called RTP over QUIC (RoQ). It also discusses how to leverage state from the QUIC implementation in the endpoints, in order to reduce the need to exchange RTCP packets and how to implement congestion control and rate adaptation without relying on RTCP feedback. Discussion Venues Discussion of this document takes place on the Audio/Video Transport Core Maintenance Working Group mailing list (avt@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction This document specifies a minimal mapping for encapsulating Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) packets within the QUIC protocol (). This mapping is called RTP over QUIC (RoQ). It also discusses how to leverage state from the QUIC implementation in the endpoints, in order to reduce the need to exchange RTCP packets, and how to implement congestion control and rate adaptation without relying on RTCP feedback.

Background The Real-time Transport Protocol (RTP) is generally used to carry real-time media for conversational media sessions, such as video conferences, across the Internet. Since RTP requires real-time delivery and is tolerant to packet losses, the default underlying transport protocol has been UDP, recently with DTLS on top to secure the media exchange and occasionally TCP (and possibly TLS) as a fallback. This specification describes an application usage of QUIC (). As a baseline, the specification does not expect more than a standard QUIC implementation as defined in , , , and , providing a secure end-to-end transport that is also expected to work well through NATs and firewalls. Beyond this baseline, real-time applications can benefit from QUIC extensions such as unreliable QUIC datagrams , which provides additional desirable properties for real-time traffic (e.g., no unnecessary retransmissions, avoiding head-of-line blocking).

Motivations From time to time, someone asks the reasonable question, "why should anyone implement and deploy RoQ"? This reasonable question deserves a better answer than "because we can". Upon reflection, the following motivations seem useful to state. The motivations in this section are in no particular order, and this reflects the reality that not all implementers and deployers would agree on "the most important motivations".

"Always-On" Transport-level Authentication and Encryption Although application-level mechanisms to encrypt RTP and RTCP payloads have existed since the introduction of Secure Real-time Transport Protocol (SRTP) , encryption of RTP and RTCP header fields and contributing sources has only been defined recently (in Cryptex , and both SRTP and Cryptex are optional capabilities for RTP. This is in sharp contrast to "always-on" transport-level encryption in the QUIC protocol, using Transport Layer Security (TLS 1.3) as described in . QUIC implementations always authenticate the entirety of each packet, and encrypt as much of each packet as is practical, even switching from "long headers", which expose more QUIC header fields needed to establish a connection, to "short headers", which only expose the absolute minimum QUIC header fields needed to identify the connection to the receiver, so that the QUIC payload is presented to the right QUIC application .

"Always-On" Internet-Safe Congestion Avoidance When RTP is carried directly over UDP, as is commonly done, the underlying UDP protocol provides no transport services beyond path multiplexing using UDP ports. All congestion avoidance behavior is up to the RTP application itself, and if anything goes wrong with the application resulting in an RTP sender failing to recognize that it is contributing to path congestion, the "worst case" response is to invoke RTP "circuit breaker" procedures , resulting in "ceasing transmission", as described in . Because RTCP-based circuit breakers only detect long-lived congestion, a response based on these mechanisms will not happen quickly. In contrast, when RTP is carried over QUIC, QUIC implementations maintain their own estimates of key transport parameters needed to detect and respond to possible congestion, and these are independent of any measurements RTP senders and receivers are maintaining. The result is that even if an RTP sender continues to "send", QUIC congestion avoidance procedures (for example, the procedures defined in ) will cause the RTP packets to be buffered and only placed on the network path as part of a response to detected loss. This happens without any action being requied on the part of RTP senders. While the effect of QUIC's response to congestion means that some RTP packets will arrive at the receiver later than a user of the RTP flow might prefer, it is still preferable to "ceasing transmission" completely until the RTP sender has a reason to believe that restarting the flow will not result in congestion. Moreover, when a single QUIC connection is used to multiplex both RTP-RTCP and non-RTP packets as described in , the QUIC connection will still be Internet-safe, with no coordination required.

Rate Adaptation Based on QUIC Feedback RTP makes use of a large number of RTP-specific feedback mechanisms because when RTP is carried directly over UDP, there is no other way to receive feedback. Some of these mechanisms are specific to the type of media RTP is sending, but others can be mapped from underlying QUIC implementations that are using this feedback to perform rate adaptation for any QUIC connection, regardless of the application reflected in the QUIC STREAM and DATAGRAM frames. This is described in (much) more detail in on rate adaptation, and in on replacing RTCP and RTP header extensions with QUIC feedback. One word of caution is in order - RTP implementations may rely on at least some minimal periodic RTCP feedback, in order to determine that an RTP flow is still active, and is not causing sustained congestion (as described in , but since this "periodicity" is measured in seconds, the impact of this "duplicate" feedback on path bandwidth utilization is likely close to zero.

Path MTU Discovery and RTP Media Coalescence The minimum Path MTU supported by conformant QUIC implementations is 1200 bytes , and in addition, QUIC implementations allow senders to use either DPLPMTUD () or PMTUD (, ) to determine the actual MTU size that the receiver and path between sender and receiver support, which can be even larger. This is especially useful in certain conferencing topologies, where otherwise senders have no choice but to use the lowest path MTU for all conference participants, but even in point-to-point RTP sessions, this also allows senders to piggyback audio media in the same UDP packet as video media, for example, and also allows QUIC receivers to piggyback QUIC ACK frames on any QUIC frames being transmitted in the other direction.

Multiplexing RTP, RTCP, and Non-RTP Flows on a Single QUIC Connection In order to conserve ports, especially at NATs and Firewalls, this specification defines a flow identifier, so that multiple RTP flows, RTCP flows, and non-RTP flows can be distinguished even if they are carried on the same QUIC connection. This is described in more detail in .

Exploiting Multiple Connections Although there is much interest in multiplexing flows on a single QUIC connection as described in , QUIC also provides the capability of establishing and validating multiple paths for a single QUIC connection . Once multiple paths have been validated, a sender can migrate from one path to another with no additional signaling, allowing an endpoint to move from one endpoint address to another without interruption, as long as only a single path is in active use at any point in time. Connection migration may be desireable for a number of reasons, but to give one example, this allows a sender to distinguish between more costly cellular paths and less costly WiFi paths, with no action required from the application.

Exploiting New QUIC Capabilities In addition to connection migration as described in , the capability of validating multiple paths for simultaneous active use is under active development in the IETF . We don't discuss Multipath QUIC further in this document, because the specification hasn't been approved yet, but it's one example of ways that RTP, a mature protocol, can exploit new transport capabilities as they become available.

What's in Scope for this Specification This document defines a mapping for RTP and RTCP over QUIC, called RoQ, and describes ways to reduce the amount of RTCP traffic by leveraging state information readily available within a QUIC endpoint. This document also describes different options for implementing congestion control and rate adaptation for RoQ. This specification focuses on providing a secure encapsulation of RTP packets for transmission over QUIC. The expected usage is wherever RTP is used to carry media packets, allowing QUIC in place of other transport protocols such as TCP, UDP, SCTP, DTLS, etc. That is, we expect RoQ to be used in contexts in which a signaling protocol is used to announce or negotiate a media encapsulation and the associated transport parameters (such as IP address, port number). RoQ is not intended as a stand-alone media transport, although QUIC transport parameters could be statically configured. The above implies that RoQ is targeted at peer-to-peer operation; but it may also be used in client-server-style settings, e.g., when talking to a conference server as described in RFC 7667 (), or, if RoQ is used to replace RTSP (), to a media server. Moreover, this document describes how a QUIC implementation and its API can be extended to improve efficiency of the RoQ protocol operation. RoQ does not impact the usage of RTP Audio Video Profiles (AVP) (), or any RTP-based mechanisms, even though it may render some of them unnecessary, e.g., Secure Real-Time Transport Prococol (SRTP) () might not be needed, because end-to-end security is already provided by QUIC, and double encryption by QUIC and by SRTP might have more costs than benefits. Nor does RoQ limit the use of RTCP-based mechanisms, even though some information or functions obtained by using RTCP mechanisms may also be available from the underlying QUIC implementation by other means. Between two (or more) endpoints, RoQ supports multiplexing multiple RTP-based media streams within a single QUIC connection and thus using a single (destination IP address, destination port number, source IP address, source port number, protocol) 5-tuple.. We note that multiple independent QUIC connections may be established in parallel using the same destination IP address, destination port number, source IP address, source port number, protocol) 5-tuple., e.g. to carry different media channels. These connections would be logically independent of one another.

What's Out of Scope for this Specification This document does not attempt to enhance QUIC for real-time media or define a replacement for, or evolution of, RTP. Work to map other media transport protocols to QUIC is under way elsewhere in the IETF. RoQ is designed for use with point-to-point connections, because QUIC itself is not defined for multicast operation. The scope of this document is limited to unicast RTP/RTCP, even though nothing would or should prevent its use in multicast setups once QUIC supports multicast. RoQ does not define congestion control and rate adaptation algorithms for use with media. However, discusses options for how congestion control and rate adaptation could be performed at the QUIC and/or at the RTP layer, and how information available at the QUIC layer could be exposed via an API for the benefit of RTP layer implementation.

• Editor's note: Need to check whether will also describe the QUIC interface that's being exposed, or if that ends up somewhere else in the document.

RoQ does not define prioritization mechanisms when handling different media as those would be dependent on the media themselves and their relationships. Prioritization is left to the application using RoQ. This document does not cover signaling for session setup. SDP for RoQ is defined in separate documents such as , and can be carried in any signaling protocol that can carry SDP, including the Session Initiation Protocol (SIP) (), Real-Time Protocols for Browser-Based Applications (RTCWeb) (), or WebRTC-HTTP Ingestion Protocol (WHIP) ().

Terminology and Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

• Editor's note: the list of terms below will almost certainly grow in size as the specification matures.

The following terms are used:

Congestion Control:

A mechanism to limit the aggregate amount of data that has been sent over a path to a receiver, but has not been acknowledged by the receiver. This prevents a sender from overwhelming the capacity of a path between a sender and a receiver, causing some outstanding data to be discarded before the receiver can receive the data and acknowledge it to the sender.

Datagram:

Datagrams exist in UDP as well as in QUIC's unreliable datagram extension. If not explicitly noted differently, the term datagram in this document refers to a QUIC Datagram as defined in .

Delay-based or Low-latency congestion control algorithm:

A congestion control algorithm that aims at keeping queues, and thus the latency, at intermediary network elements as short as possible. Delay-based congestion control algorithms use, for example, an increasing one-way delay as a signal of congestion.

Endpoint:

A QUIC server or client that participates in an RoQ session.

Frame:

A QUIC frame as defined in .

Loss-based congestion control algorithm:

A congestion control algorithm that uses packet loss, or an Explicit Congestion Notification (ECN) that is interpreted as loss (as in ), as a signal for congestion. Loss-based congestion control algorithms allow senders to send data on a path until packets are dropped by intermediary network elements, which the algorithm treats as a signal of congestion.

Media Encoder:

An entity that is used by an application to produce a stream of encoded media, which can be packetized in RTP packets to be transmitted over QUIC.

QUIC congestion controller:

A software component of an application's QUIC implementation that implements a congestion control algorithm.

Rate Adaptation:

A congestion control mechanism that helps a sender determine and adjust its sending rate, in order to maximize the amount of information that is sent to a receiver, without causing queues to build beyond a reasonable amount, causing "buffer bloat" and "jitter". Rate adapation is one way to accomplish congestion control for real-time media, especially when a sender has multiple media streams to the receiver, because the sum of all sending rates for media streams must not be high enough to cause congestion on the path these media streams share between sender and receiver.

Receiver:

An endpoint that receives media in RTP packets and may send or receive RTCP packets.

RTP congestion controller:

A software component of an application's RTP implementation that implements a congestion control algorithm.

Sender:

An endpoint that sends media in RTP packets and may send or receive RTCP packets.

Packet diagrams in this document use the format defined in to illustrate the order and size of fields.

Protocol Overview This document introduces a mapping of the Real-time Transport Protocol (RTP) to the QUIC transport protocol. RoQ allows the use of QUIC streams and QUIC datagrams to transport real-time data, and thus, the QUIC implementation MUST support QUIC's datagram extension, if RTP packets should be sent over QUIC datagrams. Since datagram frames cannot be fragmented, the QUIC implementation MUST also provide a way to query the maximum datagram size so that an application can create RTP packets that always fit into a QUIC datagram frame. specifies that RTP sessions need to be transmitted on different transport addresses to allow multiplexing between them. RoQ uses a different approach to leverage the advantages of QUIC connections without managing a separate QUIC connection per RTP session. QUIC does not provide demultiplexing between different flows on datagrams but suggests that an application implement a demultiplexing mechanism if required. An example of such a mechanism would be flow identifiers prepended to each datagram frame as described in . RoQ uses a flow identifier to replace the network address and port number to multiplex many RTP sessions over the same QUIC connection. An RTP application is responsible for determining what to send in an encoded media stream, and how to send that encoded media stream within a targeted bitrate. This document does not mandate how an application determines what to send in an encoded media stream, because decisions about what to send within a targeted bitrate, and how to adapt to changes in the targeted bitrate, can be application and codec-specific. For example, adjusting quantization in response to changing network conditions may work well in many cases, but if what's being shared is video that includes text, maintaining readability is important. A rate adaptation algorithm can be plugged in to adapt the media bitrate to the available bandwidth. This document does not mandate any specific rate adaptation mechanism, so the application can use a rate adaption mechanism of its choice. As of this writing, the IETF has produced two Experimental-track rate adaptation specifications, Network-Assisted Dynamic Adaptation (NADA) and Self-Clocked Rate Adaptation for Multimedia (SCReAM) . These rate adaptation algorithms require some feedback about the network's performance to calculate target bitrates. Traditionally this feedback is generated at the receiver and sent back to the sender via RTCP. Since QUIC also collects some metrics about the network's performance, these metrics can be used to generate the required feedback at the sender-side and provide it to the rate adaptation algorithm to avoid the additional overhead of the RTCP stream. This is discussed in more detail in .

RTP with QUIC Streams, QUIC Datagrams, and a Mixture of Both This document describes the use of QUIC streams and QUIC datagrams as RTP encapsulations. The choice of which encapsulation is used is up to the application developer, but it is worth noting the differences. QUIC was initially designed to carry HTTP in QUIC streams, and QUIC streams provide what HTTP application developers require - for example, QUIC streams provide a stateful, connection-oriented, flow-controlled, reliable, ordered stream of bytes to an application. QUIC streams can be multiplexed over a single QUIC connection, using stream IDs to demultiplex incoming messages. QUIC Datagrams ((!RFC9221}} were developed as a QUIC extension, intended to support applications that do not require reliable delivery of application data. This extension defines two QUIC DATAGRAM frame types (one including a length field, the other not including a length field), and these DATAGRAM frames can co-exist with QUIC STREAM frames within a single QUIC connection, sharing the connection's cryptographic and authentication context, and congestion controller context. There is no default relative priority between DATAGRAM frames with respect to each other, and there is no default priority between DATAGRAM frames and QUIC streams. The implementation likely presents an API to allow appplications to assign relative priorities, but this is not mandated by the standard and may not be present in all implementations. Because QUIC datagrams are an extension to QUIC, they inherit a great deal of functionality from QUIC (much of which is described in ); so much so that it is easier to explain what datagrams do NOT inherit.

• DATAGRAM frames do not provide any explicit flow control signaling. This means that a QUIC receiver may not be able to commit the necessary resources to process incoming frames, but the purpose for DATAGRAM frames is to carry application-level information that can be lost and will not be retransmitted,
• DATAGRAM frames do inherit the QUIC connection's congestion controller. This means that although there is no frame-level flow control, DATAGRAM frames may be delayed until the controller allows them to be sent, or dropped (with an optional notification to the sending application). Implementations can also delay sending DATAGRAM frames to maintain consistent packet pacing (as described in ), and can allow an application to specify a sending expiration time, but these capabilities are not mandated by the standard and may not be present in all implementations.
• DATAGRAM frames cannot be fragmented. They are limited in size by the max_datagram_frame_size transport parameter, and further limited by the max_udp_payload_size transport parameter and the Maximum Transmission Unit (MTU) of the path between endpoints.
• DATAGRAM frames belong to a QUIC connection as a whole. There is no QUIC-level way to multiplex/demultiplex DATAGRAM frames within a single QUIC connection. Any multiplexing identifiers must be added, interpreted, and removed by an application, and they will be sent as part of the payload of the DATAGRAM frame itself.

Supported RTP Topologies RoQ only supports some of the RTP topologies described in . Most notably, due to QUIC being a purely IP unicast protocol at the time of writing, RoQ cannot be used as a transport protocol for any of the paths that rely on IP multicast in several multicast topologies (e.g., Topo-ASM, Topo-SSM, Topo-SSM-RAMS). Some "multicast topologies" can include IP unicast paths (e.g., Topo-SSM, Topo-SSM-RAMS). In these cases, the unicast paths can use RoQ. RTP supports different types of translators and mixers. Whenever a middlebox such as a translator or a mixer needs to access the content of RTP/RTCP-packets, the QUIC connection has to be terminated at that middlebox. RoQ streams (see ) can support much larger RTP packet sizes than other transport protocols such as UDP can, which can lead to problems with transport translators which translate from RoQ to RTP over a different transport protocol. A similar problem can occur if a translator needs to translate from RTP over UDP to RoQ datagrams, where the MTU of a QUIC datagram may be smaller than the MTU of a UDP datagram. In both cases, the translator may need to rewrite the RTP packets to fit into the smaller MTU of the other protocol. Such a translator may need codec-specific knowledge to packetize the payload of the incoming RTP packets in smaller RTP packets. Additional details are provided in the following table.

RFC 7667 Section	Shortcut Name	RTP over QUIC?	Comments
3.1	Topo-Point-to-Point	yes
3.2.1.1	Topo-PtP-Relay	yes	Note-NAT
3.2.1.2	Topo-Trn-Translator	yes	Note-MTU Note-SEC
3.2.1.3	Topo-Media-Translator	yes	Note-MTU
3.2.2	Topo-Back-To-Back	yes	Note-SEC Note-MTU Note-MCast
3.3.1	Topo-ASM	no	Note-MCast
3.3.2	Topo-SSM	partly	Note-MCast Note-UCast-MCast
3.3.3	Topo-SSM-RAMS	partly	Note-MCast Note-MCast-UCast
3.4	Topo-Mesh	yes	Note-MCast
3.5.1	Topo-PtM-Trn-Translator	possibly	Note-MCast Note-MTU Note-Topo-PtM-Trn-Translator
3.6	Topo-Mixer	possibly	Note-MCast Note-Topo-Mixer
3.6.1	Media-Mixing-Mixer	partly	Note-Topo-Mixer
3.6.2	Media-Switching-Mixer	partly	Note-Topo-Mixer
3.7	Selective Forwarding Middlebox	yes	Note-MCast Note-Topo-Mixer
3.8	Topo-Video-switch-MCU	yes	Note-MTU Note-MCast Note-Topo-Mixer
3.9	Topo-RTCP-terminating-MCU	yes	Note-MTU Note-MCast Note-Topo-Mixer
3.10	Topo-Split-Terminal	yes	Note-MCast
3.11	Topo-Asymmetric	Possibly	Note-Warn, Note-MCast, Note-MTU

Note-NAT:

QUIC doesn't support NAT traversal.

Note-MTU:

Supported, but may require MTU adaptation.

Note-Sec:

Note that RoQ provides mandatory security, and other RTP transports do not. describes strategies to prevent the inadvertent disclosure of RTP sessions to unintended third parties.

Note-MCast:

QUIC cannot be used for multicast paths.

Note-UCast-MCast:

The topology refers to a Distribution Source, which receives and relays RTP from a number of different media senders via unicast before relaying it to the receivers via multicast. QUIC can be used between the senders and the Distribution Source.

Note-MCast-UCast:

The topology refers to a Burst Source or Retransmission Source, which retransmits RTP to receivers via unicast. QUIC can be used between the Retransmission Source and the receivers.

Note-Topo-PtM-Trn-Translator:

Supports unicast paths between RTP sources and translators.

Note-Topo-Mixer:

Supports unicast paths between RTP senders and mixers.

Note-Warn:

Quote from : This topology is so problematic and it is so easy to get the RTCP processing wrong, that it is NOT RECOMMENDED to implement this topology.

Connection Establishment and ALPN QUIC requires the use of ALPN tokens during connection setup. RoQ uses "rtp-mux-quic" as ALPN token in the TLS handshake (see also . Note that the use of a given RTP profile is not reflected in the ALPN token even though it could be considered part of the application usage. This is simply because different RTP sessions, which may use different RTP profiles, may be carried within the same QUIC connection.

• Editor's note: "rtp-mux-quic" indicates that RTP and other protocols may be multiplexed on the same QUIC connection using a flow identifier as described in . Applications are responsible for negotiation of protocols in use by appropriate use of a signaling protocol such as SDP.

• Editor's note: This implies that applications cannot use RoQ as specified in this document over WebTransport.

Draft version identification

• RFC Editor's note: Please remove this section prior to publication of a final version of this document.

RoQ uses the token "rtp-mux-quic" to identify itself in ALPN. Only implementations of the final, published RFC can identify themselves as "rtp-mux-quic". Until such an RFC exists, implementations MUST NOT identify themselves using this string. Implementations of draft versions of the protocol MUST add the string "-" and the corresponding draft number to the identifier. For example, draft-ietf-avtcore-rtp-over-quic-04 is identified using the string "rtp-mux-quic-04". Non-compatible experiments that are based on these draft versions MUST append the string "-" and an experiment name to the identifier.

Encapsulation This section describes the encapsulation of RTP/RTCP packets in QUIC. QUIC supports two transport methods: streams and datagrams . This document specifies mappings of RTP to both of the transport modes. Senders MAY combine both modes by sending some RTP/RTCP packets over the same or different QUIC streams and others in QUIC datagrams. introduces a multiplexing mechanism that supports multiplexing RTP, RTCP, and, with some constraints, other non-RTP protocols. and explain the specifics of mapping RTP to QUIC streams and QUIC datagrams, respectively.

Multiplexing RoQ uses flow identifiers to multiplex different RTP, RTCP, and non-RTP data streams on a single QUIC connection. A flow identifier is a QUIC variable-length integer as described in . Each flow identifier is associated with a stream of RTP packets, RTCP packets, or a data stream of a non-RTP protocol. In a QUIC connection using the ALPN token defined in , every QUIC datagram and every QUIC stream MUST start with a flow identifier. A peer MUST NOT send any data in a datagram or stream that is not associated with the flow identifier which started the datagram or stream. RTP and RTCP packets of different RTP sessions MUST use distinct flow identifiers. If peers wish to send multiple types of media in a single RTP session, they MAY do so by following . A single RTP session MAY be associated with one or two flow identifiers. Thus, it is possible to send RTP and RTCP packets belonging to the same session using different flow identifiers. RTP and RTCP packets of a single RTP session MAY use the same flow identifier (following the procedures defined in , or they MAY use different flow identifiers. The association between flow identifiers and data streams MUST be negotiated using appropriate signaling. Applications MAY send data using flow identifiers not associated with any RTP or RTCP stream. If a receiver cannot associate a flow identifier with any RTP/RTCP or non-RTP flow, it MAY drop the data flow. If the data flow was sent on a QUIC stream, the receiver SHOULD send a STOP_SENDING frame with the application error code set to ROQ_UNKNOWN_FLOW_ID. There are different use cases for sharing the same QUIC connection between RTP and non-RTP data streams. Peers might use the same connection to exchange signaling messages or exchange data while sending and receiving media streams. The semantics of non-RTP datagrams or streams are not in the scope of this document. Peers MAY use any protocol on top of the encapsulation described in this document. Flow identifiers introduce some overhead in addition to the header overhead of RTP/RTCP and QUIC. QUIC variable-length integers require between one and eight bytes depending on the number expressed. Thus, it is advisable to use low numbers first and only use higher ones if necessary due to an increased number of flows.

QUIC Streams To send RTP/RTCP packets over QUIC streams, a sender MUST open a new unidirectional QUIC stream. Streams are unidirectional because there is no synchronous relationship between sent and received RTP/RTCP packets. A peer that receives a bidirectional stream with a flow identifier that is associated with an RTP or RTCP stream, SHOULD stop reading from the stream and send a STOP_SENDING frame with the application protocol error code set to ROQ_STREAM_CREATION_ERROR. A RoQ sender MAY open new QUIC streams for different packets using the same flow identifier, for example, to avoid head-of-line blocking. A receiver MUST be prepared to receive RTP packets on any number of QUIC streams (subject to its limit on parallel open streams) and SHOULD not make assumptions which RTP sequence numbers are carried in which streams. Note: A sender may or may not decide to discontinue using a lower stream number after starting packet transmission on a higher stream number.

Stream Encapsulation shows the encapsulation format for RoQ Streams.

RoQ Streams Payload Format

Flow Identifier:

Flow identifier to demultiplex different data flows on the same QUIC connection.

RTP/RTCP Payload:

Contains the RTP/RTCP payload; see

The payload in a QUIC stream starts with the flow identifier followed by one or more RTP/RTCP payloads. All RTP/RTCP payloads sent on a stream MUST belong to the RTP session with the same flow identifier. Each payload begins with a length field indicating the length of the RTP/RTCP packet, followed by the packet itself, see .

RTP/RTCP payload for QUIC streams

Length:

A QUIC variable length integer (see ) describing the length of the following RTP/RTCP packets in bytes.

RTP/RTCP Packet:

The RTP/RTCP packet to transmit.

Media Frame Cancellation QUIC uses RESET_STREAM and STOP_SENDING frames to terminate the sending part of a stream and to request termination of an incoming stream by the sending peer respectively. A RoQ sender MAY use RESET_STREAM if it knows that a packet, which was not yet successfully and completely transmitted, is no longer needed. A RoQ receiver that is no longer interested in reading a certain partition of the media stream MAY signal this to the sending peer using a STOP_SENDING frame. In both cases, the error code of the RESET_STREAM frame or the STOP_SENDING frame MUST be set to ROQ_FRAME_CANCELLED. When a RoQ sender receives a STOP_SENDING frame for the last open stream available to send RTP/RTCP-data, the RoQ sender MUST open one or more new QUIC streams before sending new media frames. Any media frame that has already been sent on the QUIC stream that received the STOP_SENDING frame, MUST NOT be sent again on the new QUIC stream(s). Note that an RTP receiver cannot request a reset of only a particular media frame because the sending QUIC implementation might already have sent data for the following frame on the same stream. In that case, STOP_SENDING and the following RESET_STREAM would also drop the following media frame and thus lead to unintentionally skipping one or more frames.

• Editor's note: A receiver cannot cancel a certain frame but still receive retransmissions for a frame the was following on the same stream using STOP_SENDING, because STOP_SENDING does not include an offset which would allow signaling where retransmissions should continue.

• Editor's note: Instead of using RESET_STREAM and STOP_SENDING frames, RoQ senders and receivers might benefit from negotiating the use of the QUIC extensions defined in and . These extensions provide two new frame types, the CLOSE_STREAM and the ENOUGH frame, equivalent to RESET_STREAM and STOP_SENDING, respectively, but with an additional offset. The offset indicates the point to which data will be reliably retransmitted, while everything following might be dropped. Using CLOSE_STREAM and ENOUGH instead of RESET_STREAM and STOP_SENDING could prevent accidentally stopping retransmissions for preceding frames.

A translator that translates between two endpoints, both connected via QUIC, MUST forward RESET_STREAM frames received from one end to the other unless it forwards the RTP packets on QUIC datagrams. Large RTP packets sent on a stream will be fragmented into smaller QUIC frames. The QUIC frames are transmitted reliably and in order such that a receiving application can read a complete RTP packet from the stream as long as the stream is not closed with a RESET_STREAM frame. No retransmission has to be implemented by the application since QUIC frames lost in transit are retransmitted by QUIC.

Flow control and MAX_STREAMS Opening new streams for new packets MAY implicitly limit the number of packets concurrently in transit because the QUIC receiver provides an upper bound of parallel streams, which it can update using QUIC MAX_STREAMS frames. The number of packets that have to be transmitted concurrently depends on several factors, such as the number of RTP streams within a QUIC connection, the bitrate of the media streams, and the maximum acceptable transmission delay of a given packet. Receivers are responsible for providing senders enough credit to open new streams for new packets anytime. As an example, consider a conference scenario with 20 participants. Each participant receives audio and video streams of every other participant from a central server. If the sender opens a new QUIC stream for every frame at 30 frames per second video and 50 frames per second audio, it will open 1520 new QUIC streams per second. A receiver must provide at least that many credits for opening new unidirectional streams to the server every second. In addition, the receiver should also consider the requirements of protocols into account that are multiplexed with RTP, including RTCP and data streams. These considerations may also be relevant when implementing signaling since it may be necessary to inform the receiver about how fast and how much stream credits it will have to provide to the media-sending peer.

QUIC Datagrams Senders can also transmit RTP packets in QUIC datagrams. QUIC datagrams are an extension to QUIC described in . QUIC datagrams can only be used if the use of the extension was successfully negotiated during the QUIC handshake. If the use of an extension was signaled using a signaling protocol, but the extension was not negotiated during the QUIC handshake, a peer MAY close the connection with the ROQ_EXPECTATION_UNMET error code. QUIC datagrams preserve frame boundaries. Thus, a single RTP packet can be mapped to a single QUIC datagram without additional framing. Senders SHOULD consider the header overhead associated with QUIC datagrams and ensure that the RTP/RTCP packets, including their payloads, flow identifier, QUIC, and IP headers, will fit into path MTU. shows the encapsulation format for RoQ Datagrams.

RoQ Datagram Payload Format

Flow Identifier:

Flow identifier to demultiplex different data flows on the same QUIC connection.

RTP/RTCP Packet:

The RTP/RTCP packet to transmit.

RoQ senders need to be aware that QUIC uses the concept of QUIC frames. Different kinds of QUIC frames are used for different application and control data types. A single QUIC packet can contain more than one QUIC frame, including, for example, QUIC stream or datagram frames carrying application data and acknowledgement frames carrying QUIC acknowledgements, as long as the overall size fits into the MTU. One implication is that the number of packets a QUIC stack transmits depends on whether it can fit acknowledgement and datagram frames in the same QUIC packet. Suppose the application creates many datagram frames that fill up the QUIC packet. In that case, the QUIC stack might have to create additional packets for acknowledgement- (and possibly other control-) frames. The additional overhead could, in some cases, be reduced if the application creates smaller RTP packets, such that the resulting datagram frame can fit into a QUIC packet that can also carry acknowledgement frames. Since QUIC datagrams are not retransmitted on loss (see also for loss signaling), if an application wishes to retransmit lost RTP packets, the retransmission has to be implemented by the application. RTP retransmissions can be done in the same RTP session or a separate RTP session and the flow identifier MUST be set to the flow identifier of the RTP session in which the retransmission happens.

Connection Shutdown Either peers MAY close the connection for variety of reasons. If one of the peers wants to close the RoQ connection, the peer can use a QUIC CONNECTION_CLOSE frame with one of the error codes defined in .

Congestion Control and Rate Adaptation Like any other application on the internet, RoQ applications need a mechanism to perform congestion control to avoid overloading the network. While any generic congestion controller can protect the network, this document takes advantage of the opportunity to use rate adaptation mechanisms that are designed to provide superior user experiences for real-time media applications. A wide variety of rate adaptation algorithms for real-time media have been developed (for example, "Google Congestion Controller" ). The IETF has defined two algorithms in two Experimental RFCs (e.g. SCReAM and NADA ). These rate adaptation algorithms for RTP are specifically tailored for real-time transmissions at low latencies, but this section would apply to any rate adaptation algorithm that meets the requirements described in "Congestion Control Requirements for Interactive Real-Time Media" . This document defines two architectures for congestion control and bandwidth estimation for RoQ, depending on whether most rate adaptation is performed within a QUIC implementation at the transport layer, as described in , or within an RTP application layer, as described in , but this document does not mandate any specific congestion control or rate adaptation algorithm for either QUIC or RTP. This document also gives guidance about avoiding problems with "nested" congestion controllers, in . This document also discusses congestion control implications of using shared or multiple separate QUIC connections to send and receive multiple independent data streams, in . It is assumed that the congestion controller in use provides a pacing mechanism to determine when a packet can be sent to avoid bursts. The currently proposed congestion control algorithms for real-time communications (e.g. SCReAM and NADA) provide such pacing mechanisms. The use of congestion controllers which don't provide a pacing mechanism is out of scope of this document.

Congestion Control at the Transport Layer QUIC is a congestion controlled transport protocol. Senders are required to employ some form of congestion control. The default congestion control specified for QUIC in is similar to TCP NewReno , but senders are free to choose any congestion control algorithm as long as they follow the guidelines specified in , and QUIC implementors make use of this freedom. If a QUIC implementation is to perform rate adaptation in a way that accommodates real-time media, one way for the implementation to recognize that it is carrying real-time media is to be explicitly told that this is the case. This document defines a new "TLS Application-Layer Protocol Negotiation (ALPN) Protocol ID", as described in , that a QUIC implementation can use as a signal to choose a real-time media-centric rate controller, but this is not required for ROQ deployments. If congestion control is to be applied at the transport layer, it is RECOMMENDED that the QUIC Implementation uses a congestion controller that keeps queueing delays short to keep the transmission latency for RTP and RTCP packets as low as possible, such as the IETF-defined SCReAM and NADA algorithms. Many low latency congestion control algorithms depend on detailed arrival time feedback to estimate the current one-way delay between sender and receiver. QUIC does not provide arrival timestamps in its acknowledgments. The QUIC implementations of the sender and receiver can use an extension to add this information to QUICs acknowledgment frames, e.g. or . If congestion control is done by the QUIC implementation, the application needs a mechanism to query the currently available bandwidth to adapt media codec configurations. The employed congestion controller of the QUIC connection SHOULD expose such an API to the application. If a current bandwidth estimate is not available from the QUIC congestion controller, the sender can either implement an alternative bandwidth estimation at the application layer as described in or a receiver can feedback the observed bandwidth through RTCP, e.g., using .

Congestion Control at the RTP Application Layer RTP itself does not specify a congestion control algorithm, but defines an RTCP feedback message intended to enable rate adaptation for interactive real-time traffic using RTP, and successful rate adaptation will accomplish congestion control as well. The rate adaptation algorithms for RTP are specifically tailored for real-time transmissions at low latencies, as described in . The available rate adaptation algorithms expose a target_bitrate that can be used to dynamically reconfigure media codecs to produce media at a rate that can be sent in real-time under the observed network conditions. If an application cannot access a bandwidth estimation from the QUIC layer, or the QUIC implementation does not support a delay-based, low-latency congestion control algorithm, the application can alternatively implement a bandwidth estimation algorithm at the application layer. Calculating a bandwidth estimation at the application layer can be done using the same bandwidth estimation algorithms as described in (NADA, SCReAM). The bandwidth estimation algorithm typically needs some feedback on the transmission performance. This feedback can be collected following the guidelines in .

Resolving Interactions Between QUIC and Application-layer Congestion Control Because QUIC is a congestion-controlled transport, as described in , and RTP applications can also perform congestion control and rate adaptation, as described in , implementers should be aware of the possibility that these "nested" congestion control loops, where both controllers are managing rate adaptation for the same packet stream independently, may deliver problematic performance. Because this document is describing a specific case (media transport), we can provide some guidance to avoid the worst possible problems.

• Application-limited Media Flows - if an application chooses RTP as its transport mechanism, the goal will be maximizing the user experience, not maximizing path bandwidth utilization. If the application is, in fact, transmitting media that does not saturate path bandwidth, and paces its transmission, more heavy-handed congestion control mechanisms (drastic reductions in the sending rate when loss is detected, with much slower increases when losses are no longer detected) should rarely come into play. If the application chooses ROQ as its transport, sends enough media to saturate the path bandwidth, and does not adapt its own sending rate, drastic measures will be required in order to avoid sustained or oscillating congestion along the path.
• Awareness of Bufferbloat - modern general-purpose congestion controllers do not adjust their sending rates based only on packet loss. For example, BBR ("Bottleneck Bandwidth and Round-trip propagation time") describes its strategy for adapting sending rates in this way:

• (BBR) "uses recent measurements of a transport connection's delivery rate, round-trip time, and packet loss rate to build an explicit model of the network path. BBR then uses this model to control both how fast it sends data and the maximum volume of data it allows in flight in the network at any time."

Sharing QUIC connections Two endpoints may establish channels in order to exchange more than one type of data simultaneously. The channels can be intended to carry real-time RTP data or other non-real-time data. This can be realized in different ways.

• One straightforward solution is to establish multiple QUIC connections, one for each channel, whether the channel is used for real-time media or non-real-time data. This is a straightforward solution, but has the disadvantage that transport ports are more quickly exhausted and these are limited by the 16-bit UDP source and destination port number sizes .
• Alternatively, all real-time channels are mapped to one QUIC connection, while a separate QUIC connection is created for the non-real-time channels.

In both cases, the congestion controllers can be chosen to match the demands of the respective channels and the different QUIC connections will compete for the same resources in the network. No local prioritization of data across the different (types of) channels would be necessary. Although it is possible to multiplex (all or a subset of) real-time and non-real-time channels onto a single, shared QUIC connection, which can be done by using the flow identifier described in , the underlying QUIC implementation will likely use the same congestion controller for all channels in the shared QUIC connection. For this reason, applications multiplexing multiple streams in one connection SHOULD implement some form of stream prioritization or bandwidth allocation.

Replacing RTCP and RTP Header Extensions with QUIC Feedback Because RTP has so often used UDP as its underlying transport protocol, and receiving little or no feedback from UDP, RTP implementations rely on feedback from the RTP Control Protocol (RTCP) so that RTP senders and receivers can exchange control information to monitor connection statistics and to identify and synchronize streams. Because QUIC provides its own transport-level feedback, at least some RTP transport level feedback can be replaced with current QUIC feedback . In adition, RTP-level feedback that is not available in QUIC by default can be replaced with generally useful QUIC extensions. Examples of these extentions include:

• Arrival timestamps, which are not part of QUIC's default acknowledgment frames, but can be added using or , or
• Adjusting the frequency of QUIC acknowledgments, using .

When statistics contained in RTCP packets are also available from QUIC, or can be derived from statistics available from QUIC, it is desireable to provide these statistics at only one protocol layer. This avoids consumption of bandwidth to deliver equivalent control information at more than one level of the protocol stack. QUIC and RTCP both have rules describing when certain signals have to be sent. This document does not change any of the rules described by either protocol, but specifies a baseline for replacing some of the RTCP packet types by mapping the contents to QUIC connection statistics, and reducing the transmission frequency and bandwidth requirements for some RTCP packet types that must be transmitted periodically. Future documents can extend this mapping for other RTCP format types, and can make use of new QUIC extensions that become available over time. The mechanisms described in this section can enhance the statistics provided by RTCP and reduce the bandwidth overhead required by certain RTCP packets. Applications using RoQ need to adhere to the rules for RTCP feedback given by and the RTP profiles in use. Most statements about "QUIC" in are applicable to both RTP encapsulated in QUIC streams and RTP encapsulated in QUIC datagrams. The differences are described in and .

• Editor's Note: Additional discussion of bandwidth minimization could go in this section, or in an earlier proposed section on motivations for defining and deploying RoQ.

While RoQ places no restrictions on applications sending RTCP, this document assumes that the reason an implementor chooses to support RoQ is to obtain benefits beyond what's available when RTP uses UDP as its underlying transport layer. It is RECOMMENDED to expose relevant information from the QUIC layer to the application instead of exchanging additional RTCP packets, where applicable. and discuss what information can be exposed from the QUIC connection layer to reduce the RTCP overhead. The list of RTCP packets in this section is not exhaustive and similar considerations SHOULD be taken into account before exchanging any other type of RTCP control packets using RoQ. A more complete analysis of RTCP Control Packet Types (in ), Generic RTP Feedback (RTPFB) (in ), Payload-specific RTP Feedback (PSFB) (in ), Extended Reports (in ), and RTP Header Extensions (in ), including the information that cannot be mapped from QUIC.

RoQ Datagrams QUIC Datagrams are ack-eliciting packets, which means, that an acknowledgment is triggered when a datagram frame is received. Thus, a sender can assume that an RTP packet arrived at the receiver or was lost in transit, using the QUIC acknowledgments of QUIC Datagram frames. In the following, an RTP packet is regarded as acknowledged, when the QUIC Datagram frame that carried the RTP packet, was acknowledged.

RoQ Streams For RTP packets that are sent over QUIC streams, an RTP packet can be considered acknowledged, when all frames which carried fragments of the RTP packet were acknowledged. When QUIC Streams are used, the application should be aware that the direct mapping proposed below may not reflect the real characteristics of the network. RTP packet loss can seem lower than actual packet loss due to QUIC's automatic retransmissions. Similarly, timing information might be incorrect due to retransmissions.

Multihop Topologies In some topologies, RoQ may be used on only some of the links between multiple session participants. Other links may be using RTP over UDP, or over some other supported RTP encapsulation protocol, and some participants might be using implementations that don't support RoQ at all. These participants will not be able to infer feedback from QUIC, and they may receive less RTCP feedback than expected. On the other hand, participants using RoQ might not be aware that other participants are not using RoQ and send as little RTCP as possible since they assume their RoQ peer will be able to infer statistics from QUIC. There are two ways to solve this problem: if the middlebox translating between RoQ and RTP over other RTP transport protocols such as UDP or TCP provides Back-to-Back RTP sessions as described in , this middlebox can add RTCP packets for the participants not using RoQ by using the statistics the middlebox gets from QUIC and the mappings described in the following sections. If the middlebox does not provide Back-to-Back RTP sessions, participants may use additional signalling to let the RoQ participants know what RTCP is required.

Transport Layer Feedback This section explains how some of the RTCP packet types which are used to signal reception statistics can be replaced by equivalent statistics that are already collected by QUIC. The following list explains how this mapping can be achieved for the individual fields of different RTCP packet types.

Mapping QUIC Feedback to RTCP Receiver Reports ("RR") Considerations for mapping QUIC feedback into Receiver Reports (PT=201, Name=RR, ) are:

• Fraction lost: When RTP packets are carried in QUIC datagrams, the fraction of lost packets can be directly inferred from QUIC's acknowledgments. The calculation SHOULD include all packets up to the acknowledged RTP packet with the highest RTP sequence number. Later packets SHOULD be ignored, since they may still be in flight, unless other QUIC packets that were sent after the RTP packet, were already acknowledged.
• Cumulative lost: Similar to the fraction of lost packets, the cumulative loss can be inferred from QUIC's acknowledgments including all packets up to the latest acknowledged packet.
• Highest Sequence Number received: In RTCP, this field is a 32-bit field that contains the highest sequence number a receiver received in an RTP packet and the count of sequence number cycles the receiver has observed. A sender sends RTP packets in QUIC packets and receives acknowledgments for the QUIC packets. By keeping a mapping from a QUIC packet to the RTP packets encapsulated in that QUIC packet, the sender can infer the highest sequence number and number of cycles seen by the receiver from QUIC acknowledgments.
• Interarrival jitter: If QUIC acknowledgments carry timestamps as described in , senders can infer the interarrival jitter from the arrival timestamps in QUIC acknowledgments.
• Last SR: Similar to lost packets, the NTP timestamp of the last received sender report can be inferred from QUIC acknowledgments.
• Delay since last SR: This field is not required when the receiver reports are entirely replaced by QUIC feedback.

Mapping QUIC Feedback to RTCP Extended Report ("XR") Extended Reports (PT=207, Name=XR, ) offer an extensible framework for a variety of different control messages. Some of the statistics that are defined as extended report blocks can be derived from QUIC, too. Other report blocks need to be evaluated individually, to determine whether if the contained information can be transmitted using QUIC instead. in lists considerations for mapping QUIC feedback to some of the Extended Reports.

Mapping QUIC Feedback to Generic RTP Feedback ("RTPFB") This section lists considerations for mapping some of the generic RTP feedback types to QUIC.

Negative Acknowledgments ("NACK") Generic Negative Acknowledgments (PT=205, FMT=1, Name=Generic NACK, ) contain information about RTP packets which the receiver considered lost. recommends to use this feature only if the underlying protocol cannot provide similar feedback. QUIC does not provide negative acknowledgments, but can detect lost packets based on the Gap numbers contained in QUIC ACK frames ().

ECN Feedback ("ECN") ECN Feedback (PT=205, FMT=8, Name=RTCP-ECN-FB, ) packets report the count of observed ECN-CE marks. defines two RTCP reports, one packet type (with PT=205 and FMT=8) and a new report block for the extended reports which are listed above. QUIC supports ECN reporting through acknowledgments. If the QUIC connection supports ECN, the reporting of ECN counts SHOULD be done using QUIC acknowledgments, rather than RTCP ECN feedback reports.

Congestion Control Feedback ("CCFB") RTP Congestion Control Feedback (PT=205, FMT=11, Name=CCFB, ) contains acknowledgments, arrival timestamps and ECN notifications for each received packet. Acknowledgments and ECNs can be inferred from QUIC as described above. Arrival timestamps can be added through extended acknowledgment frames as described in or .

Mapping QUIC Connection Close to RTCP Goodbye Packets ("BYE") Goodbye (PT=203, Name=BYE, ) can be replaced by closing the QUIC connection. However, while QUIC allows application layer error codes, they do not carry string values.

Application Layer Repair and other Control Messages While presented some RTCP packets that can be replaced by QUIC features, QUIC cannot replace all of the defined RTCP packet types. This mostly affects RTCP packet types which carry control information that is to be interpreted by the RTP application layer, rather than the underlying transport protocol itself.

• Sender Reports (PT=200, Name=SR, ) are similar to Receiver Reports, as described in . They are sent by media senders and additionally contain an NTP and a RTP timestamp and the number of packets and octets transmitted by the sender. The timestamps can be used by a receiver to synchronize streams. QUIC cannot provide a similar control information, since it does not know about RTP timestamps. Nor can a QUIC receiver calculate the packet or octet counts, since it does not know about lost datagrams. Thus, sender reports are required in RoQ to synchronize streams at the receiver. The sender reports SHOULD not contain any receiver report blocks, as the information can be inferred from the QUIC transport as explained in .

In addition to carrying transmission statistics, RTCP packets can contain application layer control information, that cannot directly be mapped to QUIC. Examples of this information may include:

• Source Description (PT=202, Name=SDES) and Application (PT=204, Name=APP) packet types from , or
• many of the payload specific feedback messages (PT=206) defined in , used to control the codec behavior of the sender.

Since QUIC does not provide any kind of application layer control messaging, QUIC feedback cannot be mapped into these RTCP packet types. If the RTP application needs this information, the RTCP packet types are used in the same way as they would be used over any other transport protocol.

Error Handling The following error codes are defined for use when abruptly terminating streams, aborting reading of streams, or immediately closing RoQ connections.

ROQ_NO_ERROR (0x????):

No error. This is used when the connection or stream needs to be closed, but there is no error to signal.

ROQ_GENERAL_ERROR (0x????):

An error that does not match a more specific error code occured.

ROQ_INTERNAL_ERROR (0x????):

An internal error has occured in the RoQ stack.

ROQ_PACKET_ERROR (0x????):

Invalid payload format, e.g., length does not match packet, invalid flow id encoding, non-RTP on RTP-flow ID, etc.

ROQ_STREAM_CREATION_ERROR (0x????):

The endpoint detected that its peer created a stream that violates the ROQ protocol.

ROQ_FRAME_CANCELLED (0x????):

A receiving endpoint is using STOP_SENDING on the current stream to request new frames be sent on new streams. Similarly, a sender notifies a receiver that retransmissions of a frame were stopped using RESET_STREAM and new frames will be sent on new streams.

ROQ_UNKNOWN_FLOW_ID (0x????):

An endpoint was unable to handle a flow identifier, e.g., because it was not signalled or because the endpoint does not support multiplexing using arbitrary flow identifiers.

ROQ_EXPECTATION_UNMET (0x????):

Expectiations of the QUIC transport set by RoQ out-of-band signalling were not met by the QUIC connection.

API Considerations The mapping described in the previous sections poses some interface requirements on the QUIC implementation. Although a basic mapping should work without any of these requirements most of the optimizations regarding rate adaptation and RTCP mapping require certain functionalities to be exposed to the application. The following to sections contain a list of information that is required by an application to implement different optimizations () and functions that a QUIC implementation SHOULD expose to an application (). Each item in the following list can be considered individually. Any exposed information or function can be used by RoQ regardless of whether the other items are available. Thus, RoQ does not depend on the availability of all of the listed features but can apply different optimizations depending on the functionality exposed by the QUIC implementation.

Information to be exported from QUIC This section provides a list of items that an application might want to export from an underlying QUIC implementation. It is thus RECOMMENDED that a QUIC implementation exports the listed items to the application.

• Maximum Datagram Size: The maximum datagram size that the QUIC connection can transmit.
• Datagram Acknowledgment and Loss: allows QUIC implementations to notify the application that a QUIC Datagram was acknowledged or that it believes a datagram was lost. The exposed information SHOULD include enough information to allow the application to maintain a mapping between the datagram that was acknowledged/lost and the RTP packet that was sent in that datagram.
• Stream States: The QUIC implementation SHOULD expose to a sender, how much of the data that was sent on a stream was successfully delivered and how much data is still outstanding to be sent or retransmitted.
• Arrival timestamps: If the QUIC connection uses a timestamp extension like or , the arrival timestamps or one-way delays SHOULD be exposed to the application.
• Bandwidth Estimation: If congestion control is done at the transport layer in the QUIC implementation, the QUIC implementation SHOULD expose an estimation of the currently available bandwidth to the application. Exposing the bandwidth estimation avoids the implementation of an additional bandwidth estimation algorithm in the application.
• ECN: If ECN marks are available, they SHOULD be exposed to the application.

Functions to be exposed by QUIC This sections lists functions that a QUIC implementation SHOULD expose to an application to implement different features of the mapping described in the previous sections of this document.

• Cancel Streams: To allow an application to cancel (re)transmission of packets that are no longer needed, the QUIC implementation MUST expose a way to cancel the corresponding QUIC streams.
• Configure Congestion Controller: If congestion control is to be implemented at the QUIC connection layer as described in , the QUIC implementation SHOULD expose an API to allow the application to configure the specifics of the congestion controller.

Discussion

Impact of Connection Migration RTP sessions are characterized by a continuous flow of packets into either or both directions. A connection migration may lead to pausing media transmission until reachability of the peer under the new address is validated. This may lead to short breaks in media delivery in the order of RTT and, if RTCP is used for RTT measurements, may cause spikes in observed delays. Application layer congestion control mechanisms (and also packet repair schemes such as retransmissions) need to be prepared to cope with such spikes. If a QUIC connection is established via a signaling channel, this signaling may have involved Interactive Connectivity Establishment (ICE) exchanges to determine and choose suitable (IP address, port number) pairs for the QUIC connection. Subsequent address change events may be noticed by QUIC via its connection migration handling and/or at the ICE or other application layer, e.g., by noticing changing IP addresses at the network interface. This may imply that the two signaling and data "layers" get (temporarily) out of sync.

• Editor's Note: It may be desirable that the API provides an indication of connection migration event for either case.

0-RTT considerations For repeated connections between peers, the initiator of a QUIC connection can use 0-RTT data for both QUIC streams and datagrams. As such packets are subject to replay attacks, applications shall carefully specify which data types and operations are allowed. 0-RTT data may be beneficial for use with RoQ to reduce the risk of media clipping, e.g., at the beginning of a conversation. This specification defines carrying RTP on top of QUIC and thus does not finally define what the actual application data are going to be. RTP typically carries ephemeral media contents that is rendered and possibly recorded but otherwise causes no side effects. Moreover, the amount of data that can be carried as 0-RTT data is rather limited. But it is the responsibility of the respective application to determine if 0-RTT data is permissible.

• Editor's Note: Since the QUIC connection will often be created in the context of an existing signaling relationship (e.g., using WebRTC or SIP), specific 0-RTT keying material could be exchanged to prevent replays across sessions. Within the same connection, replayed media packets would be discarded as duplicates by the receiver.

Security Considerations RoQ is subject to the security considerations of RTP described in and the security considerations of any RTP profile in use. The security considerations for the QUIC protocol and datagram extension described in , , and also apply to RoQ. Note that RoQ provides mandatory security, and other RTP transports do not. In order to prevent the inadvertent disclosure of RTP sessions to unintended third parties, RTP topologies described in that include middleboxes supporting both RoQ and non-RoQ paths MUST forward RTP packets on non-RoQ paths using a secure AVP profile (, , or another AVP profile providing equivalent RTP-level security), whether or not RoQ senders are using a secure AVP profile for those RTP packets.

IANA Considerations

Registration of a RoQ Identification String This document creates a new registration for the identification of RoQ in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry . The "rtp-mux-quic" string identifies RoQ:

Protocol:

RTP over QUIC (RoQ)

Identification Sequence:

0x72 0x74 0x70 0x2D 0x6F 0x76 0x65 0x72 0x2D 0x71 0x75 0x69 0x63 ("rtp-mux-quic")

Specification:

This document

RoQ Error Codes This document establishes a registry for RoQ error codes.

Name	Value	Description	Specification
ROQ_NO_ERROR	0x????	No Error	TODO: This doc
ROQ_GENERAL_ERROR	0x????	General error	TODO: This doc
ROQ_INTERNAL_ERROR	0x????	Internal Error	TODO: This doc
ROQ_PACKET_ERROR	0x????	Invalid payload format	TODO: This doc
ROQ_STREAM_CREATION_ERROR	0x????	Invalid stream type	TODO: This doc
ROQ_FRAME_CANCELLED	0x????	Frame cancelled	TODO: This doc
ROQ_UNKNOWN_FLOW_ID	0x????	Unknown Flow ID	TODO: This doc
ROQ_EXPECTATION_UNMET	0x????	Externally signalled requirement unmet	TODO: This doc

References Normative References This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK] This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document defines the properties of the QUIC transport protocol that are common to all versions of the protocol. This document describes how Transport Layer Security (TLS) is used to secure QUIC. This document describes loss detection and congestion control mechanisms for QUIC. This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection. This document discusses point-to-point and multi-endpoint topologies used in environments based on the Real-time Transport Protocol (RTP). In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology. This document describes a profile called "RTP/AVP" for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. This memorandum obsoletes RFC 1890. It is mostly backwards-compatible except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes Network-Assisted Dynamic Adaptation (NADA), a novel congestion control scheme for interactive real-time media applications such as video conferencing. In the proposed scheme, the sender regulates its sending rate, based on either implicit or explicit congestion signaling, in a unified approach. The scheme can benefit from Explicit Congestion Notification (ECN) markings from network nodes. It also maintains consistent sender behavior in the absence of such markings by reacting to queuing delays and packet losses instead. This memo describes a rate adaptation algorithm for conversational media services such as interactive video. The solution conforms to the packet conservation principle and uses a hybrid loss-and-delay- based congestion control algorithm. The algorithm is evaluated over both simulated Internet bottleneck scenarios as well as in a Long Term Evolution (LTE) system simulator and is shown to achieve both low latency and high video throughput in these scenarios. This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection. RTP retransmission is an effective packet loss recovery technique for real-time applications with relaxed delay bounds. This document describes an RTP payload format for performing retransmissions. Retransmitted RTP packets are sent in a separate stream from the original RTP stream. It is assumed that feedback from receivers to senders is available. In particular, it is assumed that Real-time Transport Control Protocol (RTCP) feedback as defined in the extended RTP profile for RTCP-based feedback (denoted RTP/AVPF) is available in this memo. [STANDARDS-TRACK] Congestion control is needed for all data transported across the Internet, in order to promote fair usage and prevent congestion collapse. The requirements for interactive, point-to-point real-time multimedia, which needs low-delay, semi-reliable data delivery, are different from the requirements for bulk transfer like FTP or bursty transfers like web pages. Due to an increasing amount of RTP-based real-time media traffic on the Internet (e.g., with the introduction of the Web Real-Time Communication (WebRTC)), it is especially important to ensure that this kind of traffic is congestion controlled. This document describes a set of requirements that can be used to evaluate other congestion control mechanisms in order to figure out their fitness for this purpose, and in particular to provide a set of possible requirements for a real-time media congestion avoidance technique. Magic Leap, Inc. Google LLC This document defines an extension to the QUIC transport protocol which supports reporting multiple packet receive timestamps using a new ACK_RECEIVE_TIMESTAMPS frame type. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the QUIC Working Group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Source for this draft and an issue tracker can be found at https://github.com/wcsmith/draft-quic-receive-ts. Private Octopus Inc. The TIMESTAMP frame can be added to Quic packets when one way delay measurements are useful. The timestamp is set to the number of microseconds from the beginning of the node's epoch to the time at which the packet is sent. The draft defines the "enable_timestamp" transport parameter for negotiating the use of this extension frame, and the TIMESTAMP frame. An effective RTP congestion control algorithm requires more fine-grained feedback on packet loss, timing, and Explicit Congestion Notification (ECN) marks than is provided by the standard RTP Control Protocol (RTCP) Sender Report (SR) and Receiver Report (RR) packets. This document describes an RTCP feedback message intended to enable congestion control for interactive real-time traffic using RTP. The feedback message is designed for use with a sender-based congestion control algorithm, in which the receiver of an RTP flow sends back to the sender RTCP feedback packets containing the information the sender needs to perform congestion control. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. Fastly Google Ericsson This document describes a QUIC extension for an endpoint to control its peer's delaying of acknowledgements. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic. Source code and issues list for this draft can be found at https://github.com/quicwg/ack-frequency. Working Group information can be found at https://github.com/quicwg. This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides. Real-time media streams that use RTP are, to some degree, resilient against packet losses. Receivers may use the base mechanisms of the Real-time Transport Control Protocol (RTCP) to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term. This is the sole means for feedback and feedback-based error repair (besides a few codec-specific mechanisms). This document defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups. [STANDARDS-TRACK] This memo specifies how Explicit Congestion Notification (ECN) can be used with the Real-time Transport Protocol (RTP) running over UDP, using the RTP Control Protocol (RTCP) as a feedback mechanism. It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT (STUN) extension used in the optional initialisation method using Interactive Connectivity Establishment (ICE). Signalling and procedures for negotiation of capabilities and initialisation methods are also defined. [STANDARDS-TRACK] Informative References This document discusses the applicability of the QUIC transport protocol, focusing on caveats impacting application protocol development and deployment over QUIC. Its intended audience is designers of application protocol mappings to QUIC and implementors of these application protocols. This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK] While the Secure Real-time Transport Protocol (SRTP) provides confidentiality for the contents of a media packet, a significant amount of metadata is left unprotected, including RTP header extensions and contributing sources (CSRCs). However, this data can be moderately sensitive in many applications. While there have been previous attempts to protect this data, they have had limited deployment, due to complexity as well as technical limitations. This document updates RFC 3711, the SRTP specification, and defines Cryptex as a new mechanism that completely encrypts header extensions and CSRCs and uses simpler Session Description Protocol (SDP) signaling with the goal of facilitating deployment. The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in these applications, then network congestion can lead to uncontrolled packet loss and a resulting deterioration of the user's multimedia experience. The congestion control algorithm acts as a safety measure by stopping RTP flows from using excessive resources and protecting the network from overload. At the time of this writing, however, while there are several proprietary solutions, there is no standard algorithm for congestion control of interactive RTP flows. This document does not propose a congestion control algorithm. It instead defines a minimal set of RTP circuit breakers: conditions under which an RTP sender needs to stop transmitting media data to protect the network from excessive congestion. It is expected that, in the absence of long-lived excessive congestion, RTP applications running on best-effort IP networks will be able to operate without triggering these circuit breakers. To avoid triggering the RTP circuit breaker, any Standards Track congestion control algorithms defined for RTP will need to operate within the envelope set by these RTP circuit breaker algorithms. This document specifies Datagram Packetization Layer Path MTU Discovery (DPLPMTUD). This is a robust method for Path MTU Discovery (PMTUD) for datagram Packetization Layers (PLs). It allows a PL, or a datagram application that uses a PL, to discover whether a network path can support the current size of datagram. This can be used to detect and reduce the message size when a sender encounters a packet black hole. It can also probe a network path to discover whether the maximum packet size can be increased. This provides functionality for datagram transports that is equivalent to the PLPMTUD specification for TCP, specified in RFC 4821, which it updates. It also updates the UDP Usage Guidelines to refer to this method for use with UDP datagrams and updates SCTP. The document provides implementation notes for incorporating Datagram PMTUD into IETF datagram transports or applications that use datagram transports. This specification updates RFC 4960, RFC 4821, RFC 6951, RFC 8085, and RFC 8261. This memo describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path. It specifies a small change to the way routers generate one type of ICMP message. For a path that passes through a router that has not been so changed, this technique might not discover the correct Path MTU, but it will always choose a Path MTU as accurate as, and in many cases more accurate than, the Path MTU that would be chosen by current practice. [STANDARDS-TRACK] This document describes Path MTU Discovery (PMTUD) for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4. It obsoletes RFC 1981. Alibaba Inc. Alibaba Inc. UCLouvain UCLouvain and Tessares Private Octopus Inc. Ericsson This document specifies a multipath extension for the QUIC protocol to enable the simultaneous usage of multiple paths for a single connection. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the QUIC Working Group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Source for this draft and an issue tracker can be found at https://github.com/mirjak/draft-lmbdhk-quic-multipath. This memorandum defines the Real-Time Streaming Protocol (RTSP) version 2.0, which obsoletes RTSP version 1.0 defined in RFC 2326. RTSP is an application-layer protocol for the setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions; provide a means for choosing delivery channels such as UDP, multicast UDP, and TCP; and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550). Tencent America LLC This document describes these new SDP "proto" attribute values: "QUIC", "QUIC/RTP/SAVP", "QUIC/RTP/AVPF", and "QUIC/RTP/SAVPF", and describes how SDP Offer/Answer can be used to set up an RTP connection using QUIC as a transport protocol. These proto values are necessary to allow the use of QUIC as an underlying transport protocol for applications such as SIP and WebRTC that commonly use SDP as a session signaling protocol to set up RTP connections. This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK] This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web". It intends to serve as a starting and coordination point to make sure that (1) all the parts that are needed to achieve this goal are findable and (2) the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This document is an applicability statement -- it does not itself specify any protocol, but it specifies which other specifications implementations are supposed to follow to be compliant with Web Real-Time Communication (WebRTC). Millicast CoSMo Software This document describes a simple HTTP-based protocol that will allow WebRTC-based ingestion of content into streaming services and/or CDNs. This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK] Google LLC Cloudflare This document describes HTTP Datagrams, a convention for conveying multiplexed, potentially unreliable datagrams inside an HTTP connection. In HTTP/3, HTTP Datagrams can be sent unreliably using the QUIC DATAGRAM extension. When the QUIC DATAGRAM frame is unavailable or undesirable, HTTP Datagrams can be sent using the Capsule Protocol, which is a more general convention for conveying data in HTTP connections. HTTP Datagrams and the Capsule Protocol are intended for use by HTTP extensions, not applications. The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. This document specifies how an RTP session can contain RTP streams with media from multiple media types such as audio, video, and text. This has been restricted by the RTP specifications (RFCs 3550 and 3551), and thus this document updates RFCs 3550 and 3551 to enable this behaviour for applications that satisfy the applicability for using multiple media types in a single RTP session. This memo discusses issues that arise when multiplexing RTP data packets and RTP Control Protocol (RTCP) packets on a single UDP port. It updates RFC 3550 and RFC 3551 to describe when such multiplexing is and is not appropriate, and it explains how the Session Description Protocol (SDP) can be used to signal multiplexed sessions. [STANDARDS-TRACK] Protocol Labs Fastly QUIC ([RFC9000]) defines a RESET_STREAM frame to reset a stream. When a sender resets a stream, it stops retransmitting STREAM frames for this stream. On the receiver side, there is no guarantee that any of the data sent on that stream is delivered to the application. This document defines a new QUIC frame, the CLOSE_STREAM frame, that allows closing and resetting of a stream, while guaranteeing reliable delivery of stream data up to a certain byte offset. Mozilla Sending on QUIC streams can only be aborted early by the sender with a RESET_STREAM frame. This document describes how a receiver can indicate when the data they have received is enough, allowing the sender to reliably deliver some data, but abort sending for anything more than the indicated amount. Google Google Politecnico di Bari Politecnico di Bari Politecnico di Bari This document describes two methods of congestion control when using real-time communications on the World Wide Web (RTCWEB); one delay- based and one loss-based. It is published as an input document to the RMCAT working group on congestion control for media streams. The mailing list of that working group is rmcat@ietf.org. RFC 5681 documents the following four intertwined TCP congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. RFC 5681 explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgment (SACK) option (RFC 2883), and modifications that respond to "partial acknowledgments" (ACKs that cover new data, but not all the data outstanding when loss was detected) in the absence of SACK. This document describes a specific algorithm for responding to partial acknowledgments, referred to as "NewReno". This response to partial acknowledgments was first proposed by Janey Hoe. This document obsoletes RFC 3782. [STANDARDS-TRACK] The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports. Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP. Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control. This document obsoletes RFC 5405 and adds guidelines for multicast UDP usage. Google This document proposes an RTCP message for use in experimentally- deployed congestion control algorithms for RTP-based media flows. It also describes an absolute-value timestamp option for use in bandwidth estimatoin. Google Google Google Google Google This document specifies the BBR congestion control algorithm. BBR ("Bottleneck Bandwidth and Round-trip propagation time") uses recent measurements of a transport connection's delivery rate, round-trip time, and packet loss rate to build an explicit model of the network path. BBR then uses this model to control both how fast it sends data and the maximum volume of data it allows in flight in the network at any time. Relative to loss-based congestion control algorithms such as Reno [RFC5681] or CUBIC [RFC8312], BBR offers substantially higher throughput for bottlenecks with shallow buffers or random losses, and substantially lower queueing delays for bottlenecks with deep buffers (avoiding "bufferbloat"). BBR can be implemented in any transport protocol that supports packet-delivery acknowledgment. Thus far, open source implementations are available for TCP [RFC793] and QUIC [RFC9000]. This document specifies version 2 of the BBR algorithm, also sometimes referred to as BBRv2 or bbr2. Mozilla Sending on QUIC streams can only be aborted early by the sender with a RESET_STREAM frame. This document describes how a receiver can indicate when the data they have received is enough, allowing the sender to reliably deliver some data, but abort sending for anything more than the indicated amount. Protocol Labs Fastly QUIC (RFC9000) defines a RESET_STREAM frame to reset a stream. When a sender resets a stream, it stops retransmitting STREAM frames for this stream. On the receiver side, there is no guarantee that any of the data sent on that stream is delivered to the application. This document defines a new QUIC frame, the CLOSE_STREAM frame, that allows resetting of a stream, while guaranteeing reliable delivery of stream data up to a certain byte offset. This document describes a mechanism for associating \%time-codes, as defined by the Society of Motion Picture and Television Engineers (SMPTE), with media streams in a way that is independent of the RTP payload format of the media stream itself. [STANDARDS-TRACK] This document describes a method to inform Real-time Transport Protocol (RTP) clients when RTP packets are transmitted at a time other than their 'nominal' transmission time. It also provides a mechanism to provide improved inter-arrival jitter reports from the clients, that take into account the reported transmission times. [STANDARDS-TRACK] This document specifies an extension to the Real-time Transport Control Protocol (RTCP) to use unicast feedback to a multicast sender. The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism. [STANDARDS-TRACK] This document presents a port mapping solution that allows RTP receivers to choose their own ports for an auxiliary unicast session in RTP applications using both unicast and multicast services. The solution provides protection against denial-of-service or packet amplification attacks that could be used to cause one or more RTP packets to be sent to a victim client. [STANDARDS-TRACK] This document defines a new RTP Control Protocol (RTCP) Packet Type and an RTCP Extended Report (XR) Block Type to be used for achieving Inter-Destination Media Synchronization (IDMS). IDMS is the process of synchronizing playout across multiple media receivers. Using the RTCP XR IDMS Report Block defined in this document, media playout information from participants in a synchronization group can be collected. Based on the collected information, an RTCP IDMS Settings Packet can then be sent to distribute a common target playout point to which all the distributed receivers, sharing a media experience, can synchronize. Typical use cases in which IDMS is useful are social TV, shared service control (i.e., applications where two or more geographically separated users are watching a media stream together), distance learning, networked video walls, networked loudspeakers, etc. RTP allows multiple RTP streams to be sent in a single session but requires each Synchronization Source (SSRC) to send RTP Control Protocol (RTCP) reception quality reports for every other SSRC visible in the session. This causes the number of RTCP reception reports to grow with the number of SSRCs, rather than the number of endpoints. In many cases, most of these RTCP reception reports are unnecessary, since all SSRCs of an endpoint are normally co-located and see the same reception quality. This memo defines a Reporting Group extension to RTCP to reduce the reporting overhead in such scenarios. Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content and that delivers the substitutive multimedia content to the receivers for a period of time. The splicer is designed to handle RTP splicing and needs to know when to start and end the splicing. This memo defines two RTP/RTCP extensions to indicate the splicing-related information to the splicer: an RTP header extension that conveys the information "in band" and an RTP Control Protocol (RTCP) packet that conveys the information out of band. This document describes an RTCP XR report block, which reports packet transport parameters. The report block was developed by BT for pre-standards use in BT's next-generation network. This document has been produced to describe the report block in sufficient detail to register the block type with IANA in accordance with the Specification Required policy of RFC 3611. This specification does not standardise the new report block for use outside BT's network. This memo provides information for the Internet community. This document defines a new report block type within the framework of RTP Control Protocol (RTCP) Extended Reports (XRs). One of the initial XR report block types is the Loss Run Length Encoding (RLE) Report Block. This report conveys information regarding the individual Real-time Transport Protocol (RTP) packet receipt and loss events experienced during the RTCP interval preceding the transmission of the report. The new report, which is referred to as the Post-repair Loss RLE report, carries information regarding the packets that remain lost after all loss-repair methods are applied. By comparing the RTP packet receipts/losses before and after the loss repair is completed, one can determine the effectiveness of the loss- repair methods in an aggregated fashion. This document also defines the signaling of the Post-repair Loss RLE report in the Session Description Protocol (SDP). [STANDARDS-TRACK] In most RTP-based multicast applications, the RTP source sends inter- related data. Due to this interdependency, randomly joining RTP receivers usually cannot start consuming the multicast data right after they join the session. Thus, they often experience a random acquisition delay. An RTP receiver can use one or more different approaches to achieve rapid acquisition. Yet, due to various factors, performance of the rapid acquisition methods usually varies. Furthermore, in some cases, the RTP receiver can do a simple multicast join (in other cases, it is compelled to do so). For quality reporting, monitoring, and diagnostic purposes, it is important to collect detailed information from the RTP receivers about their acquisition and presentation experiences. This document addresses this issue by defining a new report block type, called the Multicast Acquisition (MA) report block, within the framework of RTP Control Protocol (RTCP) Extended Reports (XRs) (RFC 3611). This document also defines the necessary signaling of the new MA report block type in the Session Description Protocol (SDP). [STANDARDS-TRACK] This document defines an RTP Control Protocol (RTCP) Source Description (SDES) item and an RTCP Extended Report (XR) block carrying parameters that identify and describe a measurement period to which one or more other RTCP XR blocks may refer. [STANDARDS-TRACK] This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of packet delay variation metrics for a range of RTP applications. [STANDARDS-TRACK] This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of delay metrics for use in a range of Real-time Transport Protocol (RTP) applications. [STANDARDS-TRACK] This document defines three RTP Control Protocol (RTCP) Extended Report (XR) blocks that allow the reporting of loss, duplication, and discard summary statistics metrics in a range of RTP applications. This document defines an RTP Control Protocol (RTCP) Extended Report (XR) Block that allows the reporting of burst and gap loss metrics for use in a range of RTP applications. This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of burst and gap discard metrics for use in a range of RTP applications. An MPEG-2 Transport Stream (TS) is a standard container format used in the transmission and storage of multimedia data. Unicast/ multicast MPEG-2 TS over RTP is widely deployed in IPTV systems. This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of MPEG-2 TS decodability statistics metrics related to transmissions of MPEG-2 TS over RTP. The metrics specified in the RTCP XR block are not dependent on Program Specific Information (PSI) carried in MPEG-2 TS. This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of de-jitter buffer metrics for a range of RTP applications. This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of a simple discard count metric for use in a range of RTP applications. The RTP Control Protocol (RTCP) is used in conjunction with the Real- time Transport Protocol (RTP) in order to provide a variety of short- term and long-term reception statistics. The available reporting may include aggregate information across longer periods of time as well as individual packet reporting. This document specifies a per-packet report metric capturing individual packets discarded from the de- jitter buffer after successful reception. The RTP Control Protocol (RTCP) is used in conjunction with the Real-time Transport Protocol (RTP) to provide a variety of short-term and long-term reception statistics. The available reporting may include aggregate information across longer periods of time as well as individual packet reporting. This document specifies a report computing the bytes discarded from the de-jitter buffer after successful reception. This document defines two RTP Control Protocol (RTCP) Extended Report (XR) blocks that allow the reporting of initial synchronization delay and synchronization offset metrics for use in a range of RTP applications. This document defines an RTP Control Protocol (RTCP) Extended Report (XR) Block including two new segment types and associated Session Description Protocol (SDP) parameters that allow the reporting of mean opinion score (MOS) Metrics for use in a range of RTP applications. This document defines two RTP Control Protocol (RTCP) Extended Report (XR) blocks that allow the reporting of concealment metrics for audio applications of RTP. An MPEG2 Transport Stream (TS) is a standard container format used in the transmission and storage of multimedia data. Unicast/multicast MPEG2 TS over RTP is widely deployed in IPTV systems. This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of MPEG2 TS decodability statistics metrics related to transmissions of MPEG2 TS over RTP. The metrics specified in the RTCP XR block are related to Program Specific Information (PSI) carried in MPEG TS. This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows reporting of a post-repair loss count metric for a range of RTP applications. In addition, another metric, repaired loss count, is also introduced in this report block for calculating the pre-repair loss count when needed, so that the RTP sender or a third-party entity is able to evaluate the effectiveness of the repair methods used by the system. This document defines a new RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of loss concealment metrics for video applications of RTP. This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of burst/gap discard metrics independently of the burst/gap loss metrics for use in a range of RTP applications. This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments and point-to-point calls. The extensions discussed are messages related to the ITU-T Rec. H.271 Video Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit Rate, and Temporal-Spatial Trade-off. [STANDARDS-TRACK] This memo outlines how RTP sessions are synchronised, and discusses how rapidly such synchronisation can occur. We show that most RTP sessions can be synchronised immediately, but that the use of video switching multipoint conference units (MCUs) or large source-specific multicast (SSM) groups can greatly increase the synchronisation delay. This increase in delay can be unacceptable to some applications that use layered and/or multi-description codecs. This memo introduces three mechanisms to reduce the synchronisation delay for such sessions. First, it updates the RTP Control Protocol (RTCP) timing rules to reduce the initial synchronisation delay for SSM sessions. Second, a new feedback packet is defined for use with the extended RTP profile for RTCP-based feedback (RTP/AVPF), allowing video switching MCUs to rapidly request resynchronisation. Finally, new RTP header extensions are defined to allow rapid synchronisation of late joiners, and guarantee correct timestamp-based decoding order recovery for layered codecs in the presence of clock skew. [STANDARDS-TRACK] When an RTP receiver joins a multicast session, it may need to acquire and parse certain Reference Information before it can process any data sent in the multicast session. Depending on the join time, length of the Reference Information repetition (or appearance) interval, size of the Reference Information, and the application and transport properties, the time lag before an RTP receiver can usefully consume the multicast data, which we refer to as the Acquisition Delay, varies and can be large. This is an undesirable phenomenon for receivers that frequently switch among different multicast sessions, such as video broadcasts. In this document, we describe a method using the existing RTP and RTP Control Protocol (RTCP) machinery that reduces the acquisition delay. In this method, an auxiliary unicast RTP session carrying the Reference Information to the receiver precedes or accompanies the multicast stream. This unicast RTP flow can be transmitted at a faster than natural bitrate to further accelerate the acquisition. The motivating use case for this capability is multicast applications that carry real-time compressed audio and video. However, this method can also be used in other types of multicast applications where the acquisition delay is long enough to be a problem. [STANDARDS-TRACK] In a large RTP session using the RTP Control Protocol (RTCP) feedback mechanism defined in RFC 4585, a feedback target may experience transient overload if some event causes a large number of receivers to send feedback at once. This overload is usually avoided by ensuring that feedback reports are forwarded to all receivers, allowing them to avoid sending duplicate feedback reports. However, there are cases where it is not recommended to forward feedback reports, and this may allow feedback implosion. This memo discusses these cases and defines a new RTCP Third-Party Loss Report that can be used to inform receivers that the feedback target is aware of some loss event, allowing them to suppress feedback. Associated Session Description Protocol (SDP) signaling is also defined. [STANDARDS-TRACK] With the increased popularity of real-time multimedia applications, it is desirable to provide good control of resource usage, and users also demand more control over communication sessions. This document describes how a receiver in a multimedia conversation can pause and resume incoming data from a sender by sending real-time feedback messages when using the Real-time Transport Protocol (RTP) for real- time data transport. This document extends the Codec Control Message (CCM) RTP Control Protocol (RTCP) feedback package by explicitly allowing and describing specific use of existing CCMs and adding a group of new real-time feedback messages used to pause and resume RTP data streams. This document updates RFC 5104. Vidyo, Inc. Vidyo, Inc. Google, Inc. Google, Inc. Google, Inc. This memo describes the RTCP Payload-Specific Feedback Message "Layer Refresh Request" (LRR), which can be used to request a state refresh of one or more substreams of a layered media stream. It also defines its use with several RTP payloads for scalable media formats. Qualcomm FAU InterDigital This specification describes an RTCP feedback message format for the ISO/IEC International Standard 23001-11, known as Energy Efficient Media Consumption (Green metadata), developed by the ISO/IEC JTC 1/SC 29/ WG 3 MPEG System. The RTCP payload format specified in this specification enables receivers to provide feedback to the senders and thus allows for short-term adaptation and feedback-based energy efficient mechanisms to be implemented. The payload format has broad applicability in real-time video communication services. This document defines a mechanism by which packets of Real-time Transport Protocol (RTP) audio streams can indicate, in an RTP header extension, the audio level of the audio sample carried in the RTP packet. In large conferences, this can reduce the load on an audio mixer or other middlebox that wants to forward only a few of the loudest audio streams, without requiring it to decode and measure every stream that is received. [STANDARDS-TRACK] Source Description (SDES) items are normally transported in the RTP Control Protocol (RTCP). In some cases, it can be beneficial to speed up the delivery of these items. The main case is when a new synchronization source (SSRC) joins an RTP session and the receivers need this source's identity, relation to other sources, or its synchronization context, all of which may be fully or partially identified using SDES items. To enable this optimization, this document specifies a new RTP header extension that can carry SDES items. The Secure Real-time Transport Protocol (SRTP) provides authentication, but not encryption, of the headers of Real-time Transport Protocol (RTP) packets. However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality. This document provides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP header extensions in SRTP. This document updates RFC 3711, the Secure Real-time Transport Protocol specification, to require that all future SRTP encryption transforms specify how RTP header extensions are to be encrypted. This document describes a mechanism for RTP-level mixers in audio conferences to deliver information about the audio level of individual participants. Such audio level indicators are transported in the same RTP packets as the audio data they pertain to. [STANDARDS-TRACK] This document defines and registers two new Real-time Transport Control Protocol (RTCP) Stream Identifier Source Description (SDES) items. One, named RtpStreamId, is used for unique identification of RTP streams. The other, RepairedRtpStreamId, can be used to identify which stream is to be repaired using a redundancy RTP stream. This document describes how the Real-time Transport Protocol (RTP) is used in the context of the Controlling Multiple Streams for Telepresence (CLUE) protocol. It also describes the mechanisms and recommended practice for mapping RTP media streams, as defined in the Session Description Protocol (SDP), to CLUE Media Captures and defines a new RTP header extension (CaptureID). This specification defines a new Session Description Protocol (SDP) Grouping Framework extension called 'BUNDLE'. The extension can be used with the SDP offer/answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a "BUNDLE transport", and the media is referred to as "bundled media". The "m=" sections that use the BUNDLE transport form a BUNDLE group. This specification defines a new RTP Control Protocol (RTCP) Source Description (SDES) item and a new RTP header extension. This specification updates RFCs 3264, 5888, and 7941. This specification obsoletes RFC 8843. QUIC is a UDP-based transport protocol for stream-orientated, congestion-controlled, secure, multiplexed data transfer. RTP carries real-time data between endpoints, and the accompanying control protocol RTCP allows monitoring and control of the transfer of such data. With RTP and RTCP being agnostic to the underlying transport protocol, it is possible to multiplex both the RTP and associated RTCP flows into a single QUIC connection to take advantage of QUIC features such as low-latency setup and strong TLS-based security.

List of optional QUIC Extensions The following is a list of QUIC protocol extensions that might be beneficial for RoQ, but are not required by RoQ.

• An Unreliable Datagram Extension to QUIC . Without support for unreliable datagrams, RoQ cannot use the encapsulation specified in , but can still use QUIC streams as specified in .
• A version of QUIC receive timestamps can be helpful for improved jitter calculations and congestion control.
  • Quic Timestamps For Measuring One-Way Delays
  • QUIC Extension for Reporting Packet Receive Timestamps
• QUIC Acknowledgement Frequency can be used by a sender to optimize the acknowledgement behaviour of the receiver, e.g., to optimize congestion control.
• Signaling That a QUIC Receiver Has Enough Stream Data and Reliable QUIC Stream Resets would allow RoQ senders and receivers to use versions of CLOSE_STREAM and STOP_SENDING that contain offsets. The offset could be used to reliably retransmit all frames up to a certain frame that should be cancelled before resuming transmission of further frames on new QUIC streams.

Considered RTCP Packet Types and RTP Header Extensions This section lists all the RTCP packet types and RTP header extensions that were considered in the analysis described in . Several but not all of these control packets and their attributes can be mapped from QUIC, as described in . Mappable from QUIC has one of four values: yes, partly, QUIC extension needed, and no. Partly is used for packet types for which some fields can be mapped from QUIC, but not all. QUIC extension needed describes packet types which could be mapped with help from one or more QUIC extensions.

RTCP Control Packet Types

Name	Shortcut	PT	Defining Document	Mappable from QUIC	Comments
SMPTE time-code mapping	SMPTETC	194		no
Extended inter-arrival jitter report	IJ	195		no	Would require send-timestamps, which are not provided by any QUIC extension today
Sender Reports	SR	200		QUIC extension needed / partly	see and
Receiver Reports	RR	201		QUIC extension needed	see
Source description	SDES	202		no
Goodbye	BYE	203		partly	see
Application-defined	APP	204		no
Generic RTP Feedback	RTPFB	205		partly	see
Payload-specific	PSFB	205		partly	see
extended report	XR	207		partly	see
AVB RTCP packet	AVB
Receiver Summary Information	RSI	209
Port Mapping	TOKEN	210		no
IDMS Settings	IDMS	211		no
Reporting Group Reporting Sources	RGRS	212
Splicing Notification Message	SNM	213		no

Extended Reports (XR) Extended Report Blocks

Name	Document	Mappable from QUIC	Comments
Loss RLE Report Block		yes	If only used for acknowledgment, could be replaced by QUIC acknowledgments, see and
Duplicate RLE Report Block		no
Packet Receipt Times Report Block		QUIC extension needed / partly	QUIC could provide packet receive timestamps when using a timestamp extension that reports timestamp for every received packet, such as . However, QUIC does not provide feedback in RTP timestamp format.
Receiver Reference Time Report Block		QUIC extension needed	Used together with DLRR Report Blocks to calculate RTTs of non-senders. RTT measurements can natively be provided by QUIC.
DLRR Report Block		QUIC extension needed	Used together with Receiver Reference Time Report Blocks to calculate RTTs of non-senders. RTT can natively be provided by QUIC.
Statistics Summary Report Block		QUIC extension needed / partly	Packet loss and jitter can be inferred from QUIC acknowledgments, if a timestamp extension is used (see or ). The remaining fields cannot be mapped to QUIC.
VoIP Metrics Report Block		no	as in other reports above, only loss and RTT available
RTCP XR		no
Texas Instruments Extended VoIP Quality Block
Post-repair Loss RLE Report Block		no
Multicast Acquisition Report Block		no
IDMS Report Block		no
ECN Summary Report		partly	see
Measurement Information Block		no
Packet Delay Variation Metrics Block		no	QUIC timestamps may be used to achieve the same goal?
Delay Metrics Block		no	QUIC has RTT and can provide timestamps for one-way delay, but no way of informing peers about end-to-end statistics when QUIC is only used on one segment of the path.
Burst/Gap Loss Summary Statistics Block			QUIC ACKs?
Burst/Gap Discard Summary Statistics Block		no
Frame Impairment Statistics Summary		no
Burst/Gap Loss Metrics Block			QUIC ACKs?
Burst/Gap Discard Metrics Block		no
MPEG2 Transport Stream PSI-Independent Decodability Statistics Metrics Block		no
De-Jitter Buffer Metrics Block		no
Discard Count Metrics Block		no
DRLE (Discard RLE Report)		no
BDR (Bytes Discarded Report)		no
RFISD (RTP Flows Initial Synchronization Delay)		no
RFSO (RTP Flows Synchronization Offset Metrics Block)		no
MOS Metrics Block		no
LCB (Loss Concealment Metrics Block)		no
CSB (Concealed Seconds Metrics Block)		no
MPEG2 Transport Stream PSI Decodability Statistics Metrics Block		no
Post-Repair Loss Count Metrics Report Block		no
Video Loss Concealment Metric Report Block		no
Independent Burst/Gap Discard Metrics Block		no

Generic RTP Feedback (RTPFB)

Name	Long Name	Document	Mappable from QUIC	Comments
Generic NACK	Generic negative acknowledgement		partly	see
TMMBR	Temporary Maximum Media Stream Bit Rate Request		no
TMMBN	Temporary Maximum Media Stream Bit Rate Notification		no
RTCP-SR-REQ	RTCP Rapid Resynchronisation Request		no
RAMS	Rapid Acquisition of Multicast Sessions		no
TLLEI	Transport-Layer Third-Party Loss Early Indication		no?	no way of telling QUIC peer "don't ask for retransmission", but QUIC would not ask that anyway, only RTCP NACK?
RTCP-ECN-FB	RTCP ECN Feedback		partly	see
PAUSE-RESUME	Media Pause/Resume		no
DBI	Delay Budget Information (DBI)
CCFB	RTP Congestion Control Feedback		QUIC extension needed	see

Payload-specific RTP Feedback (PSFB) Because QUIC is a generic transport protocol, QUIC feedback cannot replace the following Payload-specific RTP Feedback (PSFB) feedback.

Name	Long Name	Document
PLI	Picture Loss Indication
SLI	Slice Loss Indication
RPSI	Reference Picture Selection Indication
FIR	Full Intra Request Command
TSTR	Temporal-Spatial Trade-off Request
TSTN	Temporal-Spatial Trade-off Notification
VBCM	Video Back Channel Message
PSLEI	Payload-Specific Third-Party Loss Early Indication
ROI	Video region-of-interest (ROI)
LRR	Layer Refresh Request Command
VP	Viewport (VP)
AFB	Application Layer Feedback
TSRR	Temporal-Spatial Resolution Request
TSRN	Temporal-Spatial Resolution Notification

RTP Header extensions Like the payload-specific feedback packets, QUIC cannot directly replace the control information in the following header extensions. RoQ does not place restrictions on sending any RTP header extensions. However, some extensions, such as Transmission Time offsets are used to improve network jitter calculation, which can be done in QUIC if a timestamp extension is used.

Compact Header Extensions

Extension URI	Description	Reference	Mappable from QUIC
urn:ietf:params:rtp-hdrext:toffset	Transmission Time offsets		no
urn:ietf:params:rtp-hdrext:ssrc-audio-level	Audio Level		no
urn:ietf:params:rtp-hdrext:splicing-interval	Splicing Interval		no
urn:ietf:params:rtp-hdrext:smpte-tc	SMPTE time-code mapping		no
urn:ietf:params:rtp-hdrext:sdes	Reserved as base URN for RTCP SDES items that are also defined as RTP compact header extensions.		no
urn:ietf:params:rtp-hdrext:ntp-64	Synchronisation metadata: 64-bit timestamp format		no
urn:ietf:params:rtp-hdrext:ntp-56	Synchronisation metadata: 56-bit timestamp format		no
urn:ietf:params:rtp-hdrext:encrypt	Encrypted extension header element		no, but maybe irrelevant?
urn:ietf:params:rtp-hdrext:csrc-audio-level	Mixer-to-client audio level indicators		no
urn:3gpp:video-orientation:6	Higher granularity (6-bit) coordination of video orientation (CVO) feature, see clause 6.2.3		probably not(?)
urn:3gpp:video-orientation	Coordination of video orientation (CVO) feature, see clause 6.2.3		probably not(?)
urn:3gpp:roi-sent	Signalling of the arbitrary region-of-interest (ROI) information for the sent video, see clause 6.2.3.4		probably not(?)
urn:3gpp:predefined-roi-sent	Signalling of the predefined region-of-interest (ROI) information for the sent video, see clause 6.2.3.4		probably not(?)

SDES Compact Header Extensions

Extension URI	Description	Reference	Mappable from QUIC
urn:ietf:params:rtp-hdrext:sdes:cname	Source Description: Canonical End-Point Identifier (SDES CNAME)		no
urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id	RTP Stream Identifier		no
urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id	RTP Repaired Stream Identifier		no
urn:ietf:params:rtp-hdrext:sdes:CaptId	CLUE CaptId		no
urn:ietf:params:rtp-hdrext:sdes:mid	Media identification		no

Experimental Results An experimental implementation of the mapping described in this document can be found on Github. The application implements the RoQ Datagrams mapping and implements SCReAM congestion control at the application layer. It can optionally disable the builtin QUIC congestion control (NewReno). The endpoints only use RTCP for congestion control feedback, which can optionally be disabled and replaced by the QUIC connection statistics as described in . Experimental results of the implementation can be found on Github, too.

Acknowledgments Early versions of this document were similar in spirit to , although many details differ. The authors would like to thank Sam Hurst for providing his thoughts about how QUIC could be used to carry RTP. The authors would like to thank Bernard Aboba, David Schinazi, Lucas Pardue, Sergio Garcia Murillo, Spencer Dawkins, and Vidhi Goel for their valuable comments and suggestions contributing to this document.