Warum funktioniert Follow-Me nicht?

In diesem Artikel werden mögliche Ursachen beschrieben, warum die Funktion Follow-Me bei Einsatz von AnyDevice nicht funktionieren könnte und wie diese zu beheben sind.

1) Der Ruf wird von der Telefonanlage nicht zum XPhone Server geroutet

Dies ist recht einfach nachzuvollziehen. Starten Sie am XPhone Connect Server den Wireshark und schneiden Sie den Netzwerkverkehr der Ethernet-Schnittstelle mit (nicht Loopback-Adapter). Filtern Sie im Anzeigefilter auf "sip".

Sie sollten nach ca. einer Minute folgendes sehen können (sofern keine andere SIP-Kommunikation auf dem System stattfindet):

Stellen Sie nun den Fehlerfall noch einmal nach. Wenn Sie im Wireshark nun keine weiteren Pakete finden können (achten Sie auf "Request: INVITE" Pakete), so gelangt der Ruf noch nicht von der PBX zum XPhone Server. Kontrollieren Sie bitte in diesem Fall das Routing in der Telefonanlage.

2) Der XPhone Connect Server findet den AnyDevice-Nutzer nicht

Die häufigste Ursache bei Follow-Me Problemen ist, dass die Telefonanlage eine Rufnummer im Feld "Diversion" bzw. "History" signalisiert, die der XPhone Server nicht kennt. Der XPhone Server sieht sich das Feld "Diversion" bzw. "History" des SIP-Invites der Telefonanlage an, um den Benutzer herauszufinden, für den der Ruf ursprünglich gedacht war.

Findet der XPhone Server den User anhand des "Diversion"-Headers nicht, so sieht man im Wireshark-Trace den Fehler 503 Service Unavailable.

Offiziell kann der XPhone Server Rufnummern nur in diesem Feld erkennen, wenn sie in einem dieser Formate geliefert wird:

1. E.164 (+49...)
2. Intern (123)

Wird die Rufnummer in einem anderen Format signalisiert, kann der XPhone Server möglicherweise die Rufnummer nicht zu einem XPhone Benutzer zuordnen und weißt den Ruf ab -> der Ruf wird abgebrochen.

Die bevorzugte Lösung ist nun, die Telefonanlage so zu konfigurieren, dass die Rufnummer im Feld "Diversion" oder "History" in einem dieser Formate geschickt wird. Ist dies nicht möglich, da z.B. die Telefonanlage in dieser Hinsicht nicht "flexibel genug" ist, bleibt noch die Möglichkeit der Anpassung des XccDiversionPatterns.

Der XccDiversionPattern ist die "Lupe", die über das Feld "Diversion" oder "History" gelegt wird und die Rufnummern aus dem Feld erkennt. Diese Rufnummernerkennung kann erweitert werden, indem man den Wert in den Erweiterten Einstellungen des SIP-Gateways bearbeitet.

Im Folgenden wurden zwei fiktive, aber realistische Szenarien ausgedacht:

Szenario 1: Die Rufnummer wird im falschen Format signalisiert

In diesem Fall wird die Rufnummer im Diversion weder im E.164- noch im internen Format signalisiert. Die Folge: Der XPhone Server kann die Rufnummer keinem Benutzer zuordnen, der Ruf wird abgebrochen.

Die Lösung ist nun unserer Lupe vorzugeben, die Rufnummer im E.164-Format zu erkennen. Dazu bearbeiten wir den Wert XccDiversionPattern, der in den "Erweiterte Einstellungen" des SIP-Gateways zu finden ist, wie folgt:

Default:

^[^<]*<(?:tel|sip):([+]?\d+)\D+.*$

Lösung:

