HowTo: Setup Nextcloud Talk with TURN server

šŸ“‘ How to
1

Background

The configuration of Nextcloud Talk mainly depends on your desired usage:

  • As long as it shall be used only within one local network, nothing should be needed at all. Just verify that all browsers support the underlying WebRTC protocol (all famous ones do on current versions) and you should be good to go.
  • Talk tries to establish a direct peer-to-peer (P2P) connection, thus on connections throughout the local network (behind a NAT/router), clients do not only need to know each others public IP, but their local IP as well. Processing this, is the job of a STUN server. As there is one preconfigured for Nextcloud Talk, still nothing need to be done.
  • In some cases, e.g. in combination with firewalls or symmetric NAT a STUN server will not work as well, and then a so called TURN server is needed. Now no direct P2P connection is established, but all traffic is relayed through the TURN server, thus additional (at least internal) traffic and resources are needed.
  • Nextcloud Talk will try direct P2P in the first place, use STUN if needed and TURN as last resort fallback. Thus to be most flexible and guarantee functionality of your Nextcloud Talk instance in all possible connection cases, you most properly want to setup a TURN server.

Install and setup coTURN as TURN server

  1. Download/install

    • On Debian and Ubuntu there are official repository packages available:
      sudo apt install coturn
    • For Fedora, an official package it is planned, as far as I can see. For this and other cases check out: Downloads Ā· coturn/coturn Wiki Ā· GitHub

  2. Make coTURN run as daemon on startup

    • On Debian and Ubuntu you just need to enable the deployed init.d service by adjusting the related environment variable:
      • sudo sed -i '/TURNSERVER_ENABLED/c\TURNSERVER_ENABLED=1' /etc/default/coturn
    • On Debian Buster the most current package update implements a systemd unit, which does not use /etc/default/coturn but is enabled automatically after install. To check whether a systemd unit is available:
      • ls -l /lib/systemd/system/coturn.service
    • On other OS/distributions, if you installed coturn manually, you may want to setup an init.d/systemd unit or use another method to run the following during boot:
      • /path/to/turnserver -c /path/to/turnserver.conf -o
      • -o starts the server in daemon mode, -c defines the path to the config file.

  3. Configure turnserver.conf for usage with Nextcloud Talk
    At last you need to adjust the TURN servers configuration file to work with Nextcloud Talk. On Debian and Ubuntu, it can be found at /etc/turnserver.conf.

    • Uncomment/adjust the following settings. Choose the listening port (default is 3478) and an authentication secret, where a random hex is recommended: openssl rand -hex 32:

      listening-port=<yourChosenPortNumber>
fingerprint
use-auth-secret
static-auth-secret=<yourChosen/GeneratedSecret>
realm=your.domain.org
total-quota=100
bps-capacity=0
stale-nonce
no-multicast-peers
    • (D)TLS is now supported by Nextcloud Talk but does not have any real security benefit. For more details see the changelog below.If you need to use TLS for your firewall, provide the path to your certificate and key files: 
      tls-listening-port=<yourChosenPortNumber>
cert=/path/to/your/cert.pem
pkey=/path/to/your/privkey.pem

      Note that in case of TLS you only need to set tls-listening-port, otherwise only listening-port. Nextcloud Talk uses a single port only, thus the alternative ports offered by the settings file can be ignored.

      For additional security, you can also configure the cipher list, a custom Diffie-Hellman file and/or disable TLSv1.0 + TLSv1.1. But again, it does not make much sense for my impression to handle it different here than for Nextcloud itself. Just decide how much compatibility you need and security/performance you want and configure webserver + coturn the same:

      cipfer-list="..."
dh-file=/path/to/your/dhparams.pem
no-tlsv1
no-tlsv1_1

    • If your TURN server is running not behind a NAT, but with direct www connection and static public IP, than you can limit the IPs it listens and answers by setting those as listening-ip and relay-ip. On larger deployments it is recommended to run your TURN server on a dedicated machine that is directly accessible from the internet.

    • If your TURN server is behind a NAT, instead in some cases you need to set external-ip to your public/external IP (i.e. outside your NAT). This of course only makes sense if you have a static IP instead of a dynamic one.

    • The following settings can be used to adjust the logging behaviour. On SBCs with SDcards you may want to adjust this, as by default coturn logs veeery much :wink:. The config file explains everything very well:

      no-stdout-log
log-file=...
syslog
simple-log

  4. sudo systemctl restart coturn or corresponding restart method

  5. Configure Nextcloud Talk to use your TURN server
    Go to Nextcloud admin panel > Talk settings. Btw. if you already have your own TURN server, you can and may want to use it as STUN server as well:

    STUN servers: your.domain.org:<yourChosenPortNumber>
