Übersicht
Webex Calling unterstützt derzeit zwei Versionen von Local Gateway:
-
Lokales Gateway
-
Lokales Gateway für Webex für die Regierung
-
Bevor Sie beginnen, sollten Sie die Voraussetzungen für das Public Switched Telephone Network (PSTN) und das Local Gateway (LGW) für Webex Calling verstehen. Siehe Cisco bevorzugte Architektur für Webex-Callingfür weitere Informationen.
-
In diesem Artikel wird davon ausgegangen, dass eine dedizierte lokale Gateway-Plattform ohne vorhandene Sprachkonfiguration vorhanden ist. Wenn Sie ein bestehendes PSTN-Gateway oder eine CUBE Enterprise-Implementierung so ändern, dass es als Local Gateway-Funktion für Webex Calling verwendet wird, achten Sie auf die Konfiguration. Stellen Sie sicher, dass Sie die bestehenden Anrufströme und -funktionen nicht aufgrund der von Ihnen vorgenommenen Änderungen unterbrechen.
Die Prozeduren enthalten Links zur Befehlsreferenzdokumentation, wo Sie mehr über die einzelnen Befehlsoptionen erfahren können. Alle Befehlsreferenzlinks gehen zur Webex Managed Gateways Befehlsreferenz, sofern nicht anders angegeben (in diesem Fall gehen die Befehlslinks zur Cisco IOS Voice Befehlsreferenz). Sie können auf alle diese Leitfäden unter Cisco Unified Border Element zugreifen Befehlsreferenzen.
Informationen zu den unterstützten SBCs von Drittanbietern finden Sie in der jeweiligen Produktreferenzdokumentation.
Es gibt zwei Optionen, um das lokale Gateway für Ihren Webex Calling-Trunk zu konfigurieren:
-
Registrierungsbasierter Trunk
-
Zertifikatbasierter Trunk
Verwenden Sie den Aufgabenfluss entweder unter dem Registration-based Local Gateway oder Certificate-based Local Gateway um das lokale Gateway für Ihren Webex Calling-Trunk zu konfigurieren.
Siehe Starten Sie mit Local Gatewayfür weitere Informationen zu den verschiedenen Kofferraumtypen. Führen Sie auf dem lokalen Gateway selbst unter Verwendung der Befehlszeilenschnittstelle (Command Line Interface, CLI) die folgenden Schritte aus. Wir verwenden das Session Initiation Protocol (SIP) und den Transport Layer Security (TLS) Transport zur Sicherung des Trunk und das Secure Real Time Protocol (SRTP) zur Sicherung der Medien zwischen dem lokalen Gateway und Webex Calling.
-
Wählen Sie CUBE als Ihr lokales Gateway. Webex for Government unterstützt derzeit keine externen Session Border Controller (SBCs). Um die neueste Liste zu überprüfen, siehe Starten Sie mit Local Gateway.
- Installieren Sie Cisco IOS XE Dublin 17.12.1a oder spätere Versionen für alle Webex for Government Local Gateways.
-
Zur Überprüfung der Liste der Root Certificate Authorities (CAs), die Webex für staatliche Unterstützung benötigt, siehe Root-Zertifizierungsstellen für Webex for Government.
-
Details zu den externen Portbereichen für Local Gateway in Webex for Government finden Sie unter Netzanforderungen für Webex for Government (FedRAMP).
Local Gateway for Webex for Government unterstützt Folgendes nicht:
-
STUN/ICE-Lite zur Optimierung des Medienpfades
-
Fax (T.38)
Um das lokale Gateway für Ihren Webex Calling Trunk in Webex for Government zu konfigurieren, verwenden Sie die folgende Option:
-
Zertifikatbasierter Trunk
Verwenden Sie den Aufgabenfluss unter der Certificate-based Local Gateway um das lokale Gateway für Ihren Webex Calling-Trunk zu konfigurieren. Weitere Informationen zur Konfiguration eines zertifikatbasierten lokalen Gateways finden Sie unter Webex Calling zertifikatsbasierte Verbindung konfigurieren.
Es ist obligatorisch, FIPS-konforme GCM-Chiffrierer zu konfigurieren, um Local Gateway for Webex for Government zu unterstützen. Ist dies nicht der Fall, schlägt die Verbindungseinrichtung fehl. Details zur Konfiguration finden Sie unter Configure Webex Calling certificate-based trunk.
Webex for Government unterstützt kein registrierungsbasiertes lokales Gateway.
In diesem Abschnitt wird beschrieben, wie ein Cisco Unified Border Element (CUBE) als lokales Gateway für Webex Calling konfiguriert wird, wobei ein registrierender SIP-Trunk verwendet wird. Der erste Teil dieses Dokuments zeigt, wie ein einfaches PSTN-Gateway konfiguriert werden kann. In diesem Fall werden alle Anrufe aus dem PSTN an Webex Calling weitergeleitet und alle Anrufe aus Webex Calling werden an das PSTN weitergeleitet. Das Bild unten zeigt diese Lösung und die Konfiguration des High-Level-Call-Routing, die befolgt wird.
Bei dieser Konstruktion werden die folgenden Hauptkonfigurationen verwendet:
-
Mieter der Sprachklasse: Wird verwendet, um kofferraumspezifische Konfigurationen zu erstellen.
-
Sprachklasse-URI: Wird verwendet, um SIP-Nachrichten für die Auswahl eines eingehenden Dial-Peer zu klassifizieren.
-
Inbound-Dial-Peer: Bietet die Behandlung von eingehenden SIP-Nachrichten und bestimmt den ausgehenden Weg unter Verwendung einer Dial-Peer-Gruppe.
-
Dial-Peer-Gruppe: Definiert die Ausgangs-Einwahl-Peers, die für die Weiterleitung von Anrufen verwendet werden.
-
Ausgehender Dial-Peer: Behandelt ausgehende SIP-Nachrichten und leitet sie zum gewünschten Ziel.
Während IP und SIP zu den Standardprotokollen für PSTN-Trunks geworden sind, sind TDM (Time Division Multiplexing) ISDN-Schaltungen immer noch weit verbreitet und werden mit Webex Calling Trunks unterstützt. Um die Medienoptimierung von IP-Pfaden für lokale Gateways mit TDM-IP-Call-Flows zu ermöglichen, ist es derzeit notwendig, einen Zwei-Bein-Call-Routing-Prozess zu verwenden. Dieser Ansatz ändert die oben gezeigte Anrufrouting-Konfiguration, indem eine Reihe interner Loop-Back-Dial-Peers zwischen Webex Calling und PSTN-Trunks eingeführt wird, wie in der Abbildung unten dargestellt.
Wenn Sie eine lokale Cisco Unified Communications Manager-Lösung mit Webex Calling verbinden, können Sie die einfache PSTN-Gateway-Konfiguration als Grundlage für den Aufbau der Lösung verwenden, die im folgenden Diagramm dargestellt ist. In diesem Fall bietet der Unified Communications Manager eine zentrale Weiterleitung und Behandlung aller PSTN- und Webex Calling-Anrufe an.
In diesem Dokument werden die im folgenden Bild dargestellten Hostnamen, IP-Adressen und Schnittstellen verwendet.
Verwenden Sie die Konfigurationsanleitung im restlichen Dokument, um Ihre Local Gateway-Konfiguration wie folgt abzuschließen:
-
Schritt 1: Konfiguration der Router-Basiskonnektivität und -sicherheit
-
Schritt 2: Webex-Anruf-Trunk konfigurieren
Je nach gewünschter Architektur folgen Sie entweder:
-
Schritt 3: Lokale Gateway mit SIP PSTN-Trunk konfigurieren
-
Schritt 4: Lokales Gateway mit einer vorhandenen Unified CM-Umgebung konfigurieren
Oder:
-
Schritt 3: Lokales Gateway mit TDM PSTN-Trunk konfigurieren
Basiskonfiguration
Der erste Schritt bei der Vorbereitung Ihres Cisco-Routers als lokales Gateway für Webex Calling besteht darin, eine Basiskonfiguration zu erstellen, die Ihre Plattform sichert und Konnektivität herstellt.
-
Alle registrierungsbasierten Local Gateway-Implementierungen erfordern Cisco IOS XE 17.6.1a oder spätere Versionen. Cisco IOS 17.12.2 oder neuer wird empfohlen. Für die empfohlenen Versionen siehe die Cisco-SoftwareforschungSeite. Suchen Sie nach der Plattform und wählen Sie eine der vorgeschlagenen Versionen aus.
-
Router der ISR4000-Serie müssen mit Lizenzen für Unified Communications und Security-Technologie konfiguriert werden.
-
Catalyst Edge-Router 8000 mit Sprachkarten oder DSPs benötigen eine DNA-Advantage-Lizenz. Router ohne Sprachkarten oder DSPs benötigen ein Minimum an DNA Essentials Lizenzierung.
-
-
Erstellen Sie eine Basiskonfiguration für Ihre Plattform, die Ihren Geschäftsrichtlinien entspricht. Konfigurieren und überprüfen Sie insbesondere Folgendes:
-
NTP
-
Acls
-
Benutzerauthentifizierung und Fernzugriff
-
DNS
-
IP-Routing
-
IP-Adressen
-
-
Das Netzwerk für Webex Calling muss eine IPv-Adresse4 verwenden.
-
Laden Sie das Cisco Root-CA-Bundle in das Local Gateway hoch.
Bei der Konfiguration der Mandantenseite zur Verbindung mit Webex Calling werden nur SRV-basierte Adressen unterstützt.
Konfiguration
| 1 |
Stellen Sie sicher, dass Sie allen Layer-Schnittstellen gültige und routable IP-Adressen 3 zuweisen, zum Beispiel:
|
| 2 |
Schützen Sie Registrierung und STUN-Anmeldedaten auf dem Router mit symmetrischer Verschlüsselung. Konfigurieren Sie den primären Verschlüsselungsschlüssel und den Verschlüsselungstyp wie folgt:
|
| 3 |
Erstellen Sie einen Platzhalter PKI Trustpoint. Benötigt diesen Trustpoint, um TLS zu einem späteren Zeitpunkt zu konfigurieren. Für registrierungsbasierte Trunks benötigt dieser Trustpoint kein Zertifikat - wie für einen zertifikatbasierten Trunk erforderlich.
|
| 4 |
Aktivieren Sie TLS1.2-Exklusivität und geben Sie den Standard-Trustpoint mit den folgenden Konfigurationsbefehlen an. Aktualisieren Sie die Transportparameter, um eine zuverlässige und sichere Verbindung für die Registrierung zu gewährleisten: Der Befehl
|
| 5 |
Installieren Sie das Cisco Root CA-Bundle, das das IdenTrust Commercial Root CA-Zertifikat1 von Webex Calling enthält. Benutzen Sie crypto pki trustpool import clean url Befehl zum Herunterladen des Root-CA-Bündels von der angegebenen URL und zum Löschen des aktuellen CA-Trustpools, dann installieren Sie das neue Bündel von Zertifikaten: Wenn Sie einen Proxy für den Zugriff auf das Internet mit HTTPS verwenden müssen, fügen Sie vor dem Importieren des CA-Bündels die folgende Konfiguration hinzu: ip http client proxy-server yourproxy.com proxy-port 80
|
| 1 |
Erstellen Sie einen registrierungsbasierten PSTN-Trunk für einen bestehenden Standort im Control Hub. Notieren Sie sich die Stammdaten, die nach der Erstellung des Stamms zur Verfügung gestellt werden. Die in der Abbildung hervorgehobenen Details werden in den Konfigurationsschritten in dieser Anleitung verwendet. Weitere Informationen unter Konfigurieren von Trunks, Routengruppen und Einwahlplänen für Webex Calling.
|
| 2 |
Geben Sie die folgenden Befehle ein, um CUBE als Webex Calling Local Gateway zu konfigurieren:
Hier ist eine Erklärung der Felder für die Konfiguration:
Aktiviert Cisco Unified Border Element (CUBE) Funktionen auf der Plattform. media statisticsAktiviert die Medienüberwachung auf dem lokalen Gateway. media bulk-statsErmöglicht der Steuerungsebene, in der Datenebene Massenanrufstatistiken zu erstellen. Weitere Informationen zu diesen Befehlen finden Sie unter Medien. allow-connections sip to sipAktivieren Sie CUBE grundlegende SIP-Back-to-Back-User-Agent-Funktionalität. Weitere Informationen unter Verbindungen zulassen. Standardmäßig ist T.38 Faxtransport aktiviert. Weitere Informationen unter Faxprotokoll t38(Sprachdienst). Ermöglicht STUN (Session Traversal of UDP through NAT) weltweit.
Weitere Informationen unter Betäubungsmittelflussdaten-Agent-IDund Betäubungsmittelflussdaten geheim. asymmetric payload fullKonfiguriert asymmetrische SIP-Payload-Unterstützung für DTMF- und dynamische Codec-Payloads. Weitere Informationen unter asymmetrische Nutzlast. early-offer forcedZwingt das lokale Gateway dazu, SDP-Informationen in der ersten INVITE-Nachricht zu senden, anstatt auf die Bestätigung des benachbarten Peers zu warten. Weitere Informationen zu diesem Befehl finden Sie unter Frühangebot. |
| 3 |
Konfiguration voice class codec 100 G.711-Codecs werden nur für alle Trunks zugelassen. Dieser einfache Ansatz eignet sich für die meisten Implementierungen. Falls erforderlich, können zusätzliche Codec-Typen, die sowohl von Ursprungs- als auch von Abbruchsystemen unterstützt werden, in die Liste aufgenommen werden. Komplexere Lösungen, die TranskodierungDie Verwendung von DSP-Modulen wird unterstützt, aber nicht in diesem Leitfaden enthalten.
Hier ist eine Erklärung der Felder für die Konfiguration: voice class codec 100Wird verwendet, um nur bevorzugte Codecs für SIP-Trunk-Anrufe zuzulassen. Weitere Informationen unter Sprachklasse-Codec. |
| 4 |
Konfiguration voice class stun-usage 100 um ICE auf dem Webex Calling Trunk zu aktivieren.
Hier ist eine Erklärung der Felder für die Konfiguration: stun usage ice liteWird verwendet, um ICE-Lite für alle Webex-Calling-Zifferblattkollegen zu aktivieren, um die Medienoptimierung wann immer möglich zu ermöglichen. Weitere Informationen unter Sprachklasse-Betäubungund Betäubung Verwendung ice lite. Medienoptimierung wird wo immer möglich verhandelt. Wenn ein Anruf Cloud-Mediendienste wie Aufzeichnung erfordert, können die Medien nicht optimiert werden. |
| 5 |
Konfigurieren Sie die Medienverschlüsselungsrichtlinie für den Webex-Verkehr.
Hier ist eine Erklärung der Felder für die Konfiguration: voice class srtp-crypto 100Gibt SHA1_80 als die einzige SRTP-Chiffriersuite CUBE im SDP in Angebots- und Antwortnachrichten an. Webex Calling unterstützt nur SHA1_80. Weitere Informationen unter Sprachklasse SRTP-Crypto. |
| 6 |
Konfigurieren Sie ein Muster, um Anrufe zu einem Local Gateway-Trunk basierend auf seinem Zieltrunk-Parameter zu identifizieren:
Hier ist eine Erklärung der Felder für die Konfiguration: voice class uri 100 sipLegt ein Muster fest, das einer eingehenden SIP-Einladung zu einem eingehenden Trunk-Dial-Peer entspricht. Wenn Sie dieses Muster eingeben, verwenden Sie dtg= gefolgt von dem Stamm-OTG/DTG-Wert, der im Control Hub bei der Erstellung des Stammes angegeben wurde. Weitere Informationen unter Sprachklasse-URI. |
| 7 |
Konfiguration sip profile 100, die verwendet werden, um SIP-Nachrichten zu ändern, bevor sie an Webex Calling gesendet werden.
Hier ist eine Erklärung der Felder für die Konfiguration:
US-amerikanischer oder kanadischer PSTN-Anbieter können die Anrufer-ID-Verifizierung für Spam- und Betrugsanrufe anbieten, mit der zusätzlichen Konfiguration, die in der Anzeige von Spam- oder Betrugsanrufen in Webex CallingArtikel. |
| 8 |
Webex Calling Trunk konfigurieren: |
| 9 |
Verwenden Sie diese Befehle, um Netzwerkgeräte wie CUBE zu konfigurieren und Header des Session Initiation Protocol (SIP) weiterzuleiten, die das Gerät nicht verarbeitet. Diese Befehle ermöglichen es dem Gerät, nicht unterstützte SIP-Header, einschließlich Geo-Location-Header und PIDF-LO (Presence Information Data Format - Location Object), auf dem lokalen Gateway zu durchlaufen. Diese Funktionalität unterstützt Nomadische E911-Dienste, indem sie sicherstellen, dass kritische Standortinformationen korrekt gespeichert und weitergeleitet werden. |
Nachdem Sie den Mieter definiert haben 100 und einen SIP VoIP-Dial-Peer konfigurieren. Das Gateway leitet eine TLS-Verbindung in Richtung Webex Calling ein. An dieser Stelle legt der Access SBC sein Zertifikat dem Local Gateway vor. Das lokale Gateway validiert das SBC-Zertifikat für Webex Calling Access unter Verwendung des CA-Root-Bündels, das zuvor aktualisiert wurde. Wenn das Zertifikat erkannt wird, wird eine persistente TLS-Sitzung zwischen dem lokalen Gateway und dem Webex Calling Access SBC eingerichtet. Das Local Gateway kann diese sichere Verbindung nutzen, um sich beim Webex Access SBC zu registrieren. Wenn die Registrierung zur Authentifizierung angefochten wird:
-
Der Befehl username, password, und realm Parameter aus dem credentials Konfiguration wird in der Antwort verwendet.
-
Die Änderungsregeln im sip-Profil 100 werden verwendet, um die SIPS-URL zurück in SIP zu konvertieren.
Die Registrierung ist erfolgreich, wenn von der Zugangs-SBC ein 200 OK empfangen wurde.

