Note that this article is about the legacy Jitsi desktop application, and NOT about Jitsi Meet, the WebRTC compatible video conferencing project. Source: I'm a Jitsi dev.
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.
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.
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.
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!
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.
One thing we’ve found in deploying Jitsi several times is that good performance is difficult to achieve across parties who are across the globe.
We have some of our team in Armenia, Belarus and London and not all of then get consistent performance.
I know you can do geographic sharding so all EU or US guests get connected to their closest server but is there a way to ensure cross country participants all get good performance?
- have the SFU (videobridge) in a more "central" location
- have multiple videobridge installations (cascaded bridges) where required with a low latency interconnect (its effectively a smart relay).
- you could use geographically distributed forced TURN servers with low latency interconnect to the SFU, but it would be more bandwidth intensive, and not really useful unless you truly have a REALLY low latency interconnect.
----------
Reducing the quality of the streams may also help, if it is bandwidth that is the constraining factor.
I've installed my own instance of Jitsi and it's particularly useful for video chats with older people or those less technically able.
My use case is elderly in-laws who can use a laptop, but are incapable of installing anything other than malware. Installing Zoom would be too complicated for them and would probably discourage them from participating in a family video chat.
With Jitsi, I send them a link by email and text them to check their email. They click on the link, browser opens and voila! - they're able to chat with their family, with zero fuss.
Costs me €2.49 per month for a Hetzner cloud instance.
Agreed! This week I used Jitsi Meet (not the self-hosted version, but I like that I can set that up if need-be) to do just that; contact technologically illiterate family members without me or them needing to have a certain OS (on smartphone, tablet, or personal computer) and set up some app.
Just a modern browser on a device with a camera and microphone. This is how this type of software should work.
Is there any feature difference between the hosted service on meet.jit.si and a self-hosted installation? I've tried looking for more information about this but I couldn't find anything.
I think the feature set is similar. I went for self-hosted in the hope that I wouldn't suffer from bandwidth/server load problems from using Jitsi's servers.
Quality was acceptable with 4 family members participating from 2 countries, including elderly folks on French rural ADSL.
Yes and no. If they're using a PC, yes; if not, they need to download and use the app. (Unless you can direct them to the “Use desktop page” setting in Chrome.)
Put nginx in front of it with Let's Encrypt and it shouldn't take more than half an hour to set up. After that you basically get a clone of meet.jit.si.
I'm using it with the low level JS library in order to build a product that contains video chat. There was a bit more messing about for me, but only a bit.
nginx and letsencrypt are already included in the docker image - just uncomment the letsencrypt variables in the .env config file :) hope that saves you some time.
Ah of course, I forgot that was included. I couldn't use that myself due to CORS and a few other things but if you just want Jitsi in a box it would work for sure.
I purchased a basic vps cloud instance from cloud.hetzner.com for €2.49 per month. 20TB of traffic a month is included, which should be sufficient. Hetzner has good network connections for European users.
Installation on Ubuntu is a breeze using an install script. It's important to complete the installation with some letsencrypt SSL certs and then you're good to go.
I created a subdomain (new A record pointing at ip address of my Jitsi server) on my business domain to make it easy for family members to go to the server themselves and create their own meeting rooms.
TIL Hetzner offers a ridiculous amount of monthly traffic. Is there anything even remotely this good hosted in the US? DigitalOcean only gives 1TB/mo per 5USD instance.
I also set up jitsi, in my case on an ubuntu server 18.04 VM on my desktop [0]. Took about 10 minutes as well to follow that guide.
In addition, I wanted to expose jitsi to the internet but not allow random people to create or join rooms. I basically followed the first part of this[1], which sets up username/password pair that you're prompted for each time you create/join a room.
edit this file:
/etc/prosody/conf.avail/HOSTNAME.com.cfg.lua
Look for the first `authentication` line for HOSTNAME.com and change it to `internal_plain`
This is enough to make a password prompt pop up every time someone creates or joins a room, and it autofills nicely after you enter it the first time on firefox/chrome/android app. If you follow the rest of the guide you can set up a second domain people can use to join rooms without a password prompt.
This makes me feel a bit better about exposing this to the internet. Not sure if there's other havoc someone could cause though.
[0] thankfully I have fast internet with a public IP
(as far as I can tell, I don't really understand what Prodosy is)
Prosody is always running, whether or not you have it configured with a password. So I'd guess zero extra load.
Additionally, without a password your server is wide open, letting anyone start their own conference calls. I would guess that load could be significantly reduced by stopping unknown people from connecting.
(I still don't understand jitsi meet's architecture well though, so there could be ways around the password)
I love Jitsi, before Covid19 I never used it, now I use it daily for calls with family and yesterday I watched a video of our 4x4 trip with friends together with them (5 guys), streaming it from YouTube into the group chat. It worked very well.
We tried Jitsi Meet as a back-up for Google Meet in our company for the daily scrum, and it works great. The only nit-pick is the Firefox performance bug, but it's not too demanding to use Chromium for now just for Jitsi Meet until that bug gets fixed.
My colleagues loved the Youtube playback ability (I put on some elevator muzak waiting for the rest to join), although I had to do a bit of hunting to get rid of the video again. :)
Doesn't this make jitsi meet _effectively_ chrome only until they better support firefox/safari/etc[2].
[1]: I get "It looks like you're using a browser we don't fully support....We recommend to try with the latest version of Chrome or Chromium" when trying to use it.
[2]: Sounds like webrtc isn't well supported and fairly buggy for some browsers, apparently?
I use it in Firefox all the time with no difficulties. The only thing that doesn't work for me is selecting an external (USB PnP) microphone, but apparently that's due to a longstanding bug in Firefox that Jitsi is doing its best to work around.
In a previous discussion on HN about Jitsi, it was claimed that Firefox was missing some key aspect of the WebRTC standard that made sending video to multiple people more efficient; and that if a single person in the conference was using Firefox, the result would be a lot more CPU utilization for everyone.
So it "works" on Firefox, but the experience will be degraded when scaling up to more users. Hopefully FF can prioritize this feature now that the entire world needs high-quality video conferences on a regular basis.
Firefox works as well, but performance issues may arise when the number of participants increases. I've used Jitsi Meet with Firefox, and its fine one-on-one.
I spent a ton of time looking at Jitsi yesterday because I’m getting fed up with FaceTime. I really want a living room solution on my large flatscreen because we’ve been spending loads of time doing extended video chats (30+ minutes) with family members. Stuff like family trivia night, etc. The iPhone/iPad screens are too small and really its a pain to hold it in place. I’ve been using a tripod to help some with the holding but the fixed lens is really limiting without an extended HDMI cord. I’ve been connecting to the TV via HDMI but the sound/input is still via the device and the iPhone refuses to do landscape mode. Overall, it’s just suboptimal.
Jitsi is open source, has an option for me to host my own server (avid self-hoster for privacy), and appears to work on just about any platform. So I should be able to get most of the family to adopt it.
So now I suppose my question is how do I get Jitsi running on my TV? Or can someone offer some other solution that might fit my use case? I really would like to be able to just go to my TV, turn it on, and have instant ability to video chat from my living room to family members on nearly any device.
My first thought was to get it running on an Raspberry Pi but it seems that’s not really something that works from all of my searching. Does anyone have any experience there?
If that’s the case is there a cheap Android device that could achieve this with some sort of decent camera? Or am I stuck running an x86 system attached to my TV?
Does anyone else have Jitsi setup in a conference room like setting with a TV?
Primarily price and power consumption. Having the ability to run something like this on a cheap ARM single board computer would be significantly cheaper. Plus, I have a stack of Raspberry Pis in my office. Who knows how long it would take to order and receive a small form factor x86 system right now.
Please someone correct me, but my understanding is that Jitsi meet has a very different architecture compared to Zoom.
Jitsi Meet uses a "SFU" which means the A/V stream of each participant is sent to all the others. That basically does not scale in terms of network bandwidth.
Zoom seems to use a central server that kind of "mix" streams and send them to all participants. Or something hybrid.
Jitsi could be able to connect to an "MCU" like OpenMCU for this kind of architecture, but I have no clue if it is easy or not to deploy.
I am working in a full-remote company with ~15 people. Jitsi is ok for meetings with 2-4 people. With more people, it just does not work reliably. Zoom does.
Zoom also use the Selective Forwarding Unit (SFU) architecture. Or a central server that kind of "mix" streams and send them to all participants, if you will.
Jitsi Videobridge does this by receiving simulcast streams from each participant. This server individually picks out streams and qualities that will fit in each recipient's downstream pipe based on measured bandwidth and configured priorities (e.g. you could choose to give more bandwidth to those who are actively speaking, or shut down all but the last N speakers video streams).
Yes, the available network bandwith on a Jitsi Videobridge could be a bottleneck. Each meeting need to fit on a single bridge instance. However, using common servers connected at 1 Gbps or 10 Gbps, it shouldn't be any problem to have meetings with substantially more than 2-4 people. Say a HD stream from most webcameras outputs 3 Mbps at full blast, with 50% overhead due to the simulcasting. That's over 2000 participants on a single server connected at 10 Gbps, all receiving all video streams in full quality.
For meetings with 2 participants the streams run peer to peer, so here you get the best possible latency and quality.
We've set up Jitsi on a VPS instance at a nearby provider, and have not seen any problems with meetings of 10-15 people. Stability and performance also outperforms all the other solutions I've tried. There's currently a bug in Firefox's simulcast implementation, so if you have any participant using this browser, this feature gets disabled for everyone. Even with this issue, I haven't noticed anything but excellent performance with this few number of participants.
What do you mean with the schedule point? You tell everyone when to join, they join, meeting starts. The rooms exists when someone is in there, you don't need to open them at a certain time.
Also, there's a thing called "calendar". One can send invitation for a specific time (via another cutting edge tech, "email"), and include an URL to the meeting.
Some people even like the fact, that they have their scheduling info in the same place!
