Lokales Gateway in Cisco IOS XE für Webex Calling konfigurieren
list-menuFeedback?
Nachdem Sie Webex Calling für Ihre Organisation konfiguriert haben, können Sie einen Trunk konfigurieren, um Ihr lokales Gateway mit Webex Calling zu verbinden. Der SIP TLS-Transport sichert den Trunk zwischen dem lokalen Gateway und der Webex-Cloud. Die Medien zwischen dem lokalen Gateway und Webex Calling verwenden SRTP.

Ü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.

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.

Call routing from/to PSTN to/from Webex Calling configuration solution

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.

Call routing configuration with a set of internal loop-back dial-peers between Webex Calling and PSTN trunks

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.

Solution diagram showing Unified Communications Manager provides centralized routing and treatment of all PSTN and Webex Calling calls

In diesem Dokument werden die im folgenden Bild dargestellten Hostnamen, IP-Adressen und Schnittstellen verwendet.

The host names, IP addresses, and interfaces used in Call routing configuration solutions

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:


interface GigabitEthernet0/0/0
  description Interface facing PSTN and/or CUCM
  ip address 10.80.13.12 255.255.255.0
!
interface GigabitEthernet0/0/1
  description Interface facing Webex Calling (Private address)
  ip address 192.51.100.1 255.255.255.240

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:


key config-key password-encrypt YourPassword
password encryption aes

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.


crypto pki trustpoint EmptyTP 
 revocation-check none
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 cn-san-validate server Befehl stellt sicher, dass das Local Gateway eine Verbindung zulässt, wenn der in Tenant 200 konfigurierte Hostname entweder in den Feldern CN oder SAN des vom ausgehenden Proxy erhaltenen Zertifikats enthalten ist.

  1. Festlegen tcp-retry count bis 1000 (5-msec-Vielfache = 5 Sekunden).

  2. Der Befehl timer connection establish Mit dem Befehl können Sie einstellen, wie lange der LGW wartet, um eine Verbindung mit einem Proxy aufzubauen, bevor Sie die nächste verfügbare Option in Betracht ziehen. Die Standardeinstellung für diesen Timer ist 20 Sekunden und das Minimum 5 Sekunden. Beginnen Sie mit einem niedrigen Wert und erhöhen Sie bei Bedarf die Netzwerkbedingungen.


sip-ua
 timers connection establish tls 5
 transport tcp tls v1.2
 crypto signaling default trustpoint EmptyTP cn-san-validate server
 tcp-retry 1000

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

ip http client source-interface GigabitEthernet0/0/1 
crypto pki trustpool import clean url https://www.cisco.com/security/pki/trs/ios_core.p7b
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.

PSTN trunk registered
2

Geben Sie die folgenden Befehle ein, um CUBE als Webex Calling Local Gateway zu konfigurieren:

 
voice service voip
 ip address trusted list
  ipv4 x.x.x.x y.y.y.y
 mode border-element
 media statistics
 media bulk-stats 
 allow-connections sip to sip
 no supplementary-service sip refer  
 stun
  stun flowdata agent-id 1 boot-count 4
  stun flowdata shared-secret 0 Password123$
 sip
  asymmetric payload full
  early-offer forced  

Hier ist eine Erklärung der Felder für die Konfiguration:


ip address trusted list
 ipv4 x.x.x.x y.y.y.y
  • Um vor Mautbetrug zu schützen, definiert die vertrauenswürdige Adressliste eine Liste von Hosts und Netzwerken, von denen das Local Gateway legitime VoIP-Anrufe erwartet.

  • Standardmäßig blockiert Local Gateway alle eingehenden VoIP-Nachrichten von IP-Adressen, die nicht in seiner vertrauenswürdigen Liste stehen. Standardmäßig werden statisch konfigurierte Dial-Peers mit „Session Target IP“- oder Servergruppen-IP-Adressen vertrauenswürdig. Das Hinzufügen dieser IP-Adressen zur vertrauenswürdigen Liste ist nicht erforderlich.

  • Wenn Sie Ihr lokales Gateway konfigurieren, fügen Sie der Liste die IP-Subnetze Ihres regionalen Webex Calling-Rechenzentrums hinzu. Weitere Informationen unter Port Reference Information für Webex Calling. Fügen Sie auch Adressbereiche für Unified Communications Manager-Server (falls verwendet) und PSTN-Trunk-Gateways hinzu.

    Wenn sich Ihr LGW hinter einer Firewall mit beschränktem Konus-NAT befindet, sollten Sie die vertrauenswürdige Liste der IP-Adressen auf der Webex Calling-Schnittstelle deaktivieren. Die Firewall schützt Sie bereits vor unerwünschten eingehenden VoIP. Die Deaktivierung reduziert den längerfristigen Konfigurationsaufwand, da wir nicht garantieren können, dass die Adressen der Webex Calling-Peers fest bleiben, und Sie müssen Ihre Firewall auf jeden Fall für die Peers konfigurieren.

mode border-element

Aktiviert Cisco Unified Border Element (CUBE) Funktionen auf der Plattform.

media statistics

Aktiviert die Medienüberwachung auf dem lokalen Gateway.

media bulk-stats

Ermöglicht der Steuerungsebene, in der Datenebene Massenanrufstatistiken zu erstellen.

Weitere Informationen zu diesen Befehlen finden Sie unter Medien.

allow-connections sip to sip

Aktivieren 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).

stun

Ermöglicht STUN (Session Traversal of UDP through NAT) weltweit.

  • Die STUN-Bindings-Funktion auf dem Local Gateway ermöglicht es, lokal erzeugte STUN-Anfragen über den ausgehandelten Medienpfad zu senden. Dies hilft, die Pinhole in der Firewall zu öffnen.

Weitere Informationen unter Betäubungsmittelflussdaten-Agent-IDund Betäubungsmittelflussdaten geheim.

asymmetric payload full

Konfiguriert asymmetrische SIP-Payload-Unterstützung für DTMF- und dynamische Codec-Payloads. Weitere Informationen unter asymmetrische Nutzlast.

early-offer forced

Zwingt 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.


voice class codec 100
 codec preference 1 g711ulaw
 codec preference 2 g711alaw

Hier ist eine Erklärung der Felder für die Konfiguration:

voice class codec 100

Wird 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.


voice class stun-usage 100 
 stun usage firewall-traversal flowdata
 stun usage ice lite

Hier ist eine Erklärung der Felder für die Konfiguration:

stun usage ice lite

Wird 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.


voice class srtp-crypto 100
 crypto 1 AES_CM_128_HMAC_SHA1_80

Hier ist eine Erklärung der Felder für die Konfiguration:

voice class srtp-crypto 100

Gibt 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:


voice class uri 100 sip
 pattern dtg=dallas1463285401_lgu

Hier ist eine Erklärung der Felder für die Konfiguration:

voice class uri 100 sip

Legt 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.


voice class sip-profiles 100
 rule 10 request ANY sip-header SIP-Req-URI modify "sips:" "sip:"
 rule 20 request ANY sip-header To modify "<sips:" "<sip:"
 rule 30 request ANY sip-header From modify "<sips:" "<sip:"
 rule 40 request ANY sip-header Contact modify "<sips:(.*)>" "<sip:\1;transport=tls>" 
 rule 50 response ANY sip-header To modify "<sips:" "<sip:"
 rule 60 response ANY sip-header From modify "<sips:" "<sip:"
 rule 70 response ANY sip-header Contact modify "<sips:" "<sip:"
 rule 80 request ANY sip-header From modify ">" ";otg=dallas1463285401_lgu>"
 rule 90 request ANY sip-header P-Asserted-Identity modify "sips:" "sip:"

