Verwenden Sie diesen Aufgabenablauf, um ein lokales Gateway für Ihren Webex Calling-Übertragungsweg zu konfigurieren. Die folgenden Schritte werden über die Befehlszeile auf dem lokalen Gateway ausgeführt. Der Übertragungsweg zwischen dem lokalen Gateway und Webex Calling wird immer mit SIP TLS und SRTP für Medien zwischen dem lokalen Gateway und dem Webex Calling Access SBC gesichert.

Vorbereitungen

  • Machen Sie sich mit den lokalen PSTN-Anforderungen (lokales Gateway) für Webex Calling vertraut.

  • Erstellen Sie einen Übertragungsweg im Control Hub, und weisen Sie ihn dem gewünschten Standort zu.

  • Bei den in diesem Dokument angegebenen Konfigurationsrichtlinien wird davon ausgegangen, dass eine dedizierte Plattform für das lokale Gateway ohne Sprachkonfiguration vorhanden ist. Wenn ein vorhandenes PSTN-Gateway oder eine Cube-Unternehmensbereitstellung geändert wird, um auch die lokale Gateway-Funktion für Webex Calling zu verwenden, achten Sie sorgfältig auf die angewendete Konfiguration, und stellen Sie sicher, dass vorhandene Anrufverläufe und -funktionen nicht infolge von vorgenommenen Änderungen unterbrochen werden.

  Befehl oder Aktion Zweck
1

Parameterzuordnung zwischen Control Hub und Cisco Unified Border Element

Verwenden Sie diese Tabelle als Referenz für die Parameter, die von Control Hub kommen und deren Zuordnung zum lokalen Gateway.

2

Durchführen der Konfiguration der Referenzplattform

Führen Sie diese Schritte als allgemeine globale Konfiguration für das lokale Gateway aus. Die Konfiguration umfasst die Konfiguration der Baseline-Plattform und eine Aktualisierung des Vertrauenspools.

3

Lokales Gateway bei Webex Calling registrieren

4

Eine Option abhängig von der Bereitstellung wählen:

Die Anrufverteilung auf dem lokalen Gateway basiert auf der von Ihnen gewählten Webex Calling-Bereitstellungsoption. In diesem Abschnitt wird davon ausgegangen, dass sich das IP PSTN-Ende auf derselben Plattform wie das lokale Gateway befindet. Die nachstehende Konfiguration gilt für eine der folgenden Optionen auf dem lokalen Gateway:

  • Die Bereitstellungsoption des lokalen Gateways ohne eine lokale IP PBX. Das lokale Gateway und IP PSTN CUBE sind gleichzeitig vorhanden.

  • Die Bereitstellungsoption für das lokale Gateway befindet sich in einer vorhandenen Unified CM-Umgebung. Das lokale Gateway und IP PSTN CUBE sind gleichzeitig vorhanden.

Tabelle 1: Parameterzuordnung zwischen Control Hub und lokalem Gateway

Control Hub

Lokales Gateway

Registrar-Domäne:

Control Hub sollte die Domäne vom LinePort analysieren, der von der UCAPI empfangen wird.

example.com

Registrar

example.com

OTG/DTG der Trunk-Gruppe

SIP-Profile:

rule <rule-number> request ANY sip-header

From modify ">" ";otg=otgDtgId>"

Leitung/Port

user@example.com

Nummer: Benutzer

Ausgehender Proxy

ausgehender Proxy (DNS-Name – SRV des Access SBC)

SIP-Benutzername

Benutzername

SIP-Passwort

Passwort

Vorbereitungen

  • Stellen Sie sicher, dass die Konfiguration der Baseline-Plattform wie NTPs, ACLs, Passwörter aktivieren, primäres Passwort, IP-Routing, IP-Adressen usw. gemäß den Richtlinien und Verfahren Ihrer Organisation konfiguriert sind.

  • Für alle LGW-Bereitstellungen ist mindestens unterstützte Version IOS-XE 16.12 oder IOS-XE 17.3 erforderlich.

1

Stellen Sie sicher, dass allen Schnittstellen der Schicht 3 gültige und routingfähige IP-Adressen zugewiesen sind:

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
 ip address 192.168.43.197 255.255.255.0
2

Sie müssen einen primären Schlüssel für das Passwort mithilfe der unten aufgeführten Befehle vorkonfigurieren, bevor es in den Anmeldedaten und den gemeinsamen geheimen Schlüsseln verwendet werden kann. Typ-6-Passwörter werden mit AES-Verschlüsselung und benutzerdefiniertem primärem Schlüssel verschlüsselt.


LocalGateway#conf t
LocalGateway(config)#key config-key password-encrypt Password123
LocalGateway(config)#password encryption aes
3

Konfigurieren Sie den IP Name Server, um die DNS-Suche zu aktivieren und sicherzustellen, dass er erreichbar ist, indem Sie ihn anpingen:


LocalGateway#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
LocalGateway(config)#ip name-server 8.8.8.8
LocalGateway(config)#end
4

Aktivieren Sie TLS 1.2 Exclusivity und einen Standardplatzhalter-Trustpoint:

  1. Erstellen sie einen Platzhalter-PKI-Trustpoint und nennen Sie ihn sampleTP.

  2. Weisen Sie den Trustpoint als standardmäßigen Signalisierungs-Trustpoint unter sip-ua zu.

  3. cn-san-validate server ist erforderlich, um sicherzustellen, dass das lokale Gateway die Verbindung nur dann herstellt, wenn der auf tenant 200 (später beschrieben) konfigurierte ausgehende Proxy der CN-SAN-Liste entspricht, die vom Server empfangen wird.

  4. Der Crypto-Trustpoint ist für das Funktionieren von TLS erforderlich, auch wenn für die Einrichtung der Verbindung kein lokales Clientzertifikat (z. B. mTLS) erforderlich ist.

  5. Deaktivieren Sie TLS v1.0 und v1.1, indem Sie v1.2-Exklusivität aktivieren.

  6. Legen Sie den Zähler für tcp-retry auf 1000 fest (Vielfache von 5 ms = 5 Sekunden).

  7. (IOS-XE 17.3.2 und höher) Legen Sie timers connection establish tls <wait-timer in="" sec=""> fest. Der Bereich liegt zwischen 5 und 20 Sekunden, der Standardwert beträgt 20 Sekunden. (LGW braucht 20 Sekunden, um den TLS-Verbindungsfehler zu erkennen, bevor versucht wird, eine Verbindung zum nächsten verfügbaren Webex Calling Access SBC herzustellen. Mit dieser CLI kann der Administrator den Wert ändern, um Netzwerkbedingungen anzupassen und Verbindungsfehler bei Access SBC viel schneller zu erkennen.)


LocalGateway#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
LocalGateway(config)#
LocalGateway(config)#crypto pki trustpoint sampleTP
LocalGateway(ca-trustpoint)# revocation-check crl
LocalGateway(ca-trustpoint)#exit

LocalGateway(config)#sip-ua
LocalGateway(config-sip-ua)# crypto signaling default trustpoint sampleTP cn-san-validate server

LocalGateway(config-sip-ua)# transport tcp tls v1.2
LocalGateway(config-sip-ua)# tcp-retry 1000
LocalGateway(config-sip-ua)#end
5

Aktualisieren Sie den Trustpool des lokalen Gateways:

Das standardmäßige Trustpool-Paket umfasst nicht die Zertifikate "Die Zertifikatzertifizierungsstelle" oder die Zertifikate "IdenTrust Commercial", die für die Validierung des serverseitigen Zertifikats während der TLS-Verbindungseinrichtung im Webex Calling.

Das Trustpool-Paket muss aktualisiert werden, indem das neueste „Cisco Trusted Core Root Bundle“ von http://www.cisco.com/security/pki/ heruntergeladen wird.

  1. Überprüfen Sie, ob die kommerziellen Zertifikate "HexCert Room CA" und "IdenTrust" vorhanden sind:

    
    LocalGateway#show crypto pki trustpool | include DigiCert
  2. Wenn dies nicht der Fall ist, aktualisieren Sie wie folgt:

    
    LocalGateway#configure terminal
    Enter configuration commands, one per line.  End with CNTL/Z.
    LocalGateway(config)#crypto pki trustpool import clean url 
    http://www.cisco.com/security/pki/trs/ios_core.p7b
    Reading file from http://www.cisco.com/security/pki/trs/ios_core.p7b
    Loading http://www.cisco.com/security/pki/trs/ios_core.p7b 
    % PEM files import succeeded.
    LocalGateway(config)#end
    
  1. Überprüfen:

    
    LocalGateway#show crypto pki trustpool | include DigiCert
    cn=DigiCert Global Root CA
    o=DigiCert Inc
    cn=DigiCert Global Root CA
    o=DigiCert Inc
    
    LocalGateway#show crypto pki trustpool | include IdenTrust Commercial
    cn=IdenTrust Commercial Root CA 1
    cn=IdenTrust Commercial Root CA 1

Vorbereitungen

Stellen Sie sicher, dass Sie die Schritte in Control Hub abgeschlossen haben, um einen Standort zu erstellen und einen Übertragungsweg für diesen Standort hinzuzufügen. In dem hier gezeigten Beispiel wurden die Informationen vom Control Hub abgerufen.

1

Geben Sie diese Befehle ein, um die lokale Gateway-Anwendung zu aktivieren (die neuesten IP-Subnetze, die zur Vertrauensliste hinzugefügt werden müssen, finden Sie unter Port-Referenzinformationen für Cisco Webex Calling):

