Re: [AVTCORE] Multiplexing in RTP over QUIC

Sam said:

"It does not then preclude someone doing something like options 1 and 2, if
they deem themselves to have a valid use case for doing so."

[BA] Right.  If the task at hand is to define a new RTP transport (over
QUIC), existing RTP RFCs should apply unless there is a transport-related
reason why they can't (e.g. multicast).  We've already defined how to
multiplex audio/video/data/control with RTP:

RFC 5761:  RTP/RTCP mux
RFC 8872:  RTP multiplexing

So why wouldn't those existing RFCs apply?

On Mon, Dec 19, 2022 at 4:50 AM Samuel Hurst <samuelh@rd.bbc.co.uk> wrote:

> On 16/12/2022 17:04, Mathis Engelbart wrote:
> > 1. A single RTP session in one QUIC connection. Multiple RTP sessions
> > and RTCP will need separate QUIC connections.
> >
> > 2. Multiplex RTP and RTCP in one QUIC connection. (Note that this
> > implies that an implementer may still choose option 1.)
>
> I feel that both of the above options are somewhat in antithesis to the
> original design goals of QUIC, and giving any explicit nod to these
> options in the draft can lead some readers to believe that it's a valid
> way of operating, when realistically it is quite wasteful in terms of
> resources.
>
> > 3. Multiplex many RTP sessions and RTCP in one QUIC connection.
>
> I think this should be the bare minimum of support. It does not then
> preclude someone doing something like options 1 and 2, if they deem
> themselves to have a valid use case for doing so.
>
> More importantly, it doesn't then lock in a particular implementation to
> having to notionally support other things besides RTP over QUIC, if
> that's all that it needs to be able to do. Not everything that RTP gets
> used for is web conferencing in a browser, it also gets used in
> broadcast and other specific fields that might be precluded if anything
> else is mandated on top.
>
> > 4. Multiplex RTP/RTCP and potentially other protocols in one QUIC
> > connection. Multiplexing non-RTP protocols could be used to do signaling
> > on the same connection or to enable use cases such as WebRTC data
> channels.
>
> This is a very good goal to aim for, but perhaps separate from the core
> function of running RTP over QUIC. Maybe start with RTP over QUIC, and
> then there can be a second specification for how to do the multiplexing,
> perhaps part of WebTransport or something else standalone.
>
> Thanks for bringing this discussion to the list!
>
> -Sam
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>