Probleme, die sich auf eingehende Direct Routing-Anrufe auswirken

Möglicherweise treten Probleme auf, wenn Sie PstN-Anrufe (Public Switched Telephone Network) über Direct Routing erhalten. In diesem Artikel werden einige dieser Probleme erläutert und Lösungen bereitgestellt, die Sie ausprobieren können.

Kein Klingelton, wenn Teams einen Anruf von einem PSTN-Endpunkt empfängt

Dieses Problem tritt im folgenden Szenario auf:

Wenn ein Microsoft Teams-Client einen Anruf empfängt, sendet er zuerst eine SIP 180-Klingelnachricht und sendet dann eine SIP 183 Session Progress-Nachricht zusammen mit einem Medienangebot (SDP).

Gemäß RFC 3261- und RFC 3960-Standards muss der vom Anrufer verwendete Endpunkt eine SIP 180 Ringing-Nachricht empfangen, den Klingelton lokal generieren. Wenn das Gerät des Anrufers eine SIP 183-Sitzungsstatusnachricht mit SDP empfängt, kann das Ziel (der Teams-Client in diesem Szenario) Audio oder Klingelton wiedergeben, bevor die Sitzung vom aufgerufenen Benutzer akzeptiert wird. Solche Audiodaten werden als frühe Medien bezeichnet.

Einige Anrufergeräte und Netzbetreiber generieren den Klingelton jedoch nicht mehr lokal, wenn sie eine SIP 183-Sitzungsstatusmeldung erhalten. Dies geschieht auch dann, wenn die Geräte und Netzbetreiber weiterhin den Klingelton generieren sollten, bis die tatsächlichen Medienpakete empfangen werden.

Lösung

Um das Problem zu beheben, müssen Sie die SBC-Konfiguration (Session Border Controller) aktualisieren, um mehrere SIP 18x-Nachrichten zu verarbeiten.

Die meisten SBCs bieten eine der folgenden Entschärfungsoptionen:

• Leiten Sie nur die erste SIP 18x-Nachricht weiter, und ignorieren Sie nachfolgende Nachrichten, bis der Anruf angenommen oder beendet wird. Diese Option wird beispielsweise von AudioCodes SBCs angeboten.
• Entfernen Sie die SDP-Informationen aus der Nachricht "SIP 183 Sitzungsfortschritt", und ändern Sie dann die Nachricht in eine SIP 180-Klingelnachricht. Diese Option wird beispielsweise von Metaswitch-SBCs angeboten.

Anweisungen zum Aktualisieren der SIP-Manipulationsregeln in Ihrem SBC finden Sie in der Dokumentation, die für Ihr SBC-Modell spezifisch ist, und wenden Sie sich an Ihren SBC-Anbieter, um weitere empfohlene Optionen zu erhalten.

Mehrere Benachrichtigungen über verpasste Anrufe

Wenn Teams einen Anruf empfängt und ablehnt, weil der Benutzer ausgelastet ist oder den Anruf zu diesem Zeitpunkt nicht annehmen möchte, kann der PSTN-Netzbetreiber oder SBC den Anruf mehrmals wiederholen. Teams interpretiert jeden wiederholten Anruf als separate Anrufe und zeigt mehrere Benachrichtigungen über verpasste Anrufe an.

Dieses Problem tritt auf, da verschiedene Kommunikationsstandards wie RFC 4497-Standard und NICC-Standard ND1017:2006/07 den gleichen SIP-Antwortcode verschiedenen Q.850-Ursachencodes zuordnen.

Beispielsweise ordnet RFC 4497 SIP-Antwortcode 486 dem Q.850-Ursachencode 34 zu, und ND1017:2006/07 (das Direct Routing verwendet) ordnet Code 486 Q.850 Ursachencode 17 zu. Aufgrund dieses Unterschieds interpretieren die PSTN-Anbieter, die den RFC 4497-Standard verwenden, den Grund, warum Teams den Anruf falsch abgelehnt hat. Daher wiederholen die PSTN-Anbieter den Anruf mehrmals.

