ICE, Kandidaten, STUN und TURN

Beachte dazu auch MRAS Edge

VoIP funktioniert derart, dass per SIP über bekannte Kanäle eine Kommunikation stattfindet. Hierbei gibt es Leitwege, Anmeldedaten, Authentifizierungen, Zertifikate, SIP-Adressen etc. Aber neben dem Weg der Signalisierung müssen natürlich auch Mediadaten übertragen werden. SIP hat damit nur insofern etwas zu tun, dass ein SIP-Paket als Nutzlast ein SDP-Paket hat, welches seinerseits wieder die Information trägt, welche Codec der Absender versteht und unter welchen IP-Adressen dieser erreichbar ist.

Ideal ist, wenn die Audio/Video-Daten natürlich direkt zwischen den beiden Endpunkten oder den Endpunkten und einer Konferenzunit (MCU), oder einem Endpunkt und einem Gateway zu Telefonwelt ausgetauscht werden. In einem internen transparenten und gerouteten Netzwerk ist das aber ganz einfach möglich. Zumindest wenn keine Firewalls dazwischen sind.

SIP und VoIP sind aber nicht auf interne LANs beschränkt, sondern soll natürlich auch und gerade im Internet und hinter Firewalls und anderen Hemmnissen funktionieren. Daher gibt es verschiedene Möglichkeiten, einen Weg zueinander zu finden. Hier exemplarisch ein SDP-Auszug:

Übrigens kann ICE problemlus uach IPv6-Kandidaten enthalten, wie dies in Lync 2013 einfach zu sehen ist

a=x-candidate-ipv6:5 1 UDP 33552383 2001:0:9d38:6ab8:201e:5df:3f57:ff98 5998 typ host
a=x-candidate-ipv6:5 2 UDP 33551870 2001:0:9d38:6ab8:201e:5df:3f57:ff98 5999 typ host
a=x-candidate-ipv6:6 1 UDP 33551871 2002:5042:141c:1000:1955:6bbe:daf:ed0a 24764 typ host
a=x-candidate-ipv6:6 2 UDP 33551358 2002:5042:141c:1000:1955:6bbe:daf:ed0a 24765 typ host

Doch woher kommen all diese Einträge ?. Der Lync Client sammelt diese Einträge für UDP und TCP getrennt ein und man kann an den Kandidaten schön sehen, welcher Typ das ist:

Typ Kandidat Beschreibung
host Direkte IP

Ein SIP-Client sollte auf dem Gerät; auf dem er installiert ist, alle IP-Schnittstellen nutzen können. Entsprechend kann er auch Ports per UDP und TCP öffnen, um Verbindungen anzunehmen und aufzubauen.

Manchmal können diese Kandidaten sehr umfangreich sein, z.B.: wenn ein PC mehrere Netzwerkkarten hat (dazu zählen auch VMWare Virtual Adapter und eventuell VPN-Schnittstellen). Und natürlich können Firewall-Programme und Virenscanner die Funktion beeinträchtigen.
srfix raddr NAT-IP (STUN) Wenn der SIP-Client einen STUN-Server kennt, dann kann er über diesen Hilfsdienst ermitteln, welche externe IP-Adresse er hinter einen NAT-Router für ausgehende Verbindungen bekommt. NAT ist ja keine "Firewall" sondern eine Adressumsetzung und es ist gar nicht mal selten, dass ein Client eine Verbindung nach extern startet und Antworten auch von anderen Systemen möglich sind.
relay raddr Edge-IP (TURN) Wird dem Client zudem noch ein "TURN"-Server mitgegeben, den er als "Relay" nutzen darf, dann kann er sich dort auch noch für kurze Zeit Kandidaten holen, die er mit anbieten darf.

Etwas vereinfacht bekommt ein Lync Client also IP/Port-Kombinationen von den folgenden Stellen:

