Lobby: Occupant exist at lobby muc room after leaving main muc room

Hi,

We face with an problem about lobby room and develop a solution already. However I want to ask if you have already face with it.

  • When moderator left conference, related occupant object deleted from room occupant list at main muc room.

  • However, sometimes we see that, it is not deleted at lobby muc room. There is 2 moderator exist which are new guest user selected as moderator and old moderator. That causes a result as if left user waiting at lobby room for new comers…

I solve that problem by develop this hook…

host_module:hook('muc-occupant-left', function(event)

    local room, occupant = event.room, event.occupant;

    if lobby_muc_service and room and room._data.lobbyroom then
        local lobby_room_obj = lobby_muc_service.get_room_from_jid(room._data.lobbyroom);
        if lobby_room_obj then
            local lobby_occupant =  lobby_room_obj:get_occupant_by_real_jid(occupant.jid);
            if lobby_occupant then
                module:log("info", "user left main room %s. Check and kick %s at lobby room also", lobby_room_obj.jid, lobby_occupant.nick)
                lobby_room_obj:set_role(true, lobby_occupant.nick, "none", "You have been kicked by yourself.");
            end
        end
    end
end);

When user left conference, client sends 2 unavailable presence

<presence to="engesin@conference.meet.example.com/8fbbc23d" type="unavailable" xmlns="jabber:client"/>

and

<presence type="unavailable" xmlns="jabber:client"/>

I can not see any unavailable presence for lobby muc room either.

1 Like

Good catch. I wonder why that causes you any problem? In the moment the participant disconnects it should leave and the lobby room … or it can take up to 60 seconds for it to drop from the lobby room.

Thank you,

think that there 2 two users. one is moderator.

then moderator leaves, there is 1 at main muc and 2 occupant at lobby muc.

when new user comes, it receives 3 presence from lobby muc (one is itself)

This sometimes trigger someone is waiting for permission to the join room.

Actually I just tested it by modifying the lobby module printing when a participant leave the lobby room and it works as expected.

I tested by having 2 moderators in a room and moderator1 enables lobby and after that moderator2 leaves the conference, by closing the tab.

I just tested this case and I see the participant leaving the lobby room once it disconnects.

This is the one joining the lobby and waiting? That participant should not receive any presence for other participants in the lobby. There was a bug some time ago when this was not working but it was fixed. Only moderators should see presences for other participants in the lobby room.

I just tested this case and I see the participant leaving the lobby room once it disconnects.

Yes it sometimes occurs for us not every time…

This is the one joining the lobby and waiting? That participant should not receive any presence for other participants in the lobby. There was a bug some time ago when this was not working but it was fixed. Only moderators should see presences for other participants in the lobby room.

  • We have private rooms for participants. there is only one moderator in the room and this moderator is also room owner.
  • when owner left, moderation transferred to one of the guest. (owner left at muc room but still exist in lobby muc)
  • if real owner comes back (we detect user as owner and set whitelist true to be able to bypass lobby for owner), prosody sends presences for both main muc and lobby muc occupants. Moderator see itself as if it waits at lobby room. if i print lobby muc occupants, i saw owner nick two resource instance. one is old one and other is live one…
  • after joining of room owner, old guest user lost its moderatorship.

after a while, as you said, ghost one left the lobby.

note: we use stable 5390 version.

You may try latest as there were a number of fixes for the last 6 months History for resources/prosody-plugins/mod_muc_lobby_rooms.lua - jitsi/jitsi-meet · GitHub

Thank you i will check that

@damencho can you show me where prosody deletes occupant at lobby muc?

I want to debug it but i can not find where it is managed…

client send presence to lobby muc when it joins but i can not see any unavailable presence to lobby muc when it left.

thank you

This presence disconnects the xmpp connection so the participant leaves all room that he/she is in.

@damencho hi,

I thing i found something meaningful at prosody logs,

when user left following logs are written

<presence type='unavailable' to='engesin@conference.example.com/1a440bae'>
<presence to='focus@auth.example.com/focus2134763495849236' type='unavailable' from='engesin@conference.example.com/1a440bae'>
<presence to='65ce3b6d-f268-4bd0-88f3-24ef46fc3a99@guest.example.com/PntGeFEt' type='unavailable' from='engesin@conference.example.com/1a440bae'>
<presence to='47859fc6-e1d1-4ac5-9608-369543b1e2e4@example.com/MnovcHT9' type='unavailable' from='engesin@conference.example.com/1a440bae'>
<presence type='unavailable'>
<presence type='unavailable' from='47859fc6-e1d1-4ac5-9608-369543b1e2e4@example.com/MnovcHT9'>
<presence to='65ce3b6d-f268-4bd0-88f3-24ef46fc3a99@guest.example.com/PntGeFEt' type='unavailable' from='engesin@lobby.example.com/c0bf0961'>
<presence to='47859fc6-e1d1-4ac5-9608-369543b1e2e4@example.com/MnovcHT9' type='unavailable' from='engesin@lobby.example.com/c0bf0961'>
stanzarouter: Discarding unhandled error iq (cancel, recipient-unavailable) from c2s: <iq id='767fb77d-020e-48c1-ac8f-811d5505b5bb:sendIQ' to='engesin@conference.example.com/0e0b5f50' type='error' from='47859fc6-e1d1-4ac5-9608-369543b1e2e4@example.com/MnovcHT9'>
stanzarouter: Discarding unhandled error presence (cancel, recipient-unavailable) from c2s: <presence to='engesin@conference.example.com/1a440bae' type='error' from='47859fc6-e1d1-4ac5-9608-369543b1e2e4@example.com/MnovcHT9'>
stanzarouter: Discarding unhandled error presence (cancel, recipient-unavailable) from c2s: <presence to='engesin@lobby.example.com/c0bf0961' type='error' from='47859fc6-e1d1-4ac5-9608-369543b1e2e4@example.com/MnovcHT9'>

as you can see <presence type="unavailable" xmlns="jabber:client"/> is in the middle before lobby unavailable messages… that cause a failure at stanzarouter… when this log occurs, I face with ghost lobby occupants because these unavailable messages are discarded…

with my muc-occupant-left hook, which is in the first post, unavailable orders are different with no stanzarouter error

<presence type='unavailable' to='engesin@conference.example.com/bca2a60f'>
<presence to='focus@auth.example.com/focus2134763495849236' type='unavailable' from='engesin@conference.example.com/bca2a60f'>
<presence to='65ce3b6d-f268-4bd0-88f3-24ef46fc3a99@guest.example.com/PntGeFEt' type='unavailable' from='engesin@conference.example.com/bca2a60f'>
<presence to='47859fc6-e1d1-4ac5-9608-369543b1e2e4@example.com/rcq2NUWs' type='unavailable' from='engesin@conference.example.com/bca2a60f'>
<presence to='65ce3b6d-f268-4bd0-88f3-24ef46fc3a99@guest.example.com/PntGeFEt' type='unavailable' from='engesin@lobby.example.com/2030c6ca'>
<presence to='47859fc6-e1d1-4ac5-9608-369543b1e2e4@example.com/rcq2NUWs' type='unavailable' from='engesin@lobby.example.com/2030c6ca'>
<presence type='unavailable'>
<presence type='unavailable' from='47859fc6-e1d1-4ac5-9608-369543b1e2e4@example.com/rcq2NUWs'>