Informationen zu STUN/TURN

Im Folgenden wird kurz beschrieben, was ein STUN-/TURN-Dienst macht und welche Probleme er bei Audio/Video bzw. Softphone Kommunikation zwischen zwei Clients beseitigt. Anschließend 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 außen 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. 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 außerhalb 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 implementiert, 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 muss dabei über einen eigenen Dienst erfolgen, einen sog. "Signaling Server". Dieser Dienst muss von beiden Clients erreichbar sein.

Das Zusammenstellen einer ICE Informationen, sog. ICE Kandidaten, erfolgt durch beide Clients. Dazu sammeln beide die verschiedenen Kandidaten (mögliche Protokolle und dazugehörende IP-Adressen mit Ports) aus ihrem LAN heraus ein. Die beiden Clients tauschen diese Kandidaten anschließend über die Signaling Server aus und versuchen daraufhin den jeweils anderen mit Hilfe des passendsten 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. 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).

Beispiele STUN und STUN/TURN

Beispiel-Abbildung: Erfolgreiche Kommunikation unter Zuhilfenahme eines STUN-Servers

Beispiel-Abbildung: Erfolgreiche Kommunikation unter Zuhilfenahme eines STUN-/TURN-Servers

Anwendungsfälle STUN/TURN Dienste 

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, muss 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.

Beispiel-Abbildung 1: Client A ist direkt erreichbar. Client B kann den Medienstrom direkt an Client A senden.

Diese Abbildung 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.

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

Beispiel-Abbildung: Erfolgloser Verbindungsaufbau über einen NAT-Router hinweg

Das Nichterreichbarkeitsproblem kann mit Hilfe eines STUN-Servers gelöst werden. 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.

Beispiel-Abbildung: Erfolgreiche Kommunikation unter Zuhilfenahme eines STUN-Servers

Mindestens ein Client kann von außen 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 außen. 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.

Beispiel-Abbildung: Erfolgloser Kommunikationsversuch ü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 nachfolgende Abbildung). 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.

Beispiel-Abbildung: Erfolgreicher Kommunikationsversuch über ein "Symmetric NAT" durch Nutzung eines 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.

Weiterführende Informationen

Wissenswertes zu STUN/TURN für die Nutzung von Audio/Video und Softphone bei ProCall Enterprise

Wissenswertes zu STUN/TURN für die Nutzung von Audio/Video und Softphone bei ProCall Enterprise

Wissenswertes zu STUN/TURN für die Nutzung von Audio/Video und Softphone bei ProCall Enterprise