Ubuntu default TURN server installation

Hi everyone,

I hope this is not a duplicate as there seem to be lots of TURN discussions. Yesterday I installed Jitsi meet from the repo on Ubuntu 18.04. Almost everything worked fine. In particular coturn installed without the problems mentioned in other topics. However, while tracking a related issue I realised that the coturn postinst script enables the TURN server in /etc/jitsi/meet/FQDN-config.js under p2p, and the local TURN server is in the list. However, it is commented out, while a third-party server is active:

        // The STUN servers that will be used in the peer to peer connections
        stunServers: [

            // { urls: 'stun:FQDN:443' },
            { urls: 'stun:meet-jit-si-turnrelay.jitsi.net:443' }
        ],

Where FQDN is the FQDN of my server.

Is this intentional, and do I interpret correctly that I would need to swap the two servers in the config in order to use my local coturn?

Thanks a lot,
Damian

OK, I think I figured it out, but maybe someone can confirm this is correct.
usetStunTurn: true
causes the TURN server to fetched via XMPP from the prosody configuration, and the one configured in FQDN-config.js is just a fallback?

That is correct. The one configured there stun servers is to be able to establish a p2p connection. And turn server always come from the server as it has credentials …

Thanks a lot for your reply. So STUN is external by default? Is there a reason not to use the internal coturn?

Nope, that’s why we left it commented in the config.js. If someone wants can use their own.

OK, so I got that working. One last question:

In other topics I read that a way to test the STUN/TURN server is to block UDP port 10000 on the server. If I do this, p2p still works, and I can see the traffic actually flowing p2p. However, more than two participants no longer works with UDP 10000 blocked. Should it still work through the TURN server? https://github.com/jitsi/jitsi-meet/blob/master/doc/turn.md seems to indicate STUN/TURN is only used for p2p. Or should the TURN server just forward traffic to JVB if UDP 10000 is blocked?

Turn forwards to jvb. To test it is to block udp 10000 only to your own ip where you run the chrome, so you block direct communication between your chrome and jvb and it will fallback to turn.

OK, so I tried the following:
-Connect from three different devices.
-Block UDP 10000 outgoing on one of the devices.

As far as I can tell this should emulate an ISP blocking UDP 10000. The result is that I lose audio and video on the blocked device. If I just use two devices with one blocked, everything works fine.

So I interpret that P2P is working, but fallback on the TURN server in case UDP 10000 is blocked is not.

I also confirmed this by looking at Brave’s WebRTC internals like here: Jitsi Meet - Problem with TURN Server
STUN properly works, but Brave never gets a TURN(S).

hi @zorc can you please tell me where you got the information from?
Or can someone tell me where I can find this " fetched via XMPP"? I’d like to see what address (for the turn server) is received.

Although, I have to say that I still haven’t gotten TURN to work. STUN works fine, but only if I change it in config.js. So to me it’s still not entirely clear how this XEP-0215 works. Whether it’s just used for the credentials or also URL of the server.

What I observed so far is that if I leave the default config with

{ urls: 'stun:meet-jit-si-turnrelay.jitsi.net:443' }

this is used in P2P. If I change it to my server and open UDP443 P2P works via my own STUN. However, I’ve never managed to get TURN to work, i.e. I don’t see any TURN URL in the browser’s webRTC, and I lose audio and video as soon as I block UDP10000 on a client.

Thanks.

That’s the same I’m trying to find out :laughing:

You’re a lucky guy.

I finally gave up, purged coturn, and reverted to the external Jitsi STUN server. I found out that coturn under Ubuntu 18.04 runs as root instead of the indicated turnserver user in the init script. Maybe this is due to the legacy init script used with systemd. Not sure why that’s the case on Ubuntu.

Gonna try now without TURN. P2P still working fine.

Noooooooooooooooooooooooooooo!

That’s funny cause on my debian it’s run as turnserver user and that’s because I had to change the acess rights of the key :slightly_smiling_face:

Now it looks like at least STUN works for me. Today I checked out the jitsi-meet repository and using that code now (with all other packages from stable).
At least I can see now some messages in firefox that something does not work with my TURN setup:

[modules/xmpp/strophe.jingle.js] <value/<>: getting turn credentials failed

[modules/xmpp/strophe.jingle.js] <value/<>: is mod_turncredentials or similar installed?

@jijit you need to enable turncredentials in prosody, see Jitsi Meet - Problem with TURN Server