VoIP Verbindungsaufbau

Wenn Teilnehmer A  bei Teilnehmer B anruft, dann ist uns allem klar, dass dazu irgendwie ein "INVITE" vom Anrufer beim Ziel ankommen muss, und der darauf antwortet. Und irgendwie kommt dann auch die Audio-Verbindung zustande. Aber warum dauert das manchmal so lange ?

Ausgangssituation

Um möglichst allgemeingültig die Funktion zu erläutern, gehe ich von folgender Ausgangssituation aus und behalte die amerikanischen Personennamen bei

  • Alice ist der Anrufer
  • Bob das Ziel
  • Beide sind aktuell an "ihren" SIP-Servern bereits angemeldet
  • Die SIP-Server sind miteinander bekannt
    Lync und Skype for Business machen das per DNS-Abfragen (z.B. _sipfederationtls._tcp.<domain>) Innerhalb einer Firma hingegen weiß jeder Lync/Skype for Business Server neben der SIP-Adresse oder Rufnummer auch den "HomePool"
  • Firewall-Grenzen werden über einen SBC oder Edge-Server überwunden

P2P Audio-Verbindung

Der Aufbau einer Audio-Verbindung zwischen zwei VoIP-Systemen ist ein gutes Beispiel, an dem die meisten Verfahren und Abhängigkeiten gut beschrieben werden können. Später gehe ich noch auf Abwandlungen ein, z.B. Responsegroups, Konferenzen und Telefonverbindungen über ein Gateway. In unserem Beispiel startet der Teilnehmer-A eine Verbindung zu Teilnehmer-B. Zur Vereinfachung gibt es nur einen Endpunkt, an dem Teilnehmer B angemeldet ist.

Phase Beschreibung Dauer

Teilnehmer A startet Anruf

Der Teilnehmer A gibt die SIP-Adresse oder Rufnummer des gewünschten Ziels ein und gibt durch einen Druck auf den passenden Button der Anwendung den Befehl, die Verbindung aufzubauen. Damit beginnt der Prozess

 

Client A sammelt RTP-Kandidaten

Die Audio-Daten werden bei einer 1:1 Verbindung direkt zwischen den beiden Teilnehmern übertragen, sofern dies möglich ist. Dazu müssen die Teilnehmer natürlich erst mal sich darauf verständigen, wie Sie denn erreichbar sind. Der Noch ehe der Teilnehmer A daher einen Ruf auslöst, muss er erst einmal die Informationen sammeln, wie er erreichbar ist. In der Regel kommen drei Klassen zusammen

  • direkten Adressen auf den Netzwerkkarten
    Der Client fordert vom IP-Stack auf jeder aktiven Netzwerkkarte Ports an und öffnet diese auch. Das geht meist sehr schnell. Die meisten Clients haben aber heute nicht nur eine Netzwerkkarte, sondern z.B. auch ein Bluetooth-PAN, WiFi, VPN-Adapter oder VMWare,/VirtualBox-Adapter. Es können schon hier einige Kandidaten zusammen kommen
  • NAT über STUN Server
    Ein Client weiß erst einmal nicht, welche Netzwerkverbindungen möglich sind. Über das Provisioning weiß der Client aber, dass es einen STUN-Server geben kann. Der Client versucht eine Verbindung zum dem Server. Wenn das erfolgreich ist, dann verrät der STUN-Server dem Client die öffentliche IP-Adresse und den Port , die der STUN-Server gesehen hat. Es ist gar nicht einmal unwahrscheinlich, dass auch später Teilnehmer B an diese Adressen kommt und die Pakete vom NAT-Router an den Client-A weiter gegeben werden.

Wichtig ist hier die Funktion einer Firmen-Firewall. Wenn Sie NAT nicht erlauben, dann sollte die Firewall diesen Verbindungsversuch aktiv mit einem REJECT abwehren. Ansonsten wartet der Client auf einen Timeout und der Rufaufbau dauert entsprechend länger. Eine Firewall wird nicht besser, wenn Sie interne Clients mit einem DROP ausbremst.

  • Relay über TURN-Server
    Zuletzt kann ein Client auch noch den Dienst eines konfigurierten TURN-Servers nutzen, der z.B. durch einen Skype for Business Edge-Server bereit gestellt wird. Auch hier versucht der Client intern z.B: per 3478/UDP oder 443/TCP den Server zu erreichen. Wenn dies klappt, dann reserviert der Client über den Weg sich noch Kandidaten von der externen öffentlichen IP-Adresse.