LocalGateway#configure terminal
LocalGateway(config)#voice service voip
LocalGateway(conf-voi-serv)#ip address trusted list
LocalGateway(cfg-iptrust-list)#ipv4 x.x.x.x y.y.y.y
LocalGateway(cfg-iptrust-list)#exit
LocalGateway(conf-voi-serv)#allow-connections sip to sip
LocalGateway(conf-voi-serv)#media statistics
LocalGateway(conf-voi-serv)#media bulk-stats
LocalGateway(conf-voi-serv)#no supplementary-service sip refer
LocalGateway(conf-voi-serv)#no supplementary-service sip handle-replaces
LocalGateway(conf-voi-serv)# fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none

LocalGateway(conf-serv-stun)#stun
LocalGateway(conf-serv-stun)#stun flowdata agent-id 1 boot-count 4
LocalGateway(conf-serv-stun)#stun flowdata shared-secret 0 Password123$

LocalGateway(conf-serv-stun)#sip

   LocalGateway(conf-serv-sip)#g729 annexb-all
   LocalGateway(conf-serv-sip)#early-offer forced
   LocalGateway(conf-serv-sip)#end

Erläuterung der Befehle:

Schutz vor Gebührenbetrug
Device(config)# voice service voip
Device(config-voi-serv)# ip address trusted list
Device(cfg-iptrust-list)# ipv4 x.x.x.x y.y.y.y
  • Explizite Aktivierung der Quell-IP-Adressen von Einheiten, von denen das lokale Gateway berechtigte VoIP-Anrufe erwartet, beispielsweise Webex Calling-Peers, Unified CM-Knoten, IP-PSTN.

  • Standardmäßig blockiert LGW alle Einrichtungen eingehender VoIP-Anrufe von IP-Adressen, die nicht in der Vertrauensliste enthalten sind. IP-Adressen von Dial-Peers mit „Sitzungsziel-IP“ oder Servergruppe sind standardmäßig vertrauenswürdig und müssen hier nicht angegeben werden.

  • Die IP-Adressen in dieser Liste müssen mit den IP-Subnetzen übereinstimmen, je nach dem regionalen Webex Calling-Rechenzentrum, mit dem der Kunde verbunden ist. Weitere Informationen finden Sie unter Port-Referenzinformationen für Webex Calling.


     

    Wenn sich Ihr LGW hinter einer Firewall mit eingeschränktem Cone NAT befindet, können Sie die Vertrauensliste mit den IP-Adressen auf der Webex Calling-Schnittstelle deaktivieren. Dies liegt daran, dass die Firewall Sie bereits vor unerwünschtem eingehenden VoIP schützt. Durch diese Aktion würde ihr Konfigurations-Overhead längerfristig reduziert, da wir nicht garantieren können, dass die Adressen der Webex Calling-Peers fest bleiben und Sie Ihre Firewall in jedem Fall für die Peers konfigurieren müssten.

  • Andere IP-Adressen müssen möglicherweise auf anderen Schnittstellen konfiguriert werden; zum Beispiel müssen Ihre Unified CM-Adressen zu den nach innen gerichteten Schnittstellen hinzugefügt werden.

  • IP-Adressen müssen mit der IP-Adresse der Hosts übereinstimmen, in die outbound-proxy in tenant 200 aufgelöst wird.

  • Weitere Informationen finden Sie unter https://www.cisco.com/c/en/us/support/docs/voice/call-routing-dial-plans/112083-tollfraud-ios.html.

Medien
voice service voip
 media statistics 
 media bulk-stats 
  • Media Statistics ermöglicht die Medienüberwachung auf dem lokalen Gateway.

  • Media bulk-stats ermöglicht es der Steuerungsebene, die Datenebene nach Massenanruf-Statistiken abzufragen.

SIP-zu-SIP-Grundfunktionen
allow-connections sip to sip
Zusätzliche Dienste
 no supplementary-service sip refer
 no supplementary-service sip handle-replaces

Deaktiviert REFER und ersetzt die Dialog-ID in der Replaces-Kopfzeile durch die Peer-Dialog-ID.

Weitere Informationen finden Sie unter https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr4/vcr4-cr-book/vcr-s12.html#wp2876138889.

Faxprotokoll
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none

Ermöglicht T.38 für den Faxtransport, obwohl der Fax-Datenverkehr nicht verschlüsselt wird.

Globale STUN aktivieren
stun
  stun flowdata agent-id 1 boot-count 4
  stun flowdata shared-secret 0 Password123$
  • Wenn ein Anruf an einen Webex Calling-Benutzer zurückgeleitet wird (sowohl der Angerufene als auch der Anrufer sind beispielsweise Webex Calling-Abonnenten und die Medien sind am Webex Calling-SBC verankert), können die Medien nicht an das lokale Gateway weitergeleitet werden, da das Loch nicht geöffnet ist.

  • Mit der STUN-Bindungsfunktion auf dem lokalen Gateway können lokal generierte STUN-Anforderungen über den ausgehandelten Medienpfad gesendet werden. Dadurch lässt sich der Port der Firewall öffnen.

  • Das STUN-Passwort ist eine Voraussetzung für das lokale Gateway, um STUN-Nachrichten zu versenden. IOS/IOS-XE-basierte Firewalls können so konfiguriert werden, dass sie nach diesem Passwort suchen und Löcher dynamisch öffnen (zum Beispiel ohne explizite In-Out-Regeln). Im Falle der Bereitstellung des lokalen Gateways ist die Firewall jedoch statisch so konfiguriert, dass sie Ports für ein- und ausgehenden Datenverkehr auf Basis der Webex Calling SBC-Subnetze öffnet. Daher sollte die Firewall dies nur als eingehendes UDP-Paket behandeln, das das Öffnen des Ports auslöst, ohne explizit den Paketinhalt zu betrachten.

G729
sip
  g729 annexb-all

Ermöglicht alle Varianten von G729.

SIP:
early-offer forced

Zwingt das lokale Gateway dazu, die SDP-Informationen in der ersten INVITE-Nachricht zu senden, anstatt auf Bestätigung vom Nachbar-Peer zu warten.

2

Konfigurieren Sie SIP-Profil 200.

LocalGateway(config)# voice class sip-profiles 200
LocalGateway (config-class)# rule 9 request ANY sip-header SIP-Req-URI modify "sips:(.*)" "sip:\1"
LocalGateway (config-class)# rule 10 request ANY sip-header To modify "<sips:(.*)" "<sip:\1"
LocalGateway (config-class)# rule 11 request ANY sip-header From modify "<sips:(.*)" "<sip:\1"
LocalGateway (config-class)# rule 12 request ANY sip-header Contact modify "<sips:(.*)>" "<sip:\1;transport=tls>" 
LocalGateway (config-class)# rule 13 response ANY sip-header To modify "<sips:(.*)" "<sip:\1"
LocalGateway (config-class)# rule 14 response ANY sip-header From modify "<sips:(.*)" "<sip:\1"
LocalGateway (config-class)# rule 15 response ANY sip-header Contact modify "<sips:(.*)" "<sip:\1"
LocalGateway (config-class)# rule 20 request ANY sip-header From modify ">" ";otg=hussain2572_lgu>"
LocalGateway (config-class)# rule 30 request ANY sip-header P-Asserted-Identity modify "sips:(.*)" "sip:\1"

Diese Regeln sind

Erläuterung der Befehle:

  • rule 9 stellt sicher, dass die Kopfzeile als “SIP-Req-URI” aufgeführt wird und nicht als “SIP-Req-URL”

    Dies konvertiert zwischen SIP-URIs und SIP-URLs, weil Webex Calling in den Anforderungs-/Antwortnachrichten keine SIP-URIs unterstützt, sie jedoch für SRV-Anfragen benötigt, z. B. _sips._tcp.<outbound-proxy>.
  • rule 20 ändert die From-Kopfzeile so, dass der OTG/DTG-Parameter der Übertragungsweg-Gruppe aus dem Control Hub eine LGW-Site innerhalb eines Unternehmens eindeutig identifiziert.

  • Dieses SIP-Profil wird auf „voice class tenant 200“ (später besprochen) für den gesamten Datenverkehr mit Webex Calling-Zugriff angewandt.

3

Konfigurieren Sie das Codec-Profil, die STUN-Definition und die SRTP Crypto-Suite.

LocalGateway(config)# voice class codec 99
LocalGateway(config-class)# codec preference 1 g711ulaw
LocalGateway(config-class)# codec preference 2 g711alaw 
LocalGateway(config-class)# exit
LocalGateway(config)# voice class srtp-crypto 200
LocalGateway(config-class)# crypto 1 AES_CM_128_HMAC_SHA1_80
LocalGateway(config-class)# exit
LocalGateway(config)# voice class stun-usage 200
LocalGateway(config-class)# stun usage firewall-traversal flowdata
LocalGateway(config-class)# stun usage ice lite
LocalGateway(config-class)# exit

Erläuterung der Befehle:

  • Voice class codec 99: Ermöglicht beide g711-Codecs (mu und a-law) für Sitzungen. Wird auf alle Dial-Peers angewendet.

  • Voice class srtp-crypto 200: Gibt SHA1 80 als die einzige SRTP-Verschlüsselungs-Suite an, die über ein lokales Gateway_im SDP-Angebot und -Antwort angeboten wird. Webex Calling unterstützt nur SHA1_80.

  • Wird auf voice class tenant 200 (später besprochen) mit Webex Calling-Zugriff angewendet.

  • Voice class stun-usage 200: Definiert die STUN-Nutzung. Wird auf alle Webex Calling-Dial-Peers (2XX-Tag) angewendet, um ein No-Way-Audio zu vermeiden, wenn ein Unified CM-Telefon den Anruf an ein anderes Webex Calling-Telefon weiterleitet.


 

In Fällen, in denen Medien am ITSP-SBC verankert sind und sich das lokale Gateway hinter einer NAT befindet und auf den eingehenden Mediendatenstrom von ITSP wartet, kann dieser Befehl auf ITSP-Dial-Peers angewandt werden.


 

