I am so impressed how quickly LiveKit has developed and become polished. If you missed it they wrote a really good article on it here[0]
I also really love as a company how LiveKit operates. I work on an Open Source library they use (Pion). They contributed so much upstream and take an active part in the community. They also publicize that they are using it. It is great seeing people doing the 'right thing' succeed :)
We've been building a live-streaming & remote operation system for drones using LiveKit. I've been extremely impressed at the speed they've delivered improvements and grateful of how supportive DZ & the LiveKit team have been of us. It's definitely the right choice if you're looking for a modern SFU system to run. Congrats on reaching 1.0!
Serious question: why does an SFU need TURN? Is it just because you already had centralized stream broadcasting and making it TURN compliant was low-hanging fruit?
Technically an SFU doesn't need it. But clients connecting to the SFU will probably need it.
Also having a TURN server allows for very restricted corporate scenarios, such as everybody connecting through a single, well known port (as Sean's S.O. reply mentions in the sibling comment).
For example in OpenVidu (not trying to plug it here so won't put a link) a Coturn server is deployed, and TURN credentials are automatically shared with all clients (web browsers, mobile phones) so they can access the SFU through the Coturn instance, if needed. People are using this on very restricted networking setups for allowing connections between differently segmented networks, some of them not even connected to the internet.
I see, so the TURN server negotiates the access authorization (and provides a single connection point), but then the SFU handles the routing between peers.
Is there a way to get a standard TURN server to reuse outbound streams for 3+ user chat? E.g. I have a CoTURN install that is strictly used for audio and while I'm not too concerned about bandwidth at my server, I'm very concerned about uplink bandwidth for users with asymmetric connections (which is practically all of them).
I'm sorry to bug you here, but it's so hard to find anyone who actually knows much of anything about WebRTC who isn't just parroting stuff they read on Stack Overflow. Half the time I get the same, subtly-wrong answers about basic signaling, even when my question isn't even about signaling.
Would be nice to have a Rust client SDK that could be used across desktop platforms, but particularly on Windows. I suppose though that could involve some nasty build system wrangling, to embed Google's WebRTC library in a Rust crate.
I think https://webrtc.rs/ is our best bet for this future. I am very optimistic about it. The security/memory safety aspect of it is just so important.
So many important things are happening over WebRTC (telemedicine, remote control of dangerous machines...) I just would hate to see one of these C++ memory bugs have a negative impact.
Do you think it would be practical to rewrite even the hard audio DSP stuff, like echo cancellation, in Rust? Or should webrtc-rs use bits and pieces of Google's WebRTC C++ library for that? I certainly see the benefits of not using the whole C++ library, with its threading model and all.
It certainly would be nice! Having a common layer for signaling (whether Rust or C++), which could be used across client SDKs is something we're evaluating. You'd still need a (albeit thinner) platform-specific SDK for the final interface and to abstract away any quirks.
I'd recommend Rust for your shared client core, even though for short-term practicality you probably have to keep using Google's C++ WebRTC library, because translating your existing high-level client code to safe Rust would be easier than translating it to reasonably safe C++.
If you're interested in pursuing this, the best starting point I've found for using the WebRTC C++ library from Rust is this: https://github.com/arcas-io/libwebrtc So far it looks like it only works on Linux and Mac.
Thanks for the pointer to that project, we'll take a look. =)
On your recommendation of Rust over C++, is the thought to deal with the double-bridging (platform-sdk => rust => libwebrtc) until webrtc.rs gets to a point where libwebrtc can be swapped out?
Yeah, I'd do double-bridging for now. The Rust/C++ bridging is pretty low-overhead IIUC, but getting it all to build and link together is probably a pain.
If I wanted to build a Twitch clone for internal social activities at my company, would this be a good tech stack for that or is WebRTC not the right fit?
You certainly could, there are some folks in the community building Twitch-like livestreaming experiences with LiveKit. One of my teammates built a mobile livestreaming demo app, perhaps I can convince him to release the code. ;)
Update:
Given that this is for internal use at your company, a single LiveKit node should be perfectly fit to handle the scale you need.
I am so impressed how quickly LiveKit has developed and become polished. If you missed it they wrote a really good article on it here[0]
I also really love as a company how LiveKit operates. I work on an Open Source library they use (Pion). They contributed so much upstream and take an active part in the community. They also publicize that they are using it. It is great seeing people doing the 'right thing' succeed :)
[0] https://blog.livekit.io/livekit-one-dot-zero/
We've been building a live-streaming & remote operation system for drones using LiveKit. I've been extremely impressed at the speed they've delivered improvements and grateful of how supportive DZ & the LiveKit team have been of us. It's definitely the right choice if you're looking for a modern SFU system to run. Congrats on reaching 1.0!
Thanks Roshan!
Was a joy to use on a side-project I was working on. Worked great with Svelte. Deploying a local dev server is easy too.
Serious question: why does an SFU need TURN? Is it just because you already had centralized stream broadcasting and making it TURN compliant was low-hanging fruit?
Technically an SFU doesn't need it. But clients connecting to the SFU will probably need it.
Also having a TURN server allows for very restricted corporate scenarios, such as everybody connecting through a single, well known port (as Sean's S.O. reply mentions in the sibling comment).
For example in OpenVidu (not trying to plug it here so won't put a link) a Coturn server is deployed, and TURN credentials are automatically shared with all clients (web browsers, mobile phones) so they can access the SFU through the Coturn instance, if needed. People are using this on very restricted networking setups for allowing connections between differently segmented networks, some of them not even connected to the internet.
In some cases a TURN server is still required[0]
Until ICE supports TLS/DTLS it is worth deploying. I hope to fix this in the near future though!
[0] https://stackoverflow.com/questions/61287054/understanding-s...
I see, so the TURN server negotiates the access authorization (and provides a single connection point), but then the SFU handles the routing between peers.
Is there a way to get a standard TURN server to reuse outbound streams for 3+ user chat? E.g. I have a CoTURN install that is strictly used for audio and while I'm not too concerned about bandwidth at my server, I'm very concerned about uplink bandwidth for users with asymmetric connections (which is practically all of them).
I'm sorry to bug you here, but it's so hard to find anyone who actually knows much of anything about WebRTC who isn't just parroting stuff they read on Stack Overflow. Half the time I get the same, subtly-wrong answers about basic signaling, even when my question isn't even about signaling.
Yea! TURN can just be the authorization/entry point into your network. The SFU is in charge of actually shuffling the packets between peers.
You will need to use a SFU to reuse outbound streams unfortunately.
Happy to help more on https://pion.ly/slack! I come back to HN once or twice a day, but will see your questions instantly. I am `Sean-Der` in `#pion`
Would be nice to have a Rust client SDK that could be used across desktop platforms, but particularly on Windows. I suppose though that could involve some nasty build system wrangling, to embed Google's WebRTC library in a Rust crate.
I think https://webrtc.rs/ is our best bet for this future. I am very optimistic about it. The security/memory safety aspect of it is just so important.
So many important things are happening over WebRTC (telemedicine, remote control of dangerous machines...) I just would hate to see one of these C++ memory bugs have a negative impact.
Do you think it would be practical to rewrite even the hard audio DSP stuff, like echo cancellation, in Rust? Or should webrtc-rs use bits and pieces of Google's WebRTC C++ library for that? I certainly see the benefits of not using the whole C++ library, with its threading model and all.
It certainly would be nice! Having a common layer for signaling (whether Rust or C++), which could be used across client SDKs is something we're evaluating. You'd still need a (albeit thinner) platform-specific SDK for the final interface and to abstract away any quirks.
I'd recommend Rust for your shared client core, even though for short-term practicality you probably have to keep using Google's C++ WebRTC library, because translating your existing high-level client code to safe Rust would be easier than translating it to reasonably safe C++.
If you're interested in pursuing this, the best starting point I've found for using the WebRTC C++ library from Rust is this: https://github.com/arcas-io/libwebrtc So far it looks like it only works on Linux and Mac.
Thanks for the pointer to that project, we'll take a look. =)
On your recommendation of Rust over C++, is the thought to deal with the double-bridging (platform-sdk => rust => libwebrtc) until webrtc.rs gets to a point where libwebrtc can be swapped out?
Yeah, I'd do double-bridging for now. The Rust/C++ bridging is pretty low-overhead IIUC, but getting it all to build and link together is probably a pain.
Arcas is fantastic! They are doing some really great work with WebRTC.
If you did not know, there is also https://github.com/signalapp/ringrtc by the Signal App team, which is written in Rust
If I wanted to build a Twitch clone for internal social activities at my company, would this be a good tech stack for that or is WebRTC not the right fit?
I don't know about LiveKit, but I work at Daily (https://www.daily.co) which uses WebRTC for client connections.
You can definitely use Daily to build a Twitch clone and beyond — we have a powerful API for custom layouts and graphics in live streams.
You certainly could, there are some folks in the community building Twitch-like livestreaming experiences with LiveKit. One of my teammates built a mobile livestreaming demo app, perhaps I can convince him to release the code. ;)
Update: Given that this is for internal use at your company, a single LiveKit node should be perfectly fit to handle the scale you need.
Do you want to build a Twitch clone, or are you unhappy for one reason or another with the existing selfhostable FOSS projects doing this?
You can do it with WebRTC just remember that it is meant for low latency video connections. The trade off is a higher bitrate and no caching.
How does this compare to mediasoup?
Related, check out OvenMediaEngine: https://github.com/AirenSoft/OvenMediaEngine