TURN server not being advertised to clients - clients using turn.delta.chat instead

Mutual Help
, ,
1

Hello everyone,

I have set up a chatmail relay server following the official installation guide. Everything seems to be working fine for email functionality, but I’ve recently noticed an issue with the TURN server configuration.

When checking the logs on my DeltaChat desktop client during a call, I see that the client is using the public TURN server (turn.delta.chat) instead of my own TURN server.

Here’s the relevant log section:

text

🌍 Public IP (STUN): 1 candidate(s)
 • x.x.x.x:16689 (UDP)
🔄 TURN Relay: 1 candidate(s)
 • 46.224.39.230:50420 (UDP)

The IP 46.224.39.230 resolves to turn.delta.chat, which is the public TURN server, not my own server’s IP.

I have chatmail-turn running on my server with the following configuration:

text

ExecStart=/usr/local/bin/chatmail-turn --realm mydomain.com --socket /run/chatmail-turn/turn.socket

The service is running and appears to be working, but clients are still being directed to the public TURN server.

My questions:

  1. How does the chatmail server generate and advertise the TURN server information to clients?

  2. Where should I configure the TURN server address that gets sent to clients?

  3. Is there a script or configuration file that needs to be set up to populate the metadata with my own TURN server details?

I’m using the latest version of chatmail.

Any guidance would be greatly appreciated.

Thanks in advance!

2

I believe the TURN configuration is supposed to be done automatically by the Chatmail install script.
These technical details might help you debug the issue: Can I add calls to my mail by adding a turn on HestiaCP? - #2 by WofWca

3

One more thing to note: the code that picks a TURN server is not great when it comes to multi-relay usage (see e.g. Calls: use all relays' TURN servers, not just one). So to isolate the issue further, please confirm that the issue is reproducible on a fresh profile created from your relay.

4

It’s very strange. In the situation above, I used ArcaneChat on android and DeltaChat on Windows, and looked at the log on Windows.

But when I use DeltaChat on both devices, there is no problem at all. The shown TURN server is my own server.

I tried again with a fresh profile on ArcaneChat, and the problem is back! The TURN server shown on the windows side is again turn.delta.chat

Is there a special problem with ArcaneChat?

5

Great, that means that your server is working fine, probably.

One more debug tool: open the dev tools in the call window with Ctrl + Shift + I and enter await calls.getIceServers(), to list the actual list of servers, and not just the gathered candidates.

Also when testing this be aware that candidate gathering sometimes ends early if the connection can already be established, and this is what might explain the differences you see.

Otherwise don’t think the remote party is supposed to affect what ICE servers you use.

6

This is the result:

‘[{“urls”:[“stun:xx.xx.xx.xx:3478”],“username”:null,“credential”:null},{“urls”:[“turn:46.224.39.230:3478”],“username”:“public”,“credential”:“o4tR7yG4rG2slhXqRUf9zgmHz”}]’

There is no TURN server other that turn.delta.chat

This is the case that one side is ArcaneChat

When both side is DeltaChat, I see in the log that TURN relay candidate is my own server. But the output of getIceServers is the same as above.

Really confusing.

7

OK, so you have added your relay on the profile that’s on the Windows machine? If so, then the fact that doesn’t return it from await calls.getIceServers() is wrong, and it probably has to do with what I linked to above.
And the candidate is probably gathered thanks to the fact that the caller (Android) provides it in the offer (which I didn’t now that it can work this way TBH).

To verify, you may also create a new profile on the Windows machine as well.

To summarize again: your relay seems to be working properly. It’s a shortcoming of Delta Chat clients.

8

All profiles (windows, android DeltaChat, and android ArcaneChat) were fresh, and created on my relay. My relay were the only relay on all of them.

And it’s strange to me that Arcanechat works differnetly from Deltachat.

9

The problem is now solved.

I don’t exactly know how … I guess the main issue occurred in a multi-relay configuration, where one of the relays wasn’t working correctly. I also suspect I made some mistakes in the tests that followed from the problem.

However, I think there is a serious issue in the latest version of DeltaChat. In version 2.56, there is no way to delete a relay immediately. The removed relays stay active for a while (90 days, I assume), and during this period, they continue to advertise TURN servers. This means that if I add a relay and later delete it, I have no way to stop using its TURN server.

Additionally, if an unpublished relay stops working, I will get connection error messages in DeltaChat all the time!

All in all, I believe there should be a way to truly remove a relay and immediately terminate all connections to it. It’s also somewhat annoying to see removed relays still listed in the connections section.