Configurazione del gateway locale su Cisco IOS XE per Webex Calling
Dopo aver configurato Webex Calling per la propria organizzazione, è possibile configurare un trunk per la connessione del gateway locale Webex Calling. Il trasporto SIP TLS protegge il trunk tra il gateway locale e il cloud Webex. Il contenuto multimediale tra il gateway locale e Webex Calling utilizza SRTP.
Panoramica
Webex Calling supporta attualmente due versioni di Local Gateway:
-
Gateway locale
-
Gateway locale per Webex per la Pubblica Amministrazione
-
Prima di iniziare, è necessario comprendere i requisiti della rete telefonica pubblica commutata (PSTN) e del gateway locale (LGW) per Webex Calling. Per ulteriori informazioni, vedere Architettura preferita Cisco Webex Calling per ulteriori informazioni.
-
Questo articolo presuppone che una piattaforma di gateway locale dedicata sia disponibile senza configurazione vocale esistente. Se si modifica un gateway PSTN esistente o una distribuzione CUBE Enterprise per utilizzarla come funzione di gateway locale per Webex Calling, prestare molta attenzione alla configurazione. Assicuratevi di non interrompere i flussi di chiamate e le funzionalità esistenti a causa delle modifiche apportate.
Le procedure contengono collegamenti alla documentazione di riferimento dei comandi, dove è possibile ottenere maggiori informazioni sulle singole opzioni dei comandi. Tutti i collegamenti di riferimento ai comandi vanno a Riferimento ai comandi di Webex Managed Gateways a meno che non sia specificato diversamente (in tal caso, i collegamenti ai comandi vanno a Riferimento ai comandi vocali Cisco IOS). È possibile accedere a tutte queste guide in Cisco Unified Border Element Riferimenti ai comandi.
Per informazioni sugli SBC di terze parti supportati, fare riferimento alla documentazione di riferimento del rispettivo prodotto.
Esistono due opzioni per configurare il gateway locale per il Webex Calling trunk:
-
Trunk basato sulla registrazione
-
Trunk basato su certificato
Utilizzare il flusso di attività in Gateway locale basato sulla registrazione o Gateway locale basato sul certificato per configurare il gateway locale per il trunk Webex Calling.
Per ulteriori informazioni sui diversi tipi di trunk, vedere Introduzione al gateway locale. Effettuare le seguenti operazioni sul gateway locale, utilizzando l'interfaccia della riga di comando (CLI). Utilizziamo il trasporto Session Initiation Protocol (SIP) e Transport Layer Security (TLS) per proteggere il trunk e il Secure Real Time Protocol (SRTP) per proteggere i contenuti multimediali tra il gateway locale e Webex Calling.
-
Seleziona CUBE come gateway locale. Webex for Government al momento non supporta alcun Session Border Controller (SBC) di terze parti. Per rivedere l'elenco più recente, vedere Introduzione al gateway locale.
- Installare Cisco IOS XE Dublin 17.12.1a o versioni successive per tutti i gateway locali Webex for Government.
-
Per rivedere l'elenco delle autorità di certificazione (CA) radice supportate da Webex for Government, vedere Autorità di certificazione radice per Webex for Government.
-
Per informazioni dettagliate sugli intervalli di porte esterne per il gateway locale in Webex for Government, vedere Requisiti di rete per Webex for Government (FedRAMP).
Il gateway locale per Webex for Government non supporta quanto segue:
-
STUN/ICE-Lite per l'ottimizzazione del percorso multimediale
-
Fax (T.38)
Per configurare il gateway locale per il trunk Webex Calling in Webex for Government, utilizzare la seguente opzione:
-
Trunk basato su certificato
Utilizzare il flusso di lavoro in Gateway locale basato su certificato per configurare il gateway locale per il trunk Webex Calling. Per maggiori dettagli su come configurare un gateway locale basato su certificato, vedere Configurare il trunk basato su certificato di Webex Calling.
È obbligatorio configurare i cifrari GCM conformi allo standard FIPS per supportare il gateway locale per Webex for Government. In caso contrario, la configurazione della chiamata fallisce. Per i dettagli sulla configurazione, vedere Configurare il trunk basato su certificato Webex Calling.
Webex for Government non supporta il gateway locale basato sulla registrazione.
In questa sezione viene descritto come configurare un Cisco Unified Border Element (CUBE) come gateway locale per Webex Calling, utilizzando un trunk SIP di registrazione. La prima parte di questo documento illustra come configurare un semplice gateway PSTN. In questo caso, tutte le chiamate dalla PSTN vengono instradate a Webex Calling e tutte le chiamate da Webex Calling vengono instradate alla PSTN. L'immagine sottostante evidenzia questa soluzione e la configurazione di routing delle chiamate di alto livello che verrà seguita.
In questo progetto vengono utilizzate le seguenti configurazioni principali:
-
inquilini della classe vocale: Utilizzato per creare configurazioni specifiche del trunk.
-
classe vocale uri: Utilizzato per classificare i messaggi SIP per la selezione di un dial-peer in ingresso.
-
dial-peer in entrata: Fornisce il trattamento per i messaggi SIP in entrata e determina il percorso in uscita utilizzando un gruppo dial-peer.
-
gruppo dial-peer: Definisce i dial-peer in uscita utilizzati per l'inoltro delle chiamate.
-
dial-peer in uscita: Fornisce il trattamento dei messaggi SIP in uscita e li indirizza alla destinazione richiesta.

Sebbene IP e SIP siano diventati i protocolli predefiniti per i trunk PSTN, i circuiti ISDN TDM (Time Division Multiplexing) sono ancora ampiamente utilizzati e supportati con i trunk Webex Calling. Per abilitare l'ottimizzazione dei media dei percorsi IP per i gateway locali con flussi di chiamate TDM-IP, è attualmente necessario utilizzare un processo di routing delle chiamate a due fasi. Questo approccio modifica la configurazione di routing delle chiamate mostrata sopra, introducendo un set di dial-peer loop-back interni tra Webex Calling e i trunk PSTN, come illustrato nell'immagine seguente.

Quando si collega una soluzione Cisco Unified Communications Manager locale con Webex Calling, è possibile utilizzare la semplice configurazione del gateway PSTN come base per creare la soluzione illustrata nel diagramma seguente. In questo caso, Unified Communications Manager fornisce il routing e la gestione centralizzati di tutte le chiamate PSTN e Webex Calling.

In questo documento vengono utilizzati i nomi host, gli indirizzi IP e le interfacce illustrati nell'immagine seguente.