Hier ist eine Erklärung der Felder für die Konfiguration:

  • Regel 10 bis 70 und 90

    Stellt sicher, dass SIP-Header, die für die Anrufsignalisierung verwendet werden, SIP statt SIPs-Schema verwenden, das Webex-Proxies erfordern. Die Konfiguration von CUBE zur Verwendung von SIP stellt sicher, dass eine sichere Registrierung verwendet wird.

  • Regentschaft 80

    Ändert den Von-Header so, dass er die OTG/DTG-Kennung der Trunk-Gruppe vom Control Hub enthält, um einen lokalen Gateway-Standort innerhalb eines Unternehmens eindeutig zu identifizieren.

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:

  1. Erstellen voice class tenant 100 um die speziell für den Webex Calling-Trunk erforderlichen Konfigurationen zu definieren und zu gruppieren. Insbesondere werden in diesem Schritt die zuvor in Control Hub angegebenen Angaben zur Stammregistrierung verwendet, wie unten beschrieben. Dial-Peers, die mit diesem Mandanten verbunden sind, werden diese Konfigurationen später erben.

    Das folgende Beispiel verwendet die in Schritt 1 dargestellten Werte für die Zwecke dieser Anleitung (fettgedruckt). Ersetzen Sie diese durch Werte für Ihren Stamm in Ihrer Konfiguration.

    
    voice class tenant 100
      registrar dns:98027369.us10.bcld.webex.com scheme sips expires 240 refresh-ratio 50 tcp tls
      credentials number Dallas1171197921_LGU username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm BroadWorks
      authentication username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm BroadWorks
      authentication username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm 98027369.us10.bcld.webex.com
      no remote-party-id
      sip-server dns:98027369.us10.bcld.webex.com
      connection-reuse
      srtp-crypto 100
      session transport tcp tls 
      no session refresh
      url sips 
      error-passthru
      rel1xx disable
      asserted-id pai 
      bind control source-interface GigabitEthernet0/0/1
      bind media source-interface GigabitEthernet0/0/1
      no pass-thru content custom-sdp 
      sip-profiles 100 
      outbound-proxy dns:dfw04.sipconnect-us.bcld.webex.com  
      privacy-policy passthru
    

    Hier ist eine Erklärung der Felder für die Konfiguration:

    voice class tenant 100

    Definiert einen Satz von Konfigurationsparametern, die nur für den Webex-Calling-Trunk verwendet werden. Weitere Informationen unter Sprachklasse-Mieter.

    registrar dns:98027369.us10.bcld.webex.com scheme sips expires 240 refresh-ratio 50 tcp tls

    Registrar-Server für das lokale Gateway mit einer Aktualisierung der Registrierung alle zwei Minuten (50% von 240 Sekunden). Weitere Informationen unter Standesbeamtin.

    Stellen Sie sicher, dass Sie hier den Wert Domain registrieren aus dem Control Hub verwenden.

    credentials number Dallas1171197921_LGU username Dallas1463285401_LGU password 0 9Wt[M6ifY+ realm BroadWorks

    Anmeldeinformationen für die Aufgabe der Trunk-Registrierung. Weitere Informationen unter Anmeldedaten (SIP UA).

    Stellen Sie sicher, dass Sie die Werte Line/Port Host, Authentication Username und Authentication Password vom Control Hub hier verwenden.

    authentication username Dallas1171197921_LGU password 0 9Wt[M6ifY+ realm BroadWorks
    authentication username Dallas1171197921_LGU password 0 9Wt[M6ifY+ realm 98027369.us10.bcld.webex.com

    Authentifizierungsaufforderungen für Anrufe. Weitere Informationen unter Authentifizierung (Dial-Peer).

    Stellen Sie sicher, dass Sie die Werte Authentication Username, Authentication Password und Registrar Domain vom Control Hub hier verwenden.

    no remote-party-id

    Deaktiviere den SIP Remote-Party-ID (RPID)-Header, da Webex-Calling PAI unterstützt, was unter Verwendung von asserted-id pai. Weitere Informationen unter Gegenpartei-ID.

    sip-server dns: us25.sipconnect.bcld.webex.com

    Konfiguriert den Ziel-SIP-Server für den Trunk. Verwenden Sie die im Control Hub angegebene Edge-Proxy-SRV-Adresse, wenn Sie Ihren Stamm erstellt haben.

    connection-reuse

    Verwendet dieselbe dauerhafte Verbindung für die Registrierung und Anrufverarbeitung. Weitere Informationen unter Verbindung-Wiederverwendung.

    srtp-crypto 100

    Konfiguriert die bevorzugten Chiffriersuiten für den SRTP-Verbindungszweig (Verbindung) (angegeben in Schritt 5). Weitere Informationen unter Sprachklasse srtp-crypto.

    session transport tcp tls

    Legt den Transport zu TLS fest. Weitere Informationen unter Sitzungstransport.

    no session refresh

    Deaktiviert die Aktualisierung der SIP-Sitzung für Anrufe zwischen CUBE und Webex. Weitere Informationen unter Aktualisierung der Sitzung.

    url sips

    SRV-Abfrage muss SIPs sein, wie sie von der Access SBC unterstützt werden; alle anderen Nachrichten werden von sip-profile 200 in SIP geändert.

    error-passthru

    Gibt die Sip-Fehler-Antwort-Pass-Thru-Funktionalität an. Weitere Informationen unter Fehlerpassthru.

    rel1xx disable

    Deaktiviert die Verwendung zuverlässiger vorläufiger Antworten für den Webex-Anruf-Trunk. Weitere Informationen unter rel.1xx.

    asserted-id pai

    (Optional) Aktiviert die Verarbeitung des P-Asserted-Identity-Headers und steuert, wie diese für den Webex-Calling-Trunk verwendet wird.

    Webex Calling enthält P-Asserted-Identity (PAI)-Header in ausgehende Anruf-INVITEs zum lokalen Gateway.

    Wenn dieser Befehl konfiguriert ist, werden Anruferinformationen aus dem PAI-Header verwendet, um die ausgehenden Von- und PAI/Remote-Party-ID-Header zu füllen.

    Wenn dieser Befehl nicht konfiguriert ist, werden Anruferinformationen aus dem Von-Header verwendet, um die ausgehenden Von- und PAI-/Remote-Party-ID-Header zu füllen.

    Weitere Informationen unter geltend gemachte ID.

    bind control source-interface GigabitEthernet0/0/1

    Konfiguriert die Quellschnittstelle und die zugehörige IP-Adresse für Nachrichten, die an Webex Calling gesendet werden. Weitere Informationen unter Bindung.

    bind media source-interface GigabitEthernet0/0/1

    Konfiguriert die Quellschnittstelle und die zugehörige IP-Adresse für Medien, die an WebexCalling gesendet werden. Weitere Informationen unter Bindung.

    no pass-thru content custom-sdp

    Standardbefehl unter Mandant. Weitere Informationen zu diesem Befehl finden Sie unter Durchlauf-Inhalt.

    sip-profiles 100

    Änderungen SIPs zu SIP ändern und Leitung/Port für INVITE- und REGISTER-Nachrichten ändern, wie festgelegt in sip-profiles 100. Weitere Informationen unter Sprachklasse SIP-Profile.

    outbound-proxy dns:dfw04.sipconnect-us.bcld.webex.com

    Webex Calling Access SBC. Geben Sie die ausgehende Proxy-Adresse ein, die bei der Erstellung Ihres Stamms im Control Hub angegeben wurde. Weitere Informationen unter Outbound-Proxy.

    privacy-policy passthru

    Konfiguriert die Datenschutz-Header-Richtlinienoptionen für den Trunk, um die Datenschutzwerte von der empfangenen Nachricht an den nächsten Anruf weiterzuleiten. Weitere Informationen unter Datenschutzerklärung.

  2. Konfigurieren Sie die Webex Calling Trunk Dial-Peer.

    
    dial-peer voice 100 voip
     description Inbound/Outbound Webex Calling
     max-conn 250
     destination-pattern BAD.BAD
     session protocol sipv2
     session target sip-server
     incoming uri request 100
     voice-class codec 100
     dtmf-relay rtp-nte
     voice-class stun-usage 100
     no voice-class sip localhost
     voice-class sip tenant 100
     srtp
     no vad
    

    Hier ist eine Erklärung der Felder für die Konfiguration:

    
    dial-peer voice 100 voip
      description Inbound/Outbound Webex Calling
    

    Definiert einen VoIP-Dial-Peer mit einem Tag von 100 und gibt eine aussagekräftige Beschreibung für einfache Verwaltung und Fehlerbehebung.

    max-conn 250

    Begrenzt die Anzahl der gleichzeitigen eingehenden und ausgehenden Anrufe zwischen LGW- und Webex-Anrufen. Für Registrierungsstämme sollte der konfigurierte Maximalwert 250 sein. Der Wert des Benutzers ist geringer, wenn dies für Ihre Bereitstellung besser geeignet wäre. Weitere Informationen zu gleichzeitigen Anruflimits für Local Gateway finden Sie im Starten Sie mit Local GatewayDokument.

    destination-pattern BAD.BAD

    Beim 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 sipv2

    Gibt an, dass Dial-Peer 100 SIP-Call-Legs bearbeitet. Weitere Informationen unter Sitzungsprotokoll (Dial-Peer).

    session target sip-server

    Zeigt an, dass der im Mandanten 100 definierte SIP-Server vererbt und für das Ziel für Anrufe von diesem Dial-Peer verwendet wird. Weitere Informationen unter Sitzungsziel (Voip Dial Peer).

    incoming uri request 100

    Angabe der Sprachklasse, die verwendet wird, um einen VoIP-Dial-Peer mit der Uniform Resource Identifier (URI) eines eingehenden Anrufs abzugleichen. Weitere Informationen unter Eingehender URI.

    voice-class codec 100

    Konfiguriert den Dial-Peer, um die gemeinsame Codec-Filterliste 100 zu verwenden. Weitere Informationen unter Sprachklasse-Codec.

    voice-class stun-usage 100

    Ermöglicht den Versand lokal erzeugter STUN-Anfragen auf dem lokalen Gateway über den ausgehandelten Medienpfad. STUN hilft, eine Firewall-Pinhole für den Medienverkehr zu öffnen. Weitere Informationen unter Sprachklasse-Betäubungsmittel.

    no voice-class sip localhost

    Deaktiviert die Ersetzung des lokalen DNS-Hostnamens an Stelle der physischen IP-Adresse in den Headern von Von, Anruf-ID und Remote-Party-ID von ausgehenden Nachrichten.

    voice-class sip tenant 100

    Der Dial-Peer erbt alle global und im Mandanten 100 konfigurierten Parameter. Parameter können auf Dial-Peer-Ebene überschrieben werden.

    srtp

    Aktiviert SRTP für den Anruf-Abschnitt.

    no vad

    Deaktiviert die Erkennung von Sprachaktivitäten.

  3. (Optional) Erzwingen Sie Anrufe nur für Audio.

    Video über Webex Calling mit Local Gateway Call Flows wird nicht unterstützt. Obwohl Video in einigen Szenarien funktionieren kann, kann es zu verminderter Qualität und unerwartetem Verhalten führen. Um Anrufe nur für Audio zu erzwingen, wenden Sie den folgenden Befehl unter Ihren Webex Calling-Wählgeräten an:

    voice-class sip audio forced

    Wenn Sie sich dafür entscheiden, Videos zuzulassen, führen Anrufe möglicherweise nicht wie erwartet.

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.

  1. Einstellung der Gegenstelle

    Voice service voip
     sip
      pass-thru headers unsupp
    
  2. Peer-spezifische Konfiguration wählen

    
    Dial-peer voice 911 voip
     voice-class sip pass-thru headers unsupp
  3. Sprachklassenkonfiguration für bestimmte Header

    Zum Proxy der Geostandort-Header:

    
    voice class sip-hdr-passthrulist 200 
     passthru-hdr Geolocation-Routing
     passthru-hdr Geolocation
     passthru-hdr-unsupp

    Pass-Through auf den ein-/ausgehenden Dial-Peer anwenden

    
    dial-peer voice 100 voip  // inbound
     voice-class sip pass-thru headers 200
    dial-peer voice 200 voip  // outbound
     voice-class sip pass-thru headers 200

    Um die Durchführung des PIDFO-Gehäuses zu ermöglichen, verwenden Sie:

    
    voice service voip 
     sip 
      pass-thru content unsupp

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.

Flussdiagramm der Authentifizierung und Registrierung von Webex-Anrufen mit lokalem Gateway

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:


voice class uri 200 sip
  host ipv4:192.168.80.13

Hier ist eine Erklärung der Felder für die Konfiguration:

voice class uri 200 sip

Legt 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:


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.13
 incoming uri via 200
 voice-class sip asserted-id pai
 voice-class sip bind control source-interface GigabitEthernet0/0/0 
 voice-class sip bind media source-interface  GigabitEthernet0/0/0 
 voice-class codec 100
 dtmf-relay rtp-nte 
 no vad

Hier ist eine Erklärung der Felder für die Konfiguration:


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk

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.BAD

Beim 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 sipv2

Gibt an, dass dieser Dial-Peer SIP-Call-Legs behandelt. Weitere Informationen unter Sitzungsprotokoll (Dial Peer).

session target ipv4: 192.168.80.13

Gibt 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 200

Gibt 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/0

Konfiguriert die Quellschnittstelle und die zugehörige IP-Adresse für Medien, die an PSTN gesendet werden. Weitere Informationen unter  Bindung.

voice-class codec 100

Konfiguriert den Dial-Peer, um die gemeinsame Codec-Filterliste 100 zu verwenden. Weitere Informationen unter Sprachklasse-Codec.

dtmf-relay rtp-nte

Definiert RTP-NTE (RFC2833) als DTMF-Fähigkeit, die auf dem Call-Leg erwartet wird. Weitere Informationen unter DTMF-Relais (Voice over IP).

no vad

Deaktiviert 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.

  1. Erstellen Sie Peer-Gruppen, um Anrufe zu Webex Calling oder dem PSTN zu leiten. Definieren Sie DPG 100 mit outbound dial-peer 100 in Richtung Webex Calling. DPG 100 wird auf den vom PSTN eingehenden Dial-Peer angewendet. In ähnlicher Weise definieren Sie DPG 200 mit outbound dial-peer 200 zum PSTN. DPG 200 wird auf den eingehenden Dial-Peer von Webex angewendet.

    
    voice class dpg 100 
     description Route calls to Webex Calling 
     dial-peer 100 
    voice class dpg 200 
     description Route calls to PSTN 
     dial-peer 200

    Hier ist eine Erklärung der Felder für die Konfiguration:

    dial-peer 100

    Verbindet einen ausgehenden Dial-Peer mit einer Dial-Peer-Gruppe. Weitere Informationen unter  Sprachklasse DPG.

  2. Verwenden Sie Dial-Peer-Gruppen, um Anrufe von Webex zum PSTN und von PSTN zu Webex zu leiten:

    
    dial-peer voice 100
     destination dpg 200
    dial-peer voice 200
     destination dpg 100 

    Hier ist eine Erklärung der Felder für die Konfiguration:

    destination dpg 200

    Gibt an, welche Dial-Peer-Gruppe und daher Dial-Peer für die ausgehende Behandlung von Anrufen verwendet werden soll, die diesem eingehenden Dial-Peer präsentiert werden.

    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.

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:


voice translation-rule 100 
 rule 1 /^\+/ /A2A/ 

voice translation-profile 100 
 translate called 100 

voice translation-rule 200 
 rule 1 /^/ /A1A/ 

voice translation-profile 200 
 translate called 200 

voice translation-rule 11 
 rule 1 /^A1A/ // 

voice translation-profile 11 
 translate called 11 

voice translation-rule 12 
 rule 1 /^A2A44/ /0/
 rule 2/^A2A/ /00/

voice translation-profile 12 
 translate called 12 

Hier ist eine Erklärung der Felder für die Konfiguration:

voice translation-rule

Verwendet 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:


card type e1 0 2 
isdn switch-type primary-net5 
controller E1 0/2/0 
 pri-group timeslots 1-31 
3

Konfigurieren Sie den folgenden TDM PSTN-Dial-Peer:


dial-peer voice 200 pots 
 description Inbound/Outbound PRI PSTN trunk 
 destination-pattern BAD.BAD 
 translation-profile incoming 200 
 direct-inward-dial 
 port 0/2/0:15

Hier ist eine Erklärung der Felder für die Konfiguration:


dial-peer voice 200 pots
 description Inbound/Outbound PRI PSTN trunk

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.BAD

Beim 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 200

Weist das Übersetzungsprofil zu, das der eingehenden angerufenen Nummer ein Anrufrouting-Tag hinzufügen wird.

direct-inward-dial

Leitet den Anruf ohne einen sekundären Wählton. Weitere Informationen unter Zifferblatt nach innen.

port 0/2/0:15

Der 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.


dial-peer voice 10 voip
 description Outbound loop-around leg
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.14
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw
 no vad 

dial-peer voice 11 voip
 description Inbound loop-around leg towards Webex
 translation-profile incoming 11
 session protocol sipv2
 incoming called-number A1AT
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw
 no vad 

dial-peer voice 12 voip
 description Inbound loop-around leg towards PSTN
 translation-profile incoming 12
 session protocol sipv2
 incoming called-number A2AT
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw 
 no vad 

Hier ist eine Erklärung der Felder für die Konfiguration:


dial-peer voice 10 voip
 description Outbound loop-around leg

Definiert einen VoIP-Dial-Peer und gibt eine aussagekräftige Beschreibung für einfache Verwaltung und Fehlerbehebung. Weitere Informationen unter Gegenstimme.

translation-profile incoming 11

Wendet das zuvor definierte Übersetzungsprofil an, um das Call-Routing-Tag zu entfernen, bevor es zum ausgehenden Trunk weitergeleitet wird.

destination-pattern BAD.BAD

Beim Routing ausgehender Anrufe unter Verwendung einer eingehenden Dial-Peer-Gruppe ist ein Dummy-Zielmuster erforderlich. Weitere Informationen unter Ziel-Muster (Schnittstelle).

session protocol sipv2

Gibt an, dass dieser Dial-Peer SIP-Call-Legs behandelt. Weitere Informationen unter  Sitzungsprotokoll (Dial Peer).

session target ipv4: 192.168.80.14

Gibt 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/0

Konfiguriert 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/0

Konfiguriert 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-nte

Definiert 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 vad

Deaktiviert die Erkennung von Sprachaktivitäten. Weitere Informationen unter  vad (Zifferblatt-Peer).

5

Fügen Sie die folgende Konfiguration des Anrufs hinzu:

  1. Erstellen Sie Dial-Peer-Gruppen, um Anrufe zwischen den PSTN- und Webex-Trunks über die Loop-Back-Funktion zu leiten.

    
    voice class dpg 100
     description Route calls to Webex Calling
     dial-peer 100
    voice class dpg 200
     description Route calls to PSTN
     dial-peer 200
    voice class dpg 10
     description Route calls to Loopback
     dial-peer 10

    Hier ist eine Erklärung der Felder für die Konfiguration:

    dial-peer 100

    Verbindet einen ausgehenden Dial-Peer mit einer Dial-Peer-Gruppe. Weitere Informationen unter  Sprachklasse DPG.

  2. Verwenden Sie Dial-Peer-Gruppen für Routenanrufe.

    
    dial-peer voice 100
     destination dpg 10
    dial-peer voice 200
     destination dpg 10
    dial-peer voice 11
     destination dpg 100
    dial-peer voice 12
     destination dpg 200

    Hier ist eine Erklärung der Felder für die Konfiguration:

    destination dpg 200

    Gibt an, welche Dial-Peer-Gruppe und daher Dial-Peer für die ausgehende Behandlung von Anrufen verwendet werden soll, die diesem eingehenden Dial-Peer präsentiert werden.

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.

Enter SIP trunk security profile information
1

Konfigurieren Sie die folgenden Sprachklassen-URIs:

  1. Klassifiziert Unified CM zu Webex-Anrufen über den SIP VIA-Port:

    
    voice class uri 300 sip
     pattern :5065
    
  2. Klassifiziert Unified CM zu PSTN-Anrufen mit SIP über den Port:

    
    voice class uri 400 sip
     pattern 192\.168\.80\.6[0-5]:5060
    

    Klassifizieren Sie eingehende Nachrichten vom UCM zum PSTN-Trunk unter Verwendung eines oder mehrerer Muster, die die Adressen und Portnummer des Ursprungs beschreiben. Bei Bedarf können reguläre Ausdrücke verwendet werden, um übereinstimmende Muster zu definieren.

    Im obigen Beispiel wird ein regulärer Ausdruck verwendet, um eine beliebige IP-Adresse im Bereich 192.168.80.60 mit 65 und die Portnummer 5060 abzugleichen.

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.


ip host ucmpub.mydomain.com 192.168.80.60
ip host ucmsub1.mydomain.com 192.168.80.61
ip host ucmsub2.mydomain.com 192.168.80.62
ip host ucmsub3.mydomain.com 192.168.80.63
ip host ucmsub4.mydomain.com 192.168.80.64
ip host ucmsub5.mydomain.com 192.168.80.65
ip host _sip._udp.wxtocucm.io srv 0 1 5065 ucmpub.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub1.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub2.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub3.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub4.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub5.mydomain.com
ip host _sip._udp.pstntocucm.io srv 0 1 5060 ucmpub.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub1.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub2.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub3.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub4.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

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:

  1. Dial-Peer für Anrufe zwischen Unified CM und Webex Calling:

    
    dial-peer voice 300 voip
     description UCM-Webex Calling trunk
     destination-pattern BAD.BAD
     session protocol sipv2
     session target dns:wxtocucm.io
     incoming uri via 300
     voice-class codec 100
     voice-class sip bind control source-interface GigabitEthernet 0/0/0
     voice-class sip bind media source-interface GigabitEthernet 0/0/0
     dtmf-relay rtp-nte
     no vad
    

    Hier ist eine Erklärung der Felder für die Konfiguration:

    
    dial-peer voice 300 voip
     description UCM-Webex Calling trunk

    Definiert einen VoIP-Dial-Peer mit einem Tag 300 und gibt eine aussagekräftige Beschreibung für einfache Verwaltung und Fehlerbehebung.

    destination-pattern BAD.BAD

    Beim 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.

    session protocol sipv2

    Gibt an, dass Dial-Peer 300 SIP-Call-Legs bearbeitet. Weitere Informationen unter  Sitzungsprotokoll (Dial-Peer).

    session target dns:wxtocucm.io

    Definiert das Sitzungsziel mehrerer Unified CM-Knoten durch DNS SRV-Auflösung. In diesem Fall wird der lokal definierte SRV-Datensatz wxtocucm.io verwendet, um Anrufe zu leiten.

    incoming uri via 300

    Nutzt die Sprachklasse-URI 300, um den gesamten eingehenden Datenverkehr von Unified CM über den Quellport 5065 zu diesem Dial-Peer zu leiten. Weitere Informationen unter  Eingehender URI.

    voice-class codec 100

    Zeigt die Codec-Filterliste für Anrufe von und nach Unified CM an. Weitere Informationen unter  Sprachklasse-Codec.

    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/0

    Konfiguriert die Quellschnittstelle und die zugehörige IP-Adresse für Medien, die an PSTN gesendet werden. Weitere Informationen unter  Bindung.

    dtmf-relay rtp-nte

    Definiert RTP-NTE (RFC2833) als DTMF-Fähigkeit, die auf dem Call-Leg erwartet wird. Weitere Informationen unter  DTMF-Relais (Voice over IP).

    no vad

    Deaktiviert die Erkennung von Sprachaktivitäten. Weitere Informationen unter  vad (Zifferblatt-Peer).

  2. Dial-Peer für Anrufe zwischen Unified CM und PSTN:

    
    dial-peer voice 400 voip
     description UCM-PSTN trunk
     destination-pattern BAD.BAD
     session protocol sipv2
     session target dns:pstntocucm.io
     incoming uri via 400
     voice-class codec 100 
     voice-class sip bind control source-interface GigabitEthernet 0/0/0
     voice-class sip bind media source-interface GigabitEthernet 0/0/0
     dtmf-relay rtp-nte
     no vad
    

    Hier ist eine Erklärung der Felder für die Konfiguration:

    
    dial-peer voice 400 voip
     description UCM-PSTN trunk

    Definiert einen VoIP-Dial-Peer mit einem Tag von 400 und gibt eine aussagekräftige Beschreibung für einfache Verwaltung und Fehlerbehebung.

    destination-pattern BAD.BAD

    Beim 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.

    session protocol sipv2

    Gibt an, dass Dial-Peer 400 SIP-Call-Legs bearbeitet. Weitere Informationen unter  Sitzungsprotokoll (Dial-Peer).

    session target dns:pstntocucm.io

    Definiert das Sitzungsziel mehrerer Unified CM-Knoten durch DNS SRV-Auflösung. In diesem Fall wird der lokal definierte SRV-Datensatz pstntocucm.io verwendet, um Anrufe zu leiten.

    incoming uri via 400

    Verwendet die Sprachklasse-URI 400, um den gesamten eingehenden Datenverkehr von den angegebenen Unified CM-Hosts über den Quellport 5060 zu diesem Dial-Peer zu leiten. Weitere Informationen unter  Eingehender URI.

    voice-class codec 100

    Zeigt die Codec-Filterliste für Anrufe von und nach Unified CM an. Weitere Informationen unter  Sprachklasse-Codec.

    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/0

    Konfiguriert die Quellschnittstelle und die zugehörige IP-Adresse für Medien, die an PSTN gesendet werden. Weitere Informationen unter  Bindung.

    dtmf-relay rtp-nte

    Definiert RTP-NTE (RFC2833) als DTMF-Fähigkeit, die auf dem Call-Leg erwartet wird. Weitere Informationen unter  DTMF-Relais (Voice over IP).

    no vad

    Deaktiviert die Erkennung von Sprachaktivitäten. Weitere Informationen unter  vad (Zifferblatt-Peer).

4

Fügen Sie das Anrufrouting unter Verwendung der folgenden Konfigurationen hinzu:

  1. Erstellen Sie Peer-Gruppen, um Anrufe zwischen Unified CM und Webex Calling zu leiten. DPG 100 definieren mit outbound dial-peer 100 in Richtung Webex Calling. DPG 100 wird auf den zugehörigen eingehenden Dial-Peer von Unified CM angewendet. In ähnlicher Weise definieren Sie DPG 300 mit outbound dial-peer 300 in Richtung Unified CM. DPG 300 wird auf den eingehenden Dial-Peer von Webex angewendet.

    
    voice class dpg 100
     description Route calls to Webex Calling
     dial-peer 100
    voice class dpg 300
     description Route calls to Unified CM Webex Calling trunk
     dial-peer 300 
  2. Erstellen Sie eine Dial-Peer-Gruppe, um Anrufe zwischen dem Unified CM und dem PSTN zu leiten. DPG 200 definieren mit outbound dial-peer 200 in Richtung PSTN. DPG 200 wird auf den zugehörigen eingehenden Dial-Peer von Unified CM angewendet. In ähnlicher Weise definieren Sie DPG 400 mit outbound dial-peer 400 in Richtung Unified CM. DPG 400 wird auf den vom PSTN eingehenden Dial-Peer angewendet.

    
    voice class dpg 200
     description Route calls to PSTN
     dial-peer 200
    voice class dpg 400
     description Route calls to Unified CM PSTN trunk
     dial-peer 400

    Hier ist eine Erklärung der Felder für die Konfiguration:

    dial-peer  100

    Verbindet einen ausgehenden Dial-Peer mit einer Dial-Peer-Gruppe. Weitere Informationen unter  Sprachklasse DPG.

  3. Verwenden Sie Dial-Peer-Gruppen, um Anrufe von Webex nach Unified CM und von Unified CM nach Webex zu leiten:

    
    dial-peer voice 100
     destination dpg 300
    dial-peer voice 300
     destination dpg 100

    Hier ist eine Erklärung der Felder für die Konfiguration:

    destination dpg 300

    Gibt an, welche Dial-Peer-Gruppe und daher Dial-Peer für die ausgehende Behandlung von Anrufen verwendet werden soll, die diesem eingehenden Dial-Peer präsentiert werden.

  4. Verwenden Sie Dial-Peer-Gruppen, um Anrufe vom PSTN nach Unified CM und vom Unified CM nach PSTN zu leiten:

    
    dial-peer voice 200
     destination dpg 400
    dial-peer voice 400
     destination dpg 200 

    Damit ist Ihre Local Gateway-Konfiguration abgeschlossen. Speichern Sie die Konfiguration und laden Sie die Plattform neu, wenn dies das erste Mal ist, dass CUBE-Funktionen konfiguriert wurden.

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

  1. Diagnosesignaturen sind standardmäßig aktiviert.

  2. 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 

  3. 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:

  1. Rufen Sie auf. Manage Google Account > Security und schalten Sie Less secure app access Einstellung.

  2. 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.

  1. 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 
    
  2. 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.

  3. 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) 
    
  4. Installieren Sie die DS-XML-Datei auf dem lokalen Gateway.

    call-home diagnostic-signature load DS_64224.xml 
    Load file DS_64224.xml success 
  5. 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.com 

    Laden 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:

  1. 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.

  2. Kopieren Sie die DS-XML-Datei auf das lokale Gateway.

    copy ftp://username:password@<server name or ip>/DS_64117.xml bootflash: 
  3. 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#  
  4. 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.

  1. 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 
    
  2. 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.

  3. Kopieren Sie die DS-XML-Datei auf das lokale Gateway.

    copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:
  4. Installieren Sie die DS-XML-Datei auf dem lokalen Gateway.

    call-home diagnostic-signature load DS_65221.xml 
    Load file DS_65221.xml success 
    
  5. 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:

  1. 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"  
    end 

    Beispiel

    call-home  
    diagnostic-signature 
    environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"  
  2. 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 
  3. 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.

  4. 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

  5. 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: 
  6. 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 
    
  7. Ü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.com 

    Heruntergeladene 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.

Call routing from/to PSTN to/from Webex Calling configuration solution

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.

Solution diagram showing Unified Communications Manager provides centralized routing and treatment of all PSTN and Webex Calling calls

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.

The host names, IP addresses, and interfaces used in certificate based local gateway configurations

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:


interface GigabitEthernet0/0/0
 description Interface facing PSTN and/or CUCM
 ip address 192.168.80.14 255.255.255.0
!
interface GigabitEthernet0/0/1
 description Interface facing Webex Calling (Public address)
 ip address 198.51.100.1 255.255.255.240

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:


key config-key password-encrypt YourPassword
password encryption aes
3

Erstellen Sie einen Verschlüsselungs-Vertrauenspunkt mit einem Zertifikat für Ihre Domain, unterzeichnet von einem unterstütztZertifizierungsstelle (CA).

  1. Erstelle ein RSA-Schlüsselpaar mit dem folgenden exec-Befehl.

    crypto key generate rsa general-keys exportable label lgw-key modulus 4096

  2. Verwenden Sie die folgenden Konfigurationsbefehle, um einen Trustpoint für das Zertifikat zu erstellen und geben Sie die Feldwerte an, die in der Zertifikatsignierungsanfrage verwendet werden sollen:

    
    crypto pki trustpoint LGW_CERT
     enrollment terminal pem
     fqdn none
     subject-name cn=cube1.lgw.com
     subject-alt-name cube1.lgw.com
     revocation-check none
     rsakeypair lgw-key
     hash sha256 

    Hinweise für Zertifikatsfelder:

    • fqdn: Dies ist kein Pflichtfeld für Webex Calling. Setzen Sie diese Konfiguration auf „Keine“, um dieses Feld nicht in der Zertifikatssignierungsanfrage aufzunehmen. Wenn Sie einen FQDN mit diesem Befehl verwenden müssen, hat dies keinen Einfluss auf den Local Gateway-Betrieb.

    • Probandenname: Um Anrufe von einem lokalen Gateway zu validieren, muss Webex die FQDN in den SIP-Kontaktköpfen mit denen übereinstimmen, die entweder im Attribut Common Name (CN) oder im Feld Alternative Name (SAN) des SBC-Zertifikats enthalten sind. Das Betrefffeld muss mindestens ein CN-Attribut enthalten und kann je nach Bedarf weitere Attribute enthalten. Weitere Informationen unter Probandenname.

    • Betreff-alt-Name: Das Feld Subject Alternative Name (SAN) des SBC-Zertifikats kann eine Liste zusätzlicher FQDNs enthalten. Webex überprüft diese Liste, um den SIP-Kontakt-Header in Nachrichten vom lokalen Gateway zu validieren, wenn das Attribut Subject CN des Zertifikats nicht übereinstimmt.

    • Hash: Es wird empfohlen, Zertifikatsunterzeichnungsanfragen (Certificate Signing Request, CSR) mit SHA zu signieren256. Das Cisco IOS XE 17.11.1 verwendet diesen Algorithmus standardmäßig und für frühere Versionen den Befehl Hash.

  3. Erzeugen Sie eine Zertifikatsignierungsanfrage (CSR) mit dem folgenden exec- oder Konfigurationsbefehl und verwenden Sie diese, um ein signiertes Zertifikat von einem unterstützten CA-Anbieter anzufordern:

    crypto pki enroll LGW_CERT

4

Geben Sie das Zertifikat der zwischensignierenden CA an, um Ihr Host-Zertifikat zu authentifizieren. Geben Sie den folgenden exec- oder Konfigurationsbefehl ein:


crypto pki authenticate LGW_CERT
<paste Intermediate X.509 base 64 based certificate here>

5

Importieren Sie das signierte Host-Zertifikat mit dem folgenden exec- oder Konfigurationsbefehl:


crypto pki import LGW_CERT certificate
<paste CUBE host X.509 base 64 certificate here>

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:


 sip-ua
  crypto signaling default trustpoint LGW_CERT
  transport tcp tls v1.2

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

ip http client source-interface GigabitEthernet0/0/1 
crypto pki trustpool import clean url https://www.cisco.com/security/pki/trs/ios_core.p7b
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.

CUBE zertifikatbasierte PSTN-Trunk-Gruppe wird erstellt

2

Geben Sie die folgenden Befehle ein, um CUBE als Webex Calling Local Gateway zu konfigurieren:


voice service voip
 ip address trusted list
  ipv4 x.x.x.x y.y.y.y
 mode border-element
 allow-connections sip to sip
 no supplementary-service sip refer
 stun
  stun flowdata agent-id 1 boot-count 4
  stun flowdata shared-secret 0 Password123$
 sip 
  asymmetric payload full
  early-offer forced
  sip-profiles inbound

Hier ist eine Erklärung der Felder für die Konfiguration:


ip address trusted list
 ipv4 x.x.x.x y.y.y.y
  • Zum Schutz vor Mautbetrug definiert die Liste der vertrauenswürdigen Adressen eine Liste von Hosts und Netzwerkeinheiten, von denen das Local Gateway legitime VoIP-Anrufe erwartet.

  • Standardmäßig blockiert ein Local Gateway alle eingehenden VoIP-Nachrichten von IP-Adressen, die nicht in seiner vertrauenswürdigen Liste stehen. Standardmäßig werden statisch konfigurierte Dial-Peers mit „Session Target IP“- oder Servergruppen-IP-Adressen vertrauenswürdig. Sie müssen diese IP-Adressen nicht der vertrauenswürdigen Liste hinzufügen.

  • Fügen Sie bei der Konfiguration Ihres lokalen Gateways die IP-Subnetze für Ihr regionales Webex Calling-Rechenzentrum in die Liste ein, siehe Port Reference Information für Webex Callingfür weitere Informationen. Fügen Sie auch Adressbereiche für Unified Communications Manager-Server (falls verwendet) und PSTN-Trunk-Gateways hinzu.

  • Weitere Informationen zur Verwendung einer vertrauenswürdigen IP-Adressliste zur Verhinderung von Mautbetrug finden Sie unter: IP-Adresse vertrauenswürdig.

mode border-element

Aktiviert Cisco Unified Border Element (CUBE) Funktionen auf der Plattform.

allow-connections sip to sip

Aktivieren 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).

stun

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.

  • Die STUN-Bindings-Funktion auf dem Local Gateway ermöglicht es, lokal erzeugte STUN-Anfragen über den ausgehandelten Medienpfad zu senden. Dies hilft, die Pinhole in der Firewall zu öffnen.

Weitere Informationen unter  Betäubungsmittelflussdaten-Agent-IDund  Betäubungsmittelflussdaten geheim.

asymmetric payload full

Konfiguriert asymmetrische SIP-Payload-Unterstützung für DTMF- und dynamische Codec-Payloads. Weitere Informationen zu diesem Befehl finden Sie unter asymmetrische Nutzlast.

early-offer forced

Zwingt 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 inbound

Ermö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.


voice class codec 100
 codec preference 1 g711ulaw
 codec preference 2 g711alaw

Hier ist eine Erklärung der Felder für die Konfiguration:

voice class codec 100

Wird 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)


