Breakout bad


Trying it out on my test server with 6624 (unstable of course).
Problem: it does not work. I tried and it seems the problem is similar.
What happens is that the users dropping in a ‘breakout room’ can see each other, chat happily, but no video between each other (did not try sound).

It’s linked to JVB (with p2p it’s working fine).
I tried to look at Jvb stats and for some reason the Jvb always refuse to initialize bandwidth estimation (TCC = 2500000, esimated = -1, trustBwe = false).
On the client’s screen the upload speed reported is around 20kb (curiously the Jvb says it is receiving amounts of data that seem normal).

Finally I disabled video and enabled it back: success, the video appeared on the other screen’s endpoint.

Thanks for the report! We have temporarily disabled it while we look into this and other weird problems we found.

that’s what ‘unstable’ is for isn’t it ? I rather like the way it’s implemented, I was fearing something complicated and it’s simple and efficient indeed - with room for improvement of course. Keep up the good work and if I can help in the testing I’ll do.

1 Like

Thanks for the kind words!

now for less kind words, more badness :slight_smile:

I have seen the black screen again, on my own instance this time. However it’s nowhere as bad as the first problem. Scenario: my private test instance is public, no auth, setup for VP8, P2p disabled. I have 3 real workstations to use to test, all running Chrome (snap, that is more or less, the stable version) on Ubuntu LTS (18 or 20).
The 3 ws connect, the first user connected creates a breakout room. Everyone go to the breakout room (it’s a stupid scenario yes), everything is displayed normally (great). The first user (‘mod’) goes back to the main room. Sees a black screen, switching the tile mode make the video appear again.

  • if going back to the breakout room, the 2 other users are shown as black rectangles in the tile mode.
  • if (instead) the 2 users in the breakout room go back to the main room, everything is displayed normally.

Now for more fun, mod rights. This is configured as a public instance, so jicofo auto-owner is set to true.
If all 3 users are going in the breakout room in this order:
when everyone is going back to the main room, both Mod and User2 are moderators. User2 has been promoted to moderator because well, alone in the main room ==> become moderator.

Now, the obvious solution is to disallow auto-owner in jicofo. Well, that’s a solution for breakout rooms, but it’s a rather drastic solution since it’s not possible to create breakout rooms.

Thanks for continuing the testing!

I just fixed some nasty issue when switching rooms, which would explain the black screen problem.

As for the auto-owner, that is by design at the moment. We might change that in the future, but for now we are keeping it like so. The problem it tries to solve is the moderator dropping and as a result nobody ever becoming a moderator.

I just did a quick test with 6678, seems same problem persists.

It would be a good idea IMO to define the use case to avoid incorrect expectations, although it don’t seem to be an established tradition for this project.

From what I see, the feature is a good fit for meetings that are properly conferences; that is, a general subject, not adversarial, and a need to discuss sub-subjects independently. An exemple could be a conference about let’s say mycology, with several specialists discussing with the interested public; and in a second phase, a room with the saprophytes specialist, another room with the lichens expert, etc…

From what you say, the ‘public room’ is not generally a good fit for enabling breakout rooms. My impression is that not a lot of people managing this kind of servers are posting on this forum, but there is still quite a few of servers born from the Covid crisis that are still around, and the managers could just as well avoid to enable breakout rooms.

Another very bad fit is the ‘counsellors’ scenario. That is, a mod create a rooms, welcomes several specialists who will counsel people, and then will go to their respective rooms, waiting for the interested people to be welcomed by the mod who will say something like: ‘Ah Hello Mr. Smith, you are coming for your very important and confidential information, Dr Jones is waiting for you in room #3’. This setup would be an appaling mistake, since anyone entering the main room can barge into any breakout room.

Even if you have an authenticated setup and no strict confidentiality requirement, setups where some audit and recording are necessary would not be a great fit at the moment. Since breakout rooms are separate Prosody rooms in a different domain, the kind of people who want for example a recording of everything said in chat would have a hard time with breakout rooms as they are. How to connect chat data in room alphaBravo in the main domain with chat data in room ae98dace-1525-40fc-a4e7-c84a81875728 in the breakout domain ? If people are getting out of a breakout room, the Prosody room is destroyed. If they are coming back, it’s another room that will be recreated with a different UUID. This is not impossible to do, but the difficulty of managing this problem is going up by an order of magnitude.

