Jitsi Meet on Debian10: timeout for pair

Hello All,

I have a Jitsi Meet - now version 2.0.4 - on Debian 10.
At first everyone was happy with it, now a frequently get complaints about people dropping out of meetings and bad audio and video quality.

I suspect this could be because at first everybody was at home but lately people come back to the office where there are behind a nat firewall.

The EM I’m seeing in /var/log/jitsi/jvb.log:

2020-06-09 10:25:45.075 INFO: [37172] [confId=424b6b03c2e5be27 gid=ffc7f0 conf_name=] Conference.dominantSpeakerChanged#446: ds_change ds_id=3f7b2f4b
2020-06-09 10:25:45.415 INFO: [37293] [confId=424b6b03c2e5be27 gid=ffc7f0 stats_id=Pattie-5Y2 conf_name=
**** ufrag=2ajg61eabvp6e5 epId=9417d95e local_ufrag=2ajg61eabvp6e5] ConnectivityCheckClient.processTimeout#857: timeout for pair: [2a01:4f9:c010:1e30:0:0:0:1]:10000/udp/host -> [2a02:1810:c3f:7200:d592:9d49:c644:9c76]:35000/udp/host (stream-9417d95e.RTP), failing.

So what I’m seeing is the domintspeakerchanged message and the timeout for pair message.

The firewall on the Jitsi server ( Shorewall ) is set to open ports udp 10000 to 30000.

Can anyone help on this issue?

Greetings, J

It seems that you need to add the followings to /etc/jitsi/videobridge/sip-communicator.properties



thanks for helping me out.
I’ ve added this and restarted;

the Conference.dominantSpeakerChanged#446: is still there, but the other EM is gone.
I will collect feedback from the users.

Many thanks.
Greetings, J.

1 Like

Same here. We were using Jitsi Meet for weeks without trouble and suddenly people are dropping out of conferences.

We are already using the TCP harvester (we have dedicated IPs for the harvester so that we can run it on port 443):


I think this might be related to an update of the videobridge, I’ll try to downgrade and see if that helps.

Hey all,

I’m getting this error too. I’m on latest stable, and I have set the appropriate NAT_HARVESTER params (i’m using @emrah’s templates from https://github.com/emrahcom/emrah-buster-templates)

This doesn’t happen all the time, but during peak load times, I get errors like

2020-10-15 15:45:22.583 INFO: [4531] [confId=69734732b279ebf3 gid=24706 stats_id=Miller-rib conf_name=0lkgcb@conference.jitsi.xxx.com ufrag=96jqr1ekmelhn6 epId=bae21355 local_ufrag=96jqr1ekmelhn6] ConnectivityCheckClient.processTimeout#860: timeout for pair: 142.93.63.xx:10000/udp/srflx -> 97.83.233.xxx:60717/udp/prflx (stream-bae21355.RTP), failing.

This seems correlated to customer errors: the video chat fails and people get a “you have been disconnected” message.

My digital ocean box’s load average / utilization is pretty low - i have a script to boot up new jvbs at peak times. So this seems to be something related to load, but NOT related to high CPU/ mem utilization.

Do I need create another JMS to handle this amount of load? Is there a max capacity of a single JMS + ~6-10 jvb nodes? I don’t see any log lines indicating

CC @emrah @damencho are you familiar with this issue?

I’m also facing this issue under high load. I’m running currently a configuration of 8 jitsi meet, each having 13-15 video-bridges. What’s more, sometimes it happens, that one of bridges is kind of lost from jitsi meet side: it gets no conferences assigned and log of JVB has just these lines, popping up every 10 seconds and nothing more - just like if connection to meet is present, but there are no conferences at all

 HealthChecker.run#170: Performed a successful health check in PT0S. Sticky failure: false

Restarting jvb service fixes the problem.