Warum werden Softphone-Gespräche nicht zusammengeschaltet?

Dieser Artikel beschreibt das Verhalten und deren Ursachen, warum Softphone-Gespräche nicht zusammengeschalten werden.

Verhalten:

• Wenn Follow-Me auf das Softphone aktiviert ist, wird der Anruf zwar im Client signalisiert, bei Annahme des Anrufes hört der Angerufene jedoch nichts bzw. der Ruf lässt sich nicht annehmen (Toast bleibt bestehen). Wenn nochmal versucht wird, den Call anzunehmen, erscheint eine Fehlermeldung.
• Der Softphone-Teilnehmer ruft eine Person an, hört jedoch nach Annahme des Rufes weiterhin das Freizeichen und bekommt von der Rufannahme des Gesprächs nichts mit.

Erklärung:

Der Call kann zwar über Port 2230 signalisiert werden, die Sprachverbindung auf den Ports 49152-65535 und 30000-33000 kommt aber nicht zustande.

Der Signalisierungszustand eingehender und ausgehender Anrufe ändert sich nach deren Annahme erst dann, wenn die WebRTC-Medienverbindung zwischen Client und Server erfolgreich aufgebaut wurde. Klappt das nicht, dann bleibt bei einem eingehenden Anruf der Toast stehen und ein ausgehender Anruf hört das Freizeichen (Ringback).
Die Ursachen für das Scheitern der Medienverbindung können natürlich vielfältig sein. Im Falle von XPhone sind die Verhältnisse im Prinzip sehr einfach, weil Client und Server "sich kennen" und daher Probleme bzgl. Codec, Verschlüsselung etc. in der Aushandlung des SDP quasi nicht existieren. D.h. Verbindungsprobleme können eigentlich nur am Austausch von UDP Paketen zwischen Client und Server scheitern. Dieser Austausch findet über die Ports 49152-65535 des Clients und die Ports 30000-33000 des Servers statt.

Über diese Ports werden sowohl STUN-Pakete zur Verbindungsprüfung als auch die Medien-Daten ausgetauscht. Der Verbindungszustand existiert in WebRTC und hängt davon ab ob der Ice-State (=Erfolgreiche Austausch von STUN) verbunden ist oder nicht. Der Zustand "Connected" wird erst bei erfolgreichen Medienverbindung gesetzt.

Schrittweise erklärt:

1. Ein eingehender Call wird über Port 2230 signalisiert
2. Im Client wird auf "Annehmen" geklickt
3. Der Client versucht, auf den dynamischen Ports (z.B. vom Client-Port 49234 zum Server-Port 30123) eine STUN-Aushandlung durchzuführen, um mit dem Server einen Audio-Kanal herzustellen
4. Klappt die STUN-Aushandlung, so wird der Ice-State in WebRTC auf Verbunden gesetzt*
5. Anhand dessen wird erkannt, dass der Call steht, im Client wird der Call nun als aufgebaut/verbunden angezeigt

*Klappt die STUN-Aushandlung nicht, so schlägt etwas auf der Verbindungsstrecke auf den Ports 49234 und 30123 fehl

Ursachen:

Ursache 1: 
RTP-Portrange für Sprachpakete (49152-65535 UDP und 30000-33000 UDP) werden von der Firewall geblockt auf
* Hardware-Firewall im Servernetz
* Software/Windows-Firewall am Client

Ursache 2:
Das Routing ist nicht korrekt
* Variante 1: Kunde nutzt einen VPN-Tunnel, über den die UDP-Pakete generell nicht geroutet werden
* Variante 2: Server hat mehrere IP-Adressen, die untereinander nicht geroutet werden (oft sind dann Softphone-Clients und PBX in verschiedenen Netzen)

Ursache 3:
Softphone-zu-Softphone wird im Routing nicht berücksichtigt – besonders bei der Verwendung eines VPNs kann dies zu weiteren Problemen führen.

Ursache 4:
Der XPhone Connect Client ist nicht über einen VPN mit dem XPhone Server verbunden. Bislang ist ein VPN-less Betrieb des XPhone Clients nicht möglich (Stand: August 2022).