> despite WebRTC mostly being about client/client communication
This is actually kind of a misconception, though it’s an understandable one given that WebRTC is almost always pitched as a peer-to-peer protocol.
In practice, most people using WebRTC for video are sending their video to a server, not directly to another client. It’s pretty safe to assume that most people who use your app are going to need TURN, and at that point, you’re not really doing peer-to-peer at all, so you might as well just have your browser-based app talk to a server that’s pretending to be another browser.
These servers (called Selective Forwarding Units or SFUs) can operate like a TURN server in the case of a one-on-one call, but they can also multiplex everyone’s feeds in the case of a larger conference (peer-to-peer 5 person calls would require each participant to send 4 copies of their video) and often have extra features like the ability to record calls, transcode streams or convert to other protocols.
The one I’ve used a lot is called Janus[0], it’s open source and has good docs, I recommend people check it out if they’re interested in getting deeper into WebRTC or other video streaming tech.
Another open-source SFU I've had great experience with is Livekit[0]. Great docs, modern, easy to deploy (it's a golang binary), and supports a number of egress options too if you want to record the media during a stream to an external system. With their cloud product they've also built a really cool 'mesh-based' SFU-CDN that allows peers to connect to an SFU closest to them and have their media broadcast to other SFUs internal to their network, which allows for easy scaling during broadcast-style use-cases.
I don’t remember where I read this (think it was some published paper) but I was building some audio streaming thing on top of WebRTC and there was an estimate that 60% of people would be able to do p2p.
I can definitely second janus. At previous job, we used that for video calls/streaming mixed with FFMPEG for some transformations along the way. Really reliable stuff.
This is actually kind of a misconception, though it’s an understandable one given that WebRTC is almost always pitched as a peer-to-peer protocol.
In practice, most people using WebRTC for video are sending their video to a server, not directly to another client. It’s pretty safe to assume that most people who use your app are going to need TURN, and at that point, you’re not really doing peer-to-peer at all, so you might as well just have your browser-based app talk to a server that’s pretending to be another browser.
These servers (called Selective Forwarding Units or SFUs) can operate like a TURN server in the case of a one-on-one call, but they can also multiplex everyone’s feeds in the case of a larger conference (peer-to-peer 5 person calls would require each participant to send 4 copies of their video) and often have extra features like the ability to record calls, transcode streams or convert to other protocols.
The one I’ve used a lot is called Janus[0], it’s open source and has good docs, I recommend people check it out if they’re interested in getting deeper into WebRTC or other video streaming tech.
[0] https://janus.conf.meetecho.com