Waiting after the knock blocks the room

Developers
1

Hi,
in my version of Jitsi (stable 8218) I have this anomaly.

When I start a room with the lobby on by default, and someone knocks on me but I close the room without accepting or rejecting it, it happens that the participant waits for the moderator’s response.

If I then try to access my room again as moderator I can’t start it as long as the participant is waiting (if he closes his waiting page everything goes back to working).

I did the same test on meet.jit.si but this doesn’t happen in the same way because I noticed that the participant receives popups informing that the room has been closed. (in the participant’s console I see a destroy room event that I don’t see in my installation…)

So the substantial difference between my installation and yours is that in your solution, the participant receives feedback that the room has been closed by the moderator, therefore the wait ends and does not remain active as it appears in my system.

What do you think it is due to?

2

That’s a problem with the module doing the lobby on by default.
Whenever the main room is destroyed, the lobby is also destroyed:

3

How are you starting lobby by default?

I’ve just tested using token_lobby_ondemand + persistent_lobby on stable 8319 and cannot repro that issue.

With someone waiting in lobby, I joined as moderator then left without admitting on rejecting. Then joined again as moderator and again I see the notification to reject or admit the guest.

4

Hi,
I use persistent_lobby + reservation (where my web server sends prosody a payload with lobby set to true and room password). It will be the client’s responsibility to enter the room password to bypass the lobby.

5

I confirm that if I disable persistent_lobby and reservation, everything works fine.

I’ll explain:

I start the room, manually enable the lobby, receive the knock but close the room → the waiting participant receives notification that the room has been closed.

6

Hmm… should work since reservations module uses persistent-lobby too.

Well, this won’t happen since persistent-lobby will keep both the lobby and main room active as long as the there is someone in either the lobby or the main room. The only way to force close the lobby from the main room is for moderator to do “End meeting for all”.

What you’ve described is as designed apart from “If I then try to access my room again as moderator I can’t start it as long as the participant is waiting”. I cannot repro that behaviour so no idea what might be causing that :frowning:

7

Thank you very much Shawn!

So you suggest to take advantage of the “End meeting for all”… ? but where can i do it? in the point underlined by damencho?

I predicted 60 seconds of time in which the meeting remains standing if the moderator leaves …

Would this fail?

8

Maybe because I modified the conference.js
in the JitsiConferenceErrors.AUTHENTICATION_REQUIRED case I added some useful logic in my company to call the AuthHandler.requireAuth(room, password);
in some cases …

9

Not really. I was just pointing out that when persistent-lobby is enabled, if someone is still in the lobby then the main room and lobby remains open even after the main room is empty. So the guest in lobby not seeing the “room is terminated” notification when moderator leaves the room is expected and not the cause of moderator not being able to rejoin.

The only situation I’ve seen where guest waiting in lobby sees the “room is terminated” notification is when the main room is explicitly closed e.g. in the case of “end meeting for all” or in the case of reservations module when the room exceeds duration and is forcefully terminated.

It is possible that the problem you are seeing is due to the customisations you made in conference.js. Have you tried disabling that and see if the issue is still there?

10

If this really is the behaviour you want, or if you are unable to resolve the underlying issue you’re facing and terminating the room helps you workaround the problem, it might be possible by changing the behavior of muc-occupant-left.

You still need persistent-lobby when auto-creating lobby because if guest joins first and nobody joins main room then it eventually gets terminated and so does the lobby room. But you can modify the behaviour so room is terminated after last person leaves.

You can achieve this by modifying this block in mod_persistent_lobby.lua to something like:

if not main_room:has_occupant() then
  -- once someone leaves, if room now empty then destroy room.
  -- This will also trigger a deletion of the lobby room
  trigger_room_destroy(main_room);
end

Or, to make updates easier, you can opt not to modify mod_persistent_lobby.lua and add another custom module to you muc component to handle the termination. It could look something like this:

-- Disclaimer: untested code.

local is_admin = require "core.usermanager".is_admin
local is_healthcheck_room = module:require "util".is_healthcheck_room


module:hook("muc-occupant-left", function (event)
    local room, occupant = event.room, event.occupant

    if is_healthcheck_room(room.jid) or is_admin(occupant.jid, module.host) then
        return
    end

   if not room:has_occupant() then
      room:set_persistent(false);  -- because mod_persistent_lobby set room to non-persistent
      room:destroy(nil, 'everyone has left the room');
   end
end)

The different between this approach compare to not having mod_persistent_lobby at all is:

  1. It can keep lobby alive if nobody has joined main room
  2. There is no grace period between when last person leaves and room is terminated.

P.S. Even if this approach successfully works around you current problem, I would suggest to try to first understand the root cause behind your issue since it may cause other problems down the road.

1 Like
11

Thanks so much for the support! I will try to follow your suggestions and will keep you updated.
Thank you