Nachdem Sie oben einen Trunk zu Webex Calling aufgebaut haben, verwenden Sie die folgende Konfiguration, um einen nicht verschlüsselten Trunk zu einem SIP-basierten PSTN-Anbieter zu erstellen:
Wenn Ihr Dienstleister einen sicheren PSTN-Trunk anbietet, können Sie eine ähnliche Konfiguration wie oben für den Webex Calling-Trunk durchführen. CUBE unterstützt sicheres Anrufrouting.
Wenn Sie einen TDM / ISDN PSTN-Trunk verwenden, gehen Sie zum nächsten Abschnitt Lokales Gateway mit TDM PSTN-Trunk konfigurieren.
Zur Konfiguration von TDM-Schnittstellen für PSTN-Call-Legs auf den Cisco TDM-SIP Gateways siehe ISDN PRI konfigurieren.
| 1 |
Konfigurieren Sie den folgenden Sprachklassen-URI, um eingehende Anrufe aus dem PSTN-Trunk zu identifizieren:
Hier ist eine Erklärung der Felder für die Konfiguration: voice class uri 200 sipLegt ein Muster fest, das einer eingehenden SIP-Einladung zu einem eingehenden Trunk-Dial-Peer entspricht. Verwenden Sie bei der Eingabe dieses Musters die IP-Adresse Ihres IP PSTN-Gateways. Weitere Informationen unter Sprachklasse-URI. |
| 2 |
Konfigurieren Sie den folgenden IP PSTN-Dial-Peer:
Hier ist eine Erklärung der Felder für die Konfiguration:
Definiert einen VoIP-Dial-Peer mit einem Tag von 200 und gibt eine aussagekräftige Beschreibung für einfache Verwaltung und Fehlerbehebung. Weitere Informationen unter Wählbare Stimme. destination-pattern BAD.BADBeim Routing ausgehender Anrufe unter Verwendung einer eingehenden Dial-Peer-Gruppe ist ein Dummy-Zielmuster erforderlich. In diesem Fall kann jedes gültige Zielmuster verwendet werden. Weitere Informationen unter Ziel-Muster (Schnittstelle). session protocol sipv2Gibt an, dass dieser Dial-Peer SIP-Call-Legs behandelt. Weitere Informationen unter Sitzungsprotokoll (Dial Peer). session target ipv4: 192.168.80.13Gibt die Zieladresse für Anrufe an den PSTN-Anbieter an. Dies kann entweder eine IP-Adresse oder ein DNS-Hostname sein. Weitere Informationen unter Sitzungsziel (VoIP-Dial-Peer). incoming uri via 200Gibt die Sprachklasse an, die verwendet wird, um eingehende Anrufe mit diesem Dial-Peer unter Verwendung der URI INVITE VIA-Header abzugleichen. Weitere Informationen unter eingehende URL.
voice-class sip asserted-id pai
(Optional) Aktiviert die Verarbeitung des P-Asserted-Identity-Headers und steuert, wie diese für den PSTN-Trunk verwendet wird. Bei Verwendung dieses Befehls wird für die abgehenden From- und P-Asserted-Identity-Header die von dem eingehenden Dial-Peer bereitgestellte rufende Partei-Identität verwendet. Wird dieser Befehl nicht verwendet, wird für die abgehenden Von- und Remote-Party-ID-Header die anrufende Partei-Identität des anrufenden Teilnehmers verwendet. Weitere Informationen unter Sprachklasse sip asserted-id.
bind control
source-interface
GigabitEthernet0/0/0
Konfiguriert die Quellschnittstelle und die zugehörige IP-Adresse für Nachrichten, die an den PSTN gesendet werden. Weitere Informationen unter Bindung. bind media source-interface GigabitEthernet0/0/0Konfiguriert die Quellschnittstelle und die zugehörige IP-Adresse für Medien, die an PSTN gesendet werden. Weitere Informationen unter Bindung. voice-class codec 100Konfiguriert den Dial-Peer, um die gemeinsame Codec-Filterliste 100 zu verwenden. Weitere Informationen unter Sprachklasse-Codec. dtmf-relay rtp-nteDefiniert RTP-NTE (RFC2833) als DTMF-Fähigkeit, die auf dem Call-Leg erwartet wird. Weitere Informationen unter DTMF-Relais (Voice over IP). no vadDeaktiviert die Erkennung von Sprachaktivitäten. Weitere Informationen unter vad (Zifferblatt-Peer). |
| 3 |
Wenn Sie Ihr lokales Gateway so konfigurieren, dass nur Anrufe zwischen Webex Calling und dem PSTN weitergeleitet werden, fügen Sie die folgende Konfiguration für das Anrufrouting hinzu. Wenn Sie Ihr Local Gateway mit einer Unified Communications Manager-Plattform konfigurieren, gehen Sie zum nächsten Abschnitt. |
Nachdem Sie einen Trunk in Richtung Webex Calling aufgebaut haben, erstellen Sie mit der folgenden Konfiguration einen TDM-Trunk für Ihren PSTN-Dienst mit Loop-Back-Call-Routing, um eine Medienoptimierung auf dem Webex-Call-Leg zu ermöglichen.
Wenn Sie keine IP-Media-Optimierung benötigen, befolgen Sie die Konfigurationsschritte für einen SIP PSTN-Trunk. Verwenden Sie anstelle des PSTN VoIP-Dial-Peer einen Voice-Port und POTS-Dial-Peer (wie in den Schritten 2 und 3 dargestellt).
| 1 |
Die Loop-Back-Dial-Peer-Konfiguration verwendet Dial-Peer-Gruppen und Call-Routing-Tags, um sicherzustellen, dass Anrufe korrekt zwischen Webex und dem PSTN verlaufen, ohne Call-Routing-Schleifen zu erstellen. Konfigurieren Sie die folgenden Übersetzungsregeln, die zum Hinzufügen und Entfernen der Call-Routing-Tags verwendet werden:
Hier ist eine Erklärung der Felder für die Konfiguration: voice translation-ruleVerwendet reguläre Ausdrücke, die in Regeln definiert sind, um Call-Routing-Tags hinzuzufügen oder zu entfernen. Über-dekadische Ziffern („A“) werden verwendet, um Klarheit für die Fehlerbehebung zu schaffen. In dieser Konfiguration wird das vom Translation-Profile 100 hinzugefügte Tag verwendet, um Anrufe von Webex Calling über die Loopback-Dial-Peers zum PSTN zu leiten. In ähnlicher Weise wird das vom Translation-Profile hinzugefügte Tag 200 verwendet, um Anrufe vom PSTN in Richtung Webex Calling zu leiten. Die Übersetzungsprofile 11 und 12 entfernen diese Tags, bevor die Anrufe an die Webex- bzw. PSTN-Trunks gesendet werden. Dieses Beispiel geht davon aus, dass angerufene Nummern von Webex Calling im +E.164-Format dargestellt werden. Regel 100 entfernt das führende +, um eine gültige angerufene Nummer beizubehalten. Regel 12 fügt dann beim Entfernen des Tags eine nationale oder internationale Routing-Ziffer(n) hinzu. Verwenden Sie Ziffern, die Ihrem lokalen nationalen ISDN-Ziffernplan entsprechen. Wenn Webex Calling Nummern im nationalen Format anzeigt, passen Sie die Regeln 100 und 12 an, um das Routing-Tag einfach hinzuzufügen bzw. zu entfernen. Weitere Informationen unter Sprachübersetzungsprofilund Sprachübersetzungsregel. |
| 2 |
Konfigurieren Sie die Ports der TDM-Sprachschnittstelle gemäß dem verwendeten Trunk-Typ und dem verwendeten Protokoll. Weitere Informationen unter ISDN PRI konfigurieren. Die Grundkonfiguration einer Primary Rate ISDN-Schnittstelle, die im NIM-Slot 2 eines Geräts installiert ist, kann beispielsweise Folgendes umfassen:
|
| 3 |
Konfigurieren Sie den folgenden TDM PSTN-Dial-Peer:
Hier ist eine Erklärung der Felder für die Konfiguration:
Definiert einen VoIP-Dial-Peer mit einem Tag von 200 und gibt eine aussagekräftige Beschreibung für einfache Verwaltung und Fehlerbehebung. Weitere Informationen unter Gegenstimme. destination-pattern BAD.BADBeim Routing ausgehender Anrufe unter Verwendung einer eingehenden Dial-Peer-Gruppe ist ein Dummy-Zielmuster erforderlich. In diesem Fall kann jedes gültige Zielmuster verwendet werden. Weitere Informationen unter Ziel-Muster (Schnittstelle). translation-profile incoming 200Weist das Übersetzungsprofil zu, das der eingehenden angerufenen Nummer ein Anrufrouting-Tag hinzufügen wird. direct-inward-dialLeitet den Anruf ohne einen sekundären Wählton. Weitere Informationen unter Zifferblatt nach innen. port 0/2/0:15Der physische Sprachanschluss, der mit diesem Dial-Peer verbunden ist. |
| 4 |
Um die Medienoptimierung von IP-Pfaden für lokale Gateways mit TDM-IP-Anrufströmen zu ermöglichen, können Sie das Anrufrouting ändern, indem Sie eine Reihe interner Loop-Back-Dial-Peers zwischen Webex Calling und PSTN-Trunks einführen. Konfigurieren Sie die folgenden Loop-Back-Dial-Peers. In diesem Fall werden alle eingehenden Anrufe zunächst auf Dial-Peer 10 und von dort auf Basis des angewendeten Routing-Tags entweder auf Dial-Peer 11 oder auf 12 geleitet. Nach dem Entfernen des Routing-Tags werden Anrufe mit Dial-Peer-Gruppen an den ausgehenden Trunk weitergeleitet.
Hier ist eine Erklärung der Felder für die Konfiguration:
Definiert einen VoIP-Dial-Peer und gibt eine aussagekräftige Beschreibung für einfache Verwaltung und Fehlerbehebung. Weitere Informationen unter Gegenstimme. translation-profile incoming 11Wendet das zuvor definierte Übersetzungsprofil an, um das Call-Routing-Tag zu entfernen, bevor es zum ausgehenden Trunk weitergeleitet wird. destination-pattern BAD.BADBeim Routing ausgehender Anrufe unter Verwendung einer eingehenden Dial-Peer-Gruppe ist ein Dummy-Zielmuster erforderlich. Weitere Informationen unter Ziel-Muster (Schnittstelle). session protocol sipv2Gibt an, dass dieser Dial-Peer SIP-Call-Legs behandelt. Weitere Informationen unter Sitzungsprotokoll (Dial Peer). session target ipv4: 192.168.80.14Gibt die Adresse der lokalen Router-Schnittstelle als Anrufziel für den Loop-Back an. Weitere Informationen unter Sitzungsziel (Voip Dial Peer). bind control source-interface GigabitEthernet0/0/0Konfiguriert die Quellschnittstelle und die zugehörige IP-Adresse für Nachrichten, die über den Loop-Back gesendet werden. Weitere Informationen unter Bindung. bind media source-interface GigabitEthernet0/0/0Konfiguriert die Quellschnittstelle und die zugehörige IP-Adresse für Medien, die über den Loop-Back gesendet werden. Weitere Informationen unter Bindung. dtmf-relay rtp-nteDefiniert RTP-NTE (RFC2833) als DTMF-Fähigkeit, die auf dem Call-Leg erwartet wird. Weitere Informationen unter DTMF-Relais (Voice over IP). codec g711alaw Zwingt alle PSTN-Anrufe zur Verwendung von G.711. Wählen Sie a-law oder u-law, um der von Ihrem ISDN-Dienst verwendeten Companding-Methode zuzustimmen. no vadDeaktiviert die Erkennung von Sprachaktivitäten. Weitere Informationen unter vad (Zifferblatt-Peer). |
| 5 |
Fügen Sie die folgende Konfiguration des Anrufs hinzu: Damit ist Ihre Local Gateway-Konfiguration abgeschlossen. Speichern Sie die Konfiguration und laden Sie die Plattform neu, wenn CUBE-Funktionen zum ersten Mal konfiguriert werden.
|
Die PSTN-Webex Calling-Konfiguration in den vorherigen Abschnitten kann geändert werden, um zusätzliche Trunks zu einem Cisco Unified Communications Manager (UCM)-Cluster aufzunehmen. In diesem Fall werden alle Anrufe über Unified CM geleitet. Anrufe von UCM auf dem Port 5060 werden zum PSTN geleitet und Anrufe vom Port 5065 werden zu Webex Calling geleitet. Die folgenden inkrementellen Konfigurationen können hinzugefügt werden, um dieses aufrufende Szenario zu berücksichtigen.
Wenn Sie den Webex-Calling-Trunk in Unified CM erstellen, stellen Sie sicher, dass Sie den eingehenden Port in den Einstellungen des SIP-Trunk-Sicherheitsprofils auf 5065 konfigurieren. Dies erlaubt eingehende Nachrichten auf Port 5065 und füllt den VIA-Header mit diesem Wert aus, wenn Nachrichten an das lokale Gateway gesendet werden.