Lösung

Um das Problem zu beheben, aktualisieren Sie die SIP-Manipulationsregeln in Ihrem SBC, um entweder den Q.850-Ursachencode zu entfernen, der SIP-Antwortcode 486 zugeordnet ist, oder ändern Sie den Ursachencode von 34 auf 17. Anweisungen zum Aktualisieren der SIP-Manipulationsregeln finden Sie in der Dokumentation, die für Ihr SBC-Modell spezifisch ist.

Wenn das Problem durch das Aktualisieren der Regeln nicht behoben wird, ist es wahrscheinlich, dass entweder der SBC, ein Netzwerkgerät im Kommunikationspfad oder Ihr PSTN-Anbieter den Anruf erneut versucht, nachdem er einen SIP 4xx-Antwortcode empfangen hat. Dieses Verhalten wird nicht empfohlen. Aktualisieren Sie in diesem Fall die Konfiguration des SBC und der Netzwerkgeräte, oder bitten Sie den PSTN-Anbieter, seine Konfiguration zu aktualisieren, um sicherzustellen, dass er keinen Anruf erneut versucht, nachdem er eine SIP 4xx-Antwort erhalten hat, um den Anruf zu beenden.

Falsche Anrufer-ID (CLI) wird für eingehende Anrufe angezeigt

Wenn Teams einen Anruf empfängt, wird die Nummer des Anrufers angezeigt, die in der From Kopfzeile in der SIP INVITE-Nachricht angegeben ist. Einige PSTN-Anbieter verwenden jedoch möglicherweise den P-Asserted-Identity Header anstelle der From Kopfzeile, um die Nummer des Anrufers zu speichern. In dieser Situation sind die informationen, die dem Teams-Benutzer angezeigt werden, falsch.

Lösung

Um dieses Problem zu beheben, überprüfen Sie, ob Ihr PSTN-Anbieter den P-Asserted-Identity Header verwendet. Wenn ja, konfigurieren Sie Ihren SBC so, dass der Inhalt der From Kopfzeile mit den Informationen aus der P-Asserted-Identity Kopfzeile neu geschrieben wird.

Informationen zum Umschreiben des From Headers finden Sie in der Dokumentation, die für Ihr SBC-Modell spezifisch ist.

Notiz

Wenn die From Kopfzeile "Anonym" als Informationen enthält, konvertiert Teams sie manchmal in eine Zahl und zeigt stattdessen 266696687 an.

Eingehende Anrufe sind falsch als "Spam wahrscheinlich" gekennzeichnet.

Wenn die Spamfilterung für Anrufe aktiviert ist, werden die Anrufer-IDs aller eingehenden Anrufe überprüft und einer Spambewertung zugewiesen. Wenn die Bewertung für eine Anrufer-ID höher als ein bestimmter Schwellenwert ist, zeigt Teams eine Benachrichtigung an, dass der Anruf möglicherweise Spam ist.

Lösung

Um die Wahrscheinlichkeit zu verringern, dass die Telefonnummer eines Anrufers als Spam gekennzeichnet wird, stellen Sie sicher, dass die Nummer im E.164-Format angegeben ist.

Eingehende Anrufe werden nicht wie erwartet blockiert.

Sie konfigurieren Teams so, dass Anrufe von Anrufer-IDs blockiert werden, die vordefinierte, bestimmte Kriterien erfüllen. Sie erhalten jedoch weiterhin Anrufe von solchen Telefonnummern.

Dieses Problem wird in der Regel durch einen Konflikt zwischen dem Anrufer-ID-Format verursacht, das von dem Ausdruck erwartet wird, der zum Anzeigen eingehender Anrufe verwendet wird, und dem Format der Anrufer-ID im From Header der SIP-Nachricht.

