RTP over QUIC (RoQ)

1.1. Background

The Real-time Transport Protocol (RTP) [RFC3550] 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 ([RFC9308]). As a baseline, the specification does not expect more than a standard QUIC implementation as defined in [RFC8999], [RFC9000], [RFC9001], and [RFC9002], 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 DATAGRAMs [RFC9221], which provides additional desirable properties for real-time traffic (e.g., no unnecessary retransmissions, avoiding head-of-line blocking).¶

1.2. 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 and RTCP 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 media 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 ([RFC7667]), or, if RoQ is used to replace RTSP ([RFC7826]), to a media server.¶

An appropriate 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.¶

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) ([RFC3551]), or any RTP-based mechanisms, even though it may render some of them unnecessary, e.g., Secure Real-Time Transport Prococol (SRTP) ([RFC3711]) 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.¶

1.3. 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, Section 7 discusses options for how congestion control and rate adaptation could be performed at the QUIC and/or at the RTP layer, and Section 11 describes the information available at the QUIC layer that could be exposed via an API for the benefit of RTP layer implementation.¶

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 [I-D.draft-dawkins-avtcore-sdp-rtp-quic], and can be carried in any signaling protocol that can carry SDP, including the Session Initiation Protocol (SIP) ([RFC3261]), Real-Time Protocols for Browser-Based Applications (RTCWeb) ([RFC8825]), or WebRTC-HTTP Ingestion Protocol (WHIP) ([I-D.draft-ietf-wish-whip]).¶

3.1. 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".¶

3.2. RTP with QUIC Streams, QUIC Datagrams, and a Mixture of Both

This document describes the use of QUIC streams and DATAGRAMs as RTP encapsulations, but does not take a position on which encapsulation an application should use. Indeed, an application can use both QUIC streams and DATAGRAM encapsulations. The choice of encapsulation is left to the application developer, but it is worth noting the differences.¶

QUIC [RFC9000] was initially designed to carry HTTP [RFC9114] in QUIC STREAM frames, and QUIC STREAM frames provide what HTTP application developers require - for example, QUIC STREAM frames provide a stateful, connection-oriented, flow-controlled, reliable, ordered stream of bytes to an application. QUIC STREAM frames 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 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 STREAM frames. 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 DATAGRAMs are an extension to QUIC, they inherit a great deal of functionality from QUIC (much of which is described in Section 3.1); 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 Section 7.7 of [RFC9002]), 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.¶

Because DATAGRAMs are an extension to QUIC, a RoQ endpoint cannot count on a RoQ peer supporting that extension. The RoQ endpoint may discover that its peer does not support DATAGRAMs while using signaling to set up QUIC connections, but may also discover that its peer has not negotiated the use of this extension during the QUIC handshake. When this happens, the RoQ endpoint needs to make a decision about what to do next.¶

• If the use of DATAGRAMs was critical for the application, the endpoint can simply close the QUIC connection, allowing someone or something to correct this mismatch, so that DATAGRAMs can be used.¶

• If the use of DATAGRAMs was not critical for the application, the endpoint can negotiate the use of QUIC STREAM frames instead.¶

3.3. Supported RTP Topologies

RoQ only supports some of the RTP topologies described in [RFC7667]. Most notably, due to QUIC [RFC9000] 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 Section 5.2) 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 over DATAGRAMs, where the max_datagram_frame_size 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.¶

Note-NAT:

QUIC [RFC9000] 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. Section 14 describes strategies to prevent the inadvertent disclosure of RTP sessions to unintended third parties.¶

Note-MCast:

QUIC [RFC9000] 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 [RFC7667]: 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.¶

4.1. 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 "roq" to identify itself in ALPN.¶

Only implementations of the final, published RFC can identify themselves as "roq". 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-09 is identified using the string "roq-09".¶

Non-compatible experiments that are based on these draft versions MUST append the string "-" and an experiment name to the identifier.¶

5.1. Multiplexing

