Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to describe whether data will be sent over streams or datagrams #6

Open
samhurst opened this issue Jun 5, 2024 · 0 comments
Open

Comments

@samhurst
Copy link

samhurst commented Jun 5, 2024

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.

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:

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant