Verzögerte Audio-Durchschaltung an SIP Softphone-Leitungen

Beobachtung

Bei Telefongesprächen erfolgt die Audio-Durchschaltung nach einer Verbindungsherstellung deutlich verzögert.
Trotz erfolgreicher Verbindungsherstellung ist die Sprache bidirektional erst einige Sekunden später zu hören: Die ersten 2-3 Sekunden des Gesprächs "fehlen", ansonsten ist die Verbindung in ungestörter Qualität verfügbar.

Wo tritt dieses Verhalten auf?

Telefongespräche auf einer SIP Softphone-Leitung im ProCall Enterprise Client für Microsoft Windows oder in der ProCall Mobile App für iOS und Android können von diesem Problem betroffen sein.

Welche Gespräche sind betroffen?

Häufiger von diesem Problem betroffen sind eingehende Gespräche am ProCall Enterprise Client für Microsoft Windows, hingegen weniger betroffen sind ausgehende Gespräche.

In der ProCall Mobile App kann dieses Verhalten sowohl bei ein- als auch ausgehenden Verbindungen in Erscheinung treten.

Mögliche Ursachen

Die Medienverbindung (verschlüsselter RTP Audio Stream G.711 aLaw-, G.711 µLaw- oder Opus-codiert) zwischen ProCall Enterprise Client für Microsoft Windows und estos UC Media Server oder zwischen ProCall Mobile App für iOS/Android und estos UC Media Server wird mithilfe des Verfahrens Interactive Connectivity Establishment (ICE) nach RFC 8445 ausgehandelt. Dabei tauschen Client und Server Candidates aus (host, srflx, relay, auf IPv4 und IPv6, UDP und TCP).
Candidates stellen die für eine mögliche Audio- oder Videoverbindung möglichen Verbindungsendpunkte dar, die zwischen den Kommunikationsteilnehmern ausgetauscht und als mögliche geeignete Verbindungswege geprüft werden.

Anzahl der Candidates

Je nach Betriebsumgebung kann eine ganz unterschiedliche Zahl von Candidates vorliegen.

Verfügt ein estos UC Media Server beispielsweise nur über ein Netzwerkinterface, und es ist darauf nur das IPv4-Protokoll, nicht aber auch das IPv6-Protokoll gebunden, wird der UC Media Server nur schätzungsweise 5 Candidates dem Client als mögliche Verbindungsendpunkte mitteilen (IPv4 UDP host, IPv4 UDP srflx, IPv4 TCP host active und passive, IPv4 UDP relay).

Befindet sich die ProCall Mobile App beispielsweise im Betrieb in einer typischen Homeoffice-Umgebung, wird diese dem UC Media Server wahrscheinlich mehr als 20 mögliche Verbindungsendpunkte mitteilen: host Adresse im WLAN, host Adresse im Mobilfunkdatennetz, srflx Adresse am Router des Heimnetzes, srflx Adresse im Mobilfunkdatennetz, relay Adresse im TURN Server. Diese Adressen jeweils berücksichtigt unter IPv4 und IPv6, UDP und TCP ergeben ohne Detailberücksichtigungen bereits rechnerisch 20 Candidates.

Bei der Verbindungsaushandlung via ICE werden die gegenseitig mitgeteilten Candidates geeignet gepaart, um die Endpunktverbindungen von beiden Seiten zu prüfen.
Ohne weitere Details zu berücksichtigen, können bei 10 UC Media Server Candidates und 20 ProCall Mobile App Candidates grob überschlagen 10 mal 20 Verbindungswege gebildet werden, die es innerhalb kürzester Zeit zu prüfen gilt, dabei eine hinreichend schnelle Verbindungswegfindung jedoch nicht sichergestellt werden kann. Es könnte eben mehrere Sekunden dauern, bis ein geeigneter Verbindungsweg sowohl von der ProCall Mobile App als auch vom UC Media Server gefunden und als Übertragungskanal miteinander vereinbart wird. Innerhalb dieser Sekunden der Verbindungsaushandlung geht dann die Audioübertragung verloren und der Benutzer nimmt dies als verzögerte Audio-Durchschaltung wahr.

Im Vergleich zum vorherigen Beispiel, in dem IPv4 und IPv6 Candidates evaluiert werden und es dabei zu grob geschätzt 200 zu prüfenden Verbindungswegen kommen könnte, ergeben sich durch Abschaltung von IPv6 Candidates grob überschlagen nur noch 50 zu prüfende Verbindungswege, was einer Reduktion von Verbindungstests um 75% entspricht.

Vorgehensweise

Reduktion der zu prüfenden Verbindungswege

Die Reduktion der zu prüfenden Verbindungswege kann also ein geeignetes Mittel sein, um die Audio-Durchschaltung zu beschleunigen.

Bedarfsweise können die dem estos UC Media Server über den estos UC Web Server zugeführten Candidates des Clients gefiltert werden. Damit erhält der UC Media Server weniger Client Candidates gemeldet, bildet weniger Candidate Pairs für den Verbindungs-Check und nominiert somit rascher die erfolgreich getestete Verbindung.