RoQ uses flow identifiers to multiplex different RTP and RTCP streams on a single QUIC connection. A flow identifier is a QUIC variable-length integer as described in Section 16 of [RFC9000]. Each flow identifier is associated with a stream of RTP or RTCP packets.¶

In a QUIC connection using the ALPN token defined in Section 4, every DATAGRAM and every QUIC stream MUST start with a flow identifier. A peer MUST NOT send any data in a DATAGRAM or STREAM frame 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 can do so by following [RFC8860].¶

A single RTP session can 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 can use the same flow identifier (following the procedures defined in [RFC5761]), or they can use different flow identifiers.¶

The association between flow identifiers and RTP/RTCP streams MUST be negotiated using appropriate signaling. If a receiver cannot associate a flow identifier with any RTP/RTCP stream, it MUST close the connection with the application error code ROQ_UNKNOWN_FLOW_ID.¶

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.¶

5.2. QUIC Streams

To send RTP/RTCP packets over QUIC streams, a sender MUST open at least one new unidirectional QUIC stream. RoQ uses unidirectional streams, 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, MUST stop reading from the stream and send a CONNECTION_CLOSE frame with the frame type set to APPLICATION_ERROR and the error code set to ROQ_STREAM_CREATION_ERROR.¶

A RoQ sender can open new QUIC streams for different packets using the same flow identifier, for example, to avoid head-of-line blocking.¶

Because a sender can continue sending on a lower stream number after starting packet transmission on a higher stream number, a RoQ receiver MUST be prepared to receive RoQ packets on any number of QUIC streams (subject to its limit on parallel open streams) and MUST not make assumptions about which RTP sequence numbers are carried in which streams.¶

Payload {
  Flow Identifier (i),
  RTP/RTCP Payload(..) ...,
}

RTP/RTCP Payload {
  Length(i),
  RTP/RTCP Packet(..),
}

5.3. QUIC DATAGRAMs

Senders can also transmit RTP packets in QUIC DATAGRAMs. DATAGRAMs are an extension to QUIC described in [RFC9221]. DATAGRAMs can only be used if the use of the DATAGRAM extension was successfully negotiated during the QUIC handshake. If the QUIC extension was signaled using a signaling protocol, but that extension was not negotiated during the QUIC handshake, a peer can 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. Because QUIC DATAGRAMs cannot be IP-fragmented (Section 5 of [RFC9221]), senders need to 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 the path MTU.¶

Figure 3 shows the encapsulation format for RoQ Datagrams.¶

