- Home
- /
- Articolo
Flusso di lavoro di configurazione Webex Calling
Ottieni il tuo supporto con tutte le informazioni disponibili su Webex Calling, sia che tu sia un partner, un amministratore o un utente. Usa i collegamenti forniti qui per iniziare a utilizzare tutti i servizi e le funzioni disponibili con Webex Calling.
Requisiti del gateway locale per Webex Calling
Prerequisiti generali
Prima di configurare un gateway locale per Webex Calling, assicurati di:
Avere una conoscenza di base dei principi VoIP
Avere una conoscenza del funzionamento di base dei concetti vocali di Cisco IOS-XE e IOS-XE
Avere una comprensione di base del protocollo SIP (Session Initiation Protocol)
Avere una conoscenza di base di Cisco Unified Communications Manager (Unified CM), se il tuo modello di distribuzione include Unified CM
Per informazioni dettagliate, consultare la Guida alla configurazione aziendale di Cisco Unified Border Element (CUBE).
Requisiti hardware e software per gateway locale
Accertati che la distribuzione presenti uno o più gateway locali (Cisco CUBE (per connettività basata su IP) o il gateway Cisco IOS (per connettività basata su TDM) riportati nella Tabella 1 della Guida all'ordinazione del gateway locale per Webex Calling. Inoltre, accertati che sulla piattaforma sia in esecuzione una release IOS-XE supportata in base alla Guida alla configurazione del gateway locale.
Requisiti di licenza per gateway locali
Le licenze di chiamata CUBE devono essere installate sul gateway locale. Per ulteriori informazioni, vedi la Guida alla configurazione CUBE.
Requisiti di certificati e sicurezza per gateway locale
Webex Calling richiede segnali e contenuti multimediali sicuri. Il gateway locale esegue la crittografia e una connessione TLS deve essere stabilita in uscita al cloud completando la seguente procedura:
LGW deve essere aggiornato con il bundle radice CA di PKI Cisco
Un set di credenziali digest SIP della pagina di configurazione del trunk di Control Hub viene utilizzato per configurare LGW (le operazioni fanno parte della configurazione seguente)
Il bundle radice CA convalida il certificato presentato
Richiesta delle credenziali (digest SIP fornito)
Il cloud identifica il gateway locale registrato in modo sicuro
Requisiti firewall, attraversamento NAT, ottimizzazione percorso multimediale per gateway locale
Nella maggior parte dei casi, il gateway locale e gli endpoint possono risiedere nella rete del cliente interna, che utilizza indirizzi IP privati con NAT. Il firewall aziendale deve consentire il traffico in uscita (SIP, RTP/UDP, HTTP) a specifici indirizzi IP/porte, indicati nelle Informazioni di riferimento porta.
Se desideri utilizzare l'ottimizzazione del percorso multimediale con ICE, l'interfaccia rivolta verso Webex Calling del gateway locale deve avere un percorso di rete diretto a/da endpoint Webex Calling. Se gli endpoint si trovano in una posizione diversa e non esiste un percorso di rete diretto tra gli endpoint e l'interfaccia rivolta verso Webex Calling del gateway locale, il gateway locale deve disporre di un indirizzo IP pubblico assegnato all'interfaccia rivolta verso Webex Calling per le chiamate tra il gateway locale e gli endpoint per utilizzare l'ottimizzazione del percorso multimediale. Inoltre, deve essere in esecuzione IOS-XE versione 16.12.5.
Il primo passo per iniziare rapidamente a utilizzare i servizi Webex Calling consiste nel completare la procedura di installazione guidata iniziale (FTSW). Una volta completata la FTSW per la prima posizione, non deve essere completata per altre posizioni.
1 | Fai clic sul collegamento Introduzione nel messaggio e-mail di benvenuto che hai ricevuto.
| ||
2 | Rivedi e accetta del condizioni del servizio. | ||
3 | Rivedi il tuo piano e fai clic su Introduzione.
| ||
4 | Seleziona il paese a cui associare il tuo centro dati e inserisci le informazioni di contatto e indirizzo del cliente. | ||
5 | Fai clic su Avanti: Posizione predefinita. | ||
6 | Selezionare una delle opzioni seguenti:
| ||
7 | Effettua le seguenti selezioni da applicare a questa posizione:
| ||
8 | Fai clic su Avanti. | ||
9 | Inserisci un indirizzo SIP Cisco Webex disponibile e fai clic su Avanti, quindi seleziona Fine. |
Operazioni preliminari
Per creare una nuova posizione, prepara le seguenti informazioni:
Indirizzo posizione
Numeri di telefono desiderati (opzionale)
1 | Accedere a Control Hub all'indirizzohttps://admin.webex.com , andare a .
| ||||
2 | Configura le impostazioni della posizione:
| ||||
3 | Fare clic su Salva e scegliere Sì / No per aggiungere numeri alla posizione ora o successivamente. | ||||
4 | Se hai fatto clic su Aggiungi ora, scegli una delle seguenti opzioni:
La scelta dell'opzione PSTN è a livello di posizione (ciascuna posizione dispone di una sola opzione PSTN). Puoi combinare e associare il numero di opzioni desiderato per la tua distribuzione ma ogni posizione avrà una sola opzione. Una volta selezionata un'opzione PSTN ed eseguito il provisioning, puoi modificarla facendo clic su Gestisci nelle proprietà PSTN della posizione. Tuttavia, alcune opzioni come Cisco PSTN potrebbero non essere disponibili in seguito all'assegnazione di un'altra opzione. Apri una richiesta di supporto per indicazioni. | ||||
5 | Scegli se attivare i numeri ora o in un secondo momento. | ||||
6 | Se hai selezionato la CCP non integrata o la PSTN locale, inserisci i Numeri di telefono come valori separati da virgola, quindi fai clic su Convalida. I numeri vengono aggiunti per la posizione specifica. Le voci valide vengono spostate nel campo Numeri convalidati e le voci non valide rimangono nel campo Aggiungi numeri, insieme a un messaggio di errore. A seconda del paese della posizione, i numeri vengono formattati in modo conforme ai requisiti di chiamata locali. Ad esempio, se è necessario un prefisso, puoi inserire i numeri con o senza il prefisso e il prefisso viene aggiunto all'inizio. | ||||
7 | Fai clic su Salva. |
Operazioni successive
Una volta creata una posizione, puoi abilitare i servizi di emergenza per tale posizione. Per ulteriori informazioni, vedi Servizio RedSky di Webex Calling.
Operazioni preliminari
Ottieni un elenco degli utenti e degli spazi di lavoro associati a una posizione: Vai a Servizi > Numeri e dal menu a discesa seleziona la posizione da eliminare.eliminare tali utenti e spazi di lavoro. Prima di eliminare una posizione, deviTieni presente che qualsiasi numero associato a questa posizione verrà restituito al provider PSTN e non sarai più proprietario di tali numeri. |
1 | Accedere a Control Hub all'indirizzohttps://admin.webex.com , andare a . |
2 | Fare clic |
3 | Scegliere Elimina posizione , e confermare che si desidera eliminare la posizione. Solitamente bastano pochi minuti per eliminare in modo permanente la posizione, ma potrebbe essere necessaria fino a un'ora. Puoi controllare lo stato facendo clic su Altro accanto al nome della posizione e selezionando Stato eliminazione. |
Puoi modificare l'impostazione PSTN nonché il nome, il fuso orario e la lingua di una posizione una volta creata. Tieni presente che la nuova lingua si applica solo ai nuovi utenti e dispositivi. Gli utenti e i dispositivi esistenti continuano a utilizzare la lingua precedente.
Per le posizioni esistenti, puoi abilitare i servizi 911 di emergenza. Per ulteriori informazioni, vedi Servizio RedSky di Webex Calling. |
1 | Accedere a Control Hub all'indirizzohttps://admin.webex.com , andare a . Se accanto a una posizione viene visualizzato il simbolo di attenzione, significa che non hai ancora configurato un numero di telefono per tale posizione. Non è possibile effettuare o ricevere chiamate finché non si configura questo numero. | ||||||
2 | (Opzionale) In Connessione PSTN, seleziona PSTN connessa al cloud o PSTN locale (gateway locale), in base a quale hai già configurato. Fai clic su Gestisci per modificare la configurazione e confermare i rischi associati selezionando Continua. Quindi, scegli una delle seguenti opzioni e fai clic su Salva:
| ||||||
3 | Seleziona il Numero principale al quale può essere raggiunto il contatto principale della posizione. | ||||||
4 | (Opzionale) Sotto Chiamata di emergenza , è possibile selezionare ID posizione di emergenza per assegnare a questa posizione.
| ||||||
5 | Seleziona il Numero della casella vocale che gli utenti possono chiamare per controllare la propria casella vocale per questa posizione. | ||||||
6 | (Opzionale) Fai clic sull'icona della matita nella parte superiore della pagina Posizione per modificare Nome posizione, Fuso orario o Lingua come necessario, quindi, fai clic su Salva.
|
Queste impostazioni per la chiamata interna sono disponibili anche nella procedura iniziale di installazione guidata. Quando modifichi il piano di chiamata, i numeri di esempio nell'aggiornamento di Control Hub visualizzano queste modifiche.
Puoi configurare le autorizzazioni per le chiamate in uscita per una posizione. Vedi questi passaggi per configurare le autorizzazioni per le chiamate in uscita. |
1 | Accedi a Control Hub, vai a , quindi scorrere fino a Chiamata interna. | ||||||||
2 | Configura le seguenti preferenze di chiamata opzionali in base alle tue esigenze:
| ||||||||
3 | Specifica la chiamata interna per posizioni specifiche. Vai a Chiamata. Scorrere fino a Composizione, quindi modificare la composizione interna come necessario: , seleziona una posizione dall'elenco e fai clic su
| ||||||||
4 | Specifica la chiamata esterna per posizioni specifiche. Vai a Chiamata. Scorrere fino a Chiamata, quindi modificare la chiamata esterna come necessario: , seleziona una posizione dall'elenco e fai clic su
Impatto sugli utenti:
|
Se sei un rivenditore a valore aggiunto (VAR), puoi utilizzare questa procedura per avviare la configurazione del gateway locale in Control Hub. Quando questo gateway è registrato sul cloud, puoi utilizzarlo in una o più posizioni Webex Calling per fornire l'indirizzamento a un provider di servizi PSTN aziendale.
Una posizione che dispone di un gateway locale non può essere eliminata quando il gateway locale viene utilizzato per altre posizioni. |
Operazioni preliminari
Una volta aggiunta una posizione e prima di configurare il PSTN locale per una posizione, devi creare un trunk.
Crea posizioni e impostazioni e numeri specifici per ciascuno di essi. Le posizioni devono esistere prima di poter aggiungere un PSTN locale.
Comprendi i requisiti di PSTN locali (gateway locale) per Webex Calling.
Non puoi scegliere più di un trunk per una posizione con PSTN locale, ma puoi scegliere lo stesso trunk per più posizioni.
1 | Accedere a Control Hub alle , andare a Servizi > Chiamata > Indirizzamento chiamata , e selezionare Aggiungere trunk .https://admin.webex.com | ||
2 | Seleziona una posizione. | ||
3 | Assegna un nome al trunk e fai clic su Salva.
|
Operazioni successive
Le informazioni sul trunk vengono visualizzate nella schermata Registra dominio, OTG/DTG gruppo trunk, Linea/Porta e Indirizzo proxy in uscita.
È consigliabile copiare queste informazioni da Control Hub e incollarle in un file di testo locale o un documento in modo da utilizzarlo come riferimento quando sei pronto a configurare il PSTN locale.
Se hai perso le credenziali, devi generarle dalla schermata delle informazioni sul trunk in Control Hub. Fai clic su Recupera nome utente e reimposta password per generare un nuovo set di credenziali di autenticazione da utilizzare sul trunk.
1 | Accedere a Control Hub all'indirizzohttps://admin.webex.com , andare a . | ||
2 | Seleziona una posizione da modificare e fai clic su Gestisci. | ||
3 | Seleziona PSTN locale e fai clic su Avanti. | ||
4 | Scegli un trunk dal menu a discesa.
| ||
5 | Fai clic sull'avviso di conferma, quindi fai clic su Salva. |
Operazioni successive
Devi utilizzare le informazioni di configurazione generate da Control Hub e mappare i parametri nel gateway locale (ad esempio, su un Cisco CUBE che si trova in loco). Questo articolo ti guida attraverso questo processo. Come riferimento, vedi il diagramma seguente per un esempio del modo in cui le informazioni di configurazione di Control Hub (a sinistra) vengono associate ai parametri nel CUBE (a destra):
Dopo aver completato correttamente la configurazione sul gateway stesso, puoi tornare a Servizi > Chiamata > Posizioni in Control Hub e il gateway creato verrà elencato nella scheda di posizione a cui è stato assegnato con un punto verde alla sinistra del nome.
Questo stato indica che il gateway è registrato in modo sicuro sul cloud di chiamata e viene utilizzato come gateway PSTN attivo per la posizione.Puoi facilmente visualizzare, attivare, rimuovere e aggiungere i numeri di telefono per la tua organizzazione in Control Hub. Per ulteriori informazioni, vedi Gestione dei numeri di telefono in Control Hub.
Se stai provando i servizi Webex e desideri convertire la tua versione di prova in un abbonamento a pagamento, puoi inviare una richiesta e-mail al partner.
1 | Accedi a Control Hub su https://admin.webex.com, seleziona l'icona dell'edificio |
2 | Seleziona la scheda Abbonamenti, quindi fai clic su Acquista ora. Viene inviato un messaggio e-mail al partner per informarlo che sei interessato alla conversione in un abbonamento a pagamento. |
Puoi utilizzare Control Hub per impostare la priorità delle opzioni di chiamata disponibili che gli utenti visualizzano in Webex App. Puoi anche abilitarli per le chiamate con singolo clic. Per ulteriori informazioni, vedere: Imposta le opzioni di chiamata per gli utenti dell'app Webex .
È possibile controllare quale applicazione di chiamata viene aperta quando gli utenti effettuano le chiamate. È possibile configurare le impostazioni del client di chiamata, inclusa la distribuzione in modalità mista per organizzazioni con utenti autorizzati Unified CM o Webex Calling e gli utenti senza servizi di chiamata a pagamento di Cisco. Per ulteriori informazioni, vedere: Imposta funzionamento chiamata.
Panoramica
Webex Calling attualmente supporta due versioni del gateway locale:
Gateway locale
Gateway locale per Webex for Government
Prima di iniziare, comprendi i requisiti di rete telefonica commutata pubblica (PSTN) e gateway locale (LGW) per Webex Calling. Vedere Architettura Cisco Preferred per Webex Calling per ulteriori informazioni.
Questo articolo presuppone l'esistenza di una piattaforma gateway locale dedicata senza configurazione vocale. 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 ai comandi dei gateway gestiti Webex se non diversamente indicato (in tal caso, i collegamenti al comando vanno a Riferimento per i comandi vocali Cisco IOS ). È possibile accedere a tutte queste guide in Cisco Unified Border Element Command References. Per informazioni sui SBC supportati da terze parti si rimanda alla rispettiva documentazione di riferimento del prodotto. |
Sono disponibili due opzioni per configurare il gateway locale per il Webex Calling tronco:
Trunk basato su registrazione
Trunk basato su certificato
Utilizzare il flusso di attività sotto il file Gateway locale basato su registrazione o Gateway locale basato su certificato per configurare il gateway locale per il Webex Calling tronco.
Vedi Introduzione al gateway locale per ulteriori informazioni sui diversi tipi di trunk. Completare la seguente procedura sul gateway locale stesso, utilizzando l'interfaccia della riga di comando (CLI). Usiamo il Session Initiation Protocol (SIP) e il trasporto TLS ( Transport Layer Security ) per proteggere il trunk e il protocollo SRTP(Secure Real-time Protocol) per proteggere il supporto tra il gateway locale e Webex Calling .
Selezionare CUBE come gateway locale. Webex per il Settore pubblico attualmente non supporta SBC (Session Border Controller) di terze parti. Per rivedere l'elenco più recente, vedi Introduzione al gateway locale.
- Installa Cisco IOS XE Dublin 17.12.1a o versioni successive per tutti i gateway locali di Webex for Government.
Per rivedere l'elenco delle autorità di certificazione radice (CA) 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, usa 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 informazioni 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 for Government. In caso contrario, l'impostazione della chiamata non riesce. Per i dettagli di configurazione, vedi Configurazione del trunk basato su certificato Webex Calling.
Webex per il Settore pubblico non supporta il gateway locale basato sulla registrazione. |
In questa sezione viene descritto come configurare un elemento Cisco Unified Border (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 ad alto livello che verrà seguita.
In questo design, vengono utilizzate le seguenti configurazioni principali:
tenant di 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 per i messaggi SIP in entrata e determina il percorso in uscita con un gruppo di dial-peer.
gruppo dial-peer: Definisce i dial-peer in uscita utilizzati per l'indirizzamento delle chiamate in uscita.
dial-peer in uscita: Fornisce il trattamento per i messaggi SIP in uscita e li indirizza al target richiesto.
Quando si connette 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 seguente diagramma. In questo caso, Unified Communications Manager fornisce l'indirizzamento e il trattamento centralizzato di tutte le chiamate PSTN e Webex Calling.
In tutto questo documento, vengono utilizzati i nomi host, gli indirizzi IP e le interfacce illustrati nell'immagine seguente.
Utilizzare le istruzioni di 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:
Passaggio 3: Configurazione del gateway locale con trunk PSTN SIP
Passaggio 4: Configurazione del gateway locale con l'ambiente Unified CM esistente
Oppure:
Passaggio 3: Configurazione del gateway locale con trunk PSTN TDM
Configurazione di base
Il primo passo nella preparazione del 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. Per le versioni consigliate, vedere la pagina Ricerca software Cisco. Cercare la piattaforma e selezionare una delle release suggerite.
I router della 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 la licenza DNA Advantage. I router senza schede vocali o DSP richiedono un minimo di licenze DNA Essentials.
Creare una configurazione di base per la piattaforma che segua i criteri aziendali. In particolare, configurare quanto segue e verificare il funzionamento:
NTP
ACL
Autenticazione utente e accesso remoto
DNS
IP
Indirizzi IP
La rete verso Webex Calling deve utilizzare un indirizzo IPv4.
Carica 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 la registrazione e le credenziali 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.
| ||
4 | Abilitare l'esclusività TLS1.2 e specificare il trustpoint predefinito utilizzando i seguenti comandi di configurazione. I parametri di trasporto devono inoltre essere aggiornati per garantire una connessione sicura affidabile per la registrazione:
| ||
5 | Installa il bundle CA radice di Cisco, che include il certificato CA DigiCert utilizzato da Webex Calling. Utilizzare il crypto pki trustpool importazione url pulito comando per scaricare il bundle CA radice dall'URL specificato e per cancellare il pool di attendibilità CA corrente, quindi installare il nuovo bundle di certificati:
|
1 | Crea un trunk PSTN basato su registrazione per una posizione esistente in Control Hub. Prendi nota delle informazioni sul trunk fornite una volta creato il trunk. Questi dettagli, come evidenziato nella figura seguente, saranno utilizzati nei passaggi di configurazione di questa guida. Per ulteriori informazioni, vedere Configura trunk, gruppi di indirizzamento e piani di chiamata per Webex Calling . | ||||
2 | Immettere i seguenti comandi per configurare CUBE come gateway locale Webex Calling:
Di seguito una spiegazione dei campi per la configurazione:
Consente di abilitare le funzioni CUBE (Cisco Unified Border Element) sulla piattaforma. statistiche mediaConsente il monitoraggio multimediale sul gateway locale. statistiche bulk multimedialiConsente al piano di controllo di eseguire il polling del piano dati per le statistiche chiamata in blocco. Per ulteriori informazioni su questi comandi, vedere Media. consentire connessioni da sip a sipAbilita funzionalità agente utente back-to-back SIP base CUBE. Per ulteriori informazioni, vedere Consenti connessioni .
Abilita globalmente STUN (Session Traversal of UDP through NAT).
Per ulteriori informazioni, vedere stun flowdata agent-id e stun flowdata shared-secret . pieno carico utile asimmetricoConfigura il supporto del payload asimmetrico SIP per payload DTMF e codec dinamici. Per ulteriori informazioni su questo comando, vedere payload asimmetrico . offerta anticipata forzataObbliga 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 codec classe vocale 100 filtro per il trunk. In questo esempio, viene utilizzato lo stesso filtro codec per tutti i trunk. È possibile configurare i filtri per ogni trunk per un controllo preciso.
Di seguito una spiegazione dei campi per la configurazione: codec classe vocale 100Utilizzato per consentire solo codec preferiti per le chiamate tramite trunk SIP. Per ulteriori informazioni, vedere codec di 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: stunutilizzoiceliteUtilizzato per abilitare ICE-Lite per tutti i dial-peer rivolti verso Webex Calling per consentire l'ottimizzazione multimediale quando possibile. Per ulteriori informazioni, vedere uso dello stordimento della lezione vocale e uso stordimento ice lite .
| ||||
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 unico CUBE della suite di crittografia SRTP in SDP nei messaggi di offerta e risposta. Webex Calling supporta solo SHA180._ Per ulteriori informazioni, vedere classe vocale srtp-crypto . | ||||
6 | Configura una sequenza per identificare in modo univoco le chiamate a un trunk del gateway locale in base al parametro del trunk di destinazione:
Di seguito una spiegazione dei campi per la configurazione: uri classe vocale 100 sipDefinisce uno schema che corrisponda a un invito SIP in arrivo a un dial-peer 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, vedi uri classe vocale. | ||||
7 | Configura 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:
| ||||
8 | Configura trunk Webex Calling: |
Dopo aver definito il tenant 100 e configurare un dial-peer VoIP SIP, 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 protetta per eseguire la registrazione con il controller SBC di accesso Webex. Quando la registrazione è contestata per l'autenticazione:
Nella risposta vengono utilizzati i parametri di nome utente, password e area di autenticazione dalla configurazione delle credenziali .
Le regole di modifica nel profilo SIP 100 vengono utilizzate per convertire nuovamente URL SIPS in SIP.
La registrazione ha esito positivo quando si riceve un 200 OK dal controller SBC di accesso.
Dopo aver creato un trunk verso Webex Calling, 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 a quella descritta sopra per il trunk Webex Calling. L'indirizzamento delle chiamate da sicuro a sicuro è supportato da CUBE. |
Per configurare interfacce TDM per segmenti di chiamata PSTN sui gateway Cisco TDM-SIP, vedere Configurazione ISDN PRI. |
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: uri classe vocale 200 sipDefinisce uno schema che corrisponda a un invito SIP in arrivo a un dial-peer trunk in arrivo. Quando si immette questo schema, utilizzare l'indirizzo IP del gateway PSTN IP. Per ulteriori informazioni, vedi uri classe vocale. |
2 | Configurare il seguente dial-peer PSTN IP:
Di seguito una spiegazione dei campi per la configurazione:
Definisce un dial-peer VoIP con un tag di 100 e fornisce una descrizione significativa per facilità di gestione e risoluzione dei problemi. Per ulteriori informazioni, vedere voce dial-peer. modello di destinazione BAD.BADUno schema di destinazione fittizio è richiesto quando si indirizzano le chiamate in uscita utilizzando un gruppo di dial-peer in entrata. Per ulteriori informazioni, vedere motivo-destinazione (interfaccia) . protocollo di sessione sipv2Specifica che il dial-peer 200 gestisce i segmenti di chiamata SIP. Per ulteriori informazioni, vedere protocollo di sessione (dial peer) . obiettivo della sessione ipv4:192.168.80.13Indica l'indirizzo indirizzo IPv4 di destinazione della destinazione per inviare il segmento di chiamata. La destinazione della sessione qui è l' indirizzo IP di ITSP . Per ulteriori informazioni, vedere destinazione sessione (peer di chiamata VoIP). uri in ingresso tramite 200Definisce un criterio di corrispondenza per l'intestazione VIA con l' IP della PSTN indirizzo IP. Corrisponde a tutti i segmenti di chiamata PSTN IP in ingresso sul gateway locale con dial-peer 200. Per ulteriori informazioni, vedere URL in arrivo. bind control source-interface GigabitEthernet0/0/0Configura l'interfaccia di origine e l'indirizzo IP associato per i messaggi inviati alla PSTN. Per ulteriori informazioni, vedere bind. associazione origine-interfaccia multimediale GigabitEthernet0/0/0Configura l'interfaccia di origine e l'indirizzo IP associato per il contenuto multimediale inviato a 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 codec di classe vocale . rtp-nte relè dtmfDefinisce RTP-NTE (RFC2833) come funzionalità DTMF prevista sul segmento di segmento di chiamata. Per ulteriori informazioni, vedere DTMF Relay (Voice over IP). no-vagliaDisabilita il rilevamento di attività vocale. Per ulteriori informazioni, vedere vad (peer di chiamata). |
3 | Se si sta configurando il gateway locale per indirizzare solo le chiamate tra Webex Calling e PSTN, aggiungere la seguente configurazione di indirizzamento chiamata. Se si sta configurando il gateway locale con una piattaforma Unified Communications Manager, passare alla sezione successiva. |
La configurazione PSTN-Webex Calling nelle sezioni precedenti può essere modificata per includere trunk aggiuntivi per 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. In questo modo, i messaggi in arrivo sulla porta 5065 vengono inseriti nell'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 l'indirizzamento SRV agli host Unified CM:
Di seguito una spiegazione dei campi per la configurazione: Il seguente comando crea un record di risorsa SRV DNS. Creare un record per ciascun host e trunk UCM: ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: Nome record risorsa SRV 2: Priorità record risorse SRV 1: Peso record risorse SRV 5060: Il numero di porta da utilizzare per l'host di destinazione in questo record di risorse ucmsub5.mydomain.com: L'organizzatore di destinazione del record di risorse Per risolvere i nomi host di destinazione dei record di risorse, creare i 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: Il nome dell'organizzatore record A. 192.168.80.65: L'indirizzo IP 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 | Configurare i seguenti dial-peer: | ||
4 | Aggiungi indirizzamento chiamata utilizzando le seguenti configurazioni: |
Le firme diagnostiche (DS) rilevano in modo proattivo i problemi riscontrati di frequente nel gateway locale basato su IOS XE e generano una notifica dell'evento tramite e-mail, syslog o messaggi sul terminale. 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 sugli eventi di attivazione del problema e sulle azioni da intraprendere per informare, risolvere il problema e porvi rimedio. È 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 azioni includono la raccolta di risultati del comando show:
Generazione di un file di registro consolidato
Caricamento del file in una posizione di rete fornita dall'utente, come server HTTPS, SCP, FTP.
I tecnici TAC creano i file DS e li firmano digitalmente per la protezione dell'integrità. A ogni file DS viene assegnato un ID numerico univoco dal sistema. Strumento di ricerca firme diagnostiche (DSLT) è una singola origine per trovare le firme applicabili per il monitoraggio e la risoluzione dei problemi di vari problemi.
Operazioni preliminari:
Non modificare il file DS da cui è stato eseguito il download DSLT . L'installazione dei file modificati non viene completata a causa dell'errore di controllo dell'integrità.
Un server SMTP(Simple Mail Transfer Protocol) necessario al gateway locale per inviare le notifiche e-mail.
Accertarsi che il gateway locale esegua IOS XE 17.6.1 o versione superiore se si desidera utilizzare il server TFTP 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 e-mail sicuro da utilizzare per inviare notifiche proattive se sul dispositivo è in esecuzione Cisco IOS XE 17.6.1a o versione successiva.
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls end
Configurare la variabile di ambienteds_email con l' indirizzo e-mail dell'amministratore per la notifica.
configure terminal call-home diagnostic-signature environment ds_email <email address> end
Di seguito viene mostrata una configurazione di esempio di un gateway locale in esecuzione su Cisco IOS XE 17.6.1a o superiore 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 priority 1 secure tls
diagnostic-signature
environment ds_email "tacfaststart@gmail.com"
Un gateway locale in esecuzione sul software Cisco IOS XE 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 affinché l'e-mail dal dispositivo venga elaborato correttamente: |
Vai a Meno sicura.
e attiva l'impostazione di accessoall'appRispondi "Sì, sono stato io" quando ricevi un'e-mail da Gmail che indica "Google ha impedito a qualcuno di accedere al tuo account utilizzando un'app non Google".
Installare le firme diagnostiche per il monitoraggio proattivo
Monitoraggio dell'utilizzo elevato CPU
Questa DS monitora l'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 mostra snmp comando per abilitare SNMP. Se non si abilita, configurare il gestore snmp-server comando.
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, serie 4400 ISR o Cisco CSR serie 1000V
Prodotto
CUBE Enterprise in Webex Calling
Ambito del problema
Prestazioni
Tipo di problema
Utilizzo elevato CPU con notifica e-mail .
Copia il file XML DS nel flash del gateway locale.
LocalGateway# copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
Il seguente esempio mostra come copiare il 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 show call-home diagnostic-signature per verificare che la firma sia 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.
Monitoraggio della registrazione trunk SIP
Questo DS verifica l'annullamento della registrazione di un SIP trunk del gateway locale con Webex Calling cloud ogni 60 secondi. Una volta rilevato, l'evento di annullamento della registrazione genera un'e-mail e una notifica di syslog e si disinstalla automaticamente dopo due occorrenze di annullamento della registrazione. Effettuare le seguenti operazioni 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
Annullamento registrazione trunk SIP con notifica e-mail .
Copia il file XML DS nel gateway locale.
copy ftp://username:password@<server name or ip>/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 show call-home diagnostic-signature per verificare che la firma sia installata correttamente. La colonna dello stato deve avere un valore "registrato".
Monitoraggio delle disconnessioni delle chiamate anomale
Questa DS utilizza il sondaggio SNMP ogni 10 minuti per rilevare una disconnessione di chiamata anomala con errori SIP 403, 488 e 503. Se l'incremento del numero di errori è maggiore o uguale a 5 dall'ultimo sondaggio, genera un registro di sistema e una notifica e-mail. Utilizza la procedura seguente per installare la firma.
Utilizzare il mostra snmp comando per verificare se SNMP è abilitato. Se non è abilitato, configurare il gestore snmp-server comando.
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 della disconnessione della chiamata anomala SIP con notifica e e-mail e syslog.
Copia il file XML DS nel gateway locale.
copy ftp://username:password@<server name or ip>/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 show call-home diagnostic-signature per verificare che la firma sia installata correttamente. La colonna dello stato deve avere un valore "registrato".
Installare le firme diagnostiche per risolvere un problema
Utilizzare le firme diagnostiche (DS) per risolvere rapidamente i problemi. I tecnici di centro TAC di Cisco hanno creato diverse firme che consentono i debug necessari per risolvere un determinato problema, rilevare il problema che si verifica, raccogliere il set di dati diagnostici corretto e trasferire automaticamente i dati al caso centro TAC di Cisco . Le firme diagnostiche (DS) eliminano la necessità di controllare manualmente l'insorgenza del problema e rendono molto più semplice la risoluzione dei problemi intermittenti e transitori.
È possibile utilizzare il Strumento di ricerca firme diagnostiche per trovare le firme applicabili e installarle per risolvere autonomamente un determinato problema oppure è possibile installare la firma consigliata dal tecnico TAC come parte del coinvolgimento del 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" syslog e automatizza la raccolta dei dati diagnostici utilizzando la seguente procedura:
Configurare un'ulteriore variabile di ambiente DSds_fsurl_prefix che è il percorso del file server centro TAC di Cisco (cxd.cisco.com) in cui vengono caricati i dati di diagnostica raccolti. Il nome utente nel percorso file è il numero del caso e la password è il token caricamento file che può essere recuperato Support Case Manager nel comando seguente. Il token di caricamento del file può essere generato nella sezione Allegati del Support Case Manager, come necessario.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" end
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 mostra snmp comando. Se non è abilitato, configurare il gestore snmp-server comando.
show snmp %SNMP agent not enabled config t snmp-server manager end
Assicurarsi di installare il monitoraggio della CPU alta 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
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 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@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/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 installata correttamente utilizzando il file show call-home diagnostic-signature comando. La colonna dello stato deve avere 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
08-11-2020
65095
00:12:53
DS_LGW_IEC_Call_spike_threshold
0.0.12
Registrato
08-11-2020
Verificare l'esecuzione delle firme diagnostiche
Nel comando seguente, la colonna "Stato" del file show call-home diagnostic-signature il comando cambia in "in esecuzione" mentre il gateway locale esegue l'azione definita all'interno della firma. L'output di mostra le 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 "Triggered/Max/Deinstall" indica il numero di volte in cui la firma specificata ha attivato un evento, il numero massimo di volte in cui viene definito un evento per rilevare un evento e se la firma si disinstalla da sola 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 | 08/11/2020 00:07:45 |
65095 | DS_LGW_IEC_Call_spike_threshold | 0.0.12 | In esecuzione | 08/11/2020 00:12:53 |
mostra le statistiche della firma-diagnostica della chiamata a casa
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 | 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 di esecuzione e visualizza gli output dei comandi pertinenti per la risoluzione del problema specificato.
Disinstallare le firme diagnostiche
Le firme diagnostiche utilizzate per la risoluzione dei problemi vengono in genere definite per disinstallare dopo il rilevamento di alcune occorrenze del problema. Se si desidera disinstallare manualmente una firma, recuperare l'ID DS dall'output di mostrare la firma diagnostica della chiamata-casa e eseguire il comando seguente:
call-home diagnostic-signature deinstall <DS ID>
Esempio:
call-home diagnostic-signature deinstall 64224
Nuove firme vengono aggiunte periodicamente allo strumento di ricerca firme diagnostiche, in base a problemi che si riscontrano comunemente 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 registrare e gestire i gateway attraverso Control Hub. È una configurazione opzionale. Al termine della registrazione, è possibile utilizzare l'opzione di convalida della configurazione in Control Hub per convalidare la configurazione del gateway locale e identificare eventuali problemi di configurazione. Attualmente, solo i trunk basati su registrazione supportano questa funzionalità.
Per ulteriori informazioni, fare riferimento alle seguenti sezioni:
In questa sezione viene descritto come configurare un Cisco Unified Border Element (CUBE) come gateway locale per Webex Calling utilizzando il 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 ad alto livello che verrà seguita.
In questo design, vengono utilizzate le seguenti configurazioni principali:
tenant di 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 per i messaggi SIP in entrata e determina il percorso in uscita con un gruppo di dial-peer.
gruppo dial-peer: Definisce i dial-peer in uscita utilizzati per l'indirizzamento delle chiamate in uscita.
dial-peer in uscita: Fornisce il trattamento per i messaggi SIP in uscita e li indirizza al target richiesto.
Quando si connette 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 seguente diagramma. In questo caso, Unified Communications Manager fornisce l'indirizzamento e il trattamento centralizzato di tutte le chiamate PSTN e Webex Calling.
In tutto questo documento, vengono utilizzati i nomi host, gli indirizzi IP e le interfacce illustrati nell'immagine seguente. Le opzioni sono fornite 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.
Utilizzare le istruzioni di 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:
Passaggio 3: Configurazione del gateway locale con trunk PSTN SIP
Passaggio 4: Configurazione del gateway locale con l'ambiente Unified CM esistente
Oppure:
Passaggio 3: Configurazione del gateway locale con trunk PSTN TDM
Configurazione di base
Il primo passo nella preparazione del 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. Per le versioni consigliate, vedere la pagina Ricerca software Cisco. Cercare la piattaforma e selezionare una delle release suggerite.
I router della 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 Essentials. I router senza schede vocali o DSP richiedono un minimo di licenze DNA Essentials.
Per requisiti di capacità elevati, è possibile anche richiedere una licenza High Security (HSEC) e diritti di throughput aggiuntivi.
Fare riferimento a Codici di autorizzazione per ulteriori dettagli.
Creare una configurazione di base per la piattaforma che segua i criteri aziendali. In particolare, configurare quanto segue e verificare il funzionamento:
NTP
ACL
Autenticazione utente e accesso remoto
DNS
IP
Indirizzi IP
La rete verso Webex Calling deve utilizzare un indirizzo IPv4. I nomi di dominio completo (FQDN) o gli indirizzi SRV (Service Record) del gateway locale 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. Assicurarsi di aggiornare il firewall di conseguenza.
Installare un certificato firmato sul gateway locale (di seguito sono riportate dettagliate operazioni di configurazione).
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 di dominio completo configurato in Control Hub durante la creazione di un trunk deve essere il certificato Nome comune (CN) o Nome alternativo oggetto (SAN) del router. Ad esempio:
Se un trunk configurato nel Control Hub dell'organizzazione dispone di cube1.lgw.com:5061 come nome di dominio completo 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 router deve contenere lgws.lgw.com. I record in cui viene risolto l'indirizzo SRV (CNAME, record A o indirizzo IP ) sono facoltativi in SAN.
Se si utilizza un nome di dominio completo o SRV per il trunk, l'indirizzo del contatto per tutte le nuove finestre di dialogo SIP del gateway locale utilizza il nome configurato in Control Hub.
Assicurarsi che i certificati siano firmati per l'uso su client e server.
Carica 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 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 firmato dall'autorità di certificazione preferita (CA). | ||
4 | Autenticare il nuovo certificato utilizzando il certificato CA intermedio (o radice), quindi importare il certificato (Fase 4). Immettere il seguente comando exec o di configurazione:
| ||
5 | Importare un certificato host firmato utilizzando il seguente comando exec o configurazione:
| ||
6 | Abilitare l'esclusività TLS1.2 e specificare il trustpoint predefinito utilizzando i seguenti comandi di configurazione:
| ||
7 | Installa il bundle CA radice di Cisco, che include il certificato CA DigiCert utilizzato da Webex Calling. Utilizzare il crypto pki trustpool importazione url pulito comando per scaricare il bundle CA radice dall'URL specificato e per cancellare il pool di attendibilità CA corrente, quindi installare il nuovo bundle di certificati:
|
1 | Crea un trunk PSTN basato su certificato CUBE per una posizione esistente in Control Hub. Per ulteriori informazioni, vedere Configura trunk, gruppi di indirizzamento e piani di chiamata per Webex Calling .
| ||||
2 | Immettere i seguenti comandi per configurare CUBE come gateway locale Webex Calling:
Di seguito una spiegazione dei campi per la configurazione:
Consente di abilitare le funzioni CUBE (Cisco Unified Border Element) sulla piattaforma. consentire connessioni da sip a sipAbilita la funzionalità agente utente SIP base CUBE back to back. Per ulteriori informazioni, vedere Consenti connessioni .
Abilita globalmente STUN (Session Traversal of UDP through NAT).
Per ulteriori informazioni, vedere stun flowdata agent-id e stun flowdata shared-secret. pieno carico utile asimmetricoConfigura il supporto del payload asimmetrico SIP per payload DTMF e codec dinamici. Per ulteriori informazioni su questo comando, vedere payload asimmetrico . offerta anticipata forzataObbliga 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 entrataConsente a CUBE di utilizzare i profili SIP per modificare i messaggi man mano che vengono ricevuti. I profili vengono applicati tramite dial-peer o tenant. | ||||
3 | Configura codec classe vocale 100 filtro codec per il trunk. In questo esempio, viene utilizzato lo stesso filtro codec per tutti i trunk. È possibile configurare i filtri per ogni trunk per un controllo preciso.
Di seguito una spiegazione dei campi per la configurazione: codec classe vocale 100Utilizzato per consentire solo codec preferiti per le chiamate tramite trunk SIP. Per ulteriori informazioni, vedere codec di classe vocale .
| ||||
4 | Configura stun-usage della classe vocale 100 per abilitare ICE sul trunk Webex Calling. (Questa operazione non è applicabile a Webex for Government)
Di seguito una spiegazione dei campi per la configurazione: stunutilizzoiceliteUtilizzato per abilitare ICE-Lite per tutti i dial-peer rivolti verso Webex Calling per consentire l'ottimizzazione multimediale quando possibile. Per ulteriori informazioni, vedere uso dello stordimento della lezione vocale e uso stordimento ice lite .
| ||||
5 | Configurare i criteri di crittografia multimediale per il traffico Webex. (Questa operazione non è applicabile a Webex for Government)
Di seguito una spiegazione dei campi per la configurazione: classe vocale srtp-crypto 100Specifica SHA1_80 come unico CUBE della suite di crittografia SRTP in SDP nei messaggi di offerta e risposta. Webex Calling supporta solo SHA180._ Per ulteriori informazioni, vedere classe vocale srtp-crypto . | ||||
6 | Configura crittografie GCM conformi a FIPS (questa fase è applicabile solo a Webex for Government).
Di seguito una spiegazione dei campi per la configurazione: classe vocale srtp-crypto 100Specifica GCM come la suite di crittografia offerta da CUBE. È obbligatorio configurare le crittografie GCM per il gateway locale per Webex for Government. | ||||
7 | Configura un percorso per identificare in modo univoco le chiamate a un trunk del gateway locale in base al nome di dominio completo o SRV della destinazione:
Di seguito una spiegazione dei campi per la configurazione: uri classe vocale 100 sipDefinisce uno schema che corrisponda a un invito SIP in arrivo a un dial-peer trunk in arrivo. Quando si immette questo schema, utilizzare FQDN LGW o SRV configurato in Control Hub durante la creazione di un 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 il processo NAT. In questo esempio, cube1.lgw.com è il nome di dominio completo configurato per il gateway locale e "198.51.100.1" è l'indirizzo IP pubblico dell'interfaccia del gateway locale rivolta 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 in Control Hub. Questo è il nome di dominio completo di un singolo host o il nome di dominio SRV utilizzato per un cluster di dispositivi.
| ||||
9 | Se il gateway è configurato con un indirizzo IP privato dietro il processo NAT statico, 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 i messaggi in uscita a 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 in Control Hub. Questo è il nome di dominio completo di un singolo host o il nome di dominio SRV utilizzato per un cluster di dispositivi. dalle 30 alle 81Converti i riferimenti di indirizzo privato all'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: dalle 10 alle 80Converti i riferimenti all'indirizzo pubblico all'indirizzo privato configurato, consentendo a messaggi di Webex di essere elaborati correttamente da CUBE. Per ulteriori informazioni, vedere profili sip delle classi vocali . | ||||
10 | Configurare un keepalive Opzioni SIP con profilo di modifica intestazione.
Di seguito una spiegazione dei campi per la configurazione: classe vocale sip-options-keepalive 100Configura un profilo di mantenimento e attiva la modalità di configurazione della lezione vocale. È possibile configurare il tempo (in secondi) in cui viene inviato il ping delle opzioni SIP Out of Dialog all'obiettivo di chiamata quando la connessione heartbeat all'endpoint è in stato UP o Down. Questo profilo keepalive viene attivato dal dial-peer configurato per Webex. Per assicurarsi che le intestazioni dei contatti includano il nome di dominio SBC completo, viene utilizzato il profilo SIP 115. Le regole 30, 40 e 50 sono richieste solo quando l'SBC è configurato dietro NAT statico. In questo esempio, cube1.lgw.com è il nome di dominio completo selezionato per il gateway locale e, se viene utilizzata la tecnologia NAT statica, "10.80.13.12" è l'indirizzo IP dell'interfaccia SBC verso Webex Calling e "192.65.79.20" è l'indirizzo IP NAT pubblico. | ||||
11 | Configura trunk Webex Calling: |
Dopo aver creato un trunk verso Webex Calling, 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 a quella descritta sopra per il trunk Webex Calling. L'indirizzamento delle chiamate da sicuro a sicuro è supportato da CUBE. |
Per configurare interfacce TDM per segmenti di chiamata PSTN sui gateway Cisco TDM-SIP, vedere Configurazione ISDN PRI. |
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: uri classe vocale 200 sipDefinisce uno schema che corrisponda a un invito SIP in arrivo a un dial-peer trunk in arrivo. Quando si immette questo schema, utilizzare l'indirizzo IP del gateway PSTN IP. Per ulteriori informazioni, vedi uri classe vocale. |
2 | Configurare il seguente dial-peer PSTN IP:
Di seguito una spiegazione dei campi per la configurazione:
Definisce un dial-peer VoIP con un tag di 100 e fornisce una descrizione significativa per facilità di gestione e risoluzione dei problemi. Per ulteriori informazioni, vedere voce dial-peer. modello di destinazione BAD.BADUno schema di destinazione fittizio è richiesto quando si indirizzano le chiamate in uscita utilizzando un gruppo di dial-peer in entrata. Per ulteriori informazioni, vedere motivo-destinazione (interfaccia) . protocollo di sessione sipv2Specifica che il dial-peer 200 gestisce i segmenti di chiamata SIP. Per ulteriori informazioni, vedere protocollo di sessione (dial peer) . obiettivo della sessione ipv4:192.168.80.13Indica l'indirizzo indirizzo IPv4 di destinazione della destinazione per inviare il segmento di chiamata. La destinazione della sessione qui è l' indirizzo IP di ITSP . Per ulteriori informazioni, vedere destinazione sessione (peer di chiamata VoIP). uri in ingresso tramite 200Definisce un criterio di corrispondenza per l'intestazione VIA con l' IP della PSTN indirizzo IP. Corrisponde a tutti i segmenti di chiamata PSTN IP in ingresso sul gateway locale con dial-peer 200. Per ulteriori informazioni, vedere URL in arrivo. bind control source-interface GigabitEthernet0/0/0Configura l'interfaccia di origine e l'indirizzo IP associato per i messaggi inviati alla PSTN. Per ulteriori informazioni, vedere bind. associazione origine-interfaccia multimediale GigabitEthernet0/0/0Configura l'interfaccia di origine e l'indirizzo IP associato per il contenuto multimediale inviato a 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 codec di classe vocale . rtp-nte relè dtmfDefinisce RTP-NTE (RFC2833) come funzionalità DTMF prevista sul segmento di segmento di chiamata. Per ulteriori informazioni, vedere DTMF Relay (Voice over IP). no-vagliaDisabilita il rilevamento di attività vocale. Per ulteriori informazioni, vedere vad (peer di chiamata). |
3 | Se si sta configurando il gateway locale per indirizzare solo le chiamate tra Webex Calling e PSTN, aggiungere la seguente configurazione di indirizzamento chiamata. Se si sta configurando il gateway locale con una piattaforma Unified Communications Manager, passare alla sezione successiva. |
La configurazione PSTN-Webex Calling nelle sezioni precedenti può essere modificata per includere trunk aggiuntivi per 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:
Di seguito una spiegazione dei campi per la configurazione: Il seguente comando crea un record di risorsa SRV DNS. Creare un record per ciascun host e trunk UCM: ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: Nome record risorsa SRV 2: Priorità record risorse SRV 1: Peso record risorse SRV 5060: Il numero di porta da utilizzare per l'host di destinazione in questo record di risorse ucmsub5.mydomain.com: L'organizzatore di destinazione del record di risorse Per risolvere i nomi host di destinazione dei record di risorse, creare i 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: Il nome dell'organizzatore record A. 192.168.80.65: L'indirizzo IP 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 | Configurare i seguenti dial-peer: | ||
4 | Aggiungi indirizzamento chiamata utilizzando le seguenti configurazioni: |
Le firme diagnostiche (DS) rilevano in modo proattivo i problemi riscontrati comunemente nel gateway locale basato su Cisco IOS XE e generano una notifica dell'evento e-mail, syslog o messaggi sul terminale. 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 sugli eventi in cui si è verificato il problema e sulle azioni da eseguire per informare del problema, risolvere e risolvere il problema. Utilizzare i messaggi di syslog, gli eventi SNMP e il monitoraggio periodico degli output del comando show specifici per definire la logica di rilevamento del problema. I tipi di azione comprendono:
Raccolta degli output del comando show
Generazione di un file di registro consolidato
Caricamento del file in una posizione di rete fornita dall'utente, ad esempio HTTPS, SCP, server FTP
I tecnici TAC creano i file DS e li firmano digitalmente per la protezione dell'integrità. Ogni file DS presenta un ID numerico univoco assegnato dal sistema. Strumento di ricerca firme diagnostiche (DSLT) è una singola origine per trovare le firme applicabili per il monitoraggio e la risoluzione dei problemi di vari problemi.
Operazioni preliminari:
Non modificare il file DS da cui è stato eseguito il download DSLT . L'installazione dei file modificati non viene completata a causa dell'errore di controllo dell'integrità.
Un server SMTP(Simple Mail Transfer Protocol) necessario al gateway locale per inviare le notifiche e-mail.
Accertarsi che il gateway locale esegua IOS XE 17.6.1 o versione superiore se si desidera utilizzare il server TFTP 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 da utilizzare per inviare una notifica proattiva se il dispositivo esegue IOS XE 17.6.1 o versioni superiori.
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls end
Configurare la variabile di ambienteds_email con l' indirizzo e-mail dell'amministratore per la notifica.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_email <email address> end
Installare le firme diagnostiche per il monitoraggio proattivo
Monitoraggio dell'utilizzo elevato CPU
Questo DS tiene traccia dell'utilizzo della CPU per 5 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.
Assicurarsi di aver abilitato SNMP utilizzando il comando mostra snmp. Se SNMP non è abilitato, configurare il gestore snmp-server comando.
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@<server name or ip>/DS_64224.xml bootflash:
Nome campo
Valore campo
Piattaforma
Software Cisco 4300, 4400 serie 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@<server name or ip>/DS_64224.xml bootflash:
Il seguente esempio mostra come copiare il 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 show call-home diagnostic-signature per verificare che la firma sia installata correttamente. La colonna dello stato deve avere 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 l'utilizzo elevato CPU sul gateway locale.
Monitoraggio delle disconnessioni delle chiamate anomale
Questa DS utilizza il sondaggio SNMP ogni 10 minuti per rilevare una disconnessione di chiamata anomala con errori SIP 403, 488 e 503. Se l'incremento del numero di errori è maggiore o uguale a 5 dall'ultimo sondaggio, genera un registro di sistema e una notifica e-mail. Utilizza la procedura seguente per installare la firma.
Assicurarsi che SNMP sia abilitato utilizzando il comando mostra snmp. Se SNMP non è abilitato, configurare il gestore snmp-server comando.
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 4300, 4400 serie ISR o Catalyst 8000V Edge
Prodotto
CUBE Enterprise in Webex Calling
Ambito del problema
Prestazioni
Tipo di problema
Rilevamento della disconnessione della chiamata anomala SIP con notifica e e-mail e syslog.
Copia il file XML DS nel gateway locale.
copy ftp://username:password@<server name or ip>/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 installata correttamente. La colonna dello stato deve contenere il valore "registered".
Installare le firme diagnostiche per risolvere un problema
Per risolvere rapidamente i problemi è possibile utilizzare le firme diagnostiche (DS). I tecnici di centro TAC di Cisco hanno creato diverse firme che consentono i debug necessari per risolvere un determinato problema, rilevare il problema che si verifica, raccogliere il set di dati diagnostici corretto e trasferire automaticamente i dati al caso centro TAC di Cisco . 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 il Strumento di ricerca firme diagnostiche per trovare le firme applicabili e installarle per risolvere autonomamente un determinato problema oppure è possibile installare la firma consigliata dal tecnico TAC come parte del coinvolgimento del 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" syslog e automatizza la raccolta dei dati diagnostici utilizzando la seguente procedura:
Configurare un'altra variabile di ambiente DSds_fsurl_prefix come percorso del file server centro TAC di Cisco (cxd.cisco.com) per caricare i dati di diagnostica. Il nome utente nel percorso file è il numero del caso e la password è il token caricamento file che può essere recuperato Support Case Manager come mostrato di seguito. Il token caricamento file può essere generato nel file Allegati sezione del Case Manager di supporto, come richiesto.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" end
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 mostra snmp. Se SNMP non è abilitato, configurare il gestore snmp-server comando.
show snmp %SNMP agent not enabled config t snmp-server manager end
È consigliabile installare il monitoraggio della CPU alta 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, 4400 serie ISR o Catalyst 8000V Edge
Prodotto
CUBE Enterprise in Webex Calling
Ambito del problema
Prestazioni
Tipo di problema
Utilizzo elevato CPU con notifica e-mail .
Scarica DS 65095 utilizzando le seguenti opzioni nello strumento DSLT:
Nome campo
Valore campo
Piattaforma
Software Cisco 4300, 4400 serie 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@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash:
Installare il file XML DS 64224 e DS 65095 per il monitoraggio della CPU alta 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 mostrare la firma diagnostica della chiamata-casa. 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
Verificare l'esecuzione delle firme diagnostiche
Nel comando seguente, la colonna "Stato" del comando show call-home diagnostic-signature passa a "in esecuzione" mentre il gateway locale esegue l'azione definita all'interno della firma. L'output di mostra le 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 "Triggered/Max/Deinstall" indica il numero di volte in cui la firma specificata ha attivato un evento, il numero massimo di volte in cui viene definito un evento per rilevare un evento e se la firma si disinstalla da sola 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 |
08/11/2020 00:07:45 |
65095 |
DS_LGW_IEC_Call_spike_threshold |
0.0.12 |
In esecuzione |
08/11/2020 00:12:53 |
mostra le statistiche della firma-diagnostica della chiamata a casa
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 |
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 di esecuzione e visualizza gli output dei comandi pertinenti per la risoluzione del problema specificato.
Disinstallare le firme diagnostiche
L'uso delle firme diagnostiche per la risoluzione dei problemi viene in genere definito per disinstallare dopo il rilevamento di alcune occorrenze del problema. Se si desidera disinstallare manualmente una firma, recuperare l' ID DS dall'output di show call-home diagnostic-signature ed eseguire il comando seguente:
call-home diagnostic-signature deinstall <DS ID>
Esempio:
call-home diagnostic-signature deinstall 64224
Nuove firme vengono aggiunte allo strumento di ricerca firme diagnostiche periodicamente, in base ai problemi riscontrati nelle distribuzioni. Il TAC attualmente non supporta richieste di creazione di nuove firme personalizzate. |
Nozioni fondamentali
Prerequisiti
Prima di distribuire CUBE HA come gateway locale per Webex Calling, accertarti di aver compreso pienamente i seguenti concetti:
Ridondanza box-to-box layer 2 con CUBE Enterprise per conservazione delle chiamate con stato
Le linee guida di configurazione fornite in questo articolo presuppongono una piattaforma gateway locale dedicata che non prevede alcuna configurazione vocale esistente. Se viene modificata una distribuzione CUBE Enterprise esistente per utilizzare anche la funzione gateway locale per Cisco Webex Calling, presta attenzione alla configurazione applicata per garantire che i flussi di chiamata e le funzionalità esistenti non vengano interrotte e che stai soddisfacendo i requisiti di progettazione CUBE HA.
Componenti hardware e software
CUBE HA come gateway locale richiede IOS-XE versione 16.12.2 o successiva e una piattaforma su cui sono supportate entrambe le funzioni CUBE HA e LGW.
I comandi show e i registri in questo articolo si basano sulla release software minima di Cisco IOS-XE 16.12.2 implementata su vCUBE (CSR1000v). |
Materiale di riferimento
Di seguito sono riportate alcune guide alla configurazione di CUBE HA dettagliate per diverse piattaforme:
Serie ISR 4K— https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-ISR4K.html
CSR 1000v (vCUBE)– https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
Architettura preferita Cisco per Cisco Webex Calling– https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Panoramica della soluzione Webex Calling
Cisco Webex Calling è un servizio di collaborazione che offre un'alternativa basata su cloud multi-tenant al servizio telefonico PBX locale con più opzioni PSTN per i clienti.
La distribuzione del gateway locale (rappresentata di seguito) è il fulcro di questo articolo. Il trunk del gateway locale (PSTN locale) in Webex Calling consente la connettività a un servizio PSTN di proprietà del cliente. Fornisce anche la connettività a una distribuzione PBX IP locale, ad esempio Cisco Unified CM. Tutte le comunicazioni da e verso il cloud vengono protette utilizzando il trasporto TLS per SIP e SRTP per contenuti multimediali.
La figura seguente mostra una distribuzione Webex Calling senza un PBX IP esistente ed è applicabile a una distribuzione per singolo sito o più siti. La configurazione descritta in questo articolo si basa su questa distribuzione.
Ridondanza box-to-box layer 2
La ridondanza box-to-box layer 2 CUBE HA utilizza il protocollo dell'infrastruttura RG (Redundancy Group) per formare una coppia di router attivo/standby. Questa coppia condivide lo stesso indirizzo IP virtuale (VIP) sulle relative interfacce e scambia continuamente messaggi di stato. Le informazioni di sessione CUBE vengono verificate sulla coppia di router consentendo al router standby di assumere immediatamente tutte le responsabilità di elaborazione delle chiamate CUBE se il router attivo è fuori uso, in modo da preservare segnali e contenuti multimediali.
La verifica è limitata a chiamate connesse con pacchetti multimediali. Le chiamate in transito non vengono verificate (ad esempio, tentativi di chiamata o chiamate che squillano in attesa di risposta). In questo articolo, CUBE HA fa riferimento alla ridondanza CUBE High Availability (HA) Box-to-box (B2B) layer 2 per la conservazione delle chiamate con stato |
A partire da IOS-XE 16.12.2, CUBE HA può essere distribuito come gateway locale per distribuzioni di trunk Cisco Webex Calling (PSTN locale) e in questo articolo verranno riportate alcune considerazioni di progettazione e configurazioni. L'immagine mostra una tipica impostazione di CUBE HA come gateway locale per una distribuzione di trunk Cisco Webex Calling.
Componente Infra del gruppo di ridondanza
Il componente Infra del gruppo di ridondanza (RG, Redundancy Group) fornisce il supporto dell'infrastruttura di comunicazione box-to-box tra i due CUBE e negozia lo stato di ridondanza stabile finale. Questo componente fornisce anche:
Un protocollo simile a HSRP che negozia lo stato di ridondanza finale per ciascun router scambiando messaggi keepalive e hello tra i due CUBE (tramite l'interfaccia di controllo), GigabitEthernet3 nella figura precedente.
Un meccanismo di trasporto per la verifica dello stato di segnali e contenuti multimediali per ciascuna chiamata dal router attivo al router standby (tramite l'interfaccia dati), GigabitEthernet3 nella figura precedente.
Configurazione e gestione dell'interfaccia IP virtuale (VIP) per le interfacce di traffico (più interfacce di traffico possono essere configurate utilizzando lo stesso gruppo RG), GigabitEthernet 1 e 2 sono considerate interfacce di traffico.
Questo componente RG deve essere configurato in modo specifico per supportare il sistema vocale B2B HA.
Gestione degli indirizzi IP virtuali (VIP) per segnali e contenuti multimediali
B2B HA si basa sull'IP virtuale per ottenere ridondanza. Il VIP e le interfacce fisiche associate su entrambi i CUBE nella coppia CUBE HA devono risiedere sulla stessa subnet LAN. La configurazione del VIP e l'associazione dell'interfaccia VIP a una determinata applicazione vocale (SIP) sono obbligatorie per il supporto vocale B2B HA. I dispositivi esterni come Unified CM, controller SBC di accesso a Webex Calling, provider di servizi o proxy, utilizzano il VIP come indirizzo IP di destinazione per le chiamate che attraversano i router CUBE HA. Pertanto, dal punto di vista di Webex Calling, le coppie di CUBE HA agiscono come un singolo gateway locale.
Le informazioni su segnale di chiamata e sessione RTP delle chiamate stabilite vengono verificate dal router attivo al router di standby. Quando il router Attivo non è attivo, il router Standby subentra e continua a inoltrare il flusso RTP precedentemente indirizzato dal primo router.
Le chiamate in uno stato temporaneo al momento del failover non verranno mantenute dopo il cambio. Ad esempio, le chiamate non ancora completamente stabilite o in corso di modifica con una funzione di trasferimento o attesa. Le chiamate stabilite possono essere disconnesse dopo il cambio.
Esistono i seguenti requisiti per l'uso di CUBE HA come gateway locale per il failover delle chiamate:
CUBE HA non può avere interfacce TDM o analogiche co-posizionate
Le interfacce Gig1 e Gig2 sono denominate interfacce di traffico (SIP/RTP) e Gig3 è l'interfaccia di controllo RG/dati
Non è possibile inserire più di 2 coppie CUBE HA nello stesso dominio layer 2, una con ID gruppo 1 e l'altra con ID gruppo 2. Se configuri 2 coppie HA con lo stesso ID gruppo, le interfacce di controllo RG/dati devono appartenere a domini layer 2 diversi (vlan, switch separato)
Il canale delle porte è supportato per entrambe le interfacce di controllo RG/dati e di traffico
Tutti i segnali/contenuti multimediali sono originati da/all'indirizzo IP virtuale
Ogni volta che una piattaforma viene ricaricata in una relazione CUBE-HA, viene sempre avviata come Standby
L'indirizzo inferiore per tutte le interfacce (Gig1, Gig2, Gig3) deve essere sulla stessa piattaforma
L'identificativo dell'interfaccia di ridondanza, rii, deve essere univoco per una combinazione di coppia/interfaccia nello stesso Layer 2
La configurazione su entrambi i CUBE deve essere identica, inclusa la configurazione fisica, e deve essere in esecuzione sullo stesso tipo di piattaforma e versione IOS-XE
Non è possibile utilizzare interfacce di loopback come associazione perché sono sempre attive
Più interfacce di traffico (SIP/RTP) (Gig1, Gig2) richiedono la configurazione del rilevamento dell'interfaccia
CUBE-HA non è supportato su una connessione via cavo crossover per il collegamento controllo RG/dati (Gig3)
Entrambe le piattaforme devono essere identiche e connesse tramite uno switch fisico su tutte le interfacce simili affinché CUBE HA funzioni, ossia GE0/0/0 di CUBE-1 e CUBE-2 devono terminare sullo stesso switch e così via.
Non è possibile impostare WAN con terminazione diretta su CUBE o Data HA su entrambi i lati
Entrambi i router, Attivo/Standby, devono essere nello stesso centro dati
È obbligatorio utilizzare un'interfaccia L3 separata per ridondanza (controllo RG/dati, Gig3), ossia l'interfaccia utilizzata per il traffico non può essere utilizzata per keepalive e verifica HA
Al momento del failover, il CUBE precedentemente attivo passa attraverso un ricaricamento per impostazione predefinita, preservando segnali e contenuti multimediali
Configurazione della ridondanza su entrambi i CUBE
Devi configurare la ridondanza box-to-box layer 2 su entrambi i CUBE da utilizzare in una coppia HA per visualizzare IP virtuali.
1 | Configura il rilevamento dell'interfaccia a livello globale per rilevare lo stato dell'interfaccia.
La CLI di rilevamento viene utilizzata in RG per rilevare lo stato dell'interfaccia di traffico vocale in modo che il router attivo esca dal ruolo attivo una volta disattivata l'interfaccia di traffico. | ||||||
2 | Configura un RG per l'uso con VoIP HA nella modalità secondaria di ridondanza dell'applicazione.
Di seguito una spiegazione dei campi utilizzati in questa configurazione:
| ||||||
3 | Abilita la ridondanza box-to-box per l'applicazione CUBE. Configura l'RG dal passaggio precedente in
redundancy-group 1: l'aggiunta e la rimozione di questo comando richiede un ricaricamento per applicare la configurazione aggiornata. Le piattaforme verranno ricaricate una volta applicata la configurazione. | ||||||
4 | Configura le interfacce Gig1 e Gig2 con i relativi IP virtuali come mostrato di seguito e applica l'identificativo dell'interfaccia di ridondanza (rii)
Di seguito una spiegazione dei campi utilizzati in questa configurazione:
| ||||||
5 | Salva la configurazione del primo CUBE e ricaricala. La piattaforma da ricaricare per ultima è sempre Standby.
Dopo aver avviato completamente VCUBE-1, salva la configurazione di VCUBE-2 e ricaricala.
| ||||||
6 | Verifica che la configurazione box-to-box funzioni come previsto. L'output rilevante è evidenziato in grassetto. VCUBE-2 è stato ricaricato per ultimo e in base alle considerazioni di progettazione; la piattaforma da ricaricare per ultima sarà sempre Standby.
|
Configurazione di un gateway locale su entrambi i CUBE
Nella configurazione dell'esempio, stiamo utilizzando le seguenti informazioni di trunk di Control Hub per creare la configurazione del gateway locale su entrambe le piattaforme, VCUBE-1 e VCUBE-2. Il nome utente e la password per questa impostazione sono i seguenti:
Nome utente: Hussain1076_LGU
Password: lOV12MEaZx
1 | Assicurati che venga creata una chiave di configurazione per la password, con i comandi shown di seguito, prima di poterla utilizzare in credenziali o segreti condivisi. Le password di tipo 6 sono crittografate utilizzando cifratura AES e questa chiave di configurazione definita dall'utente.
Questa è la configurazione del gateway locale che verrà applicata a entrambe le piattaforme in base ai parametri di Control Hub visualizzati sopra, salva e ricarica. Le credenziali SIP digest di Control Hub sono evidenziate in grassetto.
Per visualizzare l'output del comando show, è stato ricaricato VCUBE-2 seguito da VCUBE-1, rendendo VCUBE-1 il CUBE standby e VCUBE-2 il CUBE attivo |
2 | In un determinato momento, solo una piattaforma manterrà una registrazione attiva come gateway locale con il controller SBC di accesso a Webex Calling. Dai un'occhiata all'output dei seguenti comandi show. show redundancy application group 1 mostra stato registrazione sip-ua
Dall'output precedente, puoi vedere che VCUBE-2 è l'LGW attivo che mantiene la registrazione con l'SBC di accesso a Webex Calling, mentre l'output del comando "show sip-ua register status" è vuoto in VCUBE-1 |
3 | Ora abilita i seguenti debug su VCUBE-1
|
4 | Simula il failover specificando il seguente comando sull'LGW attivo, VCUBE-2 in questo caso.
Il passaggio dall'LGW ACTIVE a STANDBY si verifica nei seguenti casi oltre alla CLI sopra elencata
|
5 | Controlla se VCUBE-1 è stato registrato con il controller SBC di accesso a Webex Calling. VCUBE-2 dovrebbe essere stato ricaricato ora.
VCUBE-1 è ora l'LGW attivo. |
6 | Esamina il registro di debug pertinente su VCUBE-1 inviando un SIP REGISTER a Webex Calling tramite IP virtuale e ricevendo un 200 OK.
|
Configurazione del profilo di sicurezza del trunk SIP per il trunk al gateway locale
Nei casi in cui il gateway locale e il gateway PSTN risiedano sullo stesso dispositivo, Unified CM deve essere abilitato per distinguere due diversi tipi di traffico (chiamate da Webex e dalla PSTN) che hanno origine dallo stesso dispositivo e applicare una classe differenziata di servizio a questi tipi di chiamata. Questo tipo di gestione differenziata delle chiamate viene realizzato predisponendo due trunk tra Unified CM e il gateway locale combinato e un dispositivo gateway PSTN che richiede porte di ascolto SIP diverse per i due trunk.
Crea un profilo di sicurezza del trunk SIP dedicato per il trunk del gateway locale con le seguenti impostazioni:
|
Configurazione del profilo SIP per il trunk del gateway locale
Crea un profilo SIP dedicato per il trunk del gateway locale con le seguenti impostazioni:
|
Creazione di uno spazio di ricerca di chiamata per le chiamate da Webex
Crea uno spazio di ricerca chiamata per le chiamate provenienti da Webex con le seguenti impostazioni:
|
Configurazione di un trunk SIP da e verso Webex
Crea un trunk SIP per le chiamate da e verso Webex attraverso il gateway locale con le seguenti impostazioni:
|
Configurazione del gruppo di indirizzamento per Webex
Crea un gruppo di indirizzamento con le seguenti impostazioni:
|
Configurazione dell'elenco di indirizzamento per Webex
Crea un elenco di indirizzamento con le seguenti impostazioni:
|
Creazione di una partizione per le destinazioni Webex
Crea una partizione per le destinazioni Webex con le seguenti impostazioni:
|
Operazioni successive
Accertati di aggiungere questa partizione a tutti gli spazi di ricerca chiamata che devono avere accesso alle destinazioni Webex. Devi aggiungere questa partizione in modo specifico allo spazio di ricerca chiamata utilizzato come spazio di ricerca di chiamata in ingresso sui trunk PSTN, in modo che le chiamate dalla PSTN a Webex possano essere indirizzate.
Configurazione dei percorsi di indirizzamento per le destinazioni Webex
Configura i percorsi di indirizzamento per ogni intervallo DID su Webex con le seguenti impostazioni:
|
Configurazione della normalizzazione chiamata intersito abbreviata per Webex
Se è richiesta la chiamata intersito abbreviata a Webex, configura gli schemi di normalizzazione chiamata per ciascun intervallo ESN su Webex con le seguenti impostazioni:
|
Imposta un gruppo di ricerca di risposta
I gruppi di risposta indirizzano le chiamate in arrivo a un gruppo di utenti o spazi di lavoro. Puoi persino configurare un percorso per l'indirizzamento a un intero gruppo.
Per ulteriori informazioni su come impostare un gruppo di ricerca di risposta , vedere Gruppi di ricerca in Cisco Webex Control Hub .
Creazione di una coda chiamata
Puoi impostare una coda chiamate in modo che quando non è possibile rispondere alle chiamate dei clienti, viene fornita loro una risposta automatica, messaggi di cortesia e musica di attesa finché qualcuno non risponde alla chiamata.
Per ulteriori informazioni su come impostare e gestire una coda chiamate, vedere Gestire le code di chiamata in Cisco Webex Control Hub .
Creare un client centralinista
Il client receptionist assiste nel supporto delle esigenze del personale di front-office. È possibile impostare gli utenti come assistenti telefonici in modo che possano eseguire il screening delle chiamate in arrivo verso determinate persone all'interno dell'organizzazione.
Per informazioni su come impostare e visualizzare i client receptionist, vedi Client receptionist in Cisco Webex Control Hub.
Creare e gestire operatori automatici
Puoi aggiungere messaggi di saluto, impostare menu e indirizzare le chiamate a un servizio di risposta, a un gruppo di risposta, a una casella vocale o a una persona reale. Crea una pianificazione di 24 ore o fornisci diverse opzioni quando l'azienda è aperta o chiusa.
Per informazioni su come creare e gestire operatori automatici, vedere Gestire gli operatori automatici in Cisco Webex Control Hub .
Configurare un gruppo di cercapersone
Il servizio di chiamata di gruppo consente a un utente di effettuare una chiamata unidirezionale o un servizio di chiamata di gruppo a un massimo di 75 utenti e spazi di lavoro di destinazione componendo un numero o un interno assegnato a un gruppo di cercapersone specifico.
Per informazioni su come impostare e modificare i gruppi di cercapersone, vedere Configurazione di un gruppo di cercapersone in Cisco Webex Control Hub .
Imposta la funzione di risposta per assente
Migliora il lavoro in team e la collaborazione creando un gruppo di risposta per assente di risposta per assente in modo che gli utenti possano rispondere reciprocamente alle chiamate. Quando aggiungi utenti a un gruppo di risposta per assente e un membro del gruppo è assente o è occupato, un altro membro può rispondere alle sue chiamate.
Per informazioni su come impostare un gruppo di risposta per assente, vedi Risposta per assente in Cisco Webex Control Hub.
Imposta parcheggio chiamata
Il parcheggio chiamata consente a un gruppo definito di utenti di parcheggiare le chiamate su altri membri disponibili di un gruppo di parcheggio chiamata. Alle chiamate parcheggiate possono rispondere altri membri del gruppo sul proprio telefono.
Per ulteriori informazioni sull'impostazione del parcheggio chiamata, vedi Parcheggio chiamata in Cisco Webex Control Hub.
Abilita inclusione per gli utenti
1 | Dalla vista cliente in , vai a Chiamata > Posizioni.https://admin.webex.com |
2 | Seleziona un utente e fai clic su Calling. |
3 | Andare alla sezione Autorizzazioni tra utenti, quindi selezionare Inclusione. |
4 | Attiva il tasto di alternanza per consentire ad altri utenti di aggiungersi alla chiamata in corso di questo utente. |
5 | Selezionare Riproduci un tono quando questo utente partecipa a una chiamata se si desidera riprodurre un tono agli altri quando questo utente partecipa alla chiamata. |
6 | Fai clic su Salva. |
Abilita privacy per un utente
1 | Accedi a Control Hub e vai a . | ||
2 | Scegli un utente e fai clic su Chiamata. | ||
3 | Andare all'area Autorizzazioni tra utenti e scegliere Privacy. | ||
4 | Scegli le impostazioni di Privacy operatore automatico appropriate per questo utente.
| ||
5 | Seleziona la casella di controllo Abilita privacy. Puoi quindi decidere di bloccare tutti non scegliendo membri dall'elenco a discesa. In alternativa, puoi scegliere gli utenti, gli spazi di lavoro e le linee virtuali che possono monitorare lo stato della linea di questo utente. Se sei un amministratore di posizione, solo gli utenti, gli spazi di lavoro e le linee virtuali relative alle tue posizioni assegnate vengono visualizzati nell'elenco a discesa. Deselezionare la casella di controllo Abilita privacy per consentire a tutti di monitorare lo stato della linea. | ||
6 | Seleziona la casella di controllo Applica privacy per risposta per assente indirizzata e inclusione per abilitare la privacy per risposta per assente indirizzata e inclusione.
| ||
7 | Da Aggiungi membro per nome, scegli utenti, spazi di lavoro e linee virtuali che possono monitorare lo stato della linea telefonica e richiamare risposta per assente indirizzata e inclusione. | ||
8 | Per filtrare i membri selezionati, utilizzare il filtro per nome, numero o campo interno. | ||
9 | Fare clic su Rimuovi tutto per rimuovere tutti i membri selezionati.
| ||
10 | Fai clic su Salva. |
Configura monitoraggio
Il numero massimo di linee monitorate per un utente è 50. Tuttavia, durante la configurazione dell'elenco di monitoraggio, considera il numero di messaggi che incidono sulla larghezza di banda tra Webex Calling e la rete. Inoltre, determinare il numero massimo di linee monitorate in base al numero di pulsanti linea sul telefono dell'utente.
1 | Dalla vista cliente in https://admin.webex.com, andare a Gestione, quindi fare clic su Utenti. | ||||
2 | Seleziona l'utente che desideri modificare e fai clic su Chiamata. | ||||
3 | Andare alla sezione Autorizzazioni tra utenti e selezionare Monitoraggio. | ||||
4 | Scegliere una delle opzioni seguenti:
È possibile includere una linea virtuale nell'elenco Aggiungi linea monitorata per il monitoraggio degli utenti. | ||||
5 | Scegli se desideri notificare a questo utente le chiamate parcheggiate, cerca la persona o l'interno del parcheggio chiamata da monitorare, quindi fai clic su Salva.
|
Abilita segnale di avviso bridge chiamata per gli utenti
Operazioni preliminari
1 | Accedi a Control Hub e vai a . | ||
2 | Seleziona un utente e fai clic sulla scheda Chiamata. | ||
3 | Vai a Autorizzazioni tra utenti e fai clic su Segnale di avviso bridge chiamata. | ||
4 | Attivare Tono di avviso ponte chiamata , quindi fare clic su Salva .
Per ulteriori informazioni sul bridge di chiamata su una linea condivisa MPP, vedere Linee condivise sul telefono fisso multipiattaforma. Per ulteriori informazioni sul bridge di chiamata su una linea condivisa dell'app Webex, vedi Identificativo di linea condivisa per WebexApp. |
Attiva la modalità hotel per un utente
1 | Dalla vista cliente inhttps://admin.webex.com , andare a Gestione e selezionare Utenti . | ||
2 | Seleziona un utente e fai clic sulla scheda Chiamata. | ||
3 | Vai alla sezione Autorizzazioni tra utenti e seleziona Modalità hotel e attiva il tasto di alternanza. | ||
4 | Immettere il nome o il numero dell'organizzatore della modalità hotel nel campo di ricerca Posizione modalità hotel e scegliere l'organizzatore della modalità hotel che si desidera assegnare all'utente. È possibile selezionare un solo organizzatore hotel. Se scegli un altro organizzatore hotel, il primo viene eliminato.
| ||
5 | Per limitare il tempo di associazione di un utente all'host della modalità hotel, scegliere il numero di ore in cui l'utente può utilizzare l'host della modalità hotel dall'elenco a discesa Limite periodo di associazione. L'utente verrà disconnesso automaticamente dopo l'ora scelta.
| ||
6 | Fai clic su Salva.
|
Visualizza report chiamata
Puoi utilizzare la pagina Analisi in Control Hub per ottenere informazioni su come le persone utilizzano Webex Calling e l'app Webex (coinvolgimento) nonché sulla qualità della loro esperienza multimediale di chiamata. Per accedere all'analisi Webex Calling, accedi a Control Hub, quindi vai ad Analisi e seleziona la scheda Chiamata.
1 | Per report dettagliati cronologia chiamate , accedere a Control Hub , quindi andare a Analisi > Chiamata . |
2 | Selezionare Cronologia chiamate dettagliata . Per informazioni sulle chiamate tramite istanza dedicata, vedi Analisi istanza dedicata. |
3 | Per accedere ai dati di qualità multimediale, accedi a Control Hub, quindi vai ad Analisi e seleziona Chiamata. Per ulteriori informazioni, vedi Analisi per il tuo portfolio Cloud Collaboration.
|
Eseguire lo strumento CScan
CScan è uno strumento di preparazione della rete progettato per testare la connessione di rete a Webex Calling.
Per ulteriori informazioni, vedi Uso di CScan per testare la qualità della rete Webex Calling. |
Prerequisiti generali
Prima di configurare un gateway locale per Webex Calling, assicurati di:
Avere una conoscenza di base dei principi VoIP
Avere una conoscenza del funzionamento di base dei concetti vocali di Cisco IOS-XE e IOS-XE
Avere una comprensione di base del protocollo SIP (Session Initiation Protocol)
Avere una conoscenza di base di Cisco Unified Communications Manager (Unified CM), se il tuo modello di distribuzione include Unified CM
Per informazioni dettagliate, consultare la Guida alla configurazione aziendale di Cisco Unified Border Element (CUBE).
Requisiti hardware e software per gateway locale
Accertarsi che la distribuzione disponga di uno o più gateway locali, ad esempio:
Cisco CUBE per la connettività basata su IP
Gateway Cisco IOS per connettività basata su TDM
Il gateway locale ti aiuta a eseguire la migrazione a Webex Calling al tuo ritmo. Il gateway locale integra la distribuzione locale esistente con Webex Calling. È inoltre possibile utilizzare la connessione PSTN esistente. Vedi Introduzione al gateway locale
Requisiti di licenza per gateway locali
Le licenze di chiamata CUBE devono essere installate sul gateway locale. Per ulteriori informazioni, vedi la Guida alla configurazione CUBE.
Requisiti di certificati e sicurezza per gateway locale
Webex Calling richiede segnali e contenuti multimediali sicuri. Il gateway locale esegue la crittografia e una connessione TLS deve essere stabilita in uscita al cloud completando la seguente procedura:
LGW deve essere aggiornato con il bundle radice CA di PKI Cisco
Un set di credenziali digest SIP della pagina di configurazione del trunk di Control Hub viene utilizzato per configurare LGW (le operazioni fanno parte della configurazione seguente)
Il bundle radice CA convalida il certificato presentato
Richiesta delle credenziali (digest SIP fornito)
Il cloud identifica il gateway locale registrato in modo sicuro
Requisiti firewall, attraversamento NAT, ottimizzazione percorso multimediale per gateway locale
Nella maggior parte dei casi, il gateway locale e gli endpoint possono risiedere nella rete del cliente interna, che utilizza indirizzi IP privati con NAT. Il firewall aziendale deve consentire il traffico in uscita (SIP, RTP/UDP, HTTP) a specifici indirizzi IP/porte, indicati nelle Informazioni di riferimento porta.
Se desideri utilizzare l'ottimizzazione del percorso multimediale con ICE, l'interfaccia rivolta verso Webex Calling del gateway locale deve avere un percorso di rete diretto a/da endpoint Webex Calling. Se gli endpoint si trovano in una posizione diversa e non esiste un percorso di rete diretto tra gli endpoint e l'interfaccia rivolta verso Webex Calling del gateway locale, il gateway locale deve disporre di un indirizzo IP pubblico assegnato all'interfaccia rivolta verso Webex Calling per le chiamate tra il gateway locale e gli endpoint per utilizzare l'ottimizzazione del percorso multimediale. Inoltre, deve essere in esecuzione IOS-XE versione 16.12.5.
Il primo passo per iniziare rapidamente a utilizzare i servizi Webex Calling consiste nel completare la procedura di installazione guidata iniziale (FTSW). Una volta completata la FTSW per la prima posizione, non deve essere completata per altre posizioni.
1 | Fai clic sul collegamento Introduzione nel messaggio e-mail di benvenuto che hai ricevuto.
| ||
2 | Rivedi e accetta del condizioni del servizio. | ||
3 | Rivedi il tuo piano e fai clic su Introduzione.
| ||
4 | Seleziona il paese a cui associare il tuo centro dati e inserisci le informazioni di contatto e indirizzo del cliente. | ||
5 | Fai clic su Avanti: Posizione predefinita. | ||
6 | Selezionare una delle opzioni seguenti:
| ||
7 | Effettua le seguenti selezioni da applicare a questa posizione:
| ||
8 | Fai clic su Avanti. | ||
9 | Inserisci un indirizzo SIP Cisco Webex disponibile e fai clic su Avanti, quindi seleziona Fine. |
Operazioni preliminari
Per creare una nuova posizione, prepara le seguenti informazioni:
Indirizzo posizione
Numeri di telefono desiderati (opzionale)
1 | Accedere a Control Hub all'indirizzohttps://admin.webex.com , andare a .
| ||||
2 | Configura le impostazioni della posizione:
| ||||
3 | Fare clic su Salva e scegliere Sì / No per aggiungere numeri alla posizione ora o successivamente. | ||||
4 | Se hai fatto clic su Aggiungi ora, scegli una delle seguenti opzioni:
La scelta dell'opzione PSTN è a livello di posizione (ciascuna posizione dispone di una sola opzione PSTN). Puoi combinare e associare il numero di opzioni desiderato per la tua distribuzione ma ogni posizione avrà una sola opzione. Una volta selezionata un'opzione PSTN ed eseguito il provisioning, puoi modificarla facendo clic su Gestisci nelle proprietà PSTN della posizione. Tuttavia, alcune opzioni come Cisco PSTN potrebbero non essere disponibili in seguito all'assegnazione di un'altra opzione. Apri una richiesta di supporto per indicazioni. | ||||
5 | Scegli se attivare i numeri ora o in un secondo momento. | ||||
6 | Se hai selezionato la CCP non integrata o la PSTN locale, inserisci i Numeri di telefono come valori separati da virgola, quindi fai clic su Convalida. I numeri vengono aggiunti per la posizione specifica. Le voci valide vengono spostate nel campo Numeri convalidati e le voci non valide rimangono nel campo Aggiungi numeri, insieme a un messaggio di errore. A seconda del paese della posizione, i numeri vengono formattati in modo conforme ai requisiti di chiamata locali. Ad esempio, se è necessario un prefisso, puoi inserire i numeri con o senza il prefisso e il prefisso viene aggiunto all'inizio. | ||||
7 | Fai clic su Salva. |
Operazioni successive
Una volta creata una posizione, puoi abilitare i servizi di emergenza per tale posizione. Per ulteriori informazioni, vedi Servizio RedSky di Webex Calling.
Operazioni preliminari
Ottieni un elenco degli utenti e degli spazi di lavoro associati a una posizione: Vai a Servizi > Numeri e dal menu a discesa seleziona la posizione da eliminare.eliminare tali utenti e spazi di lavoro. Prima di eliminare una posizione, deviTieni presente che qualsiasi numero associato a questa posizione verrà restituito al provider PSTN e non sarai più proprietario di tali numeri. |
1 | Accedere a Control Hub all'indirizzohttps://admin.webex.com , andare a . |
2 | Fare clic |
3 | Scegliere Elimina posizione , e confermare che si desidera eliminare la posizione. Solitamente bastano pochi minuti per eliminare in modo permanente la posizione, ma potrebbe essere necessaria fino a un'ora. Puoi controllare lo stato facendo clic su Altro accanto al nome della posizione e selezionando Stato eliminazione. |
Puoi modificare l'impostazione PSTN nonché il nome, il fuso orario e la lingua di una posizione una volta creata. Tieni presente che la nuova lingua si applica solo ai nuovi utenti e dispositivi. Gli utenti e i dispositivi esistenti continuano a utilizzare la lingua precedente.
Per le posizioni esistenti, puoi abilitare i servizi 911 di emergenza. Per ulteriori informazioni, vedi Servizio RedSky di Webex Calling. |
1 | Accedere a Control Hub all'indirizzohttps://admin.webex.com , andare a . Se accanto a una posizione viene visualizzato il simbolo di attenzione, significa che non hai ancora configurato un numero di telefono per tale posizione. Non è possibile effettuare o ricevere chiamate finché non si configura questo numero. | ||||||
2 | (Opzionale) In Connessione PSTN, seleziona PSTN connessa al cloud o PSTN locale (gateway locale), in base a quale hai già configurato. Fai clic su Gestisci per modificare la configurazione e confermare i rischi associati selezionando Continua. Quindi, scegli una delle seguenti opzioni e fai clic su Salva:
| ||||||
3 | Seleziona il Numero principale al quale può essere raggiunto il contatto principale della posizione. | ||||||
4 | (Opzionale) Sotto Chiamata di emergenza , è possibile selezionare ID posizione di emergenza per assegnare a questa posizione.
| ||||||
5 | Seleziona il Numero della casella vocale che gli utenti possono chiamare per controllare la propria casella vocale per questa posizione. | ||||||
6 | (Opzionale) Fai clic sull'icona della matita nella parte superiore della pagina Posizione per modificare Nome posizione, Fuso orario o Lingua come necessario, quindi, fai clic su Salva.
|
Queste impostazioni per la chiamata interna sono disponibili anche nella procedura iniziale di installazione guidata. Quando modifichi il piano di chiamata, i numeri di esempio nell'aggiornamento di Control Hub visualizzano queste modifiche.
Puoi configurare le autorizzazioni per le chiamate in uscita per una posizione. Vedi questi passaggi per configurare le autorizzazioni per le chiamate in uscita. |
1 | Accedi a Control Hub, vai a , quindi scorrere fino a Chiamata interna. | ||||||||
2 | Configura le seguenti preferenze di chiamata opzionali in base alle tue esigenze:
| ||||||||
3 | Specifica la chiamata interna per posizioni specifiche. Vai a Chiamata. Scorrere fino a Composizione, quindi modificare la composizione interna come necessario: , seleziona una posizione dall'elenco e fai clic su
| ||||||||
4 | Specifica la chiamata esterna per posizioni specifiche. Vai a Chiamata. Scorrere fino a Chiamata, quindi modificare la chiamata esterna come necessario: , seleziona una posizione dall'elenco e fai clic su
Impatto sugli utenti:
|
Se sei un rivenditore a valore aggiunto (VAR), puoi utilizzare questa procedura per avviare la configurazione del gateway locale in Control Hub. Quando questo gateway è registrato sul cloud, puoi utilizzarlo in una o più posizioni Webex Calling per fornire l'indirizzamento a un provider di servizi PSTN aziendale.
Una posizione che dispone di un gateway locale non può essere eliminata quando il gateway locale viene utilizzato per altre posizioni. |
Operazioni preliminari
Una volta aggiunta una posizione e prima di configurare il PSTN locale per una posizione, devi creare un trunk.
Crea posizioni e impostazioni e numeri specifici per ciascuno di essi. Le posizioni devono esistere prima di poter aggiungere un PSTN locale.
Comprendi i requisiti di PSTN locali (gateway locale) per Webex Calling.
Non puoi scegliere più di un trunk per una posizione con PSTN locale, ma puoi scegliere lo stesso trunk per più posizioni.
1 | Accedere a Control Hub alle , andare a Servizi > Chiamata > Indirizzamento chiamata , e selezionare Aggiungere trunk .https://admin.webex.com | ||
2 | Seleziona una posizione. | ||
3 | Assegna un nome al trunk e fai clic su Salva.
|
Operazioni successive
Le informazioni sul trunk vengono visualizzate nella schermata Registra dominio, OTG/DTG gruppo trunk, Linea/Porta e Indirizzo proxy in uscita.
È consigliabile copiare queste informazioni da Control Hub e incollarle in un file di testo locale o un documento in modo da utilizzarlo come riferimento quando sei pronto a configurare il PSTN locale.
Se hai perso le credenziali, devi generarle dalla schermata delle informazioni sul trunk in Control Hub. Fai clic su Recupera nome utente e reimposta password per generare un nuovo set di credenziali di autenticazione da utilizzare sul trunk.
1 | Accedere a Control Hub all'indirizzohttps://admin.webex.com , andare a . | ||
2 | Seleziona una posizione da modificare e fai clic su Gestisci. | ||
3 | Seleziona PSTN locale e fai clic su Avanti. | ||
4 | Scegli un trunk dal menu a discesa.
| ||
5 | Fai clic sull'avviso di conferma, quindi fai clic su Salva. |
Operazioni successive
Devi utilizzare le informazioni di configurazione generate da Control Hub e mappare i parametri nel gateway locale (ad esempio, su un Cisco CUBE che si trova in loco). Questo articolo ti guida attraverso questo processo. Come riferimento, vedi il diagramma seguente per un esempio del modo in cui le informazioni di configurazione di Control Hub (a sinistra) vengono associate ai parametri nel CUBE (a destra):
Dopo aver completato correttamente la configurazione sul gateway stesso, puoi tornare a Servizi > Chiamata > Posizioni in Control Hub e il gateway creato verrà elencato nella scheda di posizione a cui è stato assegnato con un punto verde alla sinistra del nome.
Questo stato indica che il gateway è registrato in modo sicuro sul cloud di chiamata e viene utilizzato come gateway PSTN attivo per la posizione.Puoi facilmente visualizzare, attivare, rimuovere e aggiungere i numeri di telefono per la tua organizzazione in Control Hub. Per ulteriori informazioni, vedi Gestione dei numeri di telefono in Control Hub.
Se stai provando i servizi Webex e desideri convertire la tua versione di prova in un abbonamento a pagamento, puoi inviare una richiesta e-mail al partner.
1 | Accedi a Control Hub su https://admin.webex.com, seleziona l'icona dell'edificio |
2 | Seleziona la scheda Abbonamenti, quindi fai clic su Acquista ora. Viene inviato un messaggio e-mail al partner per informarlo che sei interessato alla conversione in un abbonamento a pagamento. |
Puoi utilizzare Control Hub per impostare la priorità delle opzioni di chiamata disponibili che gli utenti visualizzano in Webex App. Puoi anche abilitarli per le chiamate con singolo clic. Per ulteriori informazioni, vedere: Imposta le opzioni di chiamata per gli utenti dell'app Webex .
È possibile controllare quale applicazione di chiamata viene aperta quando gli utenti effettuano le chiamate. È possibile configurare le impostazioni del client di chiamata, inclusa la distribuzione in modalità mista per organizzazioni con utenti autorizzati Unified CM o Webex Calling e gli utenti senza servizi di chiamata a pagamento di Cisco. Per ulteriori informazioni, vedere: Imposta funzionamento chiamata.
Panoramica
Webex Calling attualmente supporta due versioni del gateway locale:
Gateway locale
Gateway locale per Webex for Government
Prima di iniziare, comprendi i requisiti di rete telefonica commutata pubblica (PSTN) e gateway locale (LGW) per Webex Calling. Vedere Architettura Cisco Preferred per Webex Calling per ulteriori informazioni.
Questo articolo presuppone l'esistenza di una piattaforma gateway locale dedicata senza configurazione vocale. 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 ai comandi dei gateway gestiti Webex se non diversamente indicato (in tal caso, i collegamenti al comando vanno a Riferimento per i comandi vocali Cisco IOS ). È possibile accedere a tutte queste guide in Cisco Unified Border Element Command References. Per informazioni sui SBC supportati da terze parti si rimanda alla rispettiva documentazione di riferimento del prodotto. |
Sono disponibili due opzioni per configurare il gateway locale per il Webex Calling tronco:
Trunk basato su registrazione
Trunk basato su certificato
Utilizzare il flusso di attività sotto il file Gateway locale basato su registrazione o Gateway locale basato su certificato per configurare il gateway locale per il Webex Calling tronco.
Vedi Introduzione al gateway locale per ulteriori informazioni sui diversi tipi di trunk. Completare la seguente procedura sul gateway locale stesso, utilizzando l'interfaccia della riga di comando (CLI). Usiamo il Session Initiation Protocol (SIP) e il trasporto TLS ( Transport Layer Security ) per proteggere il trunk e il protocollo SRTP(Secure Real-time Protocol) per proteggere il supporto tra il gateway locale e Webex Calling .
Selezionare CUBE come gateway locale. Webex per il Settore pubblico attualmente non supporta SBC (Session Border Controller) di terze parti. Per rivedere l'elenco più recente, vedi Introduzione al gateway locale.
- Installa Cisco IOS XE Dublin 17.12.1a o versioni successive per tutti i gateway locali di Webex for Government.
Per rivedere l'elenco delle autorità di certificazione radice (CA) 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, usa 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 informazioni 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 for Government. In caso contrario, l'impostazione della chiamata non riesce. Per i dettagli di configurazione, vedi Configurazione del trunk basato su certificato Webex Calling.
Webex per il Settore pubblico non supporta il gateway locale basato sulla registrazione. |
In questa sezione viene descritto come configurare un elemento Cisco Unified Border (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 ad alto livello che verrà seguita.
In questo design, vengono utilizzate le seguenti configurazioni principali:
tenant di 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 per i messaggi SIP in entrata e determina il percorso in uscita con un gruppo di dial-peer.
gruppo dial-peer: Definisce i dial-peer in uscita utilizzati per l'indirizzamento delle chiamate in uscita.
dial-peer in uscita: Fornisce il trattamento per i messaggi SIP in uscita e li indirizza al target richiesto.
Quando si connette 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 seguente diagramma. In questo caso, Unified Communications Manager fornisce l'indirizzamento e il trattamento centralizzato di tutte le chiamate PSTN e Webex Calling.
In tutto questo documento, vengono utilizzati i nomi host, gli indirizzi IP e le interfacce illustrati nell'immagine seguente.
Utilizzare le istruzioni di 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:
Passaggio 3: Configurazione del gateway locale con trunk PSTN SIP
Passaggio 4: Configurazione del gateway locale con l'ambiente Unified CM esistente
Oppure:
Passaggio 3: Configurazione del gateway locale con trunk PSTN TDM
Configurazione di base
Il primo passo nella preparazione del 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. Per le versioni consigliate, vedere la pagina Ricerca software Cisco. Cercare la piattaforma e selezionare una delle release suggerite.
I router della 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 la licenza DNA Advantage. I router senza schede vocali o DSP richiedono un minimo di licenze DNA Essentials.
Creare una configurazione di base per la piattaforma che segua i criteri aziendali. In particolare, configurare quanto segue e verificare il funzionamento:
NTP
ACL
Autenticazione utente e accesso remoto
DNS
IP
Indirizzi IP
La rete verso Webex Calling deve utilizzare un indirizzo IPv4.
Carica 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 la registrazione e le credenziali 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.
| ||
4 | Abilitare l'esclusività TLS1.2 e specificare il trustpoint predefinito utilizzando i seguenti comandi di configurazione. I parametri di trasporto devono inoltre essere aggiornati per garantire una connessione sicura affidabile per la registrazione:
| ||
5 | Installa il bundle CA radice di Cisco, che include il certificato CA DigiCert utilizzato da Webex Calling. Utilizzare il crypto pki trustpool importazione url pulito comando per scaricare il bundle CA radice dall'URL specificato e per cancellare il pool di attendibilità CA corrente, quindi installare il nuovo bundle di certificati:
|
1 | Crea un trunk PSTN basato su registrazione per una posizione esistente in Control Hub. Prendi nota delle informazioni sul trunk fornite una volta creato il trunk. Questi dettagli, come evidenziato nella figura seguente, saranno utilizzati nei passaggi di configurazione di questa guida. Per ulteriori informazioni, vedere Configura trunk, gruppi di indirizzamento e piani di chiamata per Webex Calling . | ||||
2 | Immettere i seguenti comandi per configurare CUBE come gateway locale Webex Calling:
Di seguito una spiegazione dei campi per la configurazione:
Consente di abilitare le funzioni CUBE (Cisco Unified Border Element) sulla piattaforma. statistiche mediaConsente il monitoraggio multimediale sul gateway locale. statistiche bulk multimedialiConsente al piano di controllo di eseguire il polling del piano dati per le statistiche chiamata in blocco. Per ulteriori informazioni su questi comandi, vedere Media. consentire connessioni da sip a sipAbilita funzionalità agente utente back-to-back SIP base CUBE. Per ulteriori informazioni, vedere Consenti connessioni .
Abilita globalmente STUN (Session Traversal of UDP through NAT).
Per ulteriori informazioni, vedere stun flowdata agent-id e stun flowdata shared-secret . pieno carico utile asimmetricoConfigura il supporto del payload asimmetrico SIP per payload DTMF e codec dinamici. Per ulteriori informazioni su questo comando, vedere payload asimmetrico . offerta anticipata forzataObbliga 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 codec classe vocale 100 filtro per il trunk. In questo esempio, viene utilizzato lo stesso filtro codec per tutti i trunk. È possibile configurare i filtri per ogni trunk per un controllo preciso.
Di seguito una spiegazione dei campi per la configurazione: codec classe vocale 100Utilizzato per consentire solo codec preferiti per le chiamate tramite trunk SIP. Per ulteriori informazioni, vedere codec di 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: stunutilizzoiceliteUtilizzato per abilitare ICE-Lite per tutti i dial-peer rivolti verso Webex Calling per consentire l'ottimizzazione multimediale quando possibile. Per ulteriori informazioni, vedere uso dello stordimento della lezione vocale e uso stordimento ice lite .
| ||||
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 unico CUBE della suite di crittografia SRTP in SDP nei messaggi di offerta e risposta. Webex Calling supporta solo SHA180._ Per ulteriori informazioni, vedere classe vocale srtp-crypto . | ||||
6 | Configura una sequenza per identificare in modo univoco le chiamate a un trunk del gateway locale in base al parametro del trunk di destinazione:
Di seguito una spiegazione dei campi per la configurazione: uri classe vocale 100 sipDefinisce uno schema che corrisponda a un invito SIP in arrivo a un dial-peer 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, vedi uri classe vocale. | ||||
7 | Configura 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:
| ||||
8 | Configura trunk Webex Calling: |
Dopo aver definito il tenant 100 e configurare un dial-peer VoIP SIP, 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 protetta per eseguire la registrazione con il controller SBC di accesso Webex. Quando la registrazione è contestata per l'autenticazione:
Nella risposta vengono utilizzati i parametri di nome utente, password e area di autenticazione dalla configurazione delle credenziali .
Le regole di modifica nel profilo SIP 100 vengono utilizzate per convertire nuovamente URL SIPS in SIP.
La registrazione ha esito positivo quando si riceve un 200 OK dal controller SBC di accesso.
Dopo aver creato un trunk verso Webex Calling, 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 a quella descritta sopra per il trunk Webex Calling. L'indirizzamento delle chiamate da sicuro a sicuro è supportato da CUBE. |
Per configurare interfacce TDM per segmenti di chiamata PSTN sui gateway Cisco TDM-SIP, vedere Configurazione ISDN PRI. |
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: uri classe vocale 200 sipDefinisce uno schema che corrisponda a un invito SIP in arrivo a un dial-peer trunk in arrivo. Quando si immette questo schema, utilizzare l'indirizzo IP del gateway PSTN IP. Per ulteriori informazioni, vedi uri classe vocale. |
2 | Configurare il seguente dial-peer PSTN IP:
Di seguito una spiegazione dei campi per la configurazione:
Definisce un dial-peer VoIP con un tag di 100 e fornisce una descrizione significativa per facilità di gestione e risoluzione dei problemi. Per ulteriori informazioni, vedere voce dial-peer. modello di destinazione BAD.BADUno schema di destinazione fittizio è richiesto quando si indirizzano le chiamate in uscita utilizzando un gruppo di dial-peer in entrata. Per ulteriori informazioni, vedere motivo-destinazione (interfaccia) . protocollo di sessione sipv2Specifica che il dial-peer 200 gestisce i segmenti di chiamata SIP. Per ulteriori informazioni, vedere protocollo di sessione (dial peer) . obiettivo della sessione ipv4:192.168.80.13Indica l'indirizzo indirizzo IPv4 di destinazione della destinazione per inviare il segmento di chiamata. La destinazione della sessione qui è l' indirizzo IP di ITSP . Per ulteriori informazioni, vedere destinazione sessione (peer di chiamata VoIP). uri in ingresso tramite 200Definisce un criterio di corrispondenza per l'intestazione VIA con l' IP della PSTN indirizzo IP. Corrisponde a tutti i segmenti di chiamata PSTN IP in ingresso sul gateway locale con dial-peer 200. Per ulteriori informazioni, vedere URL in arrivo. bind control source-interface GigabitEthernet0/0/0Configura l'interfaccia di origine e l'indirizzo IP associato per i messaggi inviati alla PSTN. Per ulteriori informazioni, vedere bind. associazione origine-interfaccia multimediale GigabitEthernet0/0/0Configura l'interfaccia di origine e l'indirizzo IP associato per il contenuto multimediale inviato a 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 codec di classe vocale . rtp-nte relè dtmfDefinisce RTP-NTE (RFC2833) come funzionalità DTMF prevista sul segmento di segmento di chiamata. Per ulteriori informazioni, vedere DTMF Relay (Voice over IP). no-vagliaDisabilita il rilevamento di attività vocale. Per ulteriori informazioni, vedere vad (peer di chiamata). |
3 | Se si sta configurando il gateway locale per indirizzare solo le chiamate tra Webex Calling e PSTN, aggiungere la seguente configurazione di indirizzamento chiamata. Se si sta configurando il gateway locale con una piattaforma Unified Communications Manager, passare alla sezione successiva. |
La configurazione PSTN-Webex Calling nelle sezioni precedenti può essere modificata per includere trunk aggiuntivi per 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. In questo modo, i messaggi in arrivo sulla porta 5065 vengono inseriti nell'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 l'indirizzamento SRV agli host Unified CM:
Di seguito una spiegazione dei campi per la configurazione: Il seguente comando crea un record di risorsa SRV DNS. Creare un record per ciascun host e trunk UCM: ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: Nome record risorsa SRV 2: Priorità record risorse SRV 1: Peso record risorse SRV 5060: Il numero di porta da utilizzare per l'host di destinazione in questo record di risorse ucmsub5.mydomain.com: L'organizzatore di destinazione del record di risorse Per risolvere i nomi host di destinazione dei record di risorse, creare i 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: Il nome dell'organizzatore record A. 192.168.80.65: L'indirizzo IP 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 | Configurare i seguenti dial-peer: | ||
4 | Aggiungi indirizzamento chiamata utilizzando le seguenti configurazioni: |
Le firme diagnostiche (DS) rilevano in modo proattivo i problemi riscontrati di frequente nel gateway locale basato su IOS XE e generano una notifica dell'evento tramite e-mail, syslog o messaggi sul terminale. 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 sugli eventi di attivazione del problema e sulle azioni da intraprendere per informare, risolvere il problema e porvi rimedio. È 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 azioni includono la raccolta di risultati del comando show:
Generazione di un file di registro consolidato
Caricamento del file in una posizione di rete fornita dall'utente, come server HTTPS, SCP, FTP.
I tecnici TAC creano i file DS e li firmano digitalmente per la protezione dell'integrità. A ogni file DS viene assegnato un ID numerico univoco dal sistema. Strumento di ricerca firme diagnostiche (DSLT) è una singola origine per trovare le firme applicabili per il monitoraggio e la risoluzione dei problemi di vari problemi.
Operazioni preliminari:
Non modificare il file DS da cui è stato eseguito il download DSLT . L'installazione dei file modificati non viene completata a causa dell'errore di controllo dell'integrità.
Un server SMTP(Simple Mail Transfer Protocol) necessario al gateway locale per inviare le notifiche e-mail.
Accertarsi che il gateway locale esegua IOS XE 17.6.1 o versione superiore se si desidera utilizzare il server TFTP 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 e-mail sicuro da utilizzare per inviare notifiche proattive se sul dispositivo è in esecuzione Cisco IOS XE 17.6.1a o versione successiva.
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls end
Configurare la variabile di ambienteds_email con l' indirizzo e-mail dell'amministratore per la notifica.
configure terminal call-home diagnostic-signature environment ds_email <email address> end
Di seguito viene mostrata una configurazione di esempio di un gateway locale in esecuzione su Cisco IOS XE 17.6.1a o superiore 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 priority 1 secure tls
diagnostic-signature
environment ds_email "tacfaststart@gmail.com"
Un gateway locale in esecuzione sul software Cisco IOS XE 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 affinché l'e-mail dal dispositivo venga elaborato correttamente: |
Vai a Meno sicura.
e attiva l'impostazione di accessoall'appRispondi "Sì, sono stato io" quando ricevi un'e-mail da Gmail che indica "Google ha impedito a qualcuno di accedere al tuo account utilizzando un'app non Google".
Installare le firme diagnostiche per il monitoraggio proattivo
Monitoraggio dell'utilizzo elevato CPU
Questa DS monitora l'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 mostra snmp comando per abilitare SNMP. Se non si abilita, configurare il gestore snmp-server comando.
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, serie 4400 ISR o Cisco CSR serie 1000V
Prodotto
CUBE Enterprise in Webex Calling
Ambito del problema
Prestazioni
Tipo di problema
Utilizzo elevato CPU con notifica e-mail .
Copia il file XML DS nel flash del gateway locale.
LocalGateway# copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
Il seguente esempio mostra come copiare il 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 show call-home diagnostic-signature per verificare che la firma sia 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.
Monitoraggio della registrazione trunk SIP
Questo DS verifica l'annullamento della registrazione di un SIP trunk del gateway locale con Webex Calling cloud ogni 60 secondi. Una volta rilevato, l'evento di annullamento della registrazione genera un'e-mail e una notifica di syslog e si disinstalla automaticamente dopo due occorrenze di annullamento della registrazione. Effettuare le seguenti operazioni 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
Annullamento registrazione trunk SIP con notifica e-mail .
Copia il file XML DS nel gateway locale.
copy ftp://username:password@<server name or ip>/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 show call-home diagnostic-signature per verificare che la firma sia installata correttamente. La colonna dello stato deve avere un valore "registrato".
Monitoraggio delle disconnessioni delle chiamate anomale
Questa DS utilizza il sondaggio SNMP ogni 10 minuti per rilevare una disconnessione di chiamata anomala con errori SIP 403, 488 e 503. Se l'incremento del numero di errori è maggiore o uguale a 5 dall'ultimo sondaggio, genera un registro di sistema e una notifica e-mail. Utilizza la procedura seguente per installare la firma.
Utilizzare il mostra snmp comando per verificare se SNMP è abilitato. Se non è abilitato, configurare il gestore snmp-server comando.
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 della disconnessione della chiamata anomala SIP con notifica e e-mail e syslog.
Copia il file XML DS nel gateway locale.
copy ftp://username:password@<server name or ip>/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 show call-home diagnostic-signature per verificare che la firma sia installata correttamente. La colonna dello stato deve avere un valore "registrato".
Installare le firme diagnostiche per risolvere un problema
Utilizzare le firme diagnostiche (DS) per risolvere rapidamente i problemi. I tecnici di centro TAC di Cisco hanno creato diverse firme che consentono i debug necessari per risolvere un determinato problema, rilevare il problema che si verifica, raccogliere il set di dati diagnostici corretto e trasferire automaticamente i dati al caso centro TAC di Cisco . Le firme diagnostiche (DS) eliminano la necessità di controllare manualmente l'insorgenza del problema e rendono molto più semplice la risoluzione dei problemi intermittenti e transitori.
È possibile utilizzare il Strumento di ricerca firme diagnostiche per trovare le firme applicabili e installarle per risolvere autonomamente un determinato problema oppure è possibile installare la firma consigliata dal tecnico TAC come parte del coinvolgimento del 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" syslog e automatizza la raccolta dei dati diagnostici utilizzando la seguente procedura:
Configurare un'ulteriore variabile di ambiente DSds_fsurl_prefix che è il percorso del file server centro TAC di Cisco (cxd.cisco.com) in cui vengono caricati i dati di diagnostica raccolti. Il nome utente nel percorso file è il numero del caso e la password è il token caricamento file che può essere recuperato Support Case Manager nel comando seguente. Il token di caricamento del file può essere generato nella sezione Allegati del Support Case Manager, come necessario.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" end
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 mostra snmp comando. Se non è abilitato, configurare il gestore snmp-server comando.
show snmp %SNMP agent not enabled config t snmp-server manager end
Assicurarsi di installare il monitoraggio della CPU alta 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
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 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@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/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 installata correttamente utilizzando il file show call-home diagnostic-signature comando. La colonna dello stato deve avere 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
Verificare l'esecuzione delle firme diagnostiche
Nel comando seguente, la colonna "Stato" del file show call-home diagnostic-signature il comando cambia in "in esecuzione" mentre il gateway locale esegue l'azione definita all'interno della firma. L'output di mostra le 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 "Triggered/Max/Deinstall" indica il numero di volte in cui la firma specificata ha attivato un evento, il numero massimo di volte in cui viene definito un evento per rilevare un evento e se la firma si disinstalla da sola 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 le statistiche della firma-diagnostica della chiamata a casa
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 | 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 di esecuzione e visualizza gli output dei comandi pertinenti per la risoluzione del problema specificato.
Disinstallare le firme diagnostiche
Le firme diagnostiche utilizzate per la risoluzione dei problemi vengono in genere definite per disinstallare dopo il rilevamento di alcune occorrenze del problema. Se si desidera disinstallare manualmente una firma, recuperare l'ID DS dall'output di mostrare la firma diagnostica della chiamata-casa e eseguire il comando seguente:
call-home diagnostic-signature deinstall <DS ID>
Esempio:
call-home diagnostic-signature deinstall 64224
Nuove firme vengono aggiunte periodicamente allo strumento di ricerca firme diagnostiche, in base a problemi che si riscontrano comunemente 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 registrare e gestire i gateway attraverso Control Hub. È una configurazione opzionale. Al termine della registrazione, è possibile utilizzare l'opzione di convalida della configurazione in Control Hub per convalidare la configurazione del gateway locale e identificare eventuali problemi di configurazione. Attualmente, solo i trunk basati su registrazione supportano questa funzionalità.
Per ulteriori informazioni, fare riferimento alle seguenti sezioni:
In questa sezione viene descritto come configurare un Cisco Unified Border Element (CUBE) come gateway locale per Webex Calling utilizzando il 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 ad alto livello che verrà seguita.
In questo design, vengono utilizzate le seguenti configurazioni principali:
tenant di 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 per i messaggi SIP in entrata e determina il percorso in uscita con un gruppo di dial-peer.
gruppo dial-peer: Definisce i dial-peer in uscita utilizzati per l'indirizzamento delle chiamate in uscita.
dial-peer in uscita: Fornisce il trattamento per i messaggi SIP in uscita e li indirizza al target richiesto.
Quando si connette 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 seguente diagramma. In questo caso, Unified Communications Manager fornisce l'indirizzamento e il trattamento centralizzato di tutte le chiamate PSTN e Webex Calling.
In tutto questo documento, vengono utilizzati i nomi host, gli indirizzi IP e le interfacce illustrati nell'immagine seguente. Le opzioni sono fornite 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.
Utilizzare le istruzioni di 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:
Passaggio 3: Configurazione del gateway locale con trunk PSTN SIP
Passaggio 4: Configurazione del gateway locale con l'ambiente Unified CM esistente
Oppure:
Passaggio 3: Configurazione del gateway locale con trunk PSTN TDM
Configurazione di base
Il primo passo nella preparazione del 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. Per le versioni consigliate, vedere la pagina Ricerca software Cisco. Cercare la piattaforma e selezionare una delle release suggerite.
I router della 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 Essentials. I router senza schede vocali o DSP richiedono un minimo di licenze DNA Essentials.
Per requisiti di capacità elevati, è possibile anche richiedere una licenza High Security (HSEC) e diritti di throughput aggiuntivi.
Fare riferimento a Codici di autorizzazione per ulteriori dettagli.
Creare una configurazione di base per la piattaforma che segua i criteri aziendali. In particolare, configurare quanto segue e verificare il funzionamento:
NTP
ACL
Autenticazione utente e accesso remoto
DNS
IP
Indirizzi IP
La rete verso Webex Calling deve utilizzare un indirizzo IPv4. I nomi di dominio completo (FQDN) o gli indirizzi SRV (Service Record) del gateway locale 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. Assicurarsi di aggiornare il firewall di conseguenza.
Installare un certificato firmato sul gateway locale (di seguito sono riportate dettagliate operazioni di configurazione).
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 di dominio completo configurato in Control Hub durante la creazione di un trunk deve essere il certificato Nome comune (CN) o Nome alternativo oggetto (SAN) del router. Ad esempio:
Se un trunk configurato nel Control Hub dell'organizzazione dispone di cube1.lgw.com:5061 come nome di dominio completo 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 router deve contenere lgws.lgw.com. I record in cui viene risolto l'indirizzo SRV (CNAME, record A o indirizzo IP ) sono facoltativi in SAN.
Se si utilizza un nome di dominio completo o SRV per il trunk, l'indirizzo del contatto per tutte le nuove finestre di dialogo SIP del gateway locale utilizza il nome configurato in Control Hub.
Assicurarsi che i certificati siano firmati per l'uso su client e server.
Carica 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 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 firmato dall'autorità di certificazione preferita (CA). | ||
4 | Autenticare il nuovo certificato utilizzando il certificato CA intermedio (o radice), quindi importare il certificato (Fase 4). Immettere il seguente comando exec o di configurazione:
| ||
5 | Importare un certificato host firmato utilizzando il seguente comando exec o configurazione:
| ||
6 | Abilitare l'esclusività TLS1.2 e specificare il trustpoint predefinito utilizzando i seguenti comandi di configurazione:
| ||
7 | Installa il bundle CA radice di Cisco, che include il certificato CA DigiCert utilizzato da Webex Calling. Utilizzare il crypto pki trustpool importazione url pulito comando per scaricare il bundle CA radice dall'URL specificato e per cancellare il pool di attendibilità CA corrente, quindi installare il nuovo bundle di certificati:
|
1 | Crea un trunk PSTN basato su certificato CUBE per una posizione esistente in Control Hub. Per ulteriori informazioni, vedere Configura trunk, gruppi di indirizzamento e piani di chiamata per Webex Calling .
| ||||
2 | Immettere i seguenti comandi per configurare CUBE come gateway locale Webex Calling:
Di seguito una spiegazione dei campi per la configurazione:
Consente di abilitare le funzioni CUBE (Cisco Unified Border Element) sulla piattaforma. consentire connessioni da sip a sipAbilita la funzionalità agente utente SIP base CUBE back to back. Per ulteriori informazioni, vedere Consenti connessioni .
Abilita globalmente STUN (Session Traversal of UDP through NAT).
Per ulteriori informazioni, vedere stun flowdata agent-id e stun flowdata shared-secret. pieno carico utile asimmetricoConfigura il supporto del payload asimmetrico SIP per payload DTMF e codec dinamici. Per ulteriori informazioni su questo comando, vedere payload asimmetrico . offerta anticipata forzataObbliga 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 entrataConsente a CUBE di utilizzare i profili SIP per modificare i messaggi man mano che vengono ricevuti. I profili vengono applicati tramite dial-peer o tenant. | ||||
3 | Configura codec classe vocale 100 filtro codec per il trunk. In questo esempio, viene utilizzato lo stesso filtro codec per tutti i trunk. È possibile configurare i filtri per ogni trunk per un controllo preciso.
Di seguito una spiegazione dei campi per la configurazione: codec classe vocale 100Utilizzato per consentire solo codec preferiti per le chiamate tramite trunk SIP. Per ulteriori informazioni, vedere codec di classe vocale .
| ||||
4 | Configura stun-usage della classe vocale 100 per abilitare ICE sul trunk Webex Calling. (Questa operazione non è applicabile a Webex for Government)
Di seguito una spiegazione dei campi per la configurazione: stunutilizzoiceliteUtilizzato per abilitare ICE-Lite per tutti i dial-peer rivolti verso Webex Calling per consentire l'ottimizzazione multimediale quando possibile. Per ulteriori informazioni, vedere uso dello stordimento della lezione vocale e uso stordimento ice lite .
| ||||
5 | Configurare i criteri di crittografia multimediale per il traffico Webex. (Questa operazione non è applicabile a Webex for Government)
Di seguito una spiegazione dei campi per la configurazione: classe vocale srtp-crypto 100Specifica SHA1_80 come unico CUBE della suite di crittografia SRTP in SDP nei messaggi di offerta e risposta. Webex Calling supporta solo SHA180._ Per ulteriori informazioni, vedere classe vocale srtp-crypto . | ||||
6 | Configura crittografie GCM conformi a FIPS (questa fase è applicabile solo a Webex for Government).
Di seguito una spiegazione dei campi per la configurazione: classe vocale srtp-crypto 100Specifica GCM come la suite di crittografia offerta da CUBE. È obbligatorio configurare le crittografie GCM per il gateway locale per Webex for Government. | ||||
7 | Configura un percorso per identificare in modo univoco le chiamate a un trunk del gateway locale in base al nome di dominio completo o SRV della destinazione:
Di seguito una spiegazione dei campi per la configurazione: uri classe vocale 100 sipDefinisce uno schema che corrisponda a un invito SIP in arrivo a un dial-peer trunk in arrivo. Quando si immette questo schema, utilizzare FQDN LGW o SRV configurato in Control Hub durante la creazione di un 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 il processo NAT. In questo esempio, cube1.lgw.com è il nome di dominio completo configurato per il gateway locale e "198.51.100.1" è l'indirizzo IP pubblico dell'interfaccia del gateway locale rivolta 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 in Control Hub. Questo è il nome di dominio completo di un singolo host o il nome di dominio SRV utilizzato per un cluster di dispositivi.
| ||||
9 | Se il gateway è configurato con un indirizzo IP privato dietro il processo NAT statico, 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 i messaggi in uscita a 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 in Control Hub. Questo è il nome di dominio completo di un singolo host o il nome di dominio SRV utilizzato per un cluster di dispositivi. dalle 30 alle 81Converti i riferimenti di indirizzo privato all'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: dalle 10 alle 80Converti i riferimenti all'indirizzo pubblico all'indirizzo privato configurato, consentendo a messaggi di Webex di essere elaborati correttamente da CUBE. Per ulteriori informazioni, vedere profili sip delle classi vocali . | ||||
10 | Configurare un keepalive Opzioni SIP con profilo di modifica intestazione.
Di seguito una spiegazione dei campi per la configurazione: classe vocale sip-options-keepalive 100Configura un profilo di mantenimento e attiva la modalità di configurazione della lezione vocale. È possibile configurare il tempo (in secondi) in cui viene inviato il ping delle opzioni SIP Out of Dialog all'obiettivo di chiamata quando la connessione heartbeat all'endpoint è in stato UP o Down. Questo profilo keepalive viene attivato dal dial-peer configurato per Webex. Per assicurarsi che le intestazioni dei contatti includano il nome di dominio SBC completo, viene utilizzato il profilo SIP 115. Le regole 30, 40 e 50 sono richieste solo quando l'SBC è configurato dietro NAT statico. In questo esempio, cube1.lgw.com è il nome di dominio completo selezionato per il gateway locale e, se viene utilizzata la tecnologia NAT statica, "10.80.13.12" è l'indirizzo IP dell'interfaccia SBC verso Webex Calling e "192.65.79.20" è l'indirizzo IP NAT pubblico. | ||||
11 | Configura trunk Webex Calling: |
Dopo aver creato un trunk verso Webex Calling, 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 a quella descritta sopra per il trunk Webex Calling. L'indirizzamento delle chiamate da sicuro a sicuro è supportato da CUBE. |
Per configurare interfacce TDM per segmenti di chiamata PSTN sui gateway Cisco TDM-SIP, vedere Configurazione ISDN PRI. |
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: uri classe vocale 200 sipDefinisce uno schema che corrisponda a un invito SIP in arrivo a un dial-peer trunk in arrivo. Quando si immette questo schema, utilizzare l'indirizzo IP del gateway PSTN IP. Per ulteriori informazioni, vedi uri classe vocale. |
2 | Configurare il seguente dial-peer PSTN IP:
Di seguito una spiegazione dei campi per la configurazione:
Definisce un dial-peer VoIP con un tag di 100 e fornisce una descrizione significativa per facilità di gestione e risoluzione dei problemi. Per ulteriori informazioni, vedere voce dial-peer. modello di destinazione BAD.BADUno schema di destinazione fittizio è richiesto quando si indirizzano le chiamate in uscita utilizzando un gruppo di dial-peer in entrata. Per ulteriori informazioni, vedere motivo-destinazione (interfaccia) . protocollo di sessione sipv2Specifica che il dial-peer 200 gestisce i segmenti di chiamata SIP. Per ulteriori informazioni, vedere protocollo di sessione (dial peer) . obiettivo della sessione ipv4:192.168.80.13Indica l'indirizzo indirizzo IPv4 di destinazione della destinazione per inviare il segmento di chiamata. La destinazione della sessione qui è l' indirizzo IP di ITSP . Per ulteriori informazioni, vedere destinazione sessione (peer di chiamata VoIP). uri in ingresso tramite 200Definisce un criterio di corrispondenza per l'intestazione VIA con l' IP della PSTN indirizzo IP. Corrisponde a tutti i segmenti di chiamata PSTN IP in ingresso sul gateway locale con dial-peer 200. Per ulteriori informazioni, vedere URL in arrivo. bind control source-interface GigabitEthernet0/0/0Configura l'interfaccia di origine e l'indirizzo IP associato per i messaggi inviati alla PSTN. Per ulteriori informazioni, vedere bind. associazione origine-interfaccia multimediale GigabitEthernet0/0/0Configura l'interfaccia di origine e l'indirizzo IP associato per il contenuto multimediale inviato a 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 codec di classe vocale . rtp-nte relè dtmfDefinisce RTP-NTE (RFC2833) come funzionalità DTMF prevista sul segmento di segmento di chiamata. Per ulteriori informazioni, vedere DTMF Relay (Voice over IP). no-vagliaDisabilita il rilevamento di attività vocale. Per ulteriori informazioni, vedere vad (peer di chiamata). |
3 | Se si sta configurando il gateway locale per indirizzare solo le chiamate tra Webex Calling e PSTN, aggiungere la seguente configurazione di indirizzamento chiamata. Se si sta configurando il gateway locale con una piattaforma Unified Communications Manager, passare alla sezione successiva. |
La configurazione PSTN-Webex Calling nelle sezioni precedenti può essere modificata per includere trunk aggiuntivi per 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:
Di seguito una spiegazione dei campi per la configurazione: Il seguente comando crea un record di risorsa SRV DNS. Creare un record per ciascun host e trunk UCM: ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: Nome record risorsa SRV 2: Priorità record risorse SRV 1: Peso record risorse SRV 5060: Il numero di porta da utilizzare per l'host di destinazione in questo record di risorse ucmsub5.mydomain.com: L'organizzatore di destinazione del record di risorse Per risolvere i nomi host di destinazione dei record di risorse, creare i 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: Il nome dell'organizzatore record A. 192.168.80.65: L'indirizzo IP 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 | Configurare i seguenti dial-peer: | ||
4 | Aggiungi indirizzamento chiamata utilizzando le seguenti configurazioni: |
Le firme diagnostiche (DS) rilevano in modo proattivo i problemi riscontrati comunemente nel gateway locale basato su Cisco IOS XE e generano una notifica dell'evento e-mail, syslog o messaggi sul terminale. 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 sugli eventi in cui si è verificato il problema e sulle azioni da eseguire per informare del problema, risolvere e risolvere il problema. Utilizzare i messaggi di syslog, gli eventi SNMP e il monitoraggio periodico degli output del comando show specifici per definire la logica di rilevamento del problema. I tipi di azione comprendono:
Raccolta degli output del comando show
Generazione di un file di registro consolidato
Caricamento del file in una posizione di rete fornita dall'utente, ad esempio HTTPS, SCP, server FTP
I tecnici TAC creano i file DS e li firmano digitalmente per la protezione dell'integrità. Ogni file DS presenta un ID numerico univoco assegnato dal sistema. Strumento di ricerca firme diagnostiche (DSLT) è una singola origine per trovare le firme applicabili per il monitoraggio e la risoluzione dei problemi di vari problemi.
Operazioni preliminari:
Non modificare il file DS da cui è stato eseguito il download DSLT . L'installazione dei file modificati non viene completata a causa dell'errore di controllo dell'integrità.
Un server SMTP(Simple Mail Transfer Protocol) necessario al gateway locale per inviare le notifiche e-mail.
Accertarsi che il gateway locale esegua IOS XE 17.6.1 o versione superiore se si desidera utilizzare il server TFTP 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 da utilizzare per inviare una notifica proattiva se il dispositivo esegue IOS XE 17.6.1 o versioni superiori.
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls end
Configurare la variabile di ambienteds_email con l' indirizzo e-mail dell'amministratore per la notifica.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_email <email address> end
Installare le firme diagnostiche per il monitoraggio proattivo
Monitoraggio dell'utilizzo elevato CPU
Questo DS tiene traccia dell'utilizzo della CPU per 5 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.
Assicurarsi di aver abilitato SNMP utilizzando il comando mostra snmp. Se SNMP non è abilitato, configurare il gestore snmp-server comando.
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@<server name or ip>/DS_64224.xml bootflash:
Nome campo
Valore campo
Piattaforma
Software Cisco 4300, 4400 serie 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@<server name or ip>/DS_64224.xml bootflash:
Il seguente esempio mostra come copiare il 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 show call-home diagnostic-signature per verificare che la firma sia installata correttamente. La colonna dello stato deve avere 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 l'utilizzo elevato CPU sul gateway locale.
Monitoraggio delle disconnessioni delle chiamate anomale
Questa DS utilizza il sondaggio SNMP ogni 10 minuti per rilevare una disconnessione di chiamata anomala con errori SIP 403, 488 e 503. Se l'incremento del numero di errori è maggiore o uguale a 5 dall'ultimo sondaggio, genera un registro di sistema e una notifica e-mail. Utilizza la procedura seguente per installare la firma.
Assicurarsi che SNMP sia abilitato utilizzando il comando mostra snmp. Se SNMP non è abilitato, configurare il gestore snmp-server comando.
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 4300, 4400 serie ISR o Catalyst 8000V Edge
Prodotto
CUBE Enterprise in Webex Calling
Ambito del problema
Prestazioni
Tipo di problema
Rilevamento della disconnessione della chiamata anomala SIP con notifica e e-mail e syslog.
Copia il file XML DS nel gateway locale.
copy ftp://username:password@<server name or ip>/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 installata correttamente. La colonna dello stato deve contenere il valore "registered".
Installare le firme diagnostiche per risolvere un problema
Per risolvere rapidamente i problemi è possibile utilizzare le firme diagnostiche (DS). I tecnici di centro TAC di Cisco hanno creato diverse firme che consentono i debug necessari per risolvere un determinato problema, rilevare il problema che si verifica, raccogliere il set di dati diagnostici corretto e trasferire automaticamente i dati al caso centro TAC di Cisco . 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 il Strumento di ricerca firme diagnostiche per trovare le firme applicabili e installarle per risolvere autonomamente un determinato problema oppure è possibile installare la firma consigliata dal tecnico TAC come parte del coinvolgimento del 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" syslog e automatizza la raccolta dei dati diagnostici utilizzando la seguente procedura:
Configurare un'altra variabile di ambiente DSds_fsurl_prefix come percorso del file server centro TAC di Cisco (cxd.cisco.com) per caricare i dati di diagnostica. Il nome utente nel percorso file è il numero del caso e la password è il token caricamento file che può essere recuperato Support Case Manager come mostrato di seguito. Il token caricamento file può essere generato nel file Allegati sezione del Case Manager di supporto, come richiesto.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" end
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 mostra snmp. Se SNMP non è abilitato, configurare il gestore snmp-server comando.
show snmp %SNMP agent not enabled config t snmp-server manager end
È consigliabile installare il monitoraggio della CPU alta 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, 4400 serie ISR o Catalyst 8000V Edge
Prodotto
CUBE Enterprise in Webex Calling
Ambito del problema
Prestazioni
Tipo di problema
Utilizzo elevato CPU con notifica e-mail .
Scarica DS 65095 utilizzando le seguenti opzioni nello strumento DSLT:
Nome campo
Valore campo
Piattaforma
Software Cisco 4300, 4400 serie 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@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash:
Installare il file XML DS 64224 e DS 65095 per il monitoraggio della CPU alta 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 mostrare la firma diagnostica della chiamata-casa. 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
Verificare l'esecuzione delle firme diagnostiche
Nel comando seguente, la colonna "Stato" del comando show call-home diagnostic-signature passa a "in esecuzione" mentre il gateway locale esegue l'azione definita all'interno della firma. L'output di mostra le 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 "Triggered/Max/Deinstall" indica il numero di volte in cui la firma specificata ha attivato un evento, il numero massimo di volte in cui viene definito un evento per rilevare un evento e se la firma si disinstalla da sola 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 le statistiche della firma-diagnostica della chiamata a casa
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 |
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 di esecuzione e visualizza gli output dei comandi pertinenti per la risoluzione del problema specificato.
Disinstallare le firme diagnostiche
L'uso delle firme diagnostiche per la risoluzione dei problemi viene in genere definito per disinstallare dopo il rilevamento di alcune occorrenze del problema. Se si desidera disinstallare manualmente una firma, recuperare l' ID DS dall'output di show call-home diagnostic-signature ed eseguire il comando seguente:
call-home diagnostic-signature deinstall <DS ID>
Esempio:
call-home diagnostic-signature deinstall 64224
Nuove firme vengono aggiunte allo strumento di ricerca firme diagnostiche periodicamente, in base ai problemi riscontrati nelle distribuzioni. Il TAC attualmente non supporta richieste di creazione di nuove firme personalizzate. |
Nozioni fondamentali
Prerequisiti
Prima di distribuire CUBE HA come gateway locale per Webex Calling, accertarti di aver compreso pienamente i seguenti concetti:
Ridondanza box-to-box layer 2 con CUBE Enterprise per conservazione delle chiamate con stato
Le linee guida di configurazione fornite in questo articolo presuppongono una piattaforma gateway locale dedicata che non prevede alcuna configurazione vocale esistente. Se viene modificata una distribuzione CUBE Enterprise esistente per utilizzare anche la funzione gateway locale per Cisco Webex Calling, presta attenzione alla configurazione applicata per garantire che i flussi di chiamata e le funzionalità esistenti non vengano interrotte e che stai soddisfacendo i requisiti di progettazione CUBE HA.
Componenti hardware e software
CUBE HA come gateway locale richiede IOS-XE versione 16.12.2 o successiva e una piattaforma su cui sono supportate entrambe le funzioni CUBE HA e LGW.
I comandi show e i registri in questo articolo si basano sulla release software minima di Cisco IOS-XE 16.12.2 implementata su vCUBE (CSR1000v). |
Materiale di riferimento
Di seguito sono riportate alcune guide alla configurazione di CUBE HA dettagliate per diverse piattaforme:
Serie ISR 4K— https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-ISR4K.html
CSR 1000v (vCUBE)– https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
Architettura preferita Cisco per Cisco Webex Calling– https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Panoramica della soluzione Webex Calling
Cisco Webex Calling è un servizio di collaborazione che offre un'alternativa basata su cloud multi-tenant al servizio telefonico PBX locale con più opzioni PSTN per i clienti.
La distribuzione del gateway locale (rappresentata di seguito) è il fulcro di questo articolo. Il trunk del gateway locale (PSTN locale) in Webex Calling consente la connettività a un servizio PSTN di proprietà del cliente. Fornisce anche la connettività a una distribuzione PBX IP locale, ad esempio Cisco Unified CM. Tutte le comunicazioni da e verso il cloud vengono protette utilizzando il trasporto TLS per SIP e SRTP per contenuti multimediali.
La figura seguente mostra una distribuzione Webex Calling senza un PBX IP esistente ed è applicabile a una distribuzione per singolo sito o più siti. La configurazione descritta in questo articolo si basa su questa distribuzione.
Ridondanza box-to-box layer 2
La ridondanza box-to-box layer 2 CUBE HA utilizza il protocollo dell'infrastruttura RG (Redundancy Group) per formare una coppia di router attivo/standby. Questa coppia condivide lo stesso indirizzo IP virtuale (VIP) sulle relative interfacce e scambia continuamente messaggi di stato. Le informazioni di sessione CUBE vengono verificate sulla coppia di router consentendo al router standby di assumere immediatamente tutte le responsabilità di elaborazione delle chiamate CUBE se il router attivo è fuori uso, in modo da preservare segnali e contenuti multimediali.
La verifica è limitata a chiamate connesse con pacchetti multimediali. Le chiamate in transito non vengono verificate (ad esempio, tentativi di chiamata o chiamate che squillano in attesa di risposta). In questo articolo, CUBE HA fa riferimento alla ridondanza CUBE High Availability (HA) Box-to-box (B2B) layer 2 per la conservazione delle chiamate con stato |
A partire da IOS-XE 16.12.2, CUBE HA può essere distribuito come gateway locale per distribuzioni di trunk Cisco Webex Calling (PSTN locale) e in questo articolo verranno riportate alcune considerazioni di progettazione e configurazioni. L'immagine mostra una tipica impostazione di CUBE HA come gateway locale per una distribuzione di trunk Cisco Webex Calling.
Componente Infra del gruppo di ridondanza
Il componente Infra del gruppo di ridondanza (RG, Redundancy Group) fornisce il supporto dell'infrastruttura di comunicazione box-to-box tra i due CUBE e negozia lo stato di ridondanza stabile finale. Questo componente fornisce anche:
Un protocollo simile a HSRP che negozia lo stato di ridondanza finale per ciascun router scambiando messaggi keepalive e hello tra i due CUBE (tramite l'interfaccia di controllo), GigabitEthernet3 nella figura precedente.
Un meccanismo di trasporto per la verifica dello stato di segnali e contenuti multimediali per ciascuna chiamata dal router attivo al router standby (tramite l'interfaccia dati), GigabitEthernet3 nella figura precedente.
Configurazione e gestione dell'interfaccia IP virtuale (VIP) per le interfacce di traffico (più interfacce di traffico possono essere configurate utilizzando lo stesso gruppo RG), GigabitEthernet 1 e 2 sono considerate interfacce di traffico.
Questo componente RG deve essere configurato in modo specifico per supportare il sistema vocale B2B HA.
Gestione degli indirizzi IP virtuali (VIP) per segnali e contenuti multimediali
B2B HA si basa sull'IP virtuale per ottenere ridondanza. Il VIP e le interfacce fisiche associate su entrambi i CUBE nella coppia CUBE HA devono risiedere sulla stessa subnet LAN. La configurazione del VIP e l'associazione dell'interfaccia VIP a una determinata applicazione vocale (SIP) sono obbligatorie per il supporto vocale B2B HA. I dispositivi esterni come Unified CM, controller SBC di accesso a Webex Calling, provider di servizi o proxy, utilizzano il VIP come indirizzo IP di destinazione per le chiamate che attraversano i router CUBE HA. Pertanto, dal punto di vista di Webex Calling, le coppie di CUBE HA agiscono come un singolo gateway locale.
Le informazioni su segnale di chiamata e sessione RTP delle chiamate stabilite vengono verificate dal router attivo al router di standby. Quando il router Attivo non è attivo, il router Standby subentra e continua a inoltrare il flusso RTP precedentemente indirizzato dal primo router.
Le chiamate in uno stato temporaneo al momento del failover non verranno mantenute dopo il cambio. Ad esempio, le chiamate non ancora completamente stabilite o in corso di modifica con una funzione di trasferimento o attesa. Le chiamate stabilite possono essere disconnesse dopo il cambio.
Esistono i seguenti requisiti per l'uso di CUBE HA come gateway locale per il failover delle chiamate:
CUBE HA non può avere interfacce TDM o analogiche co-posizionate
Le interfacce Gig1 e Gig2 sono denominate interfacce di traffico (SIP/RTP) e Gig3 è l'interfaccia di controllo RG/dati
Non è possibile inserire più di 2 coppie CUBE HA nello stesso dominio layer 2, una con ID gruppo 1 e l'altra con ID gruppo 2. Se configuri 2 coppie HA con lo stesso ID gruppo, le interfacce di controllo RG/dati devono appartenere a domini layer 2 diversi (vlan, switch separato)
Il canale delle porte è supportato per entrambe le interfacce di controllo RG/dati e di traffico
Tutti i segnali/contenuti multimediali sono originati da/all'indirizzo IP virtuale
Ogni volta che una piattaforma viene ricaricata in una relazione CUBE-HA, viene sempre avviata come Standby
L'indirizzo inferiore per tutte le interfacce (Gig1, Gig2, Gig3) deve essere sulla stessa piattaforma
L'identificativo dell'interfaccia di ridondanza, rii, deve essere univoco per una combinazione di coppia/interfaccia nello stesso Layer 2
La configurazione su entrambi i CUBE deve essere identica, inclusa la configurazione fisica, e deve essere in esecuzione sullo stesso tipo di piattaforma e versione IOS-XE
Non è possibile utilizzare interfacce di loopback come associazione perché sono sempre attive
Più interfacce di traffico (SIP/RTP) (Gig1, Gig2) richiedono la configurazione del rilevamento dell'interfaccia
CUBE-HA non è supportato su una connessione via cavo crossover per il collegamento controllo RG/dati (Gig3)
Entrambe le piattaforme devono essere identiche e connesse tramite uno switch fisico su tutte le interfacce simili affinché CUBE HA funzioni, ossia GE0/0/0 di CUBE-1 e CUBE-2 devono terminare sullo stesso switch e così via.
Non è possibile impostare WAN con terminazione diretta su CUBE o Data HA su entrambi i lati
Entrambi i router, Attivo/Standby, devono essere nello stesso centro dati
È obbligatorio utilizzare un'interfaccia L3 separata per ridondanza (controllo RG/dati, Gig3), ossia l'interfaccia utilizzata per il traffico non può essere utilizzata per keepalive e verifica HA
Al momento del failover, il CUBE precedentemente attivo passa attraverso un ricaricamento per impostazione predefinita, preservando segnali e contenuti multimediali
Configurazione della ridondanza su entrambi i CUBE
Devi configurare la ridondanza box-to-box layer 2 su entrambi i CUBE da utilizzare in una coppia HA per visualizzare IP virtuali.
1 | Configura il rilevamento dell'interfaccia a livello globale per rilevare lo stato dell'interfaccia.
La CLI di rilevamento viene utilizzata in RG per rilevare lo stato dell'interfaccia di traffico vocale in modo che il router attivo esca dal ruolo attivo una volta disattivata l'interfaccia di traffico. | ||||||
2 | Configura un RG per l'uso con VoIP HA nella modalità secondaria di ridondanza dell'applicazione.
Di seguito una spiegazione dei campi utilizzati in questa configurazione:
| ||||||
3 | Abilita la ridondanza box-to-box per l'applicazione CUBE. Configura l'RG dal passaggio precedente in
redundancy-group 1: l'aggiunta e la rimozione di questo comando richiede un ricaricamento per applicare la configurazione aggiornata. Le piattaforme verranno ricaricate una volta applicata la configurazione. | ||||||
4 | Configura le interfacce Gig1 e Gig2 con i relativi IP virtuali come mostrato di seguito e applica l'identificativo dell'interfaccia di ridondanza (rii)
Di seguito una spiegazione dei campi utilizzati in questa configurazione:
| ||||||
5 | Salva la configurazione del primo CUBE e ricaricala. La piattaforma da ricaricare per ultima è sempre Standby.
Dopo aver avviato completamente VCUBE-1, salva la configurazione di VCUBE-2 e ricaricala.
| ||||||
6 | Verifica che la configurazione box-to-box funzioni come previsto. L'output rilevante è evidenziato in grassetto. VCUBE-2 è stato ricaricato per ultimo e in base alle considerazioni di progettazione; la piattaforma da ricaricare per ultima sarà sempre Standby.
|
Configurazione di un gateway locale su entrambi i CUBE
Nella configurazione dell'esempio, stiamo utilizzando le seguenti informazioni di trunk di Control Hub per creare la configurazione del gateway locale su entrambe le piattaforme, VCUBE-1 e VCUBE-2. Il nome utente e la password per questa impostazione sono i seguenti:
Nome utente: Hussain1076_LGU
Password: lOV12MEaZx
1 | Assicurati che venga creata una chiave di configurazione per la password, con i comandi shown di seguito, prima di poterla utilizzare in credenziali o segreti condivisi. Le password di tipo 6 sono crittografate utilizzando cifratura AES e questa chiave di configurazione definita dall'utente.
Questa è la configurazione del gateway locale che verrà applicata a entrambe le piattaforme in base ai parametri di Control Hub visualizzati sopra, salva e ricarica. Le credenziali SIP digest di Control Hub sono evidenziate in grassetto.
Per visualizzare l'output del comando show, è stato ricaricato VCUBE-2 seguito da VCUBE-1, rendendo VCUBE-1 il CUBE standby e VCUBE-2 il CUBE attivo |
2 | In un determinato momento, solo una piattaforma manterrà una registrazione attiva come gateway locale con il controller SBC di accesso a Webex Calling. Dai un'occhiata all'output dei seguenti comandi show. show redundancy application group 1 mostra stato registrazione sip-ua
Dall'output precedente, puoi vedere che VCUBE-2 è l'LGW attivo che mantiene la registrazione con l'SBC di accesso a Webex Calling, mentre l'output del comando "show sip-ua register status" è vuoto in VCUBE-1 |
3 | Ora abilita i seguenti debug su VCUBE-1
|
4 | Simula il failover specificando il seguente comando sull'LGW attivo, VCUBE-2 in questo caso.
Il passaggio dall'LGW ACTIVE a STANDBY si verifica nei seguenti casi oltre alla CLI sopra elencata
|
5 | Controlla se VCUBE-1 è stato registrato con il controller SBC di accesso a Webex Calling. VCUBE-2 dovrebbe essere stato ricaricato ora.
VCUBE-1 è ora l'LGW attivo. |
6 | Esamina il registro di debug pertinente su VCUBE-1 inviando un SIP REGISTER a Webex Calling tramite IP virtuale e ricevendo un 200 OK.
|
Configurazione del profilo di sicurezza del trunk SIP per il trunk al gateway locale
Nei casi in cui il gateway locale e il gateway PSTN risiedano sullo stesso dispositivo, Unified CM deve essere abilitato per distinguere due diversi tipi di traffico (chiamate da Webex e dalla PSTN) che hanno origine dallo stesso dispositivo e applicare una classe differenziata di servizio a questi tipi di chiamata. Questo tipo di gestione differenziata delle chiamate viene realizzato predisponendo due trunk tra Unified CM e il gateway locale combinato e un dispositivo gateway PSTN che richiede porte di ascolto SIP diverse per i due trunk.
Crea un profilo di sicurezza del trunk SIP dedicato per il trunk del gateway locale con le seguenti impostazioni:
|
Configurazione del profilo SIP per il trunk del gateway locale
Crea un profilo SIP dedicato per il trunk del gateway locale con le seguenti impostazioni:
|
Creazione di uno spazio di ricerca di chiamata per le chiamate da Webex
Crea uno spazio di ricerca chiamata per le chiamate provenienti da Webex con le seguenti impostazioni:
|
Configurazione di un trunk SIP da e verso Webex
Crea un trunk SIP per le chiamate da e verso Webex attraverso il gateway locale con le seguenti impostazioni:
|
Configurazione del gruppo di indirizzamento per Webex
Crea un gruppo di indirizzamento con le seguenti impostazioni:
|
Configurazione dell'elenco di indirizzamento per Webex
Crea un elenco di indirizzamento con le seguenti impostazioni:
|
Creazione di una partizione per le destinazioni Webex
Crea una partizione per le destinazioni Webex con le seguenti impostazioni:
|
Operazioni successive
Accertati di aggiungere questa partizione a tutti gli spazi di ricerca chiamata che devono avere accesso alle destinazioni Webex. Devi aggiungere questa partizione in modo specifico allo spazio di ricerca chiamata utilizzato come spazio di ricerca di chiamata in ingresso sui trunk PSTN, in modo che le chiamate dalla PSTN a Webex possano essere indirizzate.
Configurazione dei percorsi di indirizzamento per le destinazioni Webex
Configura i percorsi di indirizzamento per ogni intervallo DID su Webex con le seguenti impostazioni:
|
Configurazione della normalizzazione chiamata intersito abbreviata per Webex
Se è richiesta la chiamata intersito abbreviata a Webex, configura gli schemi di normalizzazione chiamata per ciascun intervallo ESN su Webex con le seguenti impostazioni:
|
Imposta un gruppo di ricerca di risposta
I gruppi di risposta indirizzano le chiamate in arrivo a un gruppo di utenti o spazi di lavoro. Puoi persino configurare un percorso per l'indirizzamento a un intero gruppo.
Per ulteriori informazioni su come impostare un gruppo di ricerca di risposta , vedere Gruppi di ricerca in Cisco Webex Control Hub .
Creazione di una coda chiamata
Puoi impostare una coda chiamate in modo che quando non è possibile rispondere alle chiamate dei clienti, viene fornita loro una risposta automatica, messaggi di cortesia e musica di attesa finché qualcuno non risponde alla chiamata.
Per ulteriori informazioni su come impostare e gestire una coda chiamate, vedere Gestire le code di chiamata in Cisco Webex Control Hub .
Creare un client centralinista
Il client receptionist assiste nel supporto delle esigenze del personale di front-office. È possibile impostare gli utenti come assistenti telefonici in modo che possano eseguire il screening delle chiamate in arrivo verso determinate persone all'interno dell'organizzazione.
Per informazioni su come impostare e visualizzare i client receptionist, vedi Client receptionist in Cisco Webex Control Hub.
Creare e gestire operatori automatici
Puoi aggiungere messaggi di saluto, impostare menu e indirizzare le chiamate a un servizio di risposta, a un gruppo di risposta, a una casella vocale o a una persona reale. Crea una pianificazione di 24 ore o fornisci diverse opzioni quando l'azienda è aperta o chiusa.
Per informazioni su come creare e gestire operatori automatici, vedere Gestire gli operatori automatici in Cisco Webex Control Hub .
Configurare un gruppo di cercapersone
Il servizio di chiamata di gruppo consente a un utente di effettuare una chiamata unidirezionale o un servizio di chiamata di gruppo a un massimo di 75 utenti e spazi di lavoro di destinazione componendo un numero o un interno assegnato a un gruppo di cercapersone specifico.
Per informazioni su come impostare e modificare i gruppi di cercapersone, vedere Configurazione di un gruppo di cercapersone in Cisco Webex Control Hub .
Imposta la funzione di risposta per assente
Migliora il lavoro in team e la collaborazione creando un gruppo di risposta per assente di risposta per assente in modo che gli utenti possano rispondere reciprocamente alle chiamate. Quando aggiungi utenti a un gruppo di risposta per assente e un membro del gruppo è assente o è occupato, un altro membro può rispondere alle sue chiamate.
Per informazioni su come impostare un gruppo di risposta per assente, vedi Risposta per assente in Cisco Webex Control Hub.
Imposta parcheggio chiamata
Il parcheggio chiamata consente a un gruppo definito di utenti di parcheggiare le chiamate su altri membri disponibili di un gruppo di parcheggio chiamata. Alle chiamate parcheggiate possono rispondere altri membri del gruppo sul proprio telefono.
Per ulteriori informazioni sull'impostazione del parcheggio chiamata, vedi Parcheggio chiamata in Cisco Webex Control Hub.
Abilita inclusione per gli utenti
1 | Dalla vista cliente in , vai a Chiamata > Posizioni.https://admin.webex.com |
2 | Seleziona un utente e fai clic su Calling. |
3 | Andare alla sezione Autorizzazioni tra utenti, quindi selezionare Inclusione. |
4 | Attiva il tasto di alternanza per consentire ad altri utenti di aggiungersi alla chiamata in corso di questo utente. |
5 | Selezionare Riproduci un tono quando questo utente partecipa a una chiamata se si desidera riprodurre un tono agli altri quando questo utente partecipa alla chiamata. |
6 | Fai clic su Salva. |
Abilita privacy per un utente
1 | Accedi a Control Hub e vai a . | ||
2 | Scegli un utente e fai clic su Chiamata. | ||
3 | Andare all'area Autorizzazioni tra utenti e scegliere Privacy. | ||
4 | Scegli le impostazioni di Privacy operatore automatico appropriate per questo utente.
| ||
5 | Seleziona la casella di controllo Abilita privacy. Puoi quindi decidere di bloccare tutti non scegliendo membri dall'elenco a discesa. In alternativa, puoi scegliere gli utenti, gli spazi di lavoro e le linee virtuali che possono monitorare lo stato della linea di questo utente. Se sei un amministratore di posizione, solo gli utenti, gli spazi di lavoro e le linee virtuali relative alle tue posizioni assegnate vengono visualizzati nell'elenco a discesa. Deselezionare la casella di controllo Abilita privacy per consentire a tutti di monitorare lo stato della linea. | ||
6 | Seleziona la casella di controllo Applica privacy per risposta per assente indirizzata e inclusione per abilitare la privacy per risposta per assente indirizzata e inclusione.
| ||
7 | Da Aggiungi membro per nome, scegli utenti, spazi di lavoro e linee virtuali che possono monitorare lo stato della linea telefonica e richiamare risposta per assente indirizzata e inclusione. | ||
8 | Per filtrare i membri selezionati, utilizzare il filtro per nome, numero o campo interno. | ||
9 | Fare clic su Rimuovi tutto per rimuovere tutti i membri selezionati.
| ||
10 | Fai clic su Salva. |
Configura monitoraggio
Il numero massimo di linee monitorate per un utente è 50. Tuttavia, durante la configurazione dell'elenco di monitoraggio, considera il numero di messaggi che incidono sulla larghezza di banda tra Webex Calling e la rete. Inoltre, determinare il numero massimo di linee monitorate in base al numero di pulsanti linea sul telefono dell'utente.
1 | Dalla vista cliente in https://admin.webex.com, andare a Gestione, quindi fare clic su Utenti. | ||||
2 | Seleziona l'utente che desideri modificare e fai clic su Chiamata. | ||||
3 | Andare alla sezione Autorizzazioni tra utenti e selezionare Monitoraggio. | ||||
4 | Scegliere una delle opzioni seguenti:
È possibile includere una linea virtuale nell'elenco Aggiungi linea monitorata per il monitoraggio degli utenti. | ||||
5 | Scegli se desideri notificare a questo utente le chiamate parcheggiate, cerca la persona o l'interno del parcheggio chiamata da monitorare, quindi fai clic su Salva.
|
Abilita segnale di avviso bridge chiamata per gli utenti
Operazioni preliminari
1 | Accedi a Control Hub e vai a . | ||
2 | Seleziona un utente e fai clic sulla scheda Chiamata. | ||
3 | Vai a Autorizzazioni tra utenti e fai clic su Segnale di avviso bridge chiamata. | ||
4 | Attivare Tono di avviso ponte chiamata , quindi fare clic su Salva .
Per ulteriori informazioni sul bridge di chiamata su una linea condivisa MPP, vedere Linee condivise sul telefono fisso multipiattaforma. Per ulteriori informazioni sul bridge di chiamata su una linea condivisa dell'app Webex, vedi Identificativo di linea condivisa per WebexApp. |
Attiva la modalità hotel per un utente
1 | Dalla vista cliente inhttps://admin.webex.com , andare a Gestione e selezionare Utenti . | ||
2 | Seleziona un utente e fai clic sulla scheda Chiamata. | ||
3 | Vai alla sezione Autorizzazioni tra utenti e seleziona Modalità hotel e attiva il tasto di alternanza. | ||
4 | Immettere il nome o il numero dell'organizzatore della modalità hotel nel campo di ricerca Posizione modalità hotel e scegliere l'organizzatore della modalità hotel che si desidera assegnare all'utente. È possibile selezionare un solo organizzatore hotel. Se scegli un altro organizzatore hotel, il primo viene eliminato.
| ||
5 | Per limitare il tempo di associazione di un utente all'host della modalità hotel, scegliere il numero di ore in cui l'utente può utilizzare l'host della modalità hotel dall'elenco a discesa Limite periodo di associazione. L'utente verrà disconnesso automaticamente dopo l'ora scelta.
| ||
6 | Fai clic su Salva.
|
Visualizza report chiamata
Puoi utilizzare la pagina Analisi in Control Hub per ottenere informazioni su come le persone utilizzano Webex Calling e l'app Webex (coinvolgimento) nonché sulla qualità della loro esperienza multimediale di chiamata. Per accedere all'analisi Webex Calling, accedi a Control Hub, quindi vai ad Analisi e seleziona la scheda Chiamata.
1 | Per report dettagliati cronologia chiamate , accedere a Control Hub , quindi andare a Analisi > Chiamata . |
2 | Selezionare Cronologia chiamate dettagliata . Per informazioni sulle chiamate tramite istanza dedicata, vedi Analisi istanza dedicata. |
3 | Per accedere ai dati di qualità multimediale, accedi a Control Hub, quindi vai ad Analisi e seleziona Chiamata. Per ulteriori informazioni, vedi Analisi per il tuo portfolio Cloud Collaboration.
|
Eseguire lo strumento CScan
CScan è uno strumento di preparazione della rete progettato per testare la connessione di rete a Webex Calling.
Per ulteriori informazioni, vedi Uso di CScan per testare la qualità della rete Webex Calling. |
Prepara il tuo ambiente
Prerequisiti generali
Prima di configurare un gateway locale per Webex Calling, assicurati di:
-
Avere una conoscenza di base dei principi VoIP
-
Avere una conoscenza del funzionamento di base dei concetti vocali di Cisco IOS-XE e IOS-XE
-
Avere una comprensione di base del protocollo SIP (Session Initiation Protocol)
-
Avere una conoscenza di base di Cisco Unified Communications Manager (Unified CM), se il tuo modello di distribuzione include Unified CM
Per informazioni dettagliate, consultare la Guida alla configurazione aziendale di Cisco Unified Border Element (CUBE) .
Requisiti hardware e software per gateway locale
Accertarsi che la distribuzione disponga di uno o più gateway locali, ad esempio:
-
Cisco CUBE per la connettività basata su IP
-
Gateway Cisco IOS per connettività basata su TDM
Il gateway locale ti aiuta a eseguire la migrazione a Webex Calling al tuo ritmo. Il gateway locale integra la distribuzione locale esistente con Webex Calling. È inoltre possibile utilizzare la connessione PSTN esistente. Vedi Introduzione al gateway locale
Requisiti di licenza per gateway locali
Le licenze di chiamata CUBE devono essere installate sul gateway locale. Per ulteriori informazioni, vedi la Guida alla configurazione CUBE.
Requisiti di certificati e sicurezza per gateway locale
Webex Calling richiede segnali e supporti sicuri. Il gateway locale esegue la crittografia e una connessione TLS deve essere stabilita in uscita al cloud completando la seguente procedura:
-
LGW deve essere aggiornato con il bundle radice CA di PKI Cisco
-
Un set di credenziali digest SIP della pagina di configurazione del trunk di Control Hub viene utilizzato per configurare LGW (le operazioni fanno parte della configurazione seguente)
-
Il bundle radice CA convalida il certificato presentato
-
Richiesta delle credenziali (digest SIP fornito)
-
Il cloud identifica il gateway locale registrato in modo sicuro
Requisiti firewall, attraversamento NAT, ottimizzazione percorso multimediale per gateway locale
Nella maggior parte dei casi, il gateway locale e gli endpoint possono risiedere nella rete del cliente interna, che utilizza indirizzi IP privati con NAT. Il firewall aziendale deve consentire il traffico in uscita (SIP, RTP/UDP, HTTP) a specifici indirizzi IP/porte, indicati nelle Informazioni di riferimento porta.
Se desideri utilizzare l'ottimizzazione del percorso multimediale con ICE, l'interfaccia rivolta verso Webex Calling del gateway locale deve avere un percorso di rete diretto a/da endpoint Webex Calling. Se gli endpoint si trovano in una posizione diversa e non esiste un percorso di rete diretto tra gli endpoint e l'interfaccia rivolta verso Webex Calling del gateway locale, il gateway locale deve disporre di un indirizzo IP pubblico assegnato all'interfaccia rivolta verso Webex Calling per le chiamate tra il gateway locale e gli endpoint per utilizzare l'ottimizzazione del percorso multimediale. Inoltre, deve essere in esecuzione IOS-XE versione 16.12.5.
Configurazione di Webex Calling per la tua organizzazione
Il primo passo per iniziare rapidamente a utilizzare i servizi Webex Calling consiste nel completare la procedura di installazione guidata iniziale (FTSW). Una volta completata la FTSW per la prima posizione, non deve essere completata per altre posizioni.
1 |
Fai clic sul collegamento Introduzione nel messaggio e-mail di benvenuto che hai ricevuto. L'indirizzo e-mail dell'amministratore viene utilizzato automaticamente per accedere a Control Hub, dove viene richiesto di creare la password dell'amministratore. Una volta eseguito l'accesso, viene avviata automaticamente l'installazione guidata. |
2 |
Rivedi e accetta del condizioni del servizio. |
3 |
Rivedi il tuo piano e fai clic su Introduzione. Il gestore del tuo account è responsabile dell'attivazione dei primi passaggi della FTSW. Contatta il gestore del tuo account se ricevi l'avviso "Impossibile impostare la chiamata" quando selezioni Inizia. |
4 |
Seleziona il paese a cui associare il tuo centro dati e inserisci le informazioni di contatto e indirizzo del cliente. |
5 |
Fai clic su Avanti: Posizione predefinita. |
6 |
Selezionare una delle opzioni seguenti:
Al termine dell'installazione guidata, accertati di aggiungere un numero principale alla posizione creata. |
7 |
Effettua le seguenti selezioni da applicare a questa posizione:
|
8 |
Fare clic su Avanti. |
9 |
Inserisci un indirizzo SIP Cisco Webex disponibile e fai clic su Avanti, quindi seleziona Fine. |
Operazioni preliminari
Per creare una nuova posizione, prepara le seguenti informazioni:
-
Indirizzo posizione
-
Numeri di telefono desiderati (opzionale)
1 |
Accedi a Control Hub su https://admin.webex.com, vai a . Una nuova posizione verrà ospitata nel centro dati regionale corrispondente al paese selezionato utilizzando la procedura di installazione guidata iniziale. |
2 |
Configura le impostazioni della posizione:
|
3 |
Fare clic su Salva e scegliere Sì/ No per aggiungere i numeri alla posizione ora o in un secondo momento. |
4 |
Se è stato fatto clic su Sì, scegliere una delle seguenti opzioni:
La scelta dell'opzione PSTN è a livello di posizione (ciascuna posizione dispone di una sola opzione PSTN). Puoi combinare e associare il numero di opzioni desiderato per la tua distribuzione ma ogni posizione avrà una sola opzione. Una volta selezionata un'opzione PSTN ed eseguito il provisioning, puoi modificarla facendo clic su Gestisci nelle proprietà PSTN della posizione. Tuttavia, alcune opzioni come Cisco PSTN potrebbero non essere disponibili in seguito all'assegnazione di un'altra opzione. Aprire un caso di supporto per indicazioni. |
5 |
Scegli se attivare i numeri ora o in un secondo momento. |
6 |
Se hai selezionato la CCP non integrata o la PSTN locale, inserisci i Numeri di telefono come valori separati da virgola, quindi fai clic su Convalida. I numeri vengono aggiunti per la posizione specifica. Le voci valide vengono spostate nel campo Numeri convalidati e le voci non valide rimangono nel campo Aggiungi numeri, insieme a un messaggio di errore. A seconda del paese della posizione, i numeri vengono formattati in modo conforme ai requisiti di chiamata locali. Ad esempio, se è necessario un prefisso, puoi inserire i numeri con o senza il prefisso e il prefisso viene aggiunto all'inizio. |
7 |
Fai clic su Salva. |
Operazioni successive
Una volta creata una posizione, puoi abilitare i servizi di emergenza per tale posizione. Per ulteriori informazioni, vedi Servizio RedSky di Webex Calling.
Operazioni preliminari
Ottieni un elenco degli utenti e degli spazi di lavoro associati a una posizione: Andare a eliminare tali utenti e spazi di lavoro.
telefonia e dal menu a discesa selezionare la posizione da eliminare. Prima di eliminare una posizione, deviTieni presente che qualsiasi numero associato a questa posizione verrà restituito al provider PSTN e non sarai più proprietario di tali numeri.
1 |
Accedi a Control Hub su https://admin.webex.com, vai a . |
2 |
Fare clic su |
3 |
Scegliere Elimina posizionee confermare che si desidera eliminare tale posizione. Solitamente, sono necessari alcuni minuti per eliminare in modo permanente la posizione, ma potrebbero essere necessari fino a 1 ora. È possibile controllare lo stato facendo clic accanto al nome della posizione e selezionando Stato eliminazione. |
È possibile modificare l'PSTN, il nome, il fuso orario e la lingua di una località dopo la creazione. Tieni presente che la nuova lingua si applica solo ai nuovi utenti e dispositivi. Gli utenti e i dispositivi esistenti continuano a utilizzare la lingua precedente.
Per le posizioni esistenti, puoi abilitare i servizi 911 di emergenza. Per ulteriori informazioni, vedi Servizio RedSky di Webex Calling.
1 |
Accedi a Control Hub su https://admin.webex.com, vai a . Se accanto a una posizione viene visualizzato il simbolo Attenzione, significa che non è stato ancora configurato un numero di telefono per tale posizione. Non è possibile effettuare o ricevere chiamate fino a quando non si configura tale numero. |
2 |
(Opzionale) In Connessione PSTN, seleziona PSTN connessa al cloud o PSTN locale (gateway locale), in base a quale hai già configurato. Fai clic su Gestisci per modificare la configurazione e confermare i rischi associati selezionando Continua. Quindi, scegli una delle seguenti opzioni e fai clic su Salva:
|
3 |
Per la posizione, selezionare il Numero principale dall'elenco a discesa per consentire agli utenti in tale posizione di effettuare e ricevere chiamate. Il numero principale può essere assegnato all'operatore automatico in modo che i chiamanti esterni possano contattare gli utenti Webex Calling in tale posizione. Gli utenti Webex Calling in tale posizione possono anche utilizzare questo numero come ID chiamante esterno quando effettuano chiamate. |
4 |
(Opzionale) In Chiamata di emergenza, è possibile selezionare Identificativo posizione di emergenza da assegnare a questa posizione. Questa impostazione è opzionale ed è applicabile solo per i paesi che lo richiedono. In alcuni paesi (esempio: Francia), sono richieste normative che i sistemi radio cellulare stabilisce l'identità della cella quando si effettua una chiamata di emergenza e vengono rese disponibili alle autorità di emergenza. Altri paesi come Stati Uniti e Canada implementano la determinazione della posizione utilizzando altri metodi. Per ulteriori informazioni, vedere Chiamata di emergenza avanzata. Il provider delle chiamate di emergenza potrebbe richiedere informazioni sulla rete di accesso e definire una nuova intestazione di estensione SIP privata, P-Access-Network-Info. L'intestazione contiene informazioni relative alla rete di accesso. Quando si imposta l'identificativo della posizione di emergenza per una posizione, il valore della posizione viene inviato al provider come parte del messaggio SIP. Contattare il provider della chiamata di emergenza per verificare se tale impostazione è necessaria e utilizzare il valore fornito dal provider delle chiamate di emergenza." |
5 |
Seleziona il Numero della casella vocale che gli utenti possono chiamare per controllare la propria casella vocale per questa posizione. |
6 |
(Opzionale) Fare clic sull'icona della matita nella parte superiore della pagina Posizione per modificare il nome della posizione, la lingua dell'annuncio, la lingua dell'fuso orario o l'indirizzo, quindi fare clic su Salva. La modifica della lingua degli annunci viene applicate immediatamente per tutti i nuovi utenti e le funzioni aggiunte a questa posizione. Se anche gli utenti e/o le funzioni esistenti devono cambiare la lingua degli annunci, quando richiesto, selezionare Modifica per gli utenti e gli spazi di lavoro esistenti o Modifica per le funzioni esistenti. Fare clic su Applica. È possibile visualizzare lo stato di avanzamento nella pagina Attività. Non è possibile apportare altre modifiche fino a quando non è completato. Il cambio di Fuso orario per una posizione non implica l'aggiornamento dei fusi orari delle funzioni associate alla posizione. Per modificare i fusi orari per funzioni come operatore automatico, gruppo di risposta e coda chiamate, vai all'area Impostazioni generali della funzione specifica per la quale desideri aggiornare il fuso orario, quindi effettua le modifiche desiderate e salva. |
Queste impostazioni per la chiamata interna sono disponibili anche nella procedura iniziale di installazione guidata. Quando modifichi il piano di chiamata, i numeri di esempio nell'aggiornamento di Control Hub visualizzano queste modifiche.
Puoi configurare le autorizzazioni per le chiamate in uscita per una posizione. Vedi questi passaggi per configurare le autorizzazioni per le chiamate in uscita.
1 |
Accedi a Control Hub, vai a , quindi scorri fino a Chiamata interna. |
2 |
Configura le seguenti preferenze di chiamata opzionali in base alle tue esigenze:
|
3 |
Specifica la chiamata interna per posizioni specifiche. Vai a Chiamata. Scorrere fino a Composizione, quindi modificare la composizione interna come necessario: , seleziona una posizione dall'elenco e fai clic su
|
4 |
Specifica la chiamata esterna per posizioni specifiche. Vai a Chiamata. Scorrere fino a Chiamata, quindi modificare la chiamata esterna come necessario: , seleziona una posizione dall'elenco e fai clic su
Impatto sugli utenti:
|
Se sei un rivenditore a valore aggiunto (VAR), puoi utilizzare questa procedura per avviare la configurazione del gateway locale in Control Hub. Quando questo gateway è registrato sul cloud, puoi utilizzarlo in una o più posizioni Webex Calling per fornire l'indirizzamento a un provider di servizi PSTN aziendale.
Una posizione che dispone di un gateway locale non può essere eliminata quando il gateway locale viene utilizzato per altre posizioni.
Operazioni preliminari
-
Una volta aggiunta una posizione e prima di configurare il PSTN locale per una posizione, devi creare un trunk.
-
Crea posizioni e impostazioni e numeri specifici per ciascuno di essi. Le posizioni devono esistere prima di poter aggiungere un PSTN locale.
-
Comprendi i requisiti di PSTN locali (gateway locale) per Webex Calling.
-
Non puoi scegliere più di un trunk per una posizione con PSTN locale, ma puoi scegliere lo stesso trunk per più posizioni.
1 |
Accedi a Control Hub all'indirizzo https://admin.webex.com, vai a e seleziona Aggiungi trunk. |
2 |
Seleziona una posizione. |
3 |
Assegna un nome al trunk e fai clic su Salva. Il nome non può essere più lungo di 24 caratteri. |
Operazione successivi
Le informazioni sul trunk vengono visualizzate nella schermata Registra dominio, OTG/DTG gruppo trunk, Linea/Porta e Indirizzo proxy in uscita.
È consigliabile copiare queste informazioni da Control Hub e incollarle in un file di testo locale o un documento in modo da utilizzarlo come riferimento quando sei pronto a configurare il PSTN locale.
Se hai perso le credenziali, devi generarle nuovamente dalla schermata delle informazioni sul trunk in Control Hub. Fai clic su Recupera nome utente e reimposta password per generare un nuovo set di credenziali di autenticazione da utilizzare sul trunk.
1 |
Accedi a Control Hub su https://admin.webex.com, vai a . |
2 |
Seleziona una posizione da modificare e fai clic su Gestisci. |
3 |
Seleziona PSTN locale e fai clic su Avanti. |
4 |
Scegli un trunk dal menu a discesa. Visita la pagina del trunk per gestire le scelte del gruppo di trunk. |
5 |
Fai clic sull'avviso di conferma, quindi fai clic su Salva. |
Operazione successivi
È necessario eseguire le informazioni di configurazione generate da Hub di controllo e mappare i parametri nel gateway locale (ad esempio, su un cubo Cisco che si trova nei locali). Questo articolo illustra questo processo. Come riferimento, vedere il seguente diagramma per un esempio di come le informazioni di configurazione di Control Hub (a sinistra) vengono mappate sui parametri nel cubo (a destra):
Una volta completata correttamente la configurazione sul gateway stesso, puoi tornare a
in Control Hub e il gateway creato verrà elencato nella scheda posizione a cui è stato assegnato con un punto verde a sinistra del nome. Questo stato indica che il gateway è registrato in modo sicuro sul cloud di chiamata e viene utilizzato come gateway PSTN attivo per la posizione.Puoi facilmente visualizzare, attivare, rimuovere e aggiungere i numeri di telefono per la tua organizzazione in Control Hub. Per ulteriori informazioni, vedi Gestione dei numeri di telefono in Control Hub.
Se stai provando i servizi Webex e desideri convertire la tua versione di prova in un abbonamento a pagamento, puoi inviare una richiesta e-mail al partner.
1 |
Accedi a Control Hub su https://admin.webex.com, seleziona l'icona dell'edificio |
2 |
Seleziona la scheda Abbonamenti, quindi fai clic su Acquista ora. Viene inviato un messaggio e-mail al partner per informarlo che sei interessato alla conversione in un abbonamento a pagamento. |
Puoi utilizzare Control Hub per impostare la priorità delle opzioni di chiamata disponibili che gli utenti visualizzano in Webex App. Puoi anche abilitarli per le chiamate con singolo clic. Per ulteriori informazioni, consultare: Imposta le opzioni di chiamata per gli utenti dell'app Webex.
Puoi controllare l'applicazione di chiamata che viene aperta quando gli utenti effettuano chiamate. Puoi configurare le impostazioni del client di chiamata, inclusa la distribuzione in modalità mista per le organizzazioni con utenti autorizzati con Unified CM o Webex Calling e utenti senza servizi di chiamata a pagamento da Cisco. Per ulteriori informazioni, consultare: Imposta funzionamento chiamata.
Configurazione del gateway locale su Cisco IOS XE per Webex Calling
Panoramica
Webex Calling currently supports two versions of Local Gateway:
-
Gateway locale
-
Local Gateway for Webex for Government
-
Before you begin, understand the premises-based Public Switched Telephone Network (PSTN) and Local Gateway (LGW) requirements for 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. If you modify an existing PSTN gateway or CUBE Enterprise deployment to use as the Local Gateway function for Webex Calling, then pay careful attention to the configuration. Ensure that you don't interrupt the existing call flows and functionality because of the changes that you make.
For information on the supported third-party SBCs, refer to the respective product reference documentation.
Esistono due opzioni per configurare il gateway locale per il Webex Calling trunk:
-
Trunk basato sulla registrazione
-
Trunk basato su certificato
Use the task flow either under the Registration-based Local Gateway or Certificate-based Local Gateway to configure Local Gateway for your Webex Calling trunk.
See Get started with Local Gateway for more information on different trunk types. Effettuare le seguenti operazioni sul gateway locale, utilizzando l'interfaccia della riga di comando (CLI). We use Session Initiation Protocol (SIP) and Transport Layer Security (TLS) transport to secure the trunk and Secure Real Time Protocol (SRTP) to secure the media between the Local Gateway and Webex Calling.
-
Select CUBE as your Local Gateway. Webex for Government doesn’t currently support any third-party Session Border Controllers (SBCs). To review the latest list, see Get started with Local Gateway.
- Install Cisco IOS XE Dublin 17.12.1a or later versions for all Webex for Government Local Gateways.
-
To review the list of root Certificate Authorities (CAs) that Webex for Government support, see Root certificate authorities for Webex for Government.
-
For details on the external port ranges for Local Gateway in Webex for Government, see Network requirements for Webex for Government (FedRAMP).
Local Gateway for Webex for Government doesn’t support the following:
-
STUN/ICE-Lite for media path optimization
-
Fax (T.38)
To configure Local Gateway for your Webex Calling trunk in Webex for Government, use the following option:
-
Trunk basato su certificato
Use the task flow under the Certificate-based Local Gateway to configure the Local Gateway for your Webex Calling trunk. For more details on how to configure a certificate-based Local Gateway, see Configure Webex Calling certificate-based trunk.
It’s mandatory to configure FIPS-compliant GCM ciphers to support Local Gateway for Webex for Government. If not, the call setup fails. For configuration details, see Configure Webex Calling certificate-based trunk.
This section describes how to configure a Cisco Unified Border Element (CUBE) as a Local Gateway for Webex Calling, using a registering SIP trunk. The first part of this document illustrates how to configure a simple PSTN gateway. In this case, all calls from the PSTN are routed to Webex Calling and all calls from Webex Calling are routed to the PSTN. The image below highlights this solution and the high-level call routing configuration that will be followed.
In this design, the following principal configurations are used:
-
voice class tenants: Used to create trunk specific configurations.
-
voice class uri: Used to classify SIP messages for the selection of an inbound dial-peer.
-
inbound dial-peer: Provides treatment for inbound SIP messages and determines the outbound route with a dial-peer group.
-
dial-peer group: Defines the outbound dial-peers used for onward call routing.
-
outbound dial-peer: Provides treatment for outbound SIP messages and routes them to the required target.
While IP and SIP have become the default protocols for PSTN trunks, TDM (Time Division Multiplexing) ISDN circuits are still widely used and are supported with Webex Calling trunks. To enable media optimization of IP paths for Local Gateways with TDM-IP call flows, it is currently necessary to use a two-leg call routing process. This approach modifies the call routing configuration shown above, by introducing a set of internal loop-back dial-peers between Webex Calling and PSTN trunks as illustrated in the image below.
When connecting an on-premises Cisco Unified Communications Manager solution with Webex Calling, you can use the simple PSTN gateway configuration as a baseline for building the solution illustrated in the following diagram. In this case, Unified Communications Manager provides centralized routing and treatment of all PSTN and Webex Calling calls.
Throughout this document, the host names, IP addresses, and interfaces illustrated in the following image are used.
Use the configuration guidance in the rest of this document to complete your Local Gateway configuration as follows:
-
Punto 1: Configure router baseline connectivity and security
-
Punto 2: Configure Webex Calling Trunk
Depending on your required architecture, follow either:
-
Passaggio 3: Configure Local Gateway with SIP PSTN trunk
-
Passaggio 4: Configure Local Gateway with existing Unified CM environment
Oppure:
-
Passaggio 3: Configure Local Gateway with TDM PSTN trunk
Baseline configuration
The first step in preparing your Cisco router as a Local Gateway for Webex Calling is to build a baseline configuration that secures your platform and establishes connectivity.
-
All registration-based Local Gateway deployments require Cisco IOS XE 17.6.1a or later versions. For the recommended versions, see the Cisco Software Research page. Search for the platform and select one of the suggested releases.
-
ISR4000 series routers must be configured with both Unified Communications and Security technology licenses.
-
Catalyst Edge 8000 series routers fitted with voice cards or DSPs require DNA Advantage licensing. Routers without voice cards or DSPs require a minimum of DNA Essentials licensing.
-
-
Build a baseline configuration for your platform that follows your business policies. In particular, configure the following and verify the working:
-
Ntp
-
Acl
-
User authentication and remote access
-
DNS
-
Indirizzamento IP
-
IP addresses
-
-
The network toward Webex Calling must use an IPv4 address.
-
Upload the Cisco root CA bundle to the Local Gateway.
Configurazione
1 |
Ensure that you assign valid and routable IP addresses to any Layer 3 interfaces, for example:
|
2 |
Protect registration and STUN credentials on the router using symmetric encryption. Configure the primary encryption key and encryption type as follows:
|
3 |
Create a placeholder PKI trustpoint. Requires this trustpoint to configure TLS later. For registration-based trunks, this trustpoint doesn't require a certificate - as would be required for a certificate-based trunk. |
4 |
Enable TLS1.2 exclusivity and specify the default trustpoint using the following configuration commands. Transport parameters should also be updated to ensure a reliable secure connection for registration: The cn-san-validate server command ensures that the Local Gateway permits a connection if the host name configured in tenant 200 is included in either the CN or SAN fields of the certificate received from the outbound proxy.
|
5 |
Install the Cisco root CA bundle, which includes the DigiCert CA certificate used by Webex Calling. Use the crypto pki trustpool import clean url command to download the root CA bundle from the specified URL, and to clear the current CA trustpool, then install the new bundle of certificates: If you need to use a proxy for access to the internet using HTTPS, add the following configuration before importing the CA bundle: ip http client proxy-server yourproxy.com proxy-port 80 |
1 |
Create a registration based PSTN trunk for an existing location in Control Hub. Make a note of the trunk information that is provided once the trunk has been created. These details, as highlighted in the following illustration, will be used in the configuration steps in this guide. For more information, see Configure trunks, route groups, and dial plans for Webex Calling. |
2 |
Enter the following commands to configure CUBE as a Webex Calling Local Gateway: Di seguito una spiegazione dei campi per la configurazione:
Enables Cisco Unified Border Element (CUBE) features on the platform. media statisticsAbilita il monitoraggio multimediale sul gateway locale. media bulk-statsConsente al controllo di controllare il sondaggio dei dati per le statistiche sulle chiamate in massa. For more information on these commands, see Media. consenti-connessioni sip a SIPEnable CUBE basic SIP back-to-back user agent functionality. For more information, see Allow connections. By default, T.38 fax transport is enabled. For more information, see fax protocol t38 (voice-service). Enables STUN (Session Traversal of UDP through NAT) globally.
For more information, see stun flowdata agent-id and stun flowdata shared-secret. asymmetric payload fullConfigures SIP asymmetric payload support for both DTMF and dynamic codec payloads. For more information on this command, see asymmetric payload. offerta anticipata forzataForces the Local Gateway to send SDP information in the initial INVITE message instead of waiting for acknowledgment from the neighboring peer. For more information on this command, see early-offer. |
3 |
Configure voice class codec 100 filter for the trunk. In this example, the same codec filter is used for all trunks. You can configure filters for each trunk for precise control. Di seguito una spiegazione dei campi per la configurazione: voice class codec 100Used to only allow preferred codecs for calls through SIP trunks. For more information, see voice class codec. Opus codec is supported only for SIP-based PSTN trunks. If the PSTN trunk uses a voice T1/E1 or analog FXO connection, exclude codec preference 1 opus from the voice class codec 100 configuration. |
4 |
Configure voice class stun-usage 100 to enable ICE on the Webex Calling trunk. Di seguito una spiegazione dei campi per la configurazione: stun usage ice liteUsed to enable ICE-Lite for all Webex Calling facing dial-peers to allow media-optimization whenever possible. For more information, see voice class stun usage and stun usage ice lite. You require stun usage of ICE-lite for call flows using media path optimization. To provide media-optimization for a SIP to TDM gateway, configure a loopback dial-peer with ICE-Lite enabled on the IP-IP leg. For further technical details, contact the Account or TAC teams |
5 |
Configure the media encryption policy for Webex traffic. Di seguito una spiegazione dei campi per la configurazione: voice class srtp-crypto 100Specifies SHA1_80 as the only SRTP cipher-suite CUBE offers in the SDP in offer and answer messages. Webex Calling only supports SHA1_80. For more information, see voice class srtp-crypto. |
6 |
Configure a pattern to uniquely identify calls to a Local Gateway trunk based on its destination trunk parameter: Di seguito una spiegazione dei campi per la configurazione: voice class uri 100 sipDefines a pattern to match an incoming SIP invite to an incoming trunk dial-peer. When entering this pattern, use dtg= followed by the Trunk OTG/DTG value provided in Control Hub when the trunk was created. For more information, see voice class uri. |
7 |
Configure sip profile 100, which will be used to modify SIP messages before they are sent to Webex Calling.
Di seguito una spiegazione dei campi per la configurazione:
|
8 |
Configure Webex Calling trunk: |
After you define tenant 100 and configure a SIP VoIP dial-peer, the gateway initiates a TLS connection toward Webex Calling. At this point the access SBC presents its certificate to the Local Gateway. The Local Gateway validates the Webex Calling access SBC certificate using the CA root bundle that was updated earlier. If the certificate is recognised, a persistent TLS session is established between the Local Gateway and Webex Calling access SBC. The Local Gateway is then able to use this secure connection to register with the Webex access SBC. When the registration is challenged for authentication:
-
The username, password, and realm parameters from the credentials configuration is used in the response.
-
The modification rules in sip profile 100 are used to convert SIPS URL back to SIP.
Registration is successful when a 200 OK is received from the access SBC.
Having built a trunk towards Webex Calling above, use the following configuration to create a non-encrypted trunk towards a SIP based PSTN provider:
If your Service Provider offers a secure PSTN trunk, you may follow a similar configuration as detailed above for the Webex Calling trunk. Secure to secure call routing is supported by CUBE.
If you are using a TDM / ISDN PSTN trunk, skip to next section Configure Local Gateway with TDM PSTN trunk.
To configure TDM interfaces for PSTN call legs on the Cisco TDM-SIP Gateways, see Configuring ISDN PRI.
1 |
Configure the following voice class uri to identify inbound calls from the PSTN trunk: Di seguito una spiegazione dei campi per la configurazione: voice class uri 200 sipDefines a pattern to match an incoming SIP invite to an incoming trunk dial-peer. When entering this pattern, use the IP address of you IP PSTN gateway. For more information, see voice class uri. |
2 |
Configure the following IP PSTN dial-peer: Di seguito una spiegazione dei campi per la configurazione: Definisce un VoIP dial-peer con un tag 200 e fornisce una descrizione significativa per facilità di gestione e risoluzione dei problemi. For more information, see dial-peer voice. percorso-destinazione BAD. MaleA dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. For more information, see destination-pattern (interface). protocollo sessione sipv2Specifica che il dial-peer 200 gestisce i mani della chiamata SIP. For more information, see session protocol (dial peer). destinazione sessione ipv4:192.168.80.13Indica l'indirizzo IPv4 di destinazione per l'invio del gruppo di chiamata. L'obiettivo della sessione è l'indirizzo IP di ITSP. For more information, see session target (VoIP dial peer). incoming uri via 200Definisce un criterio di corrispondenza per l'intestazione VIA con l'indirizzo IP PSTN is address dell'ip del provider di connessioni IP. Matches all incoming IP PSTN call legs on the Local Gateway with dial-peer 200. For more information, see incoming url. bind control source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for messages sent to the PSTN. For more information, see bind. bind media source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for media sent to PSTN. For more information, see bind. codec classe vocale 100Configures the dial-peer to use the common codec filter list 100. For more information, see voice-class codec. dtmf-relay rtp-nteDefinisce RTP-NTE (RFC2833) come funzionalità DTMF prevista sul modello della chiamata. For more information, see DTMF Relay (Voice over IP). nessun vadDisabilita il rilevamento dell'attività vocale. For more information, see vad (dial peer). |
3 |
If you are configuring your Local Gateway to only route calls between Webex Calling and the PSTN, add the following call routing configuration. If you are configuring your Local Gateway with a Unified Communications Manager platform, skip to the next section. |
Having built a trunk towards Webex Calling, use the following configuration to create a TDM trunk for your PSTN service with loop-back call routing to allow media optimization on the Webex call leg.
1 |
The loop-back dial-peer configuration uses dial-peer groups and call routing tags to ensure that calls pass correctly between Webex and the PSTN, without creating call routing loops. Configure the following translation rules that will be used to add and remove the call routing tags: Di seguito una spiegazione dei campi per la configurazione: voice translation-ruleUses regular expressions defined in rules to add or remove call routing tags. Over-decadic digits (‘A’) are used to add clarity for troubleshooting. In this configuration, the tag added by translation-profile 100 is used to guide calls from Webex Calling towards the PSTN via the loopback dial-peers. Similarly, the tag added by translation-profile 200 is used to guide calls from the PSTN towards Webex Calling. Translation-profiles 11 and 12 remove these tags before delivering calls to the Webex and PSTN trunks respectively. This example assumes that called numbers from Webex Calling are presented in +E.164 format. Rule 100 removes the leading + to maintain a valid called number. Rule 12 then adds a national or international routing digit(s) when removing the tag. Use digits that suit your local ISDN national dial plan. If Webex Calling presents numbers in national format, adjust rules 100 and 12 to simply add and remove the routing tag respectively. For more information, see voice translation-profile and voice translation-rule. |
2 |
Configure TDM voice interface ports as required by the trunk type and protocol used. For more information, see Configuring ISDN PRI. For example, the basic configuration of a Primary Rate ISDN interface installed in NIM slot 2 of a device might include the following: |
3 |
Configure the following TDM PSTN dial-peer: Di seguito una spiegazione dei campi per la configurazione: Definisce un VoIP dial-peer con un tag 200 e fornisce una descrizione significativa per facilità di gestione e risoluzione dei problemi. For more information, see dial-peer voice. percorso-destinazione BAD. MaleA dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. For more information, see destination-pattern (interface). translation-profile incoming 200Assigns the translation profile that will add a call routing tag to the incoming called number. direct-inward-dialRoutes the call without providing a secondary dial-tone. For more information, see direct-inward-dial. port 0/2/0:15The physical voice port associated with this dial-peer. |
4 |
To enable media optimization of IP paths for Local Gateways with TDM-IP call flows, you can modify the call routing by introducing a set of internal loop-back dial-peers between Webex Calling and PSTN trunks. Configure the following loop-back dial-peers. In this case, all incoming calls will be routed initially to dial-peer 10 and from there to either dial-peer 11 or 12 based on the applied routing tag. After removal of the routing tag, calls will be routed to the outbound trunk using dial-peer groups. Di seguito una spiegazione dei campi per la configurazione: Defines a VoIP dial-peer and gives a meaningful description for ease of management and troubleshooting. For more information, see dial-peer voice. translation-profile incoming 11Applies the translation profile defined earlier to remove the call routing tag before passing to the outbound trunk. percorso-destinazione BAD. MaleA dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. For more information, see destination-pattern (interface). protocollo sessione sipv2Specifies that this dial-peer handles SIP call legs. For more information, see session protocol (dial peer). session target 192.168.80.14Specifies the local router interface address as the call target to loop-back. For more information, see session target (voip dial peer). bind control source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for messages sent through the loop-back. For more information, see bind. bind media source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for media sent through the loop-back. For more information, see bind. dtmf-relay rtp-nteDefinisce RTP-NTE (RFC2833) come funzionalità DTMF prevista sul modello della chiamata. For more information, see DTMF Relay (Voice over IP). codec g711alaw Forces all PSTN calls to use G.711. Select a-law or u-law to match the companding method used by your ISDN service. nessun vadDisabilita il rilevamento dell'attività vocale. For more information, see vad (dial peer). |
5 |
Add the following call routing configuration: This concludes your Local Gateway configuration. Save the configuration and reload the platform if this is the first time CUBE features are configured.
|
The PSTN-Webex Calling configuration in the previous sections may be modified to include additional trunks to a Cisco Unified Communications Manager (UCM) cluster. In this case, all calls are routed via Unified CM. Calls from UCM on port 5060 are routed to the PSTN and calls from port 5065 are routed to Webex Calling. The following incremental configurations may be added to include this calling scenario.
When creating the Webex Calling trunk in Unified CM, ensure that you configure the incoming port in the SIP Trunk Security Profile settings to 5065. This allows incoming messages on port 5065 and populate the VIA header with this value when sending messages to the Local Gateway.
1 |
Configura i seguenti URI di classe vocale: |
2 |
Configure the following DNS records to specify SRV routing to Unified CM hosts: IOS XE uses these records for locally determining target UCM hosts and ports. With this configuration, it is not required to configure records in your DNS system. If you prefer to use your DNS, then these local configurations are not required. Di seguito una spiegazione dei campi per la configurazione: The following command creates a DNS SRV resource record. Create a record for each UCM host and trunk: ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: SRV resource record name 2: The SRV resource record priority 1: The SRV resource record weight 5060: The port number to use for the target host in this resource record ucmsub5.mydomain.com: The resource record target host To resolve the resource record target host names, create local DNS A records. Ad esempio: ip host ucmsub5.mydomain.com 192.168.80.65 ip host: Creates a record in the local IOS XE database. ucmsub5.mydomain.com: The A record host name. 192.168.80.65: The host IP address. Create the SRV resource records and A records to reflect your UCM environment and preferred call distribution strategy. |
3 |
Configure the following dial-peers: |
4 |
Add call routing using the following configurations: |
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. You can also install the DS to automate diagnostics data collection and transfer-collected data to the Cisco TAC case to accelerate resolution time.
Le firme diagnostiche (DS) sono file XML contenenti informazioni su eventi e azioni da attivare per informare, risolvere e risolvere il problema. You can define the problem detection logic using syslog messages, SNMP events and through periodic monitoring of specific show command outputs.
I tipi di azione includono la raccolta degli output dei comandi visualizzati:
-
Generazione di un file di log consolidato
-
Uploading the file to a user-provided network location such as HTTPS, SCP, FTP server.
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) is a single source to find applicable signatures for monitoring and troubleshooting various problems.
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
Local Gateway running IOS XE 17.6.1a or higher
-
Le firme diagnostiche sono abilitate per impostazione predefinita.
-
Configure the secure email server to be used to send proactive notification if the device is running Cisco IOS XE 17.6.1a or higher.
configure terminal call-home mail-server <username>:<pwd>@<email server> priority 1 secure tls end
-
Configure the environment variable ds_email with the email address of the administrator to notify you.
configure terminal call-home diagnostic-signature environment ds_email <email address> end
The following shows an example configuration of a Local Gateway running on Cisco IOS XE 17.6.1a or higher to send the proactive notifications to tacfaststart@gmail.com using Gmail as the secure SMTP server:
We recommend you to use the Cisco IOS XE Bengaluru 17.6.x or later versions.
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:
-
Go to Less secure app access setting.
and turn on the -
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
This DS tracks CPU utilization for five seconds using the SNMP OID 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.
-
Use the show snmp command to enable SNMP. If you do not enable, then configure the snmp-server manager command.
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 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, 4400 ISR Series or Cisco CSR 1000V Series
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@<server name or ip>/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: Firma diagnostica: profilo abilitato: CiscoTAC-1 (stato: ACTIVE) URL di download: 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. If necessary, reinstall DS 64224 to continue monitoring high CPU utilization on the Local Gateway.
Registrazione trunk SIP di monitoraggio
Questo DS verifica l'annullamento della registrazione di un gateway locale Trunk SIP cloud Webex Calling ogni 60 secondi. Once the unregistration event is detected, it generates an email and syslog notification and uninstalls itself after two unregistration occurrences. Use the steps below to install the signature:
-
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@<server name or ip>/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
This DS uses SNMP polling every 10 minutes to detect abnormal call disconnect with SIP errors 403, 488 and 503. If the error count increment is greater than or equal to 5 from the last poll, it generates a syslog and email notification. Please use the steps below to install the signature.
-
Use the show snmp command to check whether SNMP is enabled. If it is not enabled, configure the snmp-server manager command.
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 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.
copy ftp://username:password@<server name or ip>/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. Diagnostic Signatures (DS) eliminate the need to manually check for the problem occurrence and makes troubleshooting of intermittent and transient issues a lot easier.
È 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:
-
Configure an additional DS environment variable ds_fsurl_prefix which is the Cisco TAC file server path (cxd.cisco.com) to which the collected diagnostics data are uploaded. The username in the file path is the case number and the password is the file upload token which can be retrieved from Support Case Manager in the following command. The file upload token can be generated in the Attachments section of the Support Case Manager, as needed.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" end
Esempio:
call-home diagnostic-signature environment ds_fsurl_prefix " environment ds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"
-
Ensure that SNMP is enabled using the show snmp command. If it is not enabled, configure the snmp-server manager command.
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@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/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
-
Verify that the signature is successfully installed using the show call-home diagnostic-signature command. La colonna dello stato deve contenere un valore "registrato".
show call-home diagnostic-signature Current diagnostic-signature settings: Firma diagnostica: profilo abilitato: CiscoTAC-1 (stato: ACTIVE) URL di download: 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
In the following command, the “Status” column of the show call-home diagnostic-signature command changes to “running” while the Local Gateway executes the action defined within the signature. 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: Firma diagnostica: profilo
abilitato: CiscoTAC-1 (stato: ACTIVE)
URL di download: 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 |
Triggered/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. If you want to uninstall a signature manually, retrieve the DS ID from the output of the show call-home diagnostic-signature command and run the following command:
call-home diagnostic-signature deinstall <DS ID>
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.
For better management of Cisco IOS XE Gateways, we recommend that you enroll and manage the gateways through the Control Hub. It is an optional configuration. When enrolled, you can use the configuration validation option in the Control Hub to validate your Local Gateway configuration and identify any configuration issues. Currently, only registration-based trunks support this functionality.
For more information, refer the following:
This section describes how to configure a Cisco Unified Border Element (CUBE) as a Local Gateway for Webex Calling, using certificate-based mutual TLS (mTLS) SIP trunk. The first part of this document illustrates how to configure a simple PSTN gateway. In this case, all calls from the PSTN are routed to Webex Calling and all calls from Webex Calling are routed to the PSTN. The following image highlights this solution and the high-level call routing configuration that will be followed.
In this design, the following principal configurations are used:
-
voice class tenants: Used to create trunk specific configurations.
-
voice class uri: Used to classify SIP messages for the selection of an inbound dial-peer.
-
inbound dial-peer: Provides treatment for inbound SIP messages and determines the outbound route with a dial-peer group.
-
dial-peer group: Defines the outbound dial-peers used for onward call routing.
-
outbound dial-peer: Provides treatment for outbound SIP messages and routes them to the required target.
While IP and SIP have become the default protocols for PSTN trunks, TDM (Time Division Multiplexing) ISDN circuits are still widely used and are supported with Webex Calling trunks. To enable media optimization of IP paths for Local Gateways with TDM-IP call flows, it is currently necessary to use a two-leg call routing process. This approach modifies the call routing configuration shown above, by introducing a set of internal loop-back dial-peers between Webex Calling and PSTN trunks as illustrated in the image below.
When connecting an on-premises Cisco Unified Communications Manager solution with Webex Calling, you can use the simple PSTN gateway configuration as a baseline for building the solution illustrated in the following diagram. In this case, Unified Communications Manager provides centralized routing and treatment of all PSTN and Webex Calling calls.
Throughout this document, the host names, IP addresses, and interfaces illustrated in the following image are used. Options are provided for public or private (behind NAT) addressing. SRV DNS records are optional, unless load balancing across multiple CUBE instances.
Use the configuration guidance in the rest of this document to complete your Local Gateway configuration as follows:
-
Punto 1: Configure router baseline connectivity and security
-
Punto 2: Configure Webex Calling Trunk
Depending on your required architecture, follow either:
-
Passaggio 3: Configure Local Gateway with SIP PSTN trunk
-
Passaggio 4: Configure Local Gateway with existing Unified CM environment
Oppure:
-
Passaggio 3: Configure Local Gateway with TDM PSTN trunk
Baseline configuration
The first step in preparing your Cisco router as a Local Gateway for Webex Calling is to build a baseline configuration that secures your platform and establishes connectivity.
-
All certificate-based Local Gateway deployments require Cisco IOS XE 17.9.1a or later versions. For the recommended versions, see the Cisco Software Research page. Search for the platform and select one of the suggested releases.
-
ISR4000 series routers must be configured with both Unified Communications and Security technology licenses.
-
Catalyst Edge 8000 series routers fitted with voice cards or DSPs require DNA Essentials licensing. Routers without voice cards or DSPs require a minimum of DNA Essentials licensing.
-
For high-capacity requirements, you may also require a High Security (HSEC) license and additional throughput entitlement.
Refer to Authorization Codes for further details.
-
-
Build a baseline configuration for your platform that follows your business policies. In particular, configure the following and verify the working:
-
Ntp
-
Acl
-
User authentication and remote access
-
DNS
-
Indirizzamento IP
-
IP addresses
-
-
The network toward Webex Calling must use a IPv4 address. Local Gateway Fully Qualified Domain Names (FQDN) or Service Record (SRV) addresses must resolve to a public IPv4 address on the internet.
-
All SIP and media ports on the Local Gateway interface facing Webex must be accessible from the internet, either directly or via static NAT. Ensure that you update your firewall accordingly.
-
Install a signed certificate on the Local Gateway (the following provides detailed configuration steps).
-
A public Certificate Authority (CA) as detailed in What Root Certificate Authorities are Supported for Calls to Cisco Webex Audio and Video Platforms? must sign the device certificate.
-
The FQDN configured in the Control Hub when creating a trunk must be the Common Name (CN) or Subject Alternate Name (SAN) certificate of the router. Ad esempio:
-
If a configured trunk in the Control Hub of your organization has cube1.lgw.com:5061 as FQDN of the Local Gateway, then the CN or SAN in the router certificate must contain cube1.lgw.com.
-
If a configured trunk in the Control Hub of your organization has lgws.lgw.com as the SRV address of the Local Gateway(s) reachable from the trunk, then the CN or SAN in the router certificate must contain lgws.lgw.com. I record che l SRV indirizzo host risolve in (CNAME, A Record o Indirizzo IP) sono opzionali in SAN.
-
Whether you use an FQDN or SRV for the trunk, the contact address for all new SIP dialogs from your Local Gateway uses the name configured in the Control Hub.
-
-
-
Assicurarsi che i certificati siano firmati per l'uso del client e del server.
-
Upload the Cisco root CA bundle to the Local Gateway.
Configurazione
1 |
Ensure that you assign valid and routable IP addresses to any Layer 3 interfaces, for example:
|
2 |
Protect STUN credentials on the router using symmetric encryption. Configure the primary encryption key and encryption type as follows: |
3 |
Create an encryption trustpoint with a certificate signed by your preferred Certificate Authority (CA). |
4 |
Authenticate your new certificate using your intermediate (or root) CA certificate, then import the certificate (Step 4). Enter the following exec or configuration command:
|
5 |
Import a signed host certificate using the following exec or configuration command:
|
6 |
Enable TLS1.2 exclusivity and specify the default trustpoint using the following configuration commands:
|
7 |
Install the Cisco root CA bundle, which includes the DigiCert CA certificate used by Webex Calling. Use the crypto pki trustpool import clean url command to download the root CA bundle from the specified URL, and to clear the current CA trustpool, then install the new bundle of certificates: If you need to use a proxy for access to the internet using HTTPS, add the following configuration before importing the CA bundle: ip http client proxy-server yourproxy.com proxy-port 80 |
1 |
Create a CUBE certificate-based PSTN trunk for an existing location in Control Hub. For more information, see Configure trunks, route groups, and dial plans for Webex Calling. Make a note of the trunk information that is provided once the trunk is created. These details, as highlighted in the following illustration, will be used in the configuration steps in this guide. |
2 |
Enter the following commands to configure CUBE as a Webex Calling Local Gateway: Di seguito una spiegazione dei campi per la configurazione:
Enables Cisco Unified Border Element (CUBE) features on the platform. consenti-connessioni sip a SIPEnable CUBE basic SIP back to back user agent functionality. For more information, see Allow connections. By default, T.38 fax transport is enabled. For more information, see fax protocol t38 (voice-service). Enables STUN (Session Traversal of UDP through NAT) globally. These global stun commands are only required when deploying your Local Gateway behind NAT.
For more information, see stun flowdata agent-id and stun flowdata shared-secret. asymmetric payload fullConfigures SIP asymmetric payload support for both DTMF and dynamic codec payloads. For more information on this command, see asymmetric payload. offerta anticipata forzataForces the Local Gateway to send SDP information in the initial INVITE message instead of waiting for acknowledgment from the neighboring peer. For more information on this command, see early-offer. sip-profiles inboundEnables CUBE to use SIP profiles to modify messages as they are received. Profiles are applied via dial-peers or tenants. |
3 |
Configure voice class codec 100 codec filter for the trunk. In this example, the same codec filter is used for all trunks. You can configure filters for each trunk for precise control. Di seguito una spiegazione dei campi per la configurazione: voice class codec 100Used to only allow preferred codecs for calls through SIP trunks. For more information, see voice class codec. Opus codec is supported only for SIP-based PSTN trunks. If the PSTN trunk uses a voice T1/E1 or analog FXO connection, exclude codec preference 1 opus from the voice class codec 100 configuration. |
4 |
Configure voice class stun-usage 100 to enable ICE on the Webex Calling trunk. (This step is not applicable for Webex for Government) Di seguito una spiegazione dei campi per la configurazione: stun usage ice liteUsed to enable ICE-Lite for all Webex Calling facing dial-peers to allow media-optimization whenever possible. For more information, see voice class stun usage and stun usage ice lite. The stun usage firewall-traversal flowdata command is only required when deploying your Local Gateway behind NAT. You require stun usage of ICE-lite for call flows using media path optimization. To provide media-optimization for a SIP to TDM gateway, configure a loopback dial-peer with ICE-Lite enabled on the IP-IP leg. For further technical details, contact the Account or TAC teams. |
5 |
Configure the media encryption policy for Webex traffic. (This step is not applicable for Webex for Government) Di seguito una spiegazione dei campi per la configurazione: voice class srtp-crypto 100Specifies SHA1_80 as the only SRTP cipher-suite CUBE offers in the SDP in offer and answer messages. Webex Calling only supports SHA1_80. For more information, see voice class srtp-crypto. |
6 |
Configure FIPS-compliant GCM ciphers (This step is applicable only for Webex for Government). Di seguito una spiegazione dei campi per la configurazione: voice class srtp-crypto 100Specifies GCM as the cipher-suite that CUBE offers. It is mandatory to configure GCM ciphers for Local Gateway for Webex for Government. |
7 |
Configure a pattern to uniquely identify calls to a Local Gateway trunk based on its destination FQDN or SRV: Di seguito una spiegazione dei campi per la configurazione: voice class uri 100 sipDefines a pattern to match an incoming SIP invite to an incoming trunk dial-peer. When entering this pattern, use LGW FQDN or SRV configured in Control Hub while creating a trunk. |
8 |
Configure SIP message manipulation profiles. If your gateway is configured with a public IP address, configure a profile as follows or skip to the next step if you are using NAT. In this example, cube1.lgw.com is the FQDN configured for the Local Gateway and "198.51.100.1" is the public IP address of the Local Gateway interface facing Webex Calling: Di seguito una spiegazione dei campi per la configurazione: rules 10 and 20To allow Webex to authenticate messages from your local gateway, the 'Contact' header in SIP request and responses messages must contain the value provisioned for the trunk in Control Hub. This will either be the FQDN of a single host, or the SRV domain name used for a cluster of devices. Skip the next step if you have configured your Local Gateway with public IP addresses. |
9 |
If your gateway is configured with a private IP address behind static NAT, configure inbound and outbound SIP profiles as follows. In this example, cube1.lgw.com is the FQDN configured for the Local Gateway, "10.80.13.12" is the interface IP address facing Webex Calling and "192.65.79.20" is the NAT public IP address. SIP profiles for outbound messages to Webex Calling
Di seguito una spiegazione dei campi per la configurazione: rules 10 and 20To allow Webex to authenticate messages from your local gateway, the 'Contact' header in SIP request and responses messages must contain the value provisioned for the trunk in Control Hub. This will either be the FQDN of a single host, or the SRV domain name used for a cluster of devices. rules 30 to 81Convert private address references to the external public address for the site, allowing Webex to correctly interpret and route subsequent messages. SIP profile for inbound messages from Webex Calling Di seguito una spiegazione dei campi per la configurazione: rules 10 to 80Convert public address references to the configured private address, allowing messages from Webex to be correctly processed by CUBE. For more information, see voice class sip-profiles. |
10 |
Configure a SIP Options keepalive with header modification profile. Di seguito una spiegazione dei campi per la configurazione: voice class sip-options-keepalive 100Configures a keepalive profile and enters voice class configuration mode. You can configure the time (in seconds) at which an SIP Out of Dialog Options Ping is sent to the dial-target when the heartbeat connection to the endpoint is in UP or Down status. This keepalive profile is triggered from the dial-peer configured towards Webex. To ensure that the contact headers include the SBC fully qualified domain name, SIP profile 115 is used. Rules 30, 40, and 50 are required only when the SBC is configured behind static NAT. In this example, cube1.lgw.com is the FQDN selected for the Local Gateway and if static NAT is used, "10.80.13.12" is the SBC interface IP address towards Webex Calling and "192.65.79.20" is the NAT public IP address. |
11 |
Configure Webex Calling trunk: |
Having built a trunk towards Webex Calling above, use the following configuration to create a non-encrypted trunk towards a SIP based PSTN provider:
If your Service Provider offers a secure PSTN trunk, you may follow a similar configuration as detailed above for the Webex Calling trunk. Secure to secure call routing is supported by CUBE.
If you are using a TDM / ISDN PSTN trunk, skip to next section Configure Local Gateway with TDM PSTN trunk.
To configure TDM interfaces for PSTN call legs on the Cisco TDM-SIP Gateways, see Configuring ISDN PRI.
1 |
Configure the following voice class uri to identify inbound calls from the PSTN trunk: Di seguito una spiegazione dei campi per la configurazione: voice class uri 200 sipDefines a pattern to match an incoming SIP invite to an incoming trunk dial-peer. When entering this pattern, use the IP address of you IP PSTN gateway. For more information, see voice class uri. |
2 |
Configure the following IP PSTN dial-peer: Di seguito una spiegazione dei campi per la configurazione: Definisce un VoIP dial-peer con un tag 200 e fornisce una descrizione significativa per facilità di gestione e risoluzione dei problemi. For more information, see dial-peer voice. percorso-destinazione BAD. MaleA dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. For more information, see destination-pattern (interface). protocollo sessione sipv2Specifica che il dial-peer 200 gestisce i mani della chiamata SIP. For more information, see session protocol (dial peer). destinazione sessione ipv4:192.168.80.13Indica l'indirizzo IPv4 di destinazione per l'invio del gruppo di chiamata. L'obiettivo della sessione è l'indirizzo IP di ITSP. For more information, see session target (VoIP dial peer). incoming uri via 200Definisce un criterio di corrispondenza per l'intestazione VIA con l'indirizzo IP PSTN is address dell'ip del provider di connessioni IP. Matches all incoming IP PSTN call legs on the Local Gateway with dial-peer 200. For more information, see incoming url. bind control source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for messages sent to the PSTN. For more information, see bind. bind media source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for media sent to PSTN. For more information, see bind. codec classe vocale 100Configures the dial-peer to use the common codec filter list 100. For more information, see voice-class codec. dtmf-relay rtp-nteDefinisce RTP-NTE (RFC2833) come funzionalità DTMF prevista sul modello della chiamata. For more information, see DTMF Relay (Voice over IP). nessun vadDisabilita il rilevamento dell'attività vocale. For more information, see vad (dial peer). |
3 |
If you are configuring your Local Gateway to only route calls between Webex Calling and the PSTN, add the following call routing configuration. If you are configuring your Local Gateway with a Unified Communications Manager platform, skip to the next section. |
Having built a trunk towards Webex Calling, use the following configuration to create a TDM trunk for your PSTN service with loop-back call routing to allow media optimization on the Webex call leg.
1 |
The loop-back dial-peer configuration uses dial-peer groups and call routing tags to ensure that calls pass correctly between Webex and the PSTN, without creating call routing loops. Configure the following translation rules that will be used to add and remove the call routing tags: Di seguito una spiegazione dei campi per la configurazione: voice translation-ruleUses regular expressions defined in rules to add or remove call routing tags. Over-decadic digits (‘A’) are used to add clarity for troubleshooting. In this configuration, the tag added by translation-profile 100 is used to guide calls from Webex Calling towards the PSTN via the loopback dial-peers. Similarly, the tag added by translation-profile 200 is used to guide calls from the PSTN towards Webex Calling. Translation-profiles 11 and 12 remove these tags before delivering calls to the Webex and PSTN trunks respectively. This example assumes that called numbers from Webex Calling are presented in +E.164 format. Rule 100 removes the leading + to maintain a valid called number. Rule 12 then adds a national or international routing digit(s) when removing the tag. Use digits that suit your local ISDN national dial plan. If Webex Calling presents numbers in national format, adjust rules 100 and 12 to simply add and remove the routing tag respectively. For more information, see voice translation-profile and voice translation-rule. |
2 |
Configure TDM voice interface ports as required by the trunk type and protocol used. For more information, see Configuring ISDN PRI. For example, the basic configuration of a Primary Rate ISDN interface installed in NIM slot 2 of a device might include the following: |
3 |
Configure the following TDM PSTN dial-peer: Di seguito una spiegazione dei campi per la configurazione: Definisce un VoIP dial-peer con un tag 200 e fornisce una descrizione significativa per facilità di gestione e risoluzione dei problemi. For more information, see dial-peer voice. percorso-destinazione BAD. MaleA dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. For more information, see destination-pattern (interface). translation-profile incoming 200Assigns the translation profile that will add a call routing tag to the incoming called number. direct-inward-dialRoutes the call without providing a secondary dial-tone. For more information, see direct-inward-dial. port 0/2/0:15The physical voice port associated with this dial-peer. |
4 |
To enable media optimization of IP paths for Local Gateways with TDM-IP call flows, you can modify the call routing by introducing a set of internal loop-back dial-peers between Webex Calling and PSTN trunks. Configure the following loop-back dial-peers. In this case, all incoming calls will be routed initially to dial-peer 10 and from there to either dial-peer 11 or 12 based on the applied routing tag. After removal of the routing tag, calls will be routed to the outbound trunk using dial-peer groups. Di seguito una spiegazione dei campi per la configurazione: Defines a VoIP dial-peer and gives a meaningful description for ease of management and troubleshooting. For more information, see dial-peer voice. translation-profile incoming 11Applies the translation profile defined earlier to remove the call routing tag before passing to the outbound trunk. percorso-destinazione BAD. MaleA dummy destination pattern is required when routing outbound calls using an inbound dial-peer group. For more information, see destination-pattern (interface). protocollo sessione sipv2Specifies that this dial-peer handles SIP call legs. For more information, see session protocol (dial peer). session target 192.168.80.14Specifies the local router interface address as the call target to loop-back. For more information, see session target (voip dial peer). bind control source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for messages sent through the loop-back. For more information, see bind. bind media source-interface GigabitEthernet0/0/0Configures the source interface and associated IP address for media sent through the loop-back. For more information, see bind. dtmf-relay rtp-nteDefinisce RTP-NTE (RFC2833) come funzionalità DTMF prevista sul modello della chiamata. For more information, see DTMF Relay (Voice over IP). codec g711alaw Forces all PSTN calls to use G.711. Select a-law or u-law to match the companding method used by your ISDN service. nessun vadDisabilita il rilevamento dell'attività vocale. For more information, see vad (dial peer). |
5 |
Add the following call routing configuration: This concludes your Local Gateway configuration. Save the configuration and reload the platform if this is the first time CUBE features are configured.
|
The PSTN-Webex Calling configuration in the previous sections may be modified to include additional trunks to a Cisco Unified Communications Manager (UCM) cluster. In this case, all calls are routed via Unified CM. Calls from UCM on port 5060 are routed to the PSTN and calls from port 5065 are routed to Webex Calling. The following incremental configurations may be added to include this calling scenario.
1 |
Configura i seguenti URI di classe vocale: |
2 |
Configure the following DNS records to specify SRV routing to Unified CM hosts: IOS XE uses these records for locally determining target UCM hosts and ports. With this configuration, it is not required to configure records in your DNS system. If you prefer to use your DNS, then these local configurations are not required. Di seguito una spiegazione dei campi per la configurazione: The following command creates a DNS SRV resource record. Create a record for each UCM host and trunk: ip host _sip._udp.pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: SRV resource record name 2: The SRV resource record priority 1: The SRV resource record weight 5060: The port number to use for the target host in this resource record ucmsub5.mydomain.com: The resource record target host To resolve the resource record target host names, create local DNS A records. Ad esempio: ip host ucmsub5.mydomain.com 192.168.80.65 ip host: Creates a record in the local IOS XE database. ucmsub5.mydomain.com: The A record host name. 192.168.80.65: The host IP address. Create the SRV resource records and A records to reflect your UCM environment and preferred call distribution strategy. |
3 |
Configure the following dial-peers: |
4 |
Add call routing using the following configurations: |
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) is a single source to find applicable signatures for monitoring and troubleshooting various problems.
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.
-
Configure the secure email server that you use to send proactive notification if the device is running IOS XE 17.6.1 or higher.
configure terminal call-home mail-server <username>:<pwd>@<email 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 <email address> 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. If SNMP is not enabled, then configure the snmp-server manager command.
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 trap globali SNMP: abilitato
Scarica DS 64224 utilizzando le seguenti opzioni del menu a discesa nello strumento DSLT:
copy ftp://username:password@<server name or ip>/DS_64224.xml bootflash:
Nome campo
Valore campo
Piattaforma
Cisco 4300, 4400 ISR Series, or Catalyst 8000V Edge Software
Prodotto
CUBE Enterprise in Webex Calling solution
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@<server name or ip>/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: Firma diagnostica: profilo abilitato: CiscoTAC-1 (stato: ACTIVE) URL di download: 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
This DS uses SNMP polling every 10 minutes to detect abnormal call disconnect with SIP errors 403, 488 and 503. If the error count increment is greater than or equal to 5 from the last poll, it generates a syslog and email notification. Please use the steps below to install the signature.
-
Accertarsi che SNMP sia abilitato utilizzando il comando show snmp. If SNMP is not enabled, configure the snmp-server manager command.
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 trap globali SNMP: abilitato
-
Scarica DS 65221 utilizzando le seguenti opzioni nello strumento DSLT:
Nome campo
Valore campo
Piattaforma
Cisco 4300, 4400 ISR Series, or Catalyst 8000V Edge Software
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@<server name or ip>/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
-
Use the command show call-home diagnostic-signature to verify that the signature is successfully installed. 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:
Configure another DS environment variable ds_fsurl_prefix as the Cisco TAC file server path (cxd.cisco.com) to upload the diagnostics data. The username in the file path is the case number and the password is the file upload token which can be retrieved from Support Case Manager as shown in the following. The file upload token can be generated in the Attachments section of the Support Case Manager, as required.
configure terminal call-home diagnostic-signature LocalGateway(cfg-call-home-diag-sign)environment ds_fsurl_prefix "scp://<case number>:<file upload token>@cxd.cisco.com" end
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. If SNMP not enabled, configure the snmp-server manager command.
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
Cisco 4300, 4400 ISR Series, or Catalyst 8000V Edge Software
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, 4400 ISR Series, or Catalyst 8000V Edge Software
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@<server name or ip>/DS_64224.xml bootflash: copy ftp://username:password@<server name or ip>/DS_65095.xml bootflash:
-
Install the high CPU monitoring DS 64224 and then DS 65095 XML file in the Local Gateway.
call-home diagnostic-signature load DS_64224.xml Load file DS_64224.xml success call-home diagnostic-signature load DS_65095.xml Load file DS_65095.xml success
-
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: Firma diagnostica: profilo abilitato: CiscoTAC-1 (stato: ACTIVE) URL di download: 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: Firma diagnostica: profilo
abilitato: CiscoTAC-1 (stato: ACTIVE)
URL di download: 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 |
Triggered/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 <DS ID>
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.
Implementazione dell'alta disponibilità CUBE come gateway locale
Nozioni fondamentali
Prerequisiti
Prima di distribuire CUBE HA come gateway locale per Webex Calling, accertarti di aver compreso pienamente i seguenti concetti:
-
Ridondanza box-to-box layer 2 con CUBE Enterprise per conservazione delle chiamate con stato
Le linee guida di configurazione fornite in questo articolo presuppongono una piattaforma gateway locale dedicata che non prevede alcuna configurazione vocale esistente. Se viene modificata una distribuzione CUBE Enterprise esistente per utilizzare anche la funzione gateway locale per Cisco Webex Calling, presta attenzione alla configurazione applicata per garantire che i flussi di chiamata e le funzionalità esistenti non vengano interrotte e che stai soddisfacendo i requisiti di progettazione CUBE HA.
Componenti hardware e software
CUBE HA come gateway locale richiede IOS-XE versione 16.12.2 o successiva e una piattaforma su cui sono supportate entrambe le funzioni CUBE HA e LGW.
I comandi show e i registri in questo articolo si basano sulla release software minima di Cisco IOS-XE 16.12.2 implementata su vCUBE (CSR1000v).
Materiale di riferimento
Di seguito sono riportate alcune guide alla configurazione di CUBE HA dettagliate per diverse piattaforme:
-
Serie ISR 4K— https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-ISR4K.html
-
CSR 1000v (vCUBE)– https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
-
Architettura preferita Cisco per Cisco Webex Calling– https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Panoramica della soluzione Webex Calling
Cisco Webex Calling è un servizio di collaborazione che offre un'alternativa basata su cloud multi-tenant al servizio telefonico PBX locale con più opzioni PSTN per i clienti.
La distribuzione del gateway locale (rappresentata di seguito) è il fulcro di questo articolo. Il trunk del gateway locale (PSTN locale) in Webex Calling consente la connettività a un servizio PSTN di proprietà del cliente. Fornisce anche la connettività a una distribuzione PBX IP locale, ad esempio Cisco Unified CM. Tutte le comunicazioni da e verso il cloud vengono protette utilizzando il trasporto TLS per SIP e SRTP per contenuti multimediali.
La figura seguente mostra una distribuzione Webex Calling senza un PBX IP esistente ed è applicabile a una distribuzione per singolo sito o più siti. La configurazione descritta in questo articolo si basa su questa distribuzione.
Ridondanza box-to-box layer 2
La ridondanza box-to-box layer 2 CUBE HA utilizza il protocollo dell'infrastruttura RG (Redundancy Group) per formare una coppia di router attivo/standby. Questa coppia condivide lo stesso indirizzo IP virtuale (VIP) sulle relative interfacce e scambia continuamente messaggi di stato. Le informazioni di sessione CUBE vengono verificate sulla coppia di router consentendo al router standby di assumere immediatamente tutte le responsabilità di elaborazione delle chiamate CUBE se il router attivo è fuori uso, in modo da preservare segnali e contenuti multimediali.
La verifica è limitata a chiamate connesse con pacchetti multimediali. Le chiamate in transito non vengono verificate (ad esempio, tentativi di chiamata o chiamate che squillano in attesa di risposta).
In questo articolo, CUBE HA fa riferimento alla ridondanza CUBE High Availability (HA) Box-to-box (B2B) layer 2 per la conservazione delle chiamate con stato
A partire da IOS-XE 16.12.2, CUBE HA può essere distribuito come gateway locale per distribuzioni di trunk Cisco Webex Calling (PSTN locale) e in questo articolo verranno riportate alcune considerazioni di progettazione e configurazioni. L'immagine mostra una tipica impostazione di CUBE HA come gateway locale per una distribuzione di trunk Cisco Webex Calling.
Componente Infra del gruppo di ridondanza
Il componente Infra del gruppo di ridondanza (RG, Redundancy Group) fornisce il supporto dell'infrastruttura di comunicazione box-to-box tra i due CUBE e negozia lo stato di ridondanza stabile finale. Questo componente fornisce anche:
-
Un protocollo simile a HSRP che negozia lo stato di ridondanza finale per ciascun router scambiando messaggi keepalive e hello tra i due CUBE (tramite l'interfaccia di controllo), GigabitEthernet3 nella figura precedente.
-
Un meccanismo di trasporto per la verifica dello stato di segnali e contenuti multimediali per ciascuna chiamata dal router attivo al router standby (tramite l'interfaccia dati), GigabitEthernet3 nella figura precedente.
-
Configurazione e gestione dell'interfaccia IP virtuale (VIP) per le interfacce di traffico (più interfacce di traffico possono essere configurate utilizzando lo stesso gruppo RG), GigabitEthernet 1 e 2 sono considerate interfacce di traffico.
Questo componente RG deve essere configurato in modo specifico per supportare il sistema vocale B2B HA.
Gestione degli indirizzi IP virtuali (VIP) per segnali e contenuti multimediali
B2B HA si basa sull'IP virtuale per ottenere ridondanza. Il VIP e le interfacce fisiche associate su entrambi i CUBE nella coppia CUBE HA devono risiedere sulla stessa subnet LAN. La configurazione del VIP e l'associazione dell'interfaccia VIP a una determinata applicazione vocale (SIP) sono obbligatorie per il supporto vocale B2B HA. I dispositivi esterni come Unified CM, controller SBC di accesso a Webex Calling, provider di servizi o proxy, utilizzano il VIP come indirizzo IP di destinazione per le chiamate che attraversano i router CUBE HA. Pertanto, dal punto di vista di Webex Calling, le coppie di CUBE HA agiscono come un singolo gateway locale.
Le informazioni su segnale di chiamata e sessione RTP delle chiamate stabilite vengono verificate dal router attivo al router di standby. Quando il router Attivo non è attivo, il router Standby subentra e continua a inoltrare il flusso RTP precedentemente indirizzato dal primo router.
Le chiamate in uno stato temporaneo al momento del failover non verranno mantenute dopo il cambio. Ad esempio, le chiamate non ancora completamente stabilite o in corso di modifica con una funzione di trasferimento o attesa. Le chiamate stabilite possono essere disconnesse dopo il cambio.
Esistono i seguenti requisiti per l'uso di CUBE HA come gateway locale per il failover delle chiamate:
-
CUBE HA non può avere interfacce TDM o analogiche co-posizionate
-
Le interfacce Gig1 e Gig2 sono denominate interfacce di traffico (SIP/RTP) e Gig3 è l'interfaccia di controllo RG/dati
-
Non è possibile inserire più di 2 coppie CUBE HA nello stesso dominio layer 2, una con ID gruppo 1 e l'altra con ID gruppo 2. Se configuri 2 coppie HA con lo stesso ID gruppo, le interfacce di controllo RG/dati devono appartenere a domini layer 2 diversi (vlan, switch separato)
-
Il canale delle porte è supportato per entrambe le interfacce di controllo RG/dati e di traffico
-
Tutti i segnali/contenuti multimediali sono originati da/all'indirizzo IP virtuale
-
Ogni volta che una piattaforma viene ricaricata in una relazione CUBE-HA, viene sempre avviata come Standby
-
L'indirizzo inferiore per tutte le interfacce (Gig1, Gig2, Gig3) deve essere sulla stessa piattaforma
-
L'identificativo dell'interfaccia di ridondanza, rii, deve essere univoco per una combinazione di coppia/interfaccia nello stesso Layer 2
-
La configurazione su entrambi i CUBE deve essere identica, inclusa la configurazione fisica, e deve essere in esecuzione sullo stesso tipo di piattaforma e versione IOS-XE
-
Non è possibile utilizzare interfacce di loopback come associazione perché sono sempre attive
-
Più interfacce di traffico (SIP/RTP) (Gig1, Gig2) richiedono la configurazione del rilevamento dell'interfaccia
-
CUBE-HA non è supportato su una connessione via cavo crossover per il collegamento controllo RG/dati (Gig3)
-
Entrambe le piattaforme devono essere identiche e connesse tramite uno switch fisico su tutte le interfacce simili affinché CUBE HA funzioni, ossia GE0/0/0 di CUBE-1 e CUBE-2 devono terminare sullo stesso switch e così via.
-
Non è possibile impostare WAN con terminazione diretta su CUBE o Data HA su entrambi i lati
-
Entrambi i router, Attivo/Standby, devono essere nello stesso centro dati
-
È obbligatorio utilizzare un'interfaccia L3 separata per ridondanza (controllo RG/dati, Gig3), ossia l'interfaccia utilizzata per il traffico non può essere utilizzata per keepalive e verifica HA
-
Al momento del failover, il CUBE precedentemente attivo passa attraverso un ricaricamento per impostazione predefinita, preservando segnali e contenuti multimediali
Configurazione della ridondanza su entrambi i CUBE
Devi configurare la ridondanza box-to-box layer 2 su entrambi i CUBE da utilizzare in una coppia HA per visualizzare IP virtuali.
1 |
Configura il rilevamento dell'interfaccia a livello globale per rilevare lo stato dell'interfaccia.
La CLI di rilevamento viene utilizzata in RG per rilevare lo stato dell'interfaccia di traffico vocale in modo che il router attivo esca dal ruolo attivo una volta disattivata l'interfaccia di traffico. | ||
2 |
Configura un RG per l'uso con VoIP HA nella modalità secondaria di ridondanza dell'applicazione.
Di seguito una spiegazione dei campi utilizzati in questa configurazione:
| ||
3 |
Abilita la ridondanza box-to-box per l'applicazione CUBE. Configurare RG dal punto precedente in
redundancy-group 1—Adding and removing this command requires a reload for the updated configuration to take effect. Le piattaforme verranno ricaricate una volta applicata la configurazione. | ||
4 |
Configura le interfacce Gig1 e Gig2 con i relativi IP virtuali come mostrato di seguito e applica l'identificativo dell'interfaccia di ridondanza (rii)
Di seguito una spiegazione dei campi utilizzati in questa configurazione:
| ||
5 |
Salva la configurazione del primo CUBE e ricaricala. La piattaforma da ricaricare per ultima è sempre Standby.
Dopo aver avviato completamente VCUBE-1, salvare la configurazione di VCUBE-2 e ricaricarla.
| ||
6 |
Verifica che la configurazione box-to-box funzioni come previsto. L'output rilevante è evidenziato in grassetto. VCUBE-2 è stato ricaricato per ultimo e in base alle considerazioni di progettazione; la piattaforma da ricaricare per ultima sarà sempre Standby. |
Configurazione di un gateway locale su entrambi i CUBE
Nella configurazione dell'esempio, stiamo utilizzando le seguenti informazioni di trunk di Control Hub per creare la configurazione del gateway locale su entrambe le piattaforme, VCUBE-1 e VCUBE-2. Il nome utente e la password per questa impostazione sono i seguenti:
-
Nome utente: Hussain1076_LGU
-
Password: lOV12MEaZx
1 |
Assicurati che venga creata una chiave di configurazione per la password, con i comandi shown di seguito, prima di poterla utilizzare in credenziali o segreti condivisi. Le password di tipo 6 sono crittografate utilizzando cifratura AES e questa chiave di configurazione definita dall'utente.
Di seguito è riportato la configurazione del gateway locale che si applicherà a entrambe le piattaforme in base ai parametri di Control Hub visualizzati sopra, Salva e ricarica. SIP Digest credentials from Control Hub are highlighted in bold.
Per visualizzare l'output del comando show, è stato ricaricato VCUBE-2 seguito da VCUBE-1, rendendo VCUBE-1 il CUBE standby e VCUBE-2 il CUBE attivo |
2 |
In un determinato momento, solo una piattaforma manterrà una registrazione attiva come gateway locale con il controller SBC di accesso a Webex Calling. Dai un'occhiata all'output dei seguenti comandi show. show redundancy application group 1 show sip-ua register status
From the output above, you can see that VCUBE-2 is the active LGW maintaining the registration with Webex Calling access SBC, whereas the output of the “show sip-ua register status” is blank in VCUBE-1 |
3 |
Ora abilita i seguenti debug su VCUBE-1
|
4 |
Simula il failover specificando il seguente comando sull'LGW attivo, VCUBE-2 in questo caso.
Il passaggio dall'LGW ACTIVE a STANDBY si verifica nei seguenti casi oltre alla CLI sopra elencata
|
5 |
Controlla se VCUBE-1 è stato registrato con il controller SBC di accesso a Webex Calling. VCUBE-2 dovrebbe essere stato ricaricato ora.
VCUBE-1 è ora l'LGW attivo. |
6 |
Esamina il registro di debug pertinente su VCUBE-1 inviando un SIP REGISTER a Webex Calling tramite IP virtuale e ricevendo un 200 OK.
|
Configurazione di Unified CM per Webex Calling
Configurazione del profilo di sicurezza del trunk SIP per il trunk al gateway locale
Nei casi in cui il gateway locale e il gateway PSTN risiedano sullo stesso dispositivo, Unified CM deve essere abilitato per distinguere due diversi tipi di traffico (chiamate da Webex e dalla PSTN) che hanno origine dallo stesso dispositivo e applicare una classe differenziata di servizio a questi tipi di chiamata. Questo tipo di gestione differenziata delle chiamate viene realizzato predisponendo due trunk tra Unified CM e il gateway locale combinato e un dispositivo gateway PSTN che richiede porte di ascolto SIP diverse per i due trunk.
Crea un profilo di sicurezza del trunk SIP dedicato per il trunk del gateway locale con le seguenti impostazioni:
|
Configurazione del profilo SIP per il trunk del gateway locale
Crea un profilo SIP dedicato per il trunk del gateway locale con le seguenti impostazioni:
|
Creazione di uno spazio di ricerca di chiamata per le chiamate da Webex
Crea uno spazio di ricerca chiamata per le chiamate provenienti da Webex con le seguenti impostazioni:
L'ultima partizione onNetRemote viene utilizzata solo in un ambiente multicluster in cui le informazioni di indirizzamento vengono scambiate tra i cluster Unified CM utilizzando il servizio di ricerca intercluster (ILS) o la replica del piano di chiamata globale (GDPR). |
Configurazione di un trunk SIP da e verso Webex
Crea un trunk SIP per le chiamate da e verso Webex attraverso il gateway locale con le seguenti impostazioni:
|
Configurazione del gruppo di indirizzamento per Webex
Crea un gruppo di indirizzamento con le seguenti impostazioni:
|
Configurazione dell'elenco di indirizzamento per Webex
Crea un elenco di indirizzamento con le seguenti impostazioni:
|
Creazione di una partizione per le destinazioni Webex
Crea una partizione per le destinazioni Webex con le seguenti impostazioni:
|
Operazione successivi
Accertati di aggiungere questa partizione a tutti gli spazi di ricerca chiamata che devono avere accesso alle destinazioni Webex. Devi aggiungere questa partizione in modo specifico allo spazio di ricerca chiamata utilizzato come spazio di ricerca di chiamata in ingresso sui trunk PSTN, in modo che le chiamate dalla PSTN a Webex possano essere indirizzate.
Configurazione dei percorsi di indirizzamento per le destinazioni Webex
Configura i percorsi di indirizzamento per ogni intervallo DID su Webex con le seguenti impostazioni:
|
Configurazione della normalizzazione chiamata intersito abbreviata per Webex
Se è richiesta la chiamata intersito abbreviata a Webex, configura gli schemi di normalizzazione chiamata per ciascun intervallo ESN su Webex con le seguenti impostazioni:
|
Impostazione delle funzioni di Webex Calling
Imposta una gruppo di risposta
I gruppi di risposta instradare le chiamate in arrivo a un gruppo di utenti o aree di lavoro. Puoi persino configurare un percorso per l'indirizzamento a un intero gruppo.
Per ulteriori informazioni sull'impostazione di una gruppo di risposta, vedere Gruppi di risposta in Cisco Webex Control Hub.
Crea una coda chiamata
Puoi impostare una coda chiamate in modo che quando non è possibile rispondere alle chiamate dei clienti, viene fornita loro una risposta automatica, messaggi di cortesia e musica di attesa finché qualcuno non risponde alla chiamata.
Per ulteriori informazioni su come impostare e gestire una conferenza coda chiamata, vedere Gestione delle code chiamata in Cisco Webex Control Hub.
Creare un client receptionist
Il client receptionist assiste nel supporto delle esigenze del personale di front-office. È possibile impostare gli utenti come operatori telefonici in modo che possano selezionare le chiamate in arrivo a determinate persone all'interno della propria organizzazione.
Per informazioni su come impostare e visualizzare i client receptionist, vedi Client receptionist in Cisco Webex Control Hub.
Creazione e gestione dei operatori automatici
Puoi aggiungere messaggi di saluto, impostare menu e indirizzare le chiamate a un servizio di risposta, a un gruppo di risposta, a una casella vocale o a una persona reale. Creare una pianificazione di 24 ore o fornire opzioni diverse quando la propria azienda è aperta o chiusa.
Per informazioni su come creare e gestire i operatori automatici, vedere Gestione dei operatori automatici Cisco Webex Control Hub.
Configurare una gruppo di cercapersone
La funzione di cercapersone di gruppo consente a un utente di effettuare una chiamata a una via o una chiamata di gruppo con cercapersone fino a 75 utenti e spazi di lavoro di destinazione componendo un numero o un interno assegnato a uno specifico gruppo di cercapersone.
Per informazioni su come impostare e modificare i gruppi di cercapersone, vedere Configurazione di un gruppo di cercapersone Cisco Webex Control Hub.
Imposta risposta per assente
Ottimizza il lavoro in team e la collaborazione creando risposta per assente gruppo in modo che gli utenti possano rispondere alle chiamate degli altri. Quando aggiungi utenti a un gruppo di risposta per assente e un membro del gruppo è assente o è occupato, un altro membro può rispondere alle sue chiamate.
Per informazioni su come impostare un gruppo di risposta per assente, vedi Risposta per assente in Cisco Webex Control Hub.
Imposta parcheggio chiamata
Il parcheggio chiamata consente a un gruppo definito di utenti di parcheggiare le chiamate su altri membri disponibili di un gruppo di parcheggio chiamata. Alle chiamate parcheggiate possono rispondere altri membri del gruppo sul proprio telefono.
Per ulteriori informazioni sull'impostazione del parcheggio chiamata, vedi Parcheggio chiamata in Cisco Webex Control Hub.
Abilita inclusione per gli utenti
1 |
Dalla vista cliente in https://admin.webex.com, vai a . |
2 |
Seleziona un utente e fai clic su Calling. |
3 |
Andare alla sezione Autorizzazioni tra utenti , quindi selezionare Inclusione. |
4 |
Attiva il tasto di alternanza per consentire ad altri utenti di aggiungersi alla chiamata in corso di questo utente. |
5 |
Selezionare Riproduci un tono quando questo utente partecipa a una chiamata se si desidera riprodurre un tono agli altri quando questo utente partecipa alla chiamata. La riproduzione di un tono quando l'utente partecipa a un'impostazione di chiamata non si applica alla funzionalità di inclusione supervisore Base ed Elementi essenziali dell'esperienza cliente. Anche se si abilita questa opzione per un supervisore, il sistema non riproduce il tono di notifica all'agente quando un supervisore inserisce la chiamata nella coda chiamata. Se si desidera riprodurre un tono a un agente quando un supervisore partecipa alla chiamata, è possibile abilitarlo attraverso le impostazioni di "Segnale di notifica per gli agenti". Per ulteriori informazioni, vedere la sezione Creazione di una coda in Webex Customer Experience Basic o Webex Customer Experience Essentials. |
6 |
Fai clic su Salva. |
Abilita privacy per un utente
1 |
Accedi a Control Hub e vai a . |
2 |
Scegli un utente e fai clic su Chiamata. |
3 |
Andare all'area Autorizzazioni tra utenti e scegliere Privacy. |
4 |
Scegli le impostazioni di Privacy operatore automatico appropriate per questo utente.
|
5 |
Seleziona la casella di controllo Abilita privacy. Puoi quindi decidere di bloccare tutti non scegliendo membri dall'elenco a discesa. In alternativa, puoi scegliere gli utenti, gli spazi di lavoro e le linee virtuali che possono monitorare lo stato della linea di questo utente. Se sei un amministratore di posizione, solo gli utenti, gli spazi di lavoro e le linee virtuali relative alle tue posizioni assegnate vengono visualizzati nell'elenco a discesa. Deselezionare la casella di controllo Abilita privacy per consentire a tutti di monitorare lo stato della linea. |
6 |
Seleziona la casella di controllo Applica privacy per risposta per assente indirizzata e inclusione per abilitare la privacy per risposta per assente indirizzata e inclusione.
|
7 |
Da Aggiungi membro per nome, scegli utenti, spazi di lavoro e linee virtuali che possono monitorare lo stato della linea telefonica e richiamare risposta per assente indirizzata e inclusione. |
8 |
Per filtrare i membri selezionati, utilizzare il filtro per nome, numero o campo interno . |
9 |
Fare clic su Rimuovi tutto per rimuovere tutti i membri selezionati. Per rimuovere un singolo membro, fai clic su Elimina accanto al nome del membro. |
10 |
Fai clic su Salva. |
Configura monitoraggio
Il numero massimo di linee monitorate per un utente è 50. Tuttavia, durante la configurazione dell'elenco di monitoraggio, considera il numero di messaggi che incidono sulla larghezza di banda tra Webex Calling e la rete. Inoltre, determinare il numero massimo di linee monitorate in base al numero di pulsanti linea sul telefono dell'utente.
1 |
Dalla vista cliente in https://admin.webex.com, vai a Gestione , quindi fai clic su Utenti. |
2 |
Seleziona l'utente che desideri modificare e fai clic su Chiamata. |
3 |
Andare alla sezione Autorizzazioni tra utenti e selezionare Monitoraggio. |
4 |
Scegliere una delle opzioni seguenti:
È possibile includere una linea virtuale nell'elenco Aggiungi linea monitorata per il monitoraggio degli utenti. |
5 |
Scegli se desideri notificare a questo utente le chiamate parcheggiate, cerca la persona o l'interno del parcheggio chiamata da monitorare, quindi fai clic su Salva. L'elenco di linee monitorate in Control Hub corrisponde all'ordine delle linee monitorate visualizzate sul dispositivo dell'utente. È possibile riordinare l'elenco delle linee monitorate in qualsiasi momento. Il nome visualizzato per la linea monitorata è il nome inserito nei campi Nome e Cognome dell'ID chiamante per l'utente, lo spazio di lavoro e la linea virtuale. |
Abilita segnale di avviso bridge chiamata per gli utenti
Operazioni preliminari
1 |
Accedi a Control Hub e vai a . |
2 |
Seleziona un utente e fai clic sulla scheda Chiamata. |
3 |
Vai a Autorizzazioni tra utenti e fai clic su Segnale di avviso bridge chiamata. |
4 |
Attiva Segnale di avviso bridge chiamata, quindi fai clic su Salva. Per impostazione predefinita, questa funzione è abilitata. Per ulteriori informazioni sul bridge di chiamata su una linea condivisa MPP, vedere Linee condivise sul telefono fisso multipiattaforma. Per ulteriori informazioni sul bridge di chiamata su una linea condivisa dell'app Webex, vedi Identificativo di linea condivisa per WebexApp. |
Attivare l'hotel per un utente
1 |
Dalla vista cliente in https://admin.webex.com, vai a Gestione e seleziona Utenti. |
2 |
Seleziona un utente e fai clic sulla scheda Chiamata. |
3 |
Vai alla sezione Autorizzazioni tra utenti e seleziona Modalità hotel e attiva il tasto di alternanza. |
4 |
Immettere il nome o il numero dell'organizzatore della modalità hotel nel campo di ricerca Posizione modalità hotel e scegliere l'organizzatore della modalità hotel che si desidera assegnare all'utente. È possibile selezionare solo un organizzatore in modalità hotel. Se scegli un altro organizzatore della modalità hotel, il primo viene eliminato. In qualità di amministratore della posizione, puoi assegnare solo l'organizzatore della modalità hotel relativo alle tue posizioni assegnate. |
5 |
Per limitare il tempo di associazione di un utente all'host della modalità hotel, scegliere il numero di ore in cui l'utente può utilizzare l'host della modalità hotel dall'elenco a discesa Limite periodo di associazione . L'utente verrà disconnesso automaticamente dopo l'orario scelto. Nella schermata viene visualizzato un messaggio di errore se il periodo di associazione limite specificato per l'utente supera il periodo di associazione limite dell'host della modalità hotel scelto. Ad esempio, se l'organizzatore della modalità hotel ha un periodo di associazione limite di 12 ore e il periodo di associazione limite dell'utente è di 24 ore, viene visualizzato un messaggio di errore. In tali casi, è necessario estendere il periodo di associazione limite dell'host della modalità hotel, se è necessario più tempo per l'utente. |
6 |
Fai clic su Salva. Un utente può anche ricercare e individuare l'host della modalità hotel che desidera utilizzare da Hub utente. Per ulteriori informazioni, vedi Accesso al tuo profilo di chiamata da qualsiasi luogo. |
Tendenze di adozione e report di utilizzo per Webex Calling
Visualizza report chiamata
Puoi utilizzare la pagina Analisi in Control Hub per ottenere informazioni su come le persone utilizzano Webex Calling e l'app Webex (coinvolgimento) nonché sulla qualità della loro esperienza multimediale di chiamata. Per accedere alla funzionalità di analisi di Webex Calling, accedi a Control Hub, quindi vai a Analisi e seleziona la scheda Chiamata .
1 |
Per report dettagliati della cronologia chiamate, accedi a Control Hub, quindi vai a . |
2 |
Selezionare Cronologia chiamate dettagliata. Per informazioni sulle chiamate tramite istanza dedicata, vedi Analisi istanza dedicata. |
3 |
Per accedere ai dati di qualità multimediale, accedi a Control Hub, quindi vai a Analisi e seleziona Chiamata. Per ulteriori informazioni, vedi Analisi per il portfolio Cloud Collaboration.
|
Eseguire lo strumento CScan
CScan è uno strumento di preparazione della rete progettato per testare la connessione di rete a Webex Calling.
Per ulteriori informazioni, vedi Uso di CScan per testare la qualità della rete Webex Calling. |