Funktionsweise

Der estos STUN/TURN Server ist als Systemdienst implementiert, welcher die STUN- und TURN-Server Funktionalität zur Verfügung stellt.

Im Folgenden wird kurz beschrieben was ein STUN-/TURN-Dienst macht und welche Probleme er bei der Audio/Video Kommunikation zwischen zwei Clients beseitigt. Anschliessend werden noch die Hauptanwendungsfälle aufgezeichnet.

Diese Beschreibung soll dazu dienen ein grundlegendes Verständnis für die Thematik zu vermitteln und geht nicht auf genauere Details ein.

Beteiligte Komponenten und Begriffe

NAT - Network Address Translation (RFC 2663)
NAT beschreibt die Umsetzung des "internen" IPv4-Adressraums eines LAN zu "externen" IPv4-Adressen (und Ports) im Internet. Das trägt zur Sicherheit des internen Netzes bei, da von aussen kein direkter, ungewünschter Zugriff auf interne Adressen erfolgen kann.

Ein NAT Device ist z.B. ein Router, der ein LAN mit dem Internet verbindet.

Symmetric NAT
Zusätzlich zum normalen NAT merken sich diese Router nicht nur die interne Client Adresse, sondern auch die von ihm angesprochene Zieladresse und lässt Daten nur von dieser in das interne Netz gelangen. Ein anderes Ziel kann also keine Daten an den internen Client senden, selbst wenn die IP-Adressen (und Ports) bekannt wären. Für eine Audio/Video Kommunikation ist in diesem Fall nur in Verbindung mit einem TURN-Server möglich.

NAT Traversal
"NAT Traversal" bezeichnet Techniken zum Aufbau und Halten von Verbindungen über NAT-Umsetzungsstellen hinweg. Zu diesen Techniken gehören STUN und TURN.

STUN - Session Traversal Utilities for NAT (RFC5389)
Dieses Protokoll ermöglicht es einem Client in einem LAN, seine eigene, öffentliche IPv4-Adresse zu ermitteln.

Der rufende Client im LAN kann auf diese Weise dem angerufenen Client ausserhalb des LAN mitteilen, welche IPv4-Adresse (und Portnummer) verwendet werden kann um eine direkte Kommunikation mit ihm zu ermöglichen ("Peer-to-Peer" Verbindung).

TURN - Traversal Using Relays around NAT (RFC5766)
Ein Server im Internet, der das TURN-Protokoll imlplementiert, ermöglicht es zwei Clients, Daten ohne eine direkte Verbindung auszutauschen ("Relay Server"). Dies wird notwendig, wenn es keine Möglichkeit gibt eine direkte Client zu Client Verbindung aufzubauen.

ICE - Interactive Connectivity Establishment (RFC5245)
Zwei Clients können die mit Hilfe von STUN und TURN ermittelten Verbindungsinformationen (und andere Daten) mit Hilfe des ICE Protokolls austauschen. Die Übermittlung der Informationen muß dabei über einen eigenen Dienst erfolgen, einen sog. "Signaling Server". Dieser Dienst muß von beiden Clients erreichbar sein.

Das Zusammenstellen einer ICE Informationen, sog. ICE Kandidaten, erfolgt durch beide Clients. Dazu sammeln beide die verschiedene Kandidaten (mögliche Protokolle und dazugehörende IP-Adressen mit Ports) aus ihrem LAN heraus ein. Die beiden Clients tauschen diese Kandidaten anschliessend über die Signaling Server aus und versuchen daraufhin den jeweils anderen mit Hilfe des passensten Kandidaten zu erreichen.

Signaling Server
Signaling Server dienen zum indirekten Austausch von Daten zwischen zwei Clients. Dies kann ein Dienst sein, der von beiden Clients erreichbar ist (z.B. ein UCServer in einem Netzwerk) oder auch mehrere Dienste die mittels Federation miteinander verbunden sind (z.B. zwei UCServer zweier Firmen, die eine XMPP Federation eingegangen sind).

Anwendungsfälle

Im Folgenden werden die Hauptanwendungsfälle der STUN/TURN-Dienste etwas ausführlicher gezeigt.

