search

SpencerDawkins / sdp-rtp-quic-issues

Issued gathered from a variety of uncoordinated places, for sanity's sake.
Other
0 stars 0 forks source link

QUIC for data exchange? #9

Open aboba opened 2 years ago

aboba commented 2 years ago

P2P QUIC connections once established can be used for transport of both media and data.

Is there a way in SDP to indicate a desire to exchange data over P2P QUIC?

In the P2P QUIC Origin Trial, we assumed that only a single QUIC connection needed to be established between two peers. The type and format of data was assumed to be controlled by the application, so that there was no need to signal whether the data would be transported over reliable streams or datagrams, and either side could open a reliable stream or send a datagram.

SpencerDawkins commented 2 years ago

@aboba - are you thinking something like a parallel to WebRTC Data Channel, that would not require an SCTP implementation?

aboba commented 2 years ago

In P2P QUIC, the two sides establish a QUIC connection using self-signed certificates and fingerprint verification, very similar to DTLS. So the QUIC connection establishment SDP is well understood. The question in my mind is what signaling is needed for what comes afterwards.

In the original P2P QUIC API proposal , after connection establishment either side could initiate QUIC reliable streams or send datagrams. The responder receives an event on a new incoming stream and can read from the incoming datagram queue. So there's no equivalent to the WebRTC data channel negotiation.

This might make sense for data, but for media typically the receiver needs to be set up beforehand to be ready to render the media appropriately. For example, new participants may cause the gallery to be rearranged (e.g. from 2 x 2 to 3 x 3), and if the video tags have not been established or are not hooked up to MediaStreamTracks, incoming media could be dropped until the infrastructure is ready. So that's why SDP O/A or other signaling is desirable.

SpencerDawkins commented 2 years ago

@aboba, so the point here is to tell the other side "by the way, don't be surprised if I'm sending you data, that's not media at all, so you need to get ready to do something with data, too", is that right?

I think if you use two different connections, you don't have to do this in SDP, but if you're only using one connection that's already set up for RTP, it seems like SDP signalling would be required.

aboba commented 2 years ago

The problem for the receiver is knowing what to do with the data it receives. Is it RTP/RTCP (in which case it needs to process it in the audio/video pipeline) or is it data that should be surfaced to the application?

In the P2P QUIC trial we left everything up to the application. But if the application doesn't want to bring its own RTP over QUIC stack, then you'd need a built-in way to demultiplex media from data. Using multiple QUIC connections simplifies the multiplexing and would also make it possible to deploy distinct CC algorithms for media and data (what has been proposed in the W3C WebTransport WG). On the other hand, it makes prioritizing data and media more complex and within WebRTC the trend has been to send everything on a single port (e.g. RTP/RTCP/STUN/TURN/DTLS/ZRTP) so as to minimize ICE issues.

SpencerDawkins commented 2 years ago

Hi, @aboba - this description is very clear, and helped me understand (at least some of) the issues better.

Do you see a general solution being in scope for AVTCORE? My understanding from https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rfc7983bis is that we've just been getting lucky - recognizing that someone is going to want to add another protocol to be carried on the same connection, and then discovering that the surprise protocol just happens to be possible to demultiplex. Is that right?

aboba commented 2 years ago

RFC7983bis is about multiplexing STUN/TURN/DTLS/RTP/RTCP/QUIC/ZRTP all on the same port. As long as QUIC greasing isn't negotiated, it seems possible. As for multiplexing RTP/RTCP along with data within QUIC, it could be done similarly to RFC 7983bis, with the first byte of the QUIC payload being used to distinguish RTP/RTCP/data.