^[^<]*<(?:tel|sip):([+]?\d+)\D+.*$]||[^00([1-9][0-9]{3,})$||+49$1

Das ]||[ ist hierbei unser Trennzeichen. Die Klammer [ darf nicht wieder geschlossen werden!

Es wird die bekannte AdaptCSTAAddress-Syntax verwendet.

In der Lösung haben wir nun die Lupe so eingestellt, dass eine 00 wie eine +49 erkannt wird.

In der Regel wechselt die PBX nicht die Art, wie sie die Rufnummer im "Diversion" oder "History" signalisiert, weswegen andere Rufnummernformate normalerweise nicht beachtet werden müssen.

Szenario 2: Die Rufnummer wird mit Präfix/Knotennummer signalisiert

Die Rufnummer ist zwar nun im richtigen Format, jedoch ist ein Präfix vor der Rufnummer, was uns dasselbe Problem beschert, dass der Benutzer nicht gefunden werden kann. Auch hier muss unser XccDiversionPattern, der in den "Erweiterte Einstellungen" des SIP-Gateways zu finden ist, angepasst werden.

In diesem Szenario hat der fiktive Kunde eine interne Rufnummernlänge von 3.

Default:

^[^<]*<(?:tel|sip):([+]?\d+)\D+.*$

Lösung:

^[^<]*<(?:tel|sip):([+]?\d+)\D+.*$]||[^99([1-9][0-9]{2})$||$1

Es kann auch passieren, dass anstelle eines Präfixes ein überflüssiges Zeichen mitgeschickt wird (z.B. +123). Hierbei kann genauso wie mit der 99 vorgegangen werden, es wird in der Lösung lediglich das 99 durch ein \+ ersetzt.

Szenario 3: Der Ruf wird auf den falschen SIP-Trunk geroutet

Weiterhin kann es möglich sein, dass der XPhone Server über mehrere SIP-Trunks mit der Telefonanlage verbunden ist. Wenn der Ruf von der Telefonanlage zum inkorrekten SIP-Trunk geschickt wird, findet der XPhone Server den User auf diesem Trunk nicht und lehnt den Ruf ab.

3) Die Telefonanlage kommt mit dem Ruf vom XPhone Server zum AnyDevice-Gerät nicht zurecht

Es kann vorkommen, dass der XPhone Server den eingehenden Ruf korrekt verarbeitet, trotzdem kommt keine Verbindung zu Stande. Meist lehnt in diesem Fall die Telefonanlage den vom XCC initiierten Ruf zum AnyDevice ab. Mögliche Gründe dafür sind:

1. Format der Rufnummern im Invite zum AnyDevice
2. Angebotene Codecs im Invite zum AnyDevice
3. Es fehlt Konfiguration in der PBX, den Ruf anzunehmen (z.B. Routing)
4. Der Provider lehnt den Call aufgrund des FROM-Headers ab

Lösung zu 1)

Bei einem Follow-Me Ruf nimmt der XCC den Ruf von der PBX an, und ruft dann das Follow-Me Gerät an. Bei dem Ruf zum Follow-Me Gerät übernimmt der XCC die From- und CLIP-Informationen aus dem eingegangen Anruf, und schickt diese genauso wieder zurück zur Telefonanlage. Lediglich die To-Information wird angepasst (nun steht hier die Rufnummer des AnyDevice Geräts). Das Format dieses To-Headers kann über den Wert "Flags" im Wahlparameter des SIP-Gateways bearbeitet werden.

Wenn die anderen Felder (From, CLIP) im falschen Format stehen, dann müssen sie initial schon im richtigen Format von der PBX zum XPhone Server geschickt werden.

Lösung zu 2)

Bei einem Follow-Me Ruf signalisiert die PBX nicht nur die Rufnummerninformationen im SIP-Invite, sondern bietet darin gleichzeitig die Codecs an, die sie vermeintlich versteht. Der XPhone Server sucht sich dann daraus den besten Codec aus, und bietet diesen wiederum selbst an, um das AnyDevice zu erreichen. Es kann vorkommen, dass die PBX dann trotzdem nicht mehr mit dem Codec zurechtkommt und den Ruf ablehnt. Die Codecs, die der XCC verwendet, können im SIP-Gateway eingestellt werden. Hier muss der Codec entfernt werden, den die PBX nicht versteht.

Lösung zu 3)

Wenn das Verhalten nicht durch 1) oder 2) gelöst werden konnte, gibt es keine weitere Analysemöglichkeiten/Hilfestellungen durch den XPhone Support. Nun muss der Telefonanlagentechniker an der PBX prüfen, warum der Ruf nicht angenommen wird.

Lösung zu 4)

Bei IP-Providern kann es vorkommen, dass der Provider den Anruf zum AnyDevice aufgrund der From-Information im SIP-Invite ablehnt, weil die Rufnummer nicht zum Kunden "gehört". Als Lösung können diese beiden Parameter in den Erweiterten Einstellungen des SIP-Gateways gesetzt werden:

XccLineNumberAsClipFirstLeg = True

XccLineNumberAsClipSecondLeg = True

4) Weitere Hinweise

• Die zentrale AnyDevice-Rufumleitenummer darf die interne Rufnummernlänge des SIP-Gateway-Wahlparameters nicht überschreiten, bzw. die interne Rufnummernlänge muss auf die AnyDevice-Rufumleitenummer-Länge angepasst werden.
• Falls der User vorher mal als AnyDevice Only User konfiguriert war, muss sichergestellt werden, dass im AnyDevice Only "Zustand" keine Umleitung aktiv ist. Diese Umleitung ist in der AnyDevice Twinning Konfiguration nämlich nicht mehr ersichtlich.