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

Ross said:

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

[BA] In general, I am seeing low-latency streaming applications adopting
unreliable/unordered transport.  Many of them started with
reliable/unordered transport because it was simpler (e.g. didn't have to do
application-layer NACK), but unreliable/unordered transport offers lower
jitter and latencies.

"(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?)"

[BA] The datagram extension is pretty widely implemented at this point.

Maybe.  But would this use RTP?

[BA] Implementations I have seen are 'RTP-ish'.  That is, they utilize a
codec identifier, sequence number and time stamp, and often have an
extension mechanism to allow meta-data (e.g. Keyframe/P-frame, TID, etc.)
to be sent along with frames.  So the problem of serializing frames for use
in decoding APIs such as WebCodecs tends to lead to something with a
resemblance to RTP.

On Mon, May 16, 2022 at 9:56 PM Ross Finlayson <finlayson@live555.com>
wrote:

>
>
> > On May 16, 2022, at 9:48 PM, Roman Shpount <roman@telurix.com> 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.
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>