I would love to use this instead of zoom. Any news about firefox support?
Jitsi Meet – Improving Scale and Media Quality with Cascading SFUs (2018)
11–20 of 115 posts
Re: Jitsi Meet – Improving Scale and Media Quality with Cascading SFUs (2018)
#12Re: Jitsi Meet – Improving Scale and Media Quality with Cascading SFUs (2018)
#13I have been considering developing a simple video conferencing solution using this approach with WebRTC. Basically, I was planning on doing something like this example [0] of server-side peers or just a set of forced TURN servers, whichever approach being deployed on servers at the edge. I figured using anycast IPs, and having server to server communication across regions before then sending back down to the client w…
Using your first solution (a custom pion SFU relay), and selectively routing the streams between "edge" servers would be similar to Octo, as shown here. Using TURN servers instead would not have the benefit of SFU (i.e. clients will have to upload to each peer) - i.e. its still a full mesh network. Using TURN servers with SFU would work similar to your pion solution, however it would also use more bandwidth, as it wo…
So currently Jitsi meet the one on the web site is NOT e2e encrypted?
Re: Jitsi Meet – Improving Scale and Media Quality with Cascading SFUs (2018)
#14Does anyone know how the audio quality and latency of Jitsi Meet compare with Zoom?
Re: Jitsi Meet – Improving Scale and Media Quality with Cascading SFUs (2018)
#15Re: Jitsi Meet – Improving Scale and Media Quality with Cascading SFUs (2018)
#16I've been excited to try it with our company for a few months, but is it as "user friendly" as Zoom for non-technical users?
Re: Jitsi Meet – Improving Scale and Media Quality with Cascading SFUs (2018)
#17Earlier quoted context omitted.
Using your first solution (a custom pion SFU relay), and selectively routing the streams between "edge" servers would be similar to Octo, as shown here. Using TURN servers instead would not have the benefit of SFU (i.e. clients will have to upload to each peer) - i.e. its still a full mesh network. Using TURN servers with SFU would work similar to your pion solution, however it would also use more bandwidth, as it wo…
>As for e2e encryption over webrtc via an SFU - yes, this is possible, but its currently very messy (wasm video encoding and encryption streamed over an SFU-bound datachannel with full mesh distribution of the encryption key). There are plans to implement "Insertable Streams" which you will be able to transform (e.g. encrypt) which will allow this to work without the hacks. So currently Jitsi meet the one on the web…
I haven't checked, but its possible for 1-to-1 or small meetings they may go full mesh, which would be e2e encrypted - a few platforms do this.
edit: just checked and jitsi is "full mesh" for 2 participants - if you have 3 or more (video) participants, it switches over to SFU.
Re: Jitsi Meet – Improving Scale and Media Quality with Cascading SFUs (2018)
#18It's a fantastic open source solution. Can be self hosted. It is to note that traffic does go through the server, hence need decent bandwidth. the server afaik does have the keys to decrypt traffic
Traffic only goes through the server for users behind NAT, triggering the TURN path.
Re: Jitsi Meet – Improving Scale and Media Quality with Cascading SFUs (2018)
#19I've been excited to try it with our company for a few months, but is it as "user friendly" as Zoom for non-technical users?
Re: Jitsi Meet – Improving Scale and Media Quality with Cascading SFUs (2018)
#20It's a fantastic open source solution. Can be self hosted. It is to note that traffic does go through the server, hence need decent bandwidth. the server afaik does have the keys to decrypt traffic
I setup my own server yesterday and shutdown the server in the middle of a conversation. The conversation kept going. Traffic only goes through the server for users behind NAT, triggering the TURN path.
Source: https://github.com/jitsi/jitsi-meet/blob/master/doc/manual-i...