"unfortunately something went wrong " and reconnecting

Worked for me. Thanks!

This solution didnt work for me

thank you!!
These settings solved my problem.

@VishalKale has your issue resolved?
I an also getting the same issue

Hi @damencho,
I have installed latest jitsi version on my server “” and whenever I am joining the conference after 20-30 seconds I’m getting error “Unfortunately something went wrong. We are trying to fix this. Reconnecting in 17 seconds”

Earlier when I was working with previous versions I never faced this issue but since I have updated the version I’m getting such error.

Please guide for the same.
Since I’m getting such issue, I have tried fresh installation in different servers aswell but still facing the same issue.


Is port 10000 accessible? See Tip: how to check UDP/10000 connectivity for a quick test

Do you see errors in the jifoco log? Or the JVB log?

Since you are seeing this on different servers and with fresh installs it’s likely not related to the code but the configuration of either the servers or your client.

Hi @corby
Thanks for your reply

I am attaching jicofo an jvb log files:
jvb.log (2.2 MB) jicofo.log (277.0 KB)

in jvb log file there is one line

2020-08-05 06:31:12.354 INFO: [7275] [confId=9aa921d00bf19cc8 gid=162057 stats_id=Wilfredo-2Cn conf_name=qwerty ufrag=ce68h1eeul21t0 epId=6c8f521c local_ufrag=ce68h1eeul21t0] ConnectivityCheckClient$PaceMaker.run#922: Pair failed: -> (stream-6c8f521c.RTP)

is this some what error? As in previous lines pair is added and after that pair failed issue is present

By itself having ‘pair failed’ in the log is not an error, when it is followed by a message about ‘pair succeeded’. If it’s not, there is probably a problem; as 10.1.0.x is a private IP address, look for

org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=...your private IP address ...
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=... your public IP address ...

in the /etc/jitsi/videobridge/sip-communicator.properties file. When there is a pair succeeded message, it will be with your public IP address.

@gpatel-fr that means “Pair failed” is not an error as earlier there was “pair succeeded” message present.

So as per you i need to check my private and public ip address in /etc/jitsi/videobridge/sip-communicator.properties file right?

So below is my .properties file:


That’s not exactly what I said. If things work, you can have any number of pair failed messages, followed by a pair succeeded and a pair validated message. If after a pair failed message you have other error messages instead, it’s not good and in this case you may have better success in including the lines in your sip-communicator.properties.

@gpatel-fr I have added the public and private ip address in .properties file but found nothing in log files by which I can come to conclusion that why I am facing “something went wrong” issue

is the parameter taken in account ? that is, is running
sudo grep LOCAL_ADDRESS /var/log/jitsi/jvb.log
returning something along the lines of:

2020-08-04 09:11:40.686 INFO: [1] AbstractReadOnlyConfigurationService.logConfigurationProperties#85: org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS =...the private address ...

and similar for PUBLIC_ADDRESS

and is the log with pair failed exactly the same or are there changes ?

I tried executing the command :
grep LOCAL_ADDRESS /var/log/jitsi/jvb.log
grep PUBLIC_ADDRESS /var/log/jitsi/jvb.log

but didn’t get any response.

NOTE: in the place the LOCAL_ADDRESS I have used my private ip address

Can you show us the output of sudo netstat -anlp | grep 10000

below is the output:

udp6 0 0 :::* 7930/java

That seems like a problem to me. The 10.0.. network is a private address. UDP port 10000 is not listening on any public IP address (if that’s all you see from netstat)

At my end UDP port 10000 is open as you can see the status below:
sudo ufw status verbose

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To Action From

80/tcp ALLOW IN Anywhere
443/tcp ALLOW IN Anywhere
4443/tcp ALLOW IN Anywhere
10000/udp ALLOW IN Anywhere
22/tcp ALLOW IN Anywhere
80/tcp (v6) ALLOW IN Anywhere (v6)
443/tcp (v6) ALLOW IN Anywhere (v6)
4443/tcp (v6) ALLOW IN Anywhere (v6)
10000/udp (v6) ALLOW IN Anywhere (v6)
22/tcp (v6) ALLOW IN Anywhere (v6)

I see. When some people run nc -l 10000 (as sometimes suggested) they are actually listening on port 10000 (on all addresses). This could lead to a false positive. It does verify the firewall, but not the jvb. I believe using ngrep is a better solution

Just because it’s open (which is good, you need that) it doesn’t mean is working.

Your JVB is not actually listening on port 10000 in a reachable way.

Unless there is some other routing/forwarding/masquerading going on in iptables that I am not aware of on your system (and there may be) I don’t believe this will work.

You need to have your JVB bind to UDP 10000 on an IP address that is reachable – either directly by the meeting participants or indirectly through a relay /TURN. Others can correct me where I am wrong.

no :slight_smile: it was really LOCAL_ADDRESS

Thanks you so much for your quick response and guidance.
It really helped me to look deep into this issue.

I was verifying the enabled ports from ubuntu and now I enabled 10000 port for network firewall from cloud console and now its working :slight_smile: