Intermittent "crash" with `Focus idle timeout` error

We have an installation of Jitsi running on Debian Buster machines that looks like this:

  • 1 Jitsi-Meet server (prosody, jicofo, nginx) running version 1.0.4466
  • 4 Videobridge2 servers running version 2.1-376-g9f12bfe2-1
  • Json web token authentication using “jitsi-meet-tokens” and a custom prosody plugin we developed. This plugin registers a hook on muc-room-created which changes room.handle_admin_query_set_command so that not all participants are automatically made owners, then it registers a hook on muc-occupant-joined which sets the participants affiliation based on the json web token.

The problem that we’re seeing is:

  • 2 or more users attempt to join a new conference (valid tokens, everything should be good)
  • Everything seems like it will work, the users are dropped into the conference. They can see video from their own cameras and, when peer2peer is enabled, they can even see video of each other. When peer2peer is disabled I don’t believe they see each other before the “crash”.
  • 0 - 20 seconds go by, and suddenly there is a “crash”. The users see the dreaded grey screen that says something went wrong and their browsers begin to countdown and attempt to rejoin the conference.
  • Sometimes they rejoin and then the conference actually succeeds, sometimes this “crash” happens repeatedly.

The most promising thing we’ve found comes from jicofo.log. We see that when the conferences fail we get a Focus idle timeout for XXX_conference_XXX. Unfortunately we’re not sure the best way to dig into that message further.

The crash doesn’t seem to be related to load, it sometimes happens when there are only a couple of active conferences. It doesn’t seem to be a simple timeout between the jitsi-meet and videobridge servers, we’ve started measuring latency between them and don’t see any abnormal spikes. It doesn’t seem to be related to the content of the token, it happens with a variety of tokens and only rarely fails.

Has anyone seen this before? Or do you have any advice? Is there anyone who can explain the different possible causes of the Focus idle timeout error?

Many thanks for reading and for any help!!!

org.jitsi.jicofo.DISABLE_AUTO_OWNER=true

does the same thing. Put this in /etc/jitsi/jicofo/sip-communicator.properties

There may be a miss configured JVB. Test JVBs one by one

Thanks for the response!

org.jitsi.jicofo.DISABLE_AUTO_OWNER=true
does the same thing. Put this in /etc/jitsi/jicofo/sip-communicator.properties

Thanks, I’ll try that out!

There may be a miss configured JVB. Test JVBs one by one

Unfortunately, if it is a misconfiguration, it’s not a simple one. All of the videobridges are able to host conferences without problems, and most of the conferences work without incident. Only sometimes do they fail.

Our videobridge config is (I think) pretty normal. Each videobridge has a unique nickname, but they all connect to prosody with the same username and password. Here’s an example of the videobridge sip-communicator.properties:

org.ice4j.ice.harvest.DISABLE_AWS_HARVESTER=true
org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=meet-jit-si-turnrelay.jitsi.net:443
org.jitsi.videobridge.ENABLE_STATISTICS=true
org.jitsi.videobridge.STATISTICS_TRANSPORT=muc,colibri
org.jitsi.videobridge.xmpp.user.shard.HOSTNAME=_DOMAIN_
org.jitsi.videobridge.xmpp.user.shard.DOMAIN=auth._DOMAIN_
org.jitsi.videobridge.xmpp.user.shard.USERNAME=jvb
org.jitsi.videobridge.xmpp.user.shard.PASSWORD=_PASSWORD_
org.jitsi.videobridge.xmpp.user.shard.MUC_JIDS=JvbBrewery@internal.auth.meet._DOMAIN_
org.jitsi.videobridge.xmpp.user.shard.MUC_NICKNAME=_UUID_GENERATED_DURING_PACKAGE_INSTALL_