ICE, Kandidaten, STUN und TURN

Beachte dazu auch MRAS Edge

Wenn ein Client eine AudioVerbindung aufbauen will, dann muss er „Kandidaten“ an die Gegenseite senden. Kandidaten sind die IP-Adresse:Ports, auf denen der Client Audio annimmt. Erster und präferierte Kandidat sind natürlich die lokalen IP-Adressen. Aber über diese können zwei Clients nur kommunizieren, wenn sie im gleichen Netzwerkverbund sind und die RTP-Pakete geroutet werden. Sobald eine AdressUmsetzung (NAT) oder ein Filter (Firewall) dazwischen ist funktioniert das nicht.

ICE in Kürze

Ein Client, der eine Verbindung über RTP (Audio, Video, Desktop-Sharing, Dateitransfer) aufbauen will, muss seinem Kommunikationspartner eine Liste von möglichen Verbindungspartnern geben. Die muss der Client sich erst besorgen. hierzu gibt es drei Quelle:

  1. Lokale Adressen
    Der Client kann erst mal auf ihm zugewiesenen Netzwerkkarten Ports öffnen und diese damit der direkten IP-Adresse anbieten. Das geht natürlich nur mit Gegenstellen im gleichen gerouteten Netzwerk.
  2. STUN und NAT
    Wenn der Client hinter einem NAT-Router sitzt, dann kann er dennoch nach außen Verbindungen initiieren, auf die dann Rückantworten eingehend möglich sind. Der Client baut eine Verbindung zum konfigurierten STUN-Server auf, der ihm dann die NAT-Adresse samt Port meldet. In vielen Fällen können auch andere Systeme ihre Pakete an dieses Ziel senden und der NAT-Router leitet sie zum Client weiter. NAT ist keine Firewall sondern eine Traversal-Technologie. So hat der Client aber weitere Kandidaten.
  3. Zuletzt kann der Client auch sich eine TURN-Servers bedienen, der ihm bereit gestellt wird. Der Client verbindet sich in der Regel per 3478/UDP mit dem Server, der dann auf seiner öffentlichen Adresse einen Port öffnet und eingehende Pakete zum Client weiter leitet, quasi eine dynamische Portveröffentlichung. Damit hat der Client weitere Kandidaten.

Diese Kandidaten gehen zum Empfänger, der seinerseits das gleiche macht und seine Kandidaten zurück sendet. Dann versuchen die Clients, wie sie direkt miteinander Daten austauschauen können. Dieses Einsammeln von Kandidaten und das Probing ist natürlich zeitkritisch. Daher gibt es in der Regel drei Faktoren, die Zeit kosten und damit den Verbindungsaufbau verzögern.

  1. Firewall droppt STUN-Versuch
    Der Client versucht von intern über die Default Route die öffentliche IP-Adresse des STUN-Server zu erreichen. Viele Firewall Administratoren blockieren aber diese Verbindung von Intern auf eine externe IP-eines Servers, der auch von intern erreichbar wäre. Wenn die Firewall diese Verbot aber nicht mit einem "ICMP not Reachable" blockt sondern das Paket einfach "verschwinden" lässt, dann verzögert dies den Client, der auf einen Timeout warten muss
  2. TURN-Server nicht erreichbar
    Ist ein TURN-Server konfiguriert aber nicht erreichbar, dann verzögert auch dies den Client, welcher auf die Antwort auf seinen Request wartet. Wer also z.B. einen Lync Edge Server in der Topologie schon addiert aber noch nicht installiert hat, wird Verzögerungen auch beim internen Verbindungsaufbau feststellen
  3. ICE-Probing unterbunden
    Die Clients versuchen sich gegenseitig unter Nutzung der Kandidaten zu erreichen. Auch hier sollte eine Firewall unerlaubte Verbindungen aktiv "ablehnen" und nicht still mit einem DROP unterschlagen.

Verschiedene Produkte versuchen durch "Early Media" zumindest die Zeit für den kanalaufbau zu reduzieren, d.h. während der INVITE schon die Endgeräte klingeln lassen, bauen diese im Hintergrund schon eine Audioverbindung auf. Diese "steht" dann quasi schon, wenn der angerufene Teilnehmer abhebt. Es gibt aber auch Fälle wie z.B. ResponseGroups, bei denen Early Media nicht sinnvoll ist und daher es beim Verbindungsaufbau Prinzip bedingt etwas dauert.

ICE mit Lync

