1. Einleitung

Wenn man einen Videochat-Server selbst hosten will, wird man regelmässig mit Usern konfrontiert, die keine Verbindung bekommen. Das betrifft Nextcloud Talk (basierend auf Spreed) genauso wie Jitsi oder Big Blue Button. VoIP Telefonie (wie z.B. Asterisk) ist ebenfalls problembehaftet. Da die Verbindungsprobleme nicht bei jedem Nutzer auftreten, sondern nur grundsätzlich bei bestimmten, liegt es nahe, dass die Netzwerkkonfiguration eine Rolle spielen muss.

Wir schauen uns hier nur an, woran es liegt, dass Benutzer (Clients) keine Verbindung zustande bekommen. Abgehackte Verbindungen oder sogenannter „Jitter“ (Knackser, kurze Unterbrechungen bis hin zur Unverständlichkeit) sind ein anderer Themenkomplex, auf den ich gelegentlich in einem anderen Post eingehen will.

2. IP Netzwerke, Firewalls und Peer-to-Peer

Bei Videochat (WebRTC) und VoIP gibt es folgende Möglichkeiten der Verbindung:

a) Beide Clients haben eine öffentliche IP und können über diese erreicht werden. Der Browser oder webRTC Client kann diese ermitteln und so eine P2P Verbindung mit der Gegenseite aufbauen. Der Traffic läuft also direkt zwischen den Clients und nicht über den Server. Die initiale Verbindung, das Bekanntmachen, der beiden Clients erfolgt über einen Signaling-Server

b) Ein Client befindet sich in einem Netzwerk hinter einem Router und kann seine externe IP Adresse nicht ermitteln. Dieser Client stellt eine Anfrage dann einen STUN-Server, wie die IP Adresse lautet, von der die Anfrage kam. Mit dieser Information wendet sich der Client dann an den Signaling Server und die Verbindungen werden ausgehandelt.

c) Mindestens ein Client befindet sich hinter einer Firewall, die nur von innen (aus dem privaten Netzwerk des Clients9 aufgebaute Verbindungen zulässt. Hier ist kein P2P möglich. Es ist erforderlich, dass beide oder mehr Clients sich mit einem TURN-Server verbinden. Der Videotraffic geht nun den Weg Client <-> Server <-> Client. Dies ist auf Serverseite sehr traffic-intensiv, funktioniert im Prinzip aber immer.

Um zuverlässig Verbindungen herzustellen, ist es also erforderlich, Signaling Server, STUN Server und TURN Server bereitzustellen.

3. Begriffe

WebRTC
WebRTC ist eine Technologie für Peer to Peer Verbindungen über das Internet. Das bedeutet, im Idealfall gehen Daten von einem Browser zum anderen ohne Server dazwischen. Ursprünglich war das Protokoll für Videochats entwickelt worden. Es funktioniert aber auch mit anderen Datenarten. In allen aktuellen Browsern ist die WebRTC API verfügbar. Es gibt eine Reihe von Javascript-Beispielen, welche die Anwendung zeigen. (Links)

Signaling Server
Ein Signaling Server wird zur Aushandlung einer Verbindung benötigt. Ist die P2P Verbindung hergestellt, wird dieser nicht länger benötigt. Signaling ist nicht Bestandteil des WebRTC Standards, da die Verbindungen auch anders ausgehandelt werden können. In Nextcloud ist ein Signaling Server bereits mit eingebaut.

STUN Server
Ein Stun Server wird benötigt, um die öffentliche IP Adresse per API Aufruf zu ermitteln. Der STUN Server wird ebenfalls nur einmalig zum Aufbau der Verbindung verwendet. Ein STUN Server ist recht lightweight und ohne grossen Ressourcenaufwand zu betreiben. Unter Linux gibt es den Dienst „coturn“, welcher STUN und TURN abwickeln kann.

TURN Server
Der TURN Server wickelt Client <-> Server Kommunikation ab. Prinzipiell kann die gesamte Kommunikation über den TURN Server laufen. Um Traffic zu vermeiden, ist das aber nur die finale Lösung, wenn 2a) und 2b) scheitern. Der Turn Server ist während der gesamten Verbindungsdauer erforderlich.

In Kürze geht es weiter mit der Konfiguration eines TURN Servers und der Einbindung in Nextcloud…