Coturn fails to connect: "TLS/TCP socket buffer operation error (callback)"

Continuing the discussion from Jitsi-videobridge: Voice/video not working for client on public LTE network:

I think that coturn has an issue with TLS/TCP connections. Is this a known problem?

With jvb configured to use my self-hosted coturn as its turn server, voice/video sometimes doesn’t work. This impacts calls that include one member behind a NAT and one member on a LTE network, like a laptop connected to home WiFi & a phone connected to mobile data.

Whenever voice/video doesn’t work, coturn throws an error message of TLS/TCP socket buffer operation error (callback). The problem is not that the turn server isn’t being used, as coturn prints messages at the start & end of both failed & successful calls.

The only action that fixes the problem is to turn mobile data off then on again on my phone (sometimes more than once). I think the problem is having a “bad” IP address that coturn doesn’t like, and only getting a different IP that coturn likes (by repeatedly disconnecting/connecting mobile data) will make it work again.

I think the root of the issue is coturn having a problem with TLS/TCP (turns) connections. I say this because I can use the same coturn server to power 1:1 calls through a self-hosted Matrix server, but it only works consistently when using unencrypted turn. When using turns, calls have the same problem that Jitsi calls do: they usually don’t connect, and when they don’t, coturn prints the TLS/TCP socket buffer operation error message. (There’s an open Riot Android issue about this, though I now suspect that coturn is at fault since the same issue is plaguing jvb.)

Note that I have nginx set up with ssl_preread to send turns traffic over port 443, to prevent the chance of ISP firewalls blocking it. I know it works because 1) if it didn’t, Jitsi calls would never work at all, and 2) when I switch my coturn to use user/password credentials & test it with the WebRTC troubleshooter, the tests pass.

Interestingly, the TLS/TCP socket buffer operation error appears even for working calls, but in those cases, coturn soon prints many more messages that indicate a successful connection. For non-working calls, the error message is the last or nearly last message.

If it makes a difference, the version of coturn I’m using is armhf on Debian 10.

I had the same problem on a debian buster system … My advice: double check the certificates on the coturn server (are they really valid?) an the paths to the certificates specified in turnserver.conf, make them accessible by the user running coturn.

Yup, the cert/key files are already world-readable, and coturn’s logs report Certificate file found and Private key file found. I’m using the same cert/key for my webserver, which works, so the cert must be valid.

If it makes a difference, I have no-tlsv1 and no-tlsv1_1 in my turnserver.conf, so the SSL/TLS versions that get used are SSL23 and TLS1.2.

EDIT: I just tried removing no-tlsv1 and no-tlsv1_1 to see if it would fix the problem; it didn’t.

Where do you have the certs stored? I created an extra folder for coturns certs, respectively mine are letsencrypt certs which I copied to /etc/coturn which is chmodded with 600 and owned by turnserver:turnserver … This worked.
I have no-tlsv1 and no-tlsv1_1 aswell.

See my config here:


Are the firewall settings correct? What are your outbound and inbound connections?

I’m seeing the same thing on both an upgrade and fresh install of Jitsi Meet on Ubuntu 18.04 with the default coturn configuration:

185: IPv4. tcp or tls connected to:
185: session 003000000000000001: TLS/TCP socket disconnected:
185: session 003000000000000001: closed (2nd stage), user <> realm <> origin <>, local, remote, reason: TLS/TCP socket buffer operation error (callback)

@brknkfr Thanks for the help. Unfortunately changing the certs had no impact.

I did the following:

  • Copied the cert & key files from /etc/letsencrypt/live/<mysite>/ to /var/lib/turn/ (a directory readable by the turnserver that already stores turndb)
  • Also copied the DH parameters file /etc/letsencrypt/ssl-dhparams.pem to /var/lib/turn/
  • Changed the owner of the copied files to the turnserver user
  • Changed the permissions of the cert & key files to 600
  • Left the permissions of the copied DH params file as 644
  • Updated turnserver.conf to use those files

Note that before all this, I hadn’t specified a dh-file in turnserver.conf. Despite this, media calls were still able to sometimes work. I expected that specifying a proper dh-file would help, but as far as I can tell, the only difference it made is that it got rid of an error message of set_ctx: ERROR: cannot set DH in coturn’s logs.

My firewall settings correctly allow in/outbound TCP traffic on ports 443 and 4443, and UDP traffic on port 10000. I confirmed this with nc -z -v [-u] <my_hostname> <port>. Also, media always works when connecting from two laptops, with one of them on a corporate VPN (and the network-inspector widget on the Jitsi Meet page shows that the port in use is 10000 with udp). It even works without using nginx’s ssl_preread to forward turns traffic to port 443 (which I’d rather not have to do anyways).

What might be relevant is the fact that jvb never uses a P2P connection when one of the clients is my phone, whether it’s on WiFi or LTE. P2P works between two laptops on different or the same/different network, and between phone/laptop both on the same network, but not between phone/laptop on different networks.

I ended up doing some packet captures to take a look at the TLS setup on the TURNS traffic, and it turns out that the Android app is terminating the TLS setup with an “Unknown CA” reason in the TLS Alert packet that it sends. I’ve replicated this on both the coturn server installed as part of Jitsi Meet (running a Let’s Encrypt certificate) and an external coturn server (running an InCommon certificate). Chrome and Firefox are able to validate the certificates on both coturn servers without issue.

A correction:

I realized that I wasn’t using the full certificate chain on the coturn server running an InCommon certificate. The Android app works fine with the full InCommon chain. However it still doesn’t like the chain of a Let’s Encrypt Certificate and the “Let’s Encrypt Authority X3” certificate.

I‘ve the same probleme here. Any idea how to solve this issue?

What I’ve done for the time being is put a certificate chain signed by InCommon on the coturn server. Nginx is still using the certificate chain signed by Let’s Encrypt without issue.

I have an issue open on GitHub though there hasn’t been any activity on it.

Same problem here, packets dump shows TLS Alert “Unknown CA” when calling from an Android (tested on two devices, Android 9 and 10) device using TURNS protocol with a LetsEncrypt certificate and the jitsi-meet setup…

has anyone found a solution yet?


Same here with coturn cert= contains the full chain, including the RootCA (CN=T-TeleSec GlobalRoot Class 2).

Same issue. Unable to get ios or android jitsi apps to work with coturn and letsencrypt cert. Chrome browser works on windows as well as android but neither mobile app works for video or audio on our install. Can the mobile app be built with let’s encrypt ability to trust our let’s encrypt generated certs?

origin <>, local, remote, reason: TLS/TCP socket buffer operation error (callback)

Get these lines in our turnserver logs for each time an ios or android app attempts to connect to coturn.

Someone was able to get it working by disabling H264: Jitsi-videobridge: Voice/video not working for client on public LTE network

I haven’t been able to test it myself yet, but anyone here who’s interested can give it a try.

No that doesn’t seem to work for me. Are you having the same issues with coturn behind a firewall of port 80 and 443 open?

I wish someone from jitsi would comment on the state of coturn and the mobile apps. Everything works fine on chrome or edge with multiple tabs open but their mobile apps appear to have an issue when p2p is turned off and attempting to join a meeting using let’s encrypt ssl certs.

What worked for me is this instead of giving:


I used


And it started working for me.

That doesn’t work for me, unfortunately. In fact, I’ve been using fullchain.pem since the beginning.

The H264 trick from before didn’t help either, btw.