RTP over QUIC

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 QUIC datagrams [RFC9221], which provides additional desirable properties for real-time traffic (e.g., no unnecessary retransmissions, avoiding head-of-line blocking).¶

Moreover, with QUIC's multiplexing capabilities, reliable and unreliable transport connections as, e.g., needed for WebRTC, can be established with only a single port used at either end of the connection.¶

1.2. What's in Scope for this Specification

This document defines a mapping for RTP and RTCP over QUIC (this mapping is hereafter referred to as "RTP-over-QUIC"), 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 RTP-over-QUIC 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). RTP-over-QUIC is not intended as a stand-alone media transport, although QUIC transport parameters could be statically configured.¶

The above implies that RTP-over-QUIC 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 RTP-over-QUIC is used to replace RTSP ([RFC7826]), to a media server.¶

Moreover, this document describes how a QUIC implementation and its API can be extended to improve efficiency of the RTP-over-QUIC protocol operation.¶

RTP-over-QUIC 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 RTP-over-QUIC 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, RTP-over-QUIC 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.¶

RTP-over-QUIC 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.¶

RTP-over-QUIC does not define congestion control and rate adaptation algorithms for use with media. However, Section 6 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 Section 6 will also describe the QUIC interface that's being exposed, or if that ends up somewhere else in the document.¶

RTP-over-QUIC 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 RTP-over-QUIC.¶

This document does not cover signaling for session setup. SDP for RTP-over-QUIC 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. 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 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.¶

Note-NAT:

QUIC [RFC9000] doesn't support NAT traversal.¶

Note-MTU:

Supported, but may require MTU adaptation.¶

Note-Sec:

Note that RTP-over-QUIC provides mandatory security, and other RTP transports do not. Section 10 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 "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.¶

5.1. 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 Section 16 of [RFC9000]. 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 Section 4, 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 [RFC8860].¶

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 [RFC5761], 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 stream, it MAY drop the data stream.¶

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

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

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. QUIC datagrams are an extension to QUIC described in [RFC9221]. 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.¶

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

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

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 Section 4, 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 [RFC8298] and NADA [RFC8698] 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. [I-D.draft-smith-quic-receive-ts] or [I-D.draft-huitema-quic-ts].¶

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 Section 6.2 or a receiver can feedback the observed bandwidth through RTCP, e.g., using [I-D.draft-alvestrand-rmcat-remb].¶

6.2. Congestion Control at the RTP 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.¶

The rate adaptation algorithms for RTP are specifically tailored for real-time transmissions at low latencies, as described in Section 6. 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 Section 6 (NADA, SCReAM). The bandwidth estimation algorithm typically needs some feedback on the transmission performance. This feedback can be collected following the guidelines in Section 7.¶

6.3. Resolving Interactions Between QUIC and Application-layer Congestion Control

Because QUIC is a congestion-controlled transport, as described in Section 6.1, and RTP applications can also perform congestion control and rate adaptation, as described in Section 6.2, 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") [I-D.cardwell-iccrg-bbr-congestion-control] 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."¶

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

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 Section 5.1, 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.¶

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

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

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

7.4. Application Layer Repair and other Control Messages

While Section 7.3.1 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, [RFC3550]) are similar to Receiver Reports, as described in Section 7.3.1. 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 Section 7.3.1.¶

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), Bye (PT=203, Name=BYE) and Application (PT=204, Name=APP) packet types from [RFC3550], or¶
• many of the payload specific feedback messages (PT=206) defined in [RFC4585], 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.¶

7.5. RTCP Control Packet Types

Several but not all of these control packets and their attributes can be mapped from QUIC, as described in Section 7.3.1. "Mappable from QUIC" has one of three values: "yes", "QUIC extension required", and "no".¶

7.6. Generic RTP Feedback (RTPFB)

7.7. Payload-specific RTP Feedback (PSFB)

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

7.8. Extended Reports (XR)

7.9. RTP Header extensions

• Transmission offset [RFC5450] is used for better jitter calculation. If we have QUIC timestamps, we don't need to work around RTP timestamps offsets because we can use the QUIC timestamps to calculate network jitter.¶

8.1. 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: Section 5.2 of [RFC9221] 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 [I-D.draft-smith-quic-receive-ts] or [I-D.draft-huitema-quic-ts], 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.¶

8.2. 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 Section 6.1, the QUIC implementation SHOULD expose an API to allow the application to configure the specifics of the congestion controller.¶

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

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

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

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