- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Wed, 10 Jan 2018 07:55:22 +0000
- To: Peter Thatcher <pthatcher@google.com>, Martin Thomson <martin.thomson@gmail.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Peter said: "So let me understand what you're saying: if later we define a mapping of RTP to QUIC and want to put that in the browser, a JS app would not be able to use both that new thing and some separate QUIC streams over the same 5-tuple without using QUIC connection IDs on the wire. Is that correct?" [BA] There seem to be multiple questions: 1. Is it ok to only allow a single QuicTransport between two endpoints? This is what the QUIC multiplexing proposal has been assuming. If you are multiplexing data sent over QuicStreams with SRTP, I suspect we can live with a single QuicTransport between endpoints. 2. Is it possible to multiplex media and RTCDataChannel over a single QuicTransport? Given that the protocols for neither RTCDataChannel over QUIC nor media/RTP over QUIC are defined, it's not possible to answer this question. But assuming that this was necessary there are several potential ways to accomplish it, including explicit or implicit grouping of streams and definition of a multiplexing header for WebRTC-relevant protocols run over QUIC (e.g. RFC 7983 for QUIC). Presumably we can cross that bridge when we come to it.
Received on Wednesday, 10 January 2018 07:55:49 UTC