voice class stun-usage 100 
 stun usage firewall-traversal flowdata
 stun usage ice lite

Hier ist eine Erklärung der Felder für die Konfiguration:

stun usage ice lite

Wird 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)


voice class srtp-crypto 100
 crypto 1 AES_CM_128_HMAC_SHA1_80

Hier ist eine Erklärung der Felder für die Konfiguration:

voice class srtp-crypto 100

Gibt 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).


voice class srtp-crypto 100
crypto 1 AEAD_AES_256_GCM

Hier ist eine Erklärung der Felder für die Konfiguration:

voice class srtp-crypto 100

Gibt 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:


voice class uri 100 sip
 pattern cube1.lgw.com

Hier ist eine Erklärung der Felder für die Konfiguration:

voice class uri 100 sip

Legt 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:


voice class sip-profiles 100
 rule 10 request ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:" 
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:" 
 

Hier ist eine Erklärung der Felder für die Konfiguration:

Regeln 10 und 20

Damit 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

voice class sip-profiles 100
 rule 10 request ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 30 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 10.80.13.12" "\1 192.65.79.20"
 rule 31 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 10.80.13.12" "\1 192.65.79.20"
 rule 40 response ANY sdp-header Audio-Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 41 request ANY sdp-header Audio-Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 50 request ANY sdp-header Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 51 response ANY sdp-header Connection-Info modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 60 response ANY sdp-header Session-Owner modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 61 request ANY sdp-header Session-Owner modify "IN IP4 10.80.13.12" "IN IP4 192.65.79.20"
 rule 70 request ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 10.80.13.12" "\1 192.65.79.20"
 rule 71 response ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 10.80.13.12" "\1 192.65.79.20"
 rule 80 request ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 10.80.13.12" "\1 192.65.79.20"
 rule 81 request ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 10.80.13.12" "\1 192.65.79.20"

