Configurazione del gateway locale su Cisco IOS XE per Webex Calling
Panoramica
Webex Calling supporta attualmente due versioni del gateway locale:
-
Gateway locale
-
Gateway locale per Webex per il Settore pubblico
-
Prima di iniziare, comprendi i requisiti di rete telefonica commutata pubblica (PSTN) e gateway locale (LGW) in sede 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 o una distribuzione CUBE Enterprise esistente da utilizzare come funzione gateway locale per Webex Calling, prestare attenzione alla configurazione. Assicurarsi di non interrompere i flussi di chiamata e la funzionalità esistenti a causa delle modifiche apportate.
Le procedure contengono collegamenti alla documentazione di riferimento dei comandi in cui è possibile ottenere ulteriori informazioni sulle singole opzioni di comando. Tutti i collegamenti di riferimento ai comandi vanno a Riferimento comando Webex Managed Gateways se non diversamente specificato (nel qual caso, i collegamenti ai comandi vanno a Riferimento comando vocale Cisco IOS). È possibile accedere a tutte queste guide nei Riferimenti ai comandi di Cisco Unified Border Element.
Per informazioni sugli SBC di terze parti supportati, consultare la relativa documentazione di riferimento del prodotto.
Esistono due opzioni per configurare il gateway locale per il Webex Calling trunk:
-
Trunk basato sulla registrazione
-
Trunk basato su certificato
Usa il flusso di attività in Gateway locale basato su registrazione o Gateway locale basato su certificato per configurare il gateway locale per il trunk Webex Calling.
Vedi Introduzione al gateway locale per ulteriori informazioni sui diversi tipi di trunk. Effettuare le seguenti operazioni sul gateway locale, utilizzando l'interfaccia della riga di comando (CLI). Utilizziamo il protocollo SIP (Session Initiation Protocol) e il trasporto TLS (Transport Layer Security) per proteggere il trunk e il protocollo SRTP (Secure Real Time Protocol) per proteggere il contenuto multimediale tra il gateway locale e Webex Calling.
-
Seleziona CUBE come gateway locale. Webex for Government attualmente non supporta SBC (Session Border Controller) di terze parti. Per esaminare l'ultimo elenco, vedi Introduzione al gateway locale.
- Installare Cisco IOS XE Dublin 17.12.1a o versioni successive per tutti i gateway Webex per il governo locale.
-
Per esaminare l'elenco delle autorità di certificazione radice (CA) supportate da Webex for Government, vedere Autorità di certificazione radice per Webex for Government.
-
Per dettagli sugli intervalli di porte esterne per il gateway locale in Webex per il Settore pubblico, vedi Requisiti di rete per Webex per il Settore pubblico (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, utilizza la seguente opzione:
-
Trunk basato su certificato
Usa il flusso di attività sotto il Gateway locale basato su certificato per configurare il gateway locale per il trunk Webex Calling. Per ulteriori dettagli su come configurare un gateway locale basato su certificato, vedi Configurazione del trunk basato su certificato Webex Calling.
È obbligatorio configurare crittografie GCM conformi a FIPS per supportare il gateway locale per Webex per il Settore pubblico. In caso contrario, l'impostazione della chiamata non riesce. Per dettagli di configurazione, vedi Configurazione del 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 indirizzate a Webex Calling e tutte le chiamate da Webex Calling vengono indirizzate alla PSTN. L'immagine seguente evidenzia questa soluzione e la configurazione di indirizzamento chiamata di alto livello che verrà seguita.
In questo progetto, vengono utilizzate le seguenti configurazioni principali:
-
tenant della classe vocale: Utilizzato per creare configurazioni specifiche del trunk.
-
URI classe vocale: Utilizzato per classificare i messaggi SIP per la selezione di un dial-peer in entrata.
-
dial-peer in entrata: Fornisce il trattamento dei 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 di chiamata successivo.
-
dial-peer in uscita: Fornisce il trattamento per i messaggi SIP in uscita e li indirizza alla destinazione richiesta.
![Indirizzamento chiamata da/a PSTN a/da soluzione di configurazione Webex Calling](https://cisco-api.ingeniuxondemand.com/DITA/content/en/us/td/i/400001-500000/470001-480000/479001-480000/479480.png)
Sebbene IP e SIP siano diventati i protocolli predefiniti per trunk PSTN, i circuiti ISDN TDM (Time Division Multiplexing) sono ancora ampiamente utilizzati e sono supportati con trunk Webex Calling. Per abilitare l'ottimizzazione multimediale dei percorsi IP per gateway locali con flussi di chiamata TDM-IP, è attualmente necessario utilizzare un processo di instradamento delle chiamate a due segmenti. Questo approccio modifica la configurazione di indirizzamento chiamata mostrata sopra, introducendo una serie di dial-peer loop-back interni tra Webex Calling e trunk PSTN come illustrato nell'immagine seguente.
![Configurazione dell'indirizzamento chiamata con una serie di dial-peer loop-back interni tra Webex Calling e trunk PSTN](https://cisco-api.ingeniuxondemand.com/DITA/content/en/us/td/i/400001-500000/480001-490000/482001-483000/482796.png)
Quando si connette una soluzione Cisco Unified Communications Manager in sede 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 l'indirizzamento e il trattamento centralizzati di tutte le chiamate PSTN e Webex Calling.
![Il diagramma della soluzione che mostra Unified Communications Manager fornisce l'indirizzamento e il trattamento centralizzati di tutte le chiamate PSTN e Webex Calling](https://cisco-api.ingeniuxondemand.com/DITA/content/en/us/td/i/400001-500000/470001-480000/479001-480000/479481.png)
In questo documento vengono utilizzati i nomi host, gli indirizzi IP e le interfacce illustrati nell'immagine seguente.
![Nomi host, indirizzi IP e interfacce utilizzati nelle soluzioni di configurazione dell'indirizzamento chiamata](https://cisco-api.ingeniuxondemand.com/DITA/content/en/us/td/i/400001-500000/480001-490000/482001-483000/482562.png)
Usa le indicazioni sulla configurazione nel resto di questo documento per completare la configurazione del gateway locale come segue:
-
Passaggio 1: Configurare la connettività e la sicurezza di base del router
-
Passaggio 2: Configura trunk Webex Calling
A seconda dell'architettura richiesta, seguire una delle seguenti opzioni:
-
Passaggio 3: Configurazione del gateway locale con trunk PSTN SIP
-
Passaggio 4: Configurazione del gateway locale con un ambiente Unified CM esistente
Oppure:
-
Passaggio 3: Configurazione del gateway locale con trunk PSTN TDM
Configurazione base
Il primo passo per preparare il router Cisco come gateway locale per Webex Calling è creare una configurazione di base che garantisca la piattaforma e stabilisca la connettività.
-
Tutte le distribuzioni del gateway locale basate sulla registrazione richiedono Cisco IOS XE 17.6.1a o versioni successive. È consigliabile Cisco IOS 17.12.2 o versioni successive. Per le versioni consigliate, vedere la pagina Ricerca software Cisco . Ricercare la piattaforma e selezionare una delle release suggerite .
-
I router serie ISR4000 devono essere configurati con licenze di tecnologia Unified Communications e Security.
-
I router Catalyst Edge serie 8000 dotati di schede vocali o DSP richiedono licenze DNA Advantage. I router senza schede vocali o DSP richiedono un minimo di licenze DNA Essentials.
-
-
Crea una configurazione di base per la tua piattaforma che segua i criteri 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 nel gateway locale.
Configurazione
1 |
Assicurarsi di assegnare indirizzi IP validi e indirizzabili a qualsiasi interfaccia Layer 3, ad esempio:
|
2 |
Proteggere le credenziali di registrazione e STUN sul router utilizzando la crittografia simmetrica. Configurare la chiave di crittografia principale e il tipo di crittografia come segue:
|
3 |
Crea un trustpoint PKI segnaposto. Richiede questo trustpoint per configurare TLS in seguito. Per trunk basati su registrazione, questo trustpoint non richiede un certificato, come sarebbe richiesto per un trunk basato su certificato. |
4 |
Abilitare l'esclusività TLS1.2 e specificare il trustpoint predefinito utilizzando i seguenti comandi di configurazione. È inoltre necessario aggiornare i parametri di trasporto per garantire una connessione affidabile e sicura per l'iscrizione: Il comando server cn-san-validate assicura che il gateway locale consenta una connessione se il nome host configurato nel tenant 200 è incluso nei campi CN o SAN del certificato ricevuto dal proxy in uscita.
|
5 |
Installa il bundle CA radice Cisco, che include il certificato CA DigiCert utilizzato da Webex Calling. Utilizzare il comando Crypto pki trustpool importa URL pulito per scaricare il bundle di CA radice dall'URL specificato e per cancellare il pool di attendibilità CA corrente, 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 proxy-porta 80 |
1 |
Creare un trunk PSTN basato sulla registrazione per una posizione esistente in Control Hub. Prendi nota delle informazioni sul trunk fornite una volta creato il trunk. I dettagli evidenziati nell'illustrazione vengono utilizzati nelle fasi di configurazione di questa guida. Per ulteriori informazioni, vedi Configurazione di trunk, gruppi di indirizzamento e piani di chiamata per Webex Calling. ![]() |
2 |
Inserisci i seguenti comandi per configurare CUBE come gateway locale Webex Calling: Di seguito una spiegazione dei campi per la configurazione:
Abilita le funzioni CUBE (Cisco Unified Border Element) sulla piattaforma. statistiche multimedialiAbilita il monitoraggio multimediale sul gateway locale. statistiche in massa multimedialiConsente al controllo di controllare il sondaggio dei dati per le statistiche sulle chiamate in massa. Per ulteriori informazioni su questi comandi, vedere Contenuto multimediale. consenti-connessioni sip a SIPAbilitare la funzionalità agente utente back-to-back SIP di base CUBE. Per ulteriori informazioni, vedi Consenti connessioni. Per impostazione predefinita, il trasporto fax T.38 è abilitato. Per ulteriori informazioni, vedi 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. payload asimmetrico pienoConfigura il supporto del payload asimmetrico SIP per payload DTMF e codec dinamico. Per ulteriori informazioni, vedi payload asimmetrico. offerta anticipata forzataForza il gateway locale a inviare informazioni SDP nel messaggio di invito iniziale anziché attendere il riconoscimento dal peer adiacente. Per ulteriori informazioni su questo comando, vedere offerta anticipata. |
3 |
Configura voice class codec 100 consentendo codec G.711 solo per tutti i trunk. Questo approccio semplice è adatto alla maggior parte delle distribuzioni. Se richiesto, è possibile aggiungere all'elenco altri tipi di codec supportati da sistemi di origine e terminazione. Sono supportate soluzioni più complesse che coinvolgono la transcodifica utilizzando moduli DSP, ma non incluse in questa guida. Di seguito una spiegazione dei campi per la configurazione: codec classe vocale 100Utilizzato per consentire solo i codec preferiti per le chiamate trunk SIP. Per ulteriori informazioni, vedere codec della classe vocale. |
4 |
Configura stun-usage della classe vocale 100 per abilitare ICE sul trunk Webex Calling. Di seguito una spiegazione dei campi per la configurazione: utilizzo stun ice liteUtilizzato per abilitare ICE-Lite per tutti i dial-peer rivolti verso Webex Calling per consentire l'ottimizzazione multimediale ove possibile. Per ulteriori informazioni, vedere utilizzo della classe vocale stun e stun usage ice lite. L'ottimizzazione multimediale viene negoziata ove possibile. Se una chiamata richiede servizi multimediali su cloud, come la registrazione, il supporto non può essere ottimizzato. |
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 offerta CUBE suite di crittografia SRTP nel valore SDP nei messaggi di offerta e risposta. Webex Calling supporta solo SHA1_80. Per ulteriori informazioni, vedere classe vocale srtp-crypto. |
6 |
Configura una sequenza per identificare le chiamate a un trunk del gateway locale in base al relativo parametro di trunk di destinazione: Di seguito una spiegazione dei campi per la configurazione: uri classe vocale 100 sipDefinisce uno schema per associare un invito SIP in ingresso a un dial-peer di trunk in arrivo. Quando si immette questo schema, utilizzare dtg= seguito dal valore OTG/DTG del trunk fornito in Control Hub quando è stato creato il trunk. Per ulteriori informazioni, vedere URI della classe vocale. |
7 |
Configurare 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 di Stati Uniti o Canada può offrire la verifica dell'ID chiamante per le chiamate di spam e frode, con la configurazione aggiuntiva menzionata nell'articolo Indicazione di chiamata spam o frode in Webex Calling . |
8 |
Configura trunk Webex Calling: |
Dopo aver definito il tenant 100 e configurato un dial-peer SIP VoIP, il gateway avvia una connessione TLS verso Webex Calling. A questo punto, l'SBC di accesso presenta il proprio 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 permanente tra il gateway locale e il controller SBC di accesso a Webex Calling. Il gateway locale può quindi utilizzare questa connessione sicura per eseguire la registrazione con il controller SBC di accesso a Webex. Quando viene richiesta la registrazione per l'autenticazione:
-
Nella risposta vengono utilizzati i parametri nome utente, password e area di autenticazione della configurazione credenziali .
-
Le regole di modifica nel profilo SIP 100 vengono utilizzate per convertire nuovamente l'URL SIPS in SIP.
La registrazione è riuscita quando viene ricevuto un 200 OK dal controller SBC di accesso.
Una volta creato un trunk verso Webex Calling precedente, utilizza la seguente configurazione per creare un trunk non crittografato verso un provider PSTN basato su SIP:
Se il provider di servizi offre un trunk PSTN sicuro, puoi seguire una configurazione simile come descritto sopra per il trunk Webex Calling. CUBE supporta l'instradamento sicuro delle chiamate.
Se utilizzi un trunk PSTN TDM/ISDN, passa alla sezione successiva Configurazione del gateway locale con trunk PSTN TDM.
Per configurare le interfacce TDM per i segmenti di chiamata PSTN sui gateway Cisco TDM-SIP, vedi Configurazione del PRI ISDN.
1 |
Configura il seguente URI della classe vocale per identificare le chiamate in entrata dal trunk PSTN: Di seguito una spiegazione dei campi per la configurazione: classe vocale uri 200 sipDefinisce uno schema per associare un invito SIP in ingresso a un dial-peer di trunk in arrivo. Quando si immette questo schema, utilizzare l'indirizzo IP del gateway PSTN IP. Per ulteriori informazioni, vedere URI della classe vocale. |
2 |
Configurare il seguente dial-peer IP PSTN: Di seguito una spiegazione dei campi per la configurazione: Descrizione Definisce un dial-peer VoIP con un tag 200 e fornisce una descrizione significativa per facilità di gestione e risoluzione dei problemi. Per ulteriori informazioni, vedi Chiamata vocale peer. schema di destinazione SCADENTE.SCADENTEÈ richiesto un percorso di destinazione fittizio quando si indirizzano le chiamate in uscita utilizzando un gruppo di dial-peer in entrata. In questo caso è possibile utilizzare qualsiasi modello di destinazione valido. Per ulteriori informazioni, vedere percorso di destinazione (interfaccia). protocollo sessione sipv2Specifica che questo dial-peer gestisce i segmenti di chiamata SIP. Per ulteriori informazioni, vedere protocollo sessione (dial peer). ipv4 destinazione sessione: 192.168.80.13Specifica l'indirizzo di destinazione per le chiamate inviate al provider PSTN. Può essere un indirizzo IP o un nome host DNS. Per ulteriori informazioni, vedi destinazione sessione (peer di chiamata VoIP). URI in ingresso tramite 200Specifica la classe vocale utilizzata per associare le chiamate in ingresso a questo dial-peer utilizzando INVITE VIA URI intestazione. Per ulteriori informazioni, vedi URL in ingresso. classe vocale sip asserted-id pai
(Opzionale) Attiva l'elaborazione dell'intestazione P-Asserted-Identity e controlla come viene utilizzata per il trunk PSTN. Se si utilizza questo comando, l'identità della parte chiamante fornita dal dial-peer in ingresso viene utilizzata per le intestazioni From e P-Asserted-Identity in uscita. Se questo comando non viene utilizzato, l'identità della parte chiamante fornita dal dial-peer in ingresso viene utilizzata per le intestazioni da e ID parte remota in uscita. Per ulteriori informazioni, vedere voice-class sip asserted-id. associazione interfaccia origine di controllo GigabitEthernet0/0/0
Configura l'interfaccia di origine e l'indirizzo IP associato per i messaggi inviati al PSTN. Per ulteriori informazioni, vedi associazione. associa interfaccia origine multimediale GigabitEthernet0/0/0Configura l'interfaccia di origine e l'indirizzo IP associato per il contenuto multimediale inviato a PSTN. Per ulteriori informazioni, vedi associazione. codec della classe vocale 100Configura il dial-peer per utilizzare l'elenco di filtri codec comuni 100. Per ulteriori informazioni, vedere codec della classe vocale. dtmf-relay rtp-nteDefinisce RTP-NTE (RFC2833) come funzionalità DTMF prevista sul modello della chiamata. Per ulteriori informazioni, vedere Inoltro DTMF (Voice over IP). nessun vadDisabilita il rilevamento dell'attività vocale. Per ulteriori informazioni, vedi vad (dial peer). |
3 |
Se stai configurando il gateway locale per indirizzare solo le chiamate tra Webex Calling e la PSTN, aggiungi la seguente configurazione di indirizzamento chiamata. Se si sta configurando il gateway locale con una piattaforma Unified Communications Manager, passare alla sezione successiva. |
Una volta creato un trunk verso Webex Calling, utilizza la seguente configurazione per creare un trunk TDM per il servizio PSTN con instradamento delle chiamate loop-back per consentire l'ottimizzazione multimediale sul segmento di chiamata Webex.
Se non si richiede l'ottimizzazione multimediale IP, seguire la procedura 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 del dial-peer loop-back utilizza gruppi di dial-peer e tag di indirizzamento chiamata per garantire che le chiamate passino correttamente tra Webex e la PSTN, senza creare loop di indirizzamento chiamata. Configura le seguenti regole di traduzione che verranno utilizzate per aggiungere e rimuovere i tag di indirizzamento chiamata: Di seguito una spiegazione dei campi per la configurazione: regola di traduzione vocaleUtilizza le espressioni regolari definite nelle regole per aggiungere o rimuovere i tag di indirizzamento chiamata. Le cifre over-decennali (‘A’) vengono utilizzate per aggiungere chiarezza per la risoluzione dei problemi. In questa configurazione, il tag aggiunto dal profilo di traduzione 100 viene utilizzato per guidare le chiamate da Webex Calling verso la PSTN tramite i dial-peer di loopback. Analogamente, il tag aggiunto dal profilo di traduzione 200 viene utilizzato per guidare le chiamate dalla PSTN verso Webex Calling. I profili di traduzione 11 e 12 rimuovono questi tag prima di consegnare le chiamate rispettivamente ai trunk Webex e PSTN. Questo esempio presuppone che i numeri chiamati di Webex Calling siano presentati in formato +E.164. La regola 100 rimuove il + iniziale per mantenere un numero chiamato valido. La regola 12 aggiunge una o più cifre di indirizzamento nazionale o internazionale quando si rimuove il tag. Utilizzare le cifre corrispondenti al piano di numerazione nazionale ISDN locale. Se Webex Calling presenta numeri in formato nazionale, regola le regole 100 e 12 per aggiungere e rimuovere semplicemente il tag di indirizzamento rispettivamente. Per ulteriori informazioni, vedi Profilo traduzione vocale e Regola traduzione vocale. |
2 |
Configurare le porte dell'interfaccia vocale TDM come richiesto dal tipo di trunk e dal protocollo utilizzato. Per ulteriori informazioni, vedi Configurazione del PRI ISDN. Ad esempio, la configurazione di base di un'interfaccia ISDN a velocità primaria installata nello slot NIM 2 di un dispositivo potrebbe includere quanto segue: |
3 |
Configurare il seguente dial-peer PSTN TDM: Di seguito una spiegazione dei campi per la configurazione: Definisce un dial-peer VoIP con un tag 200 e fornisce una descrizione significativa per facilità di gestione e risoluzione dei problemi. Per ulteriori informazioni, vedi Chiamata vocale peer. schema di destinazione SCADENTE.SCADENTEÈ richiesto un percorso di destinazione fittizio quando si indirizzano le chiamate in uscita utilizzando un gruppo di dial-peer in entrata. In questo caso è possibile utilizzare qualsiasi modello di destinazione valido. Per ulteriori informazioni, vedere percorso di destinazione (interfaccia). profilo di traduzione in ingresso 200Assegna il profilo di traduzione che aggiungerà un tag di indirizzamento chiamata al numero chiamato in arrivo. quadrante diretto verso l'internoIndirizza la chiamata senza fornire un segnale di linea secondario. Per ulteriori informazioni, vedere Direct-Inward-Dial. porta 0/2/0:15La porta vocale fisica associata a questo dial-peer. |
4 |
Per abilitare l'ottimizzazione multimediale dei percorsi IP per gateway locali con flussi di chiamata TDM-IP, puoi modificare l'indirizzamento delle chiamate introducendo una serie di dial-peer loop-back interni tra Webex Calling e trunk PSTN. Configurare i seguenti dial-peer di richiamata loop-back. In questo caso, tutte le chiamate in ingresso verranno indirizzate inizialmente al dial-peer 10 e da lì al dial-peer 11 o 12 in base al tag di indirizzamento applicato. Dopo la rimozione del tag di indirizzamento, le chiamate verranno inoltrate al trunk in uscita utilizzando gruppi di dial-peer. Di seguito una spiegazione dei campi per la configurazione: Definisce un dial-peer VoIP e fornisce una descrizione significativa per facilità di gestione e risoluzione dei problemi. Per ulteriori informazioni, vedi Chiamata vocale peer. profilo di traduzione in ingresso 11Applica il profilo di traduzione definito in precedenza per rimuovere il tag di indirizzamento chiamata prima di passare al trunk in uscita. schema di destinazione SCADENTE.SCADENTEÈ richiesto un percorso di destinazione fittizio quando si indirizzano le chiamate in uscita utilizzando un gruppo di dial-peer in entrata. Per ulteriori informazioni, vedere percorso di destinazione (interfaccia). protocollo sessione sipv2Specifica che questo dial-peer gestisce i segmenti di chiamata SIP. Per ulteriori informazioni, vedere protocollo sessione (dial peer). ipv4 destinazione sessione: 192.168.80.14Specifica l'indirizzo dell'interfaccia del router locale come destinazione di chiamata a loop-back. Per ulteriori informazioni, vedi destinazione sessione (peer di chiamata VoIP). associazione interfaccia origine di controllo GigabitEthernet0/0/0Configura l'interfaccia di origine e l'indirizzo IP associato per i messaggi inviati attraverso il loop-back. Per ulteriori informazioni, vedi associazione. associa interfaccia origine multimediale GigabitEthernet0/0/0Configura l'interfaccia di origine e l'indirizzo IP associato per il contenuto multimediale inviato attraverso il loop-back. Per ulteriori informazioni, vedi associazione. dtmf-relay rtp-nteDefinisce RTP-NTE (RFC2833) come funzionalità DTMF prevista sul modello della chiamata. Per ulteriori informazioni, vedere Inoltro DTMF (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 companding utilizzato dal servizio ISDN. nessun vadDisabilita il rilevamento dell'attività vocale. Per ulteriori informazioni, vedi vad (dial peer). |
5 |
Aggiungere la seguente configurazione di indirizzamento chiamata: Questa operazione termina la configurazione del gateway locale. Salva la configurazione e ricarica la piattaforma se questa è la prima volta che vengono configurate le funzioni CUBE.
|
La configurazione PSTN-Webex Calling nelle sezioni precedenti può essere modificata per includere trunk aggiuntivi a un cluster Cisco Unified Communications Manager (UCM). In questo caso, tutte le chiamate vengono indirizzate tramite Unified CM. Le chiamate da UCM sulla porta 5060 vengono indirizzate alla PSTN e le chiamate dalla porta 5065 vengono indirizzate a Webex Calling. Le seguenti configurazioni incrementali possono essere aggiunte per includere questo scenario di chiamata.
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 di inviare messaggi in ingresso sulla porta 5065 e inserire nell'intestazione VIA questo valore quando si inviano messaggi al gateway locale.
![Inserisci le informazioni sul profilo di sicurezza SIP Trunk](https://cisco-api.ingeniuxondemand.com/DITA/content/en/us/td/i/400001-500000/480001-490000/483001-484000/483179.png)
1 |
Configura i seguenti URI di classe vocale: |
2 |
Configurare i seguenti record DNS per specificare l'indirizzamento 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 si preferisce utilizzare il DNS, non sono necessarie queste configurazioni locali. Di seguito una spiegazione dei campi per la configurazione: Il comando seguente crea un record di risorse DNS SRV. Creare un record per ciascun host e trunk UCM: host IP _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.dominio.com _sip._udp.pstntocucm.io: Nome record risorse SRV 2: Priorità record risorse SRV 1: Il peso record risorsa SRV 5060: Il numero di porta da utilizzare per l'host di destinazione in questo record risorsa ucmsub5.mydomain.com: L'host di destinazione del record delle risorse Per risolvere i nomi host di destinazione dei record di risorse, creare record DNS A locali. Ad esempio: host ip ucmsub5.mydomain.com 192.168.80.65 host IP: Crea un record nel database IOS XE locale. ucmsub5.mydomain.com: Nome host record A. 192.168.80.65: Indirizzo IP dell'host. Creare i record delle risorse SRV e i record A per riflettere l'ambiente UCM e la strategia di distribuzione delle chiamate preferita. |
3 |
Configura i seguenti dial-peer: |
4 |
Aggiungi l'indirizzamento chiamata 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. Puoi anche installare le DS per automatizzare la raccolta dei dati diagnostici e trasferire i dati raccolti al caso Cisco TAC per accelerare il tempo 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 attraverso 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 in una posizione di rete fornita 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à. A ogni file DS viene assegnato un ID numerico univoco dal sistema. Lo strumento di ricerca delle firme diagnostiche (DSLT, Diagnostic Signatures Lookup Tool) è l'unica fonte per trovare le firme applicabili per il monitoraggio e la risoluzione di diversi 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.
-
Configura il server e-mail sicuro da utilizzare per inviare notifiche proattive se sul dispositivo è in esecuzione Cisco IOS XE 17.6.1a o versione successiva.
configura server di posta elettronica di chiamata-home :@ priorità 1 fine tls sicuro
-
Configura la variabile di ambiente ds_email con l'indirizzo e-mail dell'amministratore per notificare l'utente.
configura ambiente di firma chiamata-casa diagnostica-ambiente ds_email fine
Di seguito 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:
Si consiglia di utilizzare Cisco IOS XE Bengaluru 17.6.x o versioni successive.
call-home mail-server tacfaststart:password@smtp.gmail.com priorità 1 ambiente di firma diagnostica sicura tls 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:
-
Andare a Accesso app meno sicuro .
e attivare 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
Questa 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 %Agente SNMP non abilitato config t snmp-server manager end show snmp Chassis: Ingresso pacchetti SNMP ABCDEFGHIGK 149655 0 Errori di versione SNMP non validi 1 Nome comunità sconosciuto 0 Operazione illegale per il nome della comunità fornita 0 Errori di codifica 37763 Numero di variabili richieste 2 Numero di variabili alterate 34560 PDU Get-Request 138 PDU Get-Next 2 PDU di richiesta impostata 0 Interruzioni di pacchetti della coda di input (dimensione massima coda 1000) 158277 pacchetti SNMP in uscita 0 Errori troppo grandi (dimensione massima del pacchetto 1500) 20 Errori di nome non presenti 0 Errori di valori errati 0 Errori generali 7998 PDU risposta 10280 PDU trap Pacchetti attualmente in coda di input processo SNMP: 0 trap globali SNMP: abilitato
-
Scarica DS 64224 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
Prestazioni
Tipo di problema
Utilizzo elevato della CPU con notifica e-mail.
-
Copia il file XML DS nel flash del gateway locale.
LocalGateway# copia ftp://nomeutente:password@/DS_64224.xml bootflash:
L'esempio seguente mostra la copia del file da un server FTP al gateway locale.
copia ftp://utente:pwd@192.0.2.12/DS_64224.xml bootflash: Accesso a ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 bytes] 3571 byte copiati in 0,064 sec (55797 byte/sec)
-
Installa il file XML DS nel gateway locale.
call-home diagnostic-signature load DS_64224.xml File di caricamento DS_64224.xml riuscito
-
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".
mostra call-home diagnostic-signature Impostazioni di firma diagnostica correnti: Firma diagnostica: profilo abilitato: CiscoTAC-1 (stato: ACTIVE) URL di download: https://tools.cisco.com/its/service/oddce/services/DDCEService Variabile di ambiente: 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, reinstalla 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, viene generata una notifica e-mail e del registro di sistema e si disinstalla automaticamente dopo due occorrenze di annullamento della registrazione. Utilizza la procedura seguente per installare la firma:
-
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.
copia ftp://nomeutente:password@/DS_64117.xml bootflash:
-
Installa il file XML DS nel gateway locale.
call-home diagnostic-signature load DS_64117.xml File di caricamento DS_64117.xml riuscito 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
Questa DS utilizza il sondaggio SNMP ogni 10 minuti per rilevare la disconnessione di chiamata anomala con errori SIP 403, 488 e 503. Se il numero di errori è maggiore di o uguale a 5 dall'ultimo sondaggio, viene generata una notifica del registro di sistema ed e-mail. Utilizza la procedura seguente per installare la firma.
-
Utilizzare il comando show snmp per verificare se SNMP è abilitato. In caso contrario, configurare il comando snmp-server manager .
show snmp %Agente SNMP non abilitato config t snmp-server manager end show snmp Chassis: Ingresso pacchetti SNMP ABCDEFGHIGK 149655 0 Errori di versione SNMP non validi 1 Nome comunità sconosciuto 0 Operazione illegale per il nome della comunità fornita 0 Errori di codifica 37763 Numero di variabili richieste 2 Numero di variabili alterate 34560 PDU Get-Request 138 PDU Get-Next 2 PDU di richiesta impostata 0 Interruzioni di pacchetti della coda di input (dimensione massima coda 1000) 158277 pacchetti SNMP in uscita 0 Errori troppo grandi (dimensione massima del pacchetto 1500) 20 Errori di nome non presenti 0 Errori di valori errati 0 Errori generali 7998 PDU risposta 10280 PDU trap Pacchetti attualmente in coda di input processo SNMP: 0 trap globali SNMP: abilitato
-
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.
copia ftp://nomeutente:password@/DS_65221.xml bootflash:
-
Installa il file XML DS nel gateway locale.
call-home diagnostic-signature load DS_65221.xml File di caricamento DS_65221.xml riuscito
-
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, Diagnostic Signatures) eliminano la necessità di controllare manualmente la presenza del problema e rendono molto più semplice la risoluzione di 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:
-
Configura una variabile di ambiente DS aggiuntiva ds_fsurl_prefix che è il percorso del file server Cisco TAC (cxd.cisco.com) in cui vengono caricati i dati diagnostici raccolti. Il nome utente nel percorso file è il numero del caso e la password è il token di caricamento del file che può essere recuperato da Support Case Manager nel comando seguente. Il token di caricamento del file può essere generato nella sezione Allegati di Support Case Manager, come necessario.
configura l'ambiente LocalGateway(cfg-call-home-diag-sign)call-home-diagnostic-signature ds_fsurl_prefix "scp://:@cxd.cisco.com" fine
Esempio:
call-home diagnostic-signature environment ds_fsurl_prefix " ambiente ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"
-
Assicurarsi che SNMP sia abilitato utilizzando il comando show snmp . In caso contrario, configurare il comando snmp-server manager .
mostra snmp %Agente SNMP non abilitato config t snmp-server manager fine
-
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.
copia ftp://nomeutente:password@/DS_64224.xml bootflash: copia ftp://nomeutente: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 DS file di caricamento DS_64224.xml riuscito call-home diagnostic-signature load DS_65095.xml File di caricamento DS_65095.xml riuscito
-
Verifica che la firma sia installata correttamente utilizzando il comando show call-home diagnostic-signature . La colonna dello stato deve contenere un valore "registrato".
mostra call-home diagnostic-signature Impostazioni di firma diagnostica correnti: Firma diagnostica: profilo abilitato: CiscoTAC-1 (stato: ACTIVE) URL di download: https://tools.cisco.com/its/service/oddce/services/DDCEService Variabile di ambiente: 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 "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 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.
mostra call-home diagnostic-signature Impostazioni di firma diagnostica correnti: Firma diagnostica: profilo
abilitato: CiscoTAC-1 (stato: ACTIVE)
URL di download: https://tools.cisco.com/its/service/oddce/services/DDCEService Variabile di ambiente: 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 |
Attivato/Max/Disinstalla |
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 |
20/1/ANNO |
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 desideri disinstallare manualmente una firma, recupera l'ID DS dall'output del comando show call-home diagnostic-signature ed esegui il seguente comando:
disinstallazione firma diagnostica chiamata-home
Esempio:
disinstallazione firma diagnostica chiamata-home 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, si consiglia di eseguire l'iscrizione e gestire i gateway attraverso Control Hub. È una configurazione opzionale. Una volta eseguita l'iscrizione, puoi utilizzare l'opzione di convalida della configurazione in Control Hub per convalidare la configurazione del gateway locale e identificare eventuali problemi di configurazione. Al momento, solo i trunk basati su 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 mutual TLS (mTLS) 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 indirizzate a Webex Calling e tutte le chiamate da Webex Calling vengono indirizzate alla PSTN. L'immagine seguente evidenzia questa soluzione e la configurazione di indirizzamento chiamata di alto livello che verrà seguita.
In questo progetto, vengono utilizzate le seguenti configurazioni principali:
-
tenant della classe vocale: utilizzati per creare configurazioni specifiche del trunk.
-
URI classe vocale: Utilizzato per classificare i messaggi SIP per la selezione di un dial-peer in entrata.
-
dial-peer in entrata: Fornisce il trattamento dei 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 di chiamata successivo.
-
dial-peer in uscita: Fornisce il trattamento per i messaggi SIP in uscita e li indirizza alla destinazione richiesta.
![Indirizzamento chiamata da/a PSTN a/da soluzione di configurazione Webex Calling](https://cisco-api.ingeniuxondemand.com/DITA/content/en/us/td/i/400001-500000/470001-480000/479001-480000/479480.png)
Sebbene IP e SIP siano diventati i protocolli predefiniti per trunk PSTN, i circuiti ISDN TDM (Time Division Multiplexing) sono ancora ampiamente utilizzati e sono supportati con trunk Webex Calling. Per abilitare l'ottimizzazione multimediale dei percorsi IP per gateway locali con flussi di chiamata TDM-IP, è attualmente necessario utilizzare un processo di instradamento delle chiamate a due segmenti. Questo approccio modifica la configurazione di indirizzamento chiamata mostrata sopra, introducendo una serie di dial-peer loop-back interni tra Webex Calling e trunk PSTN come illustrato nell'immagine seguente.
![Configurazione dell'indirizzamento chiamata con una serie di dial-peer loop-back interni tra Webex Calling e trunk PSTN](https://cisco-api.ingeniuxondemand.com/DITA/content/en/us/td/i/400001-500000/480001-490000/482001-483000/482796.png)
Quando si connette una soluzione Cisco Unified Communications Manager in sede 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 l'instradamento e il trattamento centralizzati di tutte le chiamate PSTN e Webex Calling.
![Il diagramma della soluzione che mostra Unified Communications Manager fornisce l'indirizzamento e il trattamento centralizzati di tutte le chiamate PSTN e Webex Calling](https://cisco-api.ingeniuxondemand.com/DITA/content/en/us/td/i/400001-500000/470001-480000/479001-480000/479481.png)
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 opzionali, a meno che il bilanciamento del carico su più istanze CUBE.
![Nomi host, indirizzi IP e interfacce utilizzati nelle configurazioni dei gateway locali basati su certificato](https://cisco-api.ingeniuxondemand.com/DITA/content/en/us/td/i/400001-500000/470001-480000/479001-480000/479482.png)
Usa le indicazioni sulla configurazione nel resto di questo documento per completare la configurazione del gateway locale come segue:
-
Passaggio 1: Configurare la connettività e la sicurezza di base del router
-
Passaggio 2: Configura trunk Webex Calling
A seconda dell'architettura richiesta, seguire una delle seguenti opzioni:
-
Passaggio 3: Configurazione del gateway locale con trunk PSTN SIP
-
Passaggio 4: Configurazione del gateway locale con un ambiente Unified CM esistente
Oppure:
-
Passaggio 3: Configurazione del gateway locale con trunk PSTN TDM
Configurazione base
Il primo passo per preparare il router Cisco come gateway locale per Webex Calling è creare una configurazione di base che garantisca la piattaforma e stabilisca la connettività.
-
Tutte le distribuzioni del gateway locale basate su certificato richiedono Cisco IOS XE 17.9.1a o versioni successive. È consigliabile Cisco IOS XE 17.12.2 o versione successiva. Per le versioni consigliate, vedere la pagina Ricerca software Cisco . Ricercare la piattaforma e selezionare una delle release suggerite .
-
I router serie ISR4000 devono essere configurati con licenze di tecnologia Unified Communications e Security.
-
I router Catalyst Edge serie 8000 dotati di schede vocali o DSP richiedono licenze DNA Advantage. I router senza schede vocali o DSP richiedono un minimo di licenze DNA Essentials.
-
Per i requisiti di alta capacità, puoi anche richiedere una licenza HSEC (High Security) e un'autorizzazione per la velocità aggiuntiva.
Fare riferimento ai Codici autorizzazione per ulteriori dettagli.
-
-
Crea una configurazione di base per la tua piattaforma che segua i criteri 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 dei nomi di dominio completi (FQDN) del gateway locale o SRV (Service Record) configurati in Control Hub devono risolversi 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. Assicurarsi di aggiornare il firewall di conseguenza.
-
Segui la procedura di configurazione dettagliata fornita di seguito per installare un certificato firmato sul gateway locale:
-
Un'autorità di certificazione pubblica (CA), come specificato 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) dell'oggetto del certificato o uno dei nomi alternativi dell'oggetto (SAN) deve essere uguale al nome di dominio completo (FQDN) configurato in Control Hub. Ad esempio:
-
Se un trunk configurato nel Control Hub dell'organizzazione dispone di cube1.lgw.com:5061 come FQDN del gateway locale, il CN o SAN nel certificato del router deve contenere cube1.lgw.com.
-
Se un trunk configurato nel Control Hub dell'organizzazione dispone di lgws.lgw.com come indirizzo SRV dei gateway locali raggiungibili dal trunk, il CN o 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.
-
Se si utilizza un FQDN o SRV per il trunk, l'indirizzo di contatto per tutte le nuove finestre di dialogo SIP dal gateway locale deve utilizzare il nome configurato in Control Hub.
-
-
Assicurarsi che i certificati siano firmati per l'utilizzo su client e server.
-
-
Caricare il bundle CA radice Cisco nel gateway locale. Questo bundle include il certificato principale CA utilizzato per verificare la piattaforma Webex.
Configurazione
1 |
Assicurarsi di assegnare indirizzi IP validi e indirizzabili a qualsiasi interfaccia Layer 3, ad esempio:
|
2 |
Proteggere le credenziali STUN sul router utilizzando la crittografia simmetrica. Configurare la chiave di crittografia principale e il tipo di crittografia come segue: |
3 |
Creare un trustpoint di crittografia con un certificato per il dominio, firmato da un'autorità di certificazione (CA) supportata . |
4 |
Fornire il certificato della CA di firma intermedia, utilizzata per autenticare il certificato host. Immettere il seguente comando exec o di configurazione: crittografia
|
5 |
Importare il certificato organizzatore firmato utilizzando il seguente exec o comando di configurazione: crittografia
|
6 |
Abilitare l'esclusività TLS1.2 e specificare il trustpoint predefinito da utilizzare per le applicazioni vocali utilizzando i seguenti comandi di configurazione:
|
7 |
Installa il bundle CA radice Cisco, che include il certificato CA DigiCert utilizzato da Webex Calling. Utilizzare il comando Crypto pki trustpool import clean URL per scaricare il bundle di CA radice dall'URL specificato e per cancellare il pool di attendibilità CA corrente, 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 proxy-porta 80 |
1 |
Creare un trunk PSTN basato su certificato CUBE per una posizione esistente in Control Hub. Per ulteriori informazioni, vedi Configurazione di trunk, gruppi di indirizzamento e piani di chiamata per Webex Calling. Prendi nota delle informazioni sul trunk fornite una volta creato il trunk. Questi dettagli, come evidenziato nella figura riportata di seguito, verranno utilizzati nelle fasi di configurazione di questa guida. ![]() |
2 |
Inserisci i seguenti comandi per configurare CUBE come gateway locale Webex Calling: Di seguito una spiegazione dei campi per la configurazione:
Abilita le funzioni CUBE (Cisco Unified Border Element) sulla piattaforma. consenti-connessioni sip a SIPAbilitare la funzionalità agente utente ritorno su SIP base CUBE. Per ulteriori informazioni, vedi Consenti connessioni. Per impostazione predefinita, il trasporto fax T.38 è abilitato. Per ulteriori informazioni, vedi protocollo fax t38 (servizio vocale). Abilita STUN (Session Traversal of UDP through NAT) a livello globale. Questi comandi STUN globali sono richiesti solo quando si distribuisce il gateway locale dietro NAT.
Per ulteriori informazioni, vedere stun flowdata agent-id e stun flowdata shared-secret. payload asimmetrico pienoConfigura il supporto del payload asimmetrico SIP per payload DTMF e codec dinamico. Per ulteriori informazioni su questo comando, vedere payload asimmetrico. offerta anticipata forzataForza il gateway locale a inviare informazioni SDP nel messaggio di invito iniziale anziché attendere il riconoscimento dal peer adiacente. Per ulteriori informazioni su questo comando, vedere offerta anticipata. profili sip in ingressoConsente a CUBE di utilizzare profili SIP per modificare i messaggi man mano che vengono ricevuti. I profili vengono applicati tramite dial-peer o tenant. |
3 |
Configura voice class codec 100 consentendo codec G.711 solo per tutti i trunk. Questo approccio semplice è adatto alla maggior parte delle distribuzioni. Se richiesto, è possibile aggiungere all'elenco altri tipi di codec supportati da sistemi di origine e terminazione. Sono supportate soluzioni più complesse che coinvolgono la transcodifica utilizzando moduli DSP, ma non incluse in questa guida. Di seguito una spiegazione dei campi per la configurazione: codec classe vocale 100Utilizzato per consentire solo i codec preferiti per le chiamate trunk SIP. Per ulteriori informazioni, vedere codec della classe vocale. |
4 |
Configura stun-usage della classe vocale 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 stun ice liteUtilizzato per abilitare ICE-Lite per tutti i dial-peer rivolti verso Webex Calling per consentire l'ottimizzazione multimediale ove possibile. Per ulteriori informazioni, vedere utilizzo della classe vocale stun e stun usage ice lite. Il comando stun usage firewall-traversal flowdata è richiesto solo quando si distribuisce il gateway locale dietro NAT. L'ottimizzazione multimediale viene negoziata ove possibile. Se una chiamata richiede servizi multimediali su cloud, come la registrazione, il supporto non può essere ottimizzato. |
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 offerta CUBE suite di crittografia SRTP nel valore SDP nei messaggi di offerta e risposta. Webex Calling supporta solo SHA1_80. Per ulteriori informazioni, vedere classe vocale srtp-crypto. |
6 |
Configura crittografie GCM conformi a FIPS (questo passaggio è applicabile solo a Webex for Government). Di seguito una spiegazione dei campi per la configurazione: classe vocale srtp-crypto 100Specifica GCM come suite di crittografia offerta da CUBE. È obbligatorio configurare le crittografie GCM per il gateway locale per Webex for Government. |
7 |
Configura una sequenza per identificare in modo univoco le chiamate a un trunk del gateway locale in base al relativo FQDN o SRV di destinazione: Di seguito una spiegazione dei campi per la configurazione: uri classe vocale 100 sipDefinisce uno schema per associare un invito SIP in ingresso a un dial-peer di trunk in arrivo. Quando si immette questo schema, utilizzare il nome di dominio completo (FQDN) del trunk o l'SRV configurato in Control Hub per il trunk. |
8 |
Configurare i profili di manipolazione dei messaggi SIP. Se il gateway è configurato con un indirizzo IP pubblico, configurare un profilo come segue o passare al passaggio successivo se si utilizza la tecnologia NAT. In questo esempio, cube1.lgw.com è il nome di dominio completo (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' in una richiesta SIP e i messaggi di risposta devono contenere il valore predisposto per il trunk in Control Hub. Questo sarà il nome FQDN di un singolo host o il nome SRV utilizzato per un cluster di dispositivi. |
9 |
Se il gateway è configurato con un indirizzo IP privato dietro la NAT statica, configurare i profili SIP in entrata e in uscita come segue. In questo esempio, cube1.lgw.com è il nome di dominio completo configurato per il gateway locale, "10.80.13.12" è l'indirizzo IP dell'interfaccia rivolto verso Webex Calling e "192.65.79.20" è l'indirizzo IP NAT pubblico. Profili SIP per messaggi in uscita alla classe vocale 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 SIP e risposte deve contenere il valore predisposto per il trunk in Control Hub. Questo sarà il nome FQDN di un singolo host o il nome SRV utilizzato per un cluster di dispositivi. regole da 30 a 81Converti i riferimenti di indirizzi privati nell'indirizzo pubblico esterno per il sito, consentendo a Webex di interpretare e indirizzare correttamente i messaggi successivi. Profilo SIP per messaggi in entrata 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 profili SIP della classe vocale. Il provider PSTN di Stati Uniti o Canada può offrire la verifica dell'ID chiamante per le chiamate di spam e frode, con la configurazione aggiuntiva menzionata nell'articolo Indicazione di chiamata spam o frode in Webex Calling . |
10 |
Configurare un keepalive di opzioni SIP con profilo di modifica dell'intestazione. Di seguito una spiegazione dei campi per la configurazione: classe vocale sip-options-keepalive 100Configura un profilo keepalive e accede alla modalità di configurazione della classe vocale. È possibile configurare il tempo (in secondi) in cui un Ping delle opzioni fuori finestra di dialogo SIP viene inviato alla destinazione di chiamata quando la connessione heartbeat all'endpoint è in stato UP o Down. Questo profilo keepalive viene attivato dal dial-peer configurato verso Webex. Per assicurarsi che le intestazioni dei contatti includano il nome di dominio completo SBC, viene utilizzato il profilo SIP 115. Le regole 30, 40 e 50 sono obbligatorie solo se il controller SBC è configurato dietro NAT statico. In questo esempio, cube1.lgw.com è il nome di dominio completo selezionato per il gateway locale e, se viene utilizzato NAT statico, "10.80.13.12" è l'indirizzo IP dell'interfaccia SBC verso Webex Calling e "192.65.79.20" è l'indirizzo IP pubblico NAT. |
11 |
Configura trunk Webex Calling: |
Una volta creato un trunk verso Webex Calling precedente, utilizza la seguente configurazione per creare un trunk non crittografato verso un provider PSTN basato su SIP:
Se il provider di servizi offre un trunk PSTN sicuro, puoi seguire una configurazione simile come descritto sopra per il trunk Webex Calling. CUBE supporta l'instradamento sicuro delle chiamate.
Se utilizzi un trunk PSTN TDM/ISDN, passa alla sezione successiva Configurazione del gateway locale con trunk PSTN TDM.
Per configurare le interfacce TDM per i segmenti di chiamata PSTN sui gateway Cisco TDM-SIP, vedi Configurazione del PRI ISDN.
1 |
Configura il seguente URI della classe vocale per identificare le chiamate in entrata dal trunk PSTN: Di seguito una spiegazione dei campi per la configurazione: classe vocale uri 200 sipDefinisce uno schema per associare un invito SIP in ingresso a un dial-peer di trunk in arrivo. Quando si immette questo schema, utilizzare l'indirizzo IP del gateway PSTN IP. Per ulteriori informazioni, vedere URI della classe vocale. |
2 |
Configurare il seguente dial-peer IP PSTN: Di seguito una spiegazione dei campi per la configurazione: Descrizione Definisce un dial-peer VoIP con un tag 200 e fornisce una descrizione significativa per facilità di gestione e risoluzione dei problemi. Per ulteriori informazioni, vedi Chiamata vocale peer. schema di destinazione SCADENTE.SCADENTEÈ richiesto un percorso di destinazione fittizio quando si indirizzano le chiamate in uscita utilizzando un gruppo di dial-peer in entrata. In questo caso è possibile utilizzare qualsiasi modello di destinazione valido. Per ulteriori informazioni, vedere percorso di destinazione (interfaccia). protocollo sessione sipv2Specifica che questo dial-peer gestisce i segmenti di chiamata SIP. Per ulteriori informazioni, vedere protocollo sessione (dial peer). ipv4 destinazione sessione: 192.168.80.13Specifica l'indirizzo di destinazione per le chiamate inviate al provider PSTN. Può essere un indirizzo IP o un nome host DNS. Per ulteriori informazioni, vedi destinazione sessione (peer di chiamata VoIP). URI in ingresso tramite 200Specifica la classe vocale utilizzata per associare le chiamate in ingresso a questo dial-peer utilizzando INVITE VIA URI intestazione. Per ulteriori informazioni, vedi URL in ingresso. classe vocale sip asserted-id pai
(Opzionale) Attiva l'elaborazione dell'intestazione P-Asserted-Identity e controlla come viene utilizzata per il trunk PSTN. Se si utilizza questo comando, l'identità della parte chiamante fornita dal dial-peer in ingresso viene utilizzata per le intestazioni From e P-Asserted-Identity in uscita. Se questo comando non viene utilizzato, l'identità della parte chiamante fornita dal dial-peer in ingresso viene utilizzata per le intestazioni da e ID parte remota in uscita. Per ulteriori informazioni, vedere voice-class sip asserted-id. associazione interfaccia origine di controllo GigabitEthernet0/0/0
Configura l'interfaccia di origine e l'indirizzo IP associato per i messaggi inviati al PSTN. Per ulteriori informazioni, vedi associazione. associa interfaccia origine multimediale GigabitEthernet0/0/0Configura l'interfaccia di origine e l'indirizzo IP associato per il contenuto multimediale inviato a PSTN. Per ulteriori informazioni, vedi associazione. codec della classe vocale 100Configura il dial-peer per utilizzare l'elenco di filtri dei codec comuni 100. Per ulteriori informazioni, vedere codec della classe vocale. dtmf-relay rtp-nteDefinisce RTP-NTE (RFC2833) come funzionalità DTMF prevista sul modello della chiamata. Per ulteriori informazioni, vedere Inoltro DTMF (Voice over IP). nessun vadDisabilita il rilevamento dell'attività vocale. Per ulteriori informazioni, vedi vad (dial peer). |
3 |
Se stai configurando il gateway locale per indirizzare solo le chiamate tra Webex Calling e la PSTN, aggiungi la seguente configurazione di indirizzamento chiamata. Se si sta configurando il gateway locale con una piattaforma Unified Communications Manager, passare alla sezione successiva. |
Una volta creato un trunk verso Webex Calling, utilizza la seguente configurazione per creare un trunk TDM per il servizio PSTN con instradamento delle chiamate loop-back per consentire l'ottimizzazione multimediale sul segmento di chiamata Webex.
Se non si richiede l'ottimizzazione multimediale IP, seguire la procedura 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 del dial-peer loop-back utilizza gruppi di dial-peer e tag di indirizzamento chiamata per garantire che le chiamate passino correttamente tra Webex e la PSTN, senza creare loop di indirizzamento chiamata. Configura le seguenti regole di traduzione che verranno utilizzate per aggiungere e rimuovere i tag di indirizzamento chiamata: Di seguito una spiegazione dei campi per la configurazione: regola di traduzione vocaleUtilizza le espressioni regolari definite nelle regole per aggiungere o rimuovere i tag di indirizzamento chiamata. Le cifre over-decennali (‘A’) vengono utilizzate per aggiungere chiarezza per la risoluzione dei problemi. In questa configurazione, il tag aggiunto dal profilo di traduzione 100 viene utilizzato per guidare le chiamate da Webex Calling verso la PSTN tramite i dial-peer di loopback. Analogamente, il tag aggiunto dal profilo di traduzione 200 viene utilizzato per guidare le chiamate dalla PSTN verso Webex Calling. I profili di traduzione 11 e 12 rimuovono questi tag prima di consegnare le chiamate rispettivamente ai trunk Webex e PSTN. Questo esempio presuppone che i numeri chiamati di Webex Calling siano presentati in formato +E.164. La regola 100 rimuove il + iniziale per mantenere un numero chiamato valido. La regola 12 aggiunge una o più cifre di indirizzamento nazionale o internazionale quando si rimuove il tag. Utilizzare le cifre corrispondenti al piano di numerazione nazionale ISDN locale. Se Webex Calling presenta numeri in formato nazionale, regola le regole 100 e 12 per aggiungere e rimuovere semplicemente il tag di indirizzamento rispettivamente. Per ulteriori informazioni, vedi Profilo traduzione vocale e Regola traduzione vocale. |
2 |
Configurare le porte dell'interfaccia vocale TDM come richiesto dal tipo di trunk e dal protocollo utilizzato. Per ulteriori informazioni, vedi Configurazione del PRI ISDN. Ad esempio, la configurazione di base di un'interfaccia ISDN a velocità primaria installata nello slot NIM 2 di un dispositivo potrebbe includere quanto segue: |
3 |
Configurare il seguente dial-peer PSTN TDM: Di seguito una spiegazione dei campi per la configurazione: Definisce un dial-peer VoIP con un tag 200 e fornisce una descrizione significativa per facilità di gestione e risoluzione dei problemi. Per ulteriori informazioni, vedi Chiamata vocale peer. schema di destinazione SCADENTE.SCADENTEÈ richiesto un percorso di destinazione fittizio quando si indirizzano le chiamate in uscita utilizzando un gruppo di dial-peer in entrata. In questo caso è possibile utilizzare qualsiasi modello di destinazione valido. Per ulteriori informazioni, vedere percorso di destinazione (interfaccia). profilo di traduzione in ingresso 200Assegna il profilo di traduzione che aggiungerà un tag di indirizzamento chiamata al numero chiamato in arrivo. quadrante diretto verso l'internoIndirizza la chiamata senza fornire un segnale di linea secondario. Per ulteriori informazioni, vedere Direct-Inward-Dial. porta 0/2/0:15La porta vocale fisica associata a questo dial-peer. |
4 |
Per abilitare l'ottimizzazione multimediale dei percorsi IP per gateway locali con flussi di chiamata TDM-IP, puoi modificare l'indirizzamento delle chiamate introducendo una serie di dial-peer loop-back interni tra Webex Calling e trunk PSTN. Configurare i seguenti dial-peer di richiamata loop-back. In questo caso, tutte le chiamate in ingresso verranno indirizzate inizialmente al dial-peer 10 e da lì al dial-peer 11 o 12 in base al tag di indirizzamento applicato. Dopo la rimozione del tag di indirizzamento, le chiamate verranno inoltrate al trunk in uscita utilizzando gruppi di dial-peer. Di seguito una spiegazione dei campi per la configurazione: Definisce un dial-peer VoIP e fornisce una descrizione significativa per facilità di gestione e risoluzione dei problemi. Per ulteriori informazioni, vedi Chiamata vocale peer. profilo di traduzione in ingresso 11Applica il profilo di traduzione definito in precedenza per rimuovere il tag di indirizzamento chiamata prima di passare al trunk in uscita. schema di destinazione SCADENTE.SCADENTEÈ richiesto un percorso di destinazione fittizio quando si indirizzano le chiamate in uscita utilizzando un gruppo di dial-peer in entrata. Per ulteriori informazioni, vedere percorso di destinazione (interfaccia). protocollo sessione sipv2Specifica che questo dial-peer gestisce i segmenti di chiamata SIP. Per ulteriori informazioni, vedere protocollo sessione (dial peer). ipv4 destinazione sessione: 192.168.80.14Specifica l'indirizzo dell'interfaccia del router locale come destinazione di chiamata a loop-back. Per ulteriori informazioni, vedi destinazione sessione (peer di chiamata VoIP). associazione interfaccia origine di controllo GigabitEthernet0/0/0Configura l'interfaccia di origine e l'indirizzo IP associato per i messaggi inviati attraverso il loop-back. Per ulteriori informazioni, vedi associazione. associa interfaccia origine multimediale GigabitEthernet0/0/0Configura l'interfaccia di origine e l'indirizzo IP associato per il contenuto multimediale inviato attraverso il loop-back. Per ulteriori informazioni, vedi associazione. dtmf-relay rtp-nteDefinisce RTP-NTE (RFC2833) come funzionalità DTMF prevista sul modello della chiamata. Per ulteriori informazioni, vedere Inoltro DTMF (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 companding utilizzato dal servizio ISDN. nessun vadDisabilita il rilevamento dell'attività vocale. Per ulteriori informazioni, vedi vad (dial peer). |
5 |
Aggiungere la seguente configurazione di indirizzamento chiamata: Questa operazione termina la configurazione del gateway locale. Salva la configurazione e ricarica la piattaforma se questa è la prima volta che vengono configurate le funzioni CUBE.
|
La configurazione PSTN-Webex Calling nelle sezioni precedenti può essere modificata per includere trunk aggiuntivi a un cluster Cisco Unified Communications Manager (UCM). In questo caso, tutte le chiamate vengono indirizzate tramite Unified CM. Le chiamate da UCM sulla porta 5060 vengono indirizzate alla PSTN e le chiamate dalla porta 5065 vengono indirizzate a Webex Calling. Le seguenti configurazioni incrementali possono essere aggiunte per includere questo scenario di chiamata.
1 |
Configura i seguenti URI di classe vocale: |
2 |
Configurare i seguenti record DNS per specificare l'indirizzamento 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 si preferisce utilizzare il DNS, non sono necessarie queste configurazioni locali. Di seguito una spiegazione dei campi per la configurazione: Il comando seguente crea un record di risorse DNS SRV. Creare un record per ciascun host e trunk UCM: host IP _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.dominio.com _sip._udp.pstntocucm.io: Nome record risorse SRV 2: Priorità record risorse SRV 1: Il peso record risorsa SRV 5060: Il numero di porta da utilizzare per l'host di destinazione in questo record risorsa ucmsub5.mydomain.com: L'host di destinazione del record delle risorse Per risolvere i nomi host di destinazione dei record di risorse, creare record DNS A locali. Ad esempio: host ip ucmsub5.mydomain.com 192.168.80.65 host IP: Crea un record nel database IOS XE locale. ucmsub5.mydomain.com: Nome host record A. 192.168.80.65: Indirizzo IP dell'host. Creare i record delle risorse SRV e i record A per riflettere l'ambiente UCM e la strategia di distribuzione delle chiamate preferita. |
3 |
Configura i seguenti dial-peer: |
4 |
Aggiungi l'indirizzamento chiamata 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. Lo strumento di ricerca delle firme diagnostiche (DSLT, Diagnostic Signatures Lookup Tool) è l'unica fonte per trovare le firme applicabili per il monitoraggio e la risoluzione di diversi 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 versione successiva.
configurare il server di posta elettronica di tipo call-home :@ priorità 1 secure tls end
-
Configurare la variabile di ambiente con ds_email l'indirizzo e-mail dell'amministratore a cui inviare la notifica.
configura terminale call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)ambiente ds_email fine
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 %Agente SNMP non abilitato config t snmp-server manager end show snmp Chassis: Ingresso pacchetti SNMP ABCDEFGHIGK 149655 0 Errori di versione SNMP non validi 1 Nome comunità sconosciuto 0 Operazione illegale per il nome della comunità fornita 0 Errori di codifica 37763 Numero di variabili richieste 2 Numero di variabili alterate 34560 PDU Get-Request 138 PDU Get-Next 2 PDU di richiesta impostata 0 Interruzioni di pacchetti della coda di input (dimensione massima coda 1000) 158277 pacchetti SNMP in uscita 0 Errori troppo grandi (dimensione massima del pacchetto 1500) 20 Errori di nome non presenti 0 Errori di valori errati 0 Errori generali 7998 PDU risposta 10280 PDU trap Pacchetti attualmente in coda di input processo SNMP: 0 trap globali SNMP: abilitato
Scarica DS 64224 utilizzando le seguenti opzioni del menu a discesa nello strumento DSLT:
copia ftp://nomeutente:password@/DS_64224.xml bootflash:
Nome campo
Valore campo
Piattaforma
Software Cisco 4300, serie 4400 ISR o Catalyst430 V Edge
Prodotto
CUBE Enterprise in 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.
copia ftp://nomeutente:password@/DS_64224.xml bootflash:
L'esempio seguente mostra la copia del file da un server FTP al gateway locale.
copia ftp://utente:pwd@192.0.2.12/DS_64224.xml bootflash: Accesso a ftp://*:*@ 192.0.2.12/DS_64224.xml...! [OK - 3571/4096 bytes] 3571 byte copiati in 0,064 sec (55797 byte/sec)
-
Installa il file XML DS nel gateway locale.
call-home diagnostic-signature load DS_64224.xml File di caricamento DS_64224.xml riuscito
-
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".
mostra call-home diagnostic-signature Impostazioni di firma diagnostica correnti: Firma diagnostica: profilo abilitato: CiscoTAC-1 (stato: ACTIVE) URL di download: https://tools.cisco.com/its/service/oddce/services/DDCEService Variabile di ambiente: 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
Questa DS utilizza il sondaggio SNMP ogni 10 minuti per rilevare la disconnessione di chiamata anomala con errori SIP 403, 488 e 503. Se il numero di errori è maggiore di o uguale a 5 dall'ultimo sondaggio, viene generata una notifica del registro di sistema ed e-mail. Utilizza la procedura seguente per installare la firma.
-
Accertarsi che SNMP sia abilitato utilizzando il comando show snmp. Se SNMP non è abilitato, configurare il comando snmp-server manager .
show snmp %Agente SNMP non abilitato config t snmp-server manager end show snmp Chassis: Ingresso pacchetti SNMP ABCDEFGHIGK 149655 0 Errori di versione SNMP non validi 1 Nome comunità sconosciuto 0 Operazione illegale per il nome della comunità fornita 0 Errori di codifica 37763 Numero di variabili richieste 2 Numero di variabili alterate 34560 PDU Get-Request 138 PDU Get-Next 2 PDU di richiesta impostata 0 Interruzioni di pacchetti della coda di input (dimensione massima coda 1000) 158277 pacchetti SNMP in uscita 0 Errori troppo grandi (dimensione massima del pacchetto 1500) 20 Errori di nome non presenti 0 Errori di valori errati 0 Errori generali 7998 PDU risposta 10280 PDU trap Pacchetti attualmente in coda di input processo SNMP: 0 trap globali SNMP: abilitato
-
Scarica DS 65221 utilizzando le seguenti opzioni nello strumento DSLT:
Nome campo
Valore campo
Piattaforma
Software Cisco 4300, serie 4400 ISR o Catalyst430 V 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.
copia ftp://nomeutente:password@/DS_65221.xml bootflash:
-
Installa il file XML DS nel gateway locale.
call-home diagnostic-signature load DS_65221.xml File di caricamento DS_65221.xml riuscito
-
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:
Configura un'altra variabile di ambiente DS ds_fsurl_prefix come percorso del file server TAC di Cisco (cxd.cisco.com) per caricare i dati diagnostici. Il nome utente nel percorso file è il numero del caso e la password è il 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, come richiesto.
configura l'ambiente LocalGateway (cfg-call-home-diag-sign)call-home-diag-sign)call
di terminale ds_fsurl_prefix "scp://:@cxd.cisco.com" fine
Esempio:
call-home diagnostic-signature environment ds_fsurl_prefix " ambiente 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 .
mostra snmp %Agente SNMP non abilitato config t snmp-server manager fine
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 4300, serie 4400 ISR o Catalyst430 V 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 4300, serie 4400 ISR o Catalyst430 V 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.
copia ftp://nomeutente:password@/DS_64224.xml bootflash: copia ftp://nomeutente:password@/DS_65095.xml bootflash:
Installa la DS 64224 per il monitoraggio dell'elevato livello di CPU e quindi il file XML DS 65095 nel gateway locale.
call-home diagnostic-signature load DS_64224.xml File di caricamento DS_64224.xml riuscito call-home diagnostic-signature load DS_65095.xml File di caricamento DS_65095.xml riuscito
Verifica che la firma sia installata correttamente utilizzando il comando show call-home diagnostic-signature. La colonna dello stato deve contenere il valore "registered".
mostra call-home diagnostic-signature Impostazioni di firma diagnostica correnti: Firma diagnostica: profilo abilitato: CiscoTAC-1 (stato: ACTIVE) URL di download: https://tools.cisco.com/its/service/oddce/services/DDCEService Variabile di ambiente: 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
DSLGW_IEC_C_all_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.
mostra call-home diagnostic-signature Impostazioni di firma diagnostica correnti: Firma diagnostica: profilo
abilitato: CiscoTAC-1 (stato: ACTIVE)
URL di download: https://tools.cisco.com/its/service/oddce/services/DDCEService Variabile di ambiente: 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
Attivato/Max/Disinstalla
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
20/1/ANNO
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:
disinstallazione firma diagnostica chiamata-home
Esempio:
disinstallazione firma diagnostica chiamata-home 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.