It hasn’t landed yet :slight_smile:

We don’t know yet, until we ship the feature. The plan here is to release it, gather feedback and adjust as necessary.

Breakout rooms can be protected by a password too, just like you would a very confidential meeting. Also, the moderator may choose to enable the lobby in the main room, so nobody else can come in.

We have currently disabled recordings in breakout rooms until we see how we’d like to handle it.

Once again thanks for the feedback! Please note that, as I mentioned, it hasn’t shipped yet, and we will learn more about the use cases we’d like to cover as people start to use it, and it’s very likely we won’t want cover them all, and that’s also fine.

thanks for the explanations and yes the room password is a workaround (even if I’m not sure that it’s a very satisfying one).

I just tried 6686 and I feel a bit disgusted, not because it don’t work (it don’t), but my tests were all done with stable Chrome (Ubuntu snap, that is, currently 96), now I tried also with Firefox 94 (works) and Chrome 98_4739 directly downloaded from (works). Will 6686 work with Chrome_4740 ? Will 6687 work with Chrome_4739 ? Who knows.

Not sure I follow, what problem did you have with Chrome?

Hi @saghul , I am facing a problem in Google Chrome 96. My jitsi meet version is 2.0.6173-1 and video-bridge version is 2.1-538-g062e9f56-1. It was properly working in google chrome, but suddenly my google chrome version upgraded to 96 and the video conference is not working properly. Audio and video are not working. Also if participant left the meeting room it is not working. Please help me on this regards. Please help me how can I fix this Issue.


You’ll need to update to the latest stable release.

Connect 3 work stations to a meeting, mod creates breakout room; all 3 go to the breakout room, then the mod goes back to the main room: there is no video displayed unless switching on tile mode (if it’s switched off video does NOT come back). If the mod comes back to the breakout room, the 2 other appear as black rectangles in the tile mode.
The browser log only display this:

Uncaught (in promise) DOMException: The play() request was interrupted by a new load request. DOMException: The play() request was interrupted  |  Web

As I said this behaviour shows with Chrome 96 and not Chrome 98 nor Firefox 94.

Dear All,
MANY thanks for this great feature (already checked it on !!!
brief question:
I am using own Jitsi Meet deployment based on nightly builds (now : 2.0.6690-1)
(repo: unstable)

however the Breakout rooms option is not appearing so far in the UI.
Do I need to activated it manually?
if yes, how?

Breakout rooms does not work with IFrame API (, Chrome 96, macOS 12.01)

We’ll look into Chrome 96 issues, thanks for the feedback!

You may need to add the breakout_rooms component to your /etc/prosody/conf.d/<your-domain>.cfg.lua configuration. I am also using Debian unstable packages, and this didn’t happen automatically for me. Refer to /usr/share/jitsi-meet-prosody/prosody.cfg.lua-jvb.example and add what’s missing in your local configuration file.


Just tried it on my instance; yet more fun.

Scenario: Mod creates room, userA and userB enter same room. Mod creates a breakout room. Mod enters breakout room. Mod receives a boatload of notifications, the last being ‘UserA and userB have left the conference’ (have they now ?) after getting into the breakout room.
There is of course some video problem but I did not do this test with a recent Chrome, only 96, so no matter.
I then sends a set password command on behalf of Mod. It succeeds. The security option turns green. UserA tries to connect to the breakout room, UserA don’t have the password and cancels. Exits the conference. Should UserA have been booted out the conference because of lack of password for a breakout room ? Don’t seem quite right to me.
UserB then tries to enter breakout room; but I give UserB the secret password and then UserB joins mod in the breakout room. Success.

Well, it’s not actually impossible to use iFrame API, what was your problem exactly ?

more fun with password: setting a password on the main room triggers the prompt when going back from a breakout room ! Canceling if boots out of the conference of course. So no lobby, and setting a password makes it insane to manage the meeting (closing a breakout room will trigger suddenly the pasword prompt for all users in the closing breakout room). How about whitelisting the users going in a breakout room ?
Without that, protecting a conference without auth (as on seems a very real problem.

Edit: oh wait, no lobby means no lobby for the breakout rooms. So cancel that.