Hier ist eine Erklärung der Felder für die Konfiguration:

rules 10 and 20

Damit 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 81

Konvertieren 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

voice class sip-profiles 110
 rule 10 response ANY sdp-header Video-Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 20 response ANY sip-header Contact modify "@.*:" "@cube1.lgw.com:"
 rule 30 response ANY sdp-header Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 40 response ANY sdp-header Audio-Connection-Info modify "192.65.79.20" "10.80.13.12"
 rule 50 response ANY sdp-header Session-Owner modify "192.65.79.20" "10.80.13.12"
 rule 60 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 1.*) 192.65.79.20" "\1 10.80.13.12"
 rule 70 response ANY sdp-header Audio-Attribute modify "(a=candidate:1 2.*) 192.65.79.20" "\1 10.80.13.12"
 rule 80 response ANY sdp-header Audio-Attribute modify "(a=rtcp:.*) 192.65.79.20" "\1 10.80.13.12"

Hier ist eine Erklärung der Felder für die Konfiguration:

rules 10 to 80

Konvertiere ö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.


voice class sip-profiles 115
 rule 10 request OPTIONS sip-header Contact modify "<sip:.*:" "<sip:cube1.lgw.com:" 
 rule 30 request ANY sip-header Via modify "(SIP.*) 10.80.13.12" "\1 192.65.79.20"
 rule 40 response ANY sdp-header Connection-Info modify "10.80.13.12" "192.65.79.20"  
 rule 50 response ANY sdp-header Audio-Connection-Info modify "10.80.13.12" "192.65.79.20"
