WebRTC pro-tips

A random splattering of pro-tips for creating a product around WebRTC that I’ve learned over the last few years.

General tips

• Use adapter.js — it’s going to save you an inordinate amount of pain. Otherwise, you have to deal with an incredible amount of browser (and browser version!) nuance that simply isn’t worth your time.
• If you utilize a plug-in, create a polyfill for navigator.mediaDevices.getUserMedia, navigator.mediaDevices.enumerateDevices, RTCPeerConnection, MediaStream and MediaStreamTrack. It’s less work in the long run.
• Don’t allow old versions of Chrome and Firefox. For Firefox, at most I’d support the last LTS version (right now, that’s 52). For Chrome, I’d allow at most the last four-ish versions. Old versions of these browsers open yourself up to all sorts of pain.

SFU/MCU

If your conferences are any more than a few people, you’ll almost definitely need a Selective Forwarding Unit or a Media Control Unit. General tips:

• Make sure your SFU/MCU supports bundle and rtcp_mux.
• If doing audio only or video only (think screen sharing) is important, make sure your SFU/MCU supports that.
• Pay attention to the signaling channel. This is a non-standard channel that implements call setup for WebRTC. Make sure it’s a protocol you like, that the exchanges between client and server are reasonable, etc. Ugly wire format for this = debugging hell. Understand it before you commit.
• Make sure your SFU/MCU supports VP8, VP9 and Opus codecs at a bare minimum. H.264 support is also good. Other weird codecs are pretty much irrelevant.
• If you need recording, make sure you test that out. Particularly with packet loss and latency.
• If you’re using an SFU, make sure that SFU implements RTCP termination. Many simple implementations simply forward RTCP traffic from a source to all receivers (and vice-versa) which is incredibly wrong in a number of profound ways.
• I’d recommend beating the crap out of any solution you plan on using with network tests simulating packet loss and delay. The quality of how an MCU handles this can vary dramatically.

TURN

Sad reality: at some point you’ll have to relay, because in many instances a peer-to-peer connection cannot establish, or it doesn’t make much sense. Traversal Using Relays around NAT is the standard way of doing that:

• If you aren’t using a TURN server, your product is going to be a failure on any serious enterprise network. Go get coturn.
• Make sure you have TURN listening on port TCP 443. This’ll let you pick up TCP 443 (and HTTP CONNECT), which is necessary for corporate compatibility.
• If you’re using an SFU or MCU, consider running TURN along-side your software, and forcing everyone to relay through TURN. It’s sixes this way and can actually simplify a few things.

Debugging

• https://test.webrtc.org is a great site to test out webrtc connections. The code is also available here.
• chrome://webrtc-internals is awesome. Even more awesome is that same page, but for all the other browsers that don’t support it (about:webrtc in firefox is pretty much a waste of time). You can get that with this extension.
• Always test out your service with Chrome Canary and Firefox Developer. That way you can learn about incompatibilities with your system before they bite you in prod.

That’s all for now. Feel free to comment with your own hard-earned tips.