TURN server: your.domain.org:<yourChosenPortNumber>
TURN secret: <yourChosen/GeneratedSecret>
UDP and TCP

    Do not add http(s):// here, this causes errors, the protocol is simply a different one. Also turn: or something as prefix is not needed. Just enter the bare domain:port.

  6. Port opening/forwarding
    The TURN server on <yourChosenPortNumber> needs to be available for all Talk participants, so you need to open it to the web and if your TURN server is running behind a NAT, forward it to the related machine.

What else

Nextcloud Talk is still based on the Spreed video calls app (just got renamed) and thus the Spreed.ME WebRTC solution. For this reason all guides about how to configure coturn for one of them, applies to all of them.

Further reference

Thanks to @fancycode and @mario for some clarifications about all of this and if you donā€™t mind, please review the HowTo for possible mistakes or wrong understandings.
Thanks as well to @sushidave for motivating me to write this HowTo :slightly_smiling_face:.

ADMIN EDIT

If you need to use Talk with more than 5-10 users, you will need the Spreed High Performance Back-end from Nextcloud GmbH, see Talk - Nextcloud for more info

Changelog

  • Removed old lt-cred-mech and no-loopback-peers settings entirely, updated TLS hints, as it is now supported by Nextcloud Talk, but removed very old cipher-list example.

  • (D)TLS is currently not supported by Nextcloud Talk and does not have any real security benefit anyway:

  • lt-cred-mech is required for use-auth-secret for coTURN versions below 4.5.0.8 but causes a conflict warning and should be removed on coTURN 4.5.0.8 or higher: Update the example config file: use-auth-secret overrides lt-cred-mech. Ā· coturn/coturn@84a875b Ā· GitHub

    Related log entries:

    Jan 19 23:08:20 my.domain.org turnserver[6712]: CONFIGURATION ALERT: You specified --lt-cred-mech and --use-auth-secret in the same time.
Jan 19 23:08:20 my.domain.org turnserver[6712]: Be aware that you could not mix the username/password and the shared secret based auth methohds.
Jan 19 23:08:20 my.domain.org turnserver[6712]: Shared secret overrides username/password based auth method. Check your configuration!

    Related config file comments:

    # Be aware that use-auth-secret overrides some part of lt-cred-mech.
# Notice that this feature depends internally on lt-cred-mech, so if you set
# use-auth-secret then it enables internally automatically lt-cred-mech option
# like if you enable both.
#
# You can use only one of the to auth mechanisms in the same time because,
# both mechanism use the username and password validation in different way.
#
# This way be aware that you can't use both auth mechanisms in the same time!
# Use in config either the lt-cred-mech or the use-auth-secret
# to avoid any confusion.

  • no-loopback-peers has been deprecated with coTURN v4.5.1.0 and replaced with allow-loopback-peers: Change loopback defaults Ā· coturn/coturn@8a60754 Ā· GitHub

    Related config file comment:

    # (To avoid any security issue that allowing loopback access may raise,
# the no-loopback-peers option is replaced by allow-loopback-peers.)
#
# Allow it only for testing in a development environment! 
# In production it adds a possible security vulnerability, so for security reasons 
# it is not allowed using it together with empty cli-password.
26 Likes
2

You are awesome. Would you be open to turning this into a Markdown file and submit it as PR to the Talk Android repo?

2 Likes
3

Jep, I can do that. Just checked, where exactly to send PR to, just a raw TURN.md/COTURN.md file in root or as wiki page (somehow when I try to open the wiki, I get redirected to main page again)?

4

Create a folder ā€œdocsā€ in root and put a raw TURN.md there? :slight_smile:

5

Thanks to great guides here or the references made to them Iā€™ve got TALK working with TLS and Nextcloud and TURN server behind the same NAT. Using default Nextcloud STUN server for now. Android Talk to Android Talk and Android Talk to browser and back goes fine. However it refuses to work for browser to browser communications when both PCs are behind different NATs. Unlikely DPI is blocking things as both testing instances are beyond common Western ISPs, and no symmetric firewalls or so.

Have ploughed through the logs but it is a lot to take on and I couldnā€™t do much else than a lot of trial and error of random things, but still unsuccessful. I noticed that you advise UDP and TCP to use with TURN server config in Nextcloud where others say it should be UDP only. Any comment on that? Will try anyway.

Anyone came across this use case and like to share how they managed to solve it?
E.g. does the TURN server need to be on public internet for this use case? It is just for testing with <10 users.