Auch hier sollte der Client einen konfigurierten Edge-Server auch auflösen und erreichen können. Wenn der Client auf seine TURN-Anforderung ebenfalls auf einen Timeout warten muss, weil die Firewall die Pakete per "DROP" verwirft, dann dauert die Anwahl länger als erwartet.

Erst nachdem der Client diese Schritte durchlaufen hat, kann er überhaupt daran denken, einen INVITE zu senden.

 

INVITE wird gesendet

Nun sendet der Teilnehmer-A ein SIP INVITE zu seinem eigenen Registrar. Dieser Server ermittelt anhand der Adresse, wohin der INVITE weiter gesendet werden muss. Wenn der Teilnehmer-B auf dem gleichen Server ist, dann kennt der Registrar die entsprechenden Endpunkte.

Ist Teilnehmer B auf einem anderen Server oder sogar extern, dann gibt der Registrar den INVITE entsprechend weiter und informiert Teilnehmer A mit einer entsprechenden "101 Trying" Meldung.

Das ist alles nun nur Signalisierung über SIP/TCP oder SIP/TLS. Diese Übertragung kann länger dauern wenn...

  • DNS-Auflösung langsam ist
    Das gilt insbesondere bei Verbindungen zu Federation-Systemen
  • Zertifikate und CLR stocken.
    Lync/Skye for Business arbeitet intensiv mit Zertifikaten, TLS und MTLS. Wenn ein Edge Server zu einem anderen Server geht, muss er nicht nur eine TLS-Verbindung starten sondern auch sein Clientzertifikat vorweisen, welches die Gegenseite natürlich prüft. Das kann schon mal etwas dauern.
    Innerhalb einer Skype for Business Topologie sollte das aber kein Problem sein, da die meisten Server schon Verbindungen zueinander haben werden

Auch hier können durchaus einige Sekunden vergehen, speziell wenn der Weg vom Teilnehmer A zu B über mehrere Stationen geht. Mit einem Trace ist aber gut zu sehen, wie lange die Pakete unterwegs sind.

Bei einer reinen SIP-Verbindung mit SIP-Adressen versucht der Tln-A schon vor dem eigentlichen INVITE z.B. den Status und die Kontakt-Karte von Tln-B zu ermitteln, so dass die TCP-Verbindungen hier in der Regel schon bestehen.

 

INVITE wird empfangen

Am Ende wird der INVITE von dem Registrar des Teilnehmers-B an alle Endpunkte gesendet, an denen sich Teilnehmer-B aktuell angemeldet hat.

Das bedeutet nicht automatisch, dass es schon bei Teilnehmer-B auch "klingelt". Je nach Konfiguration kann sich der Client-B noch Zeit lassen, bis er sicher ist, dass die Verbindung auch zustande kommen kann. Lesen Sie einfach weiter.

 

Client-B sammelt RTP Kandidaten

Client-B hat mit dem INVITE schon die Kandidaten von Client-A bekommen aber nun muss er seinerseits die gleichen Schritte durchlaufen. In aller Kürze hier noch mal:

  • Direkte Kandidaten von den lokalen Netzwerkkarten holen
  • NAT-Kandidaten über STUN ermitteln
  • TURN-Kandidaten über TURN-Server ermitteln.

Auch hier können die üblichen "Probleme" zu merklichen Verzögerungen bei der Sammlung der Kandidaten führen.

 

Client B antwortet Client A

Mit seiner Liste der Kandidaten kann Client-B nun auch eine Antwort auf die Anfrage des Client-A senden. Das SIP-Paket geht dabei den gleichen Weg zurück, den der INVITE gekommen ist. Dazu nutzen alle System auf den Weg den "via"-Header.