!
voice class sip-options-keepalive 100
 description Keepalive for Webex Calling
 up-interval 5
 transport tcp tls
 sip-profiles 115

Hier ist eine Erklärung der Felder für die Konfiguration:

voice class sip-options-keepalive 100

Konfiguriert 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:

  1. Erstellen voice class tenant 100 um die speziell für den Webex Calling-Trunk erforderlichen Konfigurationen zu definieren und zu gruppieren. Dial-Peers, die mit diesem Mandanten verbunden sind, erben diese Konfigurationen später:

    Das folgende Beispiel verwendet die in Schritt 1 dargestellten Werte für die Zwecke dieser Anleitung (fettgedruckt). Ersetzen Sie diese durch Werte für Ihren Stamm in Ihrer Konfiguration.

    
    voice class tenant 100
     no remote-party-id
     sip-server dns:us25.sipconnect.bcld.webex.com
     srtp-crypto 100
     localhost dns:cube1.lgw.com
     session transport tcp tls
     no session refresh
     error-passthru
     rel1xx disable
     asserted-id pai
     bind control source-interface GigabitEthernet0/0/1
     bind media source-interface GigabitEthernet0/0/1
     no pass-thru content custom-sdp
     sip-profiles 100 
     sip-profiles 110 inbound
     privacy-policy passthru
    !

    Hier ist eine Erklärung der Felder für die Konfiguration:

    voice class tenant 100

    Wir empfehlen Ihnen, Mandanten zur Konfiguration von Trunks zu verwenden, die über ein eigenes TLS-Zertifikat und eine CN- oder SAN-Validierungsliste verfügen. Hier enthält das mit dem Mandanten verbundene TLS-Profil den Vertrauenspunkt, der verwendet werden soll, um neue Verbindungen anzunehmen oder zu erstellen, und verfügt über die CN- oder SAN-Liste, um die eingehenden Verbindungen zu validieren. Weitere Informationen unter Sprachklasse-Mieter.

    no remote-party-id

    Deaktivieren Sie den SIP Remote-Party-ID (RPID)-Header, da Webex Calling PAI unterstützt, die mit einem asserted-id pai Befehl. Weitere Informationen unter Gegenpartei-ID.

    sip-server dns: us25.sipconnect.bcld.webex.com

    Konfiguriert den Ziel-SIP-Server für den Trunk. Verwenden Sie die im Control Hub angegebene Edge-Proxy-SRV-Adresse, wenn Sie Ihren Trunk erstellt haben

    srtp-crypto 100

    Konfiguriert die bevorzugten Chiffriersuiten für den SRTP-Verbindungszweig (Verbindung) (angegeben in Schritt 5). Weitere Informationen unter Sprachklasse SRTP-Crypto.

    localhost dns: cube1.lgw.com

    Konfiguriert CUBE, um die physische IP-Adresse in den Kopfzeilen von From, Call-ID und Remote-Party-ID in ausgehenden Nachrichten durch den bereitgestellten FQDN zu ersetzen. Verwenden Sie hier die im Control Hub für den Kofferraum konfigurierte Stamm-FQDN oder SRV.

    session transport tcp tls

    Legt den Transport zu TLS für zugehörige Zifferblattpeers fest. Weitere Informationen unter Sitzungstransport.

    no session refresh

    Deaktiviert die Aktualisierung der SIP-Sitzung für Anrufe zwischen CUBE und Webex. Weitere Informationen unter Aktualisierung der Sitzung.

    error-passthru

    Gibt die Sip-Fehler-Antwort-Pass-Thru-Funktionalität an. Weitere Informationen unter Fehlerpassthru.

    rel1xx disable

    Deaktiviert die Verwendung zuverlässiger vorläufiger Antworten für den Webex-Anruf-Trunk. Weitere Informationen unter rel.1xx.

    asserted-id pai

    (Optional) Aktiviert die Verarbeitung des P-Asserted-Identity-Headers und steuert, wie diese für den Webex-Calling-Trunk verwendet wird.

    Webex Calling enthält P-Asserted-Identity (PAI)-Header in ausgehende Anruf-INVITEs zum lokalen Gateway.

    Wenn dieser Befehl konfiguriert ist, werden Anruferinformationen aus dem PAI-Header verwendet, um die ausgehenden Von- und PAI/Remote-Party-ID-Header zu füllen.

    Wenn dieser Befehl nicht konfiguriert ist, werden Anruferinformationen aus dem Von-Header verwendet, um die ausgehenden Von- und PAI-/Remote-Party-ID-Header zu füllen.

    Weitere Informationen unter geltend gemachte ID.

    bind control source-interface GigabitEthernet0/0/1

    Konfiguriert die Quellschnittstelle und die zugehörige IP-Adresse für Nachrichten, die an Webex Calling gesendet werden. Weitere Informationen unter Bindung.

    bind media source-interface GigabitEthernet0/0/1

    Konfiguriert die Quellschnittstelle und die zugehörige IP-Adresse für Medien, die an Webex Calling gesendet werden. Weitere Informationen unter Bindung.

    voice-class sip profiles 100

    Wendet das Header-Änderungsprofil (Public IP- oder NAT-Adressierung) für ausgehende Nachrichten an. Weitere Informationen unter Voice-Class-Sip-Profile.

    voice-class sip profiles 110 inbound

    Nur für LGW-Einsätze hinter NAT: Wendet das Header-Änderungsprofil an, das für eingehende Nachrichten verwendet wird. Weitere Informationen finden Sie unter Voice-Class-Sip-Profilen.

    privacy-policy passthru

    Konfiguriert CUBE, um die Privatsphäre-Header der empfangenen Nachricht transparent an den nächsten Aufruf zu übergeben. Weitere Informationen unter Datenschutzerklärung.

  2. Konfigurieren Sie den Webex Calling Trunk-Dial-Peer.

    
    dial-peer voice 100 voip
     description Inbound/Outbound Webex Calling
     destination-pattern BAD.BAD
     session protocol sipv2
     session target sip-server
     incoming uri request 100
     voice-class codec 100
     voice-class stun-usage 100
     voice-class sip tenant 100
     voice-class sip options-keepalive profile 100
     dtmf-relay rtp-nte 
     srtp
     no vad
    

    Hier ist eine Erklärung der Felder für die Konfiguration:

    
    dial-peer voice 100 voip
     description Inbound/Outbound Webex Calling

    Definiert einen VoIP-Dial-Peer mit einem Tag von 100 und gibt eine aussagekräftige Beschreibung für einfache Verwaltung und Fehlerbehebung. Weitere Informationen unter Gegenstimme.

    destination-pattern BAD.BAD

    Beim Routing ausgehender Anrufe unter Verwendung einer eingehenden Dial-Peer-Gruppe ist ein Dummy-Zielmuster erforderlich. Sie können in diesem Fall jedes gültige Zielmuster verwenden. Weitere Informationen unter Ziel-Muster (Schnittstelle).

    session protocol sipv2

    Gibt an, dass dieser Dial-Peer SIP-Call-Legs behandelt. Weitere Informationen unter Sitzungsprotokoll (Dial-Peer).

    session target sip-server

    Zeigt an, dass der im Mandanten 100 definierte SIP-Server vererbt und für das Ziel für Anrufe von diesem Dial-Peer verwendet wird.

    incoming uri request  100

    Gibt die Sprachklasse an, die verwendet wird, um eingehende Anrufe mit diesem Dial-Peer unter Verwendung der URI des INVITE REQUEST-Headers abzugleichen. Weitere Informationen unter  Eingehender URI.

    voice-class codec 100

    Zeigt die Codec-Filterliste für Anrufe von und nach Webex Calling an. Weitere Informationen unter Sprachklasse-Codec.

    voice-class stun-usage 100

    Ermöglicht den Versand lokal erzeugter STUN-Anfragen vom lokalen Gateway über den ausgehandelten Medienpfad. STUN-Pakete helfen, eine Firewall-Pinhole für den Medienverkehr zu öffnen und gültige Pfade für die Medienoptimierung zu erkennen.

    voice-class sip tenant 100

    Der Dial-Peer erbt alle global und im Mandanten 100 konfigurierten Parameter. Die Parameter können auf Dial-Peer-Ebene überschrieben werden. Weitere Informationen unter  Voice-Class-Schlupfmieter.

    voice-class sip options-keepalive profile 100

    Dieser Befehl überwacht die Verfügbarkeit einer Gruppe von SIP-Servern oder Endpunkten anhand eines bestimmten Profils (100).

    srtp

    Aktiviert SRTP für den Anruf-Abschnitt.

  3. (Optional) Erzwingen Sie Anrufe nur für Audio.

    Video über Webex Calling mit Local Gateway Call Flows wird nicht unterstützt. Obwohl Video in einigen Szenarien funktionieren kann, kann es zu verminderter Qualität und unerwartetem Verhalten führen. Um Anrufe nur für Audio zu erzwingen, wenden Sie den folgenden Befehl unter Ihren Webex Calling-Wählgeräten an:

    voice-class sip audio forced

    Wenn Sie sich dafür entscheiden, Videos zuzulassen, führen Anrufe möglicherweise nicht wie erwartet.

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.

  1. Einstellung der Gegenstelle

    Voice service voip
     sip
      pass-thru headers unsupp
    
  2. Dial-Peer-spezifische Konfiguration

    
    Dial-peer voice 911 voip
     voice-class sip pass-thru headers unsupp
  3. Sprachklassenkonfiguration für bestimmte Header

    Zum Proxy der Geostandort-Header:

    
    voice class sip-hdr-passthrulist 200 
     passthru-hdr Geolocation-Routing
     passthru-hdr Geolocation
     passthru-hdr-unsupp

    Pass-Through auf den ein-/ausgehenden Dial-Peer anwenden

    
    dial-peer voice 100 voip  // inbound
     voice-class sip pass-thru headers 200
    dial-peer voice 200 voip  // outbound
     voice-class sip pass-thru headers 200

    Um die Durchführung des PIDFO-Gehäuses zu ermöglichen, verwenden Sie:

    
    voice service voip 
     sip 
      pass-thru content unsupp

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:


