Currently, there's no specified way for a a media description to describe how RTP and RTCP data is transmitted, either over QUIC streams or DATAGRAM frames.
I seem to remember in the past that putting stream or dgram in the proto field of the media line (i.e. QUIC/stream/RTP/AVP), which I've been experimenting with but I don't think this is quite right.
Send one RTP session over streams, and another over DATAGRAM frames (i.e. a more important stream that I'm less tolerant of loss on against something I don't mind loss on)
Within a single RTP session, sending all RTP over streams and all RTCP over DATAGRAM frames.
Within a single RTP session that in this case is sending a video stream, sending all RTP packets containing I-frames over streams for reliability, and then B- and P-frames over DATAGRAM frames.
I'm sure there are potentially other use-cases, but these are the ones that I can think of so far.
Now, looking at QUIC transport itself, DATAGRAM frames are an extension that may not be available. So a soft-touch approach to this might be that the SDP media description simply states that the QUIC connection should be negotiated with support for DATAGRAM frames, and then leave the actual usage up to the implementations.
Otherwise, might there be a reason why we want to describe how streams/datagrams will be used in a given media session? Maybe an implementation doesn't want to have too much DATAGRAM processing to do, so it could reject an offer that includes lots of DATAGRAM usage. I don't have a good answer to this one either, so I'll leave this as an open question too.
Currently, there's no specified way for a a media description to describe how RTP and RTCP data is transmitted, either over QUIC streams or DATAGRAM frames.
I seem to remember in the past that putting
streamordgramin the proto field of the media line (i.e.QUIC/stream/RTP/AVP), which I've been experimenting with but I don't think this is quite right.The latest RoQ draft specifies that RTP can be sent on streams, DATAGRAM frames or a mixture of both. With my implementer hat on, here's some use-cases that I can think of where I might want to do different things:
I'm sure there are potentially other use-cases, but these are the ones that I can think of so far.
Now, looking at QUIC transport itself, DATAGRAM frames are an extension that may not be available. So a soft-touch approach to this might be that the SDP media description simply states that the QUIC connection should be negotiated with support for DATAGRAM frames, and then leave the actual usage up to the implementations.
Otherwise, might there be a reason why we want to describe how streams/datagrams will be used in a given media session? Maybe an implementation doesn't want to have too much DATAGRAM processing to do, so it could reject an offer that includes lots of DATAGRAM usage. I don't have a good answer to this one either, so I'll leave this as an open question too.