Who needs QUIC in WebRTC anyway?

February 18, 2019

Is QUIC in WebRTC a solution looking for a problem or a real requirement?


QUIC is the next evolution of browser transport protocols. I’ve written about it in 2015, when Google started experimenting with the idea of replacing SCTP with QUIC for data channels.

Three and a half years later, and we still don’t really have QUIC in WebRTC – at least not until last month. Google decided to come out with a new RTCQUICTransport for WebRTC in Chrome and written a post about it on their Chrome Developers site.

UDP, TCP, SCTP & QUIC. How do these transport protocols compare?

What is QUIC again?

I am not going to go into the technical details – I’ve done that in the past already, and there are other places for that. I want to focus here on the bigger picture.

If you look at the timeline of web transport protocols, it looks something like this:

Web transport protocols

We had TCP and UDP for some 40 years now. HTTP 1.1 is defunct, but runs most of the internet at the moment. HTTP/2 is growing nicely in adoption. According to W3Techs, we’re standing on ~33% adoption for HTTP/2 (Feb 2019):

Usage of http/2

HTTP/2 came to be after Google came out with SPDY, a “fix” for HTTP and got parts (most?) of it wrapped into HTTP/2 to get it standardized.

HTTP 1.0, 1.1 and HTTP/2 are all built on top of TCP. Signaling, which requires reliability and causality won’t work on top of UDP without adding these characteristics. After around 40 years, it is time for a refresh. Enter QUIC. It uses UDP and works in ways that are better than TCP for signaling purposes.

QUIC follows a similar path – Google created it to “fix” the ailments of HTTP over TCP. the end goal here is to turn it into HTTP/3.

Since QUIC is built on top of UDP, it can handle a lot more than just HTTP signaling. Which is why it is becoming an interesting topic for WebRTC –

Where QUIC in WebRTC fits exactly?

This is the real question. My answer to it in 2015 was this:

There are two places where QUIC fits in WebRTC:

1. In the signaling, which is out of scope of WebRTC, but interesting, as it enables faster connection of the initial call (theoretically at least)

2. In the data channel, by replacing SCTP with QUIC wholesale

Google’s answer in their post on Chrome Developers blog?


A powerful low level data transport API can enable applications (like real time communications) to do new things on the web. You can build on top of the API, creating your own solutions, pushing the limits of what can be done with peer to peer connections, […] WebRTC’s NV effort is to move towards lower level APIs, and experimenting early with this is valuable.


The QUIC protocol is desirable for real time communications. It is built on top of UDP, has built in encryption, congestion control and is multiplexed without head of line blocking.

Hmm… somehow they lost me in that explanation somewhere. This is about real time communications. It is about doing stuff on top of UDP. And it is about low level APIs. Great. Why do I need it again? For voice and video I already have SRTP in WebRTC. The SCTP data channel works quite well. So where exactly do I need this great thing called QUIC in WebRTC?

I think there’s merit, but it is in totally different places.

QUIC is about having a single, modern, common transport protocol for the web.

Here’s what we do today with WebRTC in terms of transport protocols:

  • HTTPS, HTTP/2 or WebSocket for our signaling, which runs over TCP/TLS
  • SRTP for media, which runs over UDP
  • SCTP for data channels

There’s this popular drawing from the High Performance Browser Networking book that shows this amalgamation of protocols:

Amalgamation of protocols

So many transport protocols in a single standard. This makes implementations of the backend more complex, as they need to be able to understand all these transport protocols as well. One can say that this is already common enough and widely used already that it is a solution looking for a problem, but the developer in me can appreciate unifying all these functionality over a single transport protocol.

Here’s how life will look like with QUIC in WebRTC:

  • QUIC is being planned for HTTP/3, so it can be used for WebRTC signaling moving forward (replacing both WebSocket and HTTP/2)
  • QUIC is looked as an SRTP replacement, which means sending real time audio and video can take place on top of it
  • QUIC can replace SCTP for the data channels (that was the obvious use of QUIC in WebRTC to begin with)

Putting it into an architecture diagram of my own, we get this:


Much simpler.

What do we gain?

Theoretically, we can multiplex signaling, voice, video and low latency data in a single QUIC connection. That’s powerful:

  • We can now tunnel or proxy all that WebRTC traffic with a lot less logic, boxes and code in our servers
  • For smaller deployments, we might not even need multiple servers – just the one that handles it all
  • It makes developing web servers that handle media and data channels simpler, as they need to support only one transport – QUIC, instead of having to implement multiple transports

What do we lose?

This isn’t going to happen in a day. Getting there is going to be a journey of multiple years and people will complain and whine about it along the way. Similar to what is happening today with WebRTC – whenever something is modified or something new is added – things tend to break (either because APIs get deprecated, behavior changes or just pure bugs).

Moving to a QUIC based stack is a huge undertaking – for the WebRTC stack, browser vendors and all the related internet infrastructure vendors.

Connecting to other realms such as SIP? That’s going to get even harder, as we move away from the domain of SRTP towards QUIC, more translations and protocol interworking will be required.

The question then becomes – is it worth all the fuss? Are we gaining enough to make this effort worthwhile?

Can you use QUIC in WebRTC now?

To some extent you can. Check out the recent post on QUIC @ webrtcHacks for that.

I will be adding a new dedicated lesson to my online WebRTC course about QUIC – my goal is to have the most up to date and relevant WebRTC training curriculum in the market, so keeping up with these changes comes with the territory.

Interested in WebRTC? Check out my WebRTC course.

You may also like

WebRTC predictions for 2023

WebRTC predictions for 2023

Your email address will not be published. Required fields are marked

  1. In the Google Chrome’s developer site it mentions “The QUIC protocol is desirable for real time communications. It is built on top of UDP, has built in encryption, congestion control and is multiplexed without head of line blocking.” however in this article, the QUIC is presented as a new transport protocol and not built on top of UDP.
    Based on the chrome’s site and the Wikipedia I take it the protocol will run on top of UDP.

  2. I think that after 4 years, you should probably go ahead and give an update and review of QUIC along with the very brief and understated benefits you highlight.

    the protocol is not the same in 2019 as it was in 2015.

    The benefits of quick sessions being independant from network location are among the game changing mechanics that your readers should “write to their ___ about getting sooner” to bring about change. Who is it they should bring this to the attention to? ironically, the purveyors of walled gardens, and sellers of golden handcuff product lines are the force that needs to make QUIC happen sooner.

  3. Another downside with SCTP is that only one implementation drives everything (I think) usrcsctp is used by everyone. Reminds me of what happened with WebSQL, it was a great feature but because SQlite was the only option people shot it down.

    We wrote an implementation in Go which was fun. It sure is nice to just take quic-go and have everything just work though 🙂

    Dropping RTP would be so painful. It so nice now that you can just use RTP with everything that already exists, no transformations needed. Not sure I see as much benefit switching to QUIC here. With RTP I can tweak settings and decide how much loss/jitter I am willing to tolerate for n latency, I really hope we have the same flexibility.

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

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

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

  6. (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.

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

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

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}