I have shipped WebRTC on three different products now, and it still surprises me. I am not proud of that. It is just the nature of the beast.
Every time, the beginning is identical. You get a call working between two browser tabs on your laptop in an afternoon, lean back, and think, huh, this was not so bad. And every single time, reality turns up a few weeks later wearing a different costume.
The first product, it was one-way audio. One person could hear, the other could not, and nothing in the logs looked wrong. I lost most of a day before I understood it was not my code at all. The two users just could not find a media path, and I had no relay in place for when that happens. Which, on real networks, is a lot.
The second product taught me about groups. Two people on a call is nothing. Then someone demoed it with the whole team, twelve people, and one guy's laptop fan spun up like it was about to take off, because in peer to peer every person is sending their video to every other person. That was the day I learned what an SFU is, the hard way, in front of people.
Third one, it was the guy on a train. Worked flawlessly in every test, then a customer joined from a moving train and the call fell apart every time his phone hopped between towers and changed IP. Totally invisible in the office. Totally reproducible on a train I was not on.
None of this is because WebRTC is bad. It is genuinely great, and nothing else gives you real time voice and video in a browser with that kind of reach. It is that the browser API is maybe a tenth of the actual job. The other ninety percent is networks behaving like networks, and networks do not care about your demo.
What I have made peace with is that you cannot really test your way out of this from a desk. The failures live out in the messy real world, on hotel wifi and locked-down office firewalls and trains. You either go find them on purpose, or your users find them for you.
So these days I plan for the ugly part from the start instead of acting shocked when it shows up. And when the real time side of a product gets serious enough that trial and error stops being an acceptable strategy, that is usually when it is worth pulling in WebRTC developers who have already collected all these scars, rather than earning a fresh set live.
Anyway. That is my list. What is the weirdest WebRTC failure you have hit in production? I have a feeling a lot of you have a train story of your own.
Top comments (0)