No stream sharing ? about galene_ynh

[jech]

Current Git master goes further, automatically generating a self-signed certificate if none is found under the data/ directory. Let me know if this feature is useful for you and you want me to tag a release.

[ericgaspar]

@lapineige

What do you think @ericgaspar ?

My plan is to push the build-in TURN server version in master. The version with additional coturn installation will go to another branch and need to be reworked, but the idea is to get coturn out of the package and put the effort on maintaining coturn_ynh instead (TURN server is also needed for other apps Nextcloud, XMPP...).

[raspoutnik]

I guess it can be reused... Config file is /etc/matrix-synapse/coturn.conf
But I'm leaving another call with someone else, and he didn't manage to have my webcam, while I had both, his and mine. Maybe have to configure STUN server too ? Also, I reproduced the previously successful combination and now face the same issue.

Here is my /opt/yunohost/galene/data/ice-servers.json

[
{
"urls": [
"turn:MY_SYNAPSE_DOMAIN:5349",
"turn:MY_SYNAPSE_DOMAIN:5349?transport=tcp"
],
"username": "galene",
"credential": "STATIC_AUTH_SECRET_AS_IN_COTURN.CONF",
"credentialType": "hmac-sha1"
}
]

[ericgaspar]

If someone as some time to try, there is a Galène version with COTURN in here : https://github.com/YunoHost-Apps/galene_ynh/tree/COTURN. Still work to do. (restore not working yet.)

[ericgaspar]

New version in master.
I will advice not to do a single upgrade but to reinstall the app as a lot of code have been added.

In this new version:

• Galène get is own COTURN server integration; to check if the TURN server is up and running, type /relay-test in the chat box; if the TURN server is properly configured, you should see a message saying that the relay test has been successful. (you have to connect first with you operator account)
• New settings included in GROUPNAME.json

Thanks in advance for testing!

PS. I open the Discussions tab (on the right of Pull Requests). For general matters we should us it and leave the Issues for actual bug report.

[jech]

IPv6 might be an issue, so I believe we need an alternative.

Galène will still work with IPv6 — it's only the TURN server that doesn't: - direct UDP over IPv4: ok - direct UDP over IPv6: ok - TURN over IPv4: ok - TURN over IPv6: fails Since clients with IPv6 available don't usually need to go through a TURN server, it should not be a problem in practice.

[jech]

@ericgaspar,

We do generate a self-signed certificate.

I see. Switching to current head master would allow you to remove this block of code, and to remove a dependency on the OpenSSL CLI, at the price of not having a stable fingerprint (the certificate would be regenerated every time Galène is restarted).

Please give me a few days, I want to tweak the code some more before I make a release.

[jech]

generating a self-signed certificate are great additions. This simplifies the package. If you have the time to post a tag release, I'll make sure to update the package!

I've just tagged 0.3.1. A self-signed certificate will be generated if neither cert.pem nor key.pem are found.

[lapineige]

