Re: [AVTCORE] Registering AVP Profiles for RTP over QUIC

[Ross Finlayson <[e-mail]>]

> On May 16, 2022, at 9:48 PM, Roman Shpount <[e-mail]> wrote:
> 
> > You would end up with this encoding when RTP over QUIC is used on top of TCP
> 
> What does “QUIC on top of TCP" even mean, given that QUIC is a UDP-based protocol?
>  
> RTP, DTLS, and SCTP are also UDP-based protocols. They all can run over TCP (see  RFC 4571) when the ICE-TCP (RFC 6544) candidate is used.

Yes, one could imagine RTP being sent with RFC 4571 framing over ‘QUIC classic’ - i.e., over QUIC as a reliable, connection-oriented protocol.  But it would seem to make a lot more sense for ‘RTP over QUIC’ to use QUIC-with-datagrams.  (How likely is it that a pair of endpoints will support ‘QUIC classic’ without the datagram extension, but will not be able to communicate via TCP?)


> In any case, it seems to me that this whole discussion is begging the question.  First, we should come to consensus as to what problem(s) we are trying to solve.  Then, and only then, we can decide whether 'RTP over QUIC’ is an appropriate way to solve these problem(s).
> 
> It may well turn out that 'RTP over QUIC’ is a solution in search of a problem.
> 
>  
> I can see a few problems that it can solve:
> 
> 1. Run real-time media over WebTransport

Maybe.  But would this use RTP?

> 2. Get rid of SCTP for data channels in the WebRTC stack

OK, but this has nothing to do with RTP

> 3. Replace DTLS in secure RTP channel setup by using a more modern protocol with cleaner implementation and faster connection establishment
> 4. Better NAT and firewall traversal with QUIC vs. plain SRTP

OK, but it seems to me that doing these (and 2.) would require rechartering the IETF RTCWeb Working Group to develop a new version of WebRTC that uses QUIC.  Perhaps this is where we should be headed (as it would produce a product that’s superior to the existing WebRTC, for the reasons you state), but this would be a big undertaking.

	Ross.