|
|
|
|
|
|
by kwindla
1487 days ago
|
|
|
Google Meet is WebRTC in production. As is Discord video and audio, Facebook messenger video, and Whatsapp calls. There are several WebRTC-as-a-service platforms that are relatively large and are used by diverse applications (meetings, telehealth, teaching/tutoring, events). I co-founded and work at one of them (Daily.co YC W16). WebRTC is almost the only choice for low-latency video and audio inside a web browser. The open source libwebrtc [1] implementation that's in Chromium and Safari is now mature enough to be used in other native applications if you have a medium-sized engineering team and are comfortable with C++. (Again, WebRTC-as-a-service platforms often provide native libraries that wrap libwebrtc to give you easier to use full stack iOS, Android, (etc) SDKs.) The three big challenges with WebRTC are that low-latency media is its own domain and the learning curve is steep, that scaling sessions to more than two or three people requires a lot of server-side packet routing code (you can't do pure peer-to-peer with lots of participants), and that there aren't yet the mature "off the shelf" cloud building blocks that exist for HTTP-ish workloads. WebRTC data channels are the non-video/audio part of the WebRTC spec. My hot take: data channels are rarely the right solution to any problem description that doesn't start with, "well, I already have a WebRTC transport open ..." [1] https://webrtc.googlesource.com/src |
|
|
On the off chance that you're still checking this thread, would you care to elaborate? Specifically, if one isn't using WebRTC for media, is there a better off-the-shelf solution for P2P with NAT traversal in native apps?