I want to monitor (and keep open) several Jitsi rooms on our self-hosted server. To this end, I wrote a small website which joins some rooms (username Big Brother ) in separate iframes using the Jitsi Meet API. I can then poll the list of participants etc. using the API JS objects.
It works fine for 1 to 3 or 4 sessions. If I try to join more sessions at once, the browser drops out of one or more of them more or less regularly (trying to reconnect…, ping timeouts, …). When I open more than 6 sessions in Google Chrome, I see „Waiting for websocket“ – probably because Chrome is limited to 6 active connections at once (WTF Google???), so I switched to Firefox now. But here, the same problem occurs, even when I distribute the rooms over multiple tabs (didn’t try multiple firefoxes with different profiles yet).
I also want to switch off video receiving, but this should not be the problem, because the connection loss also happens when no one else is in the room, i.e. there is no video or audio stream transmitted.
To put it in a nutshell:
- Why is it so horribly unstable even if I join multiple empty meetings?
- Is there some way to use the API “headless”, i.e. join the meeting without receiving any data streams or rendering anything? (Btw.: Would it help to hide – display: none; – the iframes?)
- Is there a better way to extract participant information for certain rooms?
If I read you correctly, it sounds like you’re joining all these meetings on the same machine. If so, I’m thinking the issue you’re reporting is a client-side limitation. Having multiple tabs open, whether in the same Jitsi meeting or several different meetings, puts a strain on the machine.
But: I don’t see an excessively high CPU load, even when I use multiple tabs.
Also: I think it should be not too demanding for the client to have multiple meetings running when you don’t receive any video streams.
On your client or on the server?
Depends on the specs of the client.
Both are relaxed.
Well, my laptop (Thinkpad T14, AMD Ryzen 7 PRO 4750U) might be throttling at times, but my other workstation (AMD Ryzen 9 3900X 12-Core Processor, 64GiB) should be handling this just fine. Indeed, the CPU load is low (~0.5), Firefox causes only ~50% CPU load. I have to admit, that I currently connect via X2Go, i.e. I can’t use the GPU. But anyway: There is no video stream to decode, so there should be no need for any GPU, right?
Hmm…mm… I’ve loaded 10 tabs with video streaming on my machine without any problems. So, I think that rules this out as being a Jitsi issue. It would seem that it’s something peculiar to your machine/setup.
Good to know. Did you directly open the rooms or did you also use the Jitsi Meet API to open them in an iframe? What browser on what system did you use?
Oh, I opened them directly in the browsers - Chromium, Brave and Firefox
If I filter the JS console output for “ping”, I get the following output when I have 6 iframes in one window:
console-export-2021-2-15_1-19-32.txt (43.8 KB)
Roughly: All 6 iframes start XMPP pings, all 6 fail (timeout) the first one, 4 the second one, 5 the third one. After that, exceptions are thrown and the connection is reset.
This does not happen when I have a single room connected in an iframe.
Same happens if I have multiple tabs with only 1 iframe each.
When I connect to meet.jit.si I see “Initializing e2e ping; pingInterval=-1, analyticsInterval=60000.” (instead of pingInterval=10000 for my server). Where can I find documentation about that setting and should I change it (i.e. disable pings)?
EDIT: This is a setting in
/etc/jitsi/meet/FQDN-config.js. Let’s try this out…
EDIT2: Nevermind. That’s not the XMPP pings, I guess. These seem to be configured to 10s on meet.jit.si as well…
If you do the same example but using meet.jit.si instead of your self-hosted deployment do you experience the same?
Just wanted to weigh in to say when I launch what I call my breakout rooms, I join each in a different iframe. I’ve done 6 breakouts with a main on a number of occasions and I’ve never experienced the problems you’re talking about. You can see the rough philosophy of what I’m doing here
I am wondering how the Jitsi sessions know to share your video camera and sound ?
I only have one video camera, microphone and sound output.
Would not this cause an issue for any other Jitsi sessions?
So I decided to this this for myself, only I don’t have meeting rooms that have other people in them.
On my (ageing) desktop, one Jitsi session (i.e. room) consumes 60% CPU, so starting other room soon drove my CPU to 100%.
I managed to open 9 rooms and was surprised to find video was working in each of them.
However by now YouTube as struggling to play a video. (I decided to use YouTube to judge the effect of the processor stress)
I noticed that the first room had timed out. Other rooms had stopped connecting to my video camera, but would connect again if I joined them.
Probably not possible for you, but I would prefer to see a solution using a Keyboard Video Mouse switch (KVM) and a separate computer for each instance.
Maybe I am missing something about this issue? Please let me know if I am widely off track.
If you use System Monitor/Task manager, what is the CPU and GPU load on your Desktop when you have all your Jitsi sessions connected?
I don’t see the ping timeouts and the connections seem to be stable with meet.jit.si (even though I get a high CPU load and the browser behaves strangely). So there must be something with my server configuration that makes XMPP pings time out. However, it can not be a firewall issue, I guess, because everything works when I join a single meeting. Do you have an idea which settings to check? What component is actually responsible for the XMPP traffic? Prosody?
Very nice project, thanks! Great idea to use Jitsi to transfer messages.
I’ll have a look at it.
In my case, I don’t want the Jitsi sessions to get any signal, so I just block the access to microphone and webcam (and I use
I think using the webcam in multiple tabs of the same browser is usually no problem.
System utilization is usually not high, i.e. CPU load < 2 with > 10 CPU cores.
Finding out the root of my problem might still be interesting, but I wanted to summarize the workaround I’ve now implemented to achieve my goal:
Instead of joining the rooms with a special user, I redirect the users of my website to a special website (instead of the direct Jitsi links) where the room is opened in an iframe spanning the whole document. In the background I poll the recipient infos and send them to the server. I.e. I utilize my users in order to extract the participant infos. This works well as long as there is in every room at least one participant that doesn’t join by app.
I think I’ve found the problem: After enabling
http2 in my nginx config 16 connections/iframes in a single tab seem to work fine.