Natürlich ist es für zwei Systeme am besten, direkt miteinander zu kommunizieren und erst als allerletzte Option einen Relay-Server (TURN) zu nutzen. Aber sie glauben gar nicht wie oft der TURN-Server gar nicht benötigt wird. Denn der Betrieb eines TURN-Servers kostet ja Ressourcen (CPU, Software aber vor allem Bandbreite)

Direkte Adressen

Für den Lync Client ist es einfach, die lokalen Netzwerkschnittstellen aufzuzählen, auf jeder Netzwerkkarte ein paar Sockets zu öffnen und diese den Clients anzubieten.

NAT und STUN

Wenn wir komplexe Firewalls von Firmen einmal außen vor lassen, ist eine Adress/Port-Umsetzung per NAT eine häufig anzutreffende Hürde:

Achtung: NAT ist eine Adressumsetzung aber keine Firewall. Zwar kann ein System von außen per Default nach innen keine Verbindung aufbauen aber wenn der interne Dienst "mithilft", dann ist schon eine direkte Kommunikation zwischen zwei Partnern möglich, von denen einer oder sogar beide hinter NAT-Routern verborgen sind.

Die erste Hürde ist natürlich erst mal "NAT". In der Regel wird keiner eine "offizielle" IP-Adresse haben. Quasi alle DSL-Router verbergen ihre Anwender hinter einer externen offiziellen Adresse. Das ist Durchlauf von Vorteil, weil so von außen erst mal keiner auf ihren PC zugreifen kann, sofern Sie keine Verbindung nach Extern initiiert haben.

Dummerweise verhindert dies natürlich auch erst mal jede direkte Verbindung zwischen den Clients. Wollen zwei Clients, die beide hinter einen NAT-Router sitzen und sich nicht im gleichen Subnetz befinden, miteinander sprechen, kann dass nur über einen Proxy gehen. Beide gehen dann ausgehend per NAT auf einen dritten Server(Das ist dann ein TURN-Server), der die Daten miteinander verbindet. Aber das ist nicht schön, weil der dritte Server betrieben werden muss, Bandbreite braucht und vor allem die Laufzeit der Paket erhöht. Alle drei Dinge will man gerne vermeiden.

Der Trick ist nun der dass NAT-Router ganz und gar nicht "undurchlässig sind. Es gibt nämlich durchaus NAT-Systeme, die eingehende Pakete nicht genau filtern, d.h. obwohl ein Client ein bestimmtes Ziel anspricht, kann dann auch ein anderes Systeme auf diesen Port antworten und der Router leitet die Paket dennoch an den Client zurück. Und wenn das der andere Client weiß, dann kann doch eine direkte Verbindung stattfinden. Man unterscheidet dabei in vier Klassen:

Typ

Full cone NAT

Hat ein Client einen Port extern geöffnet, kann jeder andere Rechner auch darauf antworten

Address Restricted NAT

Nur der Server (IP-Adresse), an den ein Paket gegangen ist, kann auch darauf antworten, auch wenn er mit einem anderen Quellport "reinkommt".

Port Restricted NAT

Der entfernte Server kann auch etwas zurück senden, aber nur wenn er den gleichen Quellport verwendet, auf dem er auch angesprochen wurde.

Symmetic NAT

Der entfernte Server kann auch etwas zurück senden, aber nur wenn er den gleichen Quellport verwendet, auf dem er auch angesprochen wurde. Wenn der Client einen anderen Server von dem gleichen Quellport anspricht, wird extern eine neue Zuordnung erstellt. Ein anderer Server kann also weder senden noch den Port erraten. Sehr sicher und für VoIP ist keine Verbindung ohne TURN-Server möglich.

Dummerweise sind diese NAT-Typen nicht auf jedem Switch gleich und manchmal ändert sogar ein Firmware-Wechsel das Verhalten. Und dann kommt noch uPNP dazu, welches internen Endgeräten es erlauben kann, Ports eingehende freizuschalten.

Für den Einsatz mit VoIP ist eigentlich nur das "Full Cone NAT" interessant, d.h. wenn der interne Client eine Verbindung nach außen öffnet, und damit eine Zuordnung auf dem Router erhält, auf den auch eine andere IP-Adresse etwas zuliefern kann. Nur dann kann eine direkte Verbindung von einem anderen VoIP Client erfolgen. Dabei ist die Entscheidung pro Richtung zu treffen. Es kann also sein, dass Client A per NAT direkt Client B erreichen kann aber umgekehrt die Pakete einen Umweg laufen müssen

STUN

Ist ist also an dem Client heraus zu finden, wie er seine Partner erreichen kann. Dazu muss er natürlich erst mal wissen, welche Adressen und Port er der anderen Seite anbieten kann. Die lokalen Adressen der eigenen Netzwerkkarten kann der Client noch einfach erkennen und einen Port eingehend öffnen um auf Pakete zu warten. Aber die Adressen auf der anderen Seite des Routers kann er nur mit Hilfe ermitteln. Da kommt dann der STUN-Server ins Spiel.

Der Client baut eine Verbindung zu einem bekannten externen STUN-Server auf, der nun seinerseits natürlich die externe IP-Adresse und Port des Clients als eingehende Kombination "sieht". Der NAT-Router hat ja die Kombination aus "ClientIP:Port" auf eine externe öffentliche Adresse:Port umgesetzt. Genau diese Info sendet der STUN-Server wieder an den Client über die bestehende Verbindung zurück.

Stellen Sie sich vor sie haben ein Telefon, dessen Rufnummer sie nicht kennen. Dann rufen Sie doch einfach bei einem Freund mit Komforttelefon an und lassen Sie sich die dort angezeigte Rufnummer ansagen. In vielen Fällen ist genau das dann die Rufnummer, unter der Sie erreichbar sein.

TURN

Aber nun haben wir gehört, dass es oftmals nicht ausreicht, da jemand anderes nicht auf diese nun bekannte Adressen antworten kann.

Bezogen auf das Telefon kann das heißen, dass sie zwar nun eine Rufnummer kennen, aber dies ist leider die Zentralrufnummer. Sie sind also gar nicht anrufbar. Sie können also nur nach draußen telefonieren.
Stellen Sie sich nun mal vor, dass sie dem anderen Gesprächspartner ebenfalls die Nummer ihres "Freundes" (dem STUN-Server) mitteilen. Der andere Teilnehmer kann ihren Freund anrufen und der kann Sie beide dann "verbinden"

Und genau das macht ein TURN-Server. Er nimmt Verbindungen von einem Client an und reserviert bei sich einfach ein paar Ports. Alle Daten die dann auf diese Ports des TURN-Servers gesendet werden, leitet dieser über die bereits von ihrem Client ausgehend aufgebaute Verbindung wieder weiter. Dabei muss der STUN und der TURN-Server nicht mal das gleiche System sein. Allerdings müssen die Ports dieses TURN-Servers natürlich aus dem Internet direkt erreichbar sein.

Der Lync Edge Server ist genau so eine STUN/TURN-Server, der diese Dienste auf Port 3478/UDP bzw. 443/TCP anbietet.

Damit der TURN-Server nur authorisierten Anwendern anbietet, gibt es bei Lync ein Tokenverfahren. Siehe auch MRAS Edge

Das ist der Grund, warum der AVEdge des Edge-Servers so viele Port von außen erreichbar haben muss. Die Funktion ist nicht auf den Zugriff von extern beschränkt. Der Edge-Server kann auch von intern so als Relay verwendet werden. Allerdings ist dies nicht ratsam. Intern sollte der Edge-Server einfach so erreichbar sein.

SDP

Wenn all das gelaufen ist, dann hat der Client nun drei mögliche Endpunkte.

  1. Die eigene IP-Adressen:Ports
    Die kann er selbst auslesen und öffnen
  2. Die externe IP-Adresse:Port des NAT-Router
    Die hat er mit der Hilfe des STUN-Servers ermittelt
  3. Die Ports auf dem TURN-Server
    Diese hat der TURN-Server schon mal reserviert und geöffnet, um die Pakete an den Client über die bestehende TCP-Verbindung (Port 3478) zuzuleiten