„Stun usage ice lite“ ist für Anrufverläufe erforderlich, die eine Medienpfadoptimierung verwenden.

4

Ordnen Sie der Konfiguration des lokalen Gateways Control Hub-Parameter zu:

Webex Calling wird als Mandant innerhalb des lokalen Gateways hinzugefügt. Die Konfiguration zum Registrieren des lokalen Gateways ist unter voice class tenant 200 definiert. Sie müssen die Elemente dieser Konfiguration auf der Seite „Übertragungsweg-Info“ im Control Hub abrufen, wie in diesem Bild dargestellt. Dieses Beispiel zeigt, welche Felder der jeweiligen lokalen Gateway-CLI zugeordnet werden.

Tenant 200 wird anschließend auf alle Dial-Peers mit Webex Calling-Zugriff (2xx-Tag) innerhalb der Konfiguration des lokalen Gateways angewendet. Die Funktion „voice class tenant“ ermöglicht die Gruppierung und Konfiguration von SIP-Übertragungswegparametern, die ansonsten unter „voice service voip“ und „sip-ua“ erfolgt. Wenn ein Mandant unter einem Dial-Peer konfiguriert und angewendet wird, werden die IOS-XE-Konfigurationen in der folgenden bevorzugten Reihenfolge angewendet:

  • Dial-Peer-Konfiguration

  • Mandantenkonfiguration

  • Globale Konfiguration (voice service voip / sip-ua)

5

Konfigurieren Sie voice class tenant 200, um die Registrierung des Übertragungswegs von LGW zu Webex Calling auf Basis der Parameter zu ermöglichen, die Sie vom Control Hub erhalten haben:


 

Die folgende Befehlszeile und die Parameter dienen nur als Beispiel. Sie müssen die Parameter für Ihre eigene Bereitstellung verwenden.

LocalGateway(config)#voice class tenant 200
  registrar dns:40462196.cisco-bcld.com scheme sips expires 240 refresh-ratio 50 tcp tls
  credentials number Hussain6346_LGU username Hussain2572_LGU password 0 meX7]~)VmF realm BroadWorks
  authentication username Hussain2572_LGU password 0 meX7]~)VmF realm BroadWorks
  authentication username Hussain2572_LGU password 0 meX7]~)VmF realm 40462196.cisco-bcld.com
  no remote-party-id
  sip-server dns:40462196.cisco-bcld.com
  connection-reuse
  srtp-crypto 200
  session transport tcp tls 
  url sips 
  error-passthru
  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 200 
  outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com  
  privacy-policy passthru

Erläuterung der Befehle:

voice class tenant 200

Die Multitenant-Funktion eines lokalen Gateways ermöglicht spezifische globale Konfigurationen für mehrere Mandanten auf SIP-Übertragungswegen, die differenzierte Dienste für Mandanten ermöglichen.

registrar dns:40462196.cisco-bcld.com scheme sips expires 240 refresh-ratio 50 tcp tls

Registrar-Server für das lokale Gateway, bei dem die Registrierung alle zwei Minuten aktualisiert wird (50 % von 240 Sekunden). Weitere Informationen finden Sie unter https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr3/vcr3-cr-book/vcr-r1.html#wp1687622014.

credentials number Hussain6346_LGU username Hussain2572_LGU password 0 meX71]~)Vmf realm BroadWorks

Anmeldedaten für die Registrierung des Übertragungswegs. Weitere Informationen finden Sie unter https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr1/vcr1-cr-book/vcr-c6.html#wp3153621104.

authentication username Hussain2572_LGU password 0 meX71]~)Vmf realm BroadWorks
authentication username Hussain2572_LGU password 0 meX71]~)Vmf realm 40462196.cisco-bcld.com

Authentifizierungsaufforderungen für Anrufe. Weitere Informationen finden Sie unter https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr1/vcr1-cr-book/vcr-a1.html#wp1551532462.

no remote-party-id

Deaktivieren Sie die SIP-Remote-Party-ID (RPID)-Kopfzeile, weil Webex Calling PAI unterstützt, die mit CIO aktiviert wird asserted-id pai(siehe unten).

sip-server dns:40462196.cisco-bcld.com
Webex Calling-Server. Weitere Informationen finden Sie unter https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr1/vcr1-cr-book/vcr-a1.html#wp1551532462
connection-reuse

Um dieselbe dauerhafte Verbindung für die Registrierung und Anrufverarbeitung zu verwenden.

srtp-crypto 200

Gibt SHA1_80 gemäß der Definition in voice class srtp-crypto 200 definiert.

session transport tcp tls
Legt den Transport auf TLS fest.
url sips

SRV-Abfragen müssen SIPs sein, wie von Access SBC unterstützt; alle anderen Nachrichten werden von sip-profile 200 in SIP geändert.

error-passthru

Pass-Thru-Funktionalität für SIP-Fehlerantwort.

asserted-id pai

Aktiviert die PAI-Verarbeitung im lokalen Gateway.

bind control source-interface GigabitEthernet0/0/1

Signalisierungsquellschnittstelle für Webex Calling.

bind media source-interface GigabitEthernet0/0/1

Medienquellschnittstelle für Webex Calling.

no pass-thru content custom-sdp

Standardbefehl unter Mandant.

sip-profiles 200

Ändert SIPS in SIP und Leitung/Port für INVITE- und REGISTER-Nachrichten gemäß Definition in voice class sip-profiles 200 definiert.

outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com

Webex Calling Access SBC. Weitere Informationen finden Sie unter https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr3/vcr3-cr-book/vcr-o1.html#wp3297755699.

privacy-policy passthru

Kopfzeilenwerte zur Privatsphäre vom eingehenden zum ausgehenden Abschnitt transparent übergeben.

Nachdem „tenant 200“ innerhalb des lokalen Gateways definiert und ein SIP VoIP-Dial-Peer konfiguriert wurde, initiiert das Gateway eine TLS-Verbindung zu Webex Calling. An diesem Punkt legt Access SBC dem lokalen Gateway sein Zertifikat vor. Das lokale Gateway überprüft das Webex Calling Access SBC-Zertifikat mithilfe des zuvor aktualisierten CA-Stammpakets. Zwischen dem lokale Gateway und Webex Calling Access SBC wird eine dauerhafte TLS-Sitzung aufgebaut. Das lokale Gateway sendet anschließend REGISTER an Access SBC, das abgefragt wird. Die Registrierungs-AOR ist number@domain. Die Nummer wird vom Parameter „number“ der Anmeldedaten und die Domäne von „registrar dns:<fqdn>“ genommen. Wenn die Registrierung abgefragt wird, werden die Parameter username, password und realm der Anmeldedaten (credentials) verwendet, um die Kopfzeile zu erstellen, und sip-profile 200 konvertiert die SIPS-URL zurück zu SIP. Die Registrierung ist erfolgreich, wenn 200 OK vom Access SBC empfangen wird.

Für diese Bereitstellungsoption ist die folgende Konfiguration auf dem lokalen Gateway erforderlich:

  1. Voice class tenants (Sprachklassenmandanten) – Zunächst erstellen wir zusätzliche Mandanten für ITSP-Dial-Peers ähnlich tenant 200, den wir für Webex Calling-Dial-Peers erstellt haben.

  2. Voice class URIs (Sprachklassen-URIs) – Muster, die die Host-IP-Adressen/Ports für verschiedene Übertragungswege definieren, die am lokalen Gateway enden: Webex Calling zu LGW; und PSTN SIP-Übertragungswegende auf LGW.

  3. Outbound dial-peers (Ausgehende Dial-Peers) – Um ausgehende Anrufabschnitte vom LGW zum ITSP SIP-Übertragungsweg und Webex Calling zu leiten.

  4. Voice class DPG (Sprachklassen-DPG) – Als Ziel vorgesehene(r) ausgehende(r) Dial-Peer(s), der/die von einem eingehenden Dial-Peer aufgerufen wird bzw. werden.

  5. Inbound dial-peers (Eingehende Dial-Peers) – Um eingehende Anrufabschnitte von ITSP und Webex Calling anzunehmen.

Die Konfiguration in diesem Abschnitt kann für die Einrichtung eines von einem Partner gehosteten lokalen Gateways, wie unten gezeigt, oder von einem kundenseitigen lokalen Gateway verwendet werden.

1

Konfigurieren Sie die folgenden Sprachklassenmandanten:

  1. Voice class tenant 100 wird auf alle AUSGEHENDEN IP-PSTN-Dial-Peers angewendet.

    voice class tenant 100 
      session transport udp
      url sip
      error-passthru
      bind control source-interface GigabitEthernet0/0/0
      bind media source-interface GigabitEthernet0/0/0
      no pass-thru content custom-sdp
    
  2. Voice class tenant 300 wird auf alle EINGEHENDEN Dial-Peers vom IP-PSTN angewendet.

    voice class tenant 300 
      bind control source-interface GigabitEthernet0/0/0
      bind media source-interface GigabitEthernet0/0/0
      no pass-thru content custom-sdp
    
2

Konfigurieren Sie die folgende Sprachklassen-URI:

  1. Definieren Sie die Host-IP-Adresse des ITSP:

    voice class uri 100 sip
      host ipv4:192.168.80.13
    
  2. Definieren Sie ein Muster, um die Site eines lokalen Gateways innerhalb eines Unternehmens auf Basis des Control Hub-Parameters TrunkGroup OTG/DTG eindeutig zu identifizieren:

    voice class uri 200 sip
     pattern dtg=hussain2572.lgu
    

     

    Lokales Gateway unterstützt zurzeit keinen Unterstrich "_" im Übereinstimmungsmuster. Zur Umgehung des Problems verwenden wir einen Punkt „.“ (übereinstimmungen) mit dem "_" übereinstimmen.

    Received
    INVITE sip:+16785550123@198.18.1.226:5061;transport=tls;dtg=hussain2572_lgu SIP/2.0
       Via: SIP/2.0/TLS 199.59.70.30:8934;branch=z9hG4bK2hokad30fg14d0358060.1
     pattern :8934
    