6

Bump

Anyone thoughts on UDP only vs TCP and UDP use?
With a working TALK, TURN and STUN server still wondering why I canā€™t get 2 different WebRTC PCs behind a different NAT via the open network to work. Hoping for any tips, consideration in this context. Thanks.

7

Ah yeah indeed there is still a gap with this protocol topic:

  • I remember Spreed.ME with spreed-webrtc-server used just UDP by default as protocol. Otherwise some guides around here suggested to add (UDP + TCP) as well.
  • Generally as far as I know (superficially) UDP has some performance benefits where TCP is better for stability. I remember back in that time, that just using TCP was a solution attempt for unstable connections: [Spreed.ME] Unreliable long distance connection buildup via TURN server
  • I am not sure, if both are given, how Talk decides which protocol to use, but yeah in case just try, if UDP or TCP only makes some difference for you.

Generally in my cases all kind of connections I can try here (also laptop -> laptop over www) work fine now, but as you can see I also had issues with Spreed.ME as well as spreed video calls later, which I was not able to solve :slightly_frowning_face:.

Now that I read this, I see that I forgot to add the hint, that of course the chosen TURN port needs to be forwarded from the router in case :wink:.

1 Like
8

Thanks for your reply. The turn server has been forwarded on the router, figured that one early on.
And after that about a week ago I read every post vaguely related to this topic including yours. It is good to hear that you can confirm getting it to work in general, so it should be able to work at least. Will keep on testing.

9

Just letting you all know, that adding UDP and TCP fixed the issue with the PC ot PC connections as reported above. Next mission is to get it to work behind corporate firewalls. Will report if nay success, not expecting for a while though.

10

@MichaIng Hey, can I do anything to help you with creating a PR? :slight_smile:

11

@mario
Sorry for it taking a while. Was too busy the last week :slightly_smiling_face:. PR is up: https://github.com/nextcloud/talk-android/pull/169

12

Thanks for this howto. After opening port 3479 it works for me.

2 Likes
13

Jep, I made it clearer in step 6 that you need to open the chosen port to the web, which means forwarding it, if the server is behind a NAT.

1 Like
14

Is it possible to add an notification when anyone join an public chat and the Android App is in the Background?

15

But why in the Talk App for Android repo instead of the Nextcloud Talk (still called ā€œspreedā€) repo? I think this belongs to the server app and not the client app where it is a bit confusing/difficult to find actually.

16

Jep indeed, this should be (as well) added to the server app repo.

I will add a PR to put this guide into their GitHub wiki and/or a related hint to the README.md.

On the other hand I am just thinking that, if the full text is added to forum, Android app and server app repo, perhaps docs.nextcloud.com any time later, it is a mess to keep it up-to-date. Better have it in one place, where all suggestions/corrections/updates are added and then just link to it?
@mario what you think?

17

Docs are the best place to have it.

18

I think it should stay with the repo of the Nextcloud app. Almost any other app has its further configuration information in its repository and referenced/included into the Readme. The information is pretty pointless in the Android app repo because it is required for the server part, not the client apps.

1 Like
19

Just a simple question, and do not take this as negative, I adore NextCloud and use it with pleasure on a hosted VM, works very well, also with my Windows clients
Now that I tried Talk to get privacy as opposed to Skype & Co I am wondering why the setup for out of local LAN comms is so difficult. I get it that a STUN server is needed for NAT situations (which at least in simple forms are basically everywhere).
Just if I compare the solutions I fail to understand why e.g. Skype can easily do things which Talk cannot. Both seem to establish a P2P connection as the first choice. In my scenario with a MAC at my sonā€™s place in Germany and my Windows PC in France (both behind simple NAT boxes) I would assume that making Talk work should only be a matter of allowing the relevant processes access through the client based firewall and maybe forwarding some ports by the boxes. Could someone possibly shed light on this, or explain why Talk would definitively need a TURN server to work under my scenario.

Thanks in advance, looking forward to any helpful infoā€¦

20

Iā€™ll let others respond, but Skype has two modes of operations, none of which is REALLY peer-to-peer.

In first mode of operation (more common in the earlier days) they used computers of other users (and their supernodes) in order to route your calls so they could evade NAT, Firewalls, and others.

In recent days, those ā€œsupernodesā€ are more often used compared to every other connection options available to them.

So to summarize - while TURN is quite easy to setup, Nextcloud Talk is a self-hosted solution so itā€™ll always be a bit harder to setup than other solutions. That however applies only to the admin - for me as a user, even now in its beginnings, Nextcloud Talk works better than say Skype.

1 Like