Re: [AVTCORE] Call for Adoption (CfA): RTP over QUIC

We do have a flow identifier to demuxing and we have initial wording
on mixing real-time and possibly non-real-time data especially
concerning congestion control.  Likely not all will be handled by
the doc since, at some point, we get into too many application
specifics.  But the basic mechanisms will be in place.

[BA]  The "flow identifier" concept has evolved in various QUIC datagram
drafts.  It was originally included in draft-pauly-quic-datagram as well
as draft-schinazi-quic-h3-datagram, but it was removed in RFC 9221 and has
been replaced in draft-ietf-masque-h3-datagram with the following:

   HTTP/3 Datagram {
     Quarter Stream ID (i),
     [Context ID (i)],
     HTTP Datagram Payload (..),
   }

> 2. WebTransport support. Currently the draft does not support RTP over
> WebTransport.

This is something to be looked at closer.  The discussion with David
showed that it is non-trivial to get the ALPN allocations and all the
implications right.

[BA] I think there may have been a understanding.  David's last message
(see: https://mailarchive.ietf.org/arch/msg/avt/VSkKEEajBgZ4RI7S4MlF328YUCE/
) included the following:

"Based on Bernard's question, I thought that draft-engelbart-rtp-over-quic

was trying to multiplex RTP and WebTransport over the same QUIC connection.
That's my mistake, the draft isn't trying to do that. That wouldn't work
because of the ALPN points made above, but that's not what you're trying to
do in the first place. If instead, you want to run RTP over
WebTransport, then that's possible
from a protocol perspective, but you'd need an implementation of
WebTransport that would provide you more detailed information than what is
provided to Javascript today.

"

On Sun, Jun 26, 2022 at 9:44 AM Joerg Ott <ott@in.tum.de> wrote:

> Quickly on the two points inline:
>
> > I support adoption of RTP over QUIC.
> >
> > I do have two concerns, though:
> >
> > 1. The draft currently does not address how data would be multiplexed
> > with media. Part of the appeal of QUIC transport is the potential
> > ability to handle both data and media within a single QUIC connection.
>
> We do have a flow identifier to demuxing and we have initial wording
> on mixing real-time and possibly non-real-time data especially
> concerning congestion control.  Likely not all will be handled by
> the doc since, at some point, we get into too many application
> specifics.  But the basic mechanisms will be in place.
>
> > 2. WebTransport support. Currently the draft does not support RTP over
> > WebTransport.
>
> This is something to be looked at closer.  The discussion with David
> showed that it is non-trivial to get the ALPN allocations and all the
> implications right.
>
> Jörg
>
> >> On Jun 25, 2022, at 08:56, Roland.Schott@telekom.de wrote:
> >>
> >> 
> >>
> >> * I support adoption of "RTP over QUIC".
> >>
> >> Thanks
> >>
> >> Roland
> >>
> >> *Von:* avt <avt-bounces@ietf.org> *Im Auftrag von * Bernard Aboba
> >> *Gesendet:* Freitag, 24. Juni 2022 19:59
> >> *An:* IETF AVTCore WG <avt@ietf.org>
> >> *Betreff:* [AVTCORE] Call for Adoption (CfA): RTP over QUIC
> >>
> >> This is a Call for Adoption (CfA) of "RTP over QUIC".    The draft is
> >> available for inspection here:
> >>
> >> https://datatracker.ietf.org/doc/html/draft-engelbart-rtp-over-quic
> >> <https://datatracker.ietf.org/doc/html/draft-engelbart-rtp-over-quic>
> >>
> >> The Github repo used to track issues is here:
> >>
> >> https://github.com/mengelbart/rtp-over-quic-draft
> >> <https://github.com/mengelbart/rtp-over-quic-draft>
> >>
> >> The Call for Adoption will run until midnight Pacific Time on Monday,
> >> July 11, 2022.
> >>
> >> In response, please indicate one of the following:
> >>
> >> * I support adoption of "RTP over QUIC".
> >>
> >> * I object to adoption of "RTP over QUIC" due to the following open
> >> Issues <link to filed issues>
> >>
> >> Bernard
> >>
> >> For the Chairs
> >>
> >> _______________________________________________
> >> Audio/Video Transport Core Maintenance
> >> avt@ietf.org
> >> https://www.ietf.org/mailman/listinfo/avt
> >
> > _______________________________________________
> > Audio/Video Transport Core Maintenance
> > avt@ietf.org
> > https://www.ietf.org/mailman/listinfo/avt
>