Missing relay candiates, hence LTE connection doesn't work

I have successfully installed Jitsi on a Jetson Nano. I can have video conferences as long as partners are in the same network (since I also have seen srvflx candidates I suppose it would work also between different networks).

What not is working is, if one of the partners is behind a symmetric NAT (LTE bound for instance) This time TURN would have to jump in and I can’t see any single relay candidate flow.

So I suppose I have forgotten one setting somewhere while following this guide Self-Hosting Guide - Debian/Ubuntu server · Jitsi Meet Handbook

My installation is listening on port 8443 (not 443) for internal reasons, but this seems to be not the problem.

My firewall:

ubuntu@jitsi-meet:~$ sudo ufw status
Status: active

To                         Action      From
--                         ------      ----
8443/tcp                   ALLOW       Anywhere                  
10000/udp                  ALLOW       Anywhere                  
22/tcp                     ALLOW       Anywhere                  
3478/udp                   ALLOW       Anywhere                  
5349/tcp                   ALLOW       Anywhere                  
443/tcp                    DENY        Anywhere                  
8443/tcp (v6)              ALLOW       Anywhere (v6)             
10000/udp (v6)             ALLOW       Anywhere (v6)             
22/tcp (v6)                ALLOW       Anywhere (v6)             
3478/udp (v6)              ALLOW       Anywhere (v6)             
5349/tcp (v6)              ALLOW       Anywhere (v6)             
443/tcp (v6)               DENY        Anywhere (v6)

My DSL router is forwarding traffic on these ports to the ports inside the DMZ to the Jetson:

What else can I examine? As said: No “relay” candidates. And in the browser console I see:

Call ended: connectivity-error - ICE FAILED P2P ?true

when the party, connected via LTE dials in.

  • UDP/10000 is for JVB, not for TURN

  • Can the partner connect to TCP/5349 or TCP/8443 if she is behind a restricted firewall?

  • Probably TURN tries to connect to JVB using the public IP but it seems that there is no firewall rule to redirect internal traffic when the destination is the public IP

Thanks Emrah,

I was already wondering, how you are making TURN with just one port open. Shouldn’t there be more ports open for that? I thought STUN and TURN servers are installed automatically with my Jitsi installation on the Nano.

Can the partner connect to TCP/5349 or TCP/8443 if she is behind a restricted firewall?

I guess so yes.I forgot to say, it works if I’m using your web installation of Jitsi. The same setup: A in a Wifi behind DSL router, B on an iPhone with LTE.

Probably TURN tries to connect to JVB using the public IP but it seems that there is no firewall rule to redirect internal traffic when the destination is the public IP

Not sure if I understand that. The Nano instance’s firewall rules are visible. The Nano is standing in a DMZ, directly connected to the Router, but the STUN UDP and TCP ports as well as 8443 and 10000 are forwarded. Only a subset of the open ports are port forwarded from outside to inside. So 22 is not forwarded (and not needed). I would miss a lot of TURN ports at least, but nobody mentioned that (“open UDP range bla bla”). Can the TURN activity log be seen somewhere on the box?

PS: What is JVB? Jitsi Video Bridge?

Corrected the naming:

I could make 22 more secure with public key authentication and expose the entire host to the Internet in order to see if it works then. Would you want me to do that for a little test?

Can the partner participate the meeting when P2P is disabled or when there are already 2+ participants in the room?

I want to understand the partner can access to UDP/10000

Uhm… I literally have no idea. I opened the website on one device and forwarded the link to the other. So basically there are just two and I don’t have disabled anything, at least not willingly :slight_smile:

Tomorrow I will open the entire box. Let’s see then. I’m still suspecting, that there will be some other openings necessary in order to make TURN work, but I didn’t find the proper doc yet.

@emrah OK, having tested now with opening my firewall completely. This is called “Exposed Mode” on my router and opens up the firewall for any IPv4 traffic. The result is the same: Video connectivity over Wifi, but not, if one side is running over LTE.

So it is not a firewall issue, at the first glance.

I still can’t see any TURN candidate, I suppose TURN is not working. How to investigate that?

Oh, well… Yes, this makes sense :slight_smile: There is no TURN configured in my case…

If I examine the connection using jitsi-meet.ddns.net:8443 in chrome://webrtc-internals I see this:

{ iceServers: [stun:meet-jit-si-turnrelay.jitsi.net:443], iceTransportPolicy: all, bundlePolicy: max-bundle, rtcpMuxPolicy: require, iceCandidatePoolSize: 0, sdpSemantics: \"unified-plan\", extmapAllowMixed: true }"Legacy (chrome) constraints: "{advanced: [{googScreencastMinBitrate: {exact: 100}}, {googCpuOveruseDetection: {exact: true}}]}

If I run the same configuration using jitsi-meet I get this:

{ iceServers: [turns:meet-jit-si-turnrelay.jitsi.net:443?transport=tcp, stun:meet-jit-si-turnrelay.jitsi.net:443, turn:meet-jit-si-turnrelay.jitsi.net:443], iceTransportPolicy: all, bundlePolicy: max-bundle, rtcpMuxPolicy: require, iceCandidatePoolSize: 0, sdpSemantics: "unified-plan", extmapAllowMixed: true }, {advanced: [{googScreencastMinBitrate: {exact: 100}}, {googCpuOveruseDetection: {exact: true}}]}


So basically I don’t have a TURN configuration with my setup. The big question is: Why? :slight_smile:

Opening a new topic on “how to configure static TURN server correctly”.

EDIT: See also How to configure static TURN server correctly?

That being said the quoted thread above contains the solution of the problem. Once the static TURN configuration is correct, it works als with a symmetric NAT device.

Solved