Problem with waiting room and moderators

Hi all,

I’m facing a particular scenario / situation and I would like to know if this is the intended behaviour of Jitsi and if something can be done about this. I’m using currently version 5390 of Jitsi Meet installed on a Ubuntu machine using the quick installation. This installation is JWT Token enabled and only people with token can create rooms.

  1. A moderator creates a room and enables for it the waiting room (the one where you request to be admitted)

  2. Guests start to join, for some reasons, the owner’s browser crashes, so he has to refresh the page. Whether he joins back with or withouth JWT, he has to go through the waiting/admittance room. Since the conference room is still running because guests are presents but no one can allow the previous owner/moderator to join again, he is stuck and cannot enter back.

How could we handle this situation? Isn’t there a way to configure Jitsi to “recognize” that the user is trying to join again after a crash was the previous owner who created the room? Should, in this case, just force the deletion of the room? And how?

Moreover, I would like to ask you which property allows the waiting/admittance room enabled by default.

Thanks everyone

This should not happen, was that the case after a minute or so? If there are no moderators in the room with lobby, that room is destroyed and so is the lobby. When browser crashes or on some network problems bosh and websocket can take up to minute to detect that a participant had gone to close its session server-sice, so during that time that participant is still considered to be in the room.

There is no such feature. You can implement your own logic with a custom prosody module …

1 Like

Sorry @damencho I did not express myself clearly.
The fact that the moderators crashes is not linked to the guests joining. I will re-express the example case that happened:

  1. A moderator (user with JWT token) creates a room and enables for it the waiting room (the one where the othersjoining the call can request to be admitted)

  2. Guests start to join and the call goes on normally

  3. IF for some reasons, the owner’s browser crashes during the call, he has to refresh the page or reload the browser. By doing so, whether he joins back with or withouth JWT, he has to go through the waiting/admittance room that he did setup before. Since the conference room is still running because guests are presents but no one can allow the previous owner/moderator to join again, he is stuck and cannot enter back.

Hope I expressed myself clearly now

What you’ve described is the way the lobby feature currently works. To mitigate the risk of the meeting host being locked out, apart from writing a custom prosody module as advised, you can also consider setting a password once the host enters the room. That way, if for some reason they get disconnected, they can use the password to re-enter the room. This password does not need to be passed to anyone else as they won’t need it for access.

1 Like

Thanks very much, that solved the issue and my PM is quite happy not to being locked out anymore when his browser crashes. Thanks!