voice class uri 200 sip
  host ipv4:192.168.80.13

Hier ist eine Erklärung der Felder für die Konfiguration:

voice class uri 200 sip

Legt 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:


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.13
 incoming uri via 200
 voice-class sip asserted-id pai
 voice-class sip bind control source-interface GigabitEthernet0/0/0 
 voice-class sip bind media source-interface  GigabitEthernet0/0/0 
 voice-class codec 100
 dtmf-relay rtp-nte 
 no vad

Hier ist eine Erklärung der Felder für die Konfiguration:


dial-peer voice 200 voip
 description Inbound/Outbound IP PSTN trunk

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.BAD

Beim 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 sipv2

Gibt an, dass dieser Dial-Peer SIP-Call-Legs behandelt. Weitere Informationen unter Sitzungsprotokoll (Dial Peer).

session target ipv4: 192.168.80.13

Gibt 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 200

Gibt 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/0

Konfiguriert die Quellschnittstelle und die zugehörige IP-Adresse für Medien, die an PSTN gesendet werden. Weitere Informationen unter  Bindung.

voice-class codec 100

Konfiguriert den Dial-Peer, um die gemeinsame Codec-Filterliste 100 zu verwenden. Weitere Informationen unter Sprachklasse-Codec.

dtmf-relay rtp-nte