Will ein Client also mit einem externen Client (Lync remote Arbeiter im Internet oder Federation o.ä.) kommunizieren, muss er sich eines Relays bedienen. Diese Aufgabe übernimmt der Edge Server. Der Client weiß also über das Inband Provisioning, welcher Edge Server „seiner“ ist und welche IP-Adressen dieser hat. Der Client muss nun nur noch rausfinden, wie er mit dem Edge kommunizieren kann. Dazu spricht der Client einmal die „interne“ IP-Adresse des Edge Servers an. Klappt dies, dann ist der Client „intern“ und kann den Edge Server als Relay nutzen. Der Edge leiht dem Client also externe IP:Port-Kombinationen um die Audiodaten umzusetzen. Zudem versucht der Client die externe AV-Edge IP anzusprechen. Ist dies möglich, dann teilt der Edge dem Client die „gesehene“ Source-IP-Adresse mit. So kann der Client ermitteln, ob er z.B. hinter NAT arbeitet und diese Kombination als Kandidat mit anbieten. Beide Partner verfahren so und letztlich gibt es eine ganze Menge möglicher Paarungen, die ausprobiert werden um dann die günstigste Version zu nutzen. Es ist also unkritisch und absolut normal, dass bestimmte Paarungen nicht möglich sind. Einige „Versuche“ werden auch in Firewalls „geloggt“. Speziell die „Interne IP will mit AV-Edge-IP sprechen“ führt immer wieder zu Irritationen, aber sind normal und keine Lync Besonderheit. Jedes VoIP-Produkt, welches ICE (http://www.msxfaq.de/uc/ice.htm) implementiert, nutzt diese Technik. Firewall Administratoren können unerwünschte Kommunikationswege gerne blocken und die Protokollierung für diese Regeln deaktivieren.

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. 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. Hier exemplarisch ein SDP-Auszug:

Übrigens kann ICE problemlos auch 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)

Übrigens kann man ICE auch abschalten. Das geht über eine CS-ClientPolicy (Nur Lync 2010) oder auch per Gruppenrichtlinie. Den entsprechenden Key verrät der Client z.B. über den ProcessMonitor von Sysinternals.

Auf der einen Seite lässt sich damit Zeit beim Handshake der RTP-Kandidaten sparen aber ohne ICE funktionieren natürlich eigentlich nur direkte interne Verbindungen. Eine VPN-Verbindung zählt dann natürlich auch wieder als Intern".

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. Das können durchaus mehrere Adressen sein. Die meisten Computer haben nicht mehr nur eine Netzwerkkarte. Ethernet ist Standard aber in Tablets sogar absteigend oder nur noch mit einem Adapter zu erreichen, WiFi ist mittlerweile schon immer da und selbst GSM-Karten sind häufiger anzutreffen. Und dann gibt es noch VPN-Adapter, IPSec, ISATAP, VMWare/VirtualBox-Adapter.

C:\>ipconfig | findstr /i "Adapter"
Ethernet-Adapter Gigabit:
Drahtlos-LAN-Adapter WiFi:
Mobiler Breitbandadapter Mobile Breitbandverbindung:
Ethernet-Adapter Bluetooth:
Drahtlos-LAN-Adapter AP MSXFAQ:
Ethernet-Adapter VMware Network Adapter VMnet1:
Ethernet-Adapter VMware Network Adapter VMnet8:
Ethernet-Adapter VirtualBox Host-Only Network:
Tunneladapter isatap.{3580D624-C8B4-4571-8548-90E2619E339D}:
Tunneladapter isatap.{D43EB556-CF93-40BE-9386-E6E7ECCF86FB}:
Tunneladapter isatap.{B21EF767-B8D5-4C67-8ECB-F3F4CBC47EEA}:
Tunneladapter isatap.{ACDBC4F2-437B-49F9-8758-9BA550568220}:
Tunneladapter isatap.fritz.box:
Tunneladapter isatap.{60BC6758-DF32-4876-B9DD-28F13F3CB098}:
Tunneladapter isatap.{BEBC7417-3623-4C15-8BC7-47723440912D}:
Tunneladapter isatap.{D562529D-9CEA-4E9B-974C-0FB8A914D7CF}:
Tunneladapter LAN-Verbindung* 29:

Und mehrere haben auch IP-Adressen

C:\>ipconfig | findstr /i "Adresse"
   Verbindungslokale IPv6-Adresse  . : fe80::7d0b:eb05:6c07:f9c7%10
   IPv4-Adresse  . . . . . . . . . . : 192.168.178.36
   Verbindungslokale IPv6-Adresse  . : fe80::49ff:5584:e0fa:5fae%12
   IPv4-Adresse  . . . . . . . . . . : 192.168.178.34
   Verbindungslokale IPv6-Adresse  . : fe80::193b:1b82:d12c:192%25
   IPv4-Adresse  . . . . . . . . . . : 192.168.182.1
   Verbindungslokale IPv6-Adresse  . : fe80::95fe:1fe3:3393:d8b%26
   IPv4-Adresse  . . . . . . . . . . : 192.168.23.1
   Verbindungslokale IPv6-Adresse  . : fe80::fc8e:7476:110f:ed3e%51
   IPv4-Adresse  . . . . . . . . . . : 192.168.56.1
   IPv6-Adresse. . . . . . . . . . . : 2001:0:5ef5:79fd:44c:216e:b013:1811