Payload {
  Flow Identifier (i),
  RTP/RTCP Packet (..),
}

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 frames or DATAGRAM frames carrying application data and ACK 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 ACK 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 ACK- (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 ACK frames.¶

Since DATAGRAMs are not retransmitted on loss (see also Section 9.4 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 [RFC4588] and the flow identifier MUST be set to the flow identifier of the RTP session in which the retransmission happens.¶

7.1. 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 [RFC9002] is similar to TCP NewReno [RFC6582], but senders are free to choose any congestion control algorithm as long as they follow the guidelines specified in Section 3 of [RFC8085], and QUIC implementors make use of this freedom.¶

Congestion control mechanisms are often implemented at the transport layer of the protocol stack, but can also be implemented at the application layer.¶

A congestion control mechanism could respond to actual packet loss (detected by timeouts), or to impending packet loss (signaled by mechanisms such as Explicit Congestion Notification [RFC3168]).¶

For real-time traffic, it is best that the QUIC implementation use a congestion controller that aims at keeping queues, and thus the latency, at intermediary network elements as short as possible. Delay-based congestion control algorithms might use, for example, an increasing one-way delay as a signal of impending congestion, and adjust the sending rate to prevent continued increases in one-way delay.¶

A wide variety of congestion control algorithms for real-time media have been developed (for example, "Google Congestion Controller" [I-D.draft-ietf-rmcat-gcc]). The IETF has defined two such algorithms in Experimental RFCs (SCReAM [RFC8298] and NADA [RFC8698]). These algorithms for RTP are specifically tailored for real-time transmissions at low latencies, but this section would apply to any congestion control algorithm that meets the requirements described in "Congestion Control Requirements for Interactive Real-Time Media" [RFC8836].¶

Some low latency congestion control algorithms depend on detailed arrival time feedback to estimate the current one-way delay between sender and receiver, which is unavailable in QUIC [RFC9000] without extensions. The QUIC implementations of the sender and receiver can use an extension to add this information to QUIC as described in Appendix A. An alternative to these dedicated real-time media congestion-control algorithms that QUIC implementations could support is the Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service [RFC9330], which can be used to limit growth in round-trip delays, due to increasing queuing delays. While L4S does not rely on a QUIC protocol extension, L4S does rely on support from network devices along the path from sender to receiver.¶

The application needs a mechanism to query the available bandwidth to adapt media codec configurations. If the employed congestion controller of the QUIC connection keeps an estimate of the available bandwidth, it could expose an API to the application to query the current estimate. If the congestion controller cannot provide a current bandwidth estimate to the application, the sender can implement an alternative bandwidth estimation at the application layer as described in Section 7.2.¶

It is assumed that the congestion controller in use provides a pacing mechanism to determine when a packet can be sent to avoid bursts and minimize variation in inter-packet arrival times. The currently proposed congestion control algorithms for real-time communications (e.g., SCReAM and NADA) provide such pacing mechanisms, and QUIC recommends pacing for senders based on the congestion control algorithm.¶

7.2. Rate Adaptation at the Application Layer

RTP itself does not specify a congestion control algorithm, but [RFC8888] 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.¶

If an application cannot access a bandwidth estimation from the QUIC layer, the application can alternatively implement a bandwidth estimation algorithm at the application layer. Congestion control algorithms for real-time media such as GCC [I-D.draft-ietf-rmcat-gcc], NADA [RFC8698], and SCReAM [RFC8298] expose a target_bitrate to dynamically reconfigure media codecs to produce media at the rate of the observed available bandwidth. Applications can use the same bandwidth estimation to adapt their rate when using QUIC. However, running an additional congestion control algorithm at the application layer can have unintended effects due to the interaction of two nested congestion controllers.¶

If the application transmits 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 being 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 sending rate, drastic measures will be required to avoid sustained or oscillating congestion along the path.¶

Thus, applications are advised to only use the bandwidth estimation without running the complete congestion control algorithm at the application layer before passing data to the QUIC layer.¶

The bandwidth estimation algorithm typically needs some feedback on the transmission performance. This feedback can be collected via RTCP or following the guidelines in Section 9 and Section 11.¶

7.3. 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 [RFC768].¶

• Alternatively, all real-time channels are mapped to one QUIC connection, while a separate QUIC connection is created for the non-real-time channels.¶

• A third option is to multiplex all channels in a single QUIC connection via an extension to RoQ.¶

In the first two 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, by extending RoQ, 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 will need to implement some form of stream prioritization or bandwidth allocation.¶

9.1. 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.¶

9.2. RoQ Streams

For RTP packets that are sent over QUIC streams, an RTP packet is considered acknowledged after all frames that 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.¶

9.3. 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 Section 3.2.2 of [RFC7667], 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.¶

9.4. Feedback Mappings

This section explains how some of the RTCP packet types that 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.¶

The list of RTCP packets in this section is not exhaustive, and similar considerations would apply when exchanging any other type of RTCP control packets using RoQ.¶

A more thorough analysis of RTCP Control Packet Types (in Appendix B.1), Generic RTP Feedback (RTPFB) (in Appendix B.3), Payload-specific RTP Feedback (PSFB) (in Appendix B.4), Extended Reports (in Appendix B.2), and RTP Header Extensions (in Appendix B.5), including the information that cannot be mapped from QUIC, can be found in Appendix B.¶

12.1. 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. As noted in Section 11, it may be desirable that the RoQ implementation provides an indication of connection migration to the RTP application, to assist in coping.¶

12.2. 0-RTT considerations

For repeated connections between peers, the initiator of a QUIC connection can use 0-RTT data for both QUIC STREAM frames 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.¶

12.3. Coalescing RTP packets in single QUIC packet

Applications have some control over how the QUIC stack maps application data to QUIC frames, but applications cannot control how the QUIC stack maps STREAM and DATAGRAM frames to QUIC packets Section 13 of [RFC9000] and Section 5 of [RFC9308].¶

• When RTP payloads are carried over QUIC streams, the RTP payload is treated as an ordered byte stream that will be carried in QUIC STREAM frames, with no effort to match application data boundaries.¶

• When RTP payloads are carried over DATAGRAMs, each RTP payload data unit is mapped into a DATAGRAM frame, but¶

• QUIC implementations can include multiple STREAM frames from different streams and one or more DATAGRAM frames into a single QUIC packet, and may include other QUIC frames as well.¶

QUIC stacks are allowed to wait for a short period of time if the queued QUIC packet is shorter than the path MTU, in order to optimize for bandwidth utilization instead of latency, while real-time applications usually prefer to optimize for latency rather than bandwidth utilization. This waiting interval is under the QUIC implementation's control, and might be based on knowledge about application sending behavior or heuristics to determine whether and for how long to wait.¶

When there are a lot of small DATAGRAM frames (e.g., an audio stream) and a lot of large DATAGRAM frames (e.g., a video stream), it may be a good idea to make sure the audio frames can be included in a QUIC packet that also carries video frames (i.e., the video frames don't fill the whole QUIC packet). Otherwise, the QUIC stack may have to send additional small packets only carrying single audio frames, which would waste some bandwidth.¶

Application designers are advised to take these considerations into account when selecting and configuring a QUIC stack for use with RoQ.¶

15.1. 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 [RFC7301].¶

The "roq" string identifies RoQ:¶

Protocol:

RTP over QUIC (RoQ)¶

Identification Sequence:

0x72 0x6F 0x71 ("roq")¶

Specification:

This document¶

15.2. RoQ Error Codes Registry

This document establishes a registry for RoQ error codes. The "RTP over QUIC (RoQ) Error Codes" registry manages a 62-bit space and is listed under the "Real-Time Transport Protocol (RTP) Parameters" heading.¶

The new error codes registry created in this document operates under the QUIC registration policy documented in Section 22.1 of [RFC9000]. This registry includes the common set of fields listed in Section 22.1.1 of [RFC9000].¶

Permanent registrations in this registry are assigned using the Specification Required policy ([RFC8126]), except for values between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using Standards Action or IESG Approval as defined in Sections 4.9 and 4.10 of [RFC8126].¶

Registrations for error codes are required to include a description of the error code. An expert reviewer is advised to examine new registrations for possible duplication or interaction with existing error codes.¶

In addition to common fields as described in Section Section 22.1 of [RFC9000], this registry includes two additional fields. Permanent registrations in this registry MUST include the following fields:¶

Name:

A name for the error code.¶

Description:

A brief description of the error code semantics, which can be a summary if a specification reference is provided.¶

The initial allocations in this registry are all assigned permanent status and list a change controller of the IETF and a contact of the AVTCORE working group (avt@ietf.org).¶

The entries in Table 2 are registered by this document.¶

B.1. RTCP Control Packet Types

The IANA registry for this section is [IANA-RTCP-PT].¶

B.2. RTCP XR Block Type

The IANA registry for this section is [IANA-RTCP-XR-BT].¶

B.3. FMT Values for RTP Feedback (RTPFB) Payload Types

The IANA registry for this section is [IANA-RTCP-FMT-RTPFB-PT].¶

B.4. FMT Values for Payload-Specific Feedback (PSFB) Payload Types

The IANA registry for this section is [IANA-RTCP-FMT-PSFB-PT].¶

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

B.5. 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 [RFC5450] are used to improve network jitter calculation, which can be done in QUIC if a timestamp extension is used.¶

B.6. Examples