The original SimpleWebRTC was one of the first Javascript libraries for WebRTC out there; the first public version was released more than five years ago. It offered a simple API that allowed JavaScript developers to prototype stuff quickly without having to understand the intricacies of the WebRTC APIs. “You can build cool stuff with WebRTC in five minutes” was true. Taking it to production at scale remains a bit more difficult.
Under the hood, SimpleWebRTC consisted of a bunch of Javascript modules that let you access the camera, microphone, screen content, a wrapper for the RTCPeerConnection API, and something to keep track of your peers and do all of the signaling. It came with a very simple NodeJS signaling server called signalmaster. Socket.io was used for signaling.
This simplicity came at a cost. SimpleWebRTC was designed for a single use-case: multiparty video chat using direct peer-to-peer connection between the participants. For the more complex problems we had to solve, we needed something better. Which is why we rewrote SimpleWebRTC almost from scratch, taking into account what we had learned in the last five years.
Goodbye socket.io, hello stanza.io
We moved from socket.io and a homegrown signaling protocol to Lance Stout’s stanza.io library which makes the XMPP protocol available with a nice Javascript API. This meant we did not have to reinvent concepts like “chat room” or “signaling” again but could use well-documented protocols instead, along with solid server implementations which have existed for more than a decade.
Less of a Javascript stack for WebRTC
We had a quite elaborate Javascript stack for WebRTC. It did all kinds of fancy stuff, adding a node-style error-first API. We got rid of most of it since the W3C WebRTC API is pretty nice these days. Less code means less potential for errors.
Full Mesh, 2018 style
The biggest problem of using full mesh, everyone sending directly to everyone else, has always been that both bandwidth and CPU requirements have grown linearly with the number of participants. Doing a call with more than four participants was hardly a good experience outside the lab. WebRTC implementations in 2018 are much more advanced than in 2012 and we take full advantage of that by adapting both video capture and bandwidth based on the number of participants.
And yes, we have an SFU on the roadmap too. Because for really large groups you still need a server.
Fully tested
As we have seen in the past there can be changes in a new browser version. WebRTC is still changing quite a bit and in order to protect against this as well as the (much higher) chance of making a change that does not work as expected in all supported browsers we run a series of end-to-end tests. Each of these tests verifies that the video flows in a number of different browser versions and combinations. This may sound simple but requires everything to go right under the hood. Some of them test more rare conditions such as the lack of a webcam.
These tests run on our continuous integrations servers. Some run before and after every deploy, others every five minutes to test the service uptime and a larger set of tests is run each daily to catch changes in new browser versions. We combine this with TestRTC for load testing to ensure the overall platform scales well.
Expect a bit more detail in future blog posts. Until then, give the new SimpleWebRTC a try, and let us know what you think.