JVB 2 considered stable

We’ve been running JVB 2.x on meet.jit.si for a couple months now and on our prod environment for 2 (very extreme) weeks, so wanted to let everyone know that we now consider JVB 2.x stable. Because of all the craziness, we haven’t been able to do some work to change the stable debian packages over to use JVB 2 yet, so sorry for the inconvenience, but for anyone wondering know that we do consider it production-ready at this point.

We’re being conservative with commits into master right now, so the tip should be considered stable, but 2.1-142-g668a88a9 can definitely be considered safe.


I see current “jitsi-videobridge” is packaged as version 1126-1 (?!)

I see current “jitsi-videobridge” is packaged as version 1126-1 (?!)

As I mentioned in the original post, we’ve not yet migrated over the stable debian package to use JVB 2.


What are the key new features or improvements? I think I read somewhere about it, but some more info would be nice.

After the Debian packages are updates, is this guide going to be affected or needs change with JVB2?

Same question for the secure domain:

And also for the multi video bridge install guide, that comes as video:

Looking forward to see this in action.


1 Like

We are working on making jvb2 installed by default by packages, which is step one before promoting to stable the packages.
To workaround, update to latest from unstable repo. Then do:

apt-get remove jitsi-meet
apt-get install jitsi-videobridge2

Do these configs stay the same?
nano /etc/jitsi/videobridge/sip-communicator.properties

How about these for adding multiple video bridges

My “question” was about package version numbering.

We are very interested in building a cluster setup, and I was attempting to apply what is suggested in this video today but in a dockerized environment. Does this video apply to the current docker images as well, or do we need more recent code base?
It seems I managed to create the individual jvb domains, but jicofo is complaining Jicofo 2020-03-24 20:51:45.504 SEVERE: [37] org.jitsi.impl.protocol.xmpp.ChatRoomImpl.log() Unable to get occupant for jvbbrewery@internal-muc.meet.jitsi/e3d7015ef274
and no conferences can be setup (Jicofo 2020-03-24 20:30:28.629 SEVERE: [37] org.jitsi.jicofo.JitsiMeetConferenceImpl.log() Can not invite participant – no bridge available.

I used the video step by step with Debian packages and I got it to work, well, I got both jvb happy in their logfiles and also no errors in jicofo. BUT, I have not yet seen a conference being run on the secondary JVB, not idea what would be required, it did cause a lot of CPU on JVB 1, but still the next call was on JVB1 as well.

No idea on docker, was thinking about it, but not tried yet.

@florianoverkamp That video is from 2018 and is already deprecated I think.

I’ve been trying to wrap my head around adding just one jvb to a basic debian installation for a few days now and looked into that video too, but while looking through the community it seems that there is a newer method that makes adding of jvbs easier by using MUC “rooms” in prosody.

This document on MUCs looks similar to some suggestions on here, but for some reason I can’t get it to work. It is missing a few steps and not knowing the big picture of Jitsi yet, it’s hard to figure out what’s going wrong.

The debian packages from unstable on clean machine should come with mucs enabled, you can try that.
We are currently updating the debian packages preparing for jvb2 release and stable update.


Is the docker version, if I do the below, using videobridge2.
git clone https://github.com/jitsi/docker-jitsi-meet && cd docker-jitsi-meet
cp env.example .env
mkdir -p ~/.jitsi-meet-cfg/{web/letsencrypt,transcripts,prosody,jicofo,jvb}
docker-compose up -d

Just had a conference with our default setup (Debian packages on AWS c5.xlarge, 4 cores) with 20+ participants, and I think always beyond 20, the conferences go bad.
I am hoping that videobridge2 might help out here.

Having the same situation here: fired up a second JVB, but the other JVB is not approached by Jicofo, even if one has a load of 20. Only when booting all, both work for a while (maybe until one crashes and then is never re-assigned, even if it reports nice health reports). But maybe this is a jicofo issue.

Looking forward to the new setup with rooms and JVB2.

I just noticed the recommended jitsi-meet-turnserver package in unstable depends on nginx, but on on “or apache2” as jitsi-meet-web-config.

Are there plans to move away from apache2 completely?

I wouldn’t expect the behavior you’re seeing, but we’ve got some changes (in Jicofo) incoming about bridge selection that should be merged soon (~this week) which may also help here. You can follow the pr here.

1 Like

We are not moving away, it is just apache not supporting certain features.

Thanks for the clarification. I was just playing with the unstable packages and noticed that nginx was to be installed even though I had apache2 installed before.

It’s still important to install nginx before jitsi-meet it seems. Otherwise I’ve been getting issues with nginx not being able to restart and such.

Oh that maybe a problem … indeed. I will test it :frowning:

Also test without installing any browser first. It adds nginx since it is required, but it doesn’t work after on my Debian 10. I had no time to look into it in more detail.