Comments on: Who needs QUIC in WebRTC anyway? https://bloggeek.me/who-needs-quic-in-webrtc/ The leading authority on WebRTC Thu, 26 Aug 2021 09:03:26 +0000 hourly 1 By: Tsahi Levent-Levi https://bloggeek.me/who-needs-quic-in-webrtc/#comment-133808 Thu, 26 Aug 2021 09:03:26 +0000 https://bloggeek.me/?p=13148#comment-133808 In reply to Parikshit Samant.

Probably.

Since this was published, QUIC was wrapped into HTTP/3 and is now making inroads to WebTransport. So in the client/server side it is progressing nicely (where STUN and ICE aren’t needed).
Would it make sense to use it as a SCTP replacement? Time will tell.

]]> By: Parikshit Samant https://bloggeek.me/who-needs-quic-in-webrtc/#comment-133798 Thu, 26 Aug 2021 05:16:23 +0000 https://bloggeek.me/?p=13148#comment-133798 In reply to Tsahi Levent-Levi.

And on same lines, STUN and ICE would also remain as well right? Or something else, equivalent.

]]> By: Tsahi Levent-Levi https://bloggeek.me/who-needs-quic-in-webrtc/#comment-123505 Mon, 21 Sep 2020 06:24:55 +0000 https://bloggeek.me/?p=13148#comment-123505 In reply to Qin.

Assuming P2P, you will still need TURN.

]]> By: Qin https://bloggeek.me/who-needs-quic-in-webrtc/#comment-123504 Mon, 21 Sep 2020 06:12:01 +0000 https://bloggeek.me/?p=13148#comment-123504 I wonder if QUIC would make a TURN server redundant. I doubt it but it seems so from you diagram in the article. Would appreciate it if you could share some comments on it.

]]> By: Tsahi Levent-Levi https://bloggeek.me/who-needs-quic-in-webrtc/#comment-119398 Wed, 20 Feb 2019 16:38:48 +0000 https://bloggeek.me/?p=13148#comment-119398 In reply to Lennart Grahl.

discuss-webrtc had indications of Google looking at such a replacement of SRTP with QUIC. Not sure where it stands today though.

]]> By: Tsahi Levent-Levi https://bloggeek.me/who-needs-quic-in-webrtc/#comment-119397 Wed, 20 Feb 2019 16:32:07 +0000 https://bloggeek.me/?p=13148#comment-119397 In reply to Lennart Grahl.

I have no clue why and how your replies are marked as spam. I didn’t find anything in my comments spam list from you…

]]> By: Lennart Grahl https://bloggeek.me/who-needs-quic-in-webrtc/#comment-119396 Wed, 20 Feb 2019 15:53:16 +0000 https://bloggeek.me/?p=13148#comment-119396 (This is a response to
Sean DuBois, since apparently my replies are always marked as spam.)

That is not a downside of SCTP but a problem with diversity. A problem Google and others could have tackled easily with the resources available to them, just like you did.

]]> By: Lennart Grahl https://bloggeek.me/who-needs-quic-in-webrtc/#comment-119395 Wed, 20 Feb 2019 15:44:40 +0000 https://bloggeek.me/?p=13148#comment-119395 The article states that “QUIC is looked as an SRTP replacement, which means sending real time audio and video can take place on top of it”.

But it’s not. It’s not even designed for that since QUIC is designed to transmit reliable and ordered byte streams and everything else is either a hack or proprietary (for now).

Furthermore, the exact same arguments regarding gains and losses could be made with using DTLS/SCTP… only that we already have DTLS/SCTP in the stack.

]]> By: Tsahi Levent-Levi https://bloggeek.me/who-needs-quic-in-webrtc/#comment-119394 Mon, 18 Feb 2019 21:00:40 +0000 https://bloggeek.me/?p=13148#comment-119394 In reply to David P.

David,

That’s partially correct. If QUIC is used only for the data channel and not voice and video, then the same problem of synchronization with SCTP exist with QUIC.

It can be solved for SCTP as well – just a matter of deciding how and where to place the solution.

That said, I do agree that doing it via QUIC and tearing out SRTP and replacing it with QUIC can make this simpler.

]]> By: David P https://bloggeek.me/who-needs-quic-in-webrtc/#comment-119393 Mon, 18 Feb 2019 20:57:21 +0000 https://bloggeek.me/?p=13148#comment-119393 One use-case for Webrtc NV, which I think QUIC will fulfill, is allowing a way to make data msgs arrive with corresponding media. This is only possible now, IIRC, by encoding data msgs into an off-screen portion of video frames, then using a browser extension to decode them. Game-like services need this.

]]>