Configuration - Close the room once the moderator ends the video conference or a few minutes after he hangs up

Hi guys,

We have a Jitsi server mounted on an Ubuntu 18.04 server:

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.4 LTS
Release: 18.04
Codename: bionic

ii jicofo 1.0-786-1 all JItsi Meet COnference FOcus
ii jitsi-meet 2.0.6173-1 all WebRTC JavaScript video conferences
ii jitsi-meet-prosody 1.0.5211-1 all Prosody configuration for Jitsi Meet
ii jitsi-meet-tokens 1.0.5211-1 all Prosody token authentication plugin for Jitsi Meet
ii jitsi-meet-turnserver 1.0.5211-1 all Configures coturn to be used with Jitsi Meet
ii jitsi-meet-web 1.0.5211-1 all WebRTC JavaScript video conferences
ii jitsi-meet-web-config 1.0.5211-1 all Configuration for web serving of Jitsi Meet
ii jitsi-videobridge2 2.1-538-g062e9f56-1 all WebRTC compatible Selective Forwarding Unit (SFU)

Is there a mechanism, configuration … to close the room once the moderator ends the video conference or a few minutes after he hangs up?

We have been looking for it in the settings without finding anything.

Welcome to the forum.

This doesn’t currently exist out of the box (so no available config parameter), but there are a few posts that point to ways of doing this (though with caveats). Do a search through the forum and check them out.

Does this meet your needs?

Thanks shawn !!
Really no. I only want that the room close when moderator ends. No more.

But thanks !!

If you remove the muc-occupant-pre-join callback and just keep the muc-occupant-left one, that might do it? I haven’t tried it, but I suspect it would bring you close to where you might want to be.

Something like this (Note: untested code!):

My finger-in-the-air guess at an install step:

  1. Download that file to /usr/share/jitsi-meet/prosody-plugins/mod_close_on_mod_leave.lua
  2. Enable that module in /etc/prosody/conf.d/
    Component "" "muc"
    modules_enabled = {
    room_close_when_no_mod_timeout = 120  -- set your timeout (seconds)
  3. Restart prosody


If you haven’t already, you will also need to disable auto_owner feature in Jicofo else jicofo will nominate a now moderator when last mod leaves and room will never be closed.

  1. assuming you’re on newer Jitsi that uses jicofo.conf
    hocon -f /etc/jitsi/jicofo/jicofo.conf set jicofo.conference.enable-auto-owner false
  2. restart jicofo

The last check” prevents to close the room because jicofo will have already chosen another participant as moderator

Thanks to all !!
I will test and I tell you about this.

Good point sir. Will update answer to explicitly mention removing jicofo auto-owner. I’m assuming that is sufficient.

Then nobody can be moderator if this is not a secure system. But for this case, it seems that the token authentication is active since jitsi-meet-tokens is installed

Yeah, I’m assuming @smedios already has in place some form of auth to determine who gets to be moderator. Would be rather arbitrary to want to force close a room with no moderator if we just leave it up to jicofo to assign moderatorship.

I have testes the solution commented by @Shawn but it did not work. After the moderator has opened the room, when a guest tries to enter, both sessions are disconnected and no error appears in prosody.log

I use auth token verification.

Hello again.
I forgot to check the jicofo.conf configuration. With “enable-auto-owner: false” and restart jicofo, now it lets the guest enter the room but when the moderator leaves the room, the guest stays inside the room. I have waited up to 2 min.

do you see any logs from the module in prosody logs?

If module is installed correctly, I’d expect to see log entries for this and this (p.s. I’ve just updated the gist to move that log line to correct position). Or error, considering the code was pulled together hastily as a potential starting point and never tested.

No I do not have any “moderator left” in the prosody.log.

I’ve updated the gist. Try again?


  1. Changed default log level to info or else you won’t see the logs without enabling debug logs in prosody
  2. Use room:destroy instead of kicking participants, since destroy is now nicely handled by recent Jitsi Meet and users see a notification that room is closed.

p.s. I did a quick test and it was working but logs not visible unless debug mode enable, and users were being clicked but it was not obvious from the UI that that has happened. Hence the changes mentioned above.

@shawn Hello again.
I have tried the last change but it does not work as I would like. When the moderator leaves the room, the message appears in the prosody.log:

Moderatorless room timed out. Destroying room

but the client is still connected and the window remains open and the timer continues at the top of the screen, although with a message “call terminated”.
Until the client clicks hang up, the message does not appear in the log: “BOSH client disconnected: session close” and the connection is actually closed.
Destroying the room does not close the client connection.
I I would prefer that instead of destroying the room, close the connection of the rest of the users (if possible)

Sounds like the prosody module itself is working and is closing the room. Client is still connected to prosody, but no longer an occupant of the room.

It is now down to how the UI handles the room close event; the behaviour you are describing sounds consistent with what happens when someone gets kicked from room or room terminated by reservations plugin. If you want to change that behaviour, it’s a different kettle of fish and a whole new conversation I think.

And is it not possible to modify the function that destroy the room so that instead of a “room:destroy” it could be something like a" session.close "?

No idea. But I suspect forcefully closing the client sessions might not give you any better an experience for clients on the UI. A better bet might be to explore how you can listen to room close events on UI and customise your desired behaviour there.