Thanks for this very important clarification (ideally, the title should be fixed with this clarification, since most people would be interested in the Jitsi available today).
Is the architecture of the the WebRTC-based solution explained somewhere? In particular, I'm seeking an overview of when it's p2p (how does it scale to large meetings), when it uses a central server, when call quality can degrade (eg: will one low-bandwidth user or an overloaded server wreck the call for everyone), and which links are encrypted. I'd like a reasonable understanding of these aspects before I recommend Jitsi to less tech-savvy friends and family.
Edit: Based on another Jitsi dev's comment in this thread: SFU stands for "Selective Forwarding Unit", which was extracted to a standalone project, Jisti Videobridge.
Comments
Thanks for this very important clarification (ideally, the title should be fixed with this clarification, since most people would be interested in the Jitsi available today).
Is the architecture of the the WebRTC-based solution explained somewhere? In particular, I'm seeking an overview of when it's p2p (how does it scale to large meetings), when it uses a central server, when call quality can degrade (eg: will one low-bandwidth user or an overloaded server wreck the call for everyone), and which links are encrypted. I'd like a reasonable understanding of these aspects before I recommend Jitsi to less tech-savvy friends and family.
Not sure if this answers your specific questions - but I found an article written by a dev from Jitsi, describing the architecture of Jitsi Meet:
Improving Scale and Media Quality with Cascading SFUs
https://webrtchacks.com/sfu-cascading/ (November 2018)
Edit: Based on another Jitsi dev's comment in this thread: SFU stands for "Selective Forwarding Unit", which was extracted to a standalone project, Jisti Videobridge.
Jitsi Meet is only P2P for 1:1 meetings and always uses JVB for meetings with more participants.