- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Mon, 5 Mar 2018 22:51:49 +0000
- To: Iņaki Baz Castillo <ibc@aliax.net>
- CC: WebRTC WG <public-webrtc@w3.org>
Inaki said: "Yes, what I mean is: why is QUIC is so good for carrying audio/video?" [BA] While it's not hard to come up with a peer-to-peer QUIC API for WebRTC (see the WebRTC-QUIC spec), we need to remember that the QUIC protocol is still "work in progress". The QUIC WG is only chartered to develop an HTTP transport, not a transport protocol for realtime media. Do to their IESG-enforced tunnel vision, QUIC isn't even yet a complete substitute for the SCTP data channel, yet alone a suitable transport for realtime media. QUIC v1 only provides reliable transport. You can try to fake unreliable by setting a timer, but that won't really give you maxRetransmits, which is what you need to completely support unreliable data channel over QUIC. So really, we're talking about adding an unreliable transport to QUIC and perhaps other things as well - which might require waiting for QUICv2.
Received on Monday, 5 March 2018 22:52:13 UTC