Anrufe durch SIP-Trunk-Ausfall (Session Initiation Protocol)

Einführung

In diesem Dokument werden die Situationen beschrieben, in denen Anrufe über einen SIP-Trunk aufgrund verschiedener Ursachen fehlschlagen können. Wenn der Status des SIP (sofern OPTIONS Ping aktiviert ist) aktiviert ist, wird auf der CUCM-Web-GUI der Fehler "Kein Service" für den Trunk-Status auf der Seite Gerät >Trunk angezeigt.

Voraussetzungen

Anforderungen

Cisco empfiehlt, über Kenntnisse der Cisco Call Manager-Webadministration zu verfügen.

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf Cisco CallManager Server 11.5.

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines beliebigen Befehls verstehen.

Hintergrundinformationen

CUCM bietet Ihnen die Möglichkeit, den Status des konfigurierten SIP-Trunks zu überwachen. Das SIP-Profil verfügt über die Option zum Aktivieren des OPTIONS-Pings, wodurch die SIP-OPTION-Nachricht vom CUCM gesendet wird, dessen erfolgreiche Antwort darauf hinweist, dass der Trunk "in Service" ist.

Dieses Bild zeigt, wie ein SIP-Trunk-Status aussieht, wenn das SIP-Profil, das dem Trunk zugeordnet ist, den OPTIONS-Ping deaktiviert und aktiviert hat.

 Wenn der SIP-Trunk keine erfolgreiche Kommunikation mit dem Peer-End herstellen kann, wird der Status wie folgt angezeigt.

Das Real-Time Monitoring Tool kann auch Warnmeldungen wie diese Meldung auslösen.

Fehlermeldung:

"UC_CALLMANAGER-3-SIPTrunkOOS": Alle Remote-Peers sind außer Betrieb und können Anrufe für diesen SIP-Trunk-SIP-Trunk-Namen <NAME OF TRUNK> nicht verfügbare Remote-Peers mit Ursachencode <FEHLERCODE> nicht bearbeiten.

Überprüfen

Wenn der Trunk-Status "Kein Service" lautet, wird die Trunk-Konfigurationsseite wie in der Abbildung gezeigt angezeigt.

Der Status ist ausgefallen, während der Status-Grund entweder lokal=1, lokal=2 oder lokal=3 sein kann.

Ein "In Service"-Trunk sieht wie dieses Bild aus.

Fehlerbehebung

Szenario 1. Für Local=1 kann der Grund sein, dass nach allen erneuten Versuchen keine Antworten für die Options-Anfrage eingegangen sind, wenn der Transport als UDP im SIP-Trunk-Sicherheitsprofil konfiguriert wurde, das dem SIP-Trunk auf der ursprünglichen Seite zugewiesen ist. Die Paketerfassung vom Server würde so aussehen.

Wenn der Remote-Peer Unified CM ist, können Sie dieses Problem beheben. Navigieren Sie dann zum Remote-Peer-Serviceability > Tools > Control Center (Feature Services), und stellen Sie sicher, dass der Cisco Call Manager-Dienst aktiviert und gestartet ist.

Navigieren Sie außerdem zu Remote Peer Admin > Device > Trunk, und suchen Sie nach einem SIP-Trunk, um sicherzustellen, dass der eingehende Port im zugehörigen SIP-Trunk-Sicherheitsprofil mit dem SIP-Trunk-Zielport übereinstimmt, der auf der ursprünglichen Seite konfiguriert wurde.

Überprüfen Sie außerdem die Netzwerkverbindung mithilfe des CLI-Befehls utils network ping remote_peer am Ursprungsort.

Szenario 2. Für Local=2 könnte der Grund sein, dass Unified CM keine Socket-Verbindung mit dem Remote-Peer herstellen kann.

Um dieses Problem zu beheben, navigieren Sie zu Remote Peer Serviceability > Tools > Control Center (Feature Services) (Remote Peer-Serviceability > Tools > Control Center (Feature Services)), und stellen Sie sicher, dass der Cisco Call Manager-Dienst aktiviert und gestartet ist.

Navigieren Sie außerdem zu Remote Peer Admin > Device > Trunk, und suchen Sie nach einem SIP-Trunk, um sicherzustellen, dass der eingehende Port des zugehörigen SIP-Trunk-Sicherheitsprofils vorhanden ist, das so konfiguriert ist, dass er mit dem SIP-Trunk-Zielport identisch ist, der auf der ursprünglichen Seite konfiguriert wurde.

Überprüfen Sie außerdem die Netzwerkverbindung mit dem utils-Netzwerk, das den Ping remote_Peer auf der Ursprungsseite verwendet.

Wenn der Remote-Peer kein Unified CM ist, sollte der Benutzer sicherstellen, dass der Administrator der anderen Seite die Informationen von CUCM auf seinem Server korrekt erwähnt hat.

Szenario 3. Für Local=3 kann es sein, dass der DNS-Server nicht erreichbar ist oder DNS nicht korrekt konfiguriert ist, um den Hostnamen oder die SRV aufzulösen, die auf einem lokalen SIP-Trunk konfiguriert sind. Um dieses Problem zu beheben, navigieren Sie zu OS Administration > Show > Network (Betriebssystemverwaltung > anzeigen > Netzwerk), und überprüfen Sie die DNS-Details, um sicherzustellen, dass es korrekt ist. Falls nicht, konfigurieren Sie die richtigen DNS-Serverinformationen mithilfe des CLI-Befehls network dns primary. Überprüfen Sie außerdem die Netzwerkverbindung mit dem DNS-Server über das utils-Netzwerk ping remote_peer, und stellen Sie sicher, dass der DNS-Server korrekt konfiguriert ist.