Hinweis: Die folgenden Traces können Sie einfach selbst nachvollziehen, indem Sie auf dem Lync Client das Tracking aktivieren und die Datei Communicator-uccapi-0.uccapilog im Verzeichnis C:\Users\<username>\Tracing mit dem Snooper öffnen.

All das passiert noch ehe überhaupt das Endgerät "klingelt". Hier mal ein kleiner Verbindungsaufbau der folgenden Situation. Ein Anrufer eine per Federation angebundenen Firma (msxfaq.de) nutzt einen internen PC um über dessen Edge-Server mich anzurufen. Ich bin im Homeoffice und habe eine Fritz-Box als NAT-Router.

Ein Anruf von dem linken Teilnehmer "user@msxfaq.de" auf meine SIP-Adresse frank.carius@netatwork.de ergibt dann folgenden Dialog beim Empfänger (links).

In der Übersicht sehen Sie drei Phasen der SIP-Kommunikation:

Hier sehen Sie erst mal den gekürzten Abschnitt des INVITE. (Beschränkt auf den ICEv19 Header. Da sieht man die IP-Adressen etwas besser.

In Gelb sehen Sie die Hostadresse des Anrufers. Grün sind die durch den Edge der Firma "msxfaq.de" bereitgestellten Ports. Da die Firewall allerdings NAT verhindert, kann der Client über den Weg nicht seinen externen AV-Edge erreichen und kennt daher nicht die externe IP der Firewall. Die Antwort des angerufenen Clients fällt aber anders aus:

Der gelbe Bereich verrät, dass der Client anscheinend vier Netzwerklinks hat. die 192.168.0.103 und 192.168.0.102 sind die drahtgebundene und eine drahtlose (WIFI)-Verbindung. Zudem gibt es dank VMWare Workstation die beiden virtuellen Netzwerkarten. Grün sind die Kandidaten des Edge-Servers von Net at Work zu sehen. (80.66.20.21) während die externe Schnittstelle des Home-Routers zu Telekom (79.208.121.113) gehört und per NAT einen Zugriff zum Client erlauben könnte.

ICE

Beim Einsatz von Early Media beginnen die Clients sofort mit der Aushandlung der Verbindungen, so dass bei der Annahme der Verbindung schon sofort der RTP-Kanal besteht. Ohne Early Media startet dieses Probing erst mit der Annahme der Verbindung.

Da kommt dann ICE ins Spiel. Jeder Client nimmt sich nun die Kandidaten der Gegenseite vor und sendet über alle Wege entsprechende Daten an die Gegenstelle und erwartet eingehende Daten auf seinen Kandidaten. Je nach Anzahl der Kandidaten kann das eine ganze Menge von Optionen darstellen.

Welcher Kandidat genutzt wird ist weder vom Standort noch von der Richtung abhängig. Wenn zwei Lync Clients beide "extern" sind und jeder eine offizielle IP-Adresse hat, dann können diese direkt miteinander ohne Edge kommunizieren. Oft machen aber vielleicht Firewalls einen Strich durch die Rechnung, dass im Extremfall sogar alle per TURN über den Edge sprechen, obwohl sie doch nebeneinander stehen.

Und dann muss es natürlich noch mindestens einen übereinstimmenden Codec gibt, den beide verstehen. Beide starten diesen Burst und hoffentlich gibt es mindestens einen Kanal, auf dem ein Client Daten der anderen Seite empfängt. Um nicht durch fremde Daten gestört zu werden, sind die Daten natürlich mit Credentials abgesichert, die eigentlich nur die gewünschte Gegenstelle haben kann. Entsprechend der Gewichtung der Kandidaten sollte nun jeder Teilnehmer einen Weg auswählen, über den er Daten von der anderen Seite empfängt.

Und diesen Partner teilt jeder Client seinem gegenüber wieder über ein SIP-Paket mit. Diese enthält dann nur noch den einen Kandidaten, auf dem der jeweilige Client die RTP-Daten erfolgreich und mit möglichst wenig Umwegen empfangen hat.

Das schöne daran ist, dass der Clients dazu nicht mal ermitteln oder wissen muss, hinter welcher Art "NAT" er verborgen ist.

Nun darf der Client auch tatsächlich "klingeln". Es gibt Clients die signalisieren einen eingehenden Ruf schon vorher. Wenn Sie dann schon annehmen und die Audioverbindung noch nicht ausgehandelt ist, dann gibt es ein paar Sekunden "Stille". im schlimmsten Fall kommt gar keine Verbindung zustande.

Wer mag, kann ja mal einen NETMON anwerfen und sich anschauen, wie der Client die verschiedenen "Kandidaten" malträtiert.

Bestätigung der "Candidates"

Wenn kein Early Media konfiguriert ist, werden die letztlich gewählten Kandidaten übermittelt. Der Anrufer sendet dazu seinen INVITE noch mal, um die vorherige Einladung zu ersetzen. Der SDP enthält nur noch seine Kandidaten, auf denen er die andere Seite erfolgreich "empfangen" hat. Lync informiert den angerufenen auch noch, welche Remote-candidates er erfolgreich genutzt hat.

Der andere Teilnehmer bestätigt seinerseits die Verbindung mit einem 200 OK und seinen ausgewählten Kandidaten

Damit wissen beide Parteien, welchen Weg die Audiodaten nehmen. Die Wahl des Codec und die Übermittlung von Statuspaketen erfolgt dann "inband" als Teil des RTP bzw. RTCP-Protokolls. Daher sind hier auch immer zwei Zeilen enthalten. Die erste Zeile ist die RTP-Verbindung während die zweite Zeile die RTCP-Verbindung kennzeichnet.

Ist ihnen eigentlich aufgefallen, dass innerhalb von SDP überhaupt keine Hostnamen erscheinen ?. Es werden immer nur IP-Adressen ausgetauscht. Damit auch wirklich nur die Partner miteinander sprechen, gibt es temporäre Kennworte, die mit ausgetauscht werden. So wird verhindert, dass z.B. zwei Teilnehmer, die z.B. den gleichen (privaten) IP-Adresskreis nutzen, mit fremden Clients irrtümlich eine Verbindung aufbauen.

Zudem erkennen sie anhand der SDPs, dass der Edge selbst kein Transcoding macht oder als B2BUA sich in die Verbindung einschleift,. Es ist der Client, der den Edge als TURN-Server verwenden und so die Audio-Daten vermittelt.

Andere Störungen

Natürlich kann ICE nur funktionieren, wenn sich Netzwerke und Server "vorhersehbar" verhalten. Das ist leider nicht immer so, denn es kann durchaus mehrere andere Komponenten geben, die erst nach einiger Zeit eine Verbindung "stören", z.B.

Das habe ich z.B. am Seattle Airport SEATAC beobachtet, dass dort zwar "Free Wifi by Google" angeboten wurde, aber jede VoIP-Verbindung nach kurzer Zeit (10-60 Sekunden) unterbrochen wurde, weil einfach keine RTCP-Daten mehr angekommen sind.

Solche Probleme sind natürlich außerordentlich schwer zu ermitteln. oft sind NetMon 3 und Wireshark die Helfer, um den Paketen und etwaigen Verlusten nachzuspüren. Wenn der Verdacht besteht, dass es eine lokale Software ist, dann können diese auf NDIS aufsetzenden Analysatoren auch nicht immer etwas sehen. dann hilft nur ein Mirrorport am Switch.

Weitere Links

Lync Deep Dive: Edge Media Connectivity with ICE
http://channel9.msdn.com/Events/TechEd/Europe/2012/EXL412

Keywords:Edge ICS STUN TURN