3

Konfigurieren Sie die folgenden ausgehenden Dial-Peers:

  1. Ausgehender Dial-Peer in Richtung IP-PSTN:

    dial-peer voice 101 voip 
     description Outgoing dial-peer to IP PSTN
     destination-pattern BAD.BAD
     session protocol sipv2
     session target ipv4:192.168.80.13
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class sip tenant 100
     no vad

    Erläuterung der Befehle:

    dial-peer voice 101 voip
     description Outgoing dial-peer to PSTN
    

    Definiert einen VOIP-Dial-Peer mit dem Tag 101 und eine aussagekräftige Beschreibung für eine einfache Verwaltung und Fehlerbehebung.

    destination-pattern BAD.BAD

    Ziffernmuster, mit dem dieser Dial-Peer ausgewählt werden kann. Wir rufen diesen ausgehenden Dial-Peer jedoch direkt vom eingehenden Dial-Peer mit DPG-Anweisungen auf und umgehen die Zahlenmuster-Übereinstimmungskriterien. Aus diesem Grund verwenden wir ein beliebiges Muster basierend auf alphanumerischen Ziffern, die von der CLI des Zielmusters zugelassen werden.

    session protocol sipv2

    Gibt an, dass dieser Dial-Peer SIP-Anrufabschnitte behandeln wird.

    session target ipv4:192.168.80.13

    Gibt die IPv4-Zieladresse des Ziels an, an die dieser Anrufabschnitt gesendet wird. In diesem Fall die IP-Adresse des ITSP.

    voice-class codec 99

    Gibt an, dass die Codec-Präferenzliste 99 für diesen Dial-Peer verwendet werden soll.

    dtmf-relay rtp-nte

    Definiert RTP-NTE (RFC2833) als erwartete DTMF-Funktion in diesem Anrufabschnitt.

    voice-class sip tenant 100

    Der Dial-Peer übernimmt alle Parameter von Tenant 100, es sei denn, derselbe Parameter ist unter dem Dial-Peer selbst definiert.

    no vad

    Deaktiviert die Erkennung von Sprachaktivitäten.

  2. Ausgehender Dial-Peer zu Webex Calling (Dieser Dial-Peer wird später in der Konfigurationsanleitung aktualisiert, um von Webex Calling auch als eingehender Dial-Peer verwendet zu werden).

    dial-peer voice 200201 voip
     description Inbound/Outbound Webex Calling
     destination-pattern BAD.BAD
     session protocol sipv2
     session target sip-server
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class stun-usage 200
     no voice-class sip localhost
     voice-class sip tenant 200
     srtp
     no vad
    

    Erläuterung der Befehle:

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

    Definiert einen VOIP-Dial-Peer mit dem Tag 200201 und eine aussagekräftigen Beschreibung für eine einfache Verwaltung und Fehlerbehebung.

    session target sip-server

    Gibt an, dass der globale SIP-Server das Ziel für Anrufe von diesem Dial-Peer ist. Webex Calling-Server, der in tenant 200 definiert ist, wird von diesem Dial-Peer übernommen.

    voice-class stun-usage 200

    Mit der STUN-Bindungsfunktion auf dem lokalen Gateway können lokal generierte STUN-Anforderungen über den ausgehandelten Medienpfad gesendet werden. Dadurch lässt sich der Port der Firewall öffnen.

    no voice-class sip localhost

    Deaktiviert die Ersetzung des DNS-Localhost-Namens durch die physische IP-Adresse in den Kopfzeilen „From“, „Call-ID“ und „Remote-Party-ID“ von ausgehenden Nachrichten.

    voice-class sip tenant 200

    Der Dial-Peer übernimmt alle Parameter von Tenant 200 (LGW <--> Webex Calling-Übertragungsweg), sofern der Parameter nicht unter dem Dial-Peer selbst definiert ist.

    srtp

    SRTP ist für diesen Anrufabschnitt aktiviert.

    no vad

    Deaktiviert die Erkennung von Sprachaktivitäten.

4

Konfigurieren Sie die folgenden Dial-Peer-Gruppen (DPG):

  1. Definiert Dial-Peer-Gruppe 100. Der ausgehende Dial-Peer 101 ist das Ziel für alle eingehenden Dial-Peers, die Dial-Peer-Gruppe 100 aufrufen. Wir wenden DPG 100 auf den eingehenden Dial-Peer 200201 für den Pfad Webex Calling --> LGW --> PSTN an.

    voice class dpg 100
     description Incoming WxC(DP200201) to IP PSTN(DP101)
     dial-peer 101 preference 1
    
  2. Definieren Sie Dial-Peer-Gruppe 200 mit dem ausgehenden Dial-Peer 200201 als Ziel für den Pfad PSTN --> LGW --> Webex Calling. DPG 200 wird auf den später definierten eingehenden Dial-Peer 100 angewendet.

    voice class dpg 200
     description Incoming IP PSTN(DP100) to Webex Calling(DP200201)
     dial-peer 200201 preference 1
    
5

Konfigurieren Sie die folgenden eingehenden Dial-Peers:

  1. Eingehender Dial-Peer für eingehende IP-PSTN-Anrufabschnitte:

    dial-peer voice 100 voip
     description Incoming dial-peer from PSTN
     session protocol sipv2
     destination dpg 200
     incoming uri via 100
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class sip tenant 300
     no vad
    

    Erläuterung der Befehle

    dial-peer voice 100 voip
    description Incoming dial-peer from PSTN

    Definiert einen VOIP-Dial-Peer mit dem Tag 100 und eine aussagekräftige Beschreibung für eine einfache Verwaltung und Fehlerbehebung.

    session protocol sipv2

    Gibt an, dass dieser Dial-Peer SIP-Anrufabschnitte behandeln wird.

    incoming uri via 100

    Der gesamte eingehende Datenverkehr von IP PSTN zu LocalGW wird auf der Host-IP-Adresse der eingehenden VIA-Kopfzeile zugeordnet, die in der Sprachklasse URI 100 SIP definiert ist, um eine Zuordnung auf Basis der IP-Quelladresse (ITSP) vorzunehmen.

    destination dpg 200

    Mit dem Ziel-DPG 200 umgeht IOS-XE die klassischen ausgehenden Dial-Peer-Übereinstimmungskriterien und richtet sofort den ausgehenden Anrufabschnitt mithilfe der Dial-Peers ein, die innerhalb der Ziel-Dial-Peer-Gruppe 200, d. h. Dial-Peer 200201, definiert sind.

    voice-class sip tenant 300

    Der Dial-Peer übernimmt alle Parameter von Tenant 300, es sei denn, derselbe Parameter ist unter dem Dial-Peer selbst definiert.

    no vad

    Deaktiviert die Erkennung von Sprachaktivitäten.

  2. Eingehender Dial-Peer für eingehende Webex Calling-Anrufabschnitte:

    dial-peer voice 200201 voip
     description Inbound/Outbound Webex Calling
     max-conn 250
     destination dpg 100
     incoming uri request 200
     

    Erläuterung der Befehle

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

    Aktualisiert einen VOIP-Dial-Peer mit dem Tag 200201 und einer aussagekräftigen Beschreibung für eine einfache Verwaltung und Fehlerbehebung.

    incoming uri request 200

    Der gesamte eingehende Datenverkehr von Webex Calling zum LGW kann anhand des eindeutigen DTG-Musters in der Anfrage-URI zugeordnet werden, wodurch die Site des lokalen Gateways in einem Unternehmen und im Webex Calling-Ökosystem eindeutig identifiziert wird.

    destination dpg 100

    Mit dem Ziel-DPG 100 umgeht IOS-XE die klassischen ausgehenden Dial-Peer-Übereinstimmungskriterien und richtet sofort den ausgehenden Anrufabschnitt mithilfe der Dial-Peers ein, die innerhalb der Ziel-Dial-Peer-Gruppe 100, d. h. Dial-Peer 101, definiert sind.

    max-conn 250

    Begrenzt die Anzahl der gleichzeitigen Anrufe zwischen dem LGW und Webex Calling auf 250, unter der Annahme, dass ein Single Dial-Peer Webex Calling für eingehende und ausgehende Anrufe gemäß der Definition in diesem Handbuch direkt Webex Calling wird. Weitere Informationen zu Einschränkungen bei gleichzeitigen Anrufen mit einem lokalen Gateway finden Sie unter https://www.cisco.com/c/dam/en/us/td/docs/solutions/PA/mcp/DEPLOYMENT_CALLING_Unified_CM_to_Webex_Calling.pdf.

PSTN zu Webex Calling

Alle eingehenden IP-PSTN-Anrufabschnitte auf dem lokalen Gateway werden auf Dial-Peer 100 zugeordnet, weil er ein Übereinstimmungskriterium für die VIA-Kopfzeile mit der IP-Adresse des IP-PSTN definiert. Die Auswahl von ausgehenden Dial-Peers wird durch DPG 200 bestimmt, das den ausgehenden Dial-Peer 200201 direkt aufruft, bei dem der Webex Calling-Server als Zielort aufgeführt ist.

Webex Calling zu PSTN

Alle eingehenden Webex Calling-Anrufabschnitte auf dem lokalen Gateway werden auf Dial-Peer 200201 zugeordnet, weil er Übereinstimmungskriterien für das REQUEST URI-Kopfzeilenmuster mit dem Parameter TrunkGroup OTG/DTG erfüllt, der für die Bereitstellung dieses lokalen Gateways eindeutig ist. Die Auswahl von ausgehenden Dial-Peers wird durch DPG 100 bestimmt, das den ausgehenden Dial-Peer 101 direkt aufruft, bei dem die IP-Adresse für IP-PSTN als Zielort aufgeführt ist.