Der Lync Client wird also all diese Adressen als mögliche Kandidaten an den Gegenüber er SIP senden.

NAT und STUN

Wenn wir komplexe Firewalls von Firmen einmal außen vor lassen, ist eine Address/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. Gegeben sei folgende Umgebung.

Von links nach Rechts baut der Client A (IP 192.168.1.2 mit SourcePort 20000) eine Verbindung zu Gegenstelle C (IP 90.1.1.1 Port 8000) auf. Entsprechend bekommt der Client vom NAT-Router B einen Port zur IP-Adresse auf dem externen Interface zugewiesen. Der Router hat also eine entsprechende Tabelle, in der steht, dass eingehende Pakete auf 80.1.2.3:30000 zum Client A auf Port 20000 zurück müssen.

Interessant ist aber nun, welche anderen Source-Ports und IP aus dem externen Bereich eine Verbindung zum Client A über den NAT-Router herstellen können.

SourceIP C C <>C <>C
SourcePort 8000 <>8000 Any Any
Destination Port 30000 30000 30000 <>30000

Full Cone

Ja

Ja

Ja

Nein

Address Restricted

Ja

Ja

Nein

Nein

Port Restricted

Ja

Nein

Nein

Nein

Symmetric

Ja

Nein

Nein

Nein

Static Mapping

Ja

Ja

Ja

Ja

Als NAT bezeichnet man meist nur die ersten vier Zeilen. Ein statisches Mapping erfordert eine aktive Konfiguration auf dem NAT-Gerät, quasi als "Serververöffentlichung". So würde z.B. ein Edge-Server hinter einer Firewall erreichbar gemacht. Die vier NAT-Varianten sind:

  • Full cone NAT
    Jeder entfernte Rechner kann, sofern er die IP-Adresse und den zugewiesenen Port des NAT-Routers ein Paket an den Router senden und dieser leitet das Paket an den Client weiter. Sowohl die Quell-IP aber auch der Quellport ist nicht gebunden. Diese Variante ist am "offensten" und wenn die Endpunkte sich über eine anderen Verbindung (z.B. SIP) verständigen können, ist eine direkte Übertragung möglich.
  • Address Restricted
    Der Router nimmt hier nur noch Pakete von der Gegenstelle an, an die der interne Client auch etwas gesendet hat. Der Quellport für die Rückantwort ist aber nicht festgelegt. Hier kann ein "fremder" Client kleine Pakete mehr rein senden. Bei verbindungslosen Protokollen (UDP) könnte der Sender natürlich seine IP fälschen. Die Verbindung wäre dann aber unidirektional.
  • Port Restricted NAT
    Zusätzlich zur Beschränkung auf die IP-Adresse der Gegenstelle wird hier auch noch der Port gefiltert. Ein anderer Prozess auf dem Server kann daher nicht mit einem anderen Port zum Initiator zurück kommen. Die Rückantwort muss also vom gleichen Port als Quelle kommen.
  • 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.

Es hängt also stark von ihrem Router und Firewall ab, wie genau sie NAT umsetzt und was damit entsprechend möglich ist. Manchmal ändert sogar ein Firmware-Update das Verhalten. Hinzu kommt mittlerweile auch, dass Endgeräte per UPNP Ports öffnen können, so der VoIP-Client, der NAT-Router und die Berechtigungen dies erlauben.

Für VoIP ideal ist natürlich der Weg, dass die Endpunkte direkt miteinander kommunizieren. Das ist der kürzeste Weg und erspart weitere Hops, Umwege und Ressourcen auf einem Relay. Wenn aber kein Rückweg möglich ist, dann bleibt nur der Weg über einen TURN-Server.

Für den Einsatz mit VoIP ist primär 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

Um eine hinter NAT verborgene Verbindung anzubieten muss der Client heraus finden, 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 können. 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.

Bei Lync ist der Edge-Server auch zugleich "STUN"-Server und der Client versucht diesen auch von intern zu erreichen. Wenn ihre Firewall den Zugriff von innen per NAT auf die externe öffentliche Edge-IP erlaubt, dann kann es passieren, das Audio/Video mit externen Teilnehmern direkt über die Firewall per NAT abgewickelt wird und nicht über den Edge als Media-Relay.