Wenn beide Systeme Early Media unterstützen, dann geht die Meldung als "183 Session Progress" zurück. Ansonsten sendet Client-B ein "200OK", was aber noch keine Rufannahme ist. Wenn die Software bei Teilnehmer-B den Ruf dem Anwender signalisiert, sollte er auch auch "RINGING" an den Anrufer zurück senden, so dass dieser ein "Freizeichen" hören kann. Wobei es auch hier unterschiedliche Optionen gibt, wer das Freizeichen generiert.

 

ICE-Handshake

Nun haben aber beide Partner die Liste der RTP-Endpunkte und können nun schon anfangen, RTP-Daten zu senden und so die funktionierenden Kandidaten von den nicht erreichbaren Kandidaten auszusortieren. Das machen die Endgeräte aber wieder nur mit Early Media. Mit Early Media sollten die Clients nach einigen Sekunden die funktionierenden Kandidaten ermittelt haben und Teilnehmer A sendet wieder einen INVITE zu Teilnehmer B. Diesmal sind in den Daten aber nur die ausgewählten SDP-Kandidaten enthalten. Teilnehmer B antwortet wieder mit einem 200 OK und seinen Kandidaten.

Dieser Check der RTP-Verbindung vor der eigentlichen Rufannahme funktioniert nur in Verbindung mit Early Media. Das wird später wichtig, wenn für bestimmte Fälle Early Media nicht möglich ist.

Dann können die Clients diese RTP-Probe erst machen, wenn Teilnehmer-B abhebt. Das Ergebnis ist dann, dass die ersten Sekunden kein Ton übertragen wird, wenn der RTP-Handshake lange dauert. Und damit können Sie schon selbst abschätzen, wer diesen Handshake aktiv beschleunigen kann: Die Firewall ist hier wieder gefordert.

Ist ein Verbindungsversuch per RTP zwischen Clients administrativ nicht erwünscht, dann sollte die Firewall dies auch aktiv mit einem REJECT ablehnen. Nur so können VoIP-Clients zuverlässig und vor allem schnell erkennen, dass eine Verbindung nicht möglich ist und warten nicht auf Timeouts.

 

Verbindung steht

Wenn der Teilnehmer B die Verbindung annimmt, wird die RTP-Verbindung aufgebaut und die Sprache übertragen. Über den gleichen Weg über RTP-Verbindungen werden auch Video und mittlerweile sogar Desktop Sharing übertragen. Nur PowerPoint-Freigaben werden per HTTP im Browser des Clients angezeigt.

 

Ende der Verbindung

Letztlich ist es egal, wer der Teilnehmer die Verbindung beendet. Der aktive Teilnehmer sendet ein BYE zur Gegenseite, welche dieses quittiert. Der RTP-Kanal wird abgebaut und die Reservierungen aufgehoben.

 

 

Diese Auflistung lässt zur Vereinfachung ein paar Schritte weg, z.B.

  • MRAS Edge
    Um sich per TURN-Reservierung einen Kandidaten beim Edge-Server zu besorgen, muss sich der Client natürlich erst authentifizieren und dazu braucht er bei Skype for Business ein MRAS-Token. Das besorgt er sich in der Regel vom Edge-Server schon bei der Anmeldung und erneuert es immer wieder
  • Call Admission Control
    Wenn Sie in ihrem Netzwerk CAC einsetzen, dann wird der angerufene Client vorher noch den PDP befragen, und die ein oder anderen Kandidaten nicht verwenden, z.B. weil diese ansonsten eine Bandbreitenüberlastung auf einer Teilstrecke verursachen könnte.

Response Group

Die häufigsten Beschwerden über eine verzögerte Durchschalten eines Anrufs höre ich immer wieder beim Einsatz von Response Groups. Mit dem Wissen eines P2P-Verbindungsaufbaus können Sie schon fast alleine den Grund dafür erkennen.

Stellen Sie sich vor, ein Anrufer landet in einer Response-Group und mehrere Agenten könnten den Anruf annehmen. Um eine schnelle Audio-Verbindung zu erreichen, müsste der Anruf nicht nur parallel an die Agenten gehen. Alle Clients der Agenten müssten aber auch schon Early Media starten und Kandidaten sammeln, diese an den RGS-Service übermitteln, schon eine RTP-Verbindung ausprobieren um dann den Anruf annehmen zu können.

Um es Kurz zu machen: Response Groups unterstützen technisch kein Early Media. Damit wird man immer mit einer Verzögerung bei der Vermittlung von Audio leben müssen.