Per completare la configurazione del gateway locale, utilizzare le istruzioni di configurazione riportate nel resto del documento come segue:
-
Passaggio 1: Configurare la connettività di base e la sicurezza del router
-
Passo 2: Configurare il trunk Webex Calling
A seconda dell'architettura richiesta, seguire una delle seguenti procedure:
-
Passaggio 3: Configurare il gateway locale con trunk PSTN SIP
-
Passaggio 4: Configurazione del gateway locale con un ambiente Unified CM esistente
Oppure:
-
Passaggio 3: Configurare il gateway locale con trunk PSTN TDM
Configurazione di base
Il primo passo per preparare il router Cisco come gateway locale per Webex Calling è creare una configurazione di base che protegga la piattaforma e stabilisca la connettività.
-
Tutte le distribuzioni di Local Gateway basate sulla registrazione richiedono Cisco IOS XE 17.6.1a o versioni successive. Si consiglia Cisco IOS 17.12.2 o versione successiva. Per le versioni consigliate, vedere la pagina Cisco Software Research. Cerca la piattaforma e seleziona una delle versioni suggerite.
-
I router della serie ISR4000 devono essere configurati con entrambe le licenze per la tecnologia Unified Communications e Security.
-
I router Catalyst Edge serie 8000 dotati di schede vocali o DSP richiedono la licenza DNA Advantage. I router senza schede vocali o DSP necessitano almeno della licenza DNA Essentials.
-
-
Crea una configurazione di base per la tua piattaforma che rispetti le tue policy aziendali. In particolare, configurare e verificare quanto segue:
-
Ntp
-
Acl
-
Autenticazione utente e accesso remoto
-
DNS
-
Indirizzamento IP
-
indirizzi IP
-
-
La rete verso Webex Calling deve utilizzare un indirizzo IPv4.
-
Caricare il bundle CA radice Cisco sul gateway locale.
Configurazione
1 |
Assicurarsi di assegnare indirizzi IP validi e instradabili a tutte le interfacce di Livello 3, ad esempio:
|
2 |
Proteggere la registrazione e le credenziali STUN sul router utilizzando la crittografia simmetrica. Configurare la chiave di crittografia primaria e il tipo di crittografia come segue:
|
3 |
Creare un trustpoint PKI segnaposto. Richiede questo trustpoint per configurare TLS in un secondo momento. Per i trunk basati sulla registrazione, questo trustpoint non richiede un certificato, come invece è richiesto per un trunk basato su certificato. |
4 |
Abilitare l'esclusività TLS1.2 e specificare il trustpoint predefinito utilizzando i seguenti comandi di configurazione. Aggiorna i parametri di trasporto per garantire una connessione sicura e affidabile per la registrazione: Il comando
|
5 |
Installare il bundle Cisco Root CA, che include il certificato IdenTrust Commercial Root CA1 utilizzato da Webex Calling. Utilizzare il comando crypto pki trustpool import clean url per scaricare il bundle CA radice dall'URL specificato e per cancellare l'attuale trustpool CA, quindi installare il nuovo bundle di certificati: Se è necessario utilizzare un proxy per l'accesso a Internet tramite HTTPS, aggiungere la seguente configurazione prima di importare il bundle CA: ip http client proxy-server yourproxy.com porta proxy 80 |
1 |
Creare un trunk PSTN basato sulla registrazione per una posizione esistente nel Control Hub. Prendi nota delle informazioni sul trunk fornite una volta creato il trunk. I dettagli evidenziati nell'illustrazione vengono utilizzati nei passaggi di configurazione descritti in questa guida. Per ulteriori informazioni, vedere Configurare trunk, gruppi di routing e piani di chiamata per Webex Calling. ![]() |
2 |
Immettere i seguenti comandi per configurare CUBE come gateway locale di Webex Calling: Di seguito una spiegazione dei campi per la configurazione:
Abilita le funzionalità Cisco Unified Border Element (CUBE) sulla piattaforma. statistiche sui mediaAbilita il monitoraggio multimediale sul gateway locale. statistiche di massa sui mediaConsente al controllo di controllare il sondaggio dei dati per le statistiche sulle chiamate in massa. Per ulteriori informazioni su questi comandi, vedere Media. consenti-connessioni sip a SIPAbilita la funzionalità di agente utente back-to-back SIP di base di CUBE. Per ulteriori informazioni, vedere Consenti connessioni. Per impostazione predefinita, il trasporto fax T.38 è abilitato. Per ulteriori informazioni, vedere protocollo fax t38 (servizio vocale). Abilita STUN (Session Traversal of UDP through NAT) a livello globale.
Per ulteriori informazioni, vedere stun flowdata agent-id e stun flowdata shared-secret. carico utile asimmetrico completoConfigura il supporto del payload asimmetrico SIP per i payload DTMF e codec dinamici. Per ulteriori informazioni, vedere carico utile asimmetrico. offerta anticipata forzataForza il gateway locale a inviare informazioni SDP nel messaggio INVITE iniziale anziché attendere la conferma dal peer vicino. Per maggiori informazioni su questo comando, vedere early-offer. |
3 |
Configurare codec di classe vocale 100 consentendo solo i codec G.711 per tutti i trunk. Questo semplice approccio è adatto alla maggior parte delle distribuzioni. Se necessario, è possibile aggiungere all'elenco altri tipi di codec supportati sia dal sistema di origine che da quello di destinazione. Sono supportate soluzioni più complesse che coinvolgono la transcodificamediante moduli DSP, ma non sono incluse in questa guida. |
4 |
Configurare classe vocale stun-usage 100 per abilitare ICE sul trunk Webex Calling. Di seguito una spiegazione dei campi per la configurazione: utilizzo stordimento ghiaccio leggeroUtilizzato per abilitare ICE-Lite per tutti i dial-peer che utilizzano Webex Calling per consentire l'ottimizzazione dei contenuti multimediali ove possibile. Per maggiori informazioni, vedere utilizzo della classe vocale stordimento e utilizzo della classe vocale stordimento ghiaccio lite. L'ottimizzazione dei media viene negoziata ove possibile. Se una chiamata richiede servizi multimediali cloud, come la registrazione, i contenuti multimediali non possono essere ottimizzati. |
5 |
Configurare i criteri di crittografia multimediale per il traffico Webex. Di seguito una spiegazione dei campi per la configurazione: classe vocale srtp-crypto 100Specifica SHA1_80 come unica suite di cifratura SRTP offerta da CUBE nell'SDP nei messaggi di offerta e risposta. Webex Calling supporta solo SHA1_80. Per ulteriori informazioni, vedere voice class srtp-crypto. |
6 |
Configurare un modello per identificare le chiamate a un trunk del gateway locale in base al parametro trunk di destinazione: Di seguito una spiegazione dei campi per la configurazione: corso di canto uri 100 sipDefinisce un modello per abbinare un invito SIP in arrivo a un dial-peer trunk in arrivo. Quando si inserisce questo modello, utilizzare dtg= seguito da Trunk OTG/DTG valore fornito nel Control Hub al momento della creazione del trunk. Per ulteriori informazioni, vedere classe vocale uri. |
7 |
Configurare il profilo SIP 100, che verrà utilizzato per modificare i messaggi SIP prima che vengano inviati a Webex Calling.
Di seguito una spiegazione dei campi per la configurazione:
Il provider PSTN degli Stati Uniti o del Canada può offrire la verifica dell'ID chiamante per chiamate spam e fraudolente, con la configurazione aggiuntiva menzionata nell'articolo Indicazione di chiamate spam o fraudolente in Webex Calling. |
8 |
Configurare il trunk Webex Calling: |
Dopo aver definito il tenant 100 e configurato un dial-peer VoIP SIP, il gateway avvia una connessione TLS verso Webex Calling. A questo punto, l'SBC di accesso presenta il suo certificato al gateway locale. Il gateway locale convalida il certificato SBC di accesso a Webex Calling utilizzando il bundle radice CA aggiornato in precedenza. Se il certificato viene riconosciuto, viene stabilita una sessione TLS persistente tra il gateway locale e l'SBC di accesso Webex Calling. Il gateway locale è quindi in grado di utilizzare questa connessione sicura per registrarsi con l'SBC di accesso Webex. Quando la registrazione viene contestata per autenticazione:
-
Nella risposta vengono utilizzati i parametri username, passworde realm dalla configurazione credentials.
-
Le regole di modifica nel profilo SIP 100 vengono utilizzate per convertire nuovamente l'URL SIPS in SIP.
La registrazione è avvenuta con successo quando si è ricevuto un 200 OK dall'SBC di accesso.
Dopo aver creato un trunk verso Webex Calling come descritto sopra, utilizzare la seguente configurazione per creare un trunk non crittografato verso un provider PSTN basato su SIP:
Se il tuo fornitore di servizi offre un trunk PSTN sicuro, puoi seguire una configurazione simile a quella descritta in precedenza per il trunk Webex Calling. CUBE supporta l'instradamento sicuro delle chiamate.
Se si utilizza un TDM / Tronco PSTN ISDN, passare alla sezione successiva Configurare il gateway locale con tronco PSTN TDM.
Per configurare le interfacce TDM per le linee di chiamata PSTN sui gateway Cisco TDM-SIP, vedere Configurazione ISDN PRI.
1 |
Configurare il seguente URI di classe vocale per identificare le chiamate in arrivo dal trunk PSTN: Di seguito una spiegazione dei campi per la configurazione: corso di canto uri 200 sipDefinisce un modello per abbinare un invito SIP in arrivo a un dial-peer trunk in arrivo. Quando si immette questo schema, utilizzare l'indirizzo IP del gateway IP PSTN. Per ulteriori informazioni, vedere classe vocale uri. |
2 |
Configurare il seguente dial-peer IP PSTN: Di seguito una spiegazione dei campi per la configurazione: Definisce un dial-peer VoIP con un tag di 200 e fornisce una descrizione significativa per facilitare la gestione e la risoluzione dei problemi. Per ulteriori informazioni, vedere dial-peer voice. modello-destinazione BAD.BADQuando si instradano chiamate in uscita utilizzando un gruppo di peer di chiamata in entrata, è necessario un modello di destinazione fittizio. In questo caso è possibile utilizzare qualsiasi modello di destinazione valido. Per ulteriori informazioni, vedere destination-pattern (interfaccia). protocollo sessione sipv2Specifica che questo dial-peer gestisce le tratte delle chiamate SIP. Per ulteriori informazioni, vedere protocollo di sessione (dial peer). destinazione sessione ipv4: 192.168.80.13Specifica l'indirizzo di destinazione per le chiamate inviate al provider PSTN. Potrebbe trattarsi di un indirizzo IP o di un nome host DNS. Per ulteriori informazioni, vedere destinazione della sessione (peer di selezione VoIP). uri in arrivo tramite 200Specifica la classe vocale utilizzata per abbinare le chiamate in arrivo a questo dial-peer utilizzando l'URI dell'intestazione INVITE VIA. Per ulteriori informazioni, vedere URL in arrivo. classe vocale sip id asserito pai
(Facoltativo) Attiva l'elaborazione dell'intestazione P-Asserted-Identity e controlla come questa viene utilizzata per il trunk PSTN. Se si utilizza questo comando, per le intestazioni From e P-Asserted-Identity in uscita viene utilizzata l'identità della parte chiamante fornita dal dial-peer in entrata. Se questo comando non viene utilizzato, per le intestazioni From e Remote-Party-ID in uscita viene utilizzata l'identità della parte chiamante fornita dal dial-peer in entrata. Per ulteriori informazioni, vedere voice-class sip asserted-id. controllo di associazione interfaccia sorgente GigabitEthernet0/0/0
Configura l'interfaccia sorgente e l'indirizzo IP associato per i messaggi inviati alla PSTN. Per ulteriori informazioni, vedere bind. associa l'interfaccia sorgente multimediale GigabitEthernet0/0/0Configura l'interfaccia sorgente e l'indirizzo IP associato per i contenuti multimediali inviati alla PSTN. Per ulteriori informazioni, vedere bind. codec di classe vocale 100Configura il dial-peer per utilizzare l'elenco dei filtri codec comuni 100. Per ulteriori informazioni, vedere voice-class codec. dtmf-relay rtp-nteDefinisce RTP-NTE (RFC2833) come funzionalità DTMF prevista sul modello della chiamata. Per ulteriori informazioni, vedere DTMF Relay (Voice over IP). nessun vadDisabilita il rilevamento dell'attività vocale. Per ulteriori informazioni, vedere vad (dial peer). |
3 |
Se si sta configurando il gateway locale per instradare solo le chiamate tra Webex Calling e la rete PSTN, aggiungere la seguente configurazione di instradamento delle chiamate. Se stai configurando il tuo gateway locale con una piattaforma Unified Communications Manager, passa alla sezione successiva. |
Dopo aver creato un trunk verso Webex Calling, utilizzare la seguente configurazione per creare un trunk TDM per il servizio PSTN con routing delle chiamate loop-back per consentire l'ottimizzazione dei contenuti multimediali sul segmento di chiamata Webex.
Se non è richiesta l'ottimizzazione dei media IP, seguire i passaggi di configurazione per un trunk PSTN SIP. Utilizzare una porta vocale e un dial-peer POTS (come mostrato nei passaggi 2 e 3) anziché il dial-peer VoIP PSTN.
1 |
La configurazione loop-back dial-peer utilizza gruppi dial-peer e tag di routing delle chiamate per garantire che le chiamate vengano trasmesse correttamente tra Webex e la PSTN, senza creare loop di routing delle chiamate. Configurare le seguenti regole di traduzione che verranno utilizzate per aggiungere e rimuovere i tag di instradamento delle chiamate: Di seguito una spiegazione dei campi per la configurazione: regola della traduzione vocaleUtilizza espressioni regolari definite nelle regole per aggiungere o rimuovere tag di instradamento delle chiamate. Le cifre ultradecadiche ('A') vengono utilizzate per aumentare la chiarezza nella risoluzione dei problemi. In questa configurazione, il tag aggiunto da translation-profile 100 viene utilizzato per guidare le chiamate da Webex Calling verso la PSTN tramite i dial-peer loopback. Allo stesso modo, il tag aggiunto da translation-profile 200 viene utilizzato per indirizzare le chiamate dalla PSTN verso Webex Calling. I profili di traduzione 11 e 12 rimuovono questi tag prima di inoltrare le chiamate rispettivamente ai trunk Webex e PSTN. Questo esempio presuppone che i numeri chiamati da Webex Calling siano presentati in +E.164 formato. La regola 100 rimuove il leader + per mantenere un numero chiamato valido. La regola 12 aggiunge quindi una o più cifre di routing nazionale o internazionale quando si rimuove l'etichetta. Utilizzare cifre compatibili con il piano tariffario nazionale ISDN locale. Se Webex Calling presenta i numeri in formato nazionale, modificare le regole 100 e 12 semplicemente aggiungendo e rimuovendo rispettivamente il tag di routing. Per ulteriori informazioni, vedere voice translation-profile e voice translation-rule. |
2 |
Configurare le porte dell'interfaccia vocale TDM in base al tipo di trunk e al protocollo utilizzato. Per ulteriori informazioni, vedere Configurazione ISDN PRI. Ad esempio, la configurazione di base di un'interfaccia Primary Rate ISDN installata nello slot NIM 2 di un dispositivo potrebbe includere quanto segue: |
3 |
Configurare il seguente dial-peer TDM PSTN: Di seguito una spiegazione dei campi per la configurazione: Definisce un dial-peer VoIP con un tag pari a 200 e fornisce una descrizione significativa per semplificare la gestione e la risoluzione dei problemi. Per ulteriori informazioni, vedere dial-peer voice. modello-destinazione BAD.BADQuando si instradano chiamate in uscita utilizzando un gruppo di peer di chiamata in entrata, è necessario un modello di destinazione fittizio. In questo caso è possibile utilizzare qualsiasi modello di destinazione valido. Per ulteriori informazioni, vedere destination-pattern (interfaccia). profilo di traduzione in arrivo 200Assegna il profilo di traduzione che aggiungerà un tag di instradamento delle chiamate al numero chiamato in entrata. selezione diretta internaInstrada la chiamata senza fornire un tono di selezione secondario. Per ulteriori informazioni, vedere direct-inward-dial. porta 0/2/0:15Porta vocale fisica associata a questo dial-peer. |
4 |
Per abilitare l'ottimizzazione multimediale dei percorsi IP per i gateway locali con flussi di chiamate TDM-IP, è possibile modificare l'instradamento delle chiamate introducendo un set di dial-peer loop-back interni tra Webex Calling e trunk PSTN. Configurare i seguenti dial-peer loop-back. In questo caso, tutte le chiamate in arrivo verranno inizialmente indirizzate al dial-peer 10 e da lì al dial-peer 11 o 12 in base al tag di routing applicato. Dopo la rimozione del tag di routing, le chiamate verranno instradate al trunk in uscita utilizzando gruppi dial-peer. Di seguito una spiegazione dei campi per la configurazione: Definisce un dial-peer VoIP e fornisce una descrizione significativa per semplificare la gestione e la risoluzione dei problemi. Per ulteriori informazioni, vedere dial-peer voice. profilo di traduzione in arrivo 11Applica il profilo di traduzione definito in precedenza per rimuovere il tag di instradamento delle chiamate prima di passare al trunk in uscita. modello-destinazione BAD.BADQuando si instradano chiamate in uscita utilizzando un gruppo di peer di chiamata in entrata, è necessario un modello di destinazione fittizio. Per ulteriori informazioni, vedere destination-pattern (interfaccia). protocollo sessione sipv2Specifica che questo dial-peer gestisce le tratte delle chiamate SIP. Per ulteriori informazioni, vedere protocollo di sessione (dial peer). destinazione sessione ipv4: 192.168.80.14Specifica l'indirizzo dell'interfaccia del router locale come destinazione della chiamata per il loop-back. Per ulteriori informazioni, vedere destinazione della sessione (peer di selezione VoIP). controllo di associazione interfaccia sorgente GigabitEthernet0/0/0Configura l'interfaccia sorgente e l'indirizzo IP associato per i messaggi inviati tramite loop-back. Per ulteriori informazioni, vedere bind. associa l'interfaccia sorgente multimediale GigabitEthernet0/0/0Configura l'interfaccia sorgente e l'indirizzo IP associato per i contenuti multimediali inviati tramite loop-back. Per ulteriori informazioni, vedere bind. dtmf-relay rtp-nteDefinisce RTP-NTE (RFC2833) come funzionalità DTMF prevista sul modello della chiamata. Per ulteriori informazioni, vedere DTMF Relay (Voice over IP). codec g711alaw Forza tutte le chiamate PSTN a utilizzare G.711. Selezionare a-law o u-law in base al metodo di compressione/compressione utilizzato dal servizio ISDN. nessun vadDisabilita il rilevamento dell'attività vocale. Per ulteriori informazioni, vedere vad (dial peer). |
5 |
Aggiungere la seguente configurazione di routing delle chiamate: La configurazione del gateway locale è terminata. Salvare la configurazione e ricaricare la piattaforma se questa è la prima volta che si configurano le funzionalità CUBE.
|
La configurazione PSTN-Webex Calling nelle sezioni precedenti può essere modificata per includere trunk aggiuntivi in un cluster Cisco Unified Communications Manager (UCM). In questo caso, tutte le chiamate vengono instradate tramite Unified CM. Le chiamate da UCM sulla porta 5060 vengono instradate alla PSTN, mentre le chiamate dalla porta 5065 vengono instradate a Webex Calling. Per includere questo scenario di chiamata, è possibile aggiungere le seguenti configurazioni incrementali.
Quando si crea il trunk Webex Calling in Unified CM, assicurarsi di configurare la porta in ingresso nelle impostazioni del profilo di sicurezza del trunk SIP su 5065. Ciò consente l'ingresso di messaggi sulla porta 5065 e popola l'intestazione VIA con questo valore quando si inviano messaggi al gateway locale.

