scale jitsi - make videochat more efficient

Jan Doberstein -

I run a jitsi installation - like described previous - that gets used more and more.

I had to learn that jitsi does not only use peer-to-peer communication, that all is done also in parts via the server. The initial statement that you can happily run it on small scale hardware is true - but only if you do not want to have not more than 10 people in one room only.

The journey of how to scale that starts fast if people get used to using this software. The solution is easy - once you know - but hard to get because the information is well hidden and scattered around different places.

scale jitsi - initial setup

Use the unstable build for your installation. The improvements are significant and at the time of writing, they are not yet merged to the stable release.

# install the key
wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | apt-key add -
# add the unstable repo
sh -c "echo 'deb https://download.jitsi.org unstable/' > /etc/apt/sources.list.d/jitsi-unstable.list"
apt update

Install the first server with jitsi-meet - as written previous. Complete the installation with let's encrypt.

adding more power

The true resource eater is the video bridge in jitsi and that is the component you need to scale (first). In the latest release, this is quite easy - because the communication is done via XMPP protocol and the first server (the installation of jitsi-meet) includes the control & chat server for all components.

On the first server, open the communication in the firewall.

ufw allow in 5222

Prepare the second server, install the same repository as on the first server but now install only jitsi-videobridge to get the necessary package installed. On Debian this is

apt install jitsi-videobridge

The question should be answered with the local hostname of this server.

Copy the file /etc/jitsi/videobridge/sip-communicator.properties from the first to the second server and the same location.

Check that the setting org.jitsi.videobridge.xmpp.user.shard.MUC_NICKNAME is unique on each server. The default installation is using a UUID for that.
If you are like me and just left the first server in the default settings add the setting to the same configuration file that certificates are not validates

echo "org.jitsi.videobridge.xmpp.user.shard.DISABLE_CERTIFICATE_VERIFICATION=true" >> /etc/jitsi/videobridge/sip-communicator.properties

To be able that the second videobridge can join the other you need additional the /etc/jitsi/videobridge/config to be modified. The settings JVB_HOST and JVB_SECRET needs to be the same on all hosts.

After a restart of the jitsi-videobridge server, you have now two servers for videoconferencing. That share the load.

Should you want to test this - create a room, connect with two browsers and share your video. Stop the videobridge on the first server and the only what you might notice is a short blip in the video.

other notable information

When you have Java 11 installed on Debian 10 you might need to adjust one setting like mentioned on stackoverflow. Your logfile will show something like the following if that is needed:

JVB 2020-03-21 19:29:23.687 SEVERE: [16] org.jitsi.utils.concurrent.RecurringRunnableExecutor.log() The invocation of the method org.jitsi.videobridge.stats.StatsManager$StatisticsPeriodicRunnable.run() threw an exception.
java.lang.reflect.InaccessibleObjectException: Unable to make public long com.sun.management.internal.OperatingSystemImpl.getTotalPhysicalMemorySize() accessible: module jdk.management does not "opens com.sun.management.internal" to unnamed module @54ca3634
    at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)
    at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)
    at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:198)
    at java.base/java.lang.reflect.Method.setAccessible(Method.java:192)
    at org.jitsi.videobridge.stats.OsStatistics.getTotalMemory(OsStatistics.java:138)
    at org.jitsi.videobridge.stats.VideobridgeStatistics.generate0(VideobridgeStatistics.java:703)
    at org.jitsi.videobridge.stats.VideobridgeStatistics.generate(VideobridgeStatistics.java:450)
    at org.jitsi.videobridge.stats.StatsManager$StatisticsPeriodicRunnable.doRun(StatsManager.java:321)
    at org.jitsi.utils.concurrent.PeriodicRunnableWithObject.run(PeriodicRunnableWithObject.java:87)
    at org.jitsi.utils.concurrent.RecurringRunnableExecutor.run(RecurringRunnableExecutor.java:216)
    at org.jitsi.utils.concurrent.RecurringRunnableExecutor.runInThread(RecurringRunnableExecutor.java:292)
    at org.jitsi.utils.concurrent.RecurringRunnableExecutor.access$000(RecurringRunnableExecutor.java:36)
    at org.jitsi.utils.concurrent.RecurringRunnableExecutor$1.run(RecurringRunnableExecutor.java:328)

The mighty @nicolaiBuchwitz has created an icinga plugin to monitor Jitsi with Icinga. Check that if you want to monitor your Jitsi.

The munich freifunk group has a very nice overview and description about how to use Jitsi in their wiki. The target is for endusers and is available in english, german, french and italian - at the time of writing.

(Update 26.03.2020) Depending on your needs and environment you might not want that everyone is having the ability to create rooms - for that you need to add user authentication and limitations to the setup - this little guide gives you the right information.
If you run this in some kind of corporate environment you might want to adjust the above how-to to use IMAP Authentication to the XMPP server, that all employees are able to create sessions and you do not need to maintain a user database.

Photo by Alex Kotliarskyi on Unsplash