SDP Offer/Answer for RTP using QUIC as Transport - Design Questions

2.1.1. Can We Assume the Use of "Extended Audiovisual Profiles"?

We could register both AVP and AVPF profiles, but do we need to register both?¶

2.1.2. Is "Secure RTP Encapsulated in UDP" Equivalent to "RTP Encapsulated in QUIC"?

RTP that is encapsulated in QUIC payloads will always be encrypted [RFC9000]. So we could register (for example)¶

• QUIC/RTP/AVPF, knowing that any RTP payload using the QUIC protocol is encrypted, but is not encrypted using SDES, or¶
• QUIC/RTP/SAVPF, because QUIC encryption provides at least an equivalent level of protection to SDES, or¶
• both QUIC/RTP/AVPF and QUIC/RTP/SAVPF, to minimize the changes necessary for existing RTP applications to add support for QUIC encapsulation?¶

2.1.3. Encapsulations in Datagrams and Streams

We note that [SDP-parameters] contains registrations for both RTP encapsulated in UDP datagrams and RTP encapsulated in TCP streams.¶

If we wanted to allow the same level of flexibility for QUIC/RTP, we could register (for example) QUIC/DGRAM/RTP, mapped onto QUIC datagrams ([I-D.ietf-quic-datagram]), and QUIC/STREAM/RTP, mapped onto QUIC streams ([RFC9000]), reusing terminology from the Berkeley Sockets API.¶

Should we do that? If so, starting out that way would be better than starting out with QUIC/RTP and then adding QUIC/STREAM/RTP later.¶

2.4.1. QUIC Datagram Multiplexing

[I-D.ietf-quic-datagram] does not provide support for a standardized datagram multiplexing identifier, for reasons described in Section 5.1, and at greater length in the Github issue about this (at https://github.com/quicwg/datagram/issues/6).¶

The high-level explanation is that there was considerable support for adding a datagram multiplexing identifier to the datagram frame type, but much less agreement about what effect that identifier would have, and whether the QUIC transport layer would be responsible for any particular processing, or whether this processing would necessarily be performed by the application. For example, some proponents of adding datagram multiplexing expected to use multiplexing identifiers as ways of distinguishing between datagrams of different priorities, and other propoents expected to used multiplexing identifiers to distinquish between datagrams that were part of multi-datagram conversations (more like streams, but using the datagram frame types).¶

Given that there was no agreement on the functionality that datagram multiplexer identifiers would be used for, or what requirements this addition to the protocol would place to QUIC transport processing, the best decision for the QUIC protocol seemed to be that any application that needed this capability could trivially add its own multiplexing identifiers at the beginning of the Datagram Data field ([I-D.ietf-quic-datagram]).¶

In general, that's a fine plan. The question for this document is whether there is enough similarity among various applications using QUIC/RTP that specifying an RTP-specific datagram multiplier would provide better predictability and ability to multiplex datagrams from different applications without modifying those applications when they encounter each other for the first time.¶

2.4.2. RTP Destination Transport Addresses, Bundles, and QUIC Connection-IDs

RTP has more than one way to identify endpoints, whether [RFC3550]-style destination three-tuples, or [RFC4961]-style Symmetric RTP and RTCP, or [RFC8843]-style BUNDLE transport, but all are based on IP addresses and port addresses.¶

The QUIC protocol also starts out with five-tuple awareness as it establishes a connection and performs TLS 1.3 handshake between the client and server, as described in [RFC9001], and performs path validation, as described in [RFC9000], but can also create multiple connection identifiers using different transport addresses that will be associated with the same connection, and when another path has been validated and associated with a known connection identifier, the QUIC endpoint can begin receiving packets for the same connection from an entirely different transport address, with no other signaling. This change of transport addresses might be the result of QUIC-level "connection migration", but might also be the result of NAT rebinding.¶

Applications using QUIC/RTP will need some way of managing QUIC connection identifiers, rather than transport addresses. This points to at least one potential need for a mapping of RTP semantics over QUIC, equivalent to [I-D.ietf-quic-http].¶

If QUIC/RTP applications will be making use of something like Application Layer Protocol Negotiation (ALPN) ([RFC7301]) identifiers to select QUIC/RTP processing, as HTTP/3 does, this may point to another potential need for a mapping.¶

2.4.3. Support for NAT Traversal

It's worth noting that the driving use cases for the first version of the IETF QUIC protocol have been for HTTP-based web access, where the capability described in Section 8.2 of [RFC9000] was sufficient:¶

• Path validation is not designed as a NAT traversal mechanism. Though the mechanism described here might be effective for the creation of NAT bindings that support NAT traversal, the expectation is that one endpoint is able to receive packets without first having sent a packet on that path. Effective NAT traversal needs additional synchronization mechanisms that are not provided here.¶

Some existing RTP applications share this characteristic - at least one RTP endpoint can receive a packet without having previously sent packet on that path. For these applications, current QUIC functionality will be sufficient.¶

For other RTP applications, we may need a QUIC extension that provides NAT traversal, and we may need to include information about NAT traversal in SDP Offer/Answer to enable QUIC/RTP communication.¶