-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Enable TURN by default in packages #8251
Comments
Yup, this would be good, and would make a lot of sense to include in the docker containers. I'm not totally sure how easy it'd be to add to other packages though. Related: #1219 |
I suspect it would be hard to do for a lot of environments, docker included. The networking requirements of a TURN server are somewhat exacting (certainly harder than setting up a separate coturn). |
@richvdh One option would be to recommend host networking mode for the container. Another would be to provide a known-good docker command line. |
One almost certainly wants to run the TURN server as a separate container (and from a separate image) when using docker. |
https://github.com/spantaleev/matrix-docker-ansible-deploy and similar projects take care of managing the TURN server in addition to Synapse |
oh a new infrastructure ticket. One option would be to do this properly and have turn running in a different container along side docker? To save it being installed everywhere. Easy to set up via docker-compose, via a one liner though... What does everyone think? id rather this was a separate image that synapse could talk to, but then that would need another image + tag on dockerhub so its updated when synapse is, otoh, theyd share a base image so delta wouldn't need to be huge. |
What about having running both in the same container? Yes, it’s a hack, but it is also super easy to implement. |
We can run them as separate users if privilege separation is desired (which it is). |
Still requires manual effort on the administrator’s part. I want TURN to just work out of the box in the default install, with a warning stating that Synapse does not need (and should not have) a privileged network position. Without a TURN server, Synapse can’t provide a significant part of its feature set. To me, the TURN server is really an integral part of Synapse, rather than a separate service, even though it runs in a separate process. The easiest way to do that is for Synapse to fork and exec coturn itself. |
A reasonable default for TURN servers could be https://www.metered.ca/tools/openrelay/ . A self-hosted is arguably better, but at least this provides a non-Google default. |
@OdyX That is awesome!!!!! |
Anybody already made www.metered.ca work on their synapse? I've been twisitng the params in the homeserver.yaml for quite a while now and did not yet succeed. Could somebody share a working config from their homeserver.yaml ? |
@F-Node-Karlsruhe kindly help share if any success after all with your setup (TURN server at www.metered.ca) ?? |
Also interested to know if anyone got this working, it doesn't seem to work for me when I use the Matrix VoIP Tester site. |
I got i working by spinning up my own TURN eventually. But on another server i alos use the openrelay project like so:
|
If I use those settings then via https://test.voip.librepush.net I get this error:
|
For anyone interested in small usage, the free plan of metered.ca is quite okay for now. 50GB/ per month. My setup
turn:
turn_user_lifetime: "10m"
turn_uris:
- turn:a.relay.metered.ca:80?transport=tcp
- turn:a.relay.metered.ca:443?transport=tcp
turn_username: "YOUR TURNS Server Credentials"
turn_password: "YOUR TURNS Server Credentials" |
Voice and video calls require a TURN server, as STUN is not reliable in practice. There are no public TURN servers that I am aware of, so each homeserver must provide one.
Currently, a TURN server is not installed by default. This means that many homeservers do not have a TURN server running. Those who use these homeservers cannot make voice or video calls if they are behind symmetric NAT or a stateful firewall. Configuring a TURN server requires extra manual effort on the part of the administrator, and the server must be configured carefully to avoid security problems.
To solve this problem, I would like for Synapse to enable TURN by default. Container images would bundle a TURN server, while packages would depend on one. The TURN server will be managed by Synapse, without requiring any manual effort on the part of the administrator. This is similar to how NetworkManager and libvirtd both manage dnsmasq, and how NetworkManager also spawns StrongSwan. For privilege separation reasons, it might be preferable for coturn to be a separate service that Synapse controls. This should be possible on Linux distros that use systemd.
The text was updated successfully, but these errors were encountered: