[kwindla]

Cool!

The good news is that the browser/device/connections issues have gotten so, so much better! All the browsers now mostly agree on aiming towards full compliance with the WebRTC 1.0 spec. The likelihood of something important breaking in a browser release is trending downwards. And the encoding -> network -> decoding pipelines in libwebrtc are pretty robust and performant these days.

But, as someone who has been doing WebRTC stuff since 2014 or so, and started a company that's in part a bet on the WebRTC ecosystem, I have a lot of scars from how long it took to get here. :-)

I'm biased, but I would say that there are still three classes of non-trivial difficulty that add up to "you shouldn't build everything yourself" being the right answer if you're building WebRTC-reliant features that you want to deploy to production:

  1. cross-device issues are still painful and still a moving target

  2. network bandwidth and track/encoding configurations for any use cases more complex than 1:1 calls are a steep learning curve plus lots of corner cases

  3. devops as you scale usage is a lot of work because there aren't any off the shelf cloud provider things you can just turn on and expect to work

Platforms that will take care of (parts of) the above for you include Agora, Vonage, Twilio, and (my company) Daily.co.

[otaviogood]

Maybe we should have tried Daily. :) We tried Twilio video and unfortunately had a really hard time tracking down bugs. Wasted tons of time on that and then went back to doing our own stuff. :( I still don't know where the bug was. Could have been our code or Twilio's. But when we got rid of Twilio and used our own stuff, it resolved the bugs. Was a very frustrating process. Also, the way Twilio video charges seems to assume lots of n-squared, high res connections, which we don't have, so for an application like ours, the cost can be more than 10x less.