1 |
Configura i seguenti URI di classe vocale: |
2 |
Configurare i seguenti record DNS per specificare il routing SRV agli host Unified CM: IOS XE utilizza questi record per determinare localmente gli host e le porte UCM di destinazione. Con questa configurazione non è necessario configurare i record nel sistema DNS. Se preferisci utilizzare il tuo DNS, queste configurazioni locali non sono necessarie. Di seguito una spiegazione dei campi per la configurazione: Il seguente comando crea un record di risorse DNS SRV. Crea un record per ogni host e trunk UCM: host IP _sip._udp.pstntocucm.io servizio 2 1 5060 ucmsub5.miodominio.com _sip._udp.pstntocucm.io: Nome del record di risorse SRV 2: Priorità del record di risorse SRV 1: Il peso del record delle risorse SRV 5060: Il numero di porta da utilizzare per l'host di destinazione in questo record di risorse ucmsub5.mydomain.com: L'host di destinazione del record di risorse Per risolvere i nomi host di destinazione dei record di risorse, creare record DNS A locali. Ad esempio: host IP ucmsub5.miodominio.com 192.168.80.65 host IP: Crea un record nel database IOS XE locale. ucmsub5.mydomain.com: Nome host del record A. 192.168.80.65: L'indirizzo IP dell'host. Crea i record delle risorse SRV e i record A per riflettere il tuo ambiente UCM e la strategia di distribuzione delle chiamate preferita. |
3 |
Configurare i seguenti dial-peer: |
4 |
Aggiungere l'instradamento delle chiamate utilizzando le seguenti configurazioni: |
Le firme diagnostiche (DS) individuano in modo proattivo i problemi comunemente osservati nel gateway locale basato su IOS XE e generano notifiche e-mail, registri di sistema o messaggi terminali dell'evento. È inoltre possibile installare DS per automatizzare la raccolta dei dati diagnostici e trasferire i dati raccolti al caso Cisco TAC per accelerare i tempi di risoluzione.
Le firme diagnostiche (DS) sono file XML contenenti informazioni su eventi e azioni da attivare per informare, risolvere e risolvere il problema. È possibile definire la logica di rilevamento dei problemi utilizzando messaggi syslog, eventi SNMP e tramite il monitoraggio periodico di output specifici del comando show.
I tipi di azione includono la raccolta degli output dei comandi visualizzati:
-
Generazione di un file di log consolidato
-
Caricamento del file su un percorso di rete fornito dall'utente, ad esempio un server HTTPS, SCP o FTP.
I tecnici TAC autorizzano i file DS e firmano in digitale i file per la protezione dell'integrità. A ogni file DS viene assegnato un ID numerico univoco dal sistema. Diagnostic Signatures Lookup Tool (DSLT) è un'unica fonte per trovare firme applicabili per il monitoraggio e la risoluzione di vari problemi.
Operazioni preliminari:
-
Non modificare il file DS scaricato da DSLT. L'installazione dei file da modificare non riesce a causa dell'errore di controllo dell'integrità.
-
Un server SMTP (Mail Transfer Protocol) semplice richiesto dal gateway locale per l'invio di notifiche e-mail.
-
Accertarsi che sul gateway locale sia in esecuzione IOS XE 17.6.1 o superiore se si desidera utilizzare il server SMTP sicuro per le notifiche e-mail.
Prerequisiti
Gateway locale con iOS XE 17.6.1a o versione successiva
-
Le firme diagnostiche sono abilitate per impostazione predefinita.
-
Configurare il server di posta elettronica sicuro da utilizzare per inviare notifiche proattive se il dispositivo esegue Cisco IOS XE 17.6.1a o versione successiva.
configure terminal call-home mail-server :@ priority 1 secure tls end
-
Configura la variabile d'ambiente ds_email con l'indirizzo email dell'amministratore per ricevere la notifica.
configure terminal call-home diagnostic-signature environment ds_email end
Di seguito viene mostrato un esempio di configurazione di un gateway locale in esecuzione su Cisco IOS XE 17.6.1a o versione successiva per inviare notifiche proattive a tacfaststart@gmail.com utilizzando Gmail come server SMTP sicuro:
Ti consigliamo di utilizzare Cisco IOS XE Bengaluru 17.6.x o versioni successive.
call-home
mail-server tacfaststart:password@smtp.gmail.com priority 1 secure tls
diagnostic-signature
environment ds_email "tacfaststart@gmail.com"
Un gateway locale in esecuzione su Cisco IOS XE Software non è un tipico client Gmail basato su Web che supporta OAuth, pertanto è necessario configurare un'impostazione dell'account Gmail specifica e fornire un'autorizzazione specifica per fare in modo che l'e-mail dal dispositivo venga elaborato correttamente:
-
Vai a Accesso app meno sicure.
e attiva l'impostazione -
Risposta "Sì, sono stato io" quando si riceve un messaggio e-mail da Gmail in cui viene indicato che "Google ha impedito a qualcuno di accedere all'account utilizzando un'app non Google".
Installare le firme diagnostiche per il monitoraggio proattivo
Monitoraggio di un elevato utilizzo della CPU
Questo DS tiene traccia dell'utilizzo della CPU per cinque secondi utilizzando l'OID SNMP 1.3.6.1.4.1.9.2.1.56. Quando l'utilizzo raggiunge il 75% o più, disabilita tutti i debug e disinstalla tutte le firme diagnostiche installate nel gateway locale. Utilizza questa procedura per installare la firma.
-
Utilizzare il comando show snmp per abilitare SNMP. Se non si abilita, configurare il comando snmp-server manager.
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
-
Scarica DS 64224 utilizzando le seguenti opzioni del menu a discesa nello strumento DSLT:
Nome campo
Valore campo
Piattaforma
Cisco 4300, 4400 ISR serie o Cisco CSR serie 1000V
Prodotto
CUBE Enterprise in Webex Calling
Ambito del problema
Prestazioni
Tipo di problema
Utilizzo elevato della CPU con notifica e-mail.
-
Copia il file XML DS nel flash del gateway locale.
LocalGateway# copy ftp://username:password@/DS_64224.xml bootflash:
L'esempio seguente mostra la copia del file da un server FTP al gateway locale.
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)
-
Installa il file XML DS nel gateway locale.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success
-
Utilizzare il comando mostra firma diagnostica call-home per verificare che la firma sia stata installata correttamente. La colonna dello stato deve contenere il valore "registered".
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
Download di firme digitali:
ID DS
Nome DS
Revisione
Stato
Ultimo aggiornamento (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Registrato
2020-11-07 22:05:33
Quando attivata, questa firma disinstalla tutte le DS in esecuzione, inclusa se stessa. Se necessario, reinstallare DS 64224 per continuare a monitorare l'elevato utilizzo della CPU sul gateway locale.
Registrazione trunk SIP di monitoraggio
Questo DS verifica l'annullamento della registrazione di un gateway locale Trunk SIP cloud Webex Calling ogni 60 secondi. Una volta rilevato l'evento di annullamento della registrazione, genera una notifica via email e syslog e si disinstalla automaticamente dopo due annullamenti della registrazione. Per installare la firma, attenersi alla seguente procedura:
-
Scarica DS 64117 utilizzando le seguenti opzioni del menu a discesa nello strumento DSLT:
Nome campo
Valore campo
Piattaforma
Cisco 4300, serie 4400 ISR o Cisco CSR serie 1000V
Prodotto
CUBE Enterprise in Webex Calling
Ambito del problema
SIP-SIP
Tipo di problema
Trunk SIP registrazione con notifica e-mail.
-
Copia il file XML DS nel gateway locale.
copy ftp://username:password@/DS_64117.xml bootflash:
-
Installa il file XML DS nel gateway locale.
call-home diagnostic-signature load DS_64117.xml Load file DS_64117.xml success LocalGateway#
-
Utilizzare il comando mostra firma diagnostica call-home per verificare che la firma sia stata installata correttamente. La colonna dello stato deve contenere un valore "registrato".
Disconnessioni chiamata anomala di monitoraggio
Questo DS utilizza il polling SNMP ogni 10 minuti per rilevare disconnessioni anomale delle chiamate con errori SIP 403, 488 e 503. Se l'incremento del conteggio degli errori è maggiore o uguale a 5 dall'ultimo polling, genera un syslog e una notifica via email. Per installare la firma, seguire i passaggi seguenti.
-
Utilizzare il comando show snmp per verificare se SNMP è abilitato. Se non è abilitato, configurare il comando snmp-server manager.
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
-
Scarica DS 65221 utilizzando le seguenti opzioni nello strumento DSLT:
Nome campo
Valore campo
Piattaforma
Cisco 4300, serie 4400 ISR o Cisco CSR serie 1000V
Prodotto
CUBE Enterprise in Webex Calling
Ambito del problema
Prestazioni
Tipo di problema
Rilevamento disconnessione chiamata anomala SIP con notifica e-mail e registro di sistema.
-
Copia il file XML DS nel gateway locale.
copy ftp://username:password@/DS_65221.xml bootflash:
-
Installa il file XML DS nel gateway locale.
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success
-
Utilizzare il comando mostra firma diagnostica call-home per verificare che la firma sia stata installata correttamente. La colonna dello stato deve contenere un valore "registrato".
Installare le firme diagnostiche per risolvere un problema
Utilizzare le firme diagnostiche (DS) per risolvere rapidamente i problemi. I tecnici Cisco TAC hanno creato diverse firme per consentire i debug necessari per risolvere un determinato problema, rilevare l'occorrenza del problema, raccogliere la serie giusta di dati diagnostici e trasferire automaticamente i dati al caso Cisco TAC. Le firme diagnostiche (DS) eliminano la necessità di verificare manualmente se si è verificato un problema e semplificano notevolmente la risoluzione dei problemi intermittenti e transitori.
È possibile utilizzare lo Strumento di ricerca delle firme diagnostiche per individuare le firme applicabili e installarle per risolvere automaticamente un determinato problema oppure installare la firma consigliata dal tecnico del Tac come parte del coinvolgimento in supporto.
Di seguito un esempio di come trovare e installare una DS per rilevare l'occorrenza "%VOICE_IEC-3-GW: CCAPI: Internal Error (call spike threshold): IEC=1.1.181.1.29.0" e automatizzare la raccolta di dati diagnostici utilizzando le seguenti operazioni:
-
Configurare una variabile d'ambiente DS aggiuntiva ds_fsurl_prefix, che corrisponde al percorso del file server Cisco TAC (cxd.cisco.com) su cui vengono caricati i dati diagnostici raccolti. Il nome utente nel percorso del file corrisponde al numero del caso e la password corrisponde al token di caricamento del file, che può essere recuperato da Support Case Manager con il seguente comando. Il token di caricamento del file può essere generato nella sezione Allegati di Support Case Manager, se necessario.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://:@cxd.cisco.com" end
Esempio:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"
-
Assicurarsi che SNMP sia abilitato utilizzando il comando show snmp. Se non è abilitato, configurare il comando snmp-server manager.
show snmp %SNMP agent not enabled config t snmp-server manager end
-
Assicurarsi di installare il DS 64224 di monitoraggio ad alta CPU come misura proattiva per disabilitare tutti i debug e le firme diagnostiche durante il periodo di utilizzo elevato della CPU. Scarica DS 64224 utilizzando le seguenti opzioni nello strumento DSLT:
Nome campo
Valore campo
Piattaforma
Cisco 4300, serie 4400 ISR o Cisco CSR serie 1000V
Prodotto
CUBE Enterprise in Webex Calling
Ambito del problema
Prestazioni
Tipo di problema
Utilizzo elevato della CPU con notifica e-mail.
-
Scarica DS 65095 utilizzando le seguenti opzioni nello strumento DSLT:
Nome campo
Valore campo
Piattaforma
Cisco 4300, serie 4400 ISR o Cisco CSR serie 1000V
Prodotto
CUBE Enterprise in Webex Calling
Ambito del problema
Registri di sistema
Tipo di problema
Syslog - %VOICE_IEC-3-GW: CCAPI: Internal Error (Call spike threshold): IEC=1.1.181.1.29.0
-
Copia i file XML DS nel gateway locale.
copy ftp://username:password@/DS_64224.xml bootflash: copy ftp://username:password@/DS_65095.xml bootflash:
-
Installa la DS 64224 per il monitoraggio dell'utilizzo elevato di CPU e quindi il file XML DS 65095 nel gateway locale.
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
-
Verificare che la firma sia stata installata correttamente utilizzando il comando show call-home diagnostic-signature. La colonna dello stato deve contenere un valore "registrato".
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
Firme digitali scaricate:
ID DS
Nome DS
Revisione
Stato
Ultimo aggiornamento (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Registrato
2020-11-08
65095
00:12:53
DS_LGW_IEC_Call_spike_threshold
0.0.12
Registrato
2020-11-08
Verifica esecuzione firme diagnostiche
Nel comando seguente, la colonna "Stato" del comando show call-home diagnostic-signature cambia in "running" mentre il gateway locale esegue l'azione definita nella firma. L'output delle statistiche della firma diagnostica della chiamata a casa è il modo migliore per verificare se una firma diagnostica rileva un evento di interesse ed esegue l'azione. La colonna "Attivata/Max/Disattivazione" indica il numero di volte in cui la firma specificata ha attivato un evento, il numero massimo di volte in cui viene definito per rilevare un evento e se la firma si autoinstalla dopo aver rilevato il numero massimo di eventi attivati.
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
Firme digitali scaricate:
ID DS |
Nome DS |
Revisione |
Stato |
Ultimo aggiornamento (GMT+00:00) |
---|---|---|---|---|
64224 |
DS_LGW_CPU_MON75 |
0.0.10 |
Registrato |
2020-11-08 00:07:45 |
65095 |
DS_LGW_IEC_Call_spike_threshold |
0.0.12 |
In esecuzione |
2020-11-08 00:12:53 |
mostra statistiche firma diagnostica-chiamata in home
ID DS |
Nome DS |
Innescato/Max/Deinstall |
Tempo di esecuzione medio (secondi) |
Tempo di esecuzione massimo (secondi) |
---|---|---|---|---|
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 |
Il e-mail di notifica inviato durante l'esecuzione della firma diagnostica contiene informazioni chiave come tipo di problema, dettagli del dispositivo, versione software, configurazione in esecuzione e visualizzazione degli output dei comandi correlati alla risoluzione del problema.
Disinstallare le firme diagnostiche
Per la risoluzione dei problemi vengono solitamente definite le firme diagnostiche da disinstallare dopo il rilevamento di alcune occorrenze di problemi. Se si desidera disinstallare manualmente una firma, recuperare l'ID DS dall'output del comando show call-home diagnostic-signature ed eseguire il comando seguente:
call-home diagnostic-signature deinstall
Esempio:
call-home diagnostic-signature deinstall 64224
Nuove firme vengono aggiunte periodicamente nello strumento di ricerca delle firme diagnostiche, in base ai problemi che vengono comunemente osservati nelle distribuzioni. Il TAC attualmente non supporta richieste di creazione di nuove firme personalizzate.
Per una migliore gestione dei gateway Cisco IOS XE, consigliamo di registrare e gestire i gateway tramite Control Hub. È una configurazione opzionale. Una volta effettuata la registrazione, è possibile utilizzare l'opzione di convalida della configurazione nel Control Hub per convalidare la configurazione del gateway locale e identificare eventuali problemi di configurazione. Attualmente, solo i trunk basati sulla registrazione supportano questa funzionalità.
Per ulteriori informazioni, fare riferimento a quanto segue:
In questa sezione viene descritto come configurare un Cisco Unified Border Element (CUBE) come gateway locale per Webex Calling utilizzando un trunk SIP mTLS (Mutual TLS) basato su certificato. La prima parte di questo documento illustra come configurare un semplice gateway PSTN. In questo caso, tutte le chiamate dalla PSTN vengono instradate a Webex Calling e tutte le chiamate da Webex Calling vengono instradate alla PSTN. L'immagine seguente evidenzia questa soluzione e la configurazione di routing delle chiamate di alto livello che verrà seguita.
In questo progetto vengono utilizzate le seguenti configurazioni principali:
-
inquilini della classe vocale: Used per creare configurazioni specifiche del trunk.
-
classe vocale uri: Utilizzato per classificare i messaggi SIP per la selezione di un dial-peer in ingresso.
-
dial-peer in entrata: Fornisce il trattamento per i messaggi SIP in entrata e determina il percorso in uscita utilizzando un gruppo dial-peer.
-
gruppo dial-peer: Definisce i dial-peer in uscita utilizzati per l'inoltro delle chiamate.
-
dial-peer in uscita: Fornisce il trattamento dei messaggi SIP in uscita e li indirizza alla destinazione richiesta.

Quando si collega una soluzione Cisco Unified Communications Manager locale con Webex Calling, è possibile utilizzare la semplice configurazione del gateway PSTN come base per creare la soluzione illustrata nel diagramma seguente. In questo caso, un Unified Communications Manager fornisce un routing e un trattamento centralizzati di tutte le chiamate PSTN e Webex Calling.

In questo documento vengono utilizzati i nomi host, gli indirizzi IP e le interfacce illustrati nell'immagine seguente. Sono disponibili opzioni per l'indirizzamento pubblico o privato (dietro NAT). I record DNS SRV sono facoltativi, a meno che non si effettui il bilanciamento del carico su più istanze CUBE.

Per completare la configurazione del gateway locale, utilizzare le istruzioni di configurazione riportate nel resto del documento come segue:
Configurazione di base
Il primo passo per preparare il router Cisco come gateway locale per Webex Calling è creare una configurazione di base che protegga la piattaforma e stabilisca la connettività.
-
Tutte le distribuzioni di Local Gateway basate su certificati richiedono Cisco IOS XE 17.9.1a o versioni successive. Si consiglia Cisco IOS XE 17.12.2 o versione successiva. Per le versioni consigliate, vedere la pagina Cisco Software Research. Cerca la piattaforma e seleziona una delle versioni suggerite.
-
I router della serie ISR4000 devono essere configurati con entrambe le licenze per la tecnologia Unified Communications e Security.
-
I router Catalyst Edge serie 8000 dotati di schede vocali o DSP richiedono la licenza DNA Advantage. I router senza schede vocali o DSP necessitano almeno della licenza DNA Essentials.
-
Per requisiti di elevata capacità, potrebbe essere necessaria anche una licenza HSEC (High Security) e un ulteriore diritto di throughput.
Per ulteriori dettagli fare riferimento a Codici di autorizzazione.
-
-
Crea una configurazione di base per la tua piattaforma che rispetti le tue policy aziendali. In particolare, configurare e verificare quanto segue:
-
Ntp
-
Acl
-
Autenticazione utente e accesso remoto
-
DNS
-
Indirizzamento IP
-
indirizzi IP
-
-
La rete verso Webex Calling deve utilizzare un indirizzo IPv4. Gli indirizzi FQDN (Fully Qualified Domain Name) o SRV (Service Record) del gateway locale configurati nel Control Hub devono essere risolti in un indirizzo IPv4 pubblico su Internet.
-
Tutte le porte SIP e multimediali sull'interfaccia del gateway locale rivolta verso Webex devono essere accessibili da Internet, direttamente o tramite NAT statico. Assicuratevi di aggiornare il vostro firewall di conseguenza.
-
Per installare un certificato firmato sul gateway locale, seguire i passaggi di configurazione dettagliati indicati di seguito:
-
Un'autorità di certificazione (CA) pubblica come descritto in Quali autorità di certificazione radice sono supportate per le chiamate alle piattaforme audio e video Cisco Webex? deve firmare il certificato del dispositivo.
-
Il nome comune (CN) del soggetto del certificato o uno dei nomi alternativi del soggetto (SAN) deve essere uguale al nome di dominio completo (FQDN) configurato nel Control Hub. Ad esempio:
-
Se un trunk configurato nel Control Hub della tua organizzazione ha cube1.lgw.com:5061 come FQDN del gateway locale, il CN o il SAN nel certificato del router deve contenere cube1.lgw.com.
-
Se un trunk configurato nel Control Hub della tua organizzazione ha lgws.lgw.com come indirizzo SRV del/dei gateway locale/i raggiungibile/i dal trunk, il CN o il SAN nel certificato del router deve contenere lgws.lgw.com. I record che l SRV indirizzo host risolve in (CNAME, A Record o Indirizzo IP) sono opzionali in SAN.
-
Indipendentemente dal fatto che si utilizzi un FQDN o un SRV per il trunk, l'indirizzo di contatto per tutti i nuovi dialoghi SIP dal gateway locale deve utilizzare il nome configurato nel Control Hub.
-
-
Assicurarsi che i certificati siano firmati per l'utilizzo da parte del client e del server.
-
-
Caricare il bundle CA radice Cisco sul gateway locale. Questo pacchetto include il certificato radice CA utilizzato per verificare la piattaforma Webex.
Configurazione
1 |
Assicurarsi di assegnare indirizzi IP validi e instradabili a tutte le interfacce di Livello 3, ad esempio:
|
2 |
Proteggere le credenziali STUN sul router utilizzando la crittografia simmetrica. Configurare la chiave di crittografia primaria e il tipo di crittografia come segue: |
3 |
Crea un trustpoint di crittografia con un certificato per il tuo dominio, firmato da un'autorità di certificazione (CA) supportata da. |
4 |
Fornire il certificato della CA di firma intermedia per autenticare il certificato host. Immettere il seguente comando di esecuzione o di configurazione:
|
5 |
Importare il certificato host firmato utilizzando il seguente comando di esecuzione o di configurazione:
|
6 |
Abilitare l'esclusività TLS1.2 e specificare il trustpoint predefinito da utilizzare per le applicazioni vocali utilizzando i seguenti comandi di configurazione:
|
7 |
Installare il bundle Cisco Root CA, che include il certificato IdenTrust Commercial Root CA 1 utilizzato da Webex Calling. Utilizzare il comando crypto pki trustpool import clean url url per scaricare il bundle CA radice dall'URL specificato e per cancellare l'attuale trustpool CA, quindi installare il nuovo bundle di certificati: Se è necessario utilizzare un proxy per l'accesso a Internet tramite HTTPS, aggiungere la seguente configurazione prima di importare il bundle CA: ip http client proxy-server yourproxy.com porta proxy 80 |
1 |
Creare un trunk PSTN basato su certificato CUBE per una posizione esistente nel Control Hub. Per ulteriori informazioni, vedere Configurare trunk, gruppi di routing e piani di chiamata per Webex Calling. Prendi nota delle informazioni sul trunk durante la creazione del trunk. Questi dettagli, come evidenziato nell'illustrazione seguente, vengono utilizzati nei passaggi di configurazione descritti in questa guida. ![]() |
2 |
Immettere i seguenti comandi per configurare CUBE come gateway locale di Webex Calling: Di seguito una spiegazione dei campi per la configurazione:
Abilita le funzionalità Cisco Unified Border Element (CUBE) sulla piattaforma. consenti-connessioni sip a SIPAbilita la funzionalità back-to-back user agent SIP di base di CUBE. Per ulteriori informazioni, vedere Consenti connessioni. Per impostazione predefinita, il trasporto fax T.38 è abilitato. Per ulteriori informazioni, vedere protocollo fax t38 (servizio vocale). Abilita STUN (Session Traversal of UDP through NAT) a livello globale. Questi comandi stun globali sono necessari solo quando si distribuisce il gateway locale dietro NAT.
Per ulteriori informazioni, vedere stun flowdata agent-ide stun flowdata shared-secret. carico utile asimmetrico completoConfigura il supporto del payload asimmetrico SIP per i payload DTMF e codec dinamici. Per maggiori informazioni su questo comando, vedere asymmetric payload. offerta anticipata forzataForza il gateway locale a inviare informazioni SDP nel messaggio INVITE iniziale anziché attendere la conferma dal peer vicino. Per maggiori informazioni su questo comando, vedere early-offer. profili SIP in entrataConsente a CUBE di utilizzare profili SIP per modificare i messaggi non appena vengono ricevuti. I profili vengono applicati tramite dial-peer o tenant. |
3 |
Configurare codec di classe vocale 100 consentendo solo i codec G.711 per tutti i trunk. Questo semplice approccio è adatto alla maggior parte delle distribuzioni. Se necessario, aggiungere all'elenco altri tipi di codec supportati sia dal sistema di origine che da quello di destinazione. Sono supportate soluzioni più complesse che coinvolgono la transcodificamediante moduli DSP, ma non sono incluse in questa guida. |
4 |
Configurare classe vocale stun-usage 100 per abilitare ICE sul trunk Webex Calling. (Questo passaggio non è applicabile a Webex for Government) Di seguito una spiegazione dei campi per la configurazione: utilizzo stordimento ghiaccio leggeroUtilizzato per abilitare ICE-Lite per tutti i dial-peer che utilizzano Webex Calling per consentire l'ottimizzazione dei contenuti multimediali ove possibile. Per maggiori informazioni, vedere utilizzo della classe vocale stordimento e utilizzo della classe vocale stordimento ghiaccio lite. Il comandostun usage firewall-traversal flowdataè necessario solo quando si distribuisce il gateway locale dietro NAT. L'ottimizzazione dei media viene negoziata ove possibile. Se una chiamata richiede servizi multimediali cloud, come la registrazione, i contenuti multimediali non possono essere ottimizzati. |
5 |
Configurare i criteri di crittografia multimediale per il traffico Webex. (Questo passaggio non è applicabile a Webex for Government) Di seguito una spiegazione dei campi per la configurazione: classe vocale srtp-crypto 100Specifica SHA1_80 come unica suite di cifratura SRTP offerta da CUBE nell'SDP nei messaggi di offerta e risposta. Webex Calling supporta solo SHA1_80. Per ulteriori informazioni, vedere voice class srtp-crypto. |
6 |
Configurare i cifrari GCM conformi a FIPS (Questo passaggio è applicabile solo per Webex for Government). Di seguito una spiegazione dei campi per la configurazione: classe vocale srtp-crypto 100Specifica GCM come suite crittografica offerta da CUBE. È obbligatorio configurare i cifrari GCM per il gateway locale per Webex for Government. |
7 |
Configurare un modello per identificare in modo univoco le chiamate a un trunk del gateway locale in base al suo FQDN o SRV di destinazione: Di seguito una spiegazione dei campi per la configurazione: corso di canto uri 100 sipDefinisce un modello per abbinare un invito SIP in arrivo a un dial-peer trunk in arrivo. Quando si immette questo modello, utilizzare l'FQDN o l'SRV del trunk configurato nel Control Hub per il trunk. Utilizzare l'indirizzo edge Webex Calling basato su SRV sul gateway locale durante la configurazione di trunk basati su certificati. |
8 |
Configurare i profili di manipolazione dei messaggi SIP. Se il gateway è configurato con un indirizzo IP pubblico, configurare un profilo come segue oppure passare al passaggio successivo se si utilizza NAT. In questo esempio, cube1.lgw.com è l'FQDN configurato per il gateway locale: Di seguito una spiegazione dei campi per la configurazione: regole 10 e 20Per consentire a Webex di autenticare i messaggi dal gateway locale, l'intestazione "Contatto" nei messaggi di richiesta e risposta SIP deve contenere il valore predisposto per il trunk nel Control Hub. Può trattarsi dell'FQDN di un singolo host oppure del nome SRV utilizzato per un cluster di dispositivi. |
9 |
Se il gateway è configurato con un indirizzo IP privato dietro NAT statico, configurare i profili SIP in entrata e in uscita come segue. In questo esempio, cube1.lgw.com è l'FQDN configurato per il gateway locale, "10.80.13.12" è l'indirizzo IP dell'interfaccia rivolta a Webex Calling e "192.65.79.20" è l'indirizzo IP pubblico NAT. Profili SIP per messaggi in uscita verso Webex Calling
Di seguito una spiegazione dei campi per la configurazione: regole 10 e 20Per consentire a Webex di autenticare i messaggi dal gateway locale, l'intestazione "Contatto" nei messaggi di richiesta e risposta SIP deve contenere il valore predisposto per il trunk nel Control Hub. Può trattarsi dell'FQDN di un singolo host oppure del nome SRV utilizzato per un cluster di dispositivi. regole da 30 a 81Convertire i riferimenti agli indirizzi privati nell'indirizzo pubblico esterno del sito, consentendo a Webex di interpretare e instradare correttamente i messaggi successivi. Profilo SIP per i messaggi in arrivo da Webex Calling Di seguito una spiegazione dei campi per la configurazione: regole da 10 a 80Converti i riferimenti agli indirizzi pubblici nell'indirizzo privato configurato, consentendo a CUBE di elaborare i messaggi da Webex. Per ulteriori informazioni, vedere classe vocale sip-profiles. Il provider PSTN degli Stati Uniti o del Canada può offrire la verifica dell'ID chiamante per chiamate spam e fraudolente, con la configurazione aggiuntiva menzionata nell'articolo Indicazione di chiamate spam o fraudolente in Webex Calling. |
10 |
Configurare un profilo keepalive delle opzioni SIP con modifica dell'intestazione.
|
11 |
Configurare il trunk Webex Calling: |
Dopo aver creato un trunk verso Webex Calling come descritto sopra, utilizzare la seguente configurazione per creare un trunk non crittografato verso un provider PSTN basato su SIP:
Se il tuo fornitore di servizi offre un trunk PSTN sicuro, puoi seguire una configurazione simile a quella descritta in precedenza per il trunk Webex Calling. CUBE supporta l'instradamento sicuro delle chiamate.
Se si utilizza un TDM / Tronco PSTN ISDN, passare alla sezione successiva Configurare il gateway locale con tronco PSTN TDM.
Per configurare le interfacce TDM per le linee di chiamata PSTN sui gateway Cisco TDM-SIP, vedere Configurazione ISDN PRI.
1 |
Configurare il seguente URI di classe vocale per identificare le chiamate in arrivo dal trunk PSTN: Di seguito una spiegazione dei campi per la configurazione: corso di canto uri 200 sipDefinisce un modello per abbinare un invito SIP in arrivo a un dial-peer trunk in arrivo. Quando si immette questo schema, utilizzare l'indirizzo IP del gateway IP PSTN. Per ulteriori informazioni, vedere classe vocale uri. |
2 |
Configurare il seguente dial-peer IP PSTN: Di seguito una spiegazione dei campi per la configurazione: Definisce un dial-peer VoIP con un tag di 200 e fornisce una descrizione significativa per facilitare la gestione e la risoluzione dei problemi. Per ulteriori informazioni, vedere dial-peer voice. modello-destinazione BAD.BADQuando si instradano chiamate in uscita utilizzando un gruppo di peer di chiamata in entrata, è necessario un modello di destinazione fittizio. In questo caso è possibile utilizzare qualsiasi modello di destinazione valido. Per ulteriori informazioni, vedere destination-pattern (interfaccia). protocollo sessione sipv2Specifica che questo dial-peer gestisce le tratte delle chiamate SIP. Per ulteriori informazioni, vedere protocollo di sessione (dial peer). destinazione sessione ipv4: 192.168.80.13Specifica l'indirizzo di destinazione per le chiamate inviate al provider PSTN. Potrebbe trattarsi di un indirizzo IP o di un nome host DNS. Per ulteriori informazioni, vedere destinazione della sessione (peer di selezione VoIP). uri in arrivo tramite 200Specifica la classe vocale utilizzata per abbinare le chiamate in arrivo a questo dial-peer utilizzando l'URI dell'intestazione INVITE VIA. Per ulteriori informazioni, vedere URL in arrivo. classe vocale sip id asserito pai
(Facoltativo) Attiva l'elaborazione dell'intestazione P-Asserted-Identity e controlla come questa viene utilizzata per il trunk PSTN. Se si utilizza questo comando, per le intestazioni From e P-Asserted-Identity in uscita viene utilizzata l'identità della parte chiamante fornita dal dial-peer in entrata. Se questo comando non viene utilizzato, per le intestazioni From e Remote-Party-ID in uscita viene utilizzata l'identità della parte chiamante fornita dal dial-peer in entrata. Per ulteriori informazioni, vedere voice-class sip asserted-id. controllo di associazione interfaccia sorgente GigabitEthernet0/0/0
Configura l'interfaccia sorgente e l'indirizzo IP associato per i messaggi inviati alla PSTN. Per ulteriori informazioni, vedere bind. associa l'interfaccia sorgente multimediale GigabitEthernet0/0/0Configura l'interfaccia sorgente e l'indirizzo IP associato per i contenuti multimediali inviati alla PSTN. Per ulteriori informazioni, vedere bind. codec di classe vocale 100Configura il dial-peer per utilizzare l'elenco dei filtri codec comuni 100. Per ulteriori informazioni, vedere voice-class codec. dtmf-relay rtp-nteDefinisce RTP-NTE (RFC2833) come funzionalità DTMF prevista sul modello della chiamata. Per ulteriori informazioni, vedere DTMF Relay (Voice over IP). nessun vadDisabilita il rilevamento dell'attività vocale. Per ulteriori informazioni, vedere vad (dial peer). |
3 |
Se si sta configurando il gateway locale per instradare solo le chiamate tra Webex Calling e la rete PSTN, aggiungere la seguente configurazione di instradamento delle chiamate. Se stai configurando il tuo gateway locale con una piattaforma Unified Communications Manager, passa alla sezione successiva. |
Dopo aver creato un trunk verso Webex Calling, utilizzare la seguente configurazione per creare un trunk TDM per il servizio PSTN con routing delle chiamate loop-back per consentire l'ottimizzazione dei contenuti multimediali sul segmento di chiamata Webex.
Se non è richiesta l'ottimizzazione dei media IP, seguire i passaggi di configurazione per un trunk PSTN SIP. Utilizzare una porta vocale e un dial-peer POTS (come mostrato nei passaggi 2 e 3) anziché il dial-peer VoIP PSTN.
1 |
La configurazione loop-back dial-peer utilizza gruppi dial-peer e tag di routing delle chiamate per garantire che le chiamate vengano trasmesse correttamente tra Webex e la PSTN, senza creare loop di routing delle chiamate. Configurare le seguenti regole di traduzione che verranno utilizzate per aggiungere e rimuovere i tag di instradamento delle chiamate: Di seguito una spiegazione dei campi per la configurazione: regola della traduzione vocaleUtilizza espressioni regolari definite nelle regole per aggiungere o rimuovere tag di instradamento delle chiamate. Le cifre ultradecadiche ('A') vengono utilizzate per aumentare la chiarezza nella risoluzione dei problemi. In questa configurazione, il tag aggiunto da translation-profile 100 viene utilizzato per guidare le chiamate da Webex Calling verso la PSTN tramite i dial-peer loopback. Allo stesso modo, il tag aggiunto da translation-profile 200 viene utilizzato per indirizzare le chiamate dalla PSTN verso Webex Calling. I profili di traduzione 11 e 12 rimuovono questi tag prima di inoltrare le chiamate rispettivamente ai trunk Webex e PSTN. Questo esempio presuppone che i numeri chiamati da Webex Calling siano presentati in +E.164 formato. La regola 100 rimuove il leader + per mantenere un numero chiamato valido. La regola 12 aggiunge quindi una o più cifre di routing nazionale o internazionale quando si rimuove l'etichetta. Utilizzare cifre compatibili con il piano tariffario nazionale ISDN locale. Se Webex Calling presenta i numeri in formato nazionale, modificare le regole 100 e 12 semplicemente aggiungendo e rimuovendo rispettivamente il tag di routing. Per ulteriori informazioni, vedere voice translation-profile e voice translation-rule. |
2 |
Configurare le porte dell'interfaccia vocale TDM in base al tipo di trunk e al protocollo utilizzato. Per ulteriori informazioni, vedere Configurazione ISDN PRI. Ad esempio, la configurazione di base di un'interfaccia Primary Rate ISDN installata nello slot NIM 2 di un dispositivo potrebbe includere quanto segue: |
3 |
Configurare il seguente dial-peer TDM PSTN: Di seguito una spiegazione dei campi per la configurazione: Definisce un dial-peer VoIP con un tag pari a 200 e fornisce una descrizione significativa per semplificare la gestione e la risoluzione dei problemi. Per ulteriori informazioni, vedere dial-peer voice. modello-destinazione BAD.BADQuando si instradano chiamate in uscita utilizzando un gruppo di peer di chiamata in entrata, è necessario un modello di destinazione fittizio. In questo caso è possibile utilizzare qualsiasi modello di destinazione valido. Per ulteriori informazioni, vedere destination-pattern (interfaccia). profilo di traduzione in arrivo 200Assegna il profilo di traduzione che aggiungerà un tag di instradamento delle chiamate al numero chiamato in entrata. selezione diretta internaInstrada la chiamata senza fornire un tono di selezione secondario. Per ulteriori informazioni, vedere direct-inward-dial. porta 0/2/0:15Porta vocale fisica associata a questo dial-peer. |
4 |
Per abilitare l'ottimizzazione multimediale dei percorsi IP per i gateway locali con flussi di chiamate TDM-IP, è possibile modificare l'instradamento delle chiamate introducendo un set di dial-peer loop-back interni tra Webex Calling e trunk PSTN. Configurare i seguenti dial-peer loop-back. In questo caso, tutte le chiamate in arrivo verranno inizialmente indirizzate al dial-peer 10 e da lì al dial-peer 11 o 12 in base al tag di routing applicato. Dopo la rimozione del tag di routing, le chiamate verranno instradate al trunk in uscita utilizzando gruppi dial-peer. Di seguito una spiegazione dei campi per la configurazione: Definisce un dial-peer VoIP e fornisce una descrizione significativa per semplificare la gestione e la risoluzione dei problemi. Per ulteriori informazioni, vedere dial-peer voice. profilo di traduzione in arrivo 11Applica il profilo di traduzione definito in precedenza per rimuovere il tag di instradamento delle chiamate prima di passare al trunk in uscita. modello-destinazione BAD.BADQuando si instradano chiamate in uscita utilizzando un gruppo di peer di chiamata in entrata, è necessario un modello di destinazione fittizio. Per ulteriori informazioni, vedere destination-pattern (interfaccia). protocollo sessione sipv2Specifica che questo dial-peer gestisce le tratte delle chiamate SIP. Per ulteriori informazioni, vedere protocollo di sessione (dial peer). destinazione sessione ipv4: 192.168.80.14Specifica l'indirizzo dell'interfaccia del router locale come destinazione della chiamata per il loop-back. Per ulteriori informazioni, vedere destinazione della sessione (peer di selezione VoIP). controllo di associazione interfaccia sorgente GigabitEthernet0/0/0Configura l'interfaccia sorgente e l'indirizzo IP associato per i messaggi inviati tramite loop-back. Per ulteriori informazioni, vedere bind. associa l'interfaccia sorgente multimediale GigabitEthernet0/0/0Configura l'interfaccia sorgente e l'indirizzo IP associato per i contenuti multimediali inviati tramite loop-back. Per ulteriori informazioni, vedere bind. dtmf-relay rtp-nteDefinisce RTP-NTE (RFC2833) come funzionalità DTMF prevista sul modello della chiamata. Per ulteriori informazioni, vedere DTMF Relay (Voice over IP). codec g711alaw Forza tutte le chiamate PSTN a utilizzare G.711. Selezionare a-law o u-law in base al metodo di compressione/compressione utilizzato dal servizio ISDN. nessun vadDisabilita il rilevamento dell'attività vocale. Per ulteriori informazioni, vedere vad (dial peer). |
5 |
Aggiungere la seguente configurazione di routing delle chiamate: La configurazione del gateway locale è terminata. Salvare la configurazione e ricaricare la piattaforma se questa è la prima volta che si configurano le funzionalità CUBE.
|
La configurazione PSTN-Webex Calling nelle sezioni precedenti può essere modificata per includere trunk aggiuntivi in un cluster Cisco Unified Communications Manager (UCM). In questo caso, tutte le chiamate vengono instradate tramite Unified CM. Le chiamate da UCM sulla porta 5060 vengono instradate alla PSTN, mentre le chiamate dalla porta 5065 vengono instradate a Webex Calling. Per includere questo scenario di chiamata, è possibile aggiungere le seguenti configurazioni incrementali.
1 |
Configura i seguenti URI di classe vocale: |
2 |
Configurare i seguenti record DNS per specificare il routing SRV agli host Unified CM: IOS XE utilizza questi record per determinare localmente gli host e le porte UCM di destinazione. Con questa configurazione non è necessario configurare i record nel sistema DNS. Se preferisci utilizzare il tuo DNS, queste configurazioni locali non sono necessarie. Di seguito una spiegazione dei campi per la configurazione: Il seguente comando crea un record di risorse DNS SRV. Crea un record per ogni host e trunk UCM: host IP _sip._udp.pstntocucm.io servizio 2 1 5060 ucmsub5.miodominio.com _sip._udp.pstntocucm.io: Nome del record di risorse SRV 2: Priorità del record di risorse SRV 1: Il peso del record delle risorse SRV 5060: Il numero di porta da utilizzare per l'host di destinazione in questo record di risorse ucmsub5.mydomain.com: L'host di destinazione del record di risorse Per risolvere i nomi host di destinazione dei record di risorse, creare record DNS A locali. Ad esempio: host IP ucmsub5.miodominio.com 192.168.80.65 host IP: Crea un record nel database IOS XE locale. ucmsub5.mydomain.com: Nome host del record A. 192.168.80.65: L'indirizzo IP dell'host. Crea i record delle risorse SRV e i record A per riflettere il tuo ambiente UCM e la strategia di distribuzione delle chiamate preferita. |
3 |
Configurare i seguenti dial-peer: |
4 |
Aggiungere l'instradamento delle chiamate utilizzando le seguenti configurazioni: |
Le firme diagnostiche (DS) individuano in modo proattivo i problemi comunemente osservati nel gateway locale basato su Cisco IOS XE e generano notifica e-mail, registro di sistema o messaggi terminali dell'evento. Puoi anche installare le DS per automatizzare la raccolta dei dati diagnostici e trasferire i dati raccolti al caso Cisco TAC per risolvere più rapidamente il problema.
Le firme diagnostiche (DS) sono file XML contenenti informazioni su eventi e azioni di attivazione del problema per informare, risolvere e risolvere il problema. Utilizzare i messaggi syslog, gli eventi SNMP e attraverso il monitoraggio periodico di output specifici dei comandi di visualizzazione per definire la logica di rilevamento dei problemi. I tipi di azione includono:
-
Raccolta degli output dei comandi visualizzati
-
Generazione di un file di log consolidato
-
Caricamento del file in un percorso di rete fornito dall'utente come HTTPS, SCP, server FTP
I tecnici TAC autorizzano i file DS e firmano in digitale i file per la protezione dell'integrità. Ogni file DS dispone dell'ID numerico univoco assegnato dal sistema. Diagnostic Signatures Lookup Tool (DSLT) è un'unica fonte per trovare firme applicabili per il monitoraggio e la risoluzione di vari problemi.
Operazioni preliminari:
-
Non modificare il file DS scaricato da DSLT. L'installazione dei file da modificare non riesce a causa dell'errore di controllo dell'integrità.
-
Un server SMTP (Mail Transfer Protocol) semplice richiesto dal gateway locale per l'invio di notifiche e-mail.
-
Accertarsi che sul gateway locale sia in esecuzione IOS XE 17.6.1 o superiore se si desidera utilizzare il server SMTP sicuro per le notifiche e-mail.
Prerequisiti
Gateway locale con IOS XE 17.6.1 o superiore
-
Le firme diagnostiche sono abilitate per impostazione predefinita.
-
Configurare il server e-mail sicuro utilizzato per inviare notifiche proattive se sul dispositivo è in esecuzione IOS XE 17.6.1 o superiore.
configure terminal call-home mail-server :@ priority 1 secure tls end
-
Configurare la variabile di ambiente con ds_email l'indirizzo e-mail dell'amministratore a cui inviare la notifica.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_email end
Installare le firme diagnostiche per il monitoraggio proattivo
Monitoraggio di un elevato utilizzo della CPU
Questo DS registra l'utilizzo della CPU di 5 secondi utilizzando l'OID SNMP 1.3.6.1.4.1.9.1.56. Quando l'utilizzo raggiunge il 75% o più, disabilita tutti i debug e disinstalla tutte le firme diagnostiche installate nel gateway locale. Utilizza questa procedura per installare la firma.
-
Accertarsi di aver abilitato SNMP utilizzando il comando show snmp. Se SNMP non è abilitato, configurare il comando snmp-server manager.
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
Scarica DS 64224 utilizzando le seguenti opzioni del menu a discesa nello strumento DSLT:
copy ftp://username:password@/DS_64224.xml bootflash:
Nome campo
Valore campo
Piattaforma
Software Cisco serie 4300, 4400 ISR o Catalyst 8000V Edge
Prodotto
CUBE Enterprise nella soluzione Webex Calling
Ambito del problema
Prestazioni
Tipo di problema
Utilizzo elevato della CPU con notifica e-mail
-
Copia il file XML DS nel flash del gateway locale.
copy ftp://username:password@/DS_64224.xml bootflash:
L'esempio seguente mostra la copia del file da un server FTP al gateway locale.
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)
-
Installa il file XML DS nel gateway locale.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success
-
Utilizzare il comando mostra firma diagnostica call-home per verificare che la firma sia stata installata correttamente. La colonna dello stato deve contenere un valore "registrato".
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
Download di firme digitali:
ID DS
Nome DS
Revisione
Stato
Ultimo aggiornamento (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Registrato
2020-11-07 22:05:33
Quando attivata, questa firma disinstalla tutte le DS in esecuzione, inclusa se stessa. Se necessario, reinstallare DS 64224 per continuare a monitorare un elevato utilizzo della CPU sul gateway locale.
Disconnessioni chiamata anomala di monitoraggio
Questo DS utilizza il polling SNMP ogni 10 minuti per rilevare disconnessioni anomale delle chiamate con errori SIP 403, 488 e 503. Se l'incremento del conteggio degli errori è maggiore o uguale a 5 dall'ultimo polling, genera un syslog e una notifica via email. Per installare la firma, seguire i passaggi seguenti.
-
Accertarsi che SNMP sia abilitato utilizzando il comando show snmp. Se SNMP non è abilitato, configurare il comando snmp-server manager.
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
-
Scarica DS 65221 utilizzando le seguenti opzioni nello strumento DSLT:
Nome campo
Valore campo
Piattaforma
Software Cisco serie 4300, 4400 ISR o Catalyst 8000V Edge
Prodotto
CUBE Enterprise in Webex Calling
Ambito del problema
Prestazioni
Tipo di problema
Rilevamento disconnessione chiamata anomala SIP con notifica e-mail e registro di sistema.
-
Copia il file XML DS nel gateway locale.
copy ftp://username:password@/DS_65221.xml bootflash:
-
Installa il file XML DS nel gateway locale.
call-home diagnostic-signature load DS_65221.xml Load file DS_65221.xml success
-
Utilizzare il comando show call-home diagnostic-signature per verificare che la firma sia stata installata correttamente. La colonna dello stato deve contenere il valore "registered".
Installare le firme diagnostiche per risolvere un problema
È anche possibile utilizzare le firme diagnostiche (DS) per risolvere rapidamente i problemi. I tecnici Cisco TAC hanno creato diverse firme per consentire i debug necessari per risolvere un determinato problema, rilevare l'occorrenza del problema, raccogliere la serie giusta di dati diagnostici e trasferire automaticamente i dati al caso Cisco TAC. In questo modo, si elimina la necessità di controllare manualmente la presenza del problema e si rende molto più semplice la risoluzione di problemi intermittenti e temporanei.
È possibile utilizzare lo Strumento di ricerca delle firme diagnostiche per individuare le firme applicabili e installarle per autosolvere un determinato problema oppure installare la firma consigliata dal tecnico del Tac come parte del coinvolgimento in supporto.
Di seguito un esempio di come trovare e installare una DS per rilevare l'occorrenza "%VOICE_IEC-3-GW: CCAPI: Internal Error (call spike threshold): IEC=1.1.181.1.29.0" e automatizzare la raccolta di dati diagnostici utilizzando le seguenti operazioni:
Configurare un'altra variabile d'ambiente DS ds_fsurl_prefixcome percorso del file server Cisco TAC (cxd.cisco.com) per caricare i dati diagnostici. Il nome utente nel percorso del file corrisponde al numero del caso e la password corrisponde al token di caricamento del file, che può essere recuperato da Support Case Manager come mostrato di seguito. Il token di caricamento del file può essere generato nella sezione Allegati di Support Case Manager, se necessario.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://:@cxd.cisco.com" end
Esempio:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"
-
Accertarsi che SNMP sia abilitato utilizzando il comando show snmp. Se SNMP non è abilitato, configurare il comando snmp-server manager.
show snmp %SNMP agent not enabled config t snmp-server manager end
-
Si consiglia di installare il monitoraggio ad alta CPU DS 64224 come misura proattiva per disabilitare tutti i debug e le firme diagnostiche durante il periodo di utilizzo elevato della CPU. Scarica DS 64224 utilizzando le seguenti opzioni nello strumento DSLT:
Nome campo
Valore campo
Piattaforma
Software Cisco serie 4300, 4400 ISR o Catalyst 8000V Edge
Prodotto
CUBE Enterprise in Webex Calling
Ambito del problema
Prestazioni
Tipo di problema
Utilizzo elevato della CPU con notifica e-mail.
-
Scarica DS 65095 utilizzando le seguenti opzioni nello strumento DSLT:
Nome campo
Valore campo
Piattaforma
Software Cisco serie 4300, 4400 ISR o Catalyst 8000V Edge
Prodotto
CUBE Enterprise in Webex Calling
Ambito del problema
Registri di sistema
Tipo di problema
Syslog - %VOICE_IEC-3-GW: CCAPI: Internal Error (Call spike threshold): IEC=1.1.181.1.29.0
-
Copia i file XML DS nel gateway locale.
copy ftp://username:password@/DS_64224.xml bootflash: copy ftp://username:password@/DS_65095.xml bootflash:
-
Installare il file XML DS 64224 e quindi DS 65095 per il monitoraggio elevato della CPU nel gateway locale.
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
-
Verifica che la firma sia installata correttamente utilizzando il comando show call-home diagnostic-signature. La colonna dello stato deve contenere il valore "registered".
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
Firme digitali scaricate:
ID DS
Nome DS
Revisione
Stato
Ultimo aggiornamento (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Registrato
2020-11-08:00:07:45
65095
00:12:53
DS_LGW_IEC_Call_spike_threshold
0.0.12
Registrato
2020-11-08:00:12:53
Verifica esecuzione firme diagnostiche
Nel comando seguente, la colonna "Status" (Stato) del comando show call-home diagnostic-signature changes to "running" (In esecuzione) mentre il gateway locale esegue l'azione definita all'interno della firma. L'output delle statistiche della firma diagnostica della chiamata a casa è il modo migliore per verificare se una firma diagnostica rileva un evento di interesse ed ha eseguito l'azione. La colonna "Attivata/Max/Disattivazione" indica il numero di volte in cui la firma specificata ha attivato un evento, il numero massimo di volte in cui viene definito per rilevare un evento e se la firma si autoinstalla dopo aver rilevato il numero massimo di eventi attivati.
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
Firme digitali scaricate:
ID DS |
Nome DS |
Revisione |
Stato |
Ultimo aggiornamento (GMT+00:00) |
---|---|---|---|---|
64224 |
DS_LGW_CPU_MON75 |
0.0.10 |
Registrato |
2020-11-08 00:07:45 |
65095 |
DS_LGW_IEC_Call_spike_threshold |
0.0.12 |
In esecuzione |
2020-11-08 00:12:53 |
mostra statistiche firma diagnostica-chiamata in home
ID DS |
Nome DS |
Innescato/Max/Deinstall |
Tempo di esecuzione medio (secondi) |
Tempo di esecuzione massimo (secondi) |
---|---|---|---|---|
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 |
Il e-mail di notifica inviato durante l'esecuzione della firma diagnostica contiene informazioni chiave come il tipo di problema, i dettagli del dispositivo, la versione del software, l'esecuzione della configurazione e la visualizzazione degli output dei comandi correlati alla risoluzione del problema.

Disinstallare le firme diagnostiche
Per la risoluzione dei problemi, utilizzare le firme diagnostiche da disinstallare dopo il rilevamento di alcune occorrenze di problemi. Se si desidera disinstallare manualmente una firma, recuperare l'ID DS dall'output di show call-home diagnostic-signature ed eseguire il seguente comando:
call-home diagnostic-signature deinstall
Esempio:
call-home diagnostic-signature deinstall 64224
Nuove firme vengono aggiunte periodicamente nello strumento di ricerca delle firme diagnostiche, in base ai problemi che vengono osservati nelle distribuzioni. Il TAC attualmente non supporta richieste di creazione di nuove firme personalizzate.