Gewährleistungsausschluss

Ausdrücklich wird darauf hingewiesen, dass die Reduktion von ICE Candidates mittels der nachfolgend beschriebenen Filterung und die damit einhergehende Reduktion möglicher Verbindungswege dazu führen kann, dass zwischen estos UC Media Server und ProCall Enterprise Clients bzw. ProCall Mobile Apps überhaupt keine Verbindung mehr hergestellt werden kann.

Insbesondere die Nutzung der ProCall Mobile Apps im Mobilfunkdatennetz kann auf die Nutzung von IPv6-Verbindungen angewiesen sein. Ebenfalls kann beispielsweise ein WLAN-Hotspot oder Internet-Zugang in Hotels die ausschließliche Nutzung von UDP vollständig blockieren, wodurch Verbindungen zur ProCall Enterprise Serverinfrastruktur unmöglich gemacht werden.

Für die nachfolgend beschriebenen Konfigurations- bzw. Filterungsmaßnahmen kann somit durch estos keinerlei Funktionsgewährleistung erbracht werden. Insofern diese Maßnahmen in Betracht gezogen werden, wird seitens estos eine vollständige Funktionalitätsprüfung in allen erforderlichen Betriebsszenarien im Zusammenspiel mit der individuellen Kundeninfrastruktur dringend angeraten.

Filtertechnik für ICE Candidates

Je nach Betriebsumgebung ist es sinnvoll, die IPv6 oder TCP Candidates von der ICE Verbindungsprüfung auszunehmen. Ist beispielsweise die IPv4-Kommunikation in allen Verbindungsszenarien (Office, mobiles Datennetz, Home Office, VPN, ...) sichergestellt, kann auf die IPv6 Verbindungsprüfung verzichtet werden. Ebenfalls kann auf TCP Candidates verzichtet werden, wenn der Audio Stream problemlos über regulär und bevorzugt UDP transportiert werden kann.

In estos ProCall Enterprise teilt der Client die Candidates dem estos UC Media Server über den estos UC Web Server mit. Es wird im estos ProCall Enterprise Server die Verbindungsprüfung derart beeinflusst, dass dem estos UC Media Server vom UC Web Server nur die gewünschte Art von Client Candidates zugeführt werden. Vom Client gemeldete Candidates, die nicht geprüft werden sollen (beispielsweise IPv6- und TCP Candidates) filtert der estos UC Web Server aus und der UC Media Server wird diese damit nicht erhalten. Sperrt der estos UC Web Server also die Weiterleitung von IPv6 Client Candidates, wird der UC Media Server keine IPv6 Candidates mitgeteilt bekommen und wird so auch keine Candidate Pairs für IPv6 bilden, obwohl dieser selbst womöglich IPv6 Candidates vorhält.

Diese Filtertechnik für ICE Candidates ist damit unabhängig von der Netzwerkinfrastruktur, es ist also nicht erforderlich, auf Client oder Server Netzwerkadapter zu deaktivieren oder das IPv6 Protokoll vom Adapter zu entfernen.

Filterparameter

Die gewünschten Filterparameter werden im Abschnitt kurentoservers der Konfigurationsdatei eucwebconfig.json (Standard C:\Program Files\estos\UCServer\config\eucwebconfig.json) des estos UC Web Server eingetragen:

Standardwert für alle drei Parameter ist false (auch bei nicht vorhandenem Parametereintrag) und die jeweilige Filterung damit inaktiv.

Beispielsweise zeigt sich eine Filterung von IPv6- und TCP Candidates in der eucwebconfig.json damit wie folgt:

Beispiel Screenshot eucwebconfig.json

Bitte beachten Sie die exakte Syntax hinsichtlich Komma- und Klammernsetzung, wie auch die Groß- und Kleinschreibung

Im hier dargestellten Beispiel werden der UC Media Server und der UCServer bzw. UC Web Server auf demselben Host betrieben (WebSocket Adresse 127.0.0.1).
Für abgesetzt betriebene UC Media Server beachten Sie bitte, die entsprechend andere URL beizubehalten.

Der Abschnitt hier der Vollständigkeit halber nochmals als Code Block:

   "kurentoservers" : [
      {
         "url" : "ws://127.0.0.1:8888/kurento",
         "candkillipv6": true,
         "candkilltcp": true,
         "candonlyturn": false
      }
   ],

Änderungen in der estos UC Web Server Konfigurationsdatei eucwebconfig.json werden erst nach Neustart des Dienstes estos UC Web Server aktiv. Eine Änderung der Filterparameter erfordert also einen Neustart dieses Dienstes, um die gewünschten Filter zu  aktivieren.

Ein Neustart des Dienstes estos UC Web Server wird laufende Gespräche über SIP Softphone-Leitungen trennen.
Dieser Vorgang sollte aufgrund dieser kurzzeitigen Betriebsunterbrechung außerhalb des regulären Produktivbetriebs durchgeführt werden.