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.

Hello Jitsi dev, well done on terrific product. Can I float a feature request by you? It would be great if the mobile app, and maybe the web app via a safe subdomain, could prevent the use of short 'test' room names so as to avoid children accidentally getting a chatroulette experience? I'm a little hesitant to recommend it to my fellow school-parents as it stands.

One option you have right now is to use the external API and embed it on a page.

https://github.com/jitsi/jitsi-meet/blob/master/doc/api.md

I've done this and created a UI for adding rooms, which is in my control.

We are working on this right this instant. Expect updates soon!

That's good to know. Apparently "Jitsi" was evaluated at my company before I joined but now I'm wondering whether it was the desktop project or Jitsi Meet. Are they strictly desktop and Web-based, respectively?

They are completely different projects. Jitsi (desktop) was a multi-protocol desktop client whicch supported SIP, XMPP, IRC, etc.

At one point in time it gained the hability to do multi-party video conferencing, where one participant would become the "focus" and forward everyone's video to everyone else.

This was the inception of the concept of an SFU or Selective Forwarding Unit.

Then, in order to scale this up the SFU was extrated to a standalone project: Jitsi Videobridge.

Roughly around then, WebRTC became a thing and Jitsi was already doing many of the required things to bring the experience to the web, so work continued with Jitsi Meet, a WebRTC compatible video conferencing system.

Jitsi Meet is our present and future, but Jitsi (desktop) lives on both as pieces of the puzzle (Jitsi Videobriidge, Jigasi and Jicofo use parts of it) and as a community project, where people interested in keeping it alive ssubmit fixes / improvements.

quick question : is the videobridge a multiplexer -- that is all the clients send the webrtc stream to Videobridge and it combines and forwards the streams to the clients ? Or is it signalling server(STUN) and the clients forward streams to each other ? I am asking this as to decide if I could host the videobridge on on home network (video output from multiple clients would be a problem) or if I have to host this on a cloud ?

I think you have a couple of things mixed up. A stun server is different from a signaling server. Jitsi is an SFU, which is neither. The behavior you describe with combining streams is what we call an MCU. An SFU is simpler and just forwards streams. Most of the logic of an SFU is in controlling RTCP protocols, which are typically aimed at one-to-one use cases. An SFU has to make this work for a one-to-many use case.

The videobridge receives all streams from all participants and forwards the appropriate ones to the other participants.

So as the group members increased it also increases network usage on the SFU server?

Correct.

Hmmm, what happened to the WebRTC using p2p method, where as the member increase so does the bandwidth? Like torrent?

Thanks for your work. Within days Jitsi became a tool for my family and friends to stay sane and to improvise school for multiple kids.

I was just about to comment on how using OSGi probably doubles your engineering effort (and cost!) quite substantially for very little benefit.

Source: I've developed OSGi applications professionally for nearly 9 years.

btw I <3 Jitsi Meet

Yet the Jitsi developer seems to credit OSGi as an essential basis of the project. They suggest that such a modular and dynamic architecture was necessary to support so all these protocols, platforms, etc. What would you suggest as an alternative (including things that are available now, but not then)?

The parent comment here implies they rewrote it after the article was written.

I read the bit on OSGi. It seems to support interfaces, runtime loading and unloading of modules, and a way to discover modules. Java 1.0 did all that stuff natively, though JPMS adds some more capabilities, since I guess people don’t like package private, etc.

C++ also supports these things. (C does too, but you need non-standard dynamic linker constructor/destructor extensions that are available on all platforms).

I can’t think of any widely used language without support of such things.

Question since you're on the thread - we are currently using a Janus based SFU for our project - which is a 3d application for avatar voice chat. Any obvious tradeoffs between Janus and Jitsi worth considering? Are there existing examples of Jitsi deploys running, say, rooms with 50-100 concurrent voice-only channels in a room with tens of such rooms on a server? Thanks!

Are they compatible? In other words can jitsi desktop connect to a jitsi meet session?

It appears[1] not:

"Jitsi Desktop is a xmpp, sip desktop client which has audio video capabilities, but cannot interconnect with jitsi-meet."

[1] - https://community.jitsi.org/t/jitsi-desktop-for-use-with-jit...

Kind of... Jitsi lives on in the SIP bridge: https://github.com/jitsi/jigasi

Well, seems like this confusion is inevitable, when two completely different (and incompatible?) projects use almost the same name, just because they are developed by the same group or for stronger brand recognition.

Jitsi Meet sounds interesting.

Thanks! Title changed above.