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