Für diese Bereitstellungsoption ist die folgende Konfiguration auf dem lokalen Gateway erforderlich:

  1. Sprachklassenmandanten (voice class tenants) – Sie müssen zusätzliche Mandanten für Dial-Peers mit Unified CM- und ITSP-Zugriff erstellen, ähnlich tenant 200, den wir für Dial-Peers mit Webex Calling-Zugriff erstellt haben.

  2. Sprachklassen-URIs (voice class URIs) – Muster, die die Host-IP-Adressen/Ports für verschiedene Übertragungswege definieren, die am LGW enden: vom Unified CM zum LGW für PSTN-Ziele; Unified CM zu LGW für Webex Calling-Ziele; Webex Calling zu LGW; und PSTN-SIP-Übertragungswegbeendigung auf LGW.

  3. Sprachklasse Servergruppe (voice class server-group) – Ziel-IP-Adressen/Ports für ausgehende Übertragungswege vom LGW zu Unified CM, LGW zu Webex Calling und LGW zum PSTN SIP-Übertragungsweg.

  4. Ausgehende Dial-Peers – Um ausgehende Anrufabschnitte vom LGW zu Unified CM, ITSP SIP-Übertragungsweg und/oder Webex Calling zu leiten.

  5. Voice class DPG (Sprachklassen-DPG) – Als Ziel vorgesehene(r) ausgehende(r) Dial-Peer(s), der/die von einem eingehenden Dial-Peer aufgerufen wird bzw. werden.

  6. Inbound dial-peers (Eingehende Dial-Peers) – Um eingehende Anrufabschnitte von Unified CM, ITSP und/oder Webex Calling anzunehmen.

1

Konfigurieren Sie die folgenden Sprachklassenmandanten:

  1. Voice class tenant 100 wird auf alle ausgehenden Unified CM- und IP-PSTN-Dial-Peers angewendet:

    voice class tenant 100 
      session transport udp
      url sip
      error-passthru
      bind control source-interface GigabitEthernet0/0/0
      bind media source-interface GigabitEthernet0/0/0
      no pass-thru content custom-sdp
    
  2. Voice class tenant 300 wird auf alle eingehende Dial-Peers von Unified CM und IP-PSTN angewendet:

    voice class tenant 300 
      bind control source-interface GigabitEthernet0/0/0
      bind media source-interface GigabitEthernet0/0/0
      no pass-thru content custom-sdp
    
2

Konfigurieren Sie die folgenden Sprachklassen-URIs:

  1. Definiert die Host-IP-Adresse des ITSP:

    voice class uri 100 sip
      host ipv4:192.168.80.13
    
  2. Definieren Sie ein Muster, um die Site eines lokalen Gateways innerhalb eines Unternehmens auf Basis des Control Hub-Parameters TrunkGroup OTG/DTG eindeutig zu identifizieren:

    voice class uri 200 sip
     pattern dtg=hussain2572.lgu
    

     

    Das lokale Gateway unterstützt derzeit keinen Unterstrich "_" im Übereinstimmungsmuster. Zur Umgehung des Problems verwenden wir einen Punkt „.“ (übereinstimmungen) mit dem "_" übereinstimmen.

    Received
    INVITE sip:+16785550123@198.18.1.226:5061;transport=tls;dtg=hussain2572_lgu SIP/2.0
       Via: SIP/2.0/TLS 199.59.70.30:8934;branch=z9hG4bK2hokad30fg14d0358060.1
     pattern :8934
    
  3. Definiert den VIA-Port für die Unified CM-Signalisierung des Webex Calling-Übertragungswegs:

    voice class uri 300 sip
     pattern :5065
    
  4. Definiert CUCM-Quellsignalisierungs-IP und VIA-Port für den PSTN-Übertragungsweg:

    voice class uri 302 sip
     pattern 192.168.80.60:5060
    
3

Konfigurieren Sie die folgenden Sprachklassen-Servergruppen:

  1. Definiert die IP-Adresse des Zielhosts für den Unified CM-Übertragungsweg und die Port-Nummer für die Unified CM-Gruppe 1 (5 Knoten). Unified CM verwendet Port 5065 für eingehenden Datenverkehr auf dem Webex Calling-Übertragungsweg (Webex Calling <-> LGW --> Unified CM).

    voice class server-group 301
     ipv4 192.168.80.60 port 5065
    
  2. Definiert die IP-Adresse des Zielhosts für den Unified CM-Übertragungsweg und die Port-Nummer für die Unified CM-Gruppe 2, sofern zutreffend:

    voice class server-group 303
     ipv4 192.168.80.60 port 5065
    
  3. Definiert die IP-Adresse des Zielhosts für den Unified CM-Übertragungsweg der Unified CM-Gruppe 1 (5 Knoten). Unified CM verwendet Standardport 5060 für den eingehenden Datenverkehr auf dem PSTN-Übertragungsweg. Wenn keine Portnummer angegeben ist, wird der Standardport 5060 verwendet. (PSTN <-> LGW --> Unified CM)

    voice class server-group 305
     ipv4 192.168.80.60
    
  4. Definiert die IP-Adresse des Zielhosts für den Unified CM-Übertragungsweg der Unified CM-Gruppe 2, sofern zutreffend.

    voice class server-group 307 
     ipv4 192.168.80.60
    
4

Konfigurieren Sie die folgenden ausgehenden Dial-Peers:

  1. Ausgehender Dial-Peer zu IP PSTN:

    dial-peer voice 101 voip 
     description Outgoing dial-peer to IP PSTN
     destination-pattern BAD.BAD
     session protocol sipv2
     session target ipv4:192.168.80.13
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class sip tenant 100
     no vad
    

    Erläuterung der Befehle

    dial-peer voice 101 voip
    description Outgoing dial-peer to PSTN

    Definiert einen VOIP-Dial-Peer mit dem Tag 101 und eine aussagekräftige Beschreibung für eine einfache Verwaltung und Fehlerbehebung.

    destination-pattern BAD.BAD

    Ziffernmuster, mit dem dieser Dial-Peer ausgewählt werden kann. Wir rufen diesen ausgehenden Dial-Peer jedoch direkt vom eingehenden Dial-Peer mit DPG-Anweisungen auf und umgehen die Zahlenmuster-Übereinstimmungskriterien. Aus diesem Grund verwenden wir ein beliebiges Muster basierend auf alphanumerischen Ziffern, die von der CLI des Zielmusters zugelassen werden.

    session protocol sipv2

    Gibt an, dass dieser Dial-Peer SIP-Anrufabschnitte behandeln wird.

    session target ipv4:192.168.80.13

    Gibt die IPv4-Zieladresse des Ziels an, an die dieser Anrufabschnitt gesendet wird.(In diesem Fall die IP-Adresse des ITSP.)

    voice-class codec 99

    Gibt an, dass die Codec-Präferenzliste 99 für diesen Dial-Peer verwendet werden soll.

    voice-class sip tenant 100

    Der Dial-Peer übernimmt alle Parameter von Tenant 100, es sei denn, derselbe Parameter ist unter dem Dial-Peer selbst definiert.

  2. Ausgehender Dial-Peer zu Webex Calling (Dieser Dial-Peer wird später in der Konfigurationsanleitung aktualisiert, um von Webex Calling auch als eingehender Dial-Peer verwendet zu werden).

    dial-peer voice 200201 voip
     description Inbound/Outbound Webex Calling
     destination-pattern BAD.BAD
     session protocol sipv2
     session target sip-server
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class stun-usage 200
     no voice-class sip localhost
     voice-class sip tenant 200
     srtp
     no vad
    

    Erläuterung der Befehle

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

    Definiert einen VOIP-Dial-Peer mit dem Tag 200201 und eine aussagekräftige Beschreibung für eine einfache Verwaltung und Fehlerbehebung.

    session target sip-server

    Gibt an, dass der globale SIP-Server das Ziel für Anrufe von diesem Dial-Peer ist. Webex Calling-Server, der in tenant 200 definiert ist, wird von diesem Dial-Peer übernommen.

    voice-class stun-usage 200

    Mit der STUN-Bindungsfunktion auf dem LGW können lokal generierte STUN-Anforderungen über den ausgehandelten Medienpfad gesendet werden. Dadurch lässt sich der Port der Firewall öffnen.

    no voice-class sip localhost

    Deaktiviert die Ersetzung des DNS-Localhost-Namens durch die physische IP-Adresse in den Kopfzeilen „From“, „Call-ID“ und „Remote-Party-ID“ von ausgehenden Nachrichten.

    voice-class sip tenant 200

    Der Dial-Peer übernimmt alle Parameter von Tenant 200 (LGW <--> Webex Calling-Übertragungsweg), sofern der Parameter nicht unter dem Dial-Peer selbst definiert ist.

    srtp

    SRTP ist für diesen Anrufabschnitt aktiviert.

  3. Ausgehender Dial-Peer zu Webex Calling-Übertragungsweg von Unified CM:

    dial-peer voice 301 voip
     description Outgoing dial-peer to CUCM-Group-1 for 
    inbound from Webex Calling - Nodes 1 to 5
     destination-pattern BAD.BAD
     session protocol sipv2
     session server-group 301
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class sip tenant 100
     no vad
    

    Erläuterung der Befehle

    dial-peer voice 301 voip
    description Outgoing dial-peer to CUCM-Group-1 for 
    inbound from Webex Calling – Nodes 1 to 5

    Definiert einen VOIP-Dial-Peer mit dem Tag 301 und eine aussagekräftige Beschreibung für eine einfache Verwaltung und Fehlerbehebung.

    session server-group 301

    Anstatt auf die Sitzungsziel-IP im Dial-Peer zeigen wir auf eine Zielservergruppe (server-group 301 für Dial-Peer 301), um mehrere UCM-Zielknoten zu definieren; das Beispiel zeigt allerdings nur einen einzigen Knoten.

    Servergruppe im ausgehenden Dial-Peer

    Mit mehreren Dial-Peers in der DPG und mehreren Servern in der Dial-Peer-Servergruppe können wir eine zufällige Verteilung der Anrufe über alle Abonnenten der Unified CM-Anrufverarbeitung oder auf Sammelanschlussbasis entsprechend einer definierten Einstellung erreichen. Jede Servergruppe kann bis zu fünf Server haben (IPv4/v6 mit oder ohne Port). Eine zweite Dial-Peer- und eine zweite Servergruppe ist nur erforderlich, wenn mehr als fünf Anrufverarbeitungsabonnenten verwendet werden.

    Weitere Informationen finden Sie unter https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/multiple-server-groups.html.

  4. Zweiter ausgehender Dial-Peer zu Webex Calling-Übertragungsweg von Unified CM, wenn Sie mehr als fünf Unified CM-Knoten haben:

    dial-peer voice 303 voip
     description Outgoing dial-peer to CUCM-Group-2 
    for inbound from Webex Calling - Nodes 6 to 10
     destination-pattern BAD.BAD
     session protocol sipv2
     session server-group 303
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class sip tenant 100
     no vad
  5. Ausgehender Dial-Peer zu PSTN-Übertragungsweg von Unified CM:

    dial-peer voice 305 voip
     description Outgoing dial-peer to CUCM-Group-1 
    for inbound from PSTN - Nodes 1 to 5
     destination-pattern BAD.BAD
     session protocol sipv2
     session server-group 305
     voice-class codec 99 
     dtmf-relay rtp-nte
     voice-class sip tenant 100
     no vad
    
  6. Zweiter ausgehender Dial-Peer zu PSTN-Übertragungsweg von Unified CM, wenn Sie mehr als fünf Unified CM-Knoten haben:

    dial-peer voice 307 voip
     description Outgoing dial-peer to CUCM-Group-2 
    for inbound from PSTN - Nodes 6 to 10
     destination-pattern BAD.BAD
     session protocol sipv2
     session server-group 307
     voice-class codec 99  
     dtmf-relay rtp-nte
     voice-class sip tenant 100
     no vad
    
