Das ist alles nur dann nötig wenn deine Nextcloud Instanz oder einer der Talk Teilnehmer hinter einem NAT sitzt, es also einen Router und ein internes Netzwerk gibt mit internen IP Adressen. STUN transportiert die NAT internen IP Adressen, so dass das WebRTC Protokoll die Daten in beide Richtungen an die richtigen Empfänger (hinter den NAT) weiterleiten kann. Bei symmetrischem NAT o.Ä. (ich habe auch nicht ganz die technischen Details dahinter verstanden), reicht das STUN allerdings nicht aus. Dann muss ein TURN Server her. Alle Clients senden und empfangen Daten dann über den TURN Server, welcher die richtigen Zuordnungen für das WebRTC Protokoll garantiert.
coTURN installation variiert wie immer je nach Distribution, aber mein HowTo sollte helfen: HowTo: Setup Nextcloud Talk with TURN server
EDIT:
### Background
The configuration of Nextcloud Talk mainly depends on your desired usage:
- As long as it shall be used only **within one local network**, besides the app, nothing else should be required. Just verify that all browsers support the underlying [WebRTC](https://en.wikipedia.org/wiki/WebRTC) protocol - all famous ones do on current versions - and you should be good to go. Browser support can be tested e.g. here: [https://test.webrtc.org/](https://test.webrtc.org/)
- Talk tries to establish a direct [peer-to-peer (P2P)](https://en.wikipedia.org/wiki/Peer-to-peer) connection, thus on connections **beyond the local network** (behind a [NAT](https://en.wikipedia.org/wiki/Network_address_translation) or router), clients do not only need to know each others public IP, but the participants local IPs as well. Processing this, is the job of a [STUN](https://en.wikipedia.org/wiki/STUN) server. As there is one preconfigured for Nextcloud Talk, still nothing else needs to be done.
- But in many cases, e.g. **in combination with firewalls or [symmetric NAT](https://en.wikipedia.org/wiki/Network_address_translation#Symmetric_NAT)**, a STUN server will not work as well, and then a so called [TURN](https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT) server is required. 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 used.
- 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 and install
- On **Debian and Ubuntu** there are official repository packages available:
```
sudo apt install coturn
```
- For many **other Linux derivatives and UNIX-likes** packages can be found on [https://pkgs.org/download/coturn](https://pkgs.org/download/coturn)
show original
### 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](https://en.wikipedia.org/wiki/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)](https://en.wikipedia.org/wiki/Peer-to-peer) connection, thus on connections **throughout the local network** (behind a [NAT](https://en.wikipedia.org/wiki/Network_address_translation)/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](https://en.wikipedia.org/wiki/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](https://en.wikipedia.org/wiki/Network_address_translation#Symmetric_NAT)** a STUN server will not work as well, and then a so called [TURN](https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT) 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 **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`
show original