HowTo: Setup Nextcloud Talk with TURN server

Jep this pretty much matches this HowTo. Only thing is I removed lt-cred-mech. See the changelog it OT.

does anyone have a working docker setup (docker run … or docker-compose file) for TURN server and nextcloud?

2 Likes

Hi everyone, I created a new topic for my configuration problem Talk - call and video-call does not work remains black screen

I searched a solutions in the forum but I didn’t find what I need, I ask you for help for any further configuration on my TURN server.

Great, many thanks for this great tutorial! Works like a charm! :slight_smile:

1 Like

Dear all,

I’ve installed the Talk application onto my nextCloud instance and bumped onto some issues, so came here with some troubleshooting questions…

First, a bit of context:

  • Private server from hosting provider, running Debian Stretch, insy=talled nextCloud as a Virtualmin subserver,
  • Two locations: HQ in Paris, R&D in South of France, different ISP

Results are not too bad:

  • Made test between two laptops in R&D (laptop 1: W10, laptop 2: Debian, Firefox on both) = audio + video SUCCESS
  • Made test between two laptops in HQ + R&D (laptop 1: W10, laptop 2: W8, Firefox on both) = audio SUCCESS / video FAIL (black square)

Obviously read all thread you guys pointed at in this thread! :wink:

Now for the questions:

  • Do I need to install coturn 1) to allow internal communication or 2) to allow external people to call in?
  • Do I need to install coturn in its own subserver?
  • Could I use the talk.sh script (as reported by enoch85) to install coturn?
  • Would script break the Virtualmin config?

It’s not clear to me as I tested the default config with the Trickle ICE page and got positive results with turn:stun.mydomain.com:3478?transport=tcp. Is finally the TURN server (probably coturn) already installed on my machine? So why wouldn’t colleagues in HQ get any video stream?

Thanks in advance for any help!

That is it, and also to allow internal people call external ones. AFAIK the direction, which should be only signaling layer, does not play a role.

Nope, you can install it on the same machine where Nextcloud is installed on. A separate server makes sense only if you want to more strictly separate for permissions/security reasons or to devide load for performance reasons.
Another reason to have a separate coTURN server would be in large setups (large number of frequent users) where it is benefitial to have coTURN directly connected to the www and not behind a NAT, while for other reasons you might want to have Nextcloud behind the NAT.

This is the script used on Nextcloud VM, right? I would not use it, but only as an idea what steps are done. However it includes some special steps/paths that are valid for the Nextcloud VM setup only. Follow this HowTo instead, which is valid for all kind of systems.

Which script? The VM one? As said, go through the HowTo steps manually. However coTURN (or any provided steps) do not tangent the remaining server setup/config. It is a standalone program that has no special needs about the underlying system.

Not sure what/how Trickle ICE tests exactly, but I would check on the server itself if coTURN is installed and the related process running. Then run the TURN test on Nextcloud admin panel, as this is what finally needs to work. However the address you posted looks good, although I suggest you use UDP instead of TCP in most cases.

If you assurred coTURN is up and the TURN server test on Nextcloud admin panel succeeds (so is configures correctly as well), I would do some own test from outside the local server network. E.g. try video call from home to HQ (if the coTURN server is located there) and check the logs from coTURN if it actually receives and handles the requests, so that the local network part is assured to be setup correctly. There are cases where network firewalls only allow TLS requests to pass, so then you would need to enable TLS within the coTURN settings.

2 Likes

Hi @Michalng,

Reading your answer back from vacation and wanted to thank you for such detailed content!

I’l then try to install coturn on the server, following the HowTo steps and check from the nextCloud admin… Actually, the admin settings page displays the :stop_sign: icon when checking the (default) turn.mydomain.com server, which probably indicates ther’s no TURN server at all.

Thanks again, back when done!

It just means that Nextcloud cannot access the entered coTURN, which can have different reasons. Check server state on the system, e.g. on Debian/Ubuntu systemctl status coturn, and if it is up, assure that entered domain and port are correct + the port is open/forwarded through NAT.

Hi Michalng,

The command returns “Unit coturn.service could not be found.”, so I think there’s no server at all… Any other check to confirm this?

Thanks for your help!

Seems the HowTo is perfectly detailed: I installed the whole stuff following all steps and… TADA! It works from the same site (text + audio + video) with different browsers on different OS!

Looking forward to running same test between both sites tomorrow!

Thanks to all for your help! I’ll keep you posted and hopefully switch the subject to [SOLVED] soon! :wink:

1 Like


was something I needed to change to get coturn recognizing the certificates correctly.

1 Like