5

Konfigurieren Sie die folgende DPG:

  1. Definiert DPG 100. Der ausgehende Dial-Peer 101 ist das Ziel für alle eingehenden Dial-Peers, die Dial-Peer-Gruppe 100 aufrufen. Wir wenden DPG 100 auf den eingehenden Dial-Peer 302 an, der später für den Pfad Unified CM --> LGW --> PSTN definiert wird:

    voice class dpg 100
     dial-peer 101 preference 1
    
  2. Definieren Sie DPG 200 mit dem ausgehenden Dial-Peer 200201 als Ziel für den Pfad Unified CM --> LGW --> Webex Calling:

    voice class dpg 200
     dial-peer 200201 preference 1
    
  3. Definieren Sie DPG 300 für die ausgehenden Dial-Peers 301 oder 303 für den Pfad Webex Calling --> LGW --> Unified CM:

    voice class dpg 300
     dial-peer 301 preference 1
     dial-peer 303 preference 1
    
  4. Definieren Sie DPG 302 für die ausgehenden Dial-Peers 305 oder 307 für den Pfad PSTN --> LGW --> Unified CM:

    voice class dpg 302
     dial-peer 305 preference 1
     dial-peer 307 preference 1
    
6

Konfigurieren Sie die folgenden eingehenden Dial-Peers:

  1. Eingehender Dial-Peer für eingehende IP-PSTN-Anrufabschnitte:

    dial-peer voice 100 voip
     description Incoming dial-peer from PSTN
     session protocol sipv2
     destination dpg 302
     incoming uri via 100
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class sip tenant 300
     no vad
    

    Erläuterung der Befehle

    dial-peer voice 100 voip
    description Incoming dial-peer from PSTN

    Definiert einen VOIP-Dial-Peer mit dem Tag 100 und eine aussagekräftige Beschreibung für eine einfache Verwaltung und Fehlerbehebung.

    session protocol sipv2

    Gibt an, dass dieser Dial-Peer SIP-Anrufabschnitte behandeln wird.

    incoming uri via 100

    Der gesamte eingehende Datenverkehr von IP PSTN zu LGW wird auf der Host-IP-Adresse der eingehenden VIA-Kopfzeile zugeordnet, die in der Sprachklasse URI 100 SIP definiert ist, um eine Zuordnung auf Basis der IP-Quelladresse (ITSP) vorzunehmen.

    destination dpg 302

    Mit dem Ziel-DPG 302 umgeht IOS-XE die klassischen ausgehenden Dial-Peer-Übereinstimmungskriterien und richtet sofort den ausgehenden Anrufabschnitt mithilfe der Dial-Peers ein, die innerhalb der Ziel-DPG 302 (entweder Dial-Peer 305 oder Dial-Peer 307) definiert sind.

    voice-class sip tenant 300

    Der Dial-Peer übernimmt alle Parameter von Tenant 300, es sei denn, derselbe Parameter ist unter dem Dial-Peer selbst definiert.

  2. Eingehender Dial-Peer für eingehende Webex Calling-Anrufabschnitte:

    dial-peer voice 200201 voip
     description Inbound/Outbound Webex Calling
     max-conn 250
     destination dpg 300
     incoming uri request 200
     

    Erläuterung der Befehle

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

    Aktualisiert einen VOIP-Dial-Peer mit dem Tag 200201 und einer aussagekräftigen Beschreibung für eine einfache Verwaltung und Fehlerbehebung.

    incoming uri request 200

    Der gesamte eingehende Datenverkehr von Webex Calling zum LGW kann anhand des eindeutigen DTG-Musters in der Anfrage-URI zugeordnet werden, wodurch eine Site des lokalen Gateways in einem Unternehmen und im Webex Calling-Ökosystem eindeutig identifiziert wird.

    destination dpg 300

    Mit dem Ziel-DPG 300 umgeht IOS-XE die klassischen ausgehenden Dial-Peer-Übereinstimmungskriterien und richtet sofort den ausgehenden Anrufabschnitt mithilfe der Dial-Peers ein, die innerhalb der Ziel-DPG 300 (entweder Dial-Peer 301 oder Dial-Peer 303) definiert sind.

    max-conn 250

    Begrenzt die Anzahl der gleichzeitigen Anrufe zwischen dem LGW und Webex Calling auf 250, unter der Annahme, dass ein Single Dial-Peer-Webex Calling für eingehende und ausgehende Anrufe gemäß der Definition in diesem Leitfaden verwendet wird. Weitere Informationen zu Einschränkungen bei gleichzeitigen Anrufen mit einem lokalen Gateway finden Sie unter https://www.cisco.com/c/dam/en/us/td/docs/solutions/PA/mcp/DEPLOYMENT_CALLING_Unified_CM_to_Webex_Calling.pdf.

  3. Eingehender Dial-Peer für eingehende Unified CM-Anrufabschnitte mit Webex Calling als Ziel:

    dial-peer voice 300 voip
     description Incoming dial-peer from CUCM for Webex Calling
     session protocol sipv2
     destination dpg 200
     incoming uri via 300
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class sip tenant 300
     no vad
    

    Erläuterung der Befehle

    dial-peer voice 300 voip
    description Incoming dial-peer from CUCM for Webex Calling

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

    incoming uri via 300

    Der gesamte eingehende Datenverkehr von Unified CM zum LGW wird auf dem Via-Quellport (5065) zugeordnet, der in Sprachklasse URI 300 SIP definiert ist.

    destination dpg 200

    Mit dem Ziel-DPG 200 umgeht IOS-XE die klassischen ausgehenden Dial-Peer-Übereinstimmungskriterien und richtet sofort den ausgehenden Anrufabschnitt mithilfe der Dial-Peers ein, die innerhalb der Ziel-DPG 200, d. h. Dial-Peer 200201, definiert sind.

    voice-class sip tenant 300

    Der Dial-Peer übernimmt alle Parameter von Tenant 300, es sei denn, derselbe Parameter ist unter dem Dial-Peer selbst definiert.

  4. Eingehender Dial-Peer für eingehende Unified CM-Anrufabschnitte mit PSTN als Ziel:

    dial-peer voice 302 voip
     description Incoming dial-peer from CUCM for PSTN
     session protocol sipv2
     destination dpg 100
     incoming uri via 302
     voice-class codec 99
     dtmf-relay rtp-nte
     voice-class sip tenant 300
     no vad
    

    Erläuterung der Befehle

    dial-peer voice 302 voip
    description Incoming dial-peer from CUCM for PSTN

    Definiert einen VOIP-Dial-Peer mit dem Tag 302 und einer aussagekräftigen Beschreibung für eine einfache Verwaltung und Fehlerbehebung.

    incoming uri via 302

    Der gesamte eingehende Datenverkehr von Unified CM zum LGW für ein PSTN-Ziel wird auf der IP-Adresse für die Unified CM-Quellsignalisierung und dem VIA-Port zugeordnet, der in Sprachklasse URI 302 SIP definiert ist. SIP-Standardport 5060 wird verwendet.

    destination dpg 100

    Mit dem Ziel-DPG 100 umgeht IOS-XE die klassischen ausgehenden Dial-Peer-Übereinstimmungskriterien und richtet sofort den ausgehenden Anrufabschnitt mithilfe der Dial-Peers ein, die innerhalb der Ziel-DPG 100, d. h. Dial-Peer 101, definiert sind.

    voice-class sip tenant 300

    Der Dial-Peer übernimmt alle Parameter von Tenant 300, es sei denn, derselbe Parameter ist unter dem Dial-Peer selbst definiert.