Direkte Kommunikation ist möglich (kein STUN/TURN-Dienst notwendig)

Damit Client A die Medienströme von Client B empfangen kann, muß Client A zunächst Client B seine Kontaktdaten (IP-Adresse und Port) mitteilen. Dies geschieht in der Regel über einen Signaling-Server, zu dem beide Clients eine Verbindung haben. Solange sich beide Clients im gleichen LAN befinden ist dies problemlos möglich. Abb. 1 verdeutlicht dies. In Schritt 1 sendet Client A seine IP-Adresse und Port über den Signaling Server an Client B. Daraufhin kann Client B in Schritt 2 damit beginnen einen Medienstrom an Client A zu senden.

Abb. 1: Client A ist direkt erreichbar. Client B kann den Medienstrom direkt an Client A senden.

Ein Client befindet sich hinter einem NAT-Router

Befinden sich Client A und Client B in verschiedenen LANs, die durch einen NAT-Router getrennt sind, wird das obige Szenario fehlschlagen. Da Client A nicht weiß, dass er gegenüber Client B mit der öffentlichen IP-Adresse und Port des NAT-Routers erscheint, würde Client A in Schritt 1 seine lokale IP-Adresse und Port an Client B signalisieren. Da diese Adresse aber für Client B nicht erreichbar ist, schlägt das senden des Medienstroms (Schritt 2) fehl (siehe Abb. 2).

Abb. 2: Erfolgloser Verbindungsaufbau über einen NAT-Router hinweg.

Das Nichterreichbarkeitsproblem kann mit Hilfe eines STUN-Servers gelöst werden wie in Abb. 3 dargestellt. Mit Hilfe des STUN-Servers kann Client A in Schritt 1 seine öffentliche IP-Adresse und Port ermitteln. Diese kann er dann in Schritt 2 an Client B übermitteln woraufhin dieser seinen Medienstrom an die öffentlich erreichbare Adresse des NAT-Routers senden kann. Der NAT-Router leitet den Medienstrom dann an Client A weiter.

Abb. 3: Erfolgreiche Kommunikation unter Zuhilfenahme eines STUN-Servers.

Mindestens ein Client kann von aussen gar nicht erreicht werden (Symmetric NAT-Router)

Die vorherige Lösung funktioniert allerdings nicht für alle NAT Ausprägungen. Es gibt eine Klasse von NATs, die sog. "Symmetric NAT", die nicht nur einen öffentlichen Port für einen LAN Client A öffnen, sondern für auch jede einzelne Verbindung nach aussen. Das hat zur Folge, dass Client A zwar nach wie vor seine öffentliche IP-Adresse/Port vom STUN-Server abfragen kann, diese wären dann aber für Verbindungen mit Client B nicht gültig.

Abb. 4: Erfolgloser Kommuniaktionsversuch über ein "Symmetric NAT".

Da der korrekte öffentliche Port über den STUN-Server nicht ermittelt werden kann, schlägt das Senden eines Medienstroms von Client B fehl.

Um dieses Problem mit dem "Symmetric NAT" zu lösen, benötigt man einen TURN-Server (siehe Abb. 5). Sobald Client A feststellt, dass direkte und STUN Verbindungen nicht möglich sind (Schritt 1), kann er Client B über den Signaling-Server mitteilen, dass er eine Verbindung zu einen gemeinsam bekannten TURN-Server (Schritt 2) aufbauen soll. In Schritt 3 haben beide Clients eine Verbindung zum TURN Server und können darüber nun Daten austauschen.

Abb. 5: Erfolgloser Kommuniaktionsversuch über ein "Symmetric NAT" durch Nutzung ienes TURN-Servers.

Da die Nutzdaten bei dieser Lösung direkt über den TURN-Server fließen hat ein TURN-Server insbesondere bei mehreren parallelen Verbindungen sehr hohe Anforderungen an die Bandbreite zu erfüllen. Deshalb wird diese Lösung nur dann gewählt, wenn es keine andere Möglichkeit für eine Datenübertragung gibt.

Version 6.0