Erst wenn ein Agent einen Anruf annimmt, vermittelt der Responsegroup Service das Gespräch per SIP an den Agenten weiter, Der Agent sendet dann ein INVITE/REPLACE zurück an den Anrufer um sich das Gespräch heran zu holen. Aber erst dann weiß auch der Anrufer, welcher Client den Ruf bekommt und kann auch jetzt erst die SDP-Kandidaten austauschen und den ICE-Handshake initiieren.

Das kann relativ schnell gehen aber wenn dann z.B. Firewalls die UDP-Versuche mit einem "DROP" ins Leere laufen lassen oder andere Konfigurationsfehler letztlich diesen Prozess immer wieder ein bisschen verzögern, dann kommt es schnell zu einigen Sekunden Verzögerung beim Verbindungsaufbau. In der Zeit können Anrufer und Agent noch nicht miteinander sprechen

Die Responsegroup ist nun mal nur eine „Kostenfrei Basis-Callcenter Komponente“. Es gibt 3rdParty Callcenter Tools, die technisch anders funktionieren. Die bauen z.B. zwei unabhängige Verbindungen über eine Konferenz-MCU auf. Der Anrufer landet auf einer Konferenz und der Agent wird dort dann mit aufgeschaltet. Dahat zudem den Vorteil, dass man so mit der MCU in der Mitte z.B. noch einen Supervisor aufschalten oder CallRecording möglich wird. 

Ein anderer Tipp ist, den Agenten in einem Call Center einen ganz eigenen Pool zu geben, in dem es keinen EDGE-Server gibt, Entsprechend fallen STUN und TURN weg und die Verbindung geht rasend schnell. Allerdings kann so ein Agent dann natürlich nur Telefonanrufe und VoIP-Anrufe annehmen, wenn der Anrufer im gleichen Subnetz ist oder über ein Gateway kommt. Ohne STUN und TURN ist eine Verbindung vom Home-Office oder mit externen Teilnehmern nicht möglich.

Einleitung einer Konferenz

Wenn aus einem P2P Call eine Konferenz werden soll, dann bemerken die meisten Teilnehmer ebenfalls eine kurze Unterbrechung bei der Sprache. Auch hier ist es wieder die gleiche Problematik, dass das Gespräch an einen anderen Endpunkt übergeben wird. Genau genommen werden aus der 1:1-Verbindung zweier Partner beim Wechsel auf eine Konferenz zwei eigenständige 1:1 Verbindungen zwischen dem Teilnehmer und der Audio-MCU des Pools. Die Verbindung wird quasi umgehängt und auch hier findet eine Ermittlung der Kandidaten samt ICE-Handshake statt.

Es ist dabei übrigens kaum von Belang, ob die Teilnehmer nun intern oder extern sind. Selbst wenn beide Teilnehmer intern sind und uns schon klar ist, dass die direkten Kandidaten die beste Verbindung ergeben, werden die Clients dennoch alle Kandidaten gegeneinander ausprobieren. Schließlich kann der Client ja nicht wissen, dass er im gleichen Netzwerk ist. Gerade "Private IP-Adressen" sind ja in verschiedenen Firmen und im heimischen Netzwerk nicht einzigartig.

PSTN-Call

Auch der Weg über ein PSTN-Gateway ist nur eine Abwandlung dieser Verbindung. Bei einem eingehenden Ruf ist der Teilnehmer A nun eben ein Session Border Controller oder ein SIP-Gateway, welches den INVITE startet und bei ausgehenden Rufen ist dieses Komponente der Teilnehmer-B. Allerdings kommt hier noch die Funktion MediaBypass zum Tragen, mit dem die Rolle des Mediation Servers umgangen werden kann. Hier bei wird der Mediation Server weiterhin als Relay in der Signalisierungskette genutzt aber ersetzt nicht mehr die SDP-Kandidaten.

Dies hat dann zur Folge, dass das Gateway bzw. der SBC direkt mit dem anderen Teilnehmer spricht. Wobei der Teilnehmer natürlich ein Skype for Business Client, aber eben auch wieder eine Response Group oder eine Audio-Konferenz-MCU sein kann.

Weitere Links