IP PSTN zu Unified CM PSTN-Übertragungsweg

Webex Calling-Plattform zu Unified CM Webex Calling-Übertragungsweg

Unified CM PSTN-Übertragungsweg zu IP PSTN

Unified CM Webex Calling-Übertragungsweg zu Webex Calling-Plattform

Diagnosesignaturen (DS) erkennen proaktiv häufig beobachtete Probleme im IOS XE-basierten lokalen Gateway und generieren eine E-Mail-, Syslog- oder Terminal-Benachrichtigung für das Event. 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.

Diagnosesignaturen (DS) sind XML-Dateien, die Informationen über Problemauslöse-Events und Maßnahmen enthalten, um das Problem zu melden und zu lösen. Die Logik zur Problemerkennung wird mithilfe von Syslog-Meldungen, SNMP-Events und der regelmäßigen Überwachung bestimmter Show-Befehlsausgaben definiert. Zu den Aktionstypen gehören das Sammeln von Show-Befehlsausgaben, das Generieren einer konsolidierten Protokolldatei und das Hochladen der Datei auf einen vom Benutzer bereitgestellten Netzwerkspeicherort wie HTTPS, SCP oder FTP-Server. DS-Dateien werden von TAC-Technikern verfasst und sind digital zum Schutz der Integrität signiert. Jede DS-Datei hat eine eindeutige numerische ID, die vom System zugewiesen wird. DLST (Diagnostic Signature Lookup Tool) ist eine zentrale Quelle für die Suche nach passenden Signaturen zur Überwachung und Behebung verschiedener Probleme.

Vorbereitungen:

  • Bearbeiten Sie nicht die vom DSLT heruntergeladene DS-Datei. Geänderte Dateien werden aufgrund eines Fehlers bei der Integritätsprüfung nicht installiert.

  • Zum Senden von E-Mail-Benachrichtigungen ist ein SMTP-Server (Simple Mail Transfer Protocol) für das lokale Gateway erforderlich.

  • Stellen Sie sicher, dass auf dem lokalen Gateway IOS XE 17.3.2 oder höher ausgeführt wird, wenn Sie einen sicheren SMTP-Server für E-Mail-Benachrichtigungen verwenden möchten.

Voraussetzungen

Lokales Gateway mit IOS XE 17.3.2 oder höher

  1. Diagnosesignaturen sind standardmäßig aktiviert.

  2. Konfigurieren Sie den sicheren E-Mail-Server, der zum Senden proaktiver Benachrichtigungen verwendet werden soll, wenn auf dem Gerät IOS XE 17.3.2 oder höher ausgeführt wird.

    
    LocalGateway#configure terminal 
    LocalGateway(config)#call-home  
    LocalGateway(cfg-call-home)#mail-server <username>:<pwd>@<email server> priority 1 secure tls 
    LocalGateway(config)#end 
  3. Konfigurieren Sie die Umgebungsvariable ds_email mit der E-Mail-Adresse des Administrators, die benachrichtigt werden soll.

    
    LocalGateway#configure terminal 
    LoclGateway(config)#call-home  
    LocalGateway(cfg-call-home)#diagnostic-signature 
    LocalGateway(cfg-call-home-diag-sign)environment ds_email <email address> 
    LocalGateway(config)#end 

Lokales Gateway mit IOS XE 16.11.1 oder höher

  1. Diagnosesignaturen sind standardmäßig aktiviert.

  2. Konfigurieren Sie den E-Mail-Server, der verwendet werden soll, um proaktive Benachrichtigungen zu senden, wenn auf dem Gerät eine Version vor 17.3.2 ausgeführt wird.

    
    LocalGateway#configure terminal 
    LocalGateway(config)#call-home  
    LocalGateway(cfg-call-home)#mail-server  <email server> priority 1 
    LocalGateway(config)#end 
    
  3. Konfigurieren Sie die Umgebungsvariable ds_email mit der E-Mail-Adresse des Administrators, die benachrichtigt werden soll.

    
    LocalGateway#configure terminal 
    LoclGateway(config)#call-home  
    LocalGateway(cfg-call-home)#diagnostic-signature 
    LocalGateway(cfg-call-home-diag-sign)environment ds_email <email address> 
    LocalGateway(config)#end 
    

Lokales Gateway mit Version 16.9.x

  1. Geben Sie die folgenden Befehle ein, um Diagnosesignaturen zu aktivieren.

    
    LocalGateway#configure terminal 
    LocalGateway(config)#call-home reporting contact-email-addr sch-smart-licensing@cisco.com  
    LocalGateway(config)#end  
  2. Konfigurieren Sie den E-Mail-Server, der verwendet werden soll, um proaktive Benachrichtigungen zu senden, wenn auf dem Gerät eine Version vor 17.3.2 ausgeführt wird.

    
    LocalGateway#configure terminal 
    LocalGateway(config)#call-home  
    LocalGateway(cfg-call-home)#mail-server  <email server> priority 1 
    LocalGateway(config)#end 
  3. Konfigurieren Sie die Umgebungsvariable ds_email mit der E-Mail-Adresse des Administrators, die benachrichtigt werden soll.

    
    LocalGateway#configure terminal 
    LoclGateway(config)#call-home  
    LocalGateway(cfg-call-home)#diagnostic-signature 
    LocalGateway(cfg-call-home-diag-sign)environment ds_email <email address> 
    LocalGateway(config)#end 

Die folgende Beispielkonfiguration zeigt ein lokales Gateway mit IOS XE 17.3.2, um proaktive Benachrichtigungen an tacfaststart@gmail.com zu senden, wobei Gmail als sicherer SMTP-Server verwendet wird:


call-home
mail-server tacfaststart:password@smtp.gmail.com priority 1 secure tls
diagnostic-signature
environment ds_email "tacfaststart@gmail.com"

Ein lokales Gateway, auf dem 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. Gehen Sie zu Google-Konto verwalten > Sicherheit, und aktivieren Sie die Einstellung Zugriff durch weniger sichere Apps.

  2. Antworten Sie „Yes, it was me“ (Ja, das war ich), wenn Sie eine E-Mail von Gmail mit dem Hinweis „Google prevented someone from signing in to your account using a non-Google app“ (Google hat verhindert, dass sich jemand mit einer Nicht-Google-App bei Ihrem Konto anmelden kann) erhalten.

Installieren von Diagnosesignaturen für eine proaktive Überwachung

Überwachen einer hohen CPU-Auslastung

Diese DS verfolgt 5 Sekunden lang die CPU-Auslastung unter Verwendung der SNMP-OID 1.3.6.1.4.1.9.2.1.56. Wenn die Auslastung 75 % oder mehr beträgt, werden alle Debugs deaktiviert und alle Diagnosesignaturen, die auf dem lokalen Gateway installiert sind, werden deinstalliert. Führen Sie die folgenden Schritte aus, um die Signatur zu installieren.

  1. Stellen Sie mit dem Befehl show snmp sicher, dass SNMP aktiviert ist. Wenn es nicht aktiviert ist, konfigurieren Sie den Befehl „snmp-server manager“.

    
    LocalGateway# show snmp 
    %SNMP agent not enabled 
    LocalGateway# 
    
    LocalGateway# 
    LocalGateway# config t 
    LocalGateway(config)# snmp-server manager 
    LocalGateway(config)#end 
    LocalGateway# 
    
    LocalGateway# 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 
    .... 
    .... 
    LocalGateway# 
  2. Laden Sie DS 64224 mit den folgenden Drop-down-Optionen im Diagnostic Signatures Lookup Tool herunter:

    
    LocalGateway# copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:

    Feldname

    Feldwert

    Plattform

    Cisco 4300, 4400 ISR-Serie oder Cisco CSR 1000V-Serie

    Produkt

    CUBE Enterprise in Webex Calling-Lösung

    Problemumfang

    Leistung

    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:

    Die folgende Abbildung zeigt ein Beispiel, wie die Datei von einem FTP-Server auf das lokale Gateway kopiert wird.

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

    
    LocalGateway# call-home diagnostic-signature load DS_64224.xml 
    Load file DS_64224.xml success 
    LocalGateway# 
  5. Vergewissern Sie sich mit show call-home diagnostic-signature, dass die Signatur erfolgreich installiert wurde. Die Statusspalte sollte einen Wert „registriert“ haben.

    
    LocalGateway# 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

    LocalGateway#


    Wenn ausgelöst, deinstalliert diese Signatur alle laufenden Diagnosesignaturen, einschließlich sich selbst. Installieren Sie DS 64224 ggf. erneut, um das lokale Gateway weiter auf eine hohe CPU-Auslastung zu überwachen.

Überwachen der Registrierung des SIP-Übertragungswegs

Diese Diagnosesignatur prüft alle 60 Sekunden in einer Cisco Webex Calling-Cloud ob der SIP-Übertragungsweg für ein lokales Gateway deregistriert wurde. Nachdem das Deregistrierungsevent erkannt wurde, generiert sie eine E-Mail- und eine Syslog-Benachrichtigung, und nach zwei Deregistrierungsevents deinstalliert sie sich selbst. Gehen Sie wie folgt vor, um die Signatur zu installieren.

  1. Laden Sie DS 64117 mit den folgenden Drop-down-Optionen im Diagnostic Signatures Lookup Tool herunter:

    Feldname

    Feldwert

    Plattform

    Cisco 4300, 4400 ISR-Serie oder Cisco CSR 1000V-Serie

    Produkt

    CUBE Enterprise in Webex Calling-Lösung

    Problemumfang

    SIP-SIP

    Problemtyp

    Deregistrierung des SIP-Übertragungswegs mit E-Mail-Benachrichtigung

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

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

    
    LocalGateway# call-home diagnostic-signature load DS_64117.xml 
    Load file DS_64117.xml success 
    LocalGateway#  
  4. Vergewissern Sie sich mit show call-home diagnostic-signature, dass die Signatur erfolgreich installiert wurde. Die Statusspalte sollte einen Wert „registriert“ haben.

