Coturn, prosody, turncredentials vs external_services module


since release 2.0.5765 I have issues in my on prem jitsi setup in case access to jitsi via port 443 only is required.
about:webrtc-internals shows me

iceServers: [turns:<MY_TURN_DOMAIN?transport=tcp, stun:<my_turn_domain>, turn: <MY_TURN_DOMAIN]

prosody config:

external_service_secret = “MY_TURN_SECRET”;
external_services = {
{ type = “stun”, host = “MY_TURN_DOMAIN”, port = “3478” },
{ type = “turn”, host = “MY_TURN_DOMAIN”, port = “3478”, transport = “udp”, secret = true, ttl = 86400, algorithm = “turn” },
{ type = “turns”, host = “MY_TURN_DOMAIN”, port = “5349”, transport = “tcp”, secret = true, ttl = 86400, algorithm = “turn” },
{ type = “turns”, host = “MY_TURN_DOMAIN”, port = “443”, transport = “tcp”, secret = true, ttl = 86400, algorithm = “turn” }

If i use the older turncredentials module everything works and the about:webrtc shows me the correct turn servers, including ports:

{ iceServers: [turns:MY_TURN_DOMAIN:5349?transport=tcp, turns:MY_TURN_DOMAIN:443?transport=tcp]

prosody config:

turncredentials_secret = “MY_TURN_SECRET”;
turncredentials = {
{ type = “stun”, host = “MY_TURN_DOMAIN”, port = “3478” },
{ type = “turn”, host = “MY_TURN_DOMAIN”, port = “3478”, transport = “udp” },
{ type = “turns”, host = “MY_TURN_DOMAIN”, port = “5349”, transport = “tcp” },
{ type = “turns”, host = “MY_TURN_DOMAIN”, port = “443”, transport = “tcp” }

What other parts of the jitsi config need a change to use the external_services module ?
Or can somebody share what iceservers are offered in case the “external_services” module is in use in your setup ?

environment / setup info:
-one public IP
-one system running debian. with local ip.
-2 domain names with letsencrypt (one for coturn,one for jitsi)
tcp port 443 tls turn traffic: haproxy,tcp mode > turn on docker container
tcp port 443 tls jitsi traffic: hapoxy, tcp mode / proxyprotocol > go-mmproxy > nginx including tls termination > jitsi docker containers.

Do you have this in your config jitsi-meet/prosody.cfg.lua-jvb.example at f377455069ff7ae41963864a61b87d988f5bd5bf · jitsi/jitsi-meet · GitHub?

hello damencho,
yes, the test was done with module external_services activated. the module works as i can see the turn server working fine on its default port 5349:
in case access to the turnserver is allowed on port 5349 the setup works. it only breaks in case only tcp 443 is allowed.
during the test i described above i change the config according to the modification to file doc/debian/jitsi-meet-prosody/prosody.cfg.lua-jvb.example in your pull request feat: Uses mod_external_services supporting urn:xmpp:extdisco:2. by damencho · Pull Request #8455 · jitsi/jitsi-meet · GitHub

I’m not sure why the module does not give you both, but why do you need two turns candidates? One is enough, FF even gives warning if you provide more candidates …

hello damencho, I already tested with only one turn option (with port 443). also in that case in chrome-webrtc internals i do not see the port 443 mentioned and I can successfully connect over port 5349. so it looks like external services is somehow not pushing the port configuration option ?
the reason for me to offer multiple URLS is maximizing interoperability:
a) in case the firewall blocks udp 10000 > turn on port 5349 or port 443 is ok
b) in case the firewall blocks 5349 and udp port 10000 > turn on port 443 is ok.
c) in case the firewall is doing deep inspection on port 443, allowing only https traffic and udp 10000 > turn on port 5349 would work.
I have tested with mod turncredentials that a,b scenario works. only the deep inspection scenario is hard for me to test.

can you share what iceserver you get in case external_services is in use and you specify tcp port 443 ?


You can check it on

I had to use the old AND the new variables (external_service_secret / turncredentials_secret, turncredentials_port, turncredentials_ttl) to make it work within my environment.

hello damenco, i cannot reach . is it up ?


Ups, I misspelled it :slight_smile: It is looks good:
it mentions the port in webrtc-internals:
{ iceServers: [,, } i can also connect via port tcp 443.

You config is wrong. It should look like this: jitsi-meet/prosody.cfg.lua-jvb.example at d7639963d3c0b058ccae3707f6dfda1be3625b9c · jitsi/jitsi-meet · GitHub
look at the port section.

the double quotes are wrong around the port number!
thanks a lot.
issue solved…

hi together,
we could need some support, too.
1 VM behind NAT
Default Jitsi Setup. So far everything is working, if udp/10000 is free to use for the clients.
The TCP Fallback to 443 is not working, but for the sake of compability to a lot of company users highly demanded.
We tried our look with tcp_harvester but with no results, too.

Is a fallback to tcp 443 even possible like this?
If yes, what should be changed, compared to the default setup (Ubuntu)

If not, what would be needed to get jitsi running with a working tcp443 fallback?
Is there a working howto after the recently done changes?

Thanks and best regards

1 Like

Hello Fabian,
Your setup looks like mine (one vm behind NAT). I do not use tcp_harvester.
Fallback to tcp 443 is possible (i tested with chrome,chromium on windows 10 / linux ubuntu clients)
setup: 2 domain names (one for turn, one for jitsi).
tcp 443 haproxy>go-mmproxy>nginx>nginx on docker
tcp 443 haproxy > tcp 5349 coturn on docker
tcp 5349 > tcp 5349 coturn on docker.

I would recommend to check first about:webrtc-internals to validate that turn url is published in your case. does it mention any turn servers ?

1 Like

Hi damencho and tob123,
thanks for your answers.
I followed the guide for setting up turn server for 443.
But it doesn’t work for me. If I block udp10000 i see no video and get not audio.

webrtc-internals output looks like it should (IMHO):, { iceServers: [], iceTransportPolicy: all, bundlePolicy: max-bundle, rtcpMuxPolicy: require, iceCandidatePoolSize: 0, sdpSemantics: “plan-b” }, {advanced: [{googScreencastMinBitrate: {exact: 100}}, {googCpuOveruseDetection: {exact: true}}]}

How do you block it? Do you block it on the client side?
Mind that you cannot block it on jvb side, as turnserver needs to access it.

I blocked it on my “home office router”.

Do i have to configure coturn in any additional way. or is a default ubuntu jitsi-meet install + the link for Setting Up Turn to listen on 443 enough?
Is this method working, if jitsi-meet is placed behind an enterprise FW with NAT?


Just make sure you use valid certificates.