Have a working setup with TURN, but some users are still having issues

I have the docker install of jitsi and a separate coturn instance installed on two separate ec2 instances.

The turn server is listening on ports 80 and 443 to try and prevent any issues with blocked ports from customer corporate firewalls and vpns.

It seems to work perfectly, if udp 10000 is blocked, I can see from the turn server logs that the requests are hitting it, and if I open the port back up, the turn server is no longer used.

I thought this would resolve most, if not all of the issues my users are facing, but we have done some tests with them and nothing seems to have changed.

I think this is maybe more likely due to the restrictions by their in-house IT department, but thought I’d check here to see if anyone has any further tips or advice on this matter? I’m not even sure what could be blocked at the user end for it not to work.

Some config:


external-ip=[public ip]/[private ip]
static-auth-secret=[my static auth secret]


// not done for p2p
useStunTurn: true,


turncredentials_host = "[turn.mydomain.com]"
turncredentials_secret = "[my static auth secret]";
turncredentials_port = 443;
turncredentials_ttl = 86400;
turncredentials = {
    { type = "stun", host = "[turn.mydomain.com]", port = "443" },
    { type = "turn", host = "[turn.mydomain.com]", port = "443", transport = "udp" },
    { type = "turns", host = "[turn.mydomain.com]", port = "443", transport = "tcp" }


VirtualHost "meet.jitsi"

    modules_enabled = {

VirtualHost "guest.meet.jitsi"

    modules_enabled = {



Mind that the turnserver needs access to udp 10000 to the bridge.

Here is working config for turnserver: jitsi-meet/turnserver.conf at master · jitsi/jitsi-meet · GitHub

Set this in the global section and in the p2p one.

Why you changed those? Seems wrong to me. We do not recommend using tcp with the bridge. We recommend using tcp with the turnserver. And why changing the port from the default udp 10000 to udp 443? Not sure what you were testing with blocking udp 10000 if you are using udp 443? JVB to be able to bind to ports <1024 need special permissions, not sure that succeeds on your end.

Mind that if your turnserver and jvb are in the same network that is wrong. You either need to use the default one or some other one that is in another network or you can specify the local and public address for the jvb by hand.

Thank you @damencho.

Yip, I have allowed the ip of the turnserver access to udp 10000 of the jitsi instance (security group in aws).

Thanks, I will try updating with those other settings.


I see that the ports from jitsi-meet/turnserver.conf at master · jitsi/jitsi-meet · GitHub that 3478 and 5349 are used, but I am trying to use 80 and 443 so that there is no issue with blocked ports (since 80 and 443 would need to be allowed for any web browsing). Am I correct in using 80 and 443 or am I wrong on how the turn server works? i.e. are the recommended ports used at the client end?


If I also put useStunTurn: true, in the p2p section, do I need to change the default stunServers config?

It seems to work fine with 2 users in the room but the way we use jitsi, it will never be used for just two people.

It’s currently

stunServers: [
    // { urls: 'stun:jitsi-meet.example.com:3478' },
    { urls: 'stun:meet-jit-si-turnrelay.jitsi.net:443' }

This is the part I am most unsure about. I’ve read everything I can find on the topic and this seemed to be mentioned in a few of the other forum posts that I found.

I thought org.jitsi.videobridge.DISABLE_TCP_HARVESTER=false was part of having a working turn server config (since udp would be blocked) and that org.jitsi.videobridge.SINGLE_PORT_HARVESTER_PORT=443 was the port of the turnserver it would try and use, I am guessing this is incorrect?

To be honest, I am not sure what they do, should I change these settings?

Same as above for this, I thought org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES had to be set to the address of my turn server?

The turn server and jvb are not on the same network, possibly in the same vpc within aws, I can check, but they are two separate ec2 instances.


Just checked and the instances are on the same vpc, does this matter?

Thank you!


We run turnserver on port 443 for meet.jit.si, that is fine. The default jitsi-meet install uses the standard ports as turnserver is installed on the same machine where nginx runs and cannot use port 443. There are special instructions when you need to run them on the same machine: Setting up TURN · Jitsi Meet Handbook

Nope. The turnserver for the p2p and jvb connection come from the same place from prosody.

You should not touch those. We have seen very bad jvb performance from clients connecting with tcp to it, that’s why you need the turnserver.

It will not work if they are in same vpc, I think … use the meet.jit.si one that is set by default for now …

Cheers, I will give those a try, thanks again, much appreciated!

Made the following changes:

commented out the following from the jvb/sip-communicator.properties:

# org.jitsi.videobridge.SINGLE_PORT_HARVESTER_PORT=443
# org.jitsi.videobridge.DISABLE_TCP_HARVESTER=false
# org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=[turn.mydomain.com]:443

and changed the bottom line back to


and added useStunTurn: true, to the p2p section in web/config.js.

After blocking udp 10000 on the jitsi server (still open to turn server), p2p still works but once there are 3 users the jvb is not working.

I will try and have a look at the log files, it’s easier when doing docker-compose up -d to see the logs but don’t want to restart the containers and lose changes.

I don’t think the containers need restarted for changes to take effect do they? Anytime I’ve done that in the past I’ve lost some changes that I’ve made to files under ~/docker-jitsi-meet/.jitsi-meet-cfg which are the files I’m editing.

I’ve not added the extra config to the turnserver.conf yet, will try that in case it makes a difference.


After combining damencho’s suggestions and adding in the additional recommended turn server config, I’ve got it working again after blocking udp 10000.

Time for another test with some end users.