Überwachen abnormaler Anrufunterbrechungen

Diese Diagnosesignatur nutzt alle 10 Minuten SNMP-Umfragen, um eine abnormale Anrufunterbrechung mit den SIP-Fehlern 403, 488 und 503 zu erkennen.  Wenn die Anzahl der Fehler ausgehend von der letzten Umfrage um 5 oder mehr gestiegen ist, werden eine Syslog- und eine E-Mail-Benachrichtigung generiert. Gehen Sie wie folgt vor, um die Signatur zu installieren.

  1. Prüfen Sie mit dem Befehl show snmp, ob SNMP aktiviert ist. Wenn es nicht aktiviert ist, konfigurieren Sie den Befehl „snmp-server manager“.

    
    LocalGateway# show snmp 
    %SNMP agent not enabled 
    LocalGateway# 
    
    LocalGateway# 
    LocalGateway# config t 
    LocalGateway(config)# snmp-server manager 
    LocalGateway(config)#end 
    LocalGateway# 
    
    LocalGateway# 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 
    .... 
    .... 
    LocalGateway# 
  2. Laden Sie DS 65221 mit den folgenden Optionen im Diagnostic Signatures Lookup Tool herunter:

    Feldname

    Feldwert

    Plattform

    Cisco 4300, 4400 ISR-Serie oder Cisco CSR 1000V-Serie

    Produkt

    CUBE Enterprise in Webex Calling-Lösung

    Problemumfang

    Leistung

    Problemtyp

    Erkennung einer abnormalen SIP-Anrufunterbrechung mit E-Mail- und Syslog-Benachrichtigung

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

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

    
    LocalGateway# call-home diagnostic-signature load DS_65221.xml 
    Load file DS_65221.xml success 
    LocalGateway# 
  5. Vergewissern Sie sich mit show call-home diagnostic-signature, dass die Signatur erfolgreich installiert wurde. Die Statusspalte sollte einen Wert „registriert“ haben.

Installieren von Diagnosesignaturen zur Fehlerbehebung

Diagnosesignaturen (DS) können auch zum schnellen Beheben von Problemen verwendet werden. Die Cisco TAC-Techniker haben mehrere Signaturen erstellt, die die erforderlichen Debugs ermöglichen, um ein bestimmtes Problem zu beheben, das Auftreten eines Problems 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 das Diagnostic Signatures Lookup Tool verwenden, um die entsprechenden Signaturen zu suchen und zu installieren, um ein bestimmtes Problem selbst zu lösen, oder Sie können die vom TAC-Techniker empfohlene Signatur im Rahmen der Support-Beteiligung installieren.

Hier ein Beispiel für die Suche und Installation eines DS zum Erkennen des Eintretens "%VOICE_IEC-3-GW: CCAPI: Interner Fehler (Schwellenwert für Anrufspitze): IEC=1.1.181.1.29.0“ zu erkennen und die Diagnosedatensammlung zu automatisieren.

  1. Konfigurieren Sie eine zusätzliche DS-Umgebungsvariable, der CiscoTAC-Dateiserverpfad (cxd.cisco.com), zu dem die ds_fsurl_prefix erfassten Diagnosedaten hochgeladen werden. Der Benutzername im Dateipfad ist die Fallnummer, und das Passwort ist das Datei-Upload-Token, das wie unten gezeigt vom Support Case Manager abgerufen werden kann. Das Datei-Upload-Token kann nach Bedarf im Bereich Anhänge des Support Case Manager generiert werden.

    
    LocalGateway#configure terminal 
    LocalGateway(config)#call-home  
    LocalGateway(cfg-call-home)#diagnostic-signature 
    LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com"  
    LocalGateway(config)#end 

    Beispiel:

    
    call-home  
    diagnostic-signature 
    environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"  
  2. Stellen Sie mit dem Befehl show snmp sicher, dass SNMP aktiviert ist. Wenn es nicht aktiviert ist, konfigurieren Sie den Befehl „snmp-server manager“.

    
    LocalGateway# show snmp 
    %SNMP agent not enabled 
    LocalGateway# 
     
    LocalGateway# 
    LocalGateway# config t 
    LocalGateway(config)# snmp-server manager 
    LocalGateway(config)#end 
    LocalGateway# 
  3. Es wird empfohlen, die DS 64224 zur Überwachung einer hohen CPU-Auslastung als proaktive Maßnahme zu installieren, um alle Debugs und Diagnosesignaturen bei einer hohen CPU-Auslastung zu deaktivieren. Laden Sie DS 64224 mit den folgenden Optionen im Diagnostic Signatures Lookup Tool herunter:

    Feldname

    Feldwert

    Plattform

    Cisco 4300, 4400 ISR-Serie oder Cisco CSR 1000V-Serie

    Produkt

    CUBE Enterprise in Webex Calling-Lösung

    Problemumfang

    Leistung

    Problemtyp

    Hohe CPU-Auslastung mit E-Mail-Benachrichtigung

  4. Laden Sie DS 65095 mit den folgenden Optionen im Diagnostic Signatures Lookup Tool herunter:

    Feldname

    Feldwert

    Plattform

    Cisco 4300, 4400 ISR-Serie oder Cisco CSR 1000V-Serie

    Produkt

    CUBE Enterprise in Webex Calling-Lösung

    Problemumfang

    Syslogs

    Problemtyp

    Syslog - %VOICE_IEC-3-GW: CCAPI: Interner Fehler (Schwellenwert für Anrufspitze): IEC=1.1.181.1.29.0

  5. Kopieren Sie die DS-XML-Dateien auf das lokale Gateway.

    
    LocalGateway# copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash: 
    LocalGateway# copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash: 
  6. Installieren Sie zunächst DS 64224 zur Überwachung einer hohen CPU-Auslastung und dann die XML-Datei „DS 65095“ auf dem lokalen Gateway.

    
    LocalGateway# call-home diagnostic-signature load DS_64224.xml 
    Load file DS_64224.xml success 
    LocalGateway# 
    LocalGateway# call-home diagnostic-signature load DS_65095.xml 
    Load file DS_65095.xml success 
    LocalGateway# 
  7. Vergewissern Sie sich mit show call-home diagnostic-signature, dass die Signatur erfolgreich installiert wurde. Die Statusspalte sollte einen Wert „registriert“ haben.

    
    LocalGateway# 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

    08.11.2020:00:07:45

    65095

    00:12:53

    DS_LGW_LGW LG_Call_spike_threshold

    0.0.12

    Registriert

    08.11.2020:00:12:53

    LocalGateway#

Überprüfen der Ausführung von Diagnosesignaturen

Wie unten gezeigt, ändert sich die Spalte „Status“ des Befehls show call-home diagnostic-signature in „Wird ausgeführt“ (running), während das lokale Gateway die in der Signatur definierte Aktion ausführt. Die Ausgabe von show call-home diagnostic-signature statistics ist die beste Möglichkeit, um zu prüfen, ob eine Diagnosesignatur ein relevantes Event erkannt und die Aktion ausgeführt hat. Die Spalte „Ausgelöst/Max/Deinstalliert“ gibt Folgendes an: Anzahl der Fälle, für die die Signatur ein Event ausgelöst hat; die maximale Anzahl ausgelöster Events, die erkannt werden soll; und ob die Signatur sich automatisch deinstalliert, nachdem die maximale Anzahl ausgelöster Events erkannt wurde.


LocalGateway# 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

08.11.2020 00:07:45

65095

DS_LGW_LGW LG_Call_spike_threshold

0.0.12

Wird ausgeführt

08.11.2020 00:12:53

LocalGateway#

LocalGateway# show call-home diagnostic-signature statistics

DS-ID

DS-Name

Ausgelöst/Max/Deinstalliert

Durchschnittliche Ausführungszeit (Sekunden)

Max. Ausführungszeit (Sekunden)

64224

DS_LGW_CPU_MON75

0/0/N

0,000

0,000

65095

DS_LGW_LGW LG_Call_spike_threshold

1/20/Y

23,053

23,053

LocalGateway#

Die Benachrichtigungs-E-Mail, die beim Ausführen der Diagnosesignatur gesendet wird, enthält wichtige Informationen wie Problemtyp, Gerätedetails, Softwareversion, ausgeführte Konfiguration und Ausgaben des show-Befehls, die für die Behebung des jeweiligen Problems relevant sind.

Deinstallieren von Diagnosesignaturen

Zur Fehlerbehebung verwendete Diagnosesignaturen sind in der Regel so definiert, dass sie sich nach der Erkennung einer bestimmten Anzahl von Problemvorfällen deinstallieren. Wenn Sie eine Signatur manuell deinstallieren möchten, rufen Sie die DS-ID von der Ausgabe des Befehls show call-home diagnostic-signature ab und führen den unten angegebenen Befehl aus.


LocalGateway# call-home diagnostic-signature deinstall <DS ID> 
LocalGateway# 

Beispiel:


LocalGateway# call-home diagnostic-signature deinstall 64224 
LocalGateway# 

Dem Diagnostics Signatures Lookup Tool werden regelmäßig neue Signaturen auf der Grundlage von Problemen hinzugefügt, die häufig in Bereitstellungen beobachtet werden. TAC unterstützt derzeit keine Anfragen zur Erstellung neuer benutzerdefinierter Signaturen.