HowTo: Setup Nextcloud Talk with TURN server


#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: https://github.com/coturn/coturn/wiki/Downloads
  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 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. The configuration depends on if you want to use TLS for secure connection or not. You may want to start without TLS for testing and then switch, if everything is working fine:

    • Without TLS uncomment/adjust the following settings. Choose the listening port, e.g. 3478 (which is default value, for TLS default is 5349) and an authentication secret, where a random hex is recommended: openssl rand -hex 32:

      listening-port=<yourChosenPortNumber>
      fingerprint
      lt-cred-mech
      use-auth-secret
      static-auth-secret=<yourChosen/GeneratedSecret>
      realm=your.domain.org
      total-quota=100
      bps-capacity=0
      stale-nonce
      no-loopback-peers
      no-multicast-peers
      
    • With TLS you need to provide the path to your certificate and key files as well and it is highly recommended to adjust the cipher list:

      tls-listening-port=<yourChosenPortNumber>
      fingerprint
      lt-cred-mech
      use-auth-secret
      static-auth-secret=<yourChosen/GeneratedSecret>
      realm=your.domain.org
      total-quota=100
      bps-capacity=0
      stale-nonce
      cert=/path/to/your/cert.pem
      pkey=/path/to/your/privkey.pem
      cipher-list="ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5"
      no-loopback-peers
      no-multicast-peers
      

      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.

      I added a working cipher example here that is also used within most other guides. But it makes totally sense to use the cipher-list from your Nextcloud webserver to have the same compatibility versus security versus performance for both.

      If you want it damn secure, you can also configure 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:

      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.

    • 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 on last major update) 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.

Futher 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 https://nextcloud.com/talk for more info


Nextcloud Talk documentation?
Talk do not show video and no sound
TALK with STUN/TURN: PORT etc. questions, for my understanding
How-to/FAQ WIKI
E-MAIL Server und talk Verbindungsaufbau langsam
Nextcloud Talk - Black screens, STUN/TURN setup and other failures
About the Talk category
Setting up firewall for TURN server
How to integrate TURN server with Nextcloud
TURN server for Nextcloud Talk
Unable to get video and audio using TURN server
Ongoing video calls freeze up after a while
#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?


#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:.


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


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


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


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