| 1 |
Konfigurieren Sie die folgenden Sprachklassen-URIs: |
| 2 |
Konfigurieren Sie die folgenden DNS-Datensätze, um das SRV-Routing zu Unified CM-Hosts anzugeben: IOS XE verwendet diese Datensätze zur lokalen Bestimmung von Ziel-UCM-Hosts und -Ports. Mit dieser Konfiguration ist es nicht erforderlich, Datensätze in Ihrem DNS-System zu konfigurieren. Wenn Sie lieber Ihren DNS verwenden, sind diese lokalen Konfigurationen nicht erforderlich.
Hier ist eine Erklärung der Felder für die Konfiguration: Der folgende Befehl erstellt einen DNS SRV-Ressourcendatensatz. Erstellen Sie für jeden UCM-Host und jeden Trunk einen Datensatz: ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: SRV-Ressourcensatzname 2: Die SRV-Ressourcendatensatzpriorität 1: Das SRV-Ressourcenrekordgewicht 5060: Portnummer, die für den Zielhost in diesem Ressourcendatensatz verwendet werden soll ucmsub5.mydomain.com: Der Ressourcen-Datensatz-Zielhost Erstellen Sie lokale DNS A-Datensätze, um die Hostnamen der Ressourcendatensätze zu lösen. Beispiel: ip host ucmsub5.mydomain.com 192.168.80.65 ip-Host: Erstellt einen Datensatz in der lokalen IOS XE Datenbank. ucmsub5.mydomain.com: Der Name des A-Datensatzes. 192.168.80.65: Die Host-IP-Adresse. Erstellen Sie die SRV-Ressourcendatensätze und A-Datensätze, die Ihre UCM-Umgebung und die bevorzugte Anrufverteilungsstrategie widerspiegeln. |
| 3 |
Konfigurieren Sie die folgenden Zifferblattgleichungen: |
| 4 |
Fügen Sie das Anrufrouting unter Verwendung der folgenden Konfigurationen hinzu: |
Diagnosezeichen (Diagnostic Signatures, DS) erkennt proaktiv häufig beobachtete Probleme im IOS XE-basierten lokalen Gateway und generiert eine E-Mail-, Syslog- oder Terminal-Benachrichtigung für das Ereignis. Sie können das DS auch installieren, um die Diagnosedatenerfassung zu automatisieren und die gesammelten Daten in den Cisco TAC-Fall zu übertragen, um die Auflösungszeit zu beschleunigen.
Diagnose-Signaturen (DS) sind XML-Dateien, die Informationen über Problemlöseereignisse und Maßnahmen enthalten, die durchgeführt werden, um das Problem zu informieren, zu beheben und zu beheben. Sie können die Logik der Problemerkennung mithilfe von Syslog-Nachrichten, SNMP-Ereignissen und durch regelmäßige Überwachung bestimmter Show-Kommandoausgänge definieren.
Die Aktionstypen umfassen das Sammeln der Show-Befehlsausgabe:
-
Erstellen einer konsolidierten Protokolldatei
-
Hochladen der Datei an einen vom Benutzer bereitgestellten Netzwerkstandort wie HTTPS, SCP, FTP-Server.
TAC-Techniker erstellen die DS-Dateien und signieren sie digital für einen Integritätsschutz. Jede DS-Datei hat eine eindeutige numerische ID, die vom System zugewiesen wird. Tool zum Nachschlagen von Diagnosesignaturen(DSLT) ist eine einzige Quelle, um geeignete Signaturen für die Überwachung und Fehlerbehebung verschiedener Probleme zu finden.
Vorbereitungen:
-
Bearbeiten Sie nicht die DS-Datei, von der Sie herunterladen DSLT. Die Dateien, die Sie ändern, können aufgrund eines Fehlers bei der Integritätsprüfung nicht installiert werden.
-
Ein SMTP-Server (Simple Mail Transfer Protocol), den Sie zum Senden von E-Mail-Benachrichtigungen für das lokale Gateway benötigen.
-
Stellen Sie sicher, dass im Local Gateway IOS XE 17.6.1 oder höher ausgeführt wird, wenn Sie den sicheren SMTP-Server für E-Mail-Benachrichtigungen verwenden möchten.
Voraussetzungen
Lokales Gateway mit IOS XE 17.6.1a oder höher
-
Diagnosesignaturen sind standardmäßig aktiviert.
-
Konfigurieren Sie den sicheren E-Mail-Server, der verwendet wird, um proaktive Benachrichtigungen zu senden, wenn auf dem Gerät Cisco IOS XE 17.6.1a oder höher ausgeführt wird.
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls end -
Konfigurieren Sie die Umgebungsvariable ds_email mit der E-Mail-Adresse des Administrators, um Sie zu benachrichtigen.
configure terminal call-home diagnostic-signature environment ds_email <email address> end
Die folgende Abbildung zeigt eine beispielhafte Konfiguration eines Local Gateway, das auf Cisco IOS XE läuft. 17.6.1a oder höher, um die proaktiven Benachrichtigungen an tacfaststart@gmail.comVerwendung von Gmail als sicheren SMTP-Server:
Wir empfehlen Ihnen, die Cisco IOS XE Bengaluru 17.6.x oder spätere Versionen zu verwenden.
call-home
mail-server tacfaststart:password@smtp.gmail.com priority 1 secure tls
diagnostic-signature
environment ds_email "tacfaststart@gmail.com"
Ein lokales Gateway, das auf der Cisco IOS XE-Software ausgeführt wird, ist kein typischer webbasierter Gmail-Client, der OAuth unterstützt. Daher müssen wir eine bestimmte Gmail-Kontoeinstellung konfigurieren und eine bestimmte Berechtigung erteilen, damit die E-Mail vom Gerät korrekt verarbeitet wird:
-
Rufen Sie auf. und schalten Sie Less secure app access Einstellung.
-
Antworten Sie auf "Ja, es war ich", wenn Sie eine E-Mail von Gmail mit dem Hinweis "Google hat jemanden daran gehindert, sich mit einer Nicht-Google-App bei Ihrem Konto anmelden" zu erhalten.
Installieren von Diagnosesignaturen für proaktive Überwachung
Überwachen einer hohen CPU-Auslastung
Dieser DS verfolgt die CPU-Auslastung fünf Sekunden lang mit dem SNMP OID 1.3.6.1.4.1.9.2.1.56. Wenn die Auslastung 75% oder mehr erreicht, deaktiviert sie alle Debugs und deinstalliert alle Diagnosesignaturen, die im lokalen Gateway installiert sind. Führen Sie die folgenden Schritte aus, um die Signatur zu installieren.
-
Benutzen Sie show snmp Befehl zum Aktivieren von SNMP. Wenn Sie diese Option nicht aktivieren, konfigurieren Sie die snmp-server manager Befehl.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled -
DS herunterladen 64224Verwendung der folgenden Dropdown-Optionen in Tool zum Nachschlagen von Diagnosesignaturen:
Feldname
Feldwert
Plattform
Cisco 4300, 4400 ISR Series oder Cisco CSR 1000V Series
Produkt
CUBE Enterprise in Webex Calling-Lösung
Problemumfang
Performance
Problemtyp
Hohe CPU-Auslastung mit E-Mail-Benachrichtigung.
-
Kopieren Sie die DS-XML-Datei in den Flash des lokalen Gateways.
LocalGateway# copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:Im folgenden Beispiel wird das Kopieren der Datei von einem FTP-Server auf das lokale Gateway veranschaulicht.
copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 bytes] 3571 bytes copied in 0.064 secs (55797 bytes/sec) -
Installieren Sie die DS-XML-Datei auf dem lokalen Gateway.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success -
Benutzen Sie show call-home diagnostic-signature Befehl, um zu überprüfen, ob die Signatur erfolgreich installiert wurde. Die Statusspalte sollte einen Wert „registriert“ haben.
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.comLaden Sie Diagnosesignaturen herunter:
DS-ID
DS-Name
Revision
Status
Letzte Aktualisierung (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Registriert
2020-11-07 22:05:33
Wenn ausgelöst, deinstalliert diese Signatur alle laufenden Diagnosesignaturen, einschließlich sich selbst. Falls erforderlich, installieren Sie DS 64224 neu, um die hohe CPU-Auslastung auf dem Local Gateway weiter zu überwachen.
Überwachung der Registrierung des SIP-Trunks
Dieser DS prüft alle 60 Sekunden die Aufhebung der Registrierung eines Local Gateway SIP Trunk mit der Webex Calling Cloud. Nachdem das Ereignis bei einer nicht registrierten Registrierung erkannt wurde, generiert es eine E-Mail- und Syslog-Benachrichtigung und deinstalliert sich selbst nach zwei Ereignissen ohne Registrierung. Verwenden Sie die folgenden Schritte, um die Signatur zu installieren:
-
DS herunterladen 64117Verwendung der folgenden Dropdown-Optionen in Tool zum Nachschlagen von Diagnosesignaturen:
Feldname
Feldwert
Plattform
Cisco 4300, 4400 ISR Series oder Cisco CSR 1000V Series
Produkt
CUBE Enterprise in Webex Calling-Lösung
Problemumfang
SIP-SIP
Problemtyp
SIP-Übertragungsweg die Registrierung mit E-Mail-Benachrichtigung ändern.
-
Kopieren Sie die DS-XML-Datei auf das lokale Gateway.
copy ftp://username:password@<server name or ip>/DS_64117.xml bootflash: -
Installieren Sie die DS-XML-Datei auf dem lokalen Gateway.
call-home diagnostic-signature load DS_64117.xml Load file DS_64117.xml success LocalGateway# -
Benutzen Sie show call-home diagnostic-signature Befehl, um zu überprüfen, ob die Signatur erfolgreich installiert wurde. Die Statusspalte muss über einen "registrierten"-Wert verfügen.
Überwachung abnormaler Verbindungsunterbrechungen
Dieser DS nutzt die SNMP-Abfrage alle 10 Minuten, um abnormale Verbindungsabschaltung bei SIP-Fehlern 403, 488 und 503 zu erkennen. Wenn die Fehlerzählerhöhung größer oder gleich 5 aus der letzten Umfrage ist, wird eine Syslog- und E-Mail-Benachrichtigung generiert. Gehen Sie wie folgt vor, um die Signatur zu installieren.
-
Benutzen Sie show snmp Befehl, um zu überprüfen, ob SNMP aktiviert ist. Wenn es nicht aktiviert ist, konfigurieren Sie die snmp-server manager Befehl.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled -
DS herunterladen 65221Verwendung der folgenden Optionen in Tool zum Nachschlagen von Diagnosesignaturen:
Feldname
Feldwert
Plattform
Cisco 4300, 4400 ISR Series oder Cisco CSR 1000V Series
Produkt
CUBE Enterprise in Webex Calling-Lösung
Problemumfang
Performance
Problemtyp
Abnormale Sip-Anruf-Trennungserkennung mit E-Mail- und Syslog-Benachrichtigung.
-
Kopieren Sie die DS-XML-Datei auf das lokale Gateway.
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash: -
Installieren Sie die DS-XML-Datei auf dem lokalen Gateway.
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success -
Benutzen Sie show call-home diagnostic-signature Befehl, um zu überprüfen, ob die Signatur erfolgreich installiert wurde. Die Statusspalte muss über einen "registrierten"-Wert verfügen.
Installieren Sie Diagnosesignaturen, um ein Problem zu beheben
Verwenden Sie Diagnose-Signaturen (DS), um Probleme schnell zu lösen. Die Cisco TAC-Techniker haben mehrere Signaturen erstellt, die die erforderlichen Debugs ermöglichen, um ein bestimmtes Problem zu beheben, das auftretende Problem zu erkennen, die richtigen Diagnosedaten zu erfassen und die Daten automatisch an den Cisco TAC-Fall zu übertragen. Diagnostische Signaturen (DS) machen es nicht erforderlich, manuell auf das Auftreten des Problems zu überprüfen, und erleichtern die Fehlersuche bei intermittierenden und vorübergehenden Problemen.
Sie können die Tool zum Nachschlagen von Diagnosesignaturenum die entsprechenden Signaturen zu finden und zu installieren, um ein bestimmtes Problem selbst zu lösen, oder Sie können die Signatur installieren, die vom TAC-Techniker im Rahmen des Support-Engagements empfohlen wird.
Hier ist ein Beispiel, wie ein DS gefunden und installiert wird, um das Auftreten „%VOICE_IEC-3-GW zu erkennen: CCAPI: Interner Fehler (Schwellenwert für Anrufspitze): IEC=1.1.181.1.29.0“ Syslog und automatisieren die Diagnosedatenerfassung mit den folgenden Schritten:
-
Konfigurieren Sie eine zusätzliche DS-Umgebungsvariable ds_fsurl_prefix, die der Cisco TAC-Dateiserver-Pfad (cxd.cisco.com) ist, auf den die gesammelten Diagnosedaten hochgeladen werden. Der Benutzername im Dateipfad ist die Fallnummer und das Passwort ist das Datei-Upload-Token, das abgerufen werden kann von Support-Fallmanagerim folgenden Befehl. Der Datei-Upload-Token kann bei Bedarf im Bereich Anhänge des Support Case Managers generiert werden.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" endBeispiel
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com" -
Stellen Sie sicher, dass SNMP über die show snmp Befehl. Wenn es nicht aktiviert ist, konfigurieren Sie die snmp-server manager Befehl.
show snmp %SNMP agent not enabled config t snmp-server manager end -
Stellen Sie sicher, dass High-CPU-Monitoring-DS 64224 als proaktive Maßnahme installiert wird, um alle Debugs- und Diagnosesignaturen während der Zeit hoher CPU-Auslastung zu deaktivieren. DS herunterladen 64224Verwendung der folgenden Optionen in Tool zum Nachschlagen von Diagnosesignaturen:
Feldname
Feldwert
Plattform
Cisco 4300, 4400 ISR Series oder Cisco CSR 1000V Series
Produkt
CUBE Enterprise in Webex Calling-Lösung
Problemumfang
Performance
Problemtyp
Hohe CPU-Auslastung mit E-Mail-Benachrichtigung.
-
DS herunterladen 65095Verwendung der folgenden Optionen in Tool zum Nachschlagen von Diagnosesignaturen:
Feldname
Feldwert
Plattform
Cisco 4300, 4400 ISR Series oder Cisco CSR 1000V Series
Produkt
CUBE Enterprise in Webex Calling-Lösung
Problemumfang
Syslogs
Problemtyp
Syslog - %VOICE_IEC-GW3: CCAPI: Interner Fehler (Schwellenwert für Anrufspitze): IEC=1.1.181.1.290
-
Kopieren Sie die DS-XML-Dateien auf das lokale Gateway.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash: -
Installieren Sie die High CPU Monitoring DS 64224 und dann die DS 65095 XML Datei im Local Gateway.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success call-home diagnostic-signature load DS_65095.xml Load file DS_65095.xml success -
Überprüfen Sie, ob die Signatur erfolgreich installiert wurde. show call-home diagnostic-signature Befehl. Die Statusspalte muss über einen "registrierten"-Wert verfügen.
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.comHeruntergeladene Diagnosesignaturen:
DS-ID
DS-Name
Revision
Status
Letzte Aktualisierung (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Registriert
2020-11-08
65095
00:12:53
DS_LGW_IEC_Call_spike_threshold
0.0.12
Registriert
2020-11-08
Ausführung von Diagnosesignaturen überprüfen
Im folgenden Befehl wird die Spalte „Status“ der show call-home diagnostic-signature Befehl ändert sich auf „läuft“, während das lokale Gateway die in der Signatur definierte Aktion ausführt. Die Ausgabe von show call-home diagnostic-signature statistics ist der beste Weg, um zu überprüfen, ob eine diagnostische Signatur ein interessierendes Ereignis erkennt und die Aktion ausführt. Die Spalte "Ausgelöst/Max/Deinstallieren" gibt an, wie oft die gegebenen Signatur ein Event ausgelöst hat, wie oft sie maximal zum Erkennen eines Events definiert wird und ob die Signatur sich selbst deinstalliert, nachdem die maximale Anzahl ausgelöster Ereignisse erkannt wurde.
show call-home diagnostic-signature
Current diagnostic-signature settings:
Diagnostic-signature: enabled
Profile: CiscoTAC-1 (status: ACTIVE)
Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService
Environment variable:
ds_email: carunach@cisco.com
ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com
Heruntergeladene Diagnosesignaturen:
|
DS-ID |
DS-Name |
Revision |
Status |
Letzte Aktualisierung (GMT+00:00) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0.0.10 |
Registriert |
2020-11-08 00:07:45 |
|
65095 |
DS_LGW_IEC_Call_spike_threshold |
0.0.12 |
Wird ausgeführt |
2020-11-08 00:12:53 |
Diagnose-/Unterschriftsstatistiken für Call-Home anzeigen
|
DS-ID |
DS-Name |
Ausgelöst/Max./Deinstall |
Durchschnittliche Ausführungszeit (Sekunden) |
Max. Ausführungszeit (Sekunden) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0/0/N |
0.000 |
0.000 |
|
65095 |
DS_LGW_IEC_Call_spike_threshold |
1/20/Y |
23.053 |
23.053 |
Die Benachrichtigungs-E-Mail, die während der Ausführung der Diagnosesignatur gesendet wird, enthält wichtige Informationen wie Problemtyp, Gerätedetails, Softwareversion, ausgeführte Konfiguration und Zeigt Befehlsausgabe an, die für die Behebung des jeweiligen Problems relevant sind.
Diagnosesignaturen deinstallieren
Die Verwendung von Diagnosesignaturen zur Fehlerbehebung ist in der Regel definiert, um nach der Erkennung einiger Problemereignisse zu deinstallieren. Wenn Sie eine Signatur manuell deinstallieren möchten, holen Sie die DS-ID aus der Ausgabe des show call-home diagnostic-signature und den folgenden Befehl ausführen:
call-home diagnostic-signature deinstall <DS ID>
Beispiel
call-home diagnostic-signature deinstall 64224
Das Diagnose-Signaturen-Lookup-Tool wird in regelmäßigen Abständen neue Signaturen hinzugefügt. Dies basiert auf Problemen, die häufig in Bereitstellungen beobachtet werden. TAC unterstützt derzeit keine Anfragen zur Erstellung neuer benutzerdefinierter Signaturen.
Für eine bessere Verwaltung von Cisco IOS XE Gateways empfehlen wir Ihnen, die Gateways über den Control Hub zu registrieren und zu verwalten. Es ist eine optionale Konfiguration. Wenn Sie sich angemeldet haben, können Sie die Konfigurationsvalidierungsoption im Control Hub verwenden, um Ihre Local Gateway-Konfiguration zu validieren und etwaige Konfigurationsprobleme zu identifizieren. Derzeit unterstützen nur registrierungsbasierte Trunks diese Funktionalität.
Weitere Informationen finden Sie unter:
In diesem Abschnitt wird beschrieben, wie ein Cisco Unified Border Element (CUBE) als lokales Gateway für Webex Calling unter Verwendung eines zertifikatbasierten, gegenseitigen TLS (mTLS) SIP-Trunk konfiguriert wird. Der erste Teil dieses Dokuments zeigt, wie ein einfaches PSTN-Gateway konfiguriert werden kann. In diesem Fall werden alle Anrufe aus dem PSTN an Webex Calling weitergeleitet und alle Anrufe aus Webex Calling werden an das PSTN weitergeleitet. Das folgende Bild zeigt diese Lösung und die Konfiguration des High-Level-Call-Routing, die befolgt wird.
Bei dieser Konstruktion werden die folgenden Hauptkonfigurationen verwendet:
-
Mieter der Sprachklasse: Wird verwendet, um kofferraumspezifische Konfigurationen zu erstellen.
-
Sprachklassenadresse: Wird verwendet, um SIP-Nachrichten für die Auswahl eines eingehenden Dial-Peer zu klassifizieren.
-
Inbound Dial-Peer: Bietet die Behandlung von eingehenden SIP-Nachrichten und bestimmt den ausgehenden Weg unter Verwendung einer Dial-Peer-Gruppe.
-
Dial-Peer-Gruppe: Definiert die Ausgangs-Einwahl-Peers, die für die Weiterleitung von Anrufen verwendet werden.
-
Outbound Dial-Peer: Behandelt ausgehende SIP-Nachrichten und leitet sie zum gewünschten Ziel.
Wenn Sie eine lokale Cisco Unified Communications Manager-Lösung mit Webex Calling verbinden, können Sie die einfache PSTN-Gateway-Konfiguration als Grundlage für den Aufbau der Lösung verwenden, die im folgenden Diagramm dargestellt ist. In diesem Fall bietet ein Unified Communications Manager eine zentrale Weiterleitung und Behandlung aller PSTN- und Webex Calling-Anrufe an.
In diesem Dokument werden die im folgenden Bild dargestellten Hostnamen, IP-Adressen und Schnittstellen verwendet. Es werden Optionen für die öffentliche oder private Adressierung (hinter NAT) bereitgestellt. SRV DNS-Datensätze sind optional, es sei denn, Lastausgleich über mehrere CUBE-Instanzen hinweg.
Verwenden Sie die Konfigurationsanleitung im restlichen Dokument, um Ihre Local Gateway-Konfiguration wie folgt abzuschließen:
Basiskonfiguration
Der erste Schritt bei der Vorbereitung Ihres Cisco-Routers als lokales Gateway für Webex Calling besteht darin, eine Basiskonfiguration zu erstellen, die Ihre Plattform sichert und Konnektivität herstellt.
-
Alle zertifikatbasierten Local Gateway-Implementierungen erfordern Cisco IOS XE 17.9.1a oder spätere Versionen. Cisco IOS XE 17.12.2 oder neuer wird empfohlen. Für die empfohlenen Versionen siehe die Cisco-SoftwareforschungSeite. Suchen Sie nach der Plattform und wählen Sie eine der vorgeschlagenen Versionen aus.
-
Router der ISR4000-Serie müssen mit Lizenzen für Unified Communications und Security-Technologie konfiguriert werden.
-
Catalyst Edge-Router 8000 mit Sprachkarten oder DSPs benötigen eine DNA-Advantage-Lizenz. Router ohne Sprachkarten oder DSPs benötigen ein Minimum an DNA Essentials Lizenzierung.
-
Für Anforderungen mit hoher Kapazität können Sie auch eine High Security (HSEC)-Lizenz und zusätzliche Durchsatzberechtigung benötigen.
Siehe Berechtigungscodesfür weitere Einzelheiten.
-
-
Erstellen Sie eine Basiskonfiguration für Ihre Plattform, die Ihren Geschäftsrichtlinien entspricht. Konfigurieren und überprüfen Sie insbesondere Folgendes:
-
NTP
-
Acls
-
Benutzerauthentifizierung und Fernzugriff
-
DNS
-
IP-Routing
-
IP-Adressen
-
-
Das Netzwerk für Webex Calling muss eine IPv-Adresse4 verwenden. Lokale Gateway Fully Qualified Domain Names (FQDN) oder Service Record (SRV)-Adressen, die im Control Hub konfiguriert sind, müssen sich zu einer öffentlichen IPv4-Adresse im Internet auflösen.
-
Alle SIP- und Media-Ports auf der Local Gateway-Schnittstelle mit Webex müssen über das Internet zugänglich sein, entweder direkt oder über statische NAT. Stellen Sie sicher, dass Sie Ihre Firewall entsprechend aktualisieren.
-
Befolgen Sie die folgenden detaillierten Konfigurationsschritte, um ein signiertes Zertifikat auf dem lokalen Gateway zu installieren:
-
Eine öffentliche Zertifizierungsstelle (CA), wie in Welche Root-Zertifikatsbehörden werden bei Anrufen an Cisco Webex Audio- und Video-Plattformen unterstützt?muss das Gerätezertifikat unterschreiben.
-
Zertifikate, die nur Server Authentication Extended Key Usage (EKU) enthalten, werden unterstützt. Webex Calling validiert oder erzwingt das Vorhandensein von Client Authentication EKU während der TLS-Handshake-Einrichtung nicht.
Einige externe Session Border Controller (SBC) können eine strenge EKU-Validierung durchsetzen und Zertifikate ablehnen, die keine Client Authentication EKU enthalten. Stellen Sie in solchen Fällen sicher, dass der SBC so konfiguriert ist, dass er nur Zertifikate mit Server Authentication EKU akzeptiert oder die strikte EKU-Validierung deaktiviert (falls unterstützt).
-
Der gemeinsame Name (CN) des Zertifikats oder einer der alternativen Namen des Probanden (SAN) muss mit dem im Control Hub konfigurierten FQDN übereinstimmen.
Beim Kauf eines Zertifikats mit Common Name (CN) oder Subject Alternative Name (SAN) stellen Sie sicher, dass das Zertifikat nur Kleinbuchstaben verwendet. In der Control Hub-Konfiguration werden alle FQDN-Einträge automatisch in Kleinbuchstaben umgewandelt, und jede Diskrepanz im Briefgehäuse zwischen dem FQDN und dem Zertifikat verhindert eine erfolgreiche Stammregistrierung.
Beispiel:
-
Wenn ein konfigurierter Trunk im Control Hub Ihrer Organisation cube1.lgw.com:5061 als FQDN des Local Gateway hat, muss der CN oder SAN im Router-Zertifikat cube1.lgw.com enthalten.
-
Wenn ein konfigurierter Trunk im Control Hub Ihrer Organisation lgws.lgw.com als SRV-Adresse des/der lokalen Gateways(s) vom Trunk aus erreichbar ist/sind, muss der CN oder SAN im Router-Zertifikat lgws.lgw.com enthalten. Die Datensätze, die SRV adresse in (CNAME, A Record oder IP Address) auflösen, sind in SAN optional.
-
Unabhängig davon, ob Sie einen FQDN oder SRV für den Trunk verwenden, muss die Kontaktadresse für alle neuen SIP-Dialoge von Ihrem lokalen Gateway den im Control Hub konfigurierten Namen verwenden.
-
-
-
Laden Sie das Cisco Root CA-Bundle in das Local Gateway hoch. Dieses Bündel enthält das CA-Stammzertifikat, das zur Überprüfung der Webex-Plattform verwendet wird.
Konfiguration
| 1 |
Stellen Sie sicher, dass Sie allen Layer-Schnittstellen gültige und routable IP-Adressen 3 zuweisen, zum Beispiel:
|
| 2 |
Schützen Sie STUN-Anmeldedaten auf dem Router mit symmetrischer Verschlüsselung. Konfigurieren Sie den primären Verschlüsselungsschlüssel und den Verschlüsselungstyp wie folgt:
|
| 3 |
Erstellen Sie einen Verschlüsselungs-Vertrauenspunkt mit einem Zertifikat für Ihre Domain, unterzeichnet von einem unterstütztZertifizierungsstelle (CA). |
| 4 |
Geben Sie das Zertifikat der zwischensignierenden CA an, um Ihr Host-Zertifikat zu authentifizieren. Geben Sie den folgenden exec- oder Konfigurationsbefehl ein:
|
| 5 |
Importieren Sie das signierte Host-Zertifikat mit dem folgenden exec- oder Konfigurationsbefehl:
|
| 6 |
Aktivieren Sie die Exklusivität von TLS1.2 und geben Sie den Standard-Trustpoint an, der für Sprachanwendungen mit den folgenden Konfigurationsbefehlen verwendet werden soll:
|
| 7 |
Installieren Sie das Cisco Root CA-Bundle, das das IdenTrust Commercial Root CA-Zertifikat 1 von Webex Calling enthält. Benutzen Sie crypto pki trustpool import clean url url Befehl zum Herunterladen des Root-CA-Bündels von der angegebenen URL und zum Löschen des aktuellen CA-Vertrauenspools, dann installieren Sie das neue Bündel von Zertifikaten: Wenn Sie einen Proxy für den Zugriff auf das Internet mit HTTPS verwenden müssen, fügen Sie vor dem Importieren des CA-Bündels die folgende Konfiguration hinzu: ip http client proxy-server yourproxy.com proxy-port 80
|
| 1 |
Erstellen Sie einen CUBE-zertifikatbasierten PSTN-Trunk für einen vorhandenen Standort im Control Hub. Weitere Informationen unter Konfigurieren von Trunks, Routengruppen und Einwahlplänen für Webex Calling. Notieren Sie sich die Stamminformationen zur Erstellung des Stamms. Diese Details, wie in der folgenden Abbildung hervorgehoben, werden bei den Konfigurationsschritten in dieser Anleitung verwendet.
|
| 2 |
Geben Sie die folgenden Befehle ein, um CUBE als Webex Calling Local Gateway zu konfigurieren:
Hier ist eine Erklärung der Felder für die Konfiguration:
Aktiviert Cisco Unified Border Element (CUBE) Funktionen auf der Plattform. allow-connections sip to sipAktivieren Sie die CUBE Basic SIP Back to Back User Agent Funktionalität. Weitere Informationen unter Verbindungen zulassen. Standardmäßig ist T.38 Faxtransport aktiviert. Weitere Informationen unter Faxprotokoll t38(Sprachdienst). Ermöglicht STUN (Session Traversal of UDP through NAT) weltweit. Diese globalen Betäubungsbefehle werden nur benötigt, wenn Sie Ihr lokales Gateway hinter NAT bereitstellen.
Weitere Informationen unter Betäubungsmittelflussdaten-Agent-IDund Betäubungsmittelflussdaten geheim. asymmetric payload fullKonfiguriert asymmetrische SIP-Payload-Unterstützung für DTMF- und dynamische Codec-Payloads. Weitere Informationen zu diesem Befehl finden Sie unter asymmetrische Nutzlast. early-offer forcedZwingt das lokale Gateway dazu, SDP-Informationen in der ersten INVITE-Nachricht zu senden, anstatt auf die Bestätigung des benachbarten Peers zu warten. Weitere Informationen zu diesem Befehl finden Sie unter Frühangebot. sip-profiles inboundErmöglicht CUBE die Verwendung von SIP-Profilen, um Nachrichten beim Empfang zu ändern. Profile werden über Dial-Peers oder Mieter angewendet. |
| 3 |
Konfiguration voice class codec 100 G.711-Codecs werden nur für alle Trunks zugelassen. Dieser einfache Ansatz eignet sich für die meisten Implementierungen. Falls erforderlich, fügen Sie der Liste zusätzliche Codec-Typen hinzu, die sowohl von Ursprungs- als auch von Abbruchsystemen unterstützt werden. Komplexere Lösungen, die TranskodierungDie Verwendung von DSP-Modulen wird unterstützt, aber nicht in diesem Leitfaden enthalten.
Hier ist eine Erklärung der Felder für die Konfiguration: voice class codec 100Wird verwendet, um nur bevorzugte Codecs für SIP-Trunk-Anrufe zuzulassen. Weitere Informationen unter Sprachklasse-Codec. |
| 4 |
Konfiguration voice class stun-usage 100 um ICE auf dem Webex Calling Trunk zu aktivieren. (Dieser Schritt gilt nicht für Webex for Government)
Hier ist eine Erklärung der Felder für die Konfiguration: stun usage ice liteWird verwendet, um ICE-Lite für alle Webex-Calling-Zifferblattkollegen zu aktivieren, um die Medienoptimierung wann immer möglich zu ermöglichen. Weitere Informationen unter Sprachklasse-Betäubungund Betäubung Verwendung ice lite. Der Befehl stun usage firewall-traversal flowdata Ein Befehl ist nur erforderlich, wenn Sie Ihr lokales Gateway hinter NAT bereitstellen. Medienoptimierung wird wo immer möglich verhandelt. Wenn ein Anruf Cloud-Mediendienste wie Aufzeichnung erfordert, können die Medien nicht optimiert werden. |
| 5 |
Konfigurieren Sie die Medienverschlüsselungsrichtlinie für den Webex-Verkehr. (Dieser Schritt gilt nicht für Webex for Government)
Hier ist eine Erklärung der Felder für die Konfiguration: voice class srtp-crypto 100Gibt SHA1_80 als die einzige SRTP-Chiffriersuite CUBE im SDP in Angebots- und Antwortnachrichten an. Webex Calling unterstützt nur SHA1_80. Weitere Informationen unter Sprachklasse SRTP-Crypto. |
| 6 |
Konfigurieren Sie FIPS-konforme GCM-Verschlüsselungen (Dieser Schritt gilt nur für Webex für staatliche Stellen).
Hier ist eine Erklärung der Felder für die Konfiguration: voice class srtp-crypto 100Gibt GCM als die Chiffre-Suite an, die CUBE anbietet. Es ist obligatorisch, GCM-Chiffrierer für Local Gateway für Webex for Government zu konfigurieren. |
| 7 |
Konfigurieren Sie ein Muster, um Anrufe zu einem Local Gateway-Trunk basierend auf seinem Ziel FQDN oder SRV eindeutig zu identifizieren:
Hier ist eine Erklärung der Felder für die Konfiguration: voice class uri 100 sipLegt ein Muster fest, das einer eingehenden SIP-Einladung zu einem eingehenden Trunk-Dial-Peer entspricht. Verwenden Sie bei der Eingabe dieses Musters die im Control Hub für den Stamm konfigurierte Stamm-FQDN oder SRV. Verwenden Sie bei der mandantenseitigen Konfiguration von zertifikatbasierten Trunks für Webex Calling nur SRV-basierte Webex Calling Edge-Adresse auf dem lokalen Gateway. FQDNs werden nicht mehr unterstützt. |
| 8 |
Konfiguration von SIP-Nachrichtenmanipulationsprofilen. Wenn Ihr Gateway mit einer öffentlichen IP-Adresse konfiguriert ist, konfigurieren Sie ein Profil wie folgt oder gehen Sie zum nächsten Schritt, wenn Sie NAT verwenden. In diesem Beispiel ist cube1.lgw.com der für das Local Gateway konfigurierte FQDN:
Hier ist eine Erklärung der Felder für die Konfiguration: Regeln 10 und 20Damit Webex Nachrichten von Ihrem lokalen Gateway authentifizieren kann, müssen die Kopfzeile „Kontakt“ in einer SIP-Anfrage und den Antwortnachrichten den Wert enthalten, der für den Trunk im Control Hub bereitgestellt wird. Dies ist entweder der FQDN eines einzelnen Hosts oder der SRV-Name, der für einen Cluster von Geräten verwendet wird. |
| 9 |
Wenn Ihr Gateway mit einer privaten IP-Adresse hinter statischem NAT konfiguriert ist, konfigurieren Sie die eingehenden und ausgehenden SIP-Profile wie folgt. In diesem Beispiel ist cube1.lgw.com die für das Local Gateway konfigurierte FQDN, „10.80.13.12“ die IP-Adresse der Schnittstelle für Webex Calling und „192.65.79.20“ die öffentliche IP-Adresse des NAT.
SIP-Profile für ausgehende Nachrichten an Webex Calling
Hier ist eine Erklärung der Felder für die Konfiguration: rules 10 and 20Damit Webex Nachrichten von Ihrem lokalen Gateway authentifizieren kann, muss die Kopfzeile „Kontakt“ in SIP-Anfrage- und Antwortnachrichten den Wert enthalten, der für den Trunk im Control Hub bereitgestellt wird. Dies ist entweder der FQDN eines einzelnen Hosts oder der SRV-Name, der für einen Cluster von Geräten verwendet wird. rules 30 to 81Konvertieren Sie private Adressverweise in die externe öffentliche Adresse der Website, so dass Webex nachfolgende Nachrichten korrekt interpretieren und weiterleiten kann. SIP-Profil für eingehende Nachrichten von Webex Calling
Hier ist eine Erklärung der Felder für die Konfiguration: rules 10 to 80Konvertiere öffentliche Adressverweise in die konfigurierte private Adresse, so dass CUBE die Nachrichten von Webex verarbeiten kann. Weitere Informationen unter Sprachklasse SIP-Profile. US-amerikanischer oder kanadischer PSTN-Anbieter können die Anrufer-ID-Verifizierung für Spam- und Betrugsanrufe anbieten, mit der zusätzlichen Konfiguration, die in der Anzeige von Spam- oder Betrugsanrufen in Webex CallingArtikel. |
| 10 |
Konfigurieren Sie SIP-Optionen keepalive mit Header-Modifizierungsprofil.
Hier ist eine Erklärung der Felder für die Konfiguration: voice class sip-options-keepalive 100Konfiguriert ein keepalive-Profil und wechselt in den Sprachklassenkonfigurationsmodus. Sie können die Zeit (in Sekunden) einstellen, zu der ein SIP Out of Dialog Options Ping an das Wählziel gesendet wird, wenn sich die Herzschlagverbindung zum Endpunkt im AUFWÄRTS- oder Abwärts-Status befindet. Dieses Keepalive-Profil wird von der in Richtung Webex konfigurierten Wählscheibe ausgelöst. Um sicherzustellen, dass die Kopfzeilen des Kontakts den SBC vollständig qualifizierten Domainnamen enthalten, wird das SIP-Profil 115 verwendet. Regeln 30, 40 und 50 sind nur erforderlich, wenn der SBC hinter statischem NAT konfiguriert ist. In diesem Beispiel ist cube1.lgw.com der für das lokale Gateway gewählte FQDN. Wenn statisches NAT verwendet wird, ist „10.80.13.12“ die IP-Adresse der SBC-Schnittstelle zu Webex Calling und „192.65.79.20“ die öffentliche IP-Adresse des NAT. |
| 11 |
Webex Calling Trunk konfigurieren: |
| 12 |
(Optional) Verwenden Sie diese Befehle, um Netzwerkgeräte wie CUBE zu konfigurieren und Header des Session Initiation Protocol (SIP) weiterzuleiten, die das Gerät nicht verarbeitet. Diese Befehle ermöglichen es dem Gerät, nicht unterstützte SIP-Header, einschließlich Geo-Location-Header und PIDF-LO (Presence Information Data Format - Location Object), auf dem lokalen Gateway zu durchlaufen. Diese Funktionalität unterstützt Nomadische E-Services911 , indem sie sicherstellen, dass kritische Standortinformationen korrekt gespeichert und weitergeleitet werden. |
Nachdem Sie oben einen Trunk zu Webex Calling aufgebaut haben, verwenden Sie die folgende Konfiguration, um einen nicht verschlüsselten Trunk zu einem SIP-basierten PSTN-Anbieter zu erstellen:
Wenn Ihr Dienstleister einen sicheren PSTN-Trunk anbietet, können Sie eine ähnliche Konfiguration wie oben für den Webex Calling-Trunk durchführen. CUBE unterstützt sicheres Anrufrouting.
Wenn Sie einen TDM / ISDN PSTN-Trunk verwenden, gehen Sie zum nächsten Abschnitt Lokales Gateway mit TDM PSTN-Trunk konfigurieren.
Zur Konfiguration von TDM-Schnittstellen für PSTN-Call-Legs auf den Cisco TDM-SIP Gateways siehe ISDN PRI konfigurieren.
| 1 |
Konfigurieren Sie den folgenden Sprachklassen-URI, um eingehende Anrufe aus dem PSTN-Trunk zu identifizieren:
Hier ist eine Erklärung der Felder für die Konfiguration: voice class uri 200 sipLegt ein Muster fest, das einer eingehenden SIP-Einladung zu einem eingehenden Trunk-Dial-Peer entspricht. Verwenden Sie bei der Eingabe dieses Musters die IP-Adresse Ihres IP PSTN-Gateways. Weitere Informationen unter Sprachklasse-URI. |
| 2 |
Konfigurieren Sie den folgenden IP PSTN-Dial-Peer:
Hier ist eine Erklärung der Felder für die Konfiguration:
Definiert einen VoIP-Dial-Peer mit einem Tag von 200 und gibt eine aussagekräftige Beschreibung für einfache Verwaltung und Fehlerbehebung. Weitere Informationen unter Wählbare Stimme. destination-pattern BAD.BADBeim Routing ausgehender Anrufe unter Verwendung einer eingehenden Dial-Peer-Gruppe ist ein Dummy-Zielmuster erforderlich. In diesem Fall kann jedes gültige Zielmuster verwendet werden. Weitere Informationen unter Ziel-Muster (Schnittstelle). session protocol sipv2Gibt an, dass dieser Dial-Peer SIP-Call-Legs behandelt. Weitere Informationen unter Sitzungsprotokoll (Dial Peer). session target ipv4: 192.168.80.13Gibt die Zieladresse für Anrufe an den PSTN-Anbieter an. Dies kann entweder eine IP-Adresse oder ein DNS-Hostname sein. Weitere Informationen unter Sitzungsziel (VoIP-Dial-Peer). incoming uri via 200Gibt die Sprachklasse an, die verwendet wird, um eingehende Anrufe mit diesem Dial-Peer unter Verwendung der URI INVITE VIA-Header abzugleichen. Weitere Informationen unter eingehende URL.
voice-class sip asserted-id pai
(Optional) Aktiviert die Verarbeitung des P-Asserted-Identity-Headers und steuert, wie diese für den PSTN-Trunk verwendet wird. Bei Verwendung dieses Befehls wird für die abgehenden From- und P-Asserted-Identity-Header die von dem eingehenden Dial-Peer bereitgestellte rufende Partei-Identität verwendet. Wird dieser Befehl nicht verwendet, wird für die abgehenden Von- und Remote-Party-ID-Header die anrufende Partei-Identität des anrufenden Teilnehmers verwendet. Weitere Informationen unter Sprachklasse sip asserted-id.
bind control
source-interface
GigabitEthernet0/0/0
Konfiguriert die Quellschnittstelle und die zugehörige IP-Adresse für Nachrichten, die an den PSTN gesendet werden. Weitere Informationen unter Bindung. bind media source-interface GigabitEthernet0/0/0Konfiguriert die Quellschnittstelle und die zugehörige IP-Adresse für Medien, die an PSTN gesendet werden. Weitere Informationen unter Bindung. voice-class codec 100Konfiguriert den Dial-Peer, um die gemeinsame Codec-Filterliste 100 zu verwenden. Weitere Informationen unter Sprachklasse-Codec. dtmf-relay rtp-nteDefiniert RTP-NTE (RFC2833) als DTMF-Fähigkeit, die auf dem Call-Leg erwartet wird. Weitere Informationen unter DTMF-Relais (Voice over IP). no vadDeaktiviert die Erkennung von Sprachaktivitäten. Weitere Informationen unter vad (Zifferblatt-Peer). |
| 3 |
Wenn Sie Ihr lokales Gateway so konfigurieren, dass nur Anrufe zwischen Webex Calling und dem PSTN weitergeleitet werden, fügen Sie die folgende Konfiguration für das Anrufrouting hinzu. Wenn Sie Ihr Local Gateway mit einer Unified Communications Manager-Plattform konfigurieren, gehen Sie zum nächsten Abschnitt. |
Nachdem Sie einen Trunk in Richtung Webex Calling aufgebaut haben, erstellen Sie mit der folgenden Konfiguration einen TDM-Trunk für Ihren PSTN-Dienst mit Loop-Back-Call-Routing, um eine Medienoptimierung auf dem Webex-Call-Leg zu ermöglichen.
Wenn Sie keine IP-Media-Optimierung benötigen, befolgen Sie die Konfigurationsschritte für einen SIP PSTN-Trunk. Verwenden Sie anstelle des PSTN VoIP-Dial-Peer einen Voice-Port und POTS-Dial-Peer (wie in den Schritten 2 und 3 dargestellt).
| 1 |
Die Loop-Back-Dial-Peer-Konfiguration verwendet Dial-Peer-Gruppen und Call-Routing-Tags, um sicherzustellen, dass Anrufe korrekt zwischen Webex und dem PSTN verlaufen, ohne Call-Routing-Schleifen zu erstellen. Konfigurieren Sie die folgenden Übersetzungsregeln, die zum Hinzufügen und Entfernen der Call-Routing-Tags verwendet werden:
Hier ist eine Erklärung der Felder für die Konfiguration: voice translation-ruleVerwendet reguläre Ausdrücke, die in Regeln definiert sind, um Call-Routing-Tags hinzuzufügen oder zu entfernen. Über-dekadische Ziffern („A“) werden verwendet, um Klarheit für die Fehlerbehebung zu schaffen. In dieser Konfiguration wird das vom Translation-Profile 100 hinzugefügte Tag verwendet, um Anrufe von Webex Calling über die Loopback-Dial-Peers zum PSTN zu leiten. In ähnlicher Weise wird das vom Translation-Profile hinzugefügte Tag 200 verwendet, um Anrufe vom PSTN in Richtung Webex Calling zu leiten. Die Übersetzungsprofile 11 und 12 entfernen diese Tags, bevor die Anrufe an die Webex- bzw. PSTN-Trunks gesendet werden. Dieses Beispiel geht davon aus, dass angerufene Nummern von Webex Calling im +E.164-Format dargestellt werden. Regel 100 entfernt das führende +, um eine gültige angerufene Nummer beizubehalten. Regel 12 fügt dann beim Entfernen des Tags eine nationale oder internationale Routing-Ziffer(n) hinzu. Verwenden Sie Ziffern, die Ihrem lokalen nationalen ISDN-Ziffernplan entsprechen. Wenn Webex Calling Nummern im nationalen Format anzeigt, passen Sie die Regeln 100 und 12 an, um das Routing-Tag einfach hinzuzufügen bzw. zu entfernen. Weitere Informationen unter Sprachübersetzungsprofilund Sprachübersetzungsregel. |
| 2 |
Konfigurieren Sie die Ports der TDM-Sprachschnittstelle gemäß dem verwendeten Trunk-Typ und dem verwendeten Protokoll. Weitere Informationen unter ISDN PRI konfigurieren. Die Grundkonfiguration einer Primary Rate ISDN-Schnittstelle, die im NIM-Slot 2 eines Geräts installiert ist, kann beispielsweise Folgendes umfassen:
|
| 3 |
Konfigurieren Sie den folgenden TDM PSTN-Dial-Peer:
Hier ist eine Erklärung der Felder für die Konfiguration:
Definiert einen VoIP-Dial-Peer mit einem Tag von 200 und gibt eine aussagekräftige Beschreibung für einfache Verwaltung und Fehlerbehebung. Weitere Informationen unter Gegenstimme. destination-pattern BAD.BADBeim Routing ausgehender Anrufe unter Verwendung einer eingehenden Dial-Peer-Gruppe ist ein Dummy-Zielmuster erforderlich. In diesem Fall kann jedes gültige Zielmuster verwendet werden. Weitere Informationen unter Ziel-Muster (Schnittstelle). translation-profile incoming 200Weist das Übersetzungsprofil zu, das der eingehenden angerufenen Nummer ein Anrufrouting-Tag hinzufügen wird. direct-inward-dialLeitet den Anruf ohne einen sekundären Wählton. Weitere Informationen unter Zifferblatt nach innen. port 0/2/0:15Der physische Sprachanschluss, der mit diesem Dial-Peer verbunden ist. |
| 4 |
Um die Medienoptimierung von IP-Pfaden für lokale Gateways mit TDM-IP-Anrufströmen zu ermöglichen, können Sie das Anrufrouting ändern, indem Sie eine Reihe interner Loop-Back-Dial-Peers zwischen Webex Calling und PSTN-Trunks einführen. Konfigurieren Sie die folgenden Loop-Back-Dial-Peers. In diesem Fall werden alle eingehenden Anrufe zunächst auf Dial-Peer 10 und von dort auf Basis des angewendeten Routing-Tags entweder auf Dial-Peer 11 oder auf 12 geleitet. Nach dem Entfernen des Routing-Tags werden Anrufe mit Dial-Peer-Gruppen an den ausgehenden Trunk weitergeleitet.
Hier ist eine Erklärung der Felder für die Konfiguration:
Definiert einen VoIP-Dial-Peer und gibt eine aussagekräftige Beschreibung für einfache Verwaltung und Fehlerbehebung. Weitere Informationen unter Gegenstimme. translation-profile incoming 11Wendet das zuvor definierte Übersetzungsprofil an, um das Call-Routing-Tag zu entfernen, bevor es zum ausgehenden Trunk weitergeleitet wird. destination-pattern BAD.BADBeim Routing ausgehender Anrufe unter Verwendung einer eingehenden Dial-Peer-Gruppe ist ein Dummy-Zielmuster erforderlich. Weitere Informationen unter Ziel-Muster (Schnittstelle). session protocol sipv2Gibt an, dass dieser Dial-Peer SIP-Call-Legs behandelt. Weitere Informationen unter Sitzungsprotokoll (Dial Peer). session target ipv4: 192.168.80.14Gibt die Adresse der lokalen Router-Schnittstelle als Anrufziel für den Loop-Back an. Weitere Informationen unter Sitzungsziel (Voip Dial Peer). bind control source-interface GigabitEthernet0/0/0Konfiguriert die Quellschnittstelle und die zugehörige IP-Adresse für Nachrichten, die über den Loop-Back gesendet werden. Weitere Informationen unter Bindung. bind media source-interface GigabitEthernet0/0/0Konfiguriert die Quellschnittstelle und die zugehörige IP-Adresse für Medien, die über den Loop-Back gesendet werden. Weitere Informationen unter Bindung. dtmf-relay rtp-nteDefiniert RTP-NTE (RFC2833) als DTMF-Fähigkeit, die auf dem Call-Leg erwartet wird. Weitere Informationen unter DTMF-Relais (Voice over IP). codec g711alaw Zwingt alle PSTN-Anrufe zur Verwendung von G.711. Wählen Sie a-law oder u-law, um der von Ihrem ISDN-Dienst verwendeten Companding-Methode zuzustimmen. no vadDeaktiviert die Erkennung von Sprachaktivitäten. Weitere Informationen unter vad (Zifferblatt-Peer). |
| 5 |
Fügen Sie die folgende Konfiguration des Anrufs hinzu: Damit ist Ihre Local Gateway-Konfiguration abgeschlossen. Speichern Sie die Konfiguration und laden Sie die Plattform neu, wenn CUBE-Funktionen zum ersten Mal konfiguriert werden.
|
Die PSTN-Webex Calling-Konfiguration in den vorherigen Abschnitten kann geändert werden, um zusätzliche Trunks zu einem Cisco Unified Communications Manager (UCM)-Cluster aufzunehmen. In diesem Fall werden alle Anrufe über Unified CM geleitet. Anrufe von UCM auf dem Port 5060 werden zum PSTN geleitet und Anrufe vom Port 5065 werden zu Webex Calling geleitet. Die folgenden inkrementellen Konfigurationen können hinzugefügt werden, um dieses aufrufende Szenario zu berücksichtigen.
| 1 |
Konfigurieren Sie die folgenden Sprachklassen-URIs: |
| 2 |
Konfigurieren Sie die folgenden DNS-Datensätze, um das SRV-Routing zu Unified CM-Hosts anzugeben: IOS XE verwendet diese Datensätze zur lokalen Bestimmung von Ziel-UCM-Hosts und -Ports. Mit dieser Konfiguration ist es nicht erforderlich, Datensätze in Ihrem DNS-System zu konfigurieren. Wenn Sie lieber Ihren DNS verwenden, sind diese lokalen Konfigurationen nicht erforderlich.
Hier ist eine Erklärung der Felder für die Konfiguration: Der folgende Befehl erstellt einen DNS SRV-Ressourcendatensatz. Erstellen Sie für jeden UCM-Host und jeden Trunk einen Datensatz: ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: SRV-Ressourcensatzname 2: Die SRV-Ressourcendatensatzpriorität 1: Das SRV-Ressourcenrekordgewicht 5060: Portnummer, die für den Zielhost in diesem Ressourcendatensatz verwendet werden soll ucmsub5.mydomain.com: Der Ressourcen-Datensatz-Zielhost Erstellen Sie lokale DNS A-Datensätze, um die Hostnamen der Ressourcendatensätze zu lösen. Beispiel: ip host ucmsub5.mydomain.com 192.168.80.65 ip-Host: Erstellt einen Datensatz in der lokalen IOS XE Datenbank. ucmsub5.mydomain.com: Der Name des A-Datensatzes. 192.168.80.65: Die Host-IP-Adresse. Erstellen Sie die SRV-Ressourcendatensätze und A-Datensätze, die Ihre UCM-Umgebung und die bevorzugte Anrufverteilungsstrategie widerspiegeln. |
| 3 |
Konfigurieren Sie die folgenden Zifferblattgleichungen: |
| 4 |
Fügen Sie das Anrufrouting unter Verwendung der folgenden Konfigurationen hinzu: |
Diagnosezeichen (Diagnostic Signatures, DS) erkennt proaktiv häufig beobachtete Probleme im lokalen Cisco IOS XE-basierten Gateway und generiert eine E-Mail-, Syslog- oder Terminal-Benachrichtigung für das Ereignis. Sie können die DS auch installieren, um die Erfassung von Diagnosedaten zu automatisieren und die erfassten Daten an den Cisco TAC-Fall zu übertragen, um die Auflösungszeit zu verkürzen.
Diagnose-Signaturen (DS) sind XML-Dateien, die Informationen über Problemlöseereignisse und Aktionen enthalten, um das Problem zu informieren, zu beheben und zu beheben. Verwenden Sie Syslog-Meldungen, SNMP-Ereignisse und durch periodische Überwachung bestimmter Show-Command-Outputs, um die Logik zur Problemerkennung zu definieren. Zu den Aktionstypen gehören:
-
Show-Befehlsausgabe wird gesammelt
-
Erstellen einer konsolidierten Protokolldatei
-
Hochladen der Datei auf einen vom Benutzer bereitgestellten Netzwerkspeicherort, wie HTTPS, SCP, FTP-Server
TAC-Techniker erstellen DS-Dateien und signieren sie digital für den Integritätsschutz. Jede DS-Datei hat die vom System zugewiesene eindeutige numerische ID. Tool zum Nachschlagen von Diagnosesignaturen(DSLT) ist eine einzige Quelle, um geeignete Signaturen für die Überwachung und Fehlerbehebung verschiedener Probleme zu finden.
Vorbereitungen:
-
Bearbeiten Sie nicht die DS-Datei, von der Sie herunterladen DSLT. Die Dateien, die Sie ändern, können aufgrund eines Fehlers bei der Integritätsprüfung nicht installiert werden.
-
Ein SMTP-Server (Simple Mail Transfer Protocol), den Sie zum Senden von E-Mail-Benachrichtigungen für das lokale Gateway benötigen.
-
Stellen Sie sicher, dass im Local Gateway IOS XE 17.6.1 oder höher ausgeführt wird, wenn Sie den sicheren SMTP-Server für E-Mail-Benachrichtigungen verwenden möchten.
Voraussetzungen
Lokales Gateway mit IOS XE 17.6.1 oder höher
-
Diagnosesignaturen sind standardmäßig aktiviert.
-
Konfigurieren Sie den sicheren E-Mail-Server, den Sie verwenden, um proaktive Benachrichtigungen zu senden, wenn auf dem Gerät IOS XE 17.6.1 oder höher ausgeführt wird.
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls end -
Konfigurieren Sie die Umgebungsvariable ds_email mit der E-Mail-Adresse des Administrators, den Sie benachrichtigen möchten.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_email <email address> end
Installieren von Diagnosesignaturen für proaktive Überwachung
Überwachen einer hohen CPU-Auslastung
Dieses DS verfolgt die 5-Sekunden-CPU-Auslastung unter Verwendung des SNMP OID 1.3.6.1.4.1.9.2.1.56. Wenn die Auslastung 75% oder mehr erreicht, werden alle Debugs deaktiviert und alle Diagnosesignaturen, die Sie im lokalen Gateway installieren, deinstalliert. Führen Sie die folgenden Schritte aus, um die Signatur zu installieren.
-
Stellen Sie sicher, dass Sie SNMP mit dem Befehl aktiviert haben show snmp. Wenn SNMP nicht aktiviert ist, konfigurieren Sie die snmp-server manager Befehl.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled DS herunterladen 64224Verwendung der folgenden Dropdown-Optionen in Tool zum Nachschlagen von Diagnosesignaturen:
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:Feldname
Feldwert
Plattform
Cisco 4300, 4400 ISR Series oder Catalyst 8000V Edge Software
Produkt
CUBE Enterprise in Webex Calling Lösung
Problemumfang
Performance
Problemtyp
Hohe CPU-Auslastung mit E-Mail-Benachrichtigung

-
Kopieren Sie die DS-XML-Datei in den Flash des lokalen Gateways.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:Im folgenden Beispiel wird das Kopieren der Datei von einem FTP-Server auf das lokale Gateway veranschaulicht.
copy ftp://user:pwd@192.0.2.12/DS_64224.xml bootflash: Accessing ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 bytes] 3571 bytes copied in 0.064 secs (55797 bytes/sec) -
Installieren Sie die DS-XML-Datei auf dem lokalen Gateway.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success -
Benutzen Sie show call-home diagnostic-signature Befehl, um zu überprüfen, ob die Signatur erfolgreich installiert wurde. Die Statusspalte muss über einen "registrierten"-Wert verfügen.
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.comLaden Sie Diagnosesignaturen herunter:
DS-ID
DS-Name
Revision
Status
Letzte Aktualisierung (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Registriert
2020-11-07 22:05:33
Wenn ausgelöst, deinstalliert diese Signatur alle laufenden Diagnosesignaturen, einschließlich sich selbst. Falls erforderlich, installieren Sie DS 64224 neu, um die hohe CPU-Auslastung auf dem Local Gateway weiter zu überwachen.
Bei der Überwachung abnormaler Anrufabschaltungen wird die Verbindung getrennt.
Dieser DS nutzt die SNMP-Abfrage alle 10 Minuten, um abnormale Verbindungsabschaltung bei SIP-Fehlern 403, 488 und 503 zu erkennen. Wenn die Fehlerzählerhöhung größer oder gleich 5 aus der letzten Umfrage ist, wird eine Syslog- und E-Mail-Benachrichtigung generiert. Gehen Sie wie folgt vor, um die Signatur zu installieren.
-
Stellen Sie sicher, dass SNMP über den Befehl aktiviert ist show snmp. Wenn SNMP nicht aktiviert ist, konfigurieren Sie die snmp-server manager Befehl.
show snmp %SNMP agent not enabled config t snmp-server manager end show snmp Chassis: ABCDEFGHIGK 149655 SNMP packets input 0 Bad SNMP version errors 1 Unknown community name 0 Illegal operation for community name supplied 0 Encoding errors 37763 Number of requested variables 2 Number of altered variables 34560 Get-request PDUs 138 Get-next PDUs 2 Set-request PDUs 0 Input queue packet drops (Maximum queue size 1000) 158277 SNMP packets output 0 Too big errors (Maximum packet size 1500) 20 No such name errors 0 Bad values errors 0 General errors 7998 Response PDUs 10280 Trap PDUs Packets currently in SNMP process input queue: 0 SNMP global trap: enabled -
DS herunterladen 65221Verwendung der folgenden Optionen in Tool zum Nachschlagen von Diagnosesignaturen:
Feldname
Feldwert
Plattform
Cisco 4300, 4400 ISR Series oder Catalyst 8000V Edge Software
Produkt
CUBE Enterprise in Webex Calling-Lösung
Problemumfang
Performance
Problemtyp
Abnormale Sip-Anruf-Trennungserkennung mit E-Mail- und Syslog-Benachrichtigung.
-
Kopieren Sie die DS-XML-Datei auf das lokale Gateway.
copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash: -
Installieren Sie die DS-XML-Datei auf dem lokalen Gateway.
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success -
Den Befehl benutzen show call-home diagnostic-signature um zu überprüfen, ob die Signatur erfolgreich installiert wurde. Die Statusspalte sollte einen Wert „registriert“ haben.
Installieren Sie Diagnosesignaturen, um ein Problem zu beheben
Sie können auch Diagnose-Signaturen (DS) verwenden, um Probleme schnell zu lösen. Die Cisco TAC-Techniker haben mehrere Signaturen erstellt, die die erforderlichen Debugs ermöglichen, um ein bestimmtes Problem zu beheben, das auftretende Problem zu erkennen, die richtigen Diagnosedaten zu erfassen und die Daten automatisch an den Cisco TAC-Fall zu übertragen. Dadurch ist es nicht mehr erforderlich, das Auftreten von Problemen manuell zu überprüfen, und die Fehlerbehebung bei zeitweise auftretenden und vorübergehenden Problemen wird dadurch erheblich vereinfacht.
Sie können die Tool zum Nachschlagen von Diagnosesignaturenum die entsprechenden Signaturen zu finden und sie zu installieren, um ein bestimmtes Problem selbst zu lösen, oder Sie können die Signatur installieren, die vom TAC-Techniker im Rahmen des Support-Engagements empfohlen wird.
Hier ist ein Beispiel, wie ein DS gefunden und installiert wird, um das Auftreten „%VOICE_IEC-3-GW zu erkennen: CCAPI: Interner Fehler (Schwellenwert für Anrufspitze): IEC=1.1.181.1.29.0“ Syslog und automatisieren die Diagnosedatenerfassung mit den folgenden Schritten:
Konfigurieren Sie eine andere DS-Umgebungsvariable ds_fsurl_prefix als Cisco TAC-Dateiserverpfad (cxd.cisco.com), um die Diagnosedaten hochzuladen. Der Benutzername im Dateipfad ist die Fallnummer und das Passwort ist das Datei-Upload-Token, das abgerufen werden kann von Support-Fallmanagerwie im Folgenden gezeigt. Der Datei-Upload-Token kann je nach Bedarf im Bereich Anhänge des Support Case Managers generiert werden.

configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" endBeispiel
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"-
Stellen Sie sicher, dass SNMP über den Befehl aktiviert ist show snmp. Wenn SNMP nicht aktiviert ist, konfigurieren Sie die snmp-server manager Befehl.
show snmp %SNMP agent not enabled config t snmp-server manager end -
Wir empfehlen die Installation des High CPU Monitoring DS 64224 als proaktive Maßnahme, um alle Debugs- und Diagnosesignaturen während der Zeit hoher CPU-Auslastung zu deaktivieren. DS herunterladen 64224Verwendung der folgenden Optionen in Tool zum Nachschlagen von Diagnosesignaturen:
Feldname
Feldwert
Plattform
Cisco 4300, 4400 ISR Series oder Catalyst 8000V Edge Software
Produkt
CUBE Enterprise in Webex Calling-Lösung
Problemumfang
Performance
Problemtyp
Hohe CPU-Auslastung mit E-Mail-Benachrichtigung.
-
DS herunterladen 65095Verwendung der folgenden Optionen in Tool zum Nachschlagen von Diagnosesignaturen:
Feldname
Feldwert
Plattform
Cisco 4300, 4400 ISR Series oder Catalyst 8000V Edge Software
Produkt
CUBE Enterprise in Webex Calling-Lösung
Problemumfang
Syslogs
Problemtyp
Syslog - %VOICE_IEC-GW3: CCAPI: Interner Fehler (Schwellenwert für Anrufspitze): IEC=1.1.181.1.290
-
Kopieren Sie die DS-XML-Dateien auf das lokale Gateway.
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash: -
Installieren Sie die hohe CPU-Überwachung DS 64224 und dann DS 65095 XML-Datei im Local Gateway.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success call-home diagnostic-signature load DS_65095.xml Load file DS_65095.xml success -
Überprüfen Sie, ob die Signatur erfolgreich installiert wurde unter Verwendung show call-home diagnostic-signature. Die Statusspalte sollte einen Wert „registriert“ haben.
show call-home diagnostic-signature Current diagnostic-signature settings: Diagnostic-signature: enabled Profile: CiscoTAC-1 (status: ACTIVE) Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService Environment variable: ds_email: username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.comHeruntergeladene Diagnosesignaturen:
DS-ID
DS-Name
Revision
Status
Letzte Aktualisierung (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Registriert
2020-11-08:00:07:45
65095
00:12:53
DS_LGW_IEC_Call_spike_threshold
0.0.12
Registriert
2020-11-08:00:12:53
Ausführung von Diagnosesignaturen überprüfen
Im folgenden Befehl wird die Spalte „Status“ des Befehls show call-home diagnostic-signature wechselt zu „laufen“, während das lokale Gateway die in der Signatur definierte Aktion ausführt. Die Ausgabe von show call-home diagnostic-signature statistics ist der beste Weg, um zu überprüfen, ob eine diagnostische Signatur ein interessierendes Ereignis erkennt und die Aktion ausgeführt wird. Die Spalte "Ausgelöst/Max/Deinstallieren" gibt an, wie oft die gegebenen Signatur ein Event ausgelöst hat, wie oft sie maximal zum Erkennen eines Events definiert wird und ob die Signatur sich selbst deinstalliert, nachdem die maximale Anzahl ausgelöster Ereignisse erkannt wurde.
show call-home diagnostic-signature
Current diagnostic-signature settings:
Diagnostic-signature: enabled
Profile: CiscoTAC-1 (status: ACTIVE)
Downloading URL(s): https://tools.cisco.com/its/service/oddce/services/DDCEService
Environment variable:
ds_email: carunach@cisco.com
ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com
Heruntergeladene Diagnosesignaturen:
|
DS-ID |
DS-Name |
Revision |
Status |
Letzte Aktualisierung (GMT+00:00) |
|---|---|---|---|---|
|
64224 |
DS_LGW_CPU_MON75 |
0.0.10 |
Registriert |
2020-11-08 00:07:45 |
|
65095 |
DS_LGW_IEC_Call_spike_threshold |
0.0.12 |
Wird ausgeführt |
2020-11-08 00:12:53 |
Diagnose-/Unterschriftsstatistiken für Call-Home anzeigen
|
DS-ID |
DS-Name |
Ausgelöst/Max./Deinstall |
Durchschnittliche Ausführungszeit (Sekunden) |
Max. Ausführungszeit (Sekunden) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0/0/N |
0.000 |
0.000 |
|
65095 |
DS_LGW_IEC_Call_spike_threshold |
1/20/Y |
23.053 |
23.053 |
Die Benachrichtigungs-E-Mail, die während der Ausführung der Diagnosesignatur gesendet wird, enthält schlüsselinformationen wie Problemtyp, Gerätedetails, Softwareversion, ausgeführte Konfiguration und Befehlsausgabe, die für die Behebung des jeweiligen Problems relevant sind.
Diagnosesignaturen deinstallieren
Die Diagnosesignaturen sind zu Fehlerbehebungszwecken in der Regel definiert, um nach der Erkennung einiger Problemereignisse zu deinstallieren. Wenn Sie eine Signatur manuell deinstallieren möchten, holen Sie die DS-ID aus der Ausgabe von show call-home diagnostic-signature und führen Sie folgenden Befehl aus:
call-home diagnostic-signature deinstall <DS ID>
Beispiel
call-home diagnostic-signature deinstall 64224
Das Diagnose-Signaturen-Lookup-Tool wird in regelmäßigen Abständen neue Signaturen hinzugefügt. Dies basiert auf Problemen, die in Bereitstellungen beobachtet werden. TAC unterstützt derzeit keine Anfragen zur Erstellung neuer benutzerdefinierter Signaturen.
