Connecting coturn_ynh fails (relay-test timeout)

[jakobkilian]

Describe the bug

Installed coturn_ynh as I wanted to solve this issue. Sometimes people still can't see the video streams of others in galene (opened an issue a while ago) and I thought this might be related, too.
I checked if the TURN server is available with the Trickle ICE tool –> working.
I followed the galene_ynh docu for using an own turn server, but the relay-test (in the chat box in galene) fails.
I tried the use-auth-secret and the lt-cred-mech mode with no success (Trickle ICE worked for both). In the logs (sudo journalctl -u coturn) I can only find a note that the relay-test failed. Where can I find verbose information like auth fail or an error code?

Context

• Hardware: Hetzner VPS
• YunoHost version: 11.1.5.5
• I have access to my server: SSH
• Are you in a special context or did you perform some particular tweaking on your YunoHost instance?: no

[jakobkilian]

Some more info on that case. Hope that helps, please tell me if I can get any other log...

• When being connected to Galene with a browser, there is this message in the journalctl -u galen every 2min:

Feb 12 13:34:53 portal.MYDOMAIN.org galene[15002]: turnc ERROR: 2023/02/12 13:34:53 fail to refresh permissions: write tcp4 127.0.0.1:37898->127.0.0.1:5349: write: broken pipe
Feb 12 13:34:53 portal.MYDOMAIN.org galene[15002]: turnc ERROR: 2023/02/12 13:34:53 fail to refresh permissions: CreatePermission error response (error 400: Bad Request
Feb 12 13:34:53 portal.MYDOMAIN.org galene[15002]: )

• Another thing that I checked is, if port 5349 is reachable from inside and outside of the network → it is.
• The output of serverConnection.rtcConfiguration in the Firefox console is the following. This config has been tested with Trickle ICE

Object { iceServers: (1) […] }
  iceServers: Array [ {…} ]
    0: Object { credential: "test123", credentialType: "password", username: "test", … }
        credential: "test123"
        credentialType: "password"
        urls: Array [ "turn:turn.MYDOMAIN.org:5349", "turn:turn.MYDOMAIN.org:5349?transport=tcp" ]
        username: "test"
        <prototype>: Object { … }
    length: 1
    <prototype>: Array []
<prototype>: Object { … }

Note: I changed the actual domain to MYDOMAIN on purpose.

[jakobkilian]

Would be very happy to receive tips on how I can debug the problem further :)

[ericgaspar]

Did you actually experienced issues with Galène build in Turn server?

[jakobkilian]

Did you actually experienced issues with Galène build in Turn server?

Hmm, the relay-test with the internal did work. I just had the "Port 1194 is not reachable from outside in IPv6" Issue and then read, that the internal Turn server generally does not support IPV6.
Still about 5 % of the people cannot participate in video calls (or have to change their machine) – most of the time they can enter the call and listen but video streams are not visible. As these people sometimes use iPads (difficult to debug) or are "external" people (which I cannot easily ask to send me their logs for debugging) I didn't really come further and therefore though I check the IPV6 reachability. Very often people with problems were using eduroam or company internal Wifis...

Wrong derivation?

[jech]

Two things come to mind.

1. Port 5349 is normally for TURN over (D)TLS, which Galene does not support. Are you sure that you didn't mean to specify port 3478?
2. Both ports 3478 and 5349, are often blocked in Eduroam networks. I recommend switching to either port 1149 (OpenVPN) or port 10000 (Cisco VPN server), which are more likely to be open.

[jakobkilian]

Ah, thanks. that wasn't clear to me. The standard config actually has the listening-port=3478 line commented in /etc/turnserver.conf so there never was a TCP/UDP port open.
So I uncommented, restarted and tested (using turn:turn.krakelee.org:3478 with the Trickle ICE tool) with both 3478 and 1149 with no success. Nevertheless the turn server is still reachable with 5349...

Is there any other setting in coturn_ynh that I need to set to activate TCP/UDP?

[jech]

1. Make sure that the Galene log says « relay test successful ».
2. Log into Galene and type « /relay-test ». It should report success.
3. Repeat the test (2) on the client that has an issue.

[jakobkilian]

Sorry, maybe I didn't express myself correctly: I can't do 1, 2 or 3 because the coturn server is not accessible via UDP/TCP. However, this is a matter concerning coturn_ynh, I might create an issue there if I don't get any further.

[jakobkilian]

Shame on me, I had blocked the UDP port despite checking several times → now I can reach the coturn server on 1149 from outside with UDP/TCP.
Unfortunately, everything remains the same with Galene:

12:05:13 Relay test failed: timeout
12:05:13 Perhaps you didn't configure a TURN server?

my /var/www/galene/live/data/ice-servers.json is:

[
        {
                "urls": [
                        "turn:turn.MYDOMAIN.org:1149",
                        "turn:turn.MYDOMAIN.org:1149?transport=tcp"
                ],
                "username": "test",
                "credential": "test123"
        }
]

With exactly those creds I can reach it with the Trickle ICE tool...

[yeppey]

Just installed coturn_ynh for galene_ynh (to have ipv6 STUN/TURN because the integrated "pion" in galene is v4-only) and had the same trouble.

I solved it by adding '"credentialType": "hmac-sha1"' in /var/www/galene/live/data/ice-servers.json :

[
        {
                "urls": [
                        "turn:turn.MYDOMAIN.org:5349",
                        "turn:turn.MYDOMAIN.org:5349?transport=tcp"
                ],
                "username": "test",
                "credential": "test123",
                "credentialType": "hmac-sha1"
        }
]

(don't forgot the ',' at the end of credential line)

I think this is because coturn_ynh is using dynamic credentials (wich, as I understand, is more secure) and when galene server try to connect to coturn it must use temporary credentials using this kind of formula : https://stackoverflow.com/a/54725092

After configuration in json file, you need to restart galene service.

You can check it works in galene logs :
Relay test successful in 95.293238ms, RTT = 508.12µs

And using "/relay-test" in galene tchat you should see :

Relay test in progress...
Relay test successful in 739ms, RTT 42ms