thx. i’ll give it a try
I’m using Nextcloud on FreeNAS…
How can I setup TURN server for Nextcloud Talk ?
Read the documentation : https://nextcloud-talk.readthedocs.io/en/latest/TURN/
Falls jemand Hilfe beim Setup eines Trun Servers braucht oder jemand einen Turn Server bekommen möchte kann sich gerne melden.
Hi, I realize that this thread is old, but it happens that I have seen lately the warning “maybe you need a TURN server”, and I saw this…
So, both my nextcloud server and future turn server are/will be running behind a router, so NAT. As far as I understood, I will need to forward both ports 3478 (listening port) and 3479 (alternative listening port, mentioned in above in the post by @Lars_M ). But the configuration file also mentions
# Lower and upper bounds of the UDP relay endpoints:
with default values as
Do I need to forward these ports as well?
The thread is old but still valid, as I update it regularly. However it has been ported to the official docs, just for completion: https://nextcloud-talk.readthedocs.io/en/latest/TURN/
Nextcloud Talk uses just a single port, hence the alternative listening port should not be required to be forwarded. You can, to comply with RFCs and other clients which might use it, but Nextcloud Talk has no fallback mechanism I am aware of. However I found the mentioned post and indeed Lars forwarded the default alt-listening-port . I never needed to, but would be good to know if you can verify that it works only with both ports forwarded in your case, then we’d need to further check why and add it to the HowTo + docs.
These are not used for inbound connections, so they don’t need to be forwarded. Signalling is done via Nextcloud (HTTP/HTTPS) and in case relaying done via TURN as a separate request, hence those need to be forwarded. After the connection is established, WebRTC does not require additional inbound connections. Remember that it is done as P2P connection between only “client” peers usually, which usually have no ports forwarded at all.
Das nehme ich doch mal gern in Anspruch. Habe eine Konfig mit NAT (Fritzbox) und Docker Images, wo ich das Audio / Video (ausser im LAN) nicht zum Laufen bekomme. Alles andere in NC funktioniert …
siehe auch hier:
Dynamische IP? Port in FB weitergeleitet? Coturn installiert?
a) Statische IP
b) Weiterleitung FB eingerichtet
c) Coturn installiert
und auch noch d) Nextcloud Talk Einstellungstest URL;secret;TCP funktioniert und wird im coturn Log protokolliert.
Oh sorry, dachte eins davon würde mir einen Hinweis geben wo anzusetzen, leider kann ich nicht weiterhelfen, keine Idee.
Thank you for clarification. So in theory I should only need to forward 3478. Unfortunately I can’t do the testing of one port vs two ports as my problem was solved by client’s browser change (he used to use Firefox, it used to work fine, and yesterday he had a problem, he tried Chrome and it worked…) I know, the possible need for TURN should only depend on how he is connected to WAN and not on his browser, but this did actually happen…
I’d kindly like to remind you that this is an international forum where we agreed to use the English language for communication.
So please don’t capture an english thread and answer in your native language (you could do that in the referring subforum)… this would be considered as highly impolite. And - remember - we do want to treat each other here polite and friendly
Thanks for your understanding.
FWIW, in case anyone happens to be interested in an alternative to Coturn: eturnal should be compatible with Nextcloud Talk as well.
great what are the benefits over coturn ?
eturnal doesn’t really offer notable features above Coturn (yet). Quite the opposite: While Coturn implements all features under the sun (including lots of old cruft that’s no longer in use), eturnal is a minimalistic server that implements just those that are actually used by apps such as Talk. So it might be (even) more straightforward to set up, esp. on distributions that don’t offer a Coturn package (there’s no dependencies, you basically just extract the binary tarball, configure the shared secret, and start the systemd service). And as it’s written in Erlang, it avoids a class of security-related issues Coturn ran into again just recently.
That said, I think Coturn is totally fine for most users
Many thanks for sharing. I was always wondering if there were any other TURN servers, but didn’t find any so far .
Yes while Coturn should be generally fine, it good to have alternatives also in terms of competitive or simply for simpler use cases.
Binaries are btw only available for x86_64 systems, while ARM users need to compile themselves, as long as there is no 3rd party or distro repo providing such.
… ah it’s actively coded by you in person and just three days released. ProcessOne/ejabberd to give some association. Lets see if this is something to replace Coturn in our DietPi Nextcloud Talk integration where we aim to go lightweight where possible. I would need to build binaries + dpkg/deb packages for armv6hf (RPi) armv7hf and arm64 and would simply create those for x64_64 as well. Might be nice for others as well to give it a (quicker) try, when not being to experienced with source builds.
Cool! If you decide to look into it and stumble over anything, feel free to ping me by email (email@example.com). I was thinking about offering ARM binaries myself, but have no system for building those and am still unsure whether I want to go for cross-compiling.
Just wanted to inform you about this:
Because Nextcloud use PHP, I had hoped someone writes a TURN server in PHP so every Nextcloud Installation could use it.
After update to Ubuntu 20.04 and Nexcloud 20.0.1 i got an ICE server Error. No working ICE candidat
Under Ubuntu 19.04 and Nextcloud 18 and 19.x it works very well.