Wenn die Firewall die STUN-Pakete aber blockiert, dann sollte Sie diese aktiv mit einem "Reject" zurückweisen und nicht wie hier mit einem DROP:

Ein Drop hat den Nachteil, dass der Client nicht aktiv bescheid gesagt bekommt, dass dieser Weg verboten ist und daher auf einen Timeout wartet. Das verzögert eventuell den Start einer Audio/Video-Verbindung

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 können, 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:

  • ROT
    Der erste INVITE  mit dem Austausch der Kandidaten.
  • Grün
    Ca. 7 Sekunden später wird der Ruf angenommen. Nun tauschen die Partner die ermittelten Kandidaten aus.
  • Blau
    Nach ca. 28 Minuten beenden die beiden Teilnehmer das Gespräch. Der angerufene Teilnehmer legt zuerst mit einem BYE auf.

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.

Wenn ein PC sehr viele Netzwerkkarten hat (z.B. VMWare, etc.), dann sollten Sie einen Blick auf die Anzahl der Kandidaten werden. Mehr als 40 Paare (RTC/RTCP) sind nicht erlaubt.
Siehe auch MS-ICEv2: 3.1.4.8.1 Candidates Gathering Phase (http://msdn.microsoft.com/en-us/library/dd925215(v=office.12).aspx )
Siehe auch MS-ICEv2: 3.1.4.8.2.1 Forming the Candidate Pairs http://msdn.microsoft.com/en-us/library/dd921141(v=office.12).aspx#endNote8

Der Aufbau des SDP ist in der RC 4566 beschrieben und relativ einfach

An SDP session description consists of a number of lines of text of the form:

<type>=<value>

where "<type>" MUST be exactly one case-significant character and "<value>" is structured text whose format depends on "<type>". In general, <value> is either a number of fields delimited by a single space character or a free format string, and is case-significant unless a specific field defines otherwise.  Whitespace MUST NOT be used on either side of the "=" sign.
Quelle: SDP: Session Description Protocol (http://tools.ietf.org/html/rfc4566)

Suchen der Kandidaten

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.

  • RTCP-Probleme
    Neben den reinen Audio-Daten per RTP werden auch Steuerinformationen per RTCP übermittelt. Auch wenn Exchange die Daten verschlüsselt, so verrät der Header durchaus, dass es sich um RTCP/RTP handelt. Perfide sind RTCP-Probleme, weil dann die Verbindung in der Regel erst mal zustande kommt aber nach einige Sekunden dann mit einem BYE aufgelegt wird, weil die Statusmeldungen Ausbleiben.
  • Provider, IntrusionDetection
    Auch wenn Lync alles "verschlüsselt", so kann eine Firewall dennoch "erkennen", was da vermutlich übertragen wird. Allein über Volumen kann auch ein verschlüsselter Voice-Datenstrom als solcher "erahnt" werden. Der gebräuchliche G.711-Codec tastet mit 8kHz ab und liefert also 8KByte/Sek oder 64kbit/Sek. Wenn die Pakete nun alle 20ms "lang" sind, dann sind das 50 Pakete/Sec a 160byte. Es ist für einen Provider oder Firewall nicht sonderlich schwer, solche Lasten zu erkennen und zu erschweren.

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.

  • Virenscanner
    Und unterschätzen Sie nicht die lokal installierten Virenscanner, die gerne "schlauer" sein wollen und auch den Netzwerkverkehr von Anwendungen überwachen wollen. z.B.
    Kasperski: http://support.sherweb.com/Faqs/Show/kaspersky-anti-virus-setup-for-microsoft-lync-2010
  • Firewall
    Einige Firewalls schauen tiefer in die Pakete. Einige auch zu tief. So gibt es Berichte, dass die Checkpoint SIP ALG-Option dafür sorgt, dass Verbindungen nach 10-15 Sekunden unterbrochen werden.
  • WAN Optimizer (Riverbed, Cisco WAAS etc.)
    Sie versuchen Pakete einzusparen oder zu komprimieren. Das ist bei RTP nicht sonderlich sinnvoll und auf der anderen Seite kenne ich noch keinen Optimierer, der die Pakete optimiert, die an mehrere Konferenzteilnehmer in eine Richtung mehrfach gesendet werden. Aber ich habe schon Probleme bei Firmen gelöst, indem die Lync Ports von der Optimierung ausgeschlossen wurden.

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

SIP Signaling, Negotiation and Media Flows in Skype für Business, Explained
https://channel9.msdn.com/events/Ignite/2015/BRK4102
Sehr schöner Vortrag zu SIP und SDP