Definiert RTP-NTE (RFC2833) als DTMF-Fähigkeit, die auf dem Call-Leg erwartet wird. Weitere Informationen unter DTMF-Relais (Voice over IP).

no vad

Deaktiviert 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.

  1. Erstellen Sie Peer-Gruppen, um Anrufe zu Webex Calling oder dem PSTN zu leiten. Definieren Sie DPG 100 mit outbound dial-peer 100 in Richtung Webex Calling. DPG 100 wird auf den vom PSTN eingehenden Dial-Peer angewendet. In ähnlicher Weise definieren Sie DPG 200 mit outbound dial-peer 200 zum PSTN. DPG 200 wird auf den eingehenden Dial-Peer von Webex angewendet.

    
    voice class dpg 100 
     description Route calls to Webex Calling 
     dial-peer 100 
    voice class dpg 200 
     description Route calls to PSTN 
     dial-peer 200

    Hier ist eine Erklärung der Felder für die Konfiguration:

    dial-peer 100

    Verbindet einen ausgehenden Dial-Peer mit einer Dial-Peer-Gruppe. Weitere Informationen unter  Sprachklasse DPG.

  2. Verwenden Sie Dial-Peer-Gruppen, um Anrufe von Webex zum PSTN und von PSTN zu Webex zu leiten:

    
    dial-peer voice 100
     destination dpg 200
    dial-peer voice 200
     destination dpg 100 

    Hier ist eine Erklärung der Felder für die Konfiguration:

    destination dpg 200

    Gibt an, welche Dial-Peer-Gruppe und daher Dial-Peer für die ausgehende Behandlung von Anrufen verwendet werden soll, die diesem eingehenden Dial-Peer präsentiert werden.

    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.

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:


voice translation-rule 100 
 rule 1 /^\+/ /A2A/ 

voice translation-profile 100 
 translate called 100 

voice translation-rule 200 
 rule 1 /^/ /A1A/ 

voice translation-profile 200 
 translate called 200 

voice translation-rule 11 
 rule 1 /^A1A/ // 

voice translation-profile 11 
 translate called 11 

voice translation-rule 12 
 rule 1 /^A2A44/ /0/
 rule 2/^A2A/ /00/

voice translation-profile 12 
 translate called 12 

Hier ist eine Erklärung der Felder für die Konfiguration:

voice translation-rule

Verwendet 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:


card type e1 0 2 
isdn switch-type primary-net5 
controller E1 0/2/0 
 pri-group timeslots 1-31 
3

Konfigurieren Sie den folgenden TDM PSTN-Dial-Peer:


dial-peer voice 200 pots 
 description Inbound/Outbound PRI PSTN trunk 
 destination-pattern BAD.BAD 
 translation-profile incoming 200 
 direct-inward-dial 
 port 0/2/0:15

Hier ist eine Erklärung der Felder für die Konfiguration:


dial-peer voice 200 pots
 description Inbound/Outbound PRI PSTN trunk

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.BAD

Beim 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 200

Weist das Übersetzungsprofil zu, das der eingehenden angerufenen Nummer ein Anrufrouting-Tag hinzufügen wird.

direct-inward-dial

Leitet den Anruf ohne einen sekundären Wählton. Weitere Informationen unter Zifferblatt nach innen.

port 0/2/0:15

Der 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.


dial-peer voice 10 voip
 description Outbound loop-around leg
 destination-pattern BAD.BAD
 session protocol sipv2
 session target ipv4:192.168.80.14
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw
 no vad 

dial-peer voice 11 voip
 description Inbound loop-around leg towards Webex
 translation-profile incoming 11
 session protocol sipv2
 incoming called-number A1AT
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw
 no vad 

dial-peer voice 12 voip
 description Inbound loop-around leg towards PSTN
 translation-profile incoming 12
 session protocol sipv2
 incoming called-number A2AT
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 voice-class sip bind media source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711alaw 
 no vad 

Hier ist eine Erklärung der Felder für die Konfiguration:


dial-peer voice 10 voip
 description Outbound loop-around leg

Definiert einen VoIP-Dial-Peer und gibt eine aussagekräftige Beschreibung für einfache Verwaltung und Fehlerbehebung. Weitere Informationen unter Gegenstimme.

translation-profile incoming 11

Wendet das zuvor definierte Übersetzungsprofil an, um das Call-Routing-Tag zu entfernen, bevor es zum ausgehenden Trunk weitergeleitet wird.

destination-pattern BAD.BAD

Beim Routing ausgehender Anrufe unter Verwendung einer eingehenden Dial-Peer-Gruppe ist ein Dummy-Zielmuster erforderlich. Weitere Informationen unter Ziel-Muster (Schnittstelle).

session protocol sipv2

Gibt an, dass dieser Dial-Peer SIP-Call-Legs behandelt. Weitere Informationen unter  Sitzungsprotokoll (Dial Peer).

session target ipv4: 192.168.80.14

Gibt 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/0

Konfiguriert 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/0

Konfiguriert 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-nte

Definiert 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 vad

Deaktiviert die Erkennung von Sprachaktivitäten. Weitere Informationen unter  vad (Zifferblatt-Peer).

5

Fügen Sie die folgende Konfiguration des Anrufs hinzu:

  1. Erstellen Sie Dial-Peer-Gruppen, um Anrufe zwischen den PSTN- und Webex-Trunks über die Loop-Back-Funktion zu leiten.

    
    voice class dpg 100
     description Route calls to Webex Calling
     dial-peer 100
    voice class dpg 200
     description Route calls to PSTN
     dial-peer 200
    voice class dpg 10
     description Route calls to Loopback
     dial-peer 10

    Hier ist eine Erklärung der Felder für die Konfiguration:

    dial-peer 100

    Verbindet einen ausgehenden Dial-Peer mit einer Dial-Peer-Gruppe. Weitere Informationen unter  Sprachklasse DPG.

  2. Verwenden Sie Dial-Peer-Gruppen für Routenanrufe.

    
    dial-peer voice 100
     destination dpg 10
    dial-peer voice 200
     destination dpg 10
    dial-peer voice 11
     destination dpg 100
    dial-peer voice 12
     destination dpg 200

    Hier ist eine Erklärung der Felder für die Konfiguration:

    destination dpg 200

    Gibt an, welche Dial-Peer-Gruppe und daher Dial-Peer für die ausgehende Behandlung von Anrufen verwendet werden soll, die diesem eingehenden Dial-Peer präsentiert werden.

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:

  1. Klassifiziert Unified CM zu Webex-Anrufen über den SIP VIA-Port:

    
    voice class uri 300 sip
     pattern :5065
    
  2. Klassifiziert Unified CM zu PSTN-Anrufen mit SIP über den Port:

    
    voice class uri 400 sip
     pattern 192\.168\.80\.6[0-5]:5060
    

    Klassifizieren Sie eingehende Nachrichten vom UCM zum PSTN-Trunk unter Verwendung eines oder mehrerer Muster, die die Adressen und Portnummer des Ursprungs beschreiben. Bei Bedarf können reguläre Ausdrücke verwendet werden, um übereinstimmende Muster zu definieren.

    Im obigen Beispiel wird ein regulärer Ausdruck verwendet, um eine beliebige IP-Adresse im Bereich 192.168.80.60 mit 65 und die Portnummer 5060 abzugleichen.

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.


