One specific user can't connect to my instance but works fine with meet.jit.si

Install & Config
#1

I am looking for some help to troubleshoot my Jitsi instance.

My installation is based on Ubuntu 20.04 server, running the latest stable docker image (5390-2) and nginx as reverse proxy. People are using it for a while now without any big issues.

However there is one user which reliably can’t connect. Not connect in the sense that I can see he’s there, but neither audio nor video will work. I checked his browser settings and audio/video are enabled, he can see himself on camera.

Tests 1

  • 2 of us in the meeting, problem child is joining and shows as participant but mic and video are off, we can’t hear/see him, and he cant hear/see us.

Test 2

  • Problem child starts meeting, I join, same problem
  • Problem child is able to raise his hand, but that’s the only interaction which seems to get through. Chat isn’t working either.
  • I can sucessfully join as 3rd attendee from my phone

Test 3

  • Start a meeting via meet.jit.si and we are both connected instantaniously

Preliminary conclusion: The problematic client is working in principle, but something is different about it which prevents it from joining meetings on my self hosted instance. Not even if it’s just me and him (2 participants)

Can anyone think of obvious reasons why this is happening? It can’t be networking/firewall at his end as otherwise jit.si shouldn’t work either, can it?
Although most likely, it shouldn’t be networking/firewall at my server either because it works for others?

Anything obvious I should check next?

Additional checks I ran:

Successfully cChecked port 10000 connectivity:

(server)
sudo systemctl stop jitsi-videobridge2
nc -l 10000 -u
(workstation)
echo "123" | nc -u (your public address) 10000

Tried to check the log file but for some reasons there is nothing?

sudo docker exec jitsi_jvb_1 ls -al /var/log/jitsi

total 8
drwxrwx--- 2 jvb  jitsi 4096 Jan 29 21:34 .
drwxr-xr-x 1 root root  4096 Jan 29 21:34 ..
#2

Hi,

probably this user is behind some kind of firewall.

Official jitsi server can fallback using a turn server (udp and TCP) in case this is needed.
this is probably what is missing in your case

#3

That sounds like a good explanation. That user is joining from a company network, there surely is a firewall somewhere.
I’ll look into turn servers and see what needs to be done. Any must read documentation you can think of?

#4

Probably Setting up TURN · Jitsi Meet Handbook

i guess also on this forum you will get plenty of info.
If using debian/ubuntu there is a jitsi-meet-turnserver package iirc.

1 Like
#5

Turns out I have a few turn servers configured already, is there a way I can test if they are actually used?

This is from config.js

stunServers: [
  { urls: 'stun:stun.nextcloud.com:443' },
  { urls: 'stun:stun.stunprotocol.org:3478' },
  { urls: 'stun:meet-jit-si-turnrelay.jitsi.net:443' }
  ]

And this is what I got in .env

JVB_STUN_SERVERS=stun.nextcloud.com:443,stun.stunprotocol.org:3478,meet-jit-si-turnrelay.jitsi.net:443

Not sure which one takes precendence…

#6

These are stun servers not turn servers.

2 Likes
#7

Indeed, sorry for being ignorant here, learning as I go. Been mixing up TURN and STUN. After reading up some more on this I guess TURN servers is a service I wouldn’t want to relay to a 3rd party as all traffic goes through TURN and hence selfhosting Jitsi becomes pointless.
Said this, are there public servers similar to the STUN ones above I could use to at least test that lack of TURN protocol support is indeed my issue?

The other bit I don’t understand yet is why a participant can communicate through a TURN server located somewhere on the internet but not with my Jitsi server which is equally just a public server on the internet? Is this just a matter of Jitsi not supporting the TURN protocol?

#8

The clients communicate using udp port 10000 with the bridge and in some networks udp is not allowed or outgoing port 10000 is blocked. For TCP connection we use the turn server to relay the traffic. I don’t think there are public turn servers as the turn usage is behind a password.
If you install jitsi-meet by default it come with a turnserver listening on port 5349 (that is explained in the quick install guide) , so clients with no udp can fallback to that.
In some corporate networks not only udp is blocked, but only destination port 443 is allowed, in which case the default port 5349 will also not work. Then you need to run the turnserver on port 443. Setting up TURN · Jitsi Meet Handbook
This is the case for meet.jit.si turnservers.

There is one more case for turnservers in p2p mode, sometimes direct connection is not possible due to double NATs and such so a relay can be used to for that call which will offload the traffic from the bridge, which needs to handle the cases of 3 and more people.

2 Likes