Beispielsweise kann die Anrufer-ID in einem internationalen Format angegeben werden, einschließlich eines führenden Pluszeichens (+) und eines internationalen Präfixes. Der Ausdruck sucht jedoch nur nach Zahlen, die im nationalen Format angegeben sind. Die Situation kann auch umgekehrt werden.

Lösung

Um dieses Problem zu beheben, aktualisieren Sie den Ausdruck, der zum Überprüfen eingehender Anrufe verwendet wird, indem Sie das Pluszeichen (+) als optionales Zeichen hinzufügen. Dieser überarbeitete Ausdruck behandelt mehrere Anrufer-ID-Formate und ist besonders hilfreich, wenn Sie sowohl Direct Routing als auch Anrufpläne verwenden, in denen Nummern in verschiedenen Formaten dargestellt werden.

Verzögerung beim Beantworten von PSTN-Anrufen in Teams

Wenn Teams einen Anruf von einem PSTN-Endpunkt empfängt, tritt entweder eine Verzögerung beim Annehmen des Anrufs auf, oder Sie hören ein paar Sekunden lang keine Audiodaten, nachdem Teams den Anruf beantwortet hat.

Diese Probleme werden in der Regel durch mehrere SIP-Wiedereinsendungen verursacht, die zwischen dem SBC und dem SIP-Proxy gesendet werden, bevor der Anruf erfolgreich verbunden ist. Dies ist insbesondere in Szenarien üblich, in denen medienumgehungen oder lokale Medienoptimierungen erforderlich sind, für die mehrere Neuzuversetzungen erforderlich sind. Darüber hinaus muss der SBC in einer Situation, z. B. wenn der SBC die entsprechende Medien-IP in der ursprünglichen Einladung nicht anbietet, einen Erneutladen senden, der über die richtigen Informationen verfügt. Wenn die Revite des SBC vom SIP-Proxy in der falschen Reihenfolge oder zum falschen Zeitpunkt empfangen wird (wodurch eine Rennbedingung verursacht wird), kann die Wiedereinsetzung länger dauern, um ausgehandelt zu werden. Diese Situation kann zu Audioverzögerungen führen.

Lösung

Um diese Probleme zu beheben, aktualisieren Sie Ihre SBC-Konfiguration. Stellen Sie sicher, dass sie standardmäßig die wahrscheinlichste Medien-IP bietet, um die Anzahl der Wiedereinführungen zu minimieren. Wenn beispielsweise die meisten Anrufe von internen Benutzern erwartet werden, konfigurieren Sie den SBC so, dass zuerst eine interne IP angeboten wird. Ausführliche Anweisungen zur SBC-Konfiguration finden Sie in der Dokumentation, die für Ihr SBC-Modell spezifisch ist.

Anrufe werden nach einer bestimmten Dauer abzulegen

In Teams können Anrufe, die gerade ausgeführt werden, und eingehende Anrufe, die weiterhin eine Verbindung herstellen, aus verschiedenen Gründen fallen.

Basierend auf der Zeitspanne, nach der ein Anruf abbricht, versuchen Sie die Auflösungen, die für Ihr Szenario funktionieren.

Anrufe werden nach etwa vier Sekunden abfallen

Dieses Problem wird in der Regel durch eine schlechte Konnektivität oder ein Kommunikationsproblem verursacht, das zwischen dem SBC und dem SIP-Proxy vorhanden ist. Zum Beispiel:

• Der SBC empfängt möglicherweise die SIP 100 Trying Message nicht, da die Nachricht durch eine Firewall blockiert oder aufgrund von Netzwerkproblemen nicht gesendet wird.
• Der SBC empfängt die SIP-Nachricht, erkennt sie aber nicht an, indem eine SIP-ACK-Nachricht gesendet wird.

Lösung

