Bosh is disconnected, but jicofo is not notified

I am using jitsi. In some cases, I find that the bosh has stopped in the nginx log, but the jicofo log does not receive information. What can I do to solve this exception?

If a user is abruptly disconnected it may take up to 60s to remove. You can use WebSockets, which are faster at detecting these failures.

I want to make sure that if the nginx logs do not have HTTP bind, does that mean that the client has been disconnected and jicofo should also receive messages

Not really. If the client stops the binding messages it may take jicofo up to a minute to expire that participant. It uses a timeout mechanism because the user might have suffered a momentary network impairment and will reconnect.

I saw the error log of HTTP bind 499 code in nginx, but jicofo hasn’t received any message. I think the meeting is in a zombie state. Is there any way to see the duration of the meeting in proxy? Or all the meetings?

I feel like we are discussing a detail without having the full picture. What is the general problem you are trying to solve here? Users might be connected to bad WiFi networks which disconnect etc, so you can’t avoid that.

Yes, we can’t avoid the client-side situation, so I’m wondering how I can see what’s going on in prosody. and duration. I want to see if there are any dead rooms

You can activate admin telnet module and use Console – Prosody IM

Thank you for your reply. I have used this module, but I can’t see all the room information and duration

If you don’t see a room, that room does not exist.

No, I’m still in the meeting. Did you use that command?

actually host:list() lists the configured hosts one of them is your main muc module. For debian installs it is conference.mydomain for docker it is muc.jitsi.meet or something like that.

To see the rooms you can do muc:list('conference.mydomain.com').

Yes, I see a lot of rooms that are not normally closed
In a room with only two people

  • Jicofo logs are displayed as follows
Removed participant: true,  123@conference.domain.com /1f62cde9
Jicofo 2022-06-22 16:05:37.673 INFO: [26258] org. jitsi. jicofo. JitsiMeetConferenceImpl. log() Region info, conference=50555: [[null, null]]
Jicofo 2022-06-22 16:05:37.673 INFO: [26258] org. jitsi. jicofo. JitsiMeetConferenceImpl. log() Expiring channels for:  123@conference.domain.com /1f62cde9 on: Bridge[jid= jvbbrewery@internal.auth.conference.domain.com /121a5fce-e2b8-407a-a658-88ed9b287206a, relayId=null, region=null, stress=0.03]
Jicofo 2022-06-22 16:05:57.673 INFO: [283] org. jitsi. jicofo. JitsiMeetConferenceImpl. log() Timing out single participant:  123@conference.domain.com /b074970e
Jicofo 2022-06-22 16:05:57.673 INFO: [283] org. jitsi. jicofo. JitsiMeetConferenceImpl. log() Terminating Participant[ 123@conference.domain.com /b074970e]@1997758283, reason: expired, send st: true
Jicofo 2022-06-22 16:05:57.673 INFO: [283] org. jitsi. protocol. xmpp. AbstractOperationSetJingle. log() Terminate session:  123@conference.domain.com /b074970e, reason: expired, send terminate: true
Jicofo 2022-06-22 16:05:57.674 INFO: [283] org. jitsi. jicofo. JitsiMeetConferenceImpl. log() Removing  123@conference.domain.com /b074970e sources Sources{ video: [ssrc=1997860739 ssrc=186632463 ssrc=3451604740 ssrc=746052583 ssrc=874773031 ssrc=2545992297 ] audio: [ssrc=854803733 ] }@1550609642
  • One person left at 16:05:37.673 on June 22, 2022. Only one person was detected in the room 20 seconds later.
  • Nginx logs also confirm this. This is the last HTTP bind.
[22/Jun/2022:16:05:37 +0800] "POST /http-bind?room=123 HTTP/1.1" 200 116 " https://youdomain/123 " "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.124 Safari/537.36 Edg/102.0.1245.44"

In room 123, a client disconnected from the server, but jicofo did not listen

All these are normal, what is the problem?
Jicofo stops the media for the last participant in the room, when that participant was alone for 20 seconds.

Why do you think that? As Jicofo logs show that a participant leaves at 16:05:37.673.

Yes, indeed, as the log shows, the last participant was alone for 20 seconds. Within 20 seconds of being alone, the nginx log should also have an HTTP bind message, but no. I also didn’t see the last participant leave in the subsequent logs, so I guess the last participant has left, but jicofo didn’t listen

It can be seen from the code that only when there is only one person in the room, the 20 second scheduled task will be started


            if (participants.size() == 1)
         {
//                for (final ChatRoomMember member : chatRoom.getMembers())
//                {
//                    onMemberLeft(member);
//                }
                disposeConference();
                rescheduleSingleParticipantTimeout();
            }
            else if (participants.size() == 0)
            {
                stop();
            }

So you say that when that participant that was alone in the room left, jicofo did not detect it even after a timeout is reached, up to 60 seconds?
And you can still see the room in prosody admin telnet after the timeout?

What prosody version are you using?

Yes, I waited for several days and didn’t receive the message that the last person left the room. I used prosody 0.10.0

This is a known problem we have seen with prosody 0.10. Update it to latest 0.11 or 0.12.