I searched a bit about the server configuration files, and it happens that there is no STUN/TURN server configured (as described here https://galene.org/README.html).
Maybe that's the issue ?

[raspoutnik]

Yes, I have it working with ice-servers.json configured according to coturn.conf shipped with Synapse app for Yunohost.
Thanks a lot !! 🚀

[lapineige]

You mean we can reuse that coturn server ? That's good news :) (it avoid duplicates, I guess)

Where do you find that config (file) ?

[ericgaspar]

Nice, @raspoutnik do you mind sharing your ice-servers.json setting.

[lapineige]

It works !! 🚀

Maybe have to configure STUN server too ?

I'm clearly not an expert, but I believe a TURN server should include STUN server use cases, so I don't think that the issue… but this has to be confirmed.
Maybe there is an issue with synapse using the TURN server too ?

ping @Josue-T, you might have some clue here.

[raspoutnik]

I moved from Firefox to Chrome on my Android with LTE connection and have it working bothsides with Firefox on my desktop computer again.
Further STUN tweaks do not change anyting...

With Firefox on Android I face these types of logs from galene.service :

Jan 11 18:47:45 *** galene[2869]: 2021/01/11 18:47:45 Read RTCP: io: read/write on closed pipe
Jan 11 18:47:47 *** galene[2869]: 2021/01/11 18:47:47 sendSR: io: read/write on closed pipe
Jan 11 18:47:51 *** galene[2869]: 2021/01/11 18:47:51 sendSR: io: read/write on closed pipe

[lapineige]

I had the issue yesterday, I did kill TURN server and launch it back, now the issue is gone… strange…

[lapineige]

I upgraded to that version (by forcing it, as it's the same manifest version):

cp: cannot create regular file '/etc/galene/coturn.conf': No such file or directory

And then :

Could not upgrade galene: This action broke dpkg/APT (the system package managers)... You can try to solve this issue by connecting through SSH and running sudo apt install --fix-broken and/or sudo dpkg --configure -a.

😅

Now even getcwd() fails 😅

edit: I fixed it.
Install works.

It doesn't work. Turn server is running, but no stream is shared with the server.

[lapineige]

Relay test failed: Error: timeout :(

I don't know how where to check for logs…

edit: ok, it was simply in /var/log/galene/turnserver.log

0: Trying to bind fd 41 to <127.0.0.1:3478>: errno=98
0: Fatal final failure: cannot bind TLS/TCP listener socket to addr 127.0.0.1:3478
0: Cannot bind TLS/TCP listener socket to addr 127.0.0.1:3478
0: Fatal final failure: cannot bind TLS/TCP listener socket to addr 127.0.0.1:3478

I will advice not to do a single upgrade but to reinstall the app as a lot of code have been added.

Ok thanks for the tip 👍 (and it's super easy to manually backup both groups and ice configuration, just a few files to copy)

---

PS. I open the Discussions tab (on the right of Pull Requests). For general matters we should us it and leave the Issues for actual bug report.

Oh, I did not know that feature… that could be useful indeed :)

[raspoutnik]

Hi, thank you !

I tried the new version, I also have timeout error. I lose the stream sharing when switching to 4G network, but have it inside LAN.
I checked open ports on my ISP box (5350 and new 5351), tried to change to 5351, 5352 in both config files, supposing 5350 may conflict with Synapse's Coturn configuration... but no luck.

I do not have abnormal warnings in /var/log/galene/turnserver.log, it seems to have initialized normally.

I got back to Synapse-linked configuration, this time with both 5349 and 5350 ports, TCP and UDP, and it also works, relay-test ok.

It looks like the second coturn server is unreachable from the outside...

[lapineige]

I tried the new version, I also have timeout error. I lose the stream sharing when switching to 4G network, but have it inside LAN.

Then indeed it's really a NAT / TURN server issue…

[lapineige]

@Josue-T maybe you might have some input here ? (based on your Synapse packaging experience)

[ericgaspar]

On my VPS server, TURN is working with Galène. It also worked alongside Synapse.
You can also test if you turn server is running with this https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

[lapineige]

Not sure about how that site work, but "gather candidates" doesn't give me any result.

I've synapse installed too.

[raspoutnik]

The most conclusive result I had with this tool, using "turn:galene.domain:5351?transport=tcp" for example, is that there is no clear indication that a relay has been detected, neither where, but an execution time and the word "Done", instead of "Not Reachable ?" with wrong parameters, either when switching to IceTransports value fixed to "relay". The same applies with turn:synapse.domain:5349 and 5350. So I guess it is reachable.

But /relay-test still fails with default galene ice-servers.conf, and succeeds with synapse's parameters...

[lapineige]

I upgraded to #14, it still fails 😢

[jech]

If you're running Galène 0.3, you may test your TURN server by typing /relay-test in the chat. (No need to be administrator, you just need to be logged in.)

[lapineige]

That's what I did we previous versions and now with 0.3, but it always gives me an (instantaneous) timeout.

edit : @ericgaspar I just realised that my 3478 port is closed, is that a problem ? It tries to access 127.0.0.1 so I suppose the port doesn't need to be opened for localhost ?

[jech]

The TURN port must be accessible to the client, so it must be open.

[lapineige]

Then maybe we found the issue… it should be opened https://github.com/YunoHost-Apps/galene_ynh/blob/testing/scripts/install#L93 (and I tried with a fresh install)

[jech]

Galène used TURN over plain TCP and UDP, not over TLS (Galène's traffic is already encrypted, so contacting the TURN server over TLS is not useful). Coturn accepts plain TCP connections on the TLS port, so it happens to work, but I find your configuration confusing.

Currently, galene.org uses the built-in TURN server, but here's my TURN configuration on another instance of Galène that still uses coturn:

listening-port=1194
lt-cred-mech
user=xxx:yyy
realm=irif.fr
syslog

[lapineige]

Then I wonder why I have this error with /relay-test in the log : #10 (comment)

Disclaimer: I'm a total TURN noob, so I might be completely off-topic.

[jech]

0: Trying to bind fd 41 to <127.0.0.1:3478>: errno=98
0: Fatal final failure: cannot bind TLS/TCP listener socket to addr 127.0.0.1:3478
0: Cannot bind TLS/TCP listener socket to addr 127.0.0.1:3478
0: Fatal final failure: cannot bind TLS/TCP listener socket to addr 127.0.0.1:3478

Errno=98 indicates that somebody else has already bound port 3478. Please run netstat -apn as root in order to find out who.

[lapineige]

I just checked with latest version (0.3, with a lot of changes in turn server config since my previous test), I don't have this error in the log.

I see some logs about turn server creation (8 times):

[…]
IO method (general relay thread): epoll (with changelist)
turn server id=4 created
Total General servers: 8

And something about the relay:

relay SOME_IP_ADDRESS initialization...
relay SOME_IP_ADDRESS initialization done
Relay ports initialization done

I'll try to open the port.

[ericgaspar]

@lapineige You may want to test the version with build-in TURN server :
sudo yunohost app install https://github.com/YunoHost-Apps/galene_ynh/tree/without-turn-0.3

[lapineige]

Oh ok, when I saw the name of the PR I thought it was a special version with no TURN server at all… I was wondering what it was 😅

I'll try it :)

[jech]

Oh ok, when I saw the name of the PR I thought it was a special version with no TURN server at all… I was wondering what it was 😅

Galène 0.2 relied on an external TURN server. It turned out that installing coturn was a major stumbling block for many users. Galène 0.3 includes a built-in TURN server which is started automatically if no ice-servers.json file is found. This can be controlled explicitly using the -turn command-line option. The built-in TURN server does not have all of the features of coturn (it cannot do IPv6 and it implements the protocol incorrectly in some cases), but it works well enough in practice. Please report bugs here: https://github.com/pion/turn

[lapineige]

Galène 0.2 relied on an external TURN server. It turned out that
installing coturn was a major stumbling block for many users.

I'm not surprised (and that was something that gave a lot of work to @ericgaspar for this Yunohost package), so thanks a lot, that's a great addition.

[ericgaspar]

We do generate a self-signed certificate.
Adding a built-in TURN server and generating a self-signed certificate are great additions. This simplifies the package. If you have the time to post a tag release, I'll make sure to update the package!

[lapineige]

You may want to test the version with build-in TURN server :

Relay test successful in 245ms, RTT 18ms and it works out of the box ! 🎉 🚀

That's great !

---

What are the limitations of using this built-in TURN server ?
I wonder if we could integrate only that server, or if we should propose an option (or other branch / a tutorial ?) for the full TURN server if needed.

[jech]

We've been running it in production for a few weeks, and it works well enough for our students. I think you should switch to using the built-in TURN server, it's simpler and works well enough in practice.

The main limitations are that it doesn't do IPv6 and that error-handling is not up to spec. I'm planning on fixing that at some point, but it's a pretty low priority.

[lapineige]

IPv6 might be an issue, so I believe we need an alternative. But I don't think that should prevent us from using the integrated server by default.
Maybe we could keep the other server in a separate branch from the moment ?

What do you think @ericgaspar ?

[lapineige]

Sounds good :)
And we will have a working version by default 🎉

Closing this, as it's fixed by #20