YunoHost-Apps / galene_ynh

Galène package for YunoHost
https://galene.org/
GNU General Public License v3.0
10 stars 3 forks source link

No stream sharing ? #10

Closed lapineige closed 3 years ago

lapineige commented 3 years ago

(Install works well, thanks a lot for that package ! :rocket:)

I tried to use it (from several browsers, internet connection, and PC + phone), by sharing sounds+camera and/or screen, those streams are shown in the local browser, but not shared to others participants.

Here is the output of galene service status:

Deleting unknown down connection http: TLS handshake error from 127.0.0.1:59772: EOF

I can't reproduce that message, so I don't know if it's linked.

Also there is no bandwidth indication at the bottom of each stream frame, which might indicate that nothing is sent ? :thinking:

lapineige commented 3 years ago

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 commented 3 years ago

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

lapineige commented 3 years ago

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 commented 3 years ago

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

raspoutnik commented 3 years ago

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" } ]

lapineige commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

ericgaspar commented 3 years ago

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.)

lapineige commented 3 years ago

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.

ericgaspar commented 3 years ago

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:

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.

lapineige commented 3 years ago

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 :+1: (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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

ericgaspar commented 3 years ago

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 commented 3 years ago

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

I've synapse installed too.

raspoutnik commented 3 years ago

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 commented 3 years ago

I upgraded to #14, it still fails 😢

jech commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

lapineige commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Then I wonder why I have this error with /relay-test in the log : https://github.com/YunoHost-Apps/galene_ynh/issues/10#issuecomment-760019960

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

jech commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 :sweat_smile:

I'll try it :)

jech commented 3 years ago

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 commented 3 years ago

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.

jech commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 ?

jech commented 3 years ago

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:

Since clients with IPv6 available don't usually need to go through a TURN server, it should not be a problem in practice.

jech commented 3 years ago

@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.

ericgaspar commented 3 years ago

@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...).

lapineige commented 3 years ago

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

Closing this, as it's fixed by #20

jech commented 3 years ago

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.