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.
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
220.127.116.11-1.1 armhf on Debian 10.