Thanks for providing this info. However note the following:

  • Nextcloud Talk does not support the STURN protocol, hence it does not make use of the configured certificate/encrypted TURN connections.
  • STURN does not provide any practical security benefit since WebRTC itself is encrypted and includes authentication mechanisms already. Also since Nextcloud manages the TURN connections it should be guaranteed that it is your own TURN server used and not a different one. So the only chance where STURN protects against is when the server itself is compromised (signalling level), but then a faked TURN server is likely your smallest problem.
  • The usual method to grant web applications access to private key and certificate is to not grant them direct access to the /etc/letsencrypt/ directory but instead copy key + cert to a different location where only the particular web application (coTURN) has access to, for security reasons. This can be done automatically via renewal hooks, on modern packages there are related directories inside /etc/letsencrypt/ where one can put scripts that contain the copy and chmod/chown tasks.

To ensure your turnserver really is accessible, set its external IP in /etc/turnserver.conf like so:

external-iP=123.45.67.890 # <= replace with your server public IP

Our Talk worked 90% of the time and 10% not, we just got a turning icon for about 10% of the calls. @nickvergessen pointed us to the right direction: our Turn server was configured according to the advice here above, but we needed to add the iP of the turnserver to /etc/turnserver.conf for it to really start working. 90% of the cases were apparently served by Stun and the 10% were those were Turn failed, maybe?

Now it works.

2 Likes

Is your TURN server directly accessible from www or behind a NAT?

If it still doesn’t work, you might need to configure the setting external-ip in /etc/turnserver.conf to your external IP (i.e. outside your NAT) and restart the coturn service.

EDIT: I checked the config file as well: https://github.com/coturn/coturn/blob/master/examples/etc/turnserver.conf
Indeed external-ip needs to be set as in some cases, where the server is behind a NAT. I added this info to the HowTo.

1 Like

Our server is directly exposed to the internet. When configuring, I copy pasted the turnserver.conf template in “Section 3. Configure turnserver.conf for usage with Nextcloud Talk” and changed th listening port. I did indeed not add listening-ip and relay-ip as it seems optional based upon the Howto. Will add these, too.
Thanks for the advice.

Would be interesting if relay-ip + listening-ip alone (without external-ip then) solve your connection issues already. However as long as it works now reliable, no need to tinker.

Probably we need to consult coTURN devs about some more details. Actually I am wondering why those three IP settings cannot be merged into a single one, to set whenever one has a static external IP, for simplicity :thinking:.

Please refer to https://nextcloud-talk.readthedocs.io/en/latest/TURN/ in the future and get manual updated in case something is missing, instead of linking to a thirdparty repo, thanks :slight_smile:

@nickvergessen
Linking/referring from a HowTo to the exact mirror of this HowTo does not make much sense, does it :stuck_out_tongue_winking_eye:? My HowTo and so the manual you linked are both influenced by the still valid spreedbox docs, which both are referring to as well (bottom), so it is not senseless to re-validate info based on this reference. But generally I think we should at best get answers about those *-ip settings from coTURN devs directly and finally remove spreedbox docs from our references.


Okay actually coTURN config file explains things quite good:

  • listening-ip: IP(s) coTURN listens on. Makes sense to leave this unset when behind a NAT, since local clients and remote clients likely call the TURN server via different IPs then. Although both, local and remote IPs can be set, if the remote IP is static.

  • relay-ip: IP(s) coTURN “answers” with, or better clients get answers from, if I got it right. I don’t really get the auto-estimation if this is unset:

    # If no relay IP(s) specified, then the turnserver will apply the default
    # policy: it will decide itself which relay addresses to be used, and it 
    # will always be using the client socket IP address as the relay IP address
    # of the TURN session (if the requested relay address family is the same
    # as the family of the client socket).
    

    However it sounds reasonable still to only set this if no NAT is in front of the TURN server, for the same reason as for listening-ip.

  • external-ip:

    • For Amazon EC2 users:thinking:
    • # TURN Server public/private address mapping, if the server is behind NAT.
    • I don’t get it why this resolved any issue when there is no NAT in front of coTURN.
2 Likes

I played around quite a lot with my coTurn server settings and this is where i currently ended up allowing about 5-6 people to videotalk together from their homes. My server is a V-Server with one Core and 4 GB RAM (so not very powerful). It is hosting only nextcloud, Apache, mysql and letsencrypt.
By the way: the certificates are exact the same as my apache looks at for SSL.

here is my config:

tls-listening-port=444
#5349
listening-ip=<my-ip>
fingerprint
lt-cred-mech
use-auth-secret
static-auth-secret=secret
realm=<myhostname>
total-quota=100
bps-capacity=0
stale-nonce=600
cert=/etc/letsencrypt/live/<mydomain>/cert.pem
pkey=/etc/letsencrypt/live/<mydomain>/privkey.pem
cipher-list=“ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384″
no-loopback-peers
no-multicast-peers
no-tlsv1
no-tlsv1_1
no-stdout-log
log-file=/var/log/coturn.log
syslog

You can btw remove/comment the cert/pkey/cipher. Using TLS with coTURN requires the client to support the TURNS protocol, which Nextcloud Talk does not. Even if you use the tls-listening-port, coTURN handles it internally as plain connection, so which port is used (either of the possible 4) has no practical meaning.

Just to not have a wrong impression :wink:. Ready the changelog of the HowTo for details.