Um dieses Problem zu beheben, aktualisieren Sie Ihre SBC- und Netzwerkkonfiguration, um Datenverkehr zu und von allen IP-Adressbereichen zuzulassen, die das Direct Routing-Feature für die SIP-Signalisierung verwendet. Stellen Sie außerdem sicher, dass der SBC Nachrichten gemäß dem Standardprozess sendet, der für die Kommunikation von SIP-Signalen verwendet wird.

Ausführliche Anweisungen zur SBC-Konfiguration finden Sie in der Dokumentation, die für Ihr SBC-Modell spezifisch ist.

Anrufe werden nach ca. 10 bis 20 Sekunden unterbrochen

Wenn ein eingehender Anruf zwischen 10 und 20 Sekunden nach dem Herstellen einer Verbindung abbricht und keine Audiodaten vorhanden sind, kann der Grund dafür sein, dass entweder keine Medieninformationen in diesem Zeitraum empfangen wurden oder die Ice-Verbindungsprüfungen (Interactive Connectivity Establishment) fehlgeschlagen sind. In dieser Situation fällt Teams den Anruf ab.

Lösung

Um dieses Problem zu beheben, stellen Sie sicher, dass die richtigen ICE-Kandidaten in der SDP-Nachricht vom SBC enthalten sind. Aktualisieren Sie außerdem die Netzwerk- und Firewallkonfigurationen entsprechend, um sicherzustellen, dass sie die Anforderungen und Antworten von ICE-Kandidaten verarbeiten können.

Anrufe fallen nach mehreren Minuten ab.

Ein fortlaufender Aufruf wird unterbrochen, ohne einen Fehlercode zurückzugeben, nachdem er eine Verbindung herstellt und zwischen 10 und 60 Minuten aktiv bleibt. Dieses Szenario kann auftreten, wenn sich ein Problem auf den Sitzungszeitgeber- oder Sitzungsaktualisierungsmechanismus auswirkt, der SESSION-EXPIRES im Header der SIP INVITE-Nachricht angegeben ist. Der Aufruf wird nach dem in der SESSION-EXPIRES Kopfzeile angegebenen Zeitpunkt beendet, es sei denn, eine erneute Aufforderung wird gesendet, um die Sitzung vor Ablauf der Zeit zu aktualisieren.

Im folgenden Beispiel gibt der SESSION-EXPIRES Header an, dass der Anruf nach 1.800 Sekunden endet (30 Minuten):

SESSION-EXPIRES : 1800;refresher=uac

Notiz

• Reinviten werden in der Regel an den halben Zeitpunkt gesendet, der vom Sitzungszeitgeber angegeben wird.
• Wenn der Wert des Parameters in der refresher Kopfzeile lautet uac, ist die Partei, die die SIP INVITE-Nachricht sendet, für das Senden des Erneutseinladungs zum Aktualisieren der Sitzung verantwortlich.
• Wenn der Wert des Parameters in der refresher Kopfzeile lautet uas, ist die Partei, die die SIP INVITE-Nachricht empfängt, für das Senden des Erneutseinladungs zum Aktualisieren der Sitzung verantwortlich.

Lösung

Um dieses Problem zu beheben, aktualisieren Sie Ihre SBC-Konfiguration, um sicherzustellen, dass die richtige Partei eine erneute Nachricht sendet, bevor der Sitzungszeitgeber abläuft.

Sitzungszeitgeberprobleme können auch in anderen Teilen des Anrufs auftreten, z. B. in einem PSTN-Netzbetreiber im Kommunikationspfad. Wenn der Anruf bei einem PSTN-Netzbetreiber fehlschlägt, sendet er eine SIP BYE-Nachricht an den SBC. Diese Nachricht wird dann an den SIP-Proxy gesendet, und der Proxy beendet den Anruf. Um dieses Problem zu beheben, ermitteln Sie die Quelle der SIP BYE-Nachricht, und beheben Sie dann das Problem an der Quelle.