3 ms·
This looks to be nicely architected. Looking forward to digging in. In answer to the questions about TURN, this approach won't be lower latency than TURN but w
by kwindla 7y ago
This looks to be nicely architected. Looking forward to digging in.
In answer to the questions about TURN, this approach won't be lower latency than TURN but will scale better. TURN servers are just (nearly) passive relays, so the sending client needs to set up as many outbound streams as there are receiving clients in the session.
The advantage to the TURN approach is that you can do end-to-end encryption.
The server this post is about "forwards" streams. It's in a class of infrastructure traditionally called a "Selective Forwarding Unit." So the sending client can send one stream, and the SFU copies the stream and sends it to the receiving clients. The server needs more CPU and outgoing bandwidth as the receiver count grows, but the sending client doesn't need much of either.
Once you have streams piping through a server, you can do lots of other things, of course. This server can transcode to several formats, including HLS and RTMP, and can copy streams internally across a cluster to scale more than a single machine can.
Media servers are really fun to work on: lots of small(-ish) hard problems that touch low-level network protocols, memory and cpu optimization, architecture (because eventually you want a clean plugins interface, etc.).
If you're interested in this stuff, check out Mediasoup, an open source WebRTC SFU with a very nice design in which all the low-level stuff is c++ and all the high-level interfaces are exposed as nodejs objects.[0]
[0]-https://mediasoup.org/ https://mediasoup.org/
- sansnomme 7y agoHow's the performance and features of mediasoup compared to this? I have been looking for an easy to use DFU.
- kwindla 7y agoHaven't benchmarked ant media server, but mediaSoup performance is very good. "Easy to use" is in the eye of the beholder. Mediasoup isn't a packaged solution; you need to write some javascript to get a server up and running. From this perspective it's a framework that sits at the same level as, say, Express. But the API is flexible and powerful. It's exactly what you want if you're building an SFU cluster for a specific use case and want to decide on the architecture yourself. Here's excellent "1:N broadcast" sample code: [0] With that sample code, you can broadcast a single WebRTC stream to ~500 clients on one vCPU of an AWS c5.large instance. To scale to more clients you need to use more than one vCPU. The new mediasoup v3 APIs make this pretty easy. There are now "pipe transports" and "plain rtp transports" for moving the low-level rtp bits around between processes and between machines.[1] [0]-https://github.com/michaelfig/mediasoup-broadcast-example https://github.com/michaelfig/mediasoup-broadcast-example [1]-https://mediasoup.org/documentation/v3/differences-between-v2-and-v3/ https://mediasoup.org/documentation/v3/differences-between-v...
- tpetry 7y agoThe sad part about selective forwarding units (SFU) is you loose end-to-end-encryption. So you only have encryption between you and the sfu and sfu to your participant. For hosted solutions this means a server could record all your conferences. Therefore i am waiting for the PERC standard. It will allow to send the audio/video to server only once and the server will retransmit to all peers - everything still end-to-end encrpted.
- pjc50 7y agoHow does the key distribution work for that?