ip host ucmpub.mydomain.com 192.168.80.60
ip host ucmsub1.mydomain.com 192.168.80.61
ip host ucmsub2.mydomain.com 192.168.80.62
ip host ucmsub3.mydomain.com 192.168.80.63
ip host ucmsub4.mydomain.com 192.168.80.64
ip host ucmsub5.mydomain.com 192.168.80.65
ip host _sip._udp.wxtocucm.io srv 0 1 5065 ucmpub.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub1.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub2.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub3.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub4.mydomain.com
ip host _sip._udp.wxtocucm.io srv 2 1 5065 ucmsub5.mydomain.com
ip host _sip._udp.pstntocucm.io srv 0 1 5060 ucmpub.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub1.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub2.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub3.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub4.mydomain.com
ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com

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:

  1. Dial-Peer für Anrufe zwischen Unified CM und Webex Calling:

    
    dial-peer voice 300 voip
     description UCM-Webex Calling trunk
     destination-pattern BAD.BAD
     session protocol sipv2
     session target dns:wxtocucm.io
     incoming uri via 300
     voice-class codec 100
     voice-class sip bind control source-interface GigabitEthernet 0/0/0
     voice-class sip bind media source-interface GigabitEthernet 0/0/0
     dtmf-relay rtp-nte
     no vad
    

    Hier ist eine Erklärung der Felder für die Konfiguration:

    
    dial-peer voice 300 voip
     description UCM-Webex Calling trunk

    Definiert einen VoIP-Dial-Peer mit einem Tag 300 und gibt eine aussagekräftige Beschreibung für einfache Verwaltung und Fehlerbehebung.

    destination-pattern BAD.BAD

    Beim 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.

    session protocol sipv2

    Gibt an, dass Dial-Peer 300 SIP-Call-Legs bearbeitet. Weitere Informationen unter  Sitzungsprotokoll (Dial-Peer).

    session target dns:wxtocucm.io

    Definiert das Sitzungsziel mehrerer Unified CM-Knoten durch DNS SRV-Auflösung. In diesem Fall wird der lokal definierte SRV-Datensatz wxtocucm.io verwendet, um Anrufe zu leiten.

    incoming uri via 300

    Nutzt die Sprachklasse-URI 300, um den gesamten eingehenden Datenverkehr von Unified CM über den Quellport 5065 zu diesem Dial-Peer zu leiten. Weitere Informationen unter  Eingehender URI.

    voice-class codec 100

    Zeigt die Codec-Filterliste für Anrufe von und nach Unified CM an. Weitere Informationen unter  Sprachklasse-Codec.

    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/0

    Konfiguriert die Quellschnittstelle und die zugehörige IP-Adresse für Medien, die an PSTN gesendet werden. Weitere Informationen unter  Bindung.

    dtmf-relay rtp-nte

    Definiert RTP-NTE (RFC2833) als DTMF-Fähigkeit, die auf dem Call-Leg erwartet wird. Weitere Informationen unter  DTMF-Relais (Voice over IP).

    no vad

    Deaktiviert die Erkennung von Sprachaktivitäten. Weitere Informationen unter  vad (Zifferblatt-Peer).

  2. Dial-Peer für Anrufe zwischen Unified CM und PSTN:

    
    dial-peer voice 400 voip
     description UCM-PSTN trunk
     destination-pattern BAD.BAD
     session protocol sipv2
     session target dns:pstntocucm.io
     incoming uri via 400
     voice-class codec 100 
     voice-class sip bind control source-interface GigabitEthernet 0/0/0
     voice-class sip bind media source-interface GigabitEthernet 0/0/0
     dtmf-relay rtp-nte
     no vad
    

    Hier ist eine Erklärung der Felder für die Konfiguration:

    
    dial-peer voice 400 voip
     description UCM-PSTN trunk

    Definiert einen VoIP-Dial-Peer mit einem Tag von 400 und gibt eine aussagekräftige Beschreibung für einfache Verwaltung und Fehlerbehebung.

    destination-pattern BAD.BAD

    Beim 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.

    session protocol sipv2

    Gibt an, dass Dial-Peer 400 SIP-Call-Legs bearbeitet. Weitere Informationen unter  Sitzungsprotokoll (Dial-Peer).

    session target dns:pstntocucm.io

    Definiert das Sitzungsziel mehrerer Unified CM-Knoten durch DNS SRV-Auflösung. In diesem Fall wird der lokal definierte SRV-Datensatz pstntocucm.io verwendet, um Anrufe zu leiten.

    incoming uri via 400

    Verwendet die Sprachklasse-URI 400, um den gesamten eingehenden Datenverkehr von den angegebenen Unified CM-Hosts über den Quellport 5060 zu diesem Dial-Peer zu leiten. Weitere Informationen unter  Eingehender URI.

    voice-class codec 100

    Zeigt die Codec-Filterliste für Anrufe von und nach Unified CM an. Weitere Informationen unter  Sprachklasse-Codec.

    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/0

    Konfiguriert die Quellschnittstelle und die zugehörige IP-Adresse für Medien, die an PSTN gesendet werden. Weitere Informationen unter  Bindung.

    dtmf-relay rtp-nte

    Definiert RTP-NTE (RFC2833) als DTMF-Fähigkeit, die auf dem Call-Leg erwartet wird. Weitere Informationen unter  DTMF-Relais (Voice over IP).

    no vad

    Deaktiviert die Erkennung von Sprachaktivitäten. Weitere Informationen unter  vad (Zifferblatt-Peer).

4

Fügen Sie das Anrufrouting unter Verwendung der folgenden Konfigurationen hinzu:

  1. Erstellen Sie Peer-Gruppen, um Anrufe zwischen Unified CM und Webex Calling zu leiten. DPG 100 definieren mit outbound dial-peer 100 in Richtung Webex Calling. DPG 100 wird auf den zugehörigen eingehenden Dial-Peer von Unified CM angewendet. In ähnlicher Weise definieren Sie DPG 300 mit outbound dial-peer 300 in Richtung Unified CM. DPG 300 wird auf den eingehenden Dial-Peer von Webex angewendet.

    
    voice class dpg 100
     description Route calls to Webex Calling
     dial-peer 100
    voice class dpg 300
     description Route calls to Unified CM Webex Calling trunk
     dial-peer 300 
  2. Erstellen Sie eine Dial-Peer-Gruppe, um Anrufe zwischen dem Unified CM und dem PSTN zu leiten. DPG 200 definieren mit outbound dial-peer 200 in Richtung PSTN. DPG 200 wird auf den zugehörigen eingehenden Dial-Peer von Unified CM angewendet. In ähnlicher Weise definieren Sie DPG 400 mit outbound dial-peer 400 in Richtung Unified CM. DPG 400 wird auf den vom PSTN eingehenden Dial-Peer angewendet.

    
    voice class dpg 200
     description Route calls to PSTN
     dial-peer 200
    voice class dpg 400
     description Route calls to Unified CM PSTN trunk
     dial-peer 400

    Hier ist eine Erklärung der Felder für die Konfiguration:

    dial-peer  100

    Verbindet einen ausgehenden Dial-Peer mit einer Dial-Peer-Gruppe. Weitere Informationen unter  Sprachklasse DPG.

  3. Verwenden Sie Dial-Peer-Gruppen, um Anrufe von Webex nach Unified CM und von Unified CM nach Webex zu leiten:

    
    dial-peer voice 100
     destination dpg 300
    dial-peer voice 300
     destination dpg 100

    Hier ist eine Erklärung der Felder für die Konfiguration:

    destination dpg 300

    Gibt an, welche Dial-Peer-Gruppe und daher Dial-Peer für die ausgehende Behandlung von Anrufen verwendet werden soll, die diesem eingehenden Dial-Peer präsentiert werden.

  4. Verwenden Sie Dial-Peer-Gruppen, um Anrufe vom PSTN nach Unified CM und vom Unified CM nach PSTN zu leiten:

    
    dial-peer voice 200
     destination dpg 400
    dial-peer voice 400
     destination dpg 200 

    Damit ist Ihre Local Gateway-Konfiguration abgeschlossen. Speichern Sie die Konfiguration und laden Sie die Plattform neu, wenn dies das erste Mal ist, dass CUBE-Funktionen konfiguriert wurden.

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

  1. Diagnosesignaturen sind standardmäßig aktiviert.

  2. 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 

  3. 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.

  1. 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 
    
  2. 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

    Download DS 64224 from Diagnostic Signatures Lookup tool
  3. 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) 
    
  4. Installieren Sie die DS-XML-Datei auf dem lokalen Gateway.

    
    call-home diagnostic-signature load DS_64224.xml 
    Load file DS_64224.xml success  
  5. 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.com 

    Laden 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.

  1. 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 
  2. 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.

  3. Kopieren Sie die DS-XML-Datei auf das lokale Gateway.

    copy ftp://username:password@<server name or ip>/DS_65221.xml bootflash:
  4. Installieren Sie die DS-XML-Datei auf dem lokalen Gateway.

    
    call-home diagnostic-signature load DS_65221.xml 
    Load file DS_65221.xml success 
  5. 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:

  1. 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.

    The file upload token generated in the Attachments section of the Support Case Manager
    
    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"  
    end 

    Beispiel

    
    call-home  
    diagnostic-signature 
    environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"  
  2. 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 
  3. 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.

  4. 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

  5. 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: 
  6. 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 
    
  7. Ü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.com 

    Heruntergeladene 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.

Notification email that is sent during Diagnostic Signature execution

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.

War dieser Artikel hilfreich für Sie?
War dieser Artikel hilfreich für Sie?