- Home
- /
- Articolo
Grazie per il feedback.
Guida alla distribuzione della migrazione
In questo articolo
Feedback?Il processo di migrazione strutturato da Cisco Unified CM on-premise a quello basato su cloud Webex Calling, utilizzando la metodologia PPDIO. Ciò comporta considerazioni di progettazione critiche come la selezione della regione, i piani di chiamata, i servizi di emergenza e la registrazione delle chiamate. Il processo anche dettagli sulle licenze, provisioning degli utenti, SSO e prontezza della rete per garantire un'esperienza fluida e transizione efficiente.
Introduzione
Operazioni preliminari
Questa guida è destinata a team o individui con esperienza nella configurazione e amministrazione di Cisco Unified Communications Manager (Unified CM) e degli endpoint Cisco, tra cui telefoni IP da scrivania, dispositivi video e client software Jabber. In questo documento sono presenti link alla documentazione del prodotto e di supporto per fornire assistenza.
Questo documento si concentra esclusivamente sulle transizioni da Unified CM a Webex Calling multi-tenant. Il termine Webex Calling in questo documento si riferisce sempre a Webex Calling multi-tenant.
Prima di iniziare la migrazione da Unified CM a Webex Calling, è fondamentale avere una conoscenza approfondita della soluzione Webex Calling e dei suoi rispettivi componenti. Per una migrazione di successo è necessario avere familiarità con l'architettura di Webex Calling, i modelli di servizio, le opzioni di distribuzione e le funzionalità associate per mappare correttamente i carichi di lavoro Unified CM esistenti e progettare un piano di transizione efficace.
Una conoscenza approfondita dei seguenti componenti di Webex Calling è essenziale per definire una strategia di transizione efficace e la prontezza operativa.
-
Control Hub
-
Directory e provisioning degli utenti
-
Piattaforma Webex Calling
-
Endpoint di chiamata supportati
-
Opzioni di connettività PSTN
-
Piano di chiamata e gestione dei numeri di Webex Calling
-
Funzionalità di sicurezza e conformità.
Per ulteriori informazioni, vedere Architettura preferita Cisco per Webex Calling.
Questa guida evidenzierà gli strumenti e i processi da utilizzare durante l'intero ciclo di vita della transizione. Tuttavia, la transizione dalle chiamate in sede, Unified CM, a una nuova piattaforma di chiamate cloud, Webex Calling, può rappresentare uno sforzo significativo, con potenziali sfide aziendali, tecniche e complesse. Per aiutarti a superare queste sfide, Cisco ti offre diverse opzioni per assisterti nel tuo percorso. È importante rivedere le informazioni in Chiamate cloud aziendali - Migrazione delle chiamate e comprendere ogni opzione e come ciascuna di esse può aiutarti con la tua migrazione.
-
Strumenti di migrazione Webex: strumenti self-service gratuiti integrati in Control Hub per semplificare la transizione a Webex Calling
-
Fornitori di migrazione certificati: Fornitori di software e strumenti convalidati da Cisco che hanno sviluppato soluzioni di migrazione per aiutare i partner e i clienti Webex con migrazioni complesse e di grandi dimensioni. Queste soluzioni possono aiutare a semplificare, gestire e accelerare la transizione a Webex Calling
-
Assistenza all'installazione di Webex: un servizio di migrazione gestito da Cisco che guida clienti e partner attraverso la distribuzione e la configurazione di Webex Calling, necessarie per migrare correttamente gli utenti e i servizi di Unified CM a Webex Calling.
Panoramica
Con la crescita dei servizi di collaborazione forniti tramite cloud, sempre più clienti desiderano spostare i propri carichi di lavoro di collaborazione esistenti sul cloud, viste le promesse di riduzione del costo totale di proprietà, gestione semplificata, distribuzione continua delle funzionalità, maggiore scalabilità e affidabilità superiore insite nei servizi basati su cloud. Quando i clienti desiderano passare dai servizi di collaborazione on-premise a quelli cloud, è importante che comprendano cosa comporta questa transizione e quali sono i passaggi necessari per realizzarla.
Lo scopo di questo documento è fornire indicazioni di distribuzione per i clienti che desiderano specificamente passare da Unified CM in sede a Webex Calling nel cloud. Questa guida alla distribuzione presuppone che il lettore abbia una conoscenza di base della transizione delle chiamate tra Unified CM e Webex Calling, comprese le modifiche apportate durante questa transizione e le differenze nello spostamento del carico di lavoro delle chiamate da locale al cloud. Prima di procedere, assicurati di aver esaminato e di avere familiarità con le informazioni disponibili nella Mappa di transizione. Questo documento sulla mappa di transizione fornisce informazioni sui cambiamenti e sulle differenze di questa transizione.
Come mostrato nella Figura Architettura di collaborazione on-premise: controllo delle chiamate e accesso remoto, una tipica distribuzione in sede include diversi componenti dell'infrastruttura di collaborazione sulla rete, una piattaforma di controllo delle chiamate, una piattaforma edge, endpoint hardware e software e, in alcuni casi, anche piattaforme di conferenza e pianificazione. Nell'architettura Cisco questo includerebbe Unified CM per il controllo delle chiamate, Expressway per l'accesso remoto e servizi edge business-to-business (B2B), Cisco Meeting Server / Cisco Meeting Management per conferenze in sede, Unity Connection per la messaggistica vocale e endpoint basati su IP hardware (telefoni IP Cisco, sistemi video Cisco Desk and Room) e software (Cisco Jabber) rivolti all'utente. Questi componenti potrebbero variare leggermente in alcuni ambienti, ma questo è il punto di partenza per la transizione descritta nel resto del documento.
L'architettura mostrata nella Figura Architettura di collaborazione on-premise: il controllo delle chiamate e l'accesso remoto si basano sull'architettura preferita (PA) per le distribuzioni Cisco Collaboration Enterprise On-Premises. Per ulteriori informazioni su Enterprise On-premise, vedere Architetture preferite per la collaborazione Cisco.
Prima: La tabella dei componenti dell'infrastruttura di chiamata in sede elenca gli elementi chiave dell'architettura in sede prima della transizione a Webex Calling nel cloud.
| Prodotto | Descrizione |
|---|---|
| Unified CM | Controllo delle chiamate in sede che fornisce servizi di registrazione dei dispositivi e di instradamento delle chiamate |
| Cisco Expressway-C/E | Infrastruttura edge che fornisce funzionalità di accesso mobile e remoto (MRA) e business-to-business (B2B) consentendo agli endpoint remoti di connettersi in modo sicuro dall'esterno dell'organizzazione. Expressway viene distribuito in coppia per fornire attraversamento firewall per endpoint esterni. |
| Cisco Meeting Server (CMS), Cisco Meeting Management (CMM) e Cisco Telepresence Management Suite (TMS) | Infrastruttura per conferenze vocali, video e web in sede che offre riunioni multipunto, gestione delle riunioni e funzionalità di pianificazione. [Optional] |
| Cisco Unity Connection | Piattaforma di messaggistica vocale on-premise che fornisce funzionalità di posta vocale e messaggistica unificata. [Optional] |
| Cisco Desk, Cisco Room, Cisco Board, telefoni IP Cisco e Cisco Jabber | Dispositivi basati su IP registrati su Unified CM e che forniscono funzionalità di chiamata vocale e video |
Come illustrato nella Figura Decisione di transizione: chiamate in sede a Webex Calling, i clienti che dispongono di un controllo delle chiamate in sede con Unified CM e endpoint IP desk e video hanno la possibilità di passare dall'architettura a un'architettura cloud Webex Calling.
La decisione deve essere presa in base alle esigenze di funzionalità del cliente. I clienti che hanno i seguenti requisiti devono riflettere attentamente prima di prendere questa decisione e potrebbero decidere di mantenere il controllo delle chiamate in sede:
- Modelli di telefono non supportati da Webex Calling
- Integrazioni complesse o numerose con altri sistemi o soluzioni locali, in particolare quando replicare queste integrazioni con Webex Calling è difficile o non sono disponibili soluzioni alternative equivalenti
- Piano di selezione complesso, classi di servizio altamente granulari o entrambi
- Accesso a Internet restrittivo, limitato o inaffidabile
- Rigorose politiche sulla privacy e sulla proprietà dei dati
- Requisiti di conformità per la registrazione e l'archiviazione di supporti in sede o all'interno del paese
- Integrazioni di terze parti senza un'integrazione Webex Calling alternativa valida
- Integrazioni del contact center in cui l'interfaccia del contact center non è ancora stata spostata nel cloud.
Questo documento è rivolto ai clienti con distribuzioni di controllo delle chiamate Unified CM che desiderano comprendere i passaggi generali, le considerazioni e i requisiti per abilitare la distribuzione di Webex Calling, come illustrato nella sezione successiva.
Componenti principali
L'architettura di destinazione per questa migrazione include diversi nuovi componenti. Ciò include il servizio Webex Calling per le chiamate basate su cloud, l'app Webex, Cisco Directory Connector per l'integrazione delle identità e Local Gateway (LGW) per l'accesso PSTN, nonché l'integrazione delle chiamate on-premise sul cloud. Ulteriori opzioni per l'accesso alla PSTN sono i piani di chiamata Cisco o Cloud Connected PSTN (CCP) forniti da un partner Cloud Connect per Webex Calling.
Come mostrato nella Figura Dopo: Architettura di Webex Calling, i nuovi componenti (Webex Calling, connettore di directory, gateway locale e gateway di sopravvivenza) vengono aggiunti alla distribuzione locale esistente.
Dopo: La tabella dei componenti dell'infrastruttura per le chiamate cloud elenca i nuovi elementi dell'architettura dopo la transizione a Webex.
| Prodotto | Descrizione |
|---|---|
| Webex Calling | Servizio di chiamata basato su cloud fornito dalla piattaforma Webex e che fornisce la registrazione degli endpoint e l'instradamento delle chiamate |
| Cisco Directory Connector | Applicazione Windows in esecuzione su un computer con dominio Windows che fornisce la sincronizzazione delle identità tra Active Directory locale aziendale e l'archivio identità dell'organizzazione Webex. Per i clienti che passano da Active Directory locale a Entra ID, l'integrazione dell'identità con Webex anziché Cisco Directory Connector utilizza l'app Entra ID Wizard. |
| Gateway locale | Un gateway locale funge da ponte tra la rete di comunicazioni unificate locale del cliente e il cloud Webex Calling. Può essere distribuito in locale oppure ospitato da un partner, offrendo accesso PSTN per endpoint registrati nel cloud e integrazione delle chiamate tra endpoint registrati in Unified CM e endpoint registrati nel cloud. Router per servizi integrati Cisco IOS-XE (serie ISR 1100 e 4000), Cisco Catalyst 8200/8300 La serie, il software Cisco Catalyst 8000V Edge e vari Session Border Controller (SBC) di terze parti certificati possono essere utilizzati come LGW per un approccio di migrazione graduale. |
| Gateway survivability | Survivability Gateway (SGW) è un gateway di rete locale basato su IOS-XE che fornisce servizi di chiamata di fallback agli endpoint Webex Calling in loco durante le interruzioni di rete. |
| Piano di chiamata Cisco, Cloud Connect per Webex Calling | Cisco Calling Plan e Cloud Connect per Webex Calling sono opzioni basate su cloud per l'accesso PSTN per gli endpoint Webex Calling. L'accesso PSTN è facilitato da un provider PSTN cloud e non richiede apparecchiature in sede. |
| App Webex | Applicazione client in esecuzione su sistema operativo desktop (Windows, Mac) o mobile (Android, iOS) e registrata direttamente sulla piattaforma Webex Calling per la funzionalità di chiamata. |
Panoramica del processo PPDIO
Il processo PPDIO sta per Preparare, Pianificare, Progettare, Implementare e Ottimizzare. Si tratta di una metodologia Cisco strutturata che guida i progetti dalla valutazione iniziale fino al miglioramento continuo, garantendo implementazioni o migrazioni efficienti e di successo.
Descrizione generale del PPDIO
-
Preparare: Valutare l'ambiente attuale, raccogliere i requisiti e allineare le parti interessate per stabilire una base solida.
-
Piano: Sviluppare piani di progetto dettagliati, comprensivi di tempistiche, risorse e strategie di mitigazione dei rischi.
-
Progetto: Progettare la soluzione target su misura per le esigenze aziendali e tecniche.
-
Attrezzo: Eseguire la distribuzione o la migrazione in base alla progettazione, convalidando funzionalità e prestazioni.
-
Ottimizzare: Migliorare costantemente la soluzione dopo l'implementazione monitorando le prestazioni, perfezionando le configurazioni e sfruttando gli strumenti di automazione e integrazione.
Utilizzo di PPDIO per progetti di migrazione da Unified CM a Webex Calling
Durante la transizione da Unified CM a Webex Calling, il processo PPDIO fornisce una roadmap chiara per garantire una transizione fluida ed efficiente:
Prepara
-
Valutare l'ambiente Unified CM esistente e la prontezza alla migrazione
-
Raccogli dati dettagliati su utenti, dispositivi, rete e dipendenze
-
Raccogliere i dettagli sulla posizione, tra cui l'indirizzo di risposta alle emergenze, il numero di utenti, l'accesso a Internet, l'accesso PSTN
-
Identificare i rischi e definire l'ambito del progetto per allineare tutte le parti interessate.
Pianifica
-
Creare un piano di migrazione completo con pianificazioni batch, assegnazioni di risorse e tempistiche
-
Definire attività quali aggiornamenti del firmware del dispositivo, provisioning delle licenze e onboarding degli utenti
-
Coordinare le finestre di migrazione con Cisco e i partner per ridurre al minimo le interruzioni.
Progetta
-
Mappare le attuali configurazioni Unified CM, i piani di chiamata e i profili utente agli equivalenti di Webex Calling
-
Progettare l'ambiente Webex Calling, inclusa la strategia PSTN (intermedia e finale), le posizioni, i ruoli utente e i punti di integrazione come il gateway locale (CUBE) e la sincronizzazione delle directory
-
Pianificare scenari di coesistenza in cui Unified CM e Webex Calling operano simultaneamente durante la migrazione.
Implementa
-
Utilizzare gli strumenti di migrazione di Control Hub insieme a strumenti di terze parti per eseguire modifiche alla modalità firmware del dispositivo, configurazione delle funzionalità e migrazioni degli utenti
-
Utilizzare operazioni in blocco e provisioning tramite API Webex per semplificare migrazioni e configurazioni su larga scala
-
Eseguire il provisioning delle licenze, la registrazione dei dispositivi e gli aggiornamenti della configurazione
-
Convalidare il successo della migrazione tramite test e verifica operativa.
Ottimizza
-
Monitorare costantemente le prestazioni e l'esperienza utente di Webex Calling
-
Affinare le configurazioni e i flussi di lavoro in base ai dati operativi e al feedback
-
Sfrutta le capacità di automazione e integrazione per migliorare l'efficienza e la scalabilità
-
Dismettere i componenti legacy di Unified CM secondo necessità e fornire supporto continuo per le operazioni del secondo giorno.
Questo approccio PPDIO migliorato garantisce una migrazione controllata, trasparente ed efficiente da Unified CM a Webex Calling, sfruttando gli strumenti, le API e l'ecosistema dei partner di Cisco per mantenere la continuità aziendale e migliorare le capacità di collaborazione.
Cicli di feedback PPDIO
La panoramica di alto livello illustrata nella Figura Iterazioni durante l'esecuzione di PPDIO illustra un singolo ciclo di feedback dalla fase di ottimizzazione alla fase di preparazione. Ciò significa che, dopo l'implementazione iniziale, esiste una continua opportunità di miglioramento continuo. Ogni ciclo di ottimizzazione può identificare nuovi requisiti o aree di miglioramento, che possono essere affrontati attraverso progetti o iniziative successivi. Questi singoli progetti, a loro volta, seguono ciascuno il ciclo di vita PPDIO (Preparazione, Pianificazione, Progettazione, Implementazione, Ottimizzazione) stabilito. Questo approccio iterativo garantisce che il sistema rimanga allineato con gli obiettivi aziendali in continua evoluzione e con i progressi tecnologici, promuovendo una cultura di continuo perfezionamento e adattabilità.
Durante l'esecuzione del processo PPDIO, è comune che i risultati delle fasi successive richiedano di rivedere e potenzialmente rivedere le decisioni prese nelle fasi precedenti. Ad esempio, i problemi riscontrati durante la fase di implementazione, come l'identificazione di ambiguità di progettazione o dettagli mancanti, potrebbero rivelare che determinati aspetti non sono stati affrontati appieno durante la fase di progettazione. In questi casi, diventa necessario tornare alla fase precedente pertinente per risolvere questi problemi prima di procedere. Questo meccanismo di feedback iterativo, come illustrato nella Figura Processo PPDIO assistito da Unified CM garantisce che la soluzione sia completamente convalidata e perfezionata, contribuendo in definitiva a una distribuzione più solida ed efficace.
Quando si esegue una transizione da Unified CM a Webex Calling, ogni fase del processo PPDIO può trarre notevoli vantaggi dalle informazioni raccolte dall'ambiente Unified CM esistente. Ad esempio, è possibile estrarre inventari completi di utenti, numeri di telefono, funzioni di chiamata e componenti del piano di chiamata dalla configurazione Unified CM corrente. Questi dati integrano le informazioni fornite direttamente dalle parti interessate e contribuiscono a semplificare le attività di pianificazione e progettazione. L'utilizzo di strumenti appropriati per automatizzare l'estrazione e l'analisi dei dati non solo aumenta la precisione, ma accelera anche l'intero processo. Utilizzando le informazioni ottenute dall'implementazione esistente, la transizione a Webex Calling può essere eseguita in modo più efficiente rispetto a un'implementazione greenfield tradizionale, pur continuando a rispettare la metodologia PPDIO strutturata. Questo processo è illustrato nella Figura Processo PPDIO assistito da Unified CM.
Approccio alla migrazione
Quando pianifichi la transizione da Unified CM on-premise a Webex Calling, devi stabilire come affronterai questo percorso. Per prima cosa dovrai decidere se la migrazione sarà un flash-cut (tutto in una volta) o un approccio graduale (migrazione di gruppi di users/devices per un periodo prolungato).
Eseguendo una migrazione flash-cut tutti gli utenti e i dispositivi vengono spostati più velocemente. Con questo metodo, tutti gli utenti e i dispositivi verranno spostati contemporaneamente da Unified CM locale a Webex Calling. In sostanza, si tratta di un'unica finestra di migrazione per tutti gli utenti e i dispositivi. Una volta completata questa migrazione, tutti gli utenti e i dispositivi saranno sulla piattaforma Webex Calling e l'intera infrastruttura Unified CM potrà essere dismessa. Tuttavia, molte organizzazioni non possono utilizzare questo approccio a causa della scala e delle dimensioni della loro distribuzione delle chiamate.
Il secondo approccio è una migrazione graduale. La maggior parte delle organizzazioni utilizzerà questo approccio poiché garantisce un migliore controllo, gestione e scalabilità durante la migrazione. Inoltre, è più adatto per distribuzioni UC più grandi and/or distribuzioni in più regioni. Pertanto, il presente documento si concentra sull'approccio graduale con due fasi nella transizione.
Come mostrato nella figura sottostante Transizione di chiamata in fasi: Ibrido e cloud, la prima fase di transizione (Fase 1) si traduce in una distribuzione di coesistenza con ambienti di chiamata duali. In questa fase, alcuni utenti, dispositivi e client software vengono trasferiti a Webex Calling, mentre altri utilizzano ancora il controllo delle chiamate Unified CM locale. La fase di transizione finale (Fase 2) si traduce in un ambiente di chiamata basato esclusivamente sul cloud, in cui tutti gli utenti, i dispositivi e i client software sono stati completamente trasferiti alla piattaforma Webex Calling.
Il tempo necessario a un'organizzazione per passare completamente alle chiamate cloud varia in base all'implementazione attuale. In alcuni casi, un'organizzazione può effettuare la transizione iniziale e rimanere nella fase di controllo delle chiamate doppie di coesistenza (Fase 1) per un periodo prolungato (mesi o addirittura anni), mentre in altri casi, un'organizzazione può passare completamente a Webex Calling (Fase 2) in un periodo molto breve (settimane o mesi). Il presente documento intende coprire entrambe le fasi (Fase 1 - coesistenza e Fase 2 - transizione completa).
È possibile che alcune organizzazioni mantengano indefinitamente un'implementazione del controllo delle chiamate duali senza pianificare una transizione completa alle chiamate cloud.
La seconda considerazione riguarda il modo in cui si intende trasferire utenti, dispositivi e soft client dal controllo delle chiamate on-premise al controllo delle chiamate cloud. L'approccio consigliato è una transizione in 3 fasi. La figura Transizione trifase consigliata di seguito suddivide questo approccio nelle 3 fasi.
Pre-migrazione: Questa fase si concentra sulla preparazione degli ambienti Webex e Unified CM per la migrazione. Non si tratta di richiamare pianificazioni o configurazioni specifiche, ma di concentrarsi sul completamento di attività che possono essere eseguite subito e prima dell'inizio di qualsiasi progetto di migrazione a Webex Calling. L'obiettivo è quello di gettare le basi affinché i due ambienti si preparino alla migrazione.
Preparazione alla migrazione: Questa è la fase in cui iniziano gli sforzi per preparare la migrazione a Webex Calling. In questo caso, i requisiti aziendali e tecnici devono essere rivisti e aggiornati. Non limitarti a sollevare e spostare ciò che è attualmente distribuito con Unified CM, ma ridefinisci invece i requisiti aziendali e tecnici di cui la tua azienda ha bisogno oggi e in futuro sfruttando la potenza di Webex Calling. Inoltre, questa è la fase in cui completerai la progettazione, la pianificazione della configurazione e la migrazione planning/schedule.
Migrazione (implementazione e dismissione): Questa fase è quella in cui avviene la migrazione effettiva di utenti, dispositivi, numeri di telefono e soft client. Come discusso sopra, questa fase può essere completata per tutti in una volta (flash-cut) o in più finestre di modifica (phased-cut). I piani di adozione, la formazione e le comunicazioni degli utenti finali sono fondamentali, affinché siano a conoscenza dei cambiamenti, sappiano come utilizzare la nuova piattaforma di chiamata e quando avverrà il cambiamento. L'ultimo passaggio consiste nello smantellare tutta l'infrastruttura UC locale che non viene più utilizzata.
La fase di pre-migrazione prevede attività (obbligatorie, consigliate e facoltative) su cui è possibile iniziare a lavorare immediatamente. Si consiglia di completarli il prima possibile e preferibilmente prima dell'inizio del progetto. Alcune attività potrebbero richiedere più tempo per essere completate, pertanto avviarle prima contribuirà a semplificare l'effettivo progetto di migrazione.
La figura Attività pre-migrazione sottostante evidenzia cinque categorie specifiche di attività correlate a una migrazione di Webex Calling.
Prepara
Requisiti aziendali e tecnici
Quando si pianifica una migrazione da a , è fondamentale raccogliere attentamente sia i requisiti tecnici che quelli aziendali durante la fase di pianificazione. Questo passaggio garantisce che la migrazione sia in linea con gli obiettivi operativi e le capacità tecniche della tua organizzazione, riducendo al minimo i rischi e le interruzioni.
Perché è importante raccogliere i requisiti:
-
Allinea gli obiettivi aziendali: Comprendere le esigenze aziendali aiuta a personalizzare la migrazione per supportare flussi di lavoro chiave, esperienza utente e piani di crescita.
-
Garantisce la compatibilità tecnica: Identificare tempestivamente i requisiti tecnici previene problemi di integrazione con l'infrastruttura, la rete e gli endpoint esistenti.
-
Facilita la pianificazione delle risorse: Requisiti chiari aiutano a stimare con precisione tempi, costi e risorse necessarie.
-
Attenua i rischi: Il rilevamento tempestivo di potenziali problemi consente di adottare soluzioni proattive, riducendo i tempi di inattività e le interruzioni del servizio.
Requisiti aziendali
I requisiti aziendali tipici includono:
-
Numero di utenti e posizioni da migrare
-
Funzionalità e servizi desiderati (ad esempio, instradamento delle chiamate, segreteria telefonica, conferenze, risponditori automatici, code di chiamata)
-
Politiche di conformità e sicurezza
-
Vincoli di bilancio e aspettative di costo
-
Esigenze di formazione e supporto degli utenti
-
Considerazioni sulla cronologia della migrazione e sulla continuità aziendale.
Raccogliere le funzionalità e i servizi desiderati è un passaggio fondamentale per garantire che il nuovo sistema soddisfi le esigenze aziendali. Quando si raccolgono questi requisiti, è importante non solo considerare ciò che è attualmente configurato, ma anche cercare di raccogliere i requisiti effettivi delle entità aziendali che utilizzeranno il sistema. In caso contrario, sussiste il rischio che il piano si basi su ipotesi non correnti. Assicurati di valutare le funzionalità aggiuntive o migliorate disponibili in che potrebbero non essere presenti in , come le chiamate basate su cloud, le code di chiamata avanzate e . Ciò aiuta a sfruttare appieno i vantaggi della piattaforma cloud.
Quando si valuta la configurazione corrente in , è importante riconoscere che non tutte le impostazioni esistenti potrebbero rimanere necessarie a causa dell'evoluzione dei requisiti durante il ciclo di vita del sistema. L'attenzione dovrebbe essere rivolta all'identificazione e al mantenimento solo delle configurazioni che sono in linea con le esigenze attuali e future dell'implementazione.
Concentrati di più su ciò di cui hai bisogno piuttosto che su ciò che hai.
Le policy di conformità e sicurezza sono considerazioni fondamentali durante la migrazione da Webex Calling a Webex Calling per garantire che il nuovo sistema di comunicazione basato su cloud aderisca agli standard legali, normativi e organizzativi.
-
Conformità normativa: Le organizzazioni devono verificare che siano conformi alle normative specifiche del settore, come GDPR, HIPAA o SOX, che affrontino i requisiti di riservatezza, conservazione e gestione dei dati, nonché i mandati specifici per paese relativi alla residenza dei dati, al bypass dei pedaggi e alla località dei media.
-
Sicurezza dei dati: Garantire che i dati vocali e di segnalazione siano crittografati sia in transito che a riposo per proteggerli da intercettazioni o accessi non autorizzati.
-
Controlli di accesso: Definire e applicare l'autenticazione utente, l'autorizzazione e l'accesso basato sui ruoli per impedire l'uso non autorizzato delle risorse di comunicazione.
-
Audit e monitoraggio: Implementazione di funzionalità di registrazione e monitoraggio per tracciare l'accesso e l'utilizzo per audit di conformità e indagini sugli incidenti di sicurezza.
-
Allineamento delle politiche: Allineare la migrazione alle policy di sicurezza aziendali esistenti, tra cui la sicurezza degli endpoint, la segmentazione della rete e i piani di risposta agli incidenti.
-
Garanzia di sicurezza del fornitore: Valutazione delle certificazioni di sicurezza e delle attestazioni di conformità di Cisco per garantirne l'affidabilità.
Affrontare queste policy di conformità e sicurezza durante la fase di pianificazione aiuta a mitigare i rischi, evitare sanzioni legali e mantenere l'integrità e la riservatezza delle comunicazioni durante e dopo la migrazione.
La formazione e il supporto degli utenti sono componenti essenziali durante la migrazione da a per garantire una transizione e un'adozione agevoli da parte degli utenti. Le considerazioni chiave includono:
-
Programmi di formazione: Sviluppare sessioni di formazione personalizzate per diversi gruppi di utenti (utenti finali, amministratori, personale dell'help desk) per familiarizzarli con le funzionalità, le interfacce utente e i nuovi flussi di lavoro.
-
Documentazione: Fornire guide utente chiare e accessibili, FAQ e materiali di riferimento rapido, tra cui risorse Novità e differenze e guide pratiche passo passo Prima e dopo (in formato video o guida rapida), per supportare gli utenti nell'adattamento all'esperienza aggiornata dopo la migrazione.
-
Gestione del cambiamento: Comunicare i cambiamenti in modo proattivo per gestire le aspettative degli utenti e ridurre la resistenza.
-
Struttura di supporto: Istituire un team di supporto dedicato o un percorso di escalation per risolvere tempestivamente i problemi degli utenti durante e dopo la migrazione.
-
Formazione continua: Pianificare aggiornamenti continui della formazione man mano che vengono rilasciate nuove funzionalità o aggiornamenti in .
-
Meccanismi di feedback: Implementare canali che consentano agli utenti di segnalare problemi e fornire feedback per migliorare i processi di formazione e supporto.
Affrontare queste esigenze di formazione e supporto durante la fase di pianificazione aiuta a ridurre al minimo le interruzioni, aumenta la fiducia degli utenti e massimizza i vantaggi della migrazione a .
Requisiti tecnici
Per una migrazione di successo da a è necessario raccogliere e documentare diversi requisiti tecnici chiave, tra cui i dettagli per:
-
Prontezza della rete e capacità di larghezza di banda
Una valutazione completa della rete è fondamentale per garantire che l'infrastruttura esistente possa supportare il nuovo ambiente Webex Calling. Include:
-
Analisi della larghezza di banda: Valutazione dell'utilizzo attuale e previsto della larghezza di banda per gestire il traffico voce, video e dati senza congestione.
-
Qualità del servizio (QoS): Implementazione di policy QoS per dare priorità al traffico vocale e ridurre al minimo latenza, jitter e perdita di pacchetti.
-
Connettività WAN e Internet: Verifica che i collegamenti WAN e le connessioni Internet soddisfino i requisiti per le chiamate basate su cloud, comprese le capacità di ridondanza e failover.
-
Configurazione del firewall e NAT: Assicurarsi che le impostazioni del firewall e del NAT consentano la segnalazione e il traffico multimediale richiesti per .
-
-
Integrazione con il sistema esistente
L'integrazione perfetta con i sistemi aziendali esistenti è essenziale per l'esperienza utente e la continuità del flusso di lavoro:
-
Servizi di directory: Valutazione dell'integrazione con una directory aziendale per il provisioning e l'autenticazione automatizzati degli utenti.
-
CRM e applicazioni aziendali: Identificazione dei punti di integrazione con i sistemi di gestione delle relazioni con i clienti e altre applicazioni aziendali critiche.
-
Interoperabilità PBX legacy: Pianificazione di strategie di coesistenza o di migrazione graduale se durante la transizione verranno mantenuti sistemi di telefonia legacy.
-
-
Compatibilità e provisioning degli endpoint
È necessario valutare la compatibilità di tutti gli endpoint, inclusi telefoni fissi, softphone e dispositivi mobili:
-
Supporto dispositivi: Confermare che i telefoni e i dispositivi IP esistenti siano supportati o identificare le sostituzioni necessarie.
-
Processi di provisioning: Definizione di metodi di provisioning automatizzati o semplificati per un onboarding efficiente degli endpoint.
-
Aggiornamenti firmware e software: Pianificazione degli aggiornamenti necessari per garantire interoperabilità e sicurezza.
-
-
Configurazioni di sicurezza e standard di crittografia
La sicurezza è fondamentale nelle comunicazioni cloud:
-
Crittografia: Applicazione della crittografia end-to-end per i flussi di segnalazione e multimediali, in linea con le migliori pratiche di sicurezza Cisco.
-
Autenticazione e controllo degli accessi: Implementazione di meccanismi di autenticazione sicuri (come SSO, autenticazione a più fattori) e controlli granulari degli accessi degli utenti.
-
Conformità: Garantire che la soluzione soddisfi gli standard normativi e di conformità del settore pertinenti (ad esempio, GDPR, HIPAA).
-
Monitoraggio della sicurezza: Integrazione con strumenti SIEM e impostazione di avvisi per potenziali incidenti di sicurezza.
-
| Requisito | Considerazioni chiave |
|---|---|
| Prontezza della rete e larghezza di banda | Larghezza di banda, QoS, WAN/Internet, Firewall/NAT |
| Integrazione con i sistemi esistenti | Directory, CRM, PBX, Email/Calendar |
| Compatibilità e provisioning degli endpoint | Supporto del dispositivo, provisioning, aggiornamenti del firmware |
| Configurazioni di sicurezza e crittografia | Crittografia, autenticazione, conformità, monitoraggio della sicurezza |
| Formazione degli utenti e gestione del cambiamento | Programmi di formazione, documentazione, comunicazione del cambiamento |
| Portabilità del numero e piano di selezione | Numero migration/porting, traduzione del piano di selezione |
| Integrazioni di terze parti | Cercapersone, contact center, fax, dispositivi analogici |
Prontezza e requisiti della rete
La prontezza della rete è fondamentale per una migrazione di successo verso qualsiasi soluzione di chiamata basata su cloud come . Una pianificazione inadeguata della rete può causare un peggioramento della qualità delle chiamate, chiamate interrotte e utenti insoddisfatti. I clienti devono effettuare una valutazione della rete prima di migrare a . Si consiglia di confermare la disponibilità della larghezza di banda di rete per il volume di chiamate previsto, di garantire che siano soddisfatti i requisiti di qualità del servizio (QoS) e di comprendere le varie porte che devono essere aperte nei firewall perimetrali.
Una connettività di rete affidabile con una qualità del servizio sufficiente (larghezza di banda, perdita di pacchetti, RTT) è un requisito di base per garantire la migliore esperienza utente possibile end-to-end per tutti gli endpoint, i client e le applicazioni abilitati per voce e video che utilizzano .
I clienti e i partner hanno accesso a opzioni di connettività che vanno oltre la rete Internet OTT (Over-the-top) e che possono ottimizzare la connessione, incluso Webex Edge Connect. Per ulteriori informazioni sui dettagli di progettazione di Webex Edge Connect, vedere Architettura preferita Cisco per Webex Edge Connect per Webex Meetings, chiamate multi-tenant e istanze dedicate.
I clienti possono utilizzare CScan per la valutazione della rete, che fornisce informazioni sulla qualità della rete del cliente, sul numero di chiamate che possono essere stabilite, sulla latenza e così via. Per ulteriori informazioni sullo strumento CScan, vedere Utilizzare CScan per testare la qualità della rete Webex Calling.
Per garantire che la rete sia pronta per la migrazione a , tenere presente la seguente checklist:
-
Pianificazione della larghezza di banda
Calcola le chiamate simultanee per sito per assicurarti di avere sufficiente larghezza di banda in upstream e downstream e di includere margine per altro traffico critico per l'azienda e crescita futura.
La tabella Calcoli della larghezza di banda del tipo di chiamata Webex Calling mostra i tipi di chiamata disponibili con una distribuzione insieme al codec e alla larghezza di banda massima richiesta per ciascun tipo di chiamata. Come mostrato nella tabella Calcoli della larghezza di banda del tipo di chiamata Webex Calling, la larghezza di banda della chiamata audio richiesta per ciascun tipo di chiamata può essere calcolata utilizzando la seguente formula generale:
Numero di chiamate simultanee previste * Larghezza di banda per chiamata in base al codec = Capacità di trasmissione della rete richiesta.
Tabella 2. Calcoli della larghezza di banda del tipo di chiamata Webex Calling Tipi di chiamata Codec - larghezza di banda Calcoli della larghezza di banda / Telefono da scrivania -> OPUS - 70 kbps Numero di chiamate contemporanee * 70 kbps = Capacità di trasmissione della rete richiesta / Telefono da scrivania -> Telefono da scrivania OPUS – 70 kbps Numero di chiamate contemporanee * 70 kbps = Capacità di trasmissione della rete richiesta / Telefono da scrivania -> PSTN tramite LGW G.711 – 80 kbps Numero di chiamate contemporanee * 80 kbps = Capacità di trasmissione della rete richiesta / Telefono da scrivania -> PSTN tramite Cloud PSTN (ad esempio piano tariffario Cisco) G.711 – 80 kbps Numero di chiamate contemporanee * 80 kbps = Capacità di trasmissione della rete richiesta / Telefono da scrivania -> Impresa tramite LGW G.722 – 80 kbps Numero di chiamate contemporanee * 80 kbps = Capacità di trasmissione della rete richiesta / Telefono da scrivania -> segreteria telefonica OPUS – 70 kbps Numero di chiamate contemporanee * 70 kbps = Capacità di trasmissione della rete richiesta Sommando la capacità di rete richiesta contemporaneamente per tipo di chiamata, è possibile determinare il fabbisogno di larghezza di banda potenziale totale per un sito specifico.
Tutti i segmenti di chiamata sono sempre ancorati agli SBC di accesso. Per determinare la larghezza di banda Internet richiesta per una determinata posizione, non è necessario considerare solo le chiamate tra sedi diverse, ma anche le chiamate all'interno della stessa sede e le chiamate da e verso un gateway locale in quella posizione. Ad esempio, una chiamata intra-sito tra due telefoni MPP richiederebbe fino a 2 x 70 kbps full duplex sull'accesso Internet della sede.
La tabella Esempi di calcolo della larghezza di banda di Webex Calling mostra un esempio di un esercizio completo di calcolo della larghezza di banda, presupponendo che tutti i dispositivi si trovino nello stesso sito.
Tabella 2. Esempi di calcolo della larghezza di banda di Webex Calling Tipi di chiamata Numero di chiamate contemporanee Larghezza di banda totale App Webex / Telefono fisso → App Webex 15 2 * 15 * 70 kbps = 2.100 kbps App Webex / Telefono da tavolo → Telefono da tavolo 15 2 * 15 * 70 kbps = 2.100 kbps App Webex / Telefono fisso → PSTN tramite LGW 50 2 * 50 * 80 kbps = 8.000 kbps App Webex / Telefono fisso → PSTN tramite Cloud Connect per Webex Calling 0 0 * 80 Kbps App Webex / Telefono fisso → Azienda tramite LGW 15 2 * 15 * 80 kbps = 2.400 kbps App Webex / Telefono fisso → Segreteria telefonica Webex Calling 5 5 * 70 kbps = 350 kbps Chiamate totali / Larghezza di banda 100 chiamate 14.950 kbps / 14,95 Mbps -
Tutti i valori di larghezza di banda nelle tabelle precedenti si riferiscono alla larghezza di banda IP. La larghezza di banda del collegamento è maggiore a seconda degli incapsulamenti WAN.
-
La larghezza di banda indicata nelle tabelle precedenti è per le chiamate audio. Per la larghezza di banda delle videochiamate, l'app Webex e l'MPP 8845/65 I telefoni supportano video H.264 con risoluzione massima di 720p e una larghezza di banda massima di 1.500 kbps per chiamata. Tuttavia, la quantità di larghezza di banda consumata in qualsiasi momento durante la chiamata varierà in base alla velocità in bit variabile insita nelle comunicazioni video.
-
-
Qualità del servizio (QoS)
Implementa policy QoS nel tuo ambiente on-premise per dare priorità al traffico in tempo reale e garantire che la QoS venga mantenuta su switch, router e firewall.
-
Obiettivi di latenza, jitter e perdita di pacchetti
Per una qualità vocale ottimale durante le chiamate OTT (Over-the-Top) e su Internet, si consigliano le seguenti soglie:
-
Latenza: meno di 100 ms unidirezionale
-
Jitter - inferiore a 10 ms
-
Perdita di pacchetti: 0,5% o meno.
-
-
Firewall e NAT
Assicurarsi che il firewall sia configurato per consentire il traffico come elencato nell'articolo disponibile in Informazioni di riferimento della porta per Webex Calling. Inoltre, consentire l'accesso ai domini e agli intervalli IP elencati nella stessa guida ed evitare SIP ALG poiché interferisce con la segnalazione SIP. Dovrebbe essere evitato il traffico mediatico tramite proxy.
-
DNS e NTP
Assicurare una corretta risoluzione DNS dei domini e server NTP affidabili per sincronizzare gli orologi dei dispositivi per la verifica e la registrazione dei certificati TLS.
-
Pianificazione del failover
Prendi in considerazione le connessioni dati del provider esistenti (MPLS, SD-WAN e così via) e pianifica in generale l'accesso diretto a Internet in ogni posizione all'interno della tua distribuzione. Pianificare collegamenti Internet ridondanti laddove è richiesta un'elevata disponibilità. Poiché utilizzerai servizi basati sul cloud, un requisito di base è una connettività Internet affidabile con larghezza di banda sufficiente. Dovresti riconsiderare questa transizione se le connessioni Internet delle sedi della tua organizzazione non sono generalmente affidabili, con bassa latenza e un throughput upstream e downstream adeguato.
-
Sopravvivenza del sito
La sopravvivenza del sito garantisce che la tua attività sia sempre raggiungibile, anche se la connessione di rete si interrompe. Site Survivability utilizza un gateway nella rete locale per fornire un servizio di chiamata di fallback agli endpoint in loco nei casi in cui la connessione di rete si interrompe. Valutare la sopravvivenza del sito con un Survivability Gateway (SGW) locale se i requisiti aziendali richiedono chiamate continue in caso di interruzione della rete. Per ulteriori informazioni sul controllo di sopravvivenza del sito, vedere Sopravvivenza del sito per Webex Calling.
Configurare UC connesso al cloud
Cloud Connected UC (CCUC) è una soluzione di gestione e analisi basata su cloud, progettata per fornire visibilità, amministrazione e approfondimenti centralizzati per le distribuzioni sia in locale (ad esempio Unified CM) che nel cloud (). Funge da ponte tra gli ambienti tradizionali on-premise e i servizi cloud di Cisco, supportando le organizzazioni durante tutto il percorso di migrazione da a .
Durante la transizione a , CCUC svolge un ruolo fondamentale nella semplificazione del processo di migrazione, facilitando la raccolta di dati completi dall'attuale distribuzione di Unified Communications. CCUC fornisce assistenza nelle principali attività di transizione, quali la migrazione di dispositivi, funzionalità e contatti degli utenti, nonché l'automazione degli aggiornamenti del firmware per i telefoni IP supportati. Grazie alla visibilità e alla gestione centralizzate, CCUC contribuisce a garantire un'esperienza di migrazione più fluida ed efficiente.
Cisco consiglia vivamente di implementare e rendere operativo CCUC nelle prime fasi del progetto di transizione, idealmente prima o durante la fase di preparazione. Ciò fornirà le informazioni e le capacità necessarie per valutare, inventariare e pianificare in modo approfondito le successive attività di migrazione e per iniziare il percorso verso le future capacità ibride.
Valutazione dell'ambiente attuale
Un'attività fondamentale nella pianificazione della migrazione è la valutazione dell'ambiente locale attuale e della distribuzione. Ciò fornisce informazioni su quali potenziali cambiamenti potrebbero essere necessari per una transizione di successo a . Consente inoltre di valutare gli elementi chiave della piattaforma rispetto all'attuale distribuzione on-premise. Puoi utilizzare queste informazioni per identificare quali attività specifiche sono necessarie per la transizione e quali modifiche desideri apportare per soddisfare i requisiti aziendali e tecnici e i casi d'uso.
Nell'ambito di questo sforzo è importante esaminare i seguenti aspetti.
Gestione delle licenze
Quando ci si prepara alla migrazione a ., è fondamentale comprendere l'attuale struttura delle licenze della distribuzione esistente. Esegui una valutazione della licenza delle seguenti aree della tua soluzione Cisco on-premise esistente.
-
Piattaforma
La capacità di articolare in modo completo ciò che è attualmente concesso in licenza sulla tua piattaforma principale sarà fondamentale quando collaborerai con il tuo team di account o con il tuo partner per determinare il percorso migliore per ottenere licenze flessibili. è concesso in licenza utilizzando le licenze flessibili. Per ulteriori informazioni sulle licenze flessibili, vedere Piano flessibile di collaborazione Cisco.
-
Utenti e dispositivi
Identifica la categoria di licenza richiesta dai tuoi utenti e dispositivi esistenti. Ciò verrà utilizzato per determinare quale tipo di licenza è richiesto per gli utenti e i dispositivi. Offre diversi tipi di licenza, tra cui licenze Professional e Standard per gli utenti e licenze Professional e per aree comuni per gli spazi di lavoro. Per maggiori informazioni sulla licenza del dispositivo, consultare la scheda tecnica disponibile su Licenza del dispositivo.
-
Gateway locale
Se per questa transizione è necessario Cisco Unified Border Element (CUBE) per l'accesso PSTN, è necessario prendere in considerazione anche la licenza CUBE. Le considerazioni sulla licenza CUBE sono trattate più avanti in questo documento.
Locations/Sites
Quando si pianifica questa transizione, è necessario considerare il numero e la tipologia di siti (grandi sedi centrali, regionali, filiali e così via) all'interno della distribuzione esistente. Una conoscenza approfondita dei siti di distribuzione esistenti aiuterà a pianificare strategicamente una transizione di successo, in particolare quando si tratta di determinare quali siti migrare e in quale ordine. Quando si prendono decisioni sulla migrazione, sarà fondamentale comprendere nel dettaglio i requisiti del piano di selezione (numerazione, abitudini di selezione, classi di restrizione e così via), la connettività di rete del sito e la larghezza di banda (Internet, WAN, LAN) e l'accesso PSTN (locale o centralizzato, IP o TDM) per ciascun sito. Per ulteriori informazioni sui modelli di distribuzione comuni e sulle considerazioni chiave, consultare le informazioni sui modelli di distribuzione della collaborazione disponibili in Collaboration SRND.
Un altro aspetto importante da considerare durante la transizione è la disponibilità della posizione. A seconda di dove si trova la distribuzione, sono disponibili diverse funzionalità, abbonamenti e dispositivi. Per maggiori informazioni sulla disponibilità geografica, vedere Dove è disponibile Webex?.
Infine, è importante comprendere l'impatto che la transizione avrà sugli altri servizi di collaborazione. In base all'obiettivo del presente documento, il presupposto generale è che, se si vogliono mantenere i servizi di collaborazione esistenti al di fuori del carico di lavoro delle chiamate, è prevista la transizione alla distribuzione ibrida di fase 1 menzionata sopra. Esempi di servizi di collaborazione che potrebbero richiedere una distribuzione ibrida includono contact center locali non ancora migrati al contact center Webex e integrazioni strette in sistemi quali sistemi di paging e fatturazione. Per ulteriori informazioni sulla transizione di carichi di lavoro e servizi di collaborazione aggiuntivi, vedere Transizioni di collaborazione.
Inventario esistente devices/clients
Prima di iniziare la transizione è importante fare l'inventario degli endpoint hardware e software esistenti. Avere un elenco completo dei dispositivi types/models, le versioni hardware, i tipi di sistemi operativi client software e le quantità garantiranno una pianificazione adeguata della transizione dei dispositivi e una mitigazione dell'impatto per quei dispositivi che non possono essere migrati alle chiamate cloud. L'inventario dovrebbe essere utilizzato per determinare i dispositivi da sostituire e quelli da sostituire prima della transizione.
Telefoni da scrivania
Per i telefoni da scrivania audio e video sono supportati solo i telefoni da scrivania delle serie 6800, 7800, 8800 e 9800. Questo è un sottoinsieme dei telefoni IP Cisco supportati con . Ci sono alcuni modelli e versioni dei telefoni 6800, 7800 e 8800 che non possono essere utilizzati con . Per ulteriori informazioni sui modelli e sulle versioni hardware supportati, vedere Dispositivi supportati per Webex Calling.
I telefoni IP della serie Cisco 6800 non possono essere aggiornati dal firmware Enterprise al firmware Multiplatform (MPP), necessario per . Pertanto, tutti i telefoni 6800 registrati con firmware aziendale in esecuzione devono essere sostituiti con un modello 6800 MPP o con un altro modello di telefono supportato.
I telefoni IP Cisco serie 7800 e 8800 devono essere aggiornati al firmware Multiplatform Phone (MPP) prima della transizione e della registrazione su . Per determinare quali modelli 7800 e 8800 e versioni hardware supportano il firmware MPP, vedere Convertire i telefoni IP Cisco serie 7800 e 8800 tra firmware Enterprise e MPP.
I modelli 8845, 8865 e 8865NR hanno raggiunto la fine della vendita e non è consigliabile migrarli a .
Si sconsiglia l'utilizzo delle versioni precedenti dei telefoni della serie 8800 (8811, 8841, 8851, 8851NR, 8861) con Webex Calling. I telefoni con versioni hardware VID 14 o precedenti verranno registrati, ma potrebbero verificarsi alcuni problemi di prestazioni dovuti all'hardware.
I telefoni fissi della serie 9800 utilizzano PhoneOS, che supporta sia la registrazione che la registrazione. Pertanto, è possibile passare a questi telefoni senza dover aggiornare il firmware.
Tutti gli altri telefoni IP dovranno essere sostituiti con telefoni delle serie 6800, 7800, 8800 o 9800 supportati da Webex Calling. Per ulteriori informazioni sui telefoni IP e da scrivania supportati con , vedere l'articolo in Dispositivi supportati per Webex Calling.
Endpoint video
Gli endpoint video personali e da sala, tra cui le serie Cisco Board, Room e Desk, possono registrarsi in modo nativo tramite SIP su . Qualsiasi di questi endpoint che deve creare audio and/or Per le chiamate PSTN è necessaria una licenza di chiamata:
-
I dispositivi condivisi nelle sale conferenze, negli spazi di incontro, ecc. richiedono una licenza Professional Workspace o Workspace.
-
Per utilizzare un dispositivo personale dell'utente finale è necessaria una licenza professionale o standard.
Determina quanti endpoint video sono registrati e utilizzati per effettuare chiamate audio. È possibile che alcuni endpoint video vengano utilizzati solo per partecipare a riunioni o effettuare videochiamate SIP. In entrambi i casi, gli endpoint devono comunque essere migrati prima che i server vengano dismessi; tuttavia, questo aiuterà a determinare quanti di essi avranno bisogno di una licenza per continuare a effettuare chiamate telefoniche.
-
Quando i dispositivi video vengono spostati dalla registrazione a , l'URI per questi endpoint cambierà poiché ora sono registrati nel cloud.
-
I modelli di telefono 8845, 8865 e 8875 sono videotelefoni personali supportati con .
Clienti soft
È l'unico client software supportato da , a differenza di Unified CM che supporta sia l'app Webex sia Jabber, ed è il nuovo client software predefinito per gli utenti finali.
A seconda delle modalità di distribuzione implementate per Jabber (solo messaggistica istantanea, solo telefono, and/or modalità UC complete), potrebbe essere necessario considerare anche la transizione della messaggistica and/or Carichi di lavoro delle riunioni da Jabber a . Può essere distribuito in modalità solo telefono se verrà utilizzato come client solo per le chiamate oppure può essere distribuito come suite Webex completa se altri carichi di lavoro, ad esempio Webex Messaging and/or Webex Meetings sta per essere trasferito all'app con funzionalità di chiamata.
Migliora l'esperienza dell'utente finale fornendo funzionalità di intelligenza artificiale come audio/video intelligence, trascrizione delle chiamate e altro. Per ulteriori informazioni, vedi https://www.webex.com/all-new-webex.
Prima di spostare gli utenti, dovrai trasferire i loro client Jabber a . Per completare questa transizione hai due possibilità.
-
Prima di trasferirli a
-
Quando li trasferisci a .
Per facilitare la transizione iniziale a , si consiglia di utilizzare l'opzione 1 e spostare gli utenti a con la chiamata iniziale. Ciò dà agli utenti il tempo di familiarizzare con la nuova applicazione mentre continuano a utilizzare la piattaforma di chiamata locale esistente. Una volta che sei pronto a spostare gli utenti su , dovrai configurarli per registrarsi sulla piattaforma di chiamata cloud.
Per maggiori informazioni su queste due opzioni, vedere Percorso di migrazione: una o due fasi?.
Per un elenco completo dei dispositivi supportati per , vedere Dispositivi supportati per Webex Calling.
Verifica l'idoneità del dispositivo
Come accennato in precedenza, supporta un sottoinsieme dei telefoni IP Cisco e richiede un tipo di firmware diverso per i telefoni delle serie 7800 e 8800. I telefoni Unified CM eseguono il firmware Enterprise, mentre i telefoni eseguono il firmware Multiplatform Phone (MPP). Si consiglia di verificare quali telefoni registrati sono idonei all'aggiornamento al firmware MPP durante la fase di preparazione. In questo modo avrai il tempo di sostituire i telefoni non idonei con uno dei modelli supportati o di identificare un piano alternativo, ad esempio spostando un utente solo sull'app Webex.
Per aiutare a determinare l'idoneità dei telefoni, Control Hub dispone di uno strumento integrato denominato Migra il tuo telefono a Webex Calling. Quando si utilizza questo strumento per verificare l'idoneità del dispositivo, selezionare l'opzione Migrazione Genera solo licenza dispositivo.
Questa opzione consente di caricare un file CSV contenente i telefoni, in modo da poter verificare l'idoneità di ciascun telefono. Selezionando questa opzione di migrazione, i telefoni non verranno aggiunti poiché sei ancora nella fase di preparazione e non sei ancora pronto per farlo. Per ulteriori informazioni, vedere Eseguire la migrazione del telefono a Webex Calling .
È possibile che alcuni telefoni vengano restituiti con un'idoneità Sconosciuta. Ciò accade in genere perché non è possibile convalidare alcune informazioni sul telefono nel sistema back-end. Per tutti i telefoni con stato Sconosciuto, hai due opzioni per verificare se sono idonei all'aggiornamento al firmware MPP.
-
Controllare manualmente ogni telefono e verificare il modello e la versione hardware (PID VID)
7800/8800 etichetta del telefono con informazioni sul modello e sulla versione hardware -
Utilizzare lo strumento di predisposizione del telefono IP Cisco
Scarica lo strumento da https://github.com/joemar2/mpp_readiness_check.
Questo strumento non è uno strumento Cisco ufficiale né è supportato da TAC. Offre il massimo supporto possibile ma è gratuito.
Questo strumento deve essere eseguito su una macchina locale e deve poter accedere ai server e ai telefoni IP. Dispone di un'opzione per abilitare l'accesso web sui telefoni IP, opzione consigliata e necessaria per ottenere i migliori risultati. Pertanto, dovrebbe essere utilizzato fuori orario per evitare disagi agli utenti finali. L'output dello strumento fornisce un report che elenca quali telefoni delle serie 7800 e 8800 sono idonei all'aggiornamento al firmware MPP. Poiché accede direttamente al telefono, può verificare i dispositivi Sconosciuti segnalati dallo strumento Control Hub.
Report sullo strumento di preparazione del telefono IP Cisco
Utenti
Uno dei passaggi preparatori più importanti per garantire il successo della migrazione è il corretto provisioning degli utenti. Anche se si esegue una migrazione graduale, è necessario pianificare adeguatamente tutti gli utenti. Gli utenti devono essere provvisti di uno dei seguenti requisiti:
-
Distribuzione con chiamata
-
Distribuendo il con
-
Configurazione dei servizi per un utente
-
Per rendere gli utenti ricercabili nella directory (clicca per chiamare, informazioni di contatto dell'utente, ricerca nell'elenco telefonico).
Si consiglia di effettuare il provisioning di tutti gli utenti prima o all'inizio del progetto. Ciò include gli utenti che utilizzano ancora Unified CM come piattaforma di chiamata, indipendentemente dal dispositivo di chiamata (telefono IP, Jabber, ecc.). Man mano che gli utenti migrano verso (and/or ) aggiornerai le loro licenze per abilitare i servizi di cui hanno bisogno. Eseguendo il provisioning di tutti gli utenti aziendali che effettuano chiamate prima di iniziare la transizione, si consente a un utente che è passato a o a di cercare nella directory un utente aziendale che utilizza ancora Jabber. and/or SU . Ciò garantisce che gli utenti trasferiti possano trovare le informazioni di contatto di qualsiasi altro utente e contattarlo tramite la ricerca nella directory.
La figura directory search mostra un esempio di un utente che cerca un altro utente. I risultati della ricerca mostrano le informazioni di contatto dell'utente e possono essere per un utente che è ancora su Jabber e/o per un utente che è passato a and/or .
Successivamente, occorre stabilire quali degli utenti che effettuano chiamate in sede verranno trasferiti a . Se tutti gli utenti o un gran numero di essi verranno trasferiti, si consiglia di spostarli in gruppi per garantire che il team di progetto, il personale IT e il personale di supporto siano in grado di gestire la transizione e qualsiasi problema che potrebbe sorgere. Dovresti anche dedicare del tempo a fornire informazioni iniziali e sessioni di formazione per preparare gli utenti a questa transizione. Il raggruppamento degli utenti in fase di transizione può essere effettuato in base a vari criteri, tra cui la posizione o il sito a cui sono assegnati gli utenti, i reparti degli utenti o persino i tipi di utenti (lavoratori della conoscenza, dirigenti, lavoratori mobili e così via).
Ad esempio, se gli utenti nella distribuzione sono divisi in tre sedi principali, New York (NYC), San Francisco (SFC) e Research Triangle Park (RTP), un piano di transizione degli utenti potrebbe assomigliare al piano delineato nella tabella Piano di transizione degli utenti per sito.
| Sito utente / posizione | Sessioni di informazione e formazione pre-transizione | Periodo di transizione | Supporto post-transizione |
|---|---|---|---|
| New York (1.525 utenti) | Settimana del 1 aprile | 15 aprile – 27 aprile | Settimana del 29 aprile |
| SFO (1.600 utenti) | Settimana del 6 maggio | 20 maggio – 31 maggio | Settimana del 3 giugno |
| RTP (1.275 utenti) | Settimana del 3 giugno | 17 giugno – 28 giugno | Settimana del 1 luglio |
Un altro fattore importante è la transizione tra utenti che hanno dipendenze tra loro. Ciò potrebbe includere, ma non è limitato a quanto segue:
-
Monitoraggio BLF
-
Stessa caccia pilot/group
-
Condividi le linee
-
Parte dello stesso gruppo di risposta alle chiamate
-
Utilizzando gli stessi numeri di parcheggio delle chiamate
-
Intercom
-
Admin/Exec.
È possibile rivedere la configurazione (GUI o esportazione) oppure utilizzare lo strumento Migration Insights per identificare i gruppi di utenti con queste dipendenze.
Connettività PSTN
è possibile accedere alla PSTN in tre modi: Piani tariffari Cisco, Cloud Connect per (in precedenza Cloud Connected PSTN) e PSTN on-premise (gateway locale). Tuttavia, una singola posizione, come definita all'interno, può essere assegnata solo a una singola opzione PSTN.
La rete PSTN locale con gateway locale (LGW) è una componente essenziale della strategia di transizione. Fornisce connettività tra la distribuzione in sede and/or PSTN e la piattaforma supportano sia i session border controller (SBC) Cisco che quelli certificati di terze parti, che possono essere utilizzati come gateway locale. Per l'elenco più recente degli SBC supportati, vedere Elenco degli SBC supportati.
supporta fino a 250 chiamate simultanee da un singolo gateway locale basato sulla registrazione e più di 250 chiamate simultanee da un singolo gateway locale basato sul certificato. I gateway locali basati su certificati possono supportare fino a 6500 chiamate simultanee, ma questo dipende dal tipo di connettività di cui dispone il gateway locale (Over-the-Top o peering di interconnessione) e dal modello SBC su cui è distribuito il gateway locale. Questi limiti sono in sostanza il limite di conteggio predefinito sia per le chiamate PSTN basate su gateway locali sia per le chiamate tra siti e endpoint. Per ulteriori informazioni, vedere Introduzione al gateway locale.
Tutte le chiamate che superano questo limite vengono rifiutate con un codice 403 Forbidden. Il comando show call active voice può essere eseguito sul gateway locale in qualsiasi momento per determinare il numero totale di chiamate attive.
Scarse condizioni di rete tra un gateway locale e l'SBC di accesso possono limitare le prestazioni della connessione di segnalazione, con conseguente riduzione del limite di chiamate simultanee. La latenza unidirezionale tra il gateway locale e il data center non deve superare i 100 ms e il jitter deve essere inferiore a 10 ms mentre la perdita di pacchetti è inferiore a 0,5 %.
Caratteristiche & utilizzo delle funzionalità
Quando si valuta l'ambiente attuale, è importante identificare e rivedere quali funzionalità sono configurate. Inoltre, è importante comprendere l'utilizzo delle funzionalità in modo da poter (ri)definire i requisiti aziendali e tecnici per la distribuzione.
Per determinare quali funzionalità sono configurate, analizzare la configurazione. Si tratta di dati statici che vengono impostati quando una funzionalità o un'impostazione viene configurata sul sistema. Per completare questa analisi è possibile utilizzare le seguenti opzioni:
-
Rivedere la configurazione nell'interfaccia utente grafica di amministrazione
-
esportazione di configurazione -- esportazione in blocco o AXL
-
strumento di approfondimento sulla migrazione (consigliato)
-
Strumenti dei partner di terze parti Cisco (consigliati).
Per analizzare efficacemente l'utilizzo delle funzionalità, è essenziale esaminare i dati dinamici del sistema, quali utilizzo, registrazioni e attività delle chiamate. Vari strumenti analitici e dashboard forniscono informazioni approfondite su queste metriche, consentendo una comprensione completa delle prestazioni e della capacità del sistema, che supporta un processo decisionale informato durante gli sforzi di migrazione e ottimizzazione. Per completare questo tipo di analisi è possibile utilizzare le seguenti opzioni:
-
Revisione dei record CDR grezzi
-
Revisione dei dati Unified CM RTMT
-
strumento Migration Insights che utilizza i dati CDR
-
Revisione dell'analisi UC connessa al cloud in
-
Volume delle chiamate
-
Endpoint registrati
-
(CAC) posizioni
-
Utilizzo del bagagliaio.
-
-
Strumenti dei partner di terze parti Cisco.
Per questa analisi, Cisco consiglia di iniziare con lo strumento Webex Control Hub Migration Insights. Importerai il file .TAR di esportazione e i file CDR di Unified CM (facoltativi, ma necessari per l'analisi dell'utilizzo delle funzionalità) nello strumento. Lo strumento genererà i seguenti report in formato CSV che possono essere utilizzati per avviare l'analisi:
| Nome del rapporto Descrizione del rapporto |
|---|
| ImportedDataBulk.csv Tutti gli utenti e i dispositivi dai dati Unified CM |
| DeviceEligibility.csv Identifica i dispositivi idonei alla migrazione a Webex Calling (telefoni IP, dispositivi Room OS, ATA e terze parti) |
| DevicePoolNumbers.txt Elenco di tutti i numeri in un particolare pool di dispositivi |
| HuntGroup_CallQueue_CallPark_CallPickUpGroups.csv Dettagli sui dispositivi e sugli utenti che devono essere migrati insieme in base alle linee condivise, al pilota di ricerca, alla coda di chiamata, al parcheggio delle chiamate e alla configurazione del gruppo di risposta alle chiamate |
| HuntGroupMigrationInsight.csv Informazioni dettagliate sulle linee di ricerca assegnate, sui gruppi di linee e sugli agenti associati |
| SharedlineGroupMigrationReport.csv Panoramica su come i numeri di telefono (numeri di rubrica) vengono condivisi tra gli utenti |
| Nome del rapporto Descrizione del rapporto |
|---|
| FeatureUsageBasedDeviceEligibilityReport.csv Informazioni sull'idoneità alla migrazione dei dispositivi in base all'utilizzo delle funzionalità |
| FeatureUsageWithLastUsageDateReport.csv Conteggio dell'utilizzo per il numero di volte in cui i piloti di caccia e le code di chiamata sono stati chiamati insieme all'ultima data di utilizzo |
| UserWorkspaceLastUsage.csv Ultima data di utilizzo per utenti e spazi di lavoro sia per client software che per telefoni fisici |
| DIDUsageReport.csv Utilizzo del DID sia per i DID assegnati che per quelli non assegnati |
Per maggiori dettagli sui report Migration Insights, vedere Migration Insights.
Se hai bisogno di maggiori informazioni sulle funzionalità e sull'utilizzo dopo aver esaminato le informazioni nei report Migration Insights, Cisco consiglia di prendere in considerazione uno degli strumenti di migrazione dei partner di terze parti di Cisco and/or per rivedere le configurazioni nella GUI o nei dati di esportazione della configurazione.
Integrazioni Cisco: Connessione Unity UCCX UCCE
La segreteria telefonica è parte integrante dell'offerta ed è integrata nativamente nella soluzione. Non può essere integrata con una soluzione di segreteria telefonica basata su sede come Unity Connection o Unity Connection Express. Inoltre, non esiste un modo nativo per migrare i messaggi di posta vocale o i saluti della connessione Unity esistenti al servizio di posta vocale nativo disponibile con . Alcuni strumenti di migrazione dei partner terzi di Cisco sono in grado di migrare alcuni di questi dati. Per ulteriori informazioni sulla segreteria telefonica per , vedere Configurare e gestire le impostazioni della segreteria telefonica per un utente Webex Calling.
supporta anche la posta vocale condivisa e le caselle di posta fax. Per ulteriori informazioni, vedere Gestire una casella di posta vocale condivisa e una casella di fax in entrata per Webex Calling.
dispone di una funzione di risposta automatica integrata, inclusa nella piattaforma principale. Questa funzionalità consente la transizione dei gestori delle chiamate e della funzionalità di risposta automatica di Unity Connection. Lo strumento Control Hub, Migrazione delle funzionalità da Unified CM, supporta la migrazione delle configurazioni di Unity Connection agli operatori automatici. Per ulteriori informazioni sull'utilizzo di questo strumento, vedere Migrazione di dispositivi e funzionalità da Unified CM a Webex Calling.
Registrazione chiamate
include due opzioni per la registrazione delle chiamate senza costi aggiuntivi.
-
Registrazione delle chiamate Webex
-
Registrazione Dubber Go (offerta partner): un'integrazione tra Dubber e Dubber in cui tutti i contenuti multimediali registrati vengono conservati in modo sicuro nel cloud.
opzioni di registrazione incluse la tabella evidenzia alcune caratteristiche chiave delle due opzioni di registrazione delle chiamate disponibili senza costi aggiuntivi.
| Webex | Dubber Go |
|---|---|
| Disponibile per tutti gli utenti | Disponibile per tutti gli utenti |
| Registrazioni illimitate | Registrazioni illimitate |
| Periodo di conservazione di 1 anno* | Periodo di conservazione di 30 giorni |
| 100 GB di spazio di archiviazione per organizzazione | - |
| Gli addetti alla conformità possono accedere e gestire le registrazioni delle chiamate | - |
| API per gestire le registrazioni | - |
Gli amministratori possono configurare e gestire l'accesso degli utenti alle registrazioni delle chiamate
|
Solo gli utenti possono accedere e gestire le proprie registrazioni
|
Se la tua organizzazione necessita di funzionalità di registrazione aggiuntive come la registrazione delle chiamate di conformità, periodi di conservazione più lunghi, più spazio di archiviazione, analisi AI, and/or l'accesso come amministratore, le offerte a pagamento o i componenti aggiuntivi sono disponibili sia da Cisco che da fornitori di servizi di registrazione di terze parti. Per ulteriori informazioni sui provider di registrazione, sulle configurazioni e sui servizi aggiuntivi dei partner, vedere Gestire la registrazione delle chiamate per Webex Calling.
Integrazioni di terze parti
supporta una varietà di integrazioni diterze parti , tra cui, a titolo esemplificativo ma non esaustivo, SBC per gateway locali, telefoni IP, telefoni interfonici, Speaker/Pagers, ATA, ecc. Oltre a questi dispositivi diterze parti , Webex Calling supporta diverse soluzioni diterze parti per l'assistenza clienti, l'analisi, la registrazione, la fatturazione, ecc. Per ulteriori informazioni sulle soluzioni diterze parti, vedere Webex App Hub.
Pianifica
Piano di progetto di alto livello
Quando si sviluppa un piano di progetto di alto livello per la migrazione da a , è essenziale stabilire fasi e traguardi chiari che siano in linea sia con gli obiettivi aziendali sia con i requisiti tecnici. Il piano dovrebbe iniziare con una fase di valutazione completa, che comprenda la raccolta di requisiti tecnici e aziendali dettagliati, nonché l'identificazione delle parti interessate e la definizione dei criteri di successo. Tra le considerazioni chiave rientrano l'allocazione delle risorse, la stima delle tempistiche, la gestione del rischio e le strategie di comunicazione per garantire che tutte le parti siano informate e coinvolte durante l'intera migrazione. Inoltre, il piano dovrebbe includere punti di controllo di convalida, come test pilota e implementazioni graduali, per ridurre al minimo le interruzioni e consentire aggiustamenti in base al feedback.
Esempi di elementi da includere nel piano di progetto sono:
-
Definizione dell'ambito della migrazione (ad esempio, quali utenti, dispositivi e funzionalità saranno trasferiti)
-
Pianificazione di sessioni di formazione per utenti finali e team di supporto
-
Coordinare le valutazioni della prontezza della rete e
-
Pianificazione delle attività di passaggio con opzioni di fallback. È inoltre importante integrare le revisioni di conformità e sicurezza, nonché le fasi di supporto e ottimizzazione post-migrazione.
Strutturando il piano di progetto tenendo conto di queste considerazioni, le organizzazioni possono gestire meglio la complessità, ridurre i rischi e ottenere una transizione più agevole verso .
Viaggio migratorio: una o due fasi?
richiede agli utenti di utilizzare il software client per le chiamate. Pertanto, se qualche utente sta ancora utilizzando , hai due opzioni su quando puoi spostarli su . È possibile effettuare una migrazione utente in un unico passaggio oppure in due passaggi.
Opzione 1: Migrazione utente in un unico passaggio
In una migrazione in un unico passaggio, gli utenti passano da Unified CM a . Questa opzione è in genere adatta ai clienti con un numero limitato di utenti da migrare e che possono gestire lo spostamento simultaneo sia del soft client dell'utente sia del servizio di chiamata. La figura Servizio di chiamata dell'utente, client software & il telefono migra allo stesso tempo di seguito viene evidenziato questo tipo di migrazione. Con questa opzione l'utente potrà completare contemporaneamente le seguenti operazioni:
-
Servizi di chiamata spostati da a
-
Numeri di telefono ed estensioni spostati da a
-
Il client soft è passato da Jabber a - si registrerà a
-
Registrazione telefonica spostata da a .
Può trattarsi comunque di una migrazione graduale, in cui gruppi di utenti vengono spostati in momenti diversi, ma quando ogni utente viene spostato, tutte queste operazioni avvengono contemporaneamente.
Opzione 2: Migrazione utente in due fasi
L'altro approccio è una migrazione in due fasi. Nella fase 1, gli utenti vengono trasferiti da a ma rimangono attivi per i servizi di chiamata. Quindi, nel passaggio 2, gli utenti vengono spostati da Unified CM a . Questa opzione è consigliata ai clienti più grandi per gestire le modifiche dell'utente finale e per separare la modifica del soft client dell'utente dalla modifica del servizio chiamante. La figura seguente Migra il soft client; quindi migra il servizio di chiamata, soft client & telefono a Webex Calling di seguito evidenzia questo tipo di migrazione.
Passo 1
-
Il client soft è passato da a - verrà registrato su .
Passo 2
-
Servizi di chiamata spostati da a .
-
Numeri di telefono ed estensioni spostati da a .
-
registrazione spostata da a .
-
Registrazione telefonica spostata da a .
Può trattarsi comunque di una migrazione graduale, in cui gruppi di utenti vengono spostati in momenti diversi in entrambe le fasi.
L'opzione scelta dipende da come si desidera gestire la transizione dei propri utenti verso e . Si raccomanda di procedere per gradi (opzione 2). Ciò consente di ridurre al minimo le modifiche apportate dall'utente finale in una sola volta e di suddividere lo sforzo tra le diverse parti del progetto. Tuttavia, se preferisci che gli utenti siano interessati una sola volta, allora è valida anche l'opzione 1.
Osservando il percorso consigliato (opzione 1), la mappa di transizione di alto livello dall'app Jabber a Webex la figura seguente mostra la transizione di alto livello per il passaggio 1.
In questa fase gli utenti passano da Jabber a tutti i loro servizi di chiamata. Tuttavia, la piattaforma di chiamata è ancora Unified CM e registrerà i suoi servizi di chiamata su . Come si vede nella figura mappa di transizione di alto livello dall'app Jabber a Webex, l'infrastruttura locale non cambia e funziona allo stesso modo di Jabber. L'unica modifica è che richiede una connessione verso .
Per ulteriori informazioni su questa transizione, vedere Mappa di transizione da Jabber a Webex e Guida alla distribuzione nella sezione Client nella pagina Transizione di collaborazione.
Mappa di transizione di alto livello da Unified CM a Webex Calling La figura rappresenta la transizione di alto livello da a . Questo è il secondo passaggio del percorso consigliato.
Anche se si decide di utilizzare l'approccio in un unico passaggio, vale quanto segue.
In questa fase gli utenti vengono suddivisi in gruppi. A questo punto gli utenti iniziano a utilizzare per i loro servizi di chiamata la registrazione delle chiamate e la registrazione del telefono IP.
Poiché gli utenti si spostano in gruppi, durante la transizione gli utenti Enterprise saranno suddivisi tra le due piattaforme di chiamata. Fase 1 nella mappa di transizione di alto livello da Unified CM a Webex Calling la figura illustra questo stato. Durante questa fase è necessario pianificare come gestire le chiamate tra gli utenti sulle due piattaforme e come verranno instradate le chiamate PSTN. Ogni volta che un gruppo di utenti viene trasferito a , saranno richiesti aggiornamenti dei piani di selezione e dell'instradamento delle chiamate su , e sui gateway locali.
Una volta completata la transizione di tutti gli utenti, i client software e i dispositivi (Fase 2), tutta l'infrastruttura UC locale potrà essere rimossa e dismessa.
Progetta
Selezione della regione
è disponibile a livello globale e viene fornito da data center ridondanti in più regioni: Stati Uniti (Dallas, Chicago), Canada (Vancouver, Toronto), Europa (Francoforte, Amsterdam), Regno Unito (Londra, Manchester), Australia (Melbourne, Sydney), Giappone (Tokyo, Osaka), Arabia Saudita (Riyadh, Jeddah) e India (Mumbai, Chennai). I PoP multimediali forniscono servizi multimediali per ottimizzare i tempi di andata e ritorno dei media. Ad esempio, il data center di Singapore viene utilizzato per ottimizzare i tempi di andata e ritorno dei media per i clienti nei paesi asiatici, dove i tempi di andata e ritorno verso l'Australia o il Giappone potrebbero non essere ottimali. I data center sono interconnessi tramite una dorsale multi-gigabit completamente ridondante. La figura data center distribuiti a livello globale mostra una panoramica di tutti i data center. Per l'elenco più recente dei data center disponibili, vedere Posizioni dei data center per Webex Calling.
Ogni cliente viene fornito su una delle istanze. Tutte le informazioni di provisioning di quel cliente vengono archiviate in quell'istanza e la segnalazione SIP di tutti gli endpoint e gateway locali forniti per quel cliente è collegata all'istanza su cui è fornito il cliente. Poiché è difficile modificare la selezione iniziale della regione, è importante considerare tutti i fattori rilevanti come parte del processo decisionale che porta alla selezione della regione. Per evitare un ritardo eccessivo nel round-trip della segnalazione, è importante decidere all'inizio del processo di transizione quale istanza utilizzare. Cisco consiglia di selezionare l'istanza che fornisce i tempi di andata e ritorno della segnalazione più bassi per il maggior numero di utenti all'interno della distribuzione.
Per la disponibilità nei vari Paesi, vedere Dove è disponibile Webex?.
Posizioni
Per preparare la fornitura delle posizioni è necessario raccogliere le informazioni necessarie per tutte le posizioni di destinazione della migrazione. Le informazioni necessarie per ogni posizione sono riepilogate in Informazioni da acquisire per ogni posizione.
| Informazioni | Commento |
|---|---|
| Gamma di estensione | Ogni posizione può avere estensioni che iniziano con cifre diverse. Una cifra deve essere riservata per la cifra di controllo della chiamata inter-sito (ad esempio 8) e una per la cifra di controllo PSTN (ad esempio 9). Nessun intervallo di estensione può iniziare con una di queste due cifre. Tutti i campi di estensione di tutte le sedi devono avere la stessa lunghezza. |
| Intervallo DID | - |
| Cifra di sterzo PSTN | - |
| Codice del sito | Tutti i codici sito di tutte le località devono essere univoci e avere la stessa lunghezza. |
| Numero principale | Quando si crea una posizione, è necessario predisporre due DID. Uno come numero principale (ad esempio da assegnare a un servizio di centralino automatico) e uno per il portale della segreteria telefonica. Fornire un DID per il numero della segreteria telefonica. |
| Numero della segreteria telefonica | |
| Numero di licenze | Licenze richieste per tipo, tra cui Standard, Professional, Workspace, Elenco percorsi, Piano chiamate in uscita. |
| Chiamate simultanee nell'ora di punta | Somma delle chiamate simultanee tra dispositivi e tra dispositivi e gateway locale (PSTN e chiamate ai dispositivi). Necessario per determinare la larghezza di banda richiesta per l'accesso a Internet. |
| Paese | - |
| Fuso orario | - |
| Lingua | - |
| Contatto (nome, telefono, e-mail) | - |
| Indirizzo (Indirizzo, Città, Stato, CAP) | - |
| Posizione fisica di invio dei servizi di emergenza per gli endpoint | La posizione del dispositivo di invio utilizzata per le chiamate di emergenza generalmente include quanto segue: indirizzo dell'edificio, indirizzo dell'edificio + numero del piano, indirizzo dell'edificio + numero della suite o indirizzo dell'edificio + numero del piano + office/cubical numero. |
| Posizione di rete fisica univoca per dispositivo per i servizi di emergenza | La posizione fisica della rete per le chiamate di emergenza generalmente include quanto segue: interruttore / switchport per dispositivi cablati, identificatori di set di servizi di base (BSSID) dei punti di accesso wireless (AP) per dispositivi connessi wireless, and/or subnet IP locali per dispositivi endpoint. |
PSTN
Quando si progetta un'implementazione, i clienti hanno a disposizione tre principali opzioni di connettività PSTN: Piani di chiamata Cisco (un servizio PSTN fornito tramite cloud gestito da Cisco), provider PSTN connessi al cloud (CCPP, in cui i provider forniscono il servizio PSTN tramite il cloud) e PSTN in sede (in cui i gateway locali collegano la rete aziendale alla PSTN). Con l'introduzione del trunking PSTN per le distribuzioni ibride (per ulteriori informazioni, vedere Trunking PSTN per distribuzioni ibride di Webex Calling in Trunking PSTN), le organizzazioni ottengono maggiore flessibilità nel loro approccio alla migrazione. Questa funzionalità consente ai clienti di spostare la propria rete PSTN su CCPP all'inizio del percorso di transizione e di iniziare la transizione al cloud PSTN per gli utenti, sfruttando al contempo CCPP per mantenere il servizio PSTN per gli utenti che rimangono su Cisco durante una migrazione graduale.
Questo approccio ibrido consente alle organizzazioni di spostare prima determinati gruppi di utenti sul cloud, senza dover rivedere immediatamente l'intero ambiente di telefonia. Tuttavia, introduce ulteriore complessità e rischi, in particolare per quanto riguarda l'adattamento della logica di instradamento delle chiamate esistente per supportare la nuova architettura. Anche l'interoperabilità con applicazioni legacy, come server fax, contact center o sistemi di paging, richiede un'attenta valutazione. Le principali sfide tecniche potrebbero includere la garanzia di una negoziazione codec end-to-end senza interruzioni e di una segnalazione DTMF (Dual-Tone Multi-Frequency) nell'ambiente misto, nonché la convalida della compatibilità con funzionalità di telefonia specializzate. Una pianificazione e dei test adeguati sono essenziali per ridurre al minimo le interruzioni e mantenere servizi vocali affidabili durante l'intero processo di migrazione. Inoltre, sono importanti le considerazioni commerciali, poiché il trunking ibrido richiede una licenza d'uso basata sul numero di chiamate simultanee tra l'ambiente locale e il Cloud Connected PSTN Provider (CCPP).
In alternativa, le organizzazioni possono scegliere di mantenere la connettività PSTN in sede durante la fase di transizione. In questo scenario, la migrazione a CCPP può essere eseguita in due modi: come un passaggio unico e coordinato per tutti gli utenti e le sedi una volta completata la migrazione, oppure in modo incrementale, con la migrazione PSTN che avviene in base alla sede man mano che gli utenti vengono spostati su . Questo approccio può contribuire a semplificare la coesistenza e a mantenere la continuità delle integrazioni legacy, ma introduce diverse complessità operative. Tra queste vi sono le sfide legate al trasferimento dei numeri, come la necessità di un coordinamento preciso degli ordini di trasferimento dei numeri, potenziali ritardi e limitazioni imposte dal provider, come un limite al numero di richieste di trasferimento simultanee o restrizioni sul trasferimento di sottoinsiemi di blocchi di numeri di grandi dimensioni. Le organizzazioni devono pianificare attentamente la propria strategia di transizione alla rete PSTN, tenendo conto di queste considerazioni logistiche per evitare interruzioni del servizio e garantire un'esperienza di migrazione senza intoppi.
La figura Migrazione a CCCP all'inizio rispetto al mantenimento della PSTN in sede mostra le due opzioni di migrazione PSTN spiegate sopra. L'illustrazione a sinistra mostra lo scenario in cui tutti gli utenti e le applicazioni locali utilizzano i servizi PSTN Cloud Connected tramite un trunk locale e un gateway locale che collega l'ambiente locale a, mentre l'illustrazione a destra mostra lo scenario in cui l'attuale PSTN locale rimane in posizione e gli utenti di Webex Calling utilizzano la PSTN locale tramite la connessione gateway locale tra l'ambiente locale e . Durante la transizione è possibile passare all'utilizzo della rete PSTN connessa al cloud.
In entrambi gli scenari le chiamate tra locale e utente utilizzano la connessione Gateway locale. La connessione tra locale e deve essere progettata e dimensionata di conseguenza in base al numero previsto di chiamate contemporanee e alla ridondanza richiesta.
Piano di chiamata
Per ottenere un'interoperabilità senza soluzione di continuità tra e durante il periodo di migrazione, è necessario sviluppare e implementare un'architettura completa del piano di selezione su entrambe le piattaforme. Questa progettazione del piano di chiamata a doppia piattaforma garantisce un instradamento delle chiamate coerente, una traduzione dei numeri e una trasparenza delle funzionalità, consentendo agli utenti di entrambi i sistemi di comunicare senza degrado del servizio o interruzioni dell'esperienza utente durante la fase di coesistenza.
Piano di chiamata in sede in
Durante la transizione, per consentire la coesistenza dei dispositivi registrati su Unified CM e sul piano di numerazione aziendale, è necessario apportare modifiche in modo che possano essere soddisfatti almeno i seguenti requisiti:
-
+E.164 chiamata da a
-
Composizione dell'estensione da a (all'interno del sito ma anche tra siti se gli intervalli di estensione sono univoci)
-
Chiamata abbreviata tra siti da a
-
Chiamata forzata in rete da a
-
Richiamata dalla rubrica delle chiamate perse alle destinazioni su
-
Chiamate PSTN da a PSTN se durante la transizione viene utilizzata la PSTN locale per
-
Chiamate PSTN da a se durante la transizione il trunking PSTN per le distribuzioni ibride viene utilizzato per fornire l'accesso PSTN agli utenti locali tramite Cloud Connect per
-
Forzato sulla rete da a
-
Composizione di numeri interni da a (inter-sito).
Se una qualsiasi delle abitudini di composizione sopra indicate non è supportata prima della transizione (ad esempio, non esiste un'abitudine di composizione abbreviata tra siti), non è necessario che venga necessariamente introdotta durante la transizione.
La figura Best practice dial plan mostra l'approccio best practice al piano di selezione come descritto in Architettura preferita per le distribuzioni aziendali on-premise di Cisco Collaboration 12.x, CVD. Le caratteristiche principali di questo approccio includono:
-
Partizione singola per +E.164 numeri di directory
-
Routing del core basato su +E.164 modelli di percorso
-
Normalizzazione di tutte le abitudini di composizione a +E.164 utilizzando modelli di traduzione
-
Utilizzo del modello di traduzione che chiama l'ereditarietà dello spazio di ricerca (opzione Utilizza lo spazio di ricerca chiamante dell'originatore impostato sui modelli di traduzione).
Ad esempio, la chiamata PSTN (9+1+10D) da un dispositivo in SJC dotato di spazio di ricerca delle chiamate di linea SJCInternational verrà prima trovato da 9.1[2-9]XX[2-9]XXXXXX modello di traduzione che normalizza il numero della parte chiamata a +E.164. La ricerca secondaria utilizza quindi lo stesso spazio di ricerca chiamante SJCInternational di nuovo (chiamando l'eredità dello spazio di ricerca) e il +E.164-digit la stringa verrà abbinata da un +E.164 numero di directory nella partizione DN o da uno dei modelli di percorso PSTN nella partizione USPSTNNational o SJCPSTNLocal. Le abitudini di composizione abbreviate intra-sito e inter-sito sono implementate dalle traduzioni nelle partizioni ESN e SJCtoE164. Mentre la partizione ESN è una partizione globale (accessibile ai telefoni in tutte le posizioni), la partizione SJCTOE164 è accessibile solo agli utenti nella posizione SJC. Ciò presuppone che gli intervalli di estensione siano sovrapposti.
Il primo passo per abilitare la chiamata da a è assicurarsi che +E.164 le destinazioni vengono instradate di conseguenza. Ciò può essere ottenuto aggiungendo una partizione al piano di selezione, aggiungendo +E.164 modelli di percorso per tutte le destinazioni di quella partizione e, infine, aggiunta della partizione a tutti gli spazi di ricerca chiamanti che rappresentano le classi di servizio che devono essere in grado di raggiungere . È necessario creare una partizione dedicata per consentire la creazione di una classe di servizio differenziata per le chiamate provenienti da . Per evitare loop di chiamate, lo spazio di ricerca delle chiamate in entrata sul trunk dal gateway locale non deve avere accesso alla partizione.
Come mostrato nella figura +E.164 routing a Webex Calling, per abilitare il routing da a per una posizione con +E.164 Gamma DID +1 221 555 2XXX e codice sito 121, un modello di percorso urgente corrispondente a questo +E.164 è necessario aggiungere l'intervallo alla partizione .
Se non è richiesta alcuna selezione di un gateway locale specifico del sito, anziché utilizzare un elenco di percorsi con un gruppo di percorsi locale come destinazione, è possibile predisporre modelli di percorsi che puntano a un singolo gruppo di percorsi con il gateway locale come unico membro e quindi i modelli di percorsi puntano a un singolo elenco di percorsi con questo gruppo di percorsi come unica voce.
Per abilitare la chiamata abbreviata inter-sito al sito, il modello di percorso richiesto 8121.2XXX viene aggiunto alla partizione. Per i siti da trasferire a un modello di normalizzazione della composizione 8121.2XXX che normalizza la composizione ESN a +E.164 potrebbe già esistere nella partizione ESN. In tal caso, 8121.2XXX sembra ridondante, ma non appena tutti i DN della rispettiva posizione sono stati migrati al modello di traduzione della normalizzazione della composizione 8121.2XXX, è possibile rimuovere il modello di routing 8121.2XXX e quindi abilitare la composizione ESN anche per gli utenti con solo estensione in quell'intervallo.
Con queste modifiche al piano di chiamata, le chiamate alla sede possono essere effettuate non solo componendo numeri abbreviati inter-sede e +E.164. Inoltre, la chiamata PSTN nazionale e internazionale è possibile perché queste abitudini di chiamata vengono prima normalizzate a +E.164 attraverso i modelli di traduzione di normalizzazione della composizione già esistenti e quindi vengono instradati tramite la corrispondenza +E.164 modello di percorso nella partizione.
IL +E.164 È possibile effettuare il provisioning del pattern di percorso nell'intervallo DID della posizione mentre tutti i DID sono ancora ospitati su . Il miglior algoritmo di corrispondenza del modello di corrispondenza assicura che quando viene composto un numero ospitato su +E.164 il numero di directory fornito corrisponde meglio di quello con caratteri jolly +E.164 modello di percorso che punta a in modo che le chiamate vengano estese a una linea attiva e non inviate a .
piano di chiamata
Ogni utente è dotato di un'estensione and/or UN +E.164 numero di telefono. La lunghezza dell'estensione è un'impostazione globale fissa: tutte le estensioni in una distribuzione hanno la stessa lunghezza. La chiamata tramite estensione può essere utilizzata sia tra utenti all'interno di una stessa sede che tra sedi diverse. La composizione abbreviata dell'interno tra siti (quest'ultimo caso) funziona solo se l'interno composto è univoco.
Se è richiesta la chiamata abbreviata tra sedi diverse ma ci sono sovrapposizioni tra gli interni assegnati in sedi diverse, è necessario creare un piano di numerazione specifico per l'azienda anteponendo agli interni un codice di accesso e un codice di sede. Per ulteriori informazioni, vedere Architettura preferita per le distribuzioni on-premise di Cisco Collaboration 15, Panoramica della progettazione disponibile su Architetture preferite per la collaborazione Cisco.
La lunghezza dell'estensione, il comportamento di composizione dell'estensione inter-sede, la lunghezza del prefisso per la composizione inter-sede e la cifra di controllo nel prefisso di routing per la composizione inter-sede sono configurati nelle impostazioni del servizio di chiamata in :
-
Lunghezza del prefisso di routing della posizione: Lunghezza del prefisso, inclusa la cifra di sterzo. Richiesto solo se è necessario stabilire un piano di numerazione aziendale come abitudine alternativa di chiamata abbreviata tra sedi aziendali.
-
Cifra di sterzata nel prefisso di routing: Cifra di riferimento per la consuetudine di chiamata abbreviata tra sedi aziendali. Si dovrebbero evitare sovrapposizioni con la prima cifra di qualsiasi posizione e con le cifre di chiamata in uscita della posizione. Richiesto solo se è necessario stabilire un piano di numerazione aziendale come abitudine alternativa di chiamata abbreviata tra sedi aziendali.
-
Lunghezza estensione interna: Lunghezza standard delle estensioni. Può avere un valore compreso tra due e dieci.
Quando è richiesta la composizione di un interno o la composizione tramite numeri significativi aziendali (codice di gestione, codice sito, interno) da un controllo delle chiamate in sede e il controllo delle chiamate in sede invia un interno come ID chiamante, assicurarsi di impostare anche il parametro Lunghezza massima dell'interno sconosciuto nella sezione Instradamento delle chiamate tra e locali per assicurarsi che le chiamate upstream dal controllo delle chiamate in sede a possano essere classificate correttamente come chiamate in sede. -
Consenti la composizione di numeri interni tra le sedi: Passa a enable/disable chiamate in estensione tra sedi. Questa opzione dovrebbe essere abilitata solo se tutte le estensioni all'interno dell'organizzazione sono univoche. Se l'opzione è disabilitata, è necessario comporre numeri aziendali significativi (prefisso, codice sito, interno) o numeri di telefono tra le sedi.
I primi tre parametri vengono utilizzati principalmente per creare un piano di selezione per i telefoni, al fine di ridurre al minimo i timeout tra le cifre quando si utilizza la composizione con ricevitore sganciato. Sono ancora possibili deviazioni da queste impostazioni globali (ad esempio, è possibile predisporre interni con una lunghezza diversa), ma verrà visualizzato un messaggio di avviso in Control Hub e la chiamata dai telefoni potrebbe richiedere la composizione in blocco per evitare conflitti all'interno del piano di chiamata precaricato.
La tabella Esempio di numerazione aziendale mostra un esempio di tre sedi in cui gli intervalli di estensione di due sedi, NYC e RTP, sono identici. L'istituzione di uno schema di numerazione aziendale con la cifra di controllo inter-sito 8, seguita da un codice sito a tre cifre e dall'estensione a quattro cifre crea un'abitudine di composizione abbreviata inter-sito non sovrapposta.
| Sito | Gamma di estensione | Codice del sito | Gamma Enterprise |
|---|---|---|---|
| New York | 2XXX | 202 | 8 202 2XXX |
| SFO | 3XXX | 203 | 8 203 3XXX |
| RTP | 2XXX | 204 | 8 204 2XXX |
Per consentire una transizione graduale, le abitudini di composizione dei numeri degli utenti prima e dopo la transizione dovrebbero idealmente essere le stesse. Per preparare la transizione in ogni sede, è necessario documentare gli intervalli DID e gli intervalli di estensione (o abitudini di composizione abbreviate all'interno del sito). Sulla base di queste informazioni è quindi necessario selezionare la cifra di sterzatura inter-sito.
La tabella Intervalli di estensione a lunghezza fissa mostra un esempio di tre posizioni e intervalli di estensione a lunghezza fissa. Poiché è necessario evitare sovrapposizioni nelle abitudini di composizione, è importante assicurarsi che per qualsiasi intervallo di estensione la prima cifra dell'intervallo non corrisponda alla cifra di controllo per la composizione abbreviata tra siti. Se ad esempio viene selezionato 8 come cifra di riferimento per la chiamata inter-sito, nessun intervallo di estensione in nessun sito può iniziare con 8. In genere, le estensioni di una determinata posizione corrispondono alle ultime cifre dei DID assegnati a quella posizione. Per evitare conflitti è possibile modificare la prima cifra dell'estensione. Se, ad esempio, i DID nel +1 Se in una posizione viene utilizzato l'intervallo 408 555 8XXX, invece di utilizzare 8XXX come intervallo di estensione, è possibile utilizzare 7XXX per le estensioni in quel sito
| Sito | Gamma di estensione | Interni | Codice del sito | Gamma Enterprise |
|---|---|---|---|---|
| New York | 2XXX | 2XXX | 202 | 8 202 2XXX |
| SFO | 8XXX | 7XXX | 203 | 8 203 7XXX |
| RTP | 1XX | 11XX | 204 | 8 204 11XX |
Le stringhe di selezione a sette cifre composte su un dispositivo che utilizza il piano di selezione statunitense si sovrappongono a uno schema a sette cifre per la selezione locale nel piano di selezione statunitense precaricato. Per evitare sovrapposizioni tra le abitudini di chiamata in rete e fuori rete (PSTN), in quella sede può essere utilizzato un codice di accesso esterno obbligatorio. Se lo schema di numerazione aziendale esistente e la corrispondente composizione abbreviata inter-sede si sovrappongono ai modelli della composizione nazionale, durante la transizione allo schema di numerazione, per evitare sovrapposizioni, è possibile anche modificarlo in una forma più lunga o più breve. Il modo più semplice per ottenere questo risultato è aggiungere una cifra di riempimento aggiuntiva allo schema di numerazione. Il nuovo schema di composizione inter-sito più lungo deve essere adottato solo dagli utenti già migrati a . Gli utenti ancora connessi possono continuare a comporre sette cifre. In questo caso, il piano di selezione aziendale deve assicurarsi che la composizione abbreviata a sette cifre da Unified CM venga trasformata in +E.164 o al formato di composizione abbreviata implementato su . Questa operazione deve essere eseguita prima di inviare la chiamata al gateway locale.
La tabella Transizione della composizione a sette cifre mostra un esempio di questa rinumerazione. In questo esempio, la chiamata abbreviata tra siti utilizza la cifra di controllo 8 seguita da un prefisso di sito a due cifre e da un interno a quattro cifre. Per evitare la chiamata inter-sede abbreviata a sette cifre per le posizioni su , i codici sito possono essere facilmente modificati in tre cifre anteponendo una cifra di riempimento arbitraria (8 nell'esempio) ai codici sito a due cifre utilizzati in in modo che la chiamata inter-sede dai telefoni utilizzi la cifra di controllo 8 seguita dalla cifra di riempimento 8, il vecchio codice sito a due cifre e l'interno a quattro cifre. Gli utenti non devono ricordare i nuovi codici sito; devono solo ricordarsi di usare 88 come prefisso per le chiamate inter-sito invece di 8 su .
| Sito | Interni | Codice sito | Gamma Enterprise | Sito ode | Angelo aziendale |
| New York | 2XXX | 22 | 8 22 2XXX | 822 | 8 822 2XXX |
| SFO | 8XXX | 23 | 8 23 7XXX | 823 | 8 823 7XXX |
| RTP | 1XXX | 24 | 8 24 11XX | 824 | 8 824 11XX |
In uno scenario con diversi formati di numeri aziendali e se i numeri aziendali vengono presentati come informazioni sul chiamante per le chiamate da a (ad esempio, chiamate da dispositivi senza DID), è importante implementare anche una mappatura tra i diversi formati di numeri per le informazioni sul chiamante per garantire il funzionamento della richiamata. Questa mappatura può essere ottenuta utilizzando il modello di trasformazione della parte chiamante sul trunk tra e il gateway locale.
Registrazione
Una soluzione di registrazione delle chiamate ben progettata richiede un'attenta valutazione di diversi elementi progettuali chiave per garantire che sia in linea con gli obiettivi organizzativi, i requisiti normativi e i vincoli tecnici. Due delle decisioni più critiche riguardano la selezione del fornitore e la selezione della regione, entrambe le quali potrebbero dover essere adattate a livello globale e modificate in sedi specifiche, in base alle esigenze aziendali.
1. Selezione del fornitore di registrazione delle chiamate
La scelta del fornitore di registrazione delle chiamate più adatto è fondamentale per raggiungere gli obiettivi aziendali e garantire l'allineamento delle funzionalità in tutta l'organizzazione:
-
Selezione del fornitore globale: Le organizzazioni in genere designano un fornitore primario di registrazione delle chiamate a livello globale, garantendo coerenza nel set di funzionalità, conformità e supporto in tutte le sedi
-
Override basati sulla posizione: In scenari in cui siti o regioni specifici hanno esigenze aziendali o requisiti normativi unici, potrebbe essere necessario ignorare la selezione del fornitore globale e specificare fornitori alternativi per tali sedi. Questa flessibilità supporta diversi mandati di conformità e diverse esigenze operative locali
-
Requisiti aziendali: La scelta del fornitore dovrebbe essere guidata da una valutazione dei fattori trainanti aziendali quali la conformità normativa (ad esempio: MiFID II, HIPAA), la garanzia della qualità, la risoluzione delle controversie o le esigenze di formazione
-
Disponibilità delle funzionalità: I provider devono essere valutati in base alla loro capacità di fornire le funzionalità richieste, come monitoraggio in tempo reale, capacità di ricerca e riproduzione, crittografia, criteri di conservazione, integrazione con piattaforme di analisi e supporto per diversi tipi di chiamate (in entrata, in uscita, interne).
2. Selezione della regione
Determinare la regione in cui vengono archiviate ed elaborate le registrazioni delle chiamate è fondamentale per la conformità e le prestazioni:
-
Selezione della regione globale: Per impostazione predefinita, le organizzazioni possono scegliere una singola regione per l'archiviazione delle registrazioni delle chiamate per semplificare la gestione e la governance
-
Sostituzioni regionali basate sulla posizione: Laddove le leggi sulla residenza dei dati o le politiche aziendali lo richiedano, potrebbe essere necessario ignorare l'impostazione della regione globale per posizioni specifiche, assicurando che le registrazioni delle chiamate vengano archiviate ed elaborate entro i confini geografici richiesti.
-
Requisiti di residenza dei dati: La progettazione deve tenere conto delle normative internazionali e locali sulla protezione dei dati (come GDPR, CCPA o mandati specifici per Paese) che possono stabilire dove e come conservare le registrazioni delle chiamate.
Un altro aspetto critico da considerare durante la pianificazione e la progettazione di una soluzione di registrazione delle chiamate è la stima dei requisiti di archiviazione. Prevedere con precisione le esigenze di storage è essenziale per garantire che sia disponibile una capacità sufficiente a supportare le operazioni aziendali in corso, mantenere la conformità ed evitare interruzioni del servizio.
Per determinare la domanda di stoccaggio prevista, è necessario considerare diversi parametri chiave:
-
Volume delle chiamate registrate: Valutare il numero previsto di chiamate che verranno registrate in un dato intervallo di tempo (ad esempio, al giorno, alla settimana o al mese). Ciò include non solo le chiamate esterne ma anche le comunicazioni interne, se richiesto dalla politica aziendale o dai mandati normativi
-
Durata media della chiamata: Calcola la durata tipica delle chiamate registrate, poiché le chiamate più lunghe consumeranno più spazio di archiviazione. Anche le variazioni nella durata delle chiamate tra diversi reparti o gruppi di utenti dovrebbero essere considerate nella stima
-
Periodo di conservazione: Definire il periodo di tempo per cui le registrazioni devono essere conservate, che spesso è imposto da policy aziendali o normative esterne (ad esempio standard di conformità specifici del settore). Periodi di conservazione più lunghi aumenteranno i requisiti di archiviazione complessivi
-
Proiezioni di crescita: Si consideri la crescita prevista del volume delle chiamate o l'ampliamento dell'ambito di registrazione, che potrebbe derivare dalla crescita aziendale, da nuovi requisiti normativi o dall'inserimento di ulteriori utenti o sedi.
Analizzando attentamente questi parametri, le organizzazioni possono sviluppare una strategia di archiviazione solida che garantisca scalabilità, economicità e conformità normativa per la propria soluzione di registrazione delle chiamate. Si consiglia inoltre di rivedere e modificare regolarmente le allocazioni di spazio di archiviazione in base all'evoluzione dei modelli di utilizzo nel tempo.
Chiamata di emergenza
L'obbligo di instradare una chiamata di emergenza al centro di controllo appropriato è un requisito per qualsiasi servizio di chiamata che offra il servizio PSTN. Con , l'instradamento delle chiamate di emergenza è nativo della soluzione e include il supporto per tutti i numeri di emergenza nazionali nei paesi che supportano. L'instradamento di una chiamata di emergenza si basa sulla posizione definita all'interno e sul metodo di accesso PSTN della posizione. I numeri di emergenza sono predefiniti e specifici per il Paese in cui vengono distribuiti gli utenti e i dispositivi.
Esistono due metodi per effettuare chiamate di emergenza in . Esiste un servizio di instradamento delle chiamate di emergenza di base e un servizio di instradamento delle chiamate di emergenza avanzato. Il servizio di base di instradamento delle chiamate di emergenza utilizzerà un numero selezionato dall'amministratore per identificare la posizione e il percorso della chiamata per raggiungere i servizi di emergenza. Per le chiamate di emergenza di base, il percorso della chiamata avviene in genere tramite l'opzione PSTN del cliente per quella posizione. dispone inoltre di un routing avanzato delle chiamate di emergenza progettato per le distribuzioni negli Stati Uniti e in Canada che hanno requisiti di conformità normativa che richiedono l'uso di un fornitore nazionale per inoltrare le chiamate di emergenza al centro di smistamento corretto.
Tutti i clienti dovrebbero implementare almeno la configurazione di base per le chiamate di emergenza. Le chiamate di emergenza di base richiedono che almeno un cliente sia proprietario +E.164 numero da assegnare a ciascuna posizione definita in . Per le chiamate di emergenza di base, ogni località sarà definita da un indirizzo stradale a cui verranno inviati i servizi di polizia, vigili del fuoco o ambulanza in caso di emergenza. Nella maggior parte dei casi, il numero principale della posizione è la scelta migliore per rappresentare la posizione fisica dell'emergenza. Tipicamente, l'assegnazione dell'indirizzo al +E.164 il numero è coordinato con il provider PSTN. Le immagini sottostanti mostrano l'assegnazione del numero principale da utilizzare come numero di richiamata di emergenza per la sede di Richardson.
Nella maggior parte dei casi, l'indirizzo di un edificio è sufficiente come indirizzo di spedizione per la sede. Tuttavia, se sono necessari ulteriori dettagli sulla posizione di utenti o dispositivi specifici, un amministratore può utilizzare lo stesso processo descritto sopra e assegnare tali dispositivi a un indirizzo specifico o a una posizione più precisa all'interno dell'indirizzo (ad esempio un piano o una stanza). In Gestione utenti in , la scheda Chiamata consente di utilizzare un numero specifico affinché un utente e i suoi dispositivi ottengano un indirizzo di spedizione specifico. Le immagini seguenti illustrano come assegnare un numero specifico a un dispositivo. L'amministratore è tenuto a garantire che al numero utilizzato dal dispositivo venga assegnato l'indirizzo di spedizione corretto. L'assegnazione dell'indirizzo avviene solitamente tramite il provider PSTN di quella località.
Per le implementazioni di telefonia basate negli Stati Uniti che devono fornire soluzioni di chiamata di emergenza avanzate, utilizza Horizon Mobility di RedSky integrato per l'instradamento delle chiamate di emergenza. Quando si utilizza RedSky per l'instradamento delle chiamate, un amministratore deve registrarsi per un account tramite Cisco e configurare le informazioni appropriate in Chiamata -> Impostazioni del servizio per abilitare questa funzione. Una volta abilitato il servizio RedSky a livello di sistema, un amministratore abiliterà il servizio RedSky a livello di ciascuna posizione. L'abilitazione delle chiamate di emergenza avanzate in una posizione attiverà il servizio per tutti i dispositivi assegnati a quella posizione. I dispositivi che supportano le chiamate di emergenza avanzate sono i telefoni Cisco MPP, i telefoni Cisco PhoneOS e i telefoni Cisco .
Sono disponibili due impostazioni per abilitare le chiamate di emergenza avanzate in una posizione. Consenti a RedSky di ricevere informazioni sulla connettività di rete e chiamate di prova dovrebbe essere utilizzato per verificare che la configurazione di RedSky per i mapping dei dispositivi e delle infrastrutture sia corretta. Questa impostazione consente anche di effettuare chiamate di prova al 933 per verificare la posizione utilizzando il sistema IVR di RedSky per leggere la posizione del chiamante. Sebbene questo documento non tratti la configurazione di RedSky per il monitoraggio della posizione, un amministratore dovrebbe SEMPRE testare la propria posizione prima di attivare le chiamate di emergenza da instradare a RedSky. Una volta completati i test e verificata l'accuratezza, l'amministratore indirizzerà le chiamate a RedSky attivando l'opzione di inoltro delle chiamate di emergenza a RedSky. Questa opzione indirizzerà tutte le chiamate di emergenza per la posizione a RedSky, che le recapiterà al centro di risposta della posizione.
Le impostazioni di chiamata di emergenza avanzata si applicano anche ai clienti in sede e fuori sede. Quando sono in sede, possono essere monitorati allo stesso modo in cui vengono monitorati i telefoni fissi. Quando è fuori sede, l'utente potrà impostare la propria posizione in modo dinamico direttamente all'interno del file . Per maggiori informazioni sulle chiamate di emergenza, vedere Chiamate di emergenza migliorate per .
Gestione delle licenze
Esistono diverse opzioni per assegnare le licenze agli utenti.
Assegnazione manuale tramite
Gli amministratori assegnano manualmente le licenze ai singoli utenti tramite l'interfaccia.
Gli amministratori possono modificare le licenze di servizio per i singoli utenti e assegnare direttamente le licenze di chiamata.
Modelli di assegnazione automatica delle licenze
Utilizza i modelli di assegnazione delle licenze per assegnare automaticamente le licenze agli utenti in base alle impostazioni del gruppo o dell'organizzazione.
La licenza automatica può essere eseguita tramite la sincronizzazione delle directory o gli aggiornamenti manuali degli utenti, ma gli utenti devono avere un account valido +E.164 numero di telefono formattato e i numeri di telefono devono esistere in una posizione prima del provisioning dell'utente. Se le condizioni non vengono soddisfatte (ad esempio, formato del numero di telefono non valido), le licenze non verranno assegnate.
Assegnazione in blocco tramite modello CSV
Carica un file CSV con i dettagli dell'utente e le assegnazioni delle licenze per aggiungere o modificare più utenti contemporaneamente.
L'importazione CSV supporta l'aggiunta di un massimo di 20.000 utenti e l'assegnazione di licenze, ma le licenze richiedono campi specifici come numero di telefono ed interno.
Assegnazione basata su API
Utilizzare le API per assegnare le licenze e gestire gli utenti in modo programmatico.
supporta le operazioni API per la gestione di utenti e licenze (API People, SCIM 2.0 e Licenses), che possono essere sfruttate per l'automazione dell'assegnazione delle licenze. L'API Licenze consente l'assegnazione simultanea di licenze, numeri di telefono ed interni.
| Metodo di assegnazione | Professionisti | Contro |
|---|---|---|
| Manuale attraverso | Semplice per pochi utenti. Consente un controllo preciso e granulare sull'assegnazione delle licenze. | Non scalabile, richiede molto tempo Soggetto a errori umani durante l'inserimento manuale. |
| Modelli di licenza automatici | Scalabile Riduce gli errori manuali Può essere applicato a utenti nuovi ed esistenti. | Richiede numeri di telefono e posizioni validi. Più complesso da configurare Richiede inoltre gruppi di utenti per gruppo di utenti con requisiti di licenza equivalenti. |
| Caricamento CSV in blocco | Efficiente per grandi gruppi di utenti Consente l'assegnazione simultanea di licenze, numeri di telefono ed interni. | Richiede un'attenta formattazione CSV Possibili errori se i numeri di telefono o gli interni sono mancanti o errati. |
| Assegnazione basata su API | Automatizzabile, flessibile. Consente l'assegnazione simultanea di licenze, numeri di telefono ed interni. | Richiede conoscenze di sviluppo e API. |
La tabella Opzioni di provisioning utente - riepilogo riassume le opzioni di provisioning utente e i relativi pro e contro. Questa panoramica aiuta a scegliere il metodo di assegnazione delle licenze migliore in base alle dimensioni dell'organizzazione del cliente, alle capacità di automazione e ai processi e requisiti di provisioning degli utenti.
Ove possibile, Cisco consiglia di assegnare le licenze di chiamata utilizzando modelli di licenza. Ciò richiede che per ogni gruppo di utenti che necessita di un set univoco di licenze (ad esempio: Standard vs. Professional) esista un gruppo con le rispettive appartenenze. Come discusso nelle sezioni Gruppi di utenti, i gruppi di utenti possono essere definiti manualmente o sincronizzati da una directory aziendale. È possibile combinare entrambi gli approcci.
Gli utenti appartenenti a più gruppi ottengono le licenze da tutte le assegnazioni applicate a tutti i loro gruppi. Ciò consente di utilizzare gruppi di sicurezza specifici per licenza nella directory aziendale per gestire l'assegnazione delle licenze, dove l'assegnazione delle licenze utente risultante è controllata dall'unione delle appartenenze ai gruppi.
Per ulteriori informazioni, vedere Impostare le assegnazioni automatiche delle licenze in Control Hub e Impostare modelli di assegnazione automatica delle licenze per gli utenti di Webex Calling.
Requisiti di licenza
Questa sezione riguarda solo le licenze correlate. Altri tipi di licenza (ad esempio, registrazione dispositivi Webex, messaggistica, riunioni) non sono coperti. Come parte del processo di progettazione è necessario determinare i requisiti della licenza. È necessario calcolare il numero di licenze per i seguenti tipi di licenza:
-
Standard: numero di singoli utenti che necessitano di funzionalità di telefonia standard.
-
Professionale: numero di utenti e spazi di lavoro che richiedono funzionalità di telefonia avanzate. Le linee virtuali e la segreteria telefonica di gruppo hanno diritto a un 1:1 rapporto per ogni licenza professionale. Pertanto, nei rari casi in cui il numero di linee virtuali o di segreterie telefoniche di gruppo richieste supera il numero di utenti e di spazi di lavoro che necessitano di funzionalità di telefonia avanzate, è necessario prendere in considerazione licenze professionali aggiuntive.
-
Spazio di lavoro per area comune: numero di postazioni di uso condiviso o di aree comuni che richiedono funzionalità di chiamata standard.
-
Assistenza clienti: numero di agenti e supervisori che necessitano delle funzionalità di Assistenza clienti. L'assistenza clienti include la licenza Professional.
-
Elenco percorsi chiamate: numero di chiamate PSTN Cloud Connected richieste tra utenti in sede and/or applicazioni specializzate di terze parti in sede.
-
Console dell'operatore: numero di utenti che necessitano di accedere al client della console dell'operatore.
-
Piano di chiamata Cisco (piano di chiamata in uscita): numero di utenti che necessitano di un numero PSTN and/or accesso alle chiamate PSTN in uscita per il servizio Cisco PSTN.
Non esiste un tipo di licenza dedicato per gli spazi di lavoro professionali. Gli spazi di lavoro professionali richiedono una licenza Professional.
Gli spazi di lavoro solo hot-desking offrono il servizio di host hot-desking e chiamate di emergenza dall'host hot-desking e non richiedono alcuna licenza. Per ulteriori informazioni, vedere Aggiungere e gestire dispositivi solo hot desk.
Per determinare il tipo di licenza richiesto per ciascun utente e area di lavoro in base alle funzionalità necessarie, vedere Funzionalità disponibili in base al tipo di licenza per Webex Calling.
Per distinguere tra le funzionalità offerte dalle code di chiamata combinate con la licenza professionale rispetto all'assistenza clienti, vedere Confronto tra le funzionalità di coda di chiamata e assistenza clienti di Webex Calling.
Provisioning utenti
Quando si effettua il provisioning degli utenti in Webex, sono disponibili diverse opzioni, ciascuna adatta a diverse esigenze organizzative e ambienti:
-
Provisioning manuale: Gli amministratori possono aggiungere e gestire singoli utenti direttamente all'interno di . Questo metodo è semplice ma è più adatto alle piccole organizzazioni o alle modifiche limitate degli utenti.
-
Provisioning in blocco tramite CSV: Per basi di utenti più ampie, gli amministratori possono importare e aggiornare gli utenti in blocco caricando file CSV in formato . Ciò consente la gestione efficiente di migliaia di utenti contemporaneamente.
- Opzioni di sincronizzazione della directory:
Connettore directory: Si tratta di uno strumento di sincronizzazione automatica utilizzato negli ambienti Microsoft Active Directory. Sincronizza account utente, gruppi e attributi in base a una pianificazione (oraria, giornaliera o settimanale). Supporta configurazioni Active Directory multi-dominio e multi-foresta e può sincronizzare immagini di profilo e oggetti room.
App guidata ID di accesso (Azure AD): Progettato per le organizzazioni che utilizzano Microsoft Entra ID (Azure AD), questo metodo fornisce la sincronizzazione automatica e quasi in tempo reale degli account utente e degli attributi direttamente da Entra ID a . È completamente gestito internamente e richiede una configurazione minima.
Applicazioni SCIM 2.0: Per gli ambienti non Microsoft o altri provider di identità come Okta o Duo, le app di sincronizzazione basate su SCIM consentono il provisioning e il deprovisioning automatico degli utenti con mappatura degli attributi e sincronizzazione dei gruppi.
-
Sincronizzazione utente CM unificata: Questa opzione consente di creare account utente basati su utenti finali esistenti tramite la sincronizzazione da a . Ciò richiede che Cloud Connected UC (CCUC) sia in esecuzione sui cluster locali. Tuttavia, in genere si consiglia di sincronizzare gli utenti da una directory cloud centralizzata come Entra ID anziché direttamente da .
-
Provisioning API: Per il provisioning degli utenti è possibile utilizzare le API pubbliche (People, SCIM 2.0). Il vantaggio principale dell'utilizzo delle API è la possibilità di integrare il provisioning degli utenti con altri sistemi aziendali.
Questa panoramica e tabella illustrano le principali opzioni di provisioning degli utenti, i relativi vantaggi e limiti, per aiutarti a scegliere l'approccio migliore per le esigenze della tua organizzazione.Tabella 6. Opzioni di provisioning utente per Metodo di provisioning Descrizione Professionisti Contro Manuale Create/manage utenti individualmente in Semplice per pochi utenti; nessuna infrastruttura necessaria Non scalabile; richiede molto tempo per molti utenti In blocco (file CSV) Import/update utenti in blocco tramite CSV in Efficiente per i gruppi; non è richiesta alcuna codifica Preparazione manuale del CSV; meno dinamico Persone e API SCIM 2.0 Gestione programmatica degli utenti tramite API Webex Flessibile; supporta l'automazione e l'integrazione Richiede sviluppo e infrastrutture Sincronizzazione rubriche Sincronizzazione automatica da AD, Entra ID, app SCIM, Unified CM Automatizza il ciclo di vita; supporta il filtraggio e la mappatura Complessità di configurazione: alcune delle opzioni hanno funzionalità limitate o richiedono infrastrutture
Gruppi di utenti
La gestione dei gruppi di utenti consente agli amministratori di organizzare gli utenti in gruppi per una gestione efficiente in blocco di licenze, impostazioni e risorse. I gruppi aiutano a semplificare l'amministrazione applicando criteri, licenze e modelli di impostazioni a più utenti contemporaneamente, anziché gestirli singolarmente.
La gestione dei gruppi di utenti offre numerosi vantaggi, tra cui:
-
Amministrazione semplificata: Gestisci licenze, impostazioni e policy per più utenti contemporaneamente.
-
Coerenza: Applicare impostazioni e licenze uniformi a tutti gli utenti dello stesso gruppo.
-
Scalabilità: Supporta fino a 250.000 membri per gruppo.
-
Integrazione: Sincronizza i gruppi da Microsoft Entra ID (Azure AD) o Active Directory per la gestione automatizzata di utenti e gruppi.
-
Flessibilità: Crea gruppi locali o sincronizza i gruppi di sicurezza; gestisci l'appartenenza ai gruppi manualmente o tramite file CSV.
-
Assegnazione delle risorse: Controlla l'accesso alle app e ai servizi incorporati in base all'appartenenza al gruppo.
I principali casi d'uso per i gruppi di utenti durante il provisioning sono:
-
Assegnazioni di licenza: Assegna licenze ai gruppi per fornire automaticamente servizi quali chiamate, riunioni, messaggistica o servizi ibridi ai membri del gruppo.
-
Modelli di impostazioni: Applica raccolte di impostazioni di servizio (ad esempio, messaggistica, riunione, chiamata) ai gruppi per un'esperienza utente coerente.
-
Gestione utenti in blocco: Aggiungi o rimuovi utenti in blocco tramite file CSV o sincronizzazione delle directory.
-
Automazione e integrazione: Utilizza API o sincronizzazione delle directory per la gestione automatizzata del ciclo di vita di utenti e gruppi.
La tabella seguente riassume le diverse opzioni per gestire i gruppi di utenti e la gestione dei gruppi in .
| Opzione | Descrizione | Professionisti | Contro |
|---|---|---|---|
| provisioning di gruppo (gruppi) | Crea e gestisci gruppi direttamente in . Add/remove membri manualmente o tramite CSV. | Controllo completo sull'appartenenza al gruppo Applicazione immediata di licenze e modelli Facile da creare e modificare gruppi |
Aggiornamenti manuali richiesti Rischio di errori nei caricamenti manuali di CSV Nessuna sincronizzazione automatica con directory esterne |
| Gruppi sincronizzati da Entra ID (Azure AD) o Active Directory | Sincronizza automaticamente i gruppi di sicurezza e le appartenenze dai servizi di directory esterni. | La sincronizzazione automatica riduce il lavoro manuale Garantisce la coerenza con la directory aziendale Supporta grandi organizzazioni |
Impossibile modificare l'appartenenza al gruppo in Ritardo di sincronizzazione fino a 12 ore I gruppi nidificati richiedono la selezione manuale |
| Gruppi e API SCIM 2.0 (Gruppi) | Utilizzare i gruppi o l'API SCIM 2.0 per la gestione programmatica dei gruppi e delle appartenenze | Automazione e integrazione con altri sistemi Scalabile per ambienti grandi o complessi |
Richiede uno sforzo di sviluppo La complessità dipende dall'utilizzo dell'API |
Sebbene i gruppi sincronizzati garantiscano coerenza e offrano un unico punto di amministrazione, è possibile un approccio ibrido che combina gruppi sincronizzati e gruppi (gestiti nell'hub di controllo o tramite API). Ad esempio, i gruppi per l'assegnazione delle licenze potrebbero essere gruppi sincronizzati e un set separato di gruppi potrebbe essere utilizzato per l'assegnazione di modelli utente e di chiamata.
Questo approccio completo alla gestione dei gruppi di utenti consente alle organizzazioni di gestire in modo efficiente le licenze, le impostazioni e le policy degli utenti, garantendo esperienze di collaborazione coerenti e scalabili.
Approccio consigliato durante la migrazione da a
La fonte dati principale per gli utenti è il database, che contiene le informazioni dell'utente finale. Tuttavia, in genere non è la fonte autorevole per la gestione dell'identità degli utenti e, cosa ancora più importante, verrà disattivato alla fine della transizione e pertanto è escluso come fonte autorevole a lungo termine per le informazioni sull'identità.
Cisco consiglia di utilizzare una directory cloud centralizzata, ad esempio Microsoft Entra ID (Azure AD), come unica fonte attendibile per le identità degli utenti. La sincronizzazione degli utenti dall'ID Entra garantisce coerenza, semplifica la gestione e supporta le funzionalità Single Sign-On (SSO).
Per garantire che tutti gli utenti siano presenti anche nell'ID Entra, le organizzazioni devono verificare che gli account utente corrispondano agli account nell'ID Entra. Ciò può essere fatto esportando gli elenchi degli utenti e confrontandoli con gli elenchi degli utenti Entra ID.
In sintesi, il metodo di provisioning consigliato consiste nel sincronizzare gli utenti dall'ID Microsoft Entra (Azure AD) a Webex utilizzando la procedura guidata di Azure AD o le app SCIM. Il provisioning in blocco manuale e CSV è disponibile come metodi supplementari, ma è meno scalabile e più soggetto a errori per le grandi organizzazioni. Garantire che Entra ID sia la fonte autorevole e che tutti gli utenti esistano in Entra ID è fondamentale per una migrazione riuscita e un'esperienza utente coerente in tutti gli ambienti.
La transizione da un servizio di directory locale, come Active Directory, a un servizio di directory cloud, come Entra ID (Azure ID), è indipendente dalla transizione della chiamata. Cisco consiglia di completare la transizione a un servizio di directory cloud prima di iniziare la transizione delle chiamate.
Progettazione di gruppi di utenti
Dopo aver trasferito la directory aziendale da locale al cloud, raccogliere i gruppi di utenti richiesti in base ai requisiti di licenza e di modello delle funzionalità. Per ogni documento di gruppo:
-
Nome gruppo: nome univoco del gruppo.
-
Licenze: licenze da assegnare a questo gruppo (se presenti) e ambito (le licenze devono essere assegnate agli utenti esistenti o solo ai nuovi utenti)
-
Modelli di impostazioni: Modelli di chiamata utente e app Webex.
-
Sincronizzazione directory: Questo gruppo verrà sincronizzato dalla directory aziendale oppure si tratta di un gruppo Webex locale predisposto in Control Hub o tramite un'API.
-
Descrizione: come verrà utilizzato questo gruppo e quali utenti dovrebbero esserne membri
Questi dettagli verranno utilizzati in seguito, durante la fase di implementazione, per creare gruppi locali o gruppi nella directory aziendale e gestire l'appartenenza degli utenti ai gruppi.
Single Sign-On (SSO)
Cisco consiglia l'uso di SSO per l'autenticazione degli utenti. L'utilizzo dell'SSO presenta alcuni vantaggi interessanti, tra cui:
-
Autenticazione utente semplificata: Gli utenti possono effettuare l'accesso una sola volta utilizzando le proprie credenziali aziendali (ad esempio da Azure ID) per accedere ad altre applicazioni integrate, eliminando la necessità di più password e riducendo le richieste di accesso. Ciò aumenta la sicurezza garantendo che le password aziendali non vengano mai memorizzate o trasmesse dopo l'autenticazione.
-
Gestione semplificata degli utenti: Automatizza la creazione, l'aggiornamento e la disattivazione degli account utente in base alle modifiche nella directory aziendale, riducendo le spese amministrative e garantendo l'accesso solo agli utenti autorizzati.
-
Sicurezza migliorata: SSO riduce l'affaticamento da password e il rischio di violazioni correlate alle password centralizzando l'autenticazione tramite provider di identità (IdP) affidabili.
-
Facile integrazione dell'autenticazione a più fattori (MFA): L'MFA può essere facilmente supportato tramite una soluzione di Identity Access Management come Cisco Duo o tramite il supporto MFA dell'IdP.
Esistono diverse opzioni per implementare l'SSO per i servizi:
-
SSO basato su SAML 2.0: Protocollo principale supportato per l'integrazione SSO, che consente lo scambio sicuro di informazioni di autenticazione tra l'IdP e il fornitore di servizi.
-
Connessione OpenID (OIDC): Supportato come protocollo di autenticazione moderno alternativo per l'integrazione SSO.
-
Identità Webex: Supportato anche come opzione di provider di identità.
L'SSO viene configurato e gestito centralmente tramite , richiedendo lo scambio di metadati tra e l'IdP scelto.
Dopo la configurazione, è possibile testare l'SSO prima dell'attivazione per garantirne la corretta configurazione.
Cisco supporta l'integrazione con numerosi IdP e sistemi di gestione delle identità (IAM) testati e comunemente utilizzati, tra cui:
-
Cisco Duo
-
Okta
-
Servizi federativi di Microsoft Active Directory (ADFS)
-
Microsoft Azure
-
PingFederate
-
OpenAM
-
F5 BIG-IP.
Questi IdP sono conformi agli standard SAML 2.0 o OpenID Connect e sono stati convalidati per la compatibilità con le soluzioni di collaborazione Cisco.
Supporto IdP multiplo
consente alle organizzazioni di configurare SSO con più IdP per adattarsi ad ambienti IT complessi come fusioni, acquisizioni o reparti IT decentralizzati in cui gruppi diversi utilizzano IdP diversi. Il supporto IdP multipli può essere implementato utilizzando la funzionalità IdP multipli oppure tramite l'integrazione di un sistema IAM aziendale come Cisco Duo.
Il supporto multi-Identity Provider (IdP) di affronta diversi casi d'uso chiave in cui le organizzazioni necessitano di un'autenticazione flessibile e sicura in diversi ambienti IT:
1. Fusione e acquisizioni
Quando le aziende si fondono o ne acquisiscono altre, spesso hanno infrastrutture IT separate e IdP distinti che non possono federarsi. Il supporto di più IdP consente agli utenti di entrambe le organizzazioni di autenticarsi e collaborare in modo sicuro senza dover unificare immediatamente i propri sistemi di identità.
2. Più dipartimenti IT indipendenti
Le grandi organizzazioni o le istituzioni governative possono avere più dipartimenti IT indipendenti, ognuno dei quali gestisce il proprio IdP. La funzionalità IdP multipli consente a questi dipartimenti di gestire i propri sistemi di autenticazione, consentendo al contempo agli utenti di accedere senza problemi.
3. Diversi gruppi di utenti o domini
Le organizzazioni con vari gruppi di utenti (ad esempio, dipendenti o collaboratori) o più domini di posta elettronica possono configurare regole di routing per indirizzare le richieste di autenticazione all'IdP appropriato in base all'appartenenza al dominio o al gruppo. Ciò supporta criteri di accesso differenziati e controlli di sicurezza.
4. Supporto per vari protocolli di autenticazione
supporta gli IdP SAML e OpenID Connect (OIDC), consentendo alle organizzazioni di integrare diversi tipi di provider di identità in base alle loro infrastrutture esistenti e ai requisiti di sicurezza.
5. Maggiore sicurezza e conformità
Abilitando più IdP, le organizzazioni possono implementare meccanismi di autenticazione più efficaci, tra cui l'autenticazione a più fattori (MFA) tramite integrazioni come Duo, e applicare policy di sicurezza coerenti su diverse basi di utenti.
6. Esperienza utente semplificata
Gli utenti possono autenticarsi utilizzando le credenziali esistenti dei rispettivi IdP, garantendo un'esperienza di accesso unificata nonostante la complessità di base dei molteplici sistemi di identità.
Sebbene il supporto di più IdP offra flessibilità, richiede un attento coordinamento tra i team di sicurezza e identità per mantenere policy di sicurezza coerenti ed evitare potenziali vulnerabilità.
Duo MFA con SSO per
Duo Access Gateway (DAG) può autenticare gli utenti utilizzando directory esistenti in locale o basate su cloud, come Active Directory (AD) e OpenLDAP. Supporta inoltre l'integrazione con altri provider di identità come Microsoft ADFS, Microsoft Azure, Okta, OneLogin, CAS e Shibboleth. Questa flessibilità consente alle organizzazioni di utilizzare la propria attuale infrastruttura di directory per Webex SSO con Duo MFA.
Duo agisce come un livello di autenticazione avanzata in aggiunta all'autenticazione della directory primaria. Funziona come un fornitore di identità (IdP) utilizzando SAML 2.0 per applicare l'autenticazione a due fattori (2FA) prima di concedere l'accesso a . Duo valuta il contesto dell'utente, del dispositivo e della rete in base a criteri configurabili per consentire o negare l'accesso, migliorando la sicurezza oltre il semplice nome utente e password. Duo fornisce inoltre controlli flessibili delle policy, come ad esempio la richiesta di MFA a ogni accesso per alcune app e meno frequentemente per altre.
I vantaggi di Cisco Duo includono:
-
Sicurezza avanzata: Aggiunge un'autenticazione a più fattori resistente al phishing per proteggere l'accesso, riducendo il rischio di password compromesse.
-
Politiche flessibili: Consente un controllo granulare sui requisiti di autenticazione per applicazione o gruppo di utenti.
-
Integrazione con directory esistenti: Supporta AD on-premise, OpenLDAP, directory cloud e vari provider SSO, riducendo al minimo le modifiche all'infrastruttura.
-
Comodità per l'utente: Supporta Single Sign-On (SSO) per ridurre l'affaticamento da password consentendo agli utenti di effettuare l'accesso una sola volta e di accedere a più risorse in modo sicuro.
-
Endpoint attendibili: Supporta l'affidabilità dei dispositivi per i client su Windows e macOS, migliorando la sicurezza.
-
Iscrizione self-service: La registrazione in linea e il prompt Duo migliorano l'esperienza utente durante la configurazione MFA.
Duo MFA con SSO sfrutta le directory esistenti come Active Directory e OpenLDAP o i provider di identità cloud per autenticare gli utenti. Il ruolo di Duo è quello di fornire un secondo fattore di autenticazione forte e basato su policy, integrato tramite SAML 2.0, migliorando la sicurezza e mantenendo la praticità per l'utente tramite SSO. I vantaggi includono un migliore livello di sicurezza, un'applicazione flessibile delle policy, un'integrazione fluida e una migliore esperienza utente.
Cisco consiglia di implementare l'SSO per gli utenti. Per una maggiore sicurezza si consiglia l'integrazione con Cisco Duo.
La strategia Enterprise IAM e SSO deve essere implementata prima di iniziare la transizione da a .
Funzionalità
dispone di una serie completa di funzionalità di base incluse nel servizio. Sono incluse numerose funzionalità di chiamata di livello aziendale disponibili da molti anni. Potresti non vedere una parità del 100% tra funzionalità e caratteristiche, tuttavia, come puoi vedere nella figura sottostante, le principali funzionalità di chiamata sono disponibili in .
Oltre alle numerose funzionalità utente, la piattaforma include anche le funzionalità di sistema principali. Tra queste rientrano funzioni quali risponditori automatici, code di chiamata, parcheggio delle chiamate, ecc. È possibile visualizzare tutte le funzionalità del sistema principale disponibili in Servizio → Chiamata → Funzionalità come illustrato nella figura Funzionalità principali di Webex Calling.
Partecipante automatico
L'Auto Attendant consente di 24/7 automazione della gestione delle chiamate in entrata, che consente una gestione efficiente delle chiamate senza la necessità che una persona risponda a ogni chiamata.
Il risponditore automatico risponde alle chiamate in arrivo e fornisce al chiamante un menu di opzioni su dove desidera indirizzare la chiamata. Potrebbe trattarsi di una persona, di una casella vocale o di un servizio di chiamata (ad esempio, la coda di chiamata). Il chiamante utilizza il tastierino numerico del telefono per inserire il numero dal menu del risponditore automatico.
Il centralino automatico supporta le seguenti funzionalità principali:
-
Orari di lavoro e dopo l'orario di lavoro
-
Pianificazione festività
-
Opzione di menu di chiamata per indirizzare i tuoi clienti dove devono andare
-
Personalizza i saluti
-
Opzione di chiamata per nome
-
Opzioni di inoltro chiamata
-
Analisi e report di Control Hub.
Per ulteriori informazioni, vedere Gestire gli operatori automatici.
Parcheggio di chiamata
Il parcheggio delle chiamate consente agli utenti di mettere facilmente in attesa una chiamata in modo che un altro utente possa recuperarla facilmente quando è disponibile a rispondervi. Inoltre, consente all'utente che ha risposto alla chiamata originale di effettuare o ricevere altre chiamate mentre la chiamata è parcheggiata.
Sono disponibili due tipi di parcheggi di chiamata in :
-
Parcheggio diretto delle chiamate - consente a qualsiasi utente di parcheggiare una chiamata sull'interno di un altro utente o su un'estensione di parcheggio delle chiamate, come definito dall'amministratore
-
Gruppo di parcheggio chiamate - consente a un gruppo definito di utenti di parcheggiare automaticamente le chiamate sulle destinazioni di parcheggio disponibili definite per il gruppo. Queste destinazioni possono essere gli interni dei membri del gruppo o gli interni del parcheggio delle chiamate.
In base alla configurazione e al tipo di parcheggio, gli utenti possono recuperare le chiamate componendo *88+><extension of parked call>, premendo il tasto di linea associato all'estensione del parcheggio della chiamata o utilizzando un tasto funzione sul proprio telefono IP.
È disponibile un'opzione di richiamo per richiamare una chiamata parcheggiata dopo un periodo di tempo specificato all'utente che ha parcheggiato la chiamata o a un altro utente.
Per ulteriori informazioni, vedere Gestire il parcheggio delle chiamate in Control Hub.
Risposta per assente
La funzione di risposta alle chiamate consente a un amministratore di definire un gruppo di utenti (membri) che possono rispondere a una chiamata sul telefono di un altro membro. Ciò consente all'utente di rispondere alle chiamate quando i suoi colleghi sono occupati e non possono rispondere a una chiamata in arrivo.
Gli utenti di un gruppo devono trovarsi nella stessa posizione.
Per rispondere a una chiamata, gli utenti possono utilizzare il telefono fisso o quello fisso.
-
:
-
Supporta notifiche visive e audio
-
Notifica chiamata in ingresso
-
Basato su FAC (composizione *98) o notifica chiamata di risposta
-
Notifiche di risposta alle chiamate multilinea.
-
-
Telefoni da scrivania:
-
Notifica chiamata in ingresso
-
Suoni acustici e notifiche visive tramite il LED del ricevitore. Il 6821 supporta solo i segnali acustici
-
Quando il tipo di notifica selezionato non è nessuno
-
-
Notifiche di risposta alle chiamate solo per le linee principali.
-
Per ulteriori informazioni, vedere Configurare il gruppo di risposta alle chiamate.
Coda di chiamata
include code di chiamate solo vocali come parte delle sue funzionalità principali e qualsiasi utente con una licenza Professional può far parte di una coda di chiamate, agente o supervisore. Questa funzionalità consente agli utenti di interagire in modo efficiente con i clienti. Le code di chiamata supportano un sottoinsieme di alcune delle funzionalità principali del call center, come code vocali, richiamata, routing basato su competenze o priorità, gestione delle code degli agenti, analisi, reporting, ecc.
La richiesta di Cisco di integrare Microsoft Teams consente agli agenti di accedere alle chiamate in coda e alle funzionalità direttamente dal loro client Microsoft Teams.
Le code di chiamata supportano le seguenti funzionalità chiave:
-
Saluti e messaggi (benvenuto, conforto, sussurro, ecc.)
-
Musica di attesa
-
Richiamata
-
Criteri di instradamento delle code (servizio notturno, festivi, inoltro)
-
Coda degli agenti login/logout
-
Gestione dello stato della coda degli agenti
-
o supporto tramite telefono fisso
-
L'agente supervisore chiama il monitor, l'allenatore, l'intermediario o il subentrante tramite i codici di accesso alle funzionalità (FAC)
-
(accesso amministratore) per:
-
gestione delle code
-
Analisi e reporting di agenti e code
-
Gestione code, agenti e supervisori.
-
Per ulteriori informazioni, vedere Configurare la coda di chiamata.
dispone di una funzionalità aggiuntiva Customer Assist che fornisce funzionalità aggiuntive per la coda delle chiamate e garantisce agli agenti e ai supervisori una migliore esperienza utente all'interno di . Per un confronto tra le funzioni Coda chiamate e Assistenza clienti, vedere Confronto tra le funzioni Coda chiamate e Assistenza clienti di Webex Calling.
Gruppo di ricerca
I gruppi di ricerca consentono di instradare le chiamate in arrivo a un gruppo specifico di utenti tramite uno schema di instradamento delle chiamate predeterminato. In questo modo si garantisce che le chiamate vengano risposte dal gruppo di utenti giusto o che vengano inviate a una segreteria telefonica per un follow-up.
Una grande differenza tra i gruppi di ricerca e le code di chiamata è che le chiamate non vengono messe in coda nei gruppi di ricerca, quindi se nessun utente del gruppo di ricerca è disponibile a rispondere alla chiamata, questa verrà disconnessa, inviata alla segreteria telefonica o inoltrata a un altro numero (utente o servizio).
Per ulteriori informazioni, vedere Gestire i gruppi di ricerca in Control Hub.
Modalità operative
La funzione Modalità operative consente alle aziende di instradare in modo efficiente le chiamate verso diverse destinazioni (utenti, segreteria telefonica, servizi di chiamata come una coda di chiamate). Il luogo e il momento in cui una chiamata viene instradata si basano su una pianificazione oraria e giornaliera e qualsiasi utente può essere autorizzato a gestire queste modalità (pianificazioni) per controllare le modifiche all'instradamento delle chiamate.
Ad esempio, le chiamate a una coda di chiamate possono essere instradate verso un'altra coda di chiamate con agenti in un fuso orario diverso per rispondere alle chiamate fuori orario, durante l'orario lavorativo possono essere instradate verso gli agenti locali e durante le festività possono essere instradate verso la segreteria telefonica per un follow-up dopo il ritorno degli agenti in ufficio.
Un utente autorizzato può passare da uno scenario all'altro (modalità) di inoltro delle chiamate se ha bisogno di modificare la destinazione delle chiamate in arrivo per un determinato periodo di tempo. Questi utenti possono gestire le modalità tramite il loro 6800/7800/8800 Telefoni MPP, telefoni 9800 o nell'Hub utente in Gestisci modalità.
Per ulteriori informazioni, vedere Instradamento delle chiamate in base alle modalità operative in Webex Calling.
Gruppo di risposta
I gruppi di paging consentono agli utenti di effettuare una chiamata unidirezionale per inviare un messaggio audio a un gruppo di utenti. Ogni gruppo può contenere fino a 75 utenti target and/or spazi di lavoro raggiungibili componendo un numero o un'estensione predefiniti.
Quando un utente chiama un gruppo di paging, viene effettuata una chiamata simultanea a tutti i destinatari assegnati nel gruppo, dopodiché il chiamante può pronunciare i propri messaggi e riagganciare una volta terminati.
Per ulteriori informazioni, vedere Configurare un gruppo di paging in Control Hub.
Registrazioni
supporta la registrazione delle chiamate effettuate o ricevute da un utente. Ciò potrebbe essere necessario per esigenze di qualità, garanzia, sicurezza o formazione. Per impostazione predefinita, le chiamate vengono registrate in , ma è possibile utilizzare anche altri fornitori di servizi di registrazione di terze parti se sono richieste altre funzionalità di registrazione o requisiti di conformità e normativi.
Quando si utilizza come piattaforma di registrazione, tutte le chiamate registrate vengono gestite all'interno di . Gli amministratori a pieno titolo con il ruolo di Compliance Officer possono riprodurre e scaricare le registrazioni. Senza il ruolo di Compliance Officer, l'amministratore può solo eliminare le registrazioni.
Per ulteriori informazioni su questa funzionalità e un elenco di registrazioni di terze parti, vedere Gestire la registrazione delle chiamate per Webex Calling.
Numero unico
La funzione Single Number Reach consente di effettuare chiamate al numero di telefono di un utente su più dispositivi. Possono essere inclusi sia altri telefoni fissi che cellulari. È possibile effettuare chiamate anche da questi dispositivi e gli utenti possono passare e ricevere chiamate da un dispositivo all'altro.
Per ulteriori informazioni su questa funzionalità e su come un amministratore la configura in , vedere Configurare la portata di un singolo numero (ufficio ovunque).
Per ulteriori informazioni su come un utente può gestire e configurare autonomamente questa funzionalità nel Webex User Hub (portale), vedere Configurare la portata di un singolo numero (ufficio ovunque).
Gruppo con casella vocale
I gruppi di posta vocale consentono di avere una casella di posta vocale condivisa che può essere assegnata a un utente o a una funzione di instradamento delle chiamate. Ecco alcuni dei motivi per cui potrebbe essere necessario un gruppo di segreteria telefonica:
-
Segreteria telefonica generica per un reparto o un gruppo di lavoro
-
Aggiungere l'opzione di segreteria telefonica a un risponditore automatico o a un gruppo di ricerca
-
Per inviare chiamate in overflow da una coda di chiamate
-
Utenti che necessitano solo di una casella vocale.
Per ulteriori informazioni, vedere Gestire una casella di posta vocale condivisa e una casella di fax in entrata per Webex Calling.
La console dell'operatore è elencata nella pagina Funzioni di chiamata in Webex, tuttavia è una funzionalità aggiuntiva che richiede l'acquisto della licenza della console dell'operatore per essere utilizzata.
Per ulteriori informazioni, vedere Introduzione alla console dell'operatore.
Per informazioni su tutte le funzionalità, incluse alcune funzionalità aggiuntive, vedere Funzionalità disponibili in base al tipo di licenza per Webex Calling.
Implementa
Preparazione della rete
Il primo passo nella transizione è garantire una connettività Internet affidabile e sicura tra la rete locale e il cloud.
Poiché la maggior parte delle organizzazioni si connette a Internet tramite uno o più firewall o dispositivi di sicurezza, è essenziale convalidare che i flussi di traffico richiesti siano supportati.
Gli amministratori di rete e di sicurezza devono comprendere questi flussi in termini di:
-
Direzione (in entrata vs in uscita)
-
Protocolli (Esempio - SIP TLS, SRTP, HTTPS)
-
Intervalli di indirizzi IP utilizzati dai servizi
-
Numeri di porta che devono essere aperti o consentiti.
Ciò garantisce che i firewall aziendali, i dispositivi NAT e le altre infrastrutture di rete siano configurati correttamente per gestire il traffico, mantenendo al contempo le policy di sicurezza aziendali.
Per informazioni sui flussi richiesti, inclusi indirizzo IP, porte e protocolli, vedere Informazioni di riferimento sulle porte per Webex Calling. Utilizzare queste informazioni per configurare il firewall, i proxy e altre infrastrutture di rete nella distribuzione esistente per abilitare i flussi di rete.
Per i servizi di collaborazione cloud come . l'approccio consigliato è l'accesso Internet decentralizzato da ogni filiale o sede. Consentendo al traffico di uscire localmente, questo modello:
-
Riduce il ritardo di andata e ritorno e il jitter, migliorando la qualità complessiva della chiamata
-
Si adatta in modo efficiente man mano che più utenti e siti passano a
-
Funziona perfettamente con SD-WAN, che può indirizzare dinamicamente le sessioni al punto di ingresso cloud più vicino per prestazioni ottimali
- Consente di tracciare la posizione dell'utente in base al suo indirizzo IP pubblico, facilitando l'analisi del percorso multimediale e la risoluzione dei problemi.
Inoltre, le organizzazioni devono garantire un'adeguata larghezza di banda Internet in ogni sede. La larghezza di banda deve essere dimensionata in base al numero previsto di chiamate simultanee, al codec selezionato (ad esempio, Opus o G.711), più il sovraccarico per la segnalazione, le ritrasmissioni e la crescita. Ciò è in linea con la fase di preparazione del ciclo di vita PPDIO e costituisce una solida base per la migrazione.
Impostazione iniziale
La sottosezione di configurazione iniziale all'interno della fase di implementazione della distribuzione è fondamentale per stabilire un ambiente di chiamata cloud ben strutturato e gestibile. Questa fase comprende attività critiche quali la creazione dell'organizzazione, l'acquisizione e l'assegnazione delle licenze, nonché la verifica e la rivendicazione dei domini aziendali per garantire una corretta gestione degli utenti e la sicurezza. Inoltre, include modelli di licenza di provisioning per automatizzare l'assegnazione delle licenze utente, la configurazione di Single Sign-On (SSO) per semplificare l'autenticazione utente e migliorare la sicurezza e la regolazione delle impostazioni del servizio e del client per allinearle alle policy aziendali e alle esigenze degli utenti. Il completamento di queste attività di configurazione iniziale garantisce che l'ambiente sia configurato correttamente per scalabilità, sicurezza e un'esperienza utente fluida, preparando il terreno per le successive fasi di distribuzione e operative.
Verifica dominio
Per consentire l'identificazione degli utenti registrati con i domini di posta elettronica della tua azienda su , è essenziale verificare i tuoi domini. Senza la verifica del dominio, gli utenti verranno assegnati a un'organizzazione di consumatori, complicando la gestione degli utenti per la tua azienda. La verifica del dominio è un passaggio obbligatorio che consente alla tua organizzazione di rivendicare e gestire questi utenti in modo efficace.
Assicurati che tutti i domini associati agli indirizzi email dei tuoi utenti siano verificati. La verifica del dominio non è esclusiva: lo stesso dominio può essere verificato su più organizzazioni.
Per maggiori informazioni sulla gestione dei domini, vedere Gestisci i tuoi domini.
Richiedi (converti) gli utenti esistenti
Dopo aver verificato con successo i tuoi domini, puoi procedere a richiedere alla tua organizzazione gli utenti che si sono registrati per utilizzare i domini di posta elettronica della tua azienda. Questo processo consolida tutti gli utenti sotto un'unica organizzazione, consentendo una gestione centralizzata e un'amministrazione semplificata. Richiedendo questi utenti, garantisci alla tua azienda il pieno controllo sugli account utente, consentendoti di assegnare le licenze appropriate, configurare i servizi e fornire il supporto necessario in modo efficiente. Questo approccio di gestione unificato migliora la sicurezza, semplifica il provisioning degli utenti e garantisce un accesso coerente ai servizi in tutta l'organizzazione. Richiedere gli utenti impedisce inoltre che vengano gestiti da organizzazioni esterne o di consumatori, mantenendo così l'integrità organizzativa e il controllo sulle risorse di collaborazione.
Per maggiori informazioni sulla rivendicazione degli utenti, vedere Rivendica utenti per la tua organizzazione (converti) utenti.
Configurare e testare la sincronizzazione delle directory
Per consentire una gestione fluida di utenti e gruppi, puoi sincronizzare utenti e gruppi dalla directory aziendale, ovvero Microsoft Entra ID (in precedenza Azure AD) o Microsoft Active Directory (AD), in . Questo processo garantisce che le identità degli utenti e le appartenenze ai gruppi vengano mantenute in modo coerente nell'intero ambiente.
Per le organizzazioni che implementano distribuzioni graduali, è fondamentale controllare e limitare l'ambito della sincronizzazione durante le implementazioni iniziali. Ciò riduce al minimo il rischio di modifiche indesiderate e consente di effettuare test mirati prima di un'adozione più ampia.
Il metodo più efficace per filtrare gli utenti sincronizzati è sfruttare l'appartenenza a gruppi di directory:
| 1 |
Crea un gruppo di sincronizzazione dedicato: Nella directory aziendale (ID Microsoft Entra o AD), crea un gruppo di sicurezza specifico per la sincronizzazione (ad esempio, gruppo di sincronizzazione). |
| 2 |
Popolare il gruppo con gli utenti target: Aggiungere a questo gruppo solo gli utenti che si desidera sincronizzare (ad esempio un gruppo di prova durante la fase pilota). Ciò consente di controllare attentamente chi è incluso nel processo di sincronizzazione. |
| 3 |
Configurare l'accordo di sincronizzazione con il filtraggio basato sui gruppi: Quando si imposta l'accordo di sincronizzazione nel provisioning di Directory Connector o Entra ID, configurare l'ambito in modo da includere solo gli utenti che sono membri del gruppo designato.
|
| 4 |
Espandi il gruppo secondo necessità: Man mano che si procede verso fasi di distribuzione più ampie, è sufficiente aggiungere altri utenti o gruppi al gruppo di sincronizzazione. L'ambito di sincronizzazione verrà automaticamente ampliato per includere questi utenti, consentendo un'implementazione controllata e graduale. Esempi di passaggi di implementazione:
Riferimenti: Sincronizza gli utenti Entra ID in Control Hub |
Configurare e testare Single Sign-On (SSO)
Single Sign-On (SSO) migliora la sicurezza e semplifica l'accesso degli utenti consentendo loro di autenticarsi una sola volta con le proprie credenziali aziendali e di ottenere un accesso senza interruzioni a . supporta l'integrazione SSO con IdP conformi a SAML 2.0, tra cui Microsoft Entra ID (in precedenza Azure AD), soluzioni federate di Active Directory (AD) e vari IdP di terze parti.
A questo punto la configurazione SSO progettata dovrebbe essere implementata e testata.
Riferimenti:
Integrazione Single Sign-On nell'hub di controllo
configurare l'accesso singolo per l'amministrazione Webex
Ottenere, fornire e verificare le licenze
Come parte della configurazione iniziale di , è essenziale procurarsi, fornire e verificare le licenze appropriate per abilitare e gestire i servizi in modo efficace. Il processo di approvvigionamento prevede la selezione dei tipi di licenza in base ai ruoli utente e ai carichi di lavoro, ad esempio licenze Professional, Standard e Workspace. Le licenze vengono generate e fornite tramite le piattaforme software Cisco o tramite i partner. Dopo l'approvvigionamento e la fornitura, è necessario verificare il numero corretto di licenze in . Questo processo garantisce che l'organizzazione disponga delle licenze corrette, attivate e pronte per l'uso nella distribuzione.
Come parte della configurazione iniziale delle licenze in , è importante configurare le licenze automatiche basate sull'organizzazione per semplificare l'assegnazione delle licenze ai nuovi utenti. Questa configurazione consente la concessione automatica delle licenze quando gli utenti vengono aggiunti all'organizzazione, eliminando la necessità di assegnazione manuale delle licenze. Quando si configura la concessione automatica delle licenze a livello di organizzazione, si selezionano i servizi da assegnare e si definisce l'ambito, ad esempio applicando le licenze solo agli utenti futuri o includendo anche gli utenti esistenti.
Tuttavia, se il piano di distribuzione prevede l'utilizzo di licenze automatiche a livello di gruppo, è possibile scegliere di non assegnare licenze a livello di organizzazione per evitare conflitti o assegnazioni di licenze duplicate. Con l'assegnazione automatica delle licenze a livello di gruppo, le licenze vengono assegnate in base all'appartenenza al gruppo. Gli utenti in più gruppi ricevono le licenze da tutte le assegnazioni di gruppo applicabili.
La configurazione dell'assegnazione delle licenze basata sui gruppi deve essere eseguita dopo il completamento della sincronizzazione delle directory, in modo che i gruppi sincronizzati esistano e possano essere utilizzati per l'assegnazione delle licenze.
Nello specifico, l'assegnazione automatica delle licenze richiede dettagli di provisioning aggiuntivi, come la posizione dell'utente e l'assegnazione del numero di telefono. Il numero di telefono di lavoro dell'utente deve essere in +E.164 formato, pre-provisionato e assegnato a una posizione valida affinché la licenza venga attivata automaticamente. Se queste condizioni non vengono soddisfatte, l'utente non potrà usufruire automaticamente dei servizi e potrebbe dover intervenire manualmente.
In sintesi, se si desidera un'assegnazione di licenze ampia e a livello di organizzazione, configurare l'assegnazione automatica delle licenze in base all'organizzazione per i nuovi utenti. Se preferisci un controllo più granulare o hai esigenze di licenza diverse per ogni gruppo, configura la licenza automatica a livello di gruppo ed evita di assegnare licenze a livello di organizzazione per evitare sovrapposizioni e garantire una corretta gestione delle licenze.
Impostazioni del servizio Webex Calling
È essenziale condurre una revisione e una configurazione complete delle impostazioni del servizio globale all'interno di .
Per prima cosa accedi e vai alla sezione delle impostazioni. Esaminare attentamente ogni opzione configurabile, tra cui, a titolo esemplificativo ma non esaustivo, la configurazione della composizione interna, i parametri delle chiamate di emergenza, i criteri di instradamento delle chiamate, la gestione della segreteria telefonica e le impostazioni predefinite del dispositivo.
Adatta queste impostazioni globali in modo che riflettano le politiche e le decisioni di progettazione della tua organizzazione.
Inoltre, impostazioni di configurazione e modelli utente e app.
Migrazione pilota
Durante la fase di implementazione, l'esecuzione di una migrazione pilota rappresenta una tappa fondamentale nella convalida della transizione da a . Questo progetto pilota prevede la fornitura di un sottoinsieme rappresentativo di utenti in una o più sedi sulla piattaforma, garantendo che la popolazione selezionata rifletta diversi casi d'uso e ruoli organizzativi. Parallelamente alla migrazione degli utenti, i servizi di collaborazione essenziali, tra cui segreteria telefonica, risponditori automatici, code di chiamata e gruppi di ricerca, devono essere trasferiti ai loro equivalenti per mantenere la continuità aziendale e la funzionalità del servizio.
La migrazione pilota dovrebbe sfruttare la stessa combinazione di strumenti forniti da Cisco e utilità di migrazione di terze parti pianificate per la più ampia implementazione organizzativa, garantendo che i processi, i flussi di lavoro di automazione e i punti di integrazione siano convalidati in modo approfondito in condizioni rappresentative.
Gli obiettivi principali di questo progetto pilota sono due: in primo luogo, convalidare e perfezionare i processi di transizione end-to-end, inclusi i flussi di lavoro di provisioning degli utenti, le procedure di migrazione dei dati e le configurazioni degli endpoint; e in secondo luogo, verificare in modo completo la funzionalità dei servizi migrati in condizioni operative reali.
Questo approccio graduale consente al team di progetto di identificare e risolvere eventuali problemi tecnici o procedurali in un ambiente controllato, raccogliere il feedback degli utenti sulla nuova esperienza della piattaforma, valutare l'efficacia degli strumenti di migrazione selezionati e stabilire la fiducia nella metodologia di migrazione prima di procedere con una distribuzione organizzativa più ampia.
Le informazioni acquisite durante questa fase pilota sono fondamentali per ottimizzare le successive ondate di migrazione e garantire una transizione fluida e con rischi ridotti per l'intera azienda.
Procurati PSTN
Per ottenere servizi PSTN per , selezionare prima un'opzione di connettività PSTN in .
Se un'organizzazione prevede di mantenere il controllo ibrido delle chiamate doppie ( fase 1 nella figura Transizione delle chiamate in fasi: Ibrido e Cloud) temporaneamente o indefinitamente, dovranno distribuire uno o più gateway locali per PSTN in sede per consentire le chiamate tra endpoint e endpoint.
Se l'obiettivo finale è una transizione completa ( fase 2) al cloud, inclusa la PSTN, allora sarà necessario un Cisco Calling Plan o un'opzione Cloud Connect per la PSTN.
Collabora con il provider scelto per ordinare e trasferire i numeri di telefono prima di configurarli in . L'ordinazione di numeri di telefono o l'avvio di ordini di porta è solo required/possible per PSTN in sede e Cloud Connect per . Per i piani di chiamata Cisco, l'ordine e il trasferimento vengono avviati da Control Hub non appena viene creata la sede e nei paesi in cui è disponibile il piano di chiamata Cisco. Per ulteriori informazioni sui piani Cisco Calling, vedere Introduzione ai piani Cisco.
Come parte dell'implementazione PSTN, assicurati che il tuo provider abbia abilitato i servizi PSTN in entrata e in uscita per la tua posizione. Inoltre, esegui delle chiamate di prova per verificare che le chiamate vengano instradate correttamente attraverso la connessione PSTN scelta.
Configura le posizioni
Prima di aggiungere utenti e dispositivi a , è necessario predisporre le posizioni di chiamata. Per ogni località è necessario inserire un indirizzo valido. Negli Stati Uniti e in Canada, questo indirizzo viene convalidato e utilizzato dalla piattaforma per inviare informazioni sulla posizione PIDF-LO per le chiamate di emergenza.
Quando si configurano sedi che utilizzano la rete PSTN locale, è necessario impostare di conseguenza i gateway locali. In , è necessario creare un trunk e un gruppo di routing per ciascun gateway locale, quindi il gruppo di routing viene assegnato come scelta PSTN per la posizione. Cisco consiglia vivamente di selezionare sempre un gruppo di routing come scelta PSTN, poiché questo approccio consente di aggiungere facilmente ulteriori trunk in futuro, supportando sia la scalabilità che la ridondanza. Cisco consiglia inoltre di abilitare il supporto della doppia identità e P-Charge-Info su ogni trunk PSTN, poiché ciò semplifica l'identificazione della parte fatturabile per le chiamate dirette o deviate in uscita. Se il tuo provider PSTN utilizza un'intestazione diversa per la fatturazione, puoi copiare le informazioni dall'intestazione P-Charge-Info sul gateway locale nell'intestazione di fatturazione richiesta.
Per le sedi che utilizzano Cloud Connect o il Cisco Calling Plan come opzione PSTN, è sufficiente selezionare la rispettiva scelta PSTN per la sede durante la configurazione. Se la sede utilizza Cloud Connect o la rete PSTN locale, sarà necessario aggiungere i numeri di telefono ordinati nel passaggio precedente. È possibile aggiungere i numeri come inattivi se non si desidera includerli subito nell'instradamento delle chiamate; è possibile attivare questi numeri in un secondo momento, quando vengono assegnati a utenti o funzioni.
È importante impostare sempre il numero principale per ogni posizione. Il numero principale può essere assegnato a un utente o a una funzionalità, ad esempio un centralino automatico. Per abilitare la segreteria telefonica nella sede, assicurarsi di impostare il numero pilota della segreteria telefonica, noto anche come numero del portale vocale.
Ulteriori impostazioni per le posizioni di chiamata includono la configurazione dei dettagli delle chiamate di emergenza, come il numero di richiamata di emergenza, le opzioni di notifica e le funzionalità avanzate delle chiamate di emergenza. Dovresti anche rivedere e adattare le impostazioni di registrazione, le preferenze della lingua e le configurazioni del dispositivo in base alle esigenze di ogni posizione. Se la tua organizzazione utilizza la chiamata abbreviata inter-sede in rete con numeri aziendali significativi, ricorda di configurare un codice sito univoco per la posizione nelle impostazioni di chiamata interna. Infine, se la chiamata esterna richiede una cifra di chiamata in uscita, assicurarsi di impostarla nelle impostazioni di chiamata esterna. Quando si configura una cifra di selezione in uscita, Cisco consiglia di abilitare l'applicazione della cifra di selezione in uscita per garantire la coerenza.
Integrazione con il controllo delle chiamate in sede
Per l'integrazione con il controllo delle chiamate in sede, è necessario configurare i trunk, i gruppi di routing, i piani di selezione aziendali e le impostazioni globali e di posizione. Iniziare configurando i trunk e i gateway locali destinati all'interconnessione con il sistema di controllo delle chiamate in sede; questo passaggio è necessario solo se sono necessari trunk dedicati. Se i trunk e i gruppi di routing esistenti sono sufficienti per la distribuzione, possono essere riutilizzati per l'interconnessione on-premise senza ulteriore configurazione.
Una volta stabiliti i trunk e i gruppi di routing, procedere alla creazione dei piani di selezione aziendali e assegnare il gruppo di routing appropriato come destinazione per ciascun piano di selezione. Quando l'integrazione coinvolge più sistemi di controllo delle chiamate in sede collegati tramite diversi trunk, saranno necessari più piani di selezione. È importante assicurarsi che questi piani di selezione contengano solo i modelli necessari per l'instradamento delle chiamate verso destinazioni locali.
Se la distribuzione richiede il supporto per il routing di estensioni sconosciute, questa funzionalità deve essere abilitata a livello di posizione. Inoltre, quando è attivato il routing dell'estensione sconosciuta, è necessario specificare la lunghezza massima dell'estensione sconosciuta nella sezione Instradamento delle chiamate tra e locali delle impostazioni dei servizi di chiamata in . Ciò garantisce un instradamento delle chiamate fluido e una corretta gestione degli scenari di composizione basati sugli interni nel tuo ambiente integrato.
Migrare gli utenti in batch
Quando si migrano gli utenti da a, potrebbe non essere possibile spostare tutti gli utenti contemporaneamente. Ciò può essere dovuto a molteplici ragioni, tra cui, a titolo esemplificativo ma non esaustivo, il numero di siti o utenti e il tempo necessario per la transizione di un sito. and/or gruppo di utenti contemporaneamente, risorse IT o del sito limitate per supportare la finestra di modifica, durata della finestra di modifica, complessità della modifica, ecc.
Quando si migrano gli utenti in più fasi, è fondamentale identificare quali utenti devono migrare insieme nello stesso batch. L'obiettivo principale è quello di far migrare insieme gli utenti che hanno dipendenze reciproche per i loro servizi e funzionalità di chiamata. Si desidera garantire che tutte le funzionalità di chiamata (ad esempio le code di chiamata) siano pienamente funzionanti come lo erano prima della transizione.
Anche se si implementa l'interoperabilità delle chiamate tra e con i gateway locali, non è possibile suddividere i servizi o le funzionalità condivise su questa connessione. Pertanto, è necessario identificare le dipendenze tra gli utenti esaminando funzionalità come:
-
Monitoraggio di altri utenti tramite BLF
-
Nello stesso pilota di caccia, coda di chiamata, ecc.
-
Linee condivise
-
Utilizzo del servizio di risposta alle chiamate
-
Utilizzando gli stessi numeri di parcheggio delle chiamate
-
Intercom
-
Executive/Admin.
Un esempio potrebbe essere un utente che fa parte di un gruppo di ricerca che sta passando a . Questo utente passerà al Gruppo di caccia e a tutti gli altri membri del Gruppo di caccia. Pertanto, dopo la transizione, il gruppo di ricerca e i suoi membri potranno rispondere correttamente alle chiamate sulla nuova piattaforma.
La situazione diventa più complessa quando gli utenti sono connessi a gruppi di utenti diversi per servizi e funzionalità di chiamata diversi. Ciò richiederà la transizione di più gruppi di utenti e di un servizio di chiamata contemporaneamente.
Utilizzare l'output dello strumento Migration Insights o dello strumento di terze parti utilizzato nella fase prepare per determinare quali utenti e funzionalità devono essere raggruppati insieme. Questo output avrebbe dovuto essere utilizzato per sviluppare il tuo piano di migrazione e ti fornirà informazioni su come raggruppare gli utenti e le funzionalità che devono essere trasferiti insieme.
I passaggi chiave per la transizione di un gruppo di utenti sono:
-
Identificazione degli utenti da migrare insieme
-
Verifica che tutti gli utenti siano presenti
-
Verificare che tutti i TN per gli utenti esistano in
-
Verificare il formato corretto del numero di telefono nella directory
-
Assicurarsi che il modello di licenza e di impostazioni per i gruppi di utenti sia impostato correttamente
-
Verifica o configurazione di tutti i servizi e le funzionalità di chiamata per il gruppo di utenti (prima o durante la transizione, a seconda dei casi)
-
Nella directory aziendale aggiungere gli utenti al gruppo di utenti abilitati alle chiamate
-
Leverage Tools: strumenti di migrazione di utenti e funzionalità and/or strumenti di terze parti
-
Disable/Delete user/device numero di directory e chiamata features/services dopo la transizione.
Dopo aver migrato un gruppo di utenti, testa un sottoinsieme di utenti per verificare che tutte le loro funzionalità e servizi di chiamata funzionino correttamente. Se le funzionalità di chiamata, quali coda di chiamata, gruppi di ricerca, ecc., vengono trasferite al gruppo di utenti, è necessario testare il corretto funzionamento di questi servizi di chiamata.
Spazi di lavoro
In , uno spazio di lavoro si riferisce a una posizione condivisa (come una sala conferenze, uno spazio di riunione o una scrivania condivisa) a cui possono essere assegnati dispositivi, estensioni e utenti. A differenza dei tradizionali telefoni Unifed CM, gli spazi di lavoro sono:
-
Incentrato sulla posizione: legato agli spazi fisici.
-
Dispositivo flessibile: può avere uno o più dispositivi (telefoni fissi, lavagne, ecc.).
Una volta identificati gli spazi di lavoro come parte della transizione a , è possibile aggiungerli in Dispositivi. Ogni area di lavoro necessita dell'assegnazione di un dispositivo e, se sono già presenti in Unified CM, devono essere reimpostati o riconfigurati. È possibile abilitare o disabilitare funzionalità quali segreteria telefonica, inoltro di chiamata e risposta alle chiamate e applicare policy per videochiamate, parcheggio delle chiamate e mobilità, a seconda delle necessità. Testare ogni spazio di lavoro effettuando chiamate interne ed esterne, testando le funzionalità video, di conferenza e di mobilità. Infine, informa gli utenti di eventuali procedure applicabili ai dispositivi e alle prenotazioni degli spazi di lavoro.
Per maggiori informazioni sugli spazi di lavoro in , vedere Spazi di lavoro.
Dispositivi di provisioning
I telefoni attualmente registrati dovranno essere migrati come parte della transizione al cloud. Per rendere la migrazione il più semplice possibile e ridurre al minimo le possibilità di fallimento, Cisco consiglia di migrare contemporaneamente anche le sedi fisiche o i reparti. Tuttavia, potrebbe essere necessario migrare gli utenti in batch a causa delle dipendenze delle funzionalità. Per maggiori dettagli, vedere la sezione Migrare gli utenti in batch.
Tutti i telefoni supportati da cui devi effettuare la transizione dovranno essere configurati come utente o area di lavoro e il telefono fisico dovrà essere riconfigurato per registrarsi con . Inoltre, i telefoni delle serie 7800 e 8800 necessitano di un aggiornamento del firmware da Enterprise a Multiplatform Phone (MPP). Questo processo include il caricamento del firmware transitorio prima di caricare il firmware MPP necessario per la registrazione. Richiede inoltre la licenza di migrazione appropriata. Negli ultimi anni Cisco ha migliorato questo processo per semplificare l'aggiornamento dei telefoni con firmware Enterprise al firmware MPP. Per ulteriori informazioni sui passaggi per completare l'aggiornamento del firmware, vedere Convertire i telefoni IP Cisco serie 7800 e 8800 tra firmware Enterprise e MPP.
Oltre ai passaggi descritti in questo articolo, è disponibile uno strumento integrato, Migra il tuo telefono a Webex Calling, che puoi utilizzare per migrare i tuoi telefoni 7800 e 8800 dal firmware Enterprise a quello MPP. Questo strumento consente inoltre di aggiungere i telefoni e di assegnarli agli utenti o agli spazi di lavoro appropriati. Per maggiori informazioni sull'utilizzo dello strumento, vedere Migrare il telefono.
Per tutti i telefoni della serie 9800 registrati con il suddetto requisito di migrazione del firmware non si applica. Questi telefoni utilizzano PhoneOS, supportato sia da che da . Per trasferire questi telefoni, dovrai aggiungerli a Webex Calling, assegnarli a un utente o a un'area di lavoro e quindi ripristinare le impostazioni di fabbrica dei telefoni. Sequenza di avvio PhoneOS per la registrazione la figura sottostante mostra la sequenza di avvio PhoneOS e come il telefono si registrerà una volta aggiunto a , anche se il telefono è ancora predisposto su and/or Sono in uso le opzioni DHCP (esempio: 150).
supporta il ripristino delle impostazioni di fabbrica dei dispositivi PhoneOS per consentire l'onboarding Zero-Touch su . Gli amministratori possono ripristinare da remoto le impostazioni di fabbrica dei telefoni 9800 e 8875 tramite le pagine di amministrazione CUCM, eliminando la necessità di accesso fisico ai telefoni per l'onboarding dei telefoni su . Questa funzionalità è supportata con i Device Pack a partire dal 9 settembre 2025:
-
CUCM v15 - Unified Communications Manager versione 15
-
CUCM v14 - Unified Communications Manager versione 14.
Per maggiori informazioni sul processo di registrazione per la serie 9800, vedere Processo di registrazione.
Oltre ai telefoni IP Cisco, potrebbe essere necessario fornire altri dispositivi quali adattatori telefonici analogici (ATA), telefoni wireless (Wi-Fi, DECT), dispositivi video, gateway vocali e dispositivi e telefoni diterze parti . Molti di questi dispositivi non dispongono di un percorso di aggiornamento del firmware, come i telefoni IP, per passare dal firmware aziendale al firmware cloud. Pertanto, dovrai predisporre ciascuno di questi dispositivi in Control Hub. Alcuni di questi non possono essere trasferiti e sarà necessario sostituirli con un modello equivalente (ad esempio ATA) 191/192) e altri richiederanno una riconfigurazione manuale and/or modifiche al software.
- Gateway vocali - Per migrare il gateway locale, vedere Migrazione del gateway locale.
Per ulteriori informazioni sulla configurazione del gateway vocale VG400, VG410 o VG420 in Control Hub, vedere Gateway locale
-
Adattatore telefonico analogico (ATA) - Per iniziare a utilizzare Cisco ATA 191 e 192, vedere Cisco ATA.
-
Telefono wireless Wi-Fi - Per integrare i telefoni wireless 840 e 860, vedere Integrare il telefono wireless Webex.
-
Telefoni wireless DECT - Per iniziare a utilizzare la nuova serie Cisco IP DECT 6800, vedere Cisco IP DECT.
Per creare e gestire la rete DECT digitale in Control Hub, vedere Gestire la rete DECT
Per ulteriori informazioni su Cisco IP DECT 6800, vedere Guida alla distribuzione
-
3rd dispositivi e telefoni di terze parti- Lavora con fornitori di terze parti su device/phone requisiti e il processo per migrarli o sostituirli per supportarli.
Configura funzioni
Tutte le funzionalità di chiamata necessarie devono essere predisposte prima o durante la transizione. Come discusso nella sezione Migrazione degli utenti in batch, le funzionalità di chiamata devono essere configurate e trasferite quando gli utenti che le utilizzano vengono trasferiti.
Per maggiori dettagli su come configurare ciascuna funzionalità, consultare gli articoli della guida alla configurazione corrispondenti.
-
Risponditori automatici - Per gestire i risponditori automatici, vedere Risponditori automatici
-
Parcheggio chiamata - Per gestire il parcheggio chiamata, vedere Parcheggio chiamata
-
Risposta chiamata - Per configurare il gruppo di risposta chiamata, vedere Risposta chiamata
-
Coda di chiamata s - Per configurare la coda di chiamata, vedere Coda di chiamata
-
Gruppi di ricerca - Per gestire i gruppi di ricerca, vedere Gestisci gruppo di ricerca
-
Modalità operative - Per l'instradamento delle chiamate in base alle modalità operative, vedere Instradamento delle chiamate in base alle modalità operative
-
Gruppi di paging - Per configurare un gruppo di paging, vedere Configurare un gruppo di paging
-
Registrazioni - Per gestire la registrazione delle chiamate per , vedere Gestisci registrazioni
-
Copertura con un singolo numero - Per configurare la copertura con un singolo numero (ufficio ovunque), vedere Configurare un singolo numero
-
Gruppo segreteria telefonica - Per gestire una segreteria telefonica condivisa e una casella fax in entrata per , vedere Gestisci segreteria telefonica.
Test accettazione
I test di accettazione garantiscono che l'ambiente migrato soddisfi i requisiti funzionali, funzioni come previsto e offra un'esperienza utente fluida in tutti i flussi di lavoro di comunicazione. Questo processo di convalida è multiforme e comprende tutto, dal provisioning degli utenti e dalle assegnazioni dei numeri alle prestazioni operative delle funzionalità di chiamata avanzate.
Questa sezione fornisce esempi e mette in evidenza gli aspetti chiave da considerare durante i test di accettazione; tuttavia, non intende costituire una checklist esaustiva o completa.
Provisioning degli utenti e assegnazione dei numeri
Un aspetto fondamentale dei test di accettazione consiste nel verificare che tutti gli utenti siano forniti in modo accurato e completo all'interno di . Ciò richiede un confronto approfondito tra la directory di origine () e la nuova base utenti stabilita per garantire che ogni account utente, insieme agli attributi associati quali numeri di interno e assegnazioni di selezione passante (DID), sia stato migrato correttamente. La completezza del provisioning è fondamentale non solo per l'operatività immediata, ma anche per l'amministrazione e il supporto continui.
La convalida dell'assegnazione del numero include la conferma che a ciascun utente sia assegnato l'interno e il numero esterno corretti e che tali numeri vengano instradati correttamente nei flussi di chiamate sia interne (in rete) che esterne (PSTN). È essenziale verificare eventuali sovrapposizioni, assegnazioni mancanti o configurazioni errate che potrebbero causare errori di instradamento delle chiamate o interruzioni del servizio.
Flussi di chiamata PSTN e presentazione dell'ID chiamante
Una procedura di test di accettazione solida deve comprendere la convalida end-to-end dei flussi di chiamate PSTN. Ciò include sia gli scenari di chiamate in entrata che quelli di chiamate in uscita. Per le chiamate PSTN in entrata, il team di test deve confermare che le chiamate vengano recapitate agli endpoint previsti, siano essi singoli utenti, code di chiamata, gruppi di ricerca o risponditori automatici. Le chiamate PSTN in uscita devono essere effettuate correttamente, prestando particolare attenzione alla corretta trasmissione e presentazione delle informazioni sull'ID chiamante. Ciò implica garantire che il nome e il numero corretti del chiamante vengano visualizzati ai destinatari esterni, in conformità con le politiche organizzative e i requisiti normativi.
I test dovrebbero anche tenere conto di scenari di failover, come la gestione di endpoint non raggiungibili o interruzioni di rete. Ciò aiuta a confermare che i meccanismi di fallback e il routing alternativo funzionino correttamente, mantenendo la continuità e l'affidabilità del servizio.
Flussi di chiamate on-net
I flussi di chiamate interni o in rete costituiscono la spina dorsale della comunicazione aziendale. I test di accettazione in quest'area verificano che le chiamate tra utenti all'interno dell'organizzazione vengano instradate correttamente, con funzionalità quali trasferimento di chiamata, messa in attesa, inoltro e conferenza che funzionino come previsto. È necessario confermare l'integrità dei piani di selezione, la connettività tra interni e il supporto delle policy di chiamata aziendali.
Gestione delle chiamate utente e convalida delle funzionalità
Un aspetto importante dei test di accettazione consiste nel convalidare il modo in cui gli utenti gestiscono le chiamate utilizzando e i telefoni fissi supportati. Questo processo si concentra sulla conferma che i flussi di lavoro delle chiamate quotidiane siano intuitivi e affidabili e che gli utenti abbiano accesso senza problemi alle funzionalità principali necessarie per i loro ruoli. I test dovrebbero valutare la facilità con cui gli utenti possono effettuare e ricevere chiamate, gestire le funzioni di attesa e ripresa ed eseguire trasferimenti sia ciechi che consultivi. È inoltre essenziale verificare che l'inoltro di chiamata, la conferenza e altre funzionalità avanzate, come il parcheggio e il recupero delle chiamate o l'attivazione della modalità "non disturbare", siano prontamente disponibili e funzionino senza problemi.
L'esperienza dovrebbe essere valutata in termini di chiarezza e reattività, considerando il modo in cui gli utenti interagiscono con la cronologia delle chiamate, la segreteria telefonica e le directory integrate. Occorre prestare particolare attenzione alla possibilità di spostare le chiamate attive tra dispositivi e di utilizzare in modo efficace i controlli durante le chiamate all'interno dell'applicazione o sui telefoni fisici. L'obiettivo finale è garantire che l'esperienza dell'utente finale sia coerente, efficiente e supporti pienamente le esigenze di comunicazione dell'organizzazione dopo la migrazione.
Code chiamate: Esperienza di agente e supervisore
Le code di chiamata vengono spesso utilizzate per gestire scenari di chiamate in entrata ad alto volume. In questo caso, i test di accettazione si concentrano su diverse dimensioni. Innanzitutto, è necessario verificare che le chiamate vengano distribuite agli agenti in base alla logica di coda configurata, ad esempio round robin, inattività più lunga o squillo simultaneo. La presentazione delle chiamate in coda sui desktop degli agenti deve essere esaminata per chiarezza e facilità d'uso, garantendo che gli agenti possano accettare, mettere in attesa e trasferire le chiamate in modo efficiente.
Per i supervisori, l'esperienza desktop dovrebbe essere valutata per funzionalità quali monitoraggio in tempo reale, inclusione nelle chiamate e analisi o approfondimenti sulle prestazioni della coda. Ciò include, a titolo esemplificativo ma non esaustivo, la convalida di dashboard e strumenti di reporting che forniscono dati fruibili sulla distribuzione delle chiamate, sull'attività degli agenti e sulle metriche delle code.
Gruppi di risposta: Distribuzione delle chiamate
I gruppi di ricerca sono un meccanismo fondamentale per distribuire le chiamate a gruppi predefiniti di utenti. I test di accettazione devono confermare che le chiamate vengano instradate ai membri del gruppo in base all'algoritmo di ricerca configurato e che gli scenari di overflow, inoltro e mancata risposta vengano gestiti secondo la progettazione. Per garantire la coerenza operativa e la soddisfazione dell'utente è essenziale garantire che i comportamenti di appartenenza al gruppo e di instradamento delle chiamate corrispondano a quelli precedentemente stabiliti.
Operatori automatici: Annunci e operazioni del menu
I risponditori automatici rappresentano la prima linea della gestione automatizzata delle chiamate. I test devono riguardare la riproduzione degli annunci, l'accuratezza dei saluti registrati e il corretto funzionamento degli alberi dei menu. Le selezioni del menu dovrebbero indirizzare in modo affidabile le chiamate ai reparti, alle persone o ai numeri esterni appropriati. I test dovrebbero includere anche scenari non validi o di timeout per confermare che i chiamanti ricevano istruzioni chiare o vengano reindirizzati come previsto.
Funzionamento della segreteria telefonica
Infine, la funzionalità di segreteria telefonica è fondamentale per l'esperienza dell'utente. I test di accettazione devono verificare che le caselle vocali siano assegnate correttamente e accessibili, sia dall'interno dell'organizzazione che da remoto. È necessario confermare la capacità di registrare, recuperare e gestire i messaggi, nonché l'invio delle notifiche.
Ottimizza
Migrazione PSTN a Cloud Connect per
Una volta che tutti gli endpoint e gli utenti sono migrati verso le chiamate cloud, l'unico scopo di Unified CM è quello di fungere da transito tra i gateway PSTN e tramite il gateway locale. La rimozione dei gateway PSTN e del gateway locale dall'immagine utilizzando Cloud Connect come accesso PSTN per tutti gli utenti di Webex Calling presenta diversi vantaggi, tra cui la riduzione dei costi e una maggiore affidabilità. Per trasferire l'accesso PSTN locale a Cloud Connect per , seguire questi passaggi:
-
Cloud Connect per la selezione dei partner.
Consulta l'elenco dei partner Cloud Connect e seleziona tra i partner disponibili per la sede della tua organizzazione.
-
Cloud Connect per la convalida.
Prima di trasferire l'accesso PSTN per le sedi a Cloud Connect, è necessario verificare e convalidare la connettività alla PSTN tramite il partner Cloud Connect selezionato. A tale scopo, è necessario predisporre una sede di prova in cui siano presenti alcuni utenti di prova. L'accesso PSTN per questa posizione di prova viene quindi impostato sul partner Cloud Connect prima di convalidare la connettività PSTN utilizzando i telefoni di prova. Dopo la convalida, la posizione di prova può essere deprovisionata.
-
Portabilità del numero.
Per preparare il passaggio a Cloud Connect è necessario effettuare un ordine di porta per tutti i numeri attualmente assegnati al trunk PSTN su cui terminano. Tutti i numeri devono essere trasferiti al partner Cloud Connect. Per mantenere la raggiungibilità tra sedi diverse, è necessario trasferire contemporaneamente tutti i numeri di tutte le sedi.
-
Passa al partner Cloud Connect.
Alla data del passaggio, l'accesso PSTN per tutte le sedi deve essere impostato sul provider PSTN Cloud Connected e la connettività in entrata e in uscita deve essere verificata.
Come discusso nella sezione PSTN del capitolo sulla progettazione, i clienti possono anche scegliere di spostare il loro accesso PSTN su Cloud Connect all'inizio della transizione utilizzando il trunking PSTN per le distribuzioni ibride. Per ulteriori informazioni, vedere Trunking PSTN per distribuzioni ibride di Webex Calling. In tal caso, durante la transizione l'accesso PSTN avviene tramite gateway locale e, dopo aver spostato tutti gli utenti, non è necessario alcun ulteriore passaggio di migrazione correlato alla PSTN, oltre alla dismissione dei gateway locali.
Ottimizzare l'infrastruttura on-premise
Una volta che tutti gli utenti sono stati trasferiti e tutti gli endpoint sono stati trasferiti alla registrazione cloud (o sono stati dismessi), aggiornare l'infrastruttura locale appropriata ora che le chiamate cloud sono in uso. Gli aggiornamenti all'infrastruttura includono:
-
Rimuovere i record DNS SRV di controllo delle chiamate e di messaggistica in locale dai server DNS in locale, inclusi cisco_uds._tcp.<domain>, cup_login._tcp.<domain>. Questi record SRV non sono più necessari per l'individuazione del servizio client.
-
Rimuovere i record DNS SRV correlati al perimetro dal sistema DNS pubblico, inclusi collab_edge._tls.<domain>. Questi record SRV non sono più necessari per la scoperta del servizio client dei servizi edge di collaborazione.
-
Aggiornare tutti gli ambiti DHCP rilevanti per rimuovere l'opzione 66 e l'opzione 150 TFTP/boot indirizzi dei server. Questi ambiti non sono più necessari per la scoperta e il download della configurazione del controllo delle chiamate degli endpoint.
-
Update/remove dial-peer appropriati in locale Gateway/CUBE che instradano le chiamate da e verso Unified CM. Questi dial-peer non sono più necessari per l'instradamento delle chiamate in sede.
-
Elimina o rimuovi tutte le macchine virtuali del nodo cluster and/or server. Riutilizzare le risorse di elaborazione e l'hardware in base alle esigenze. Queste risorse non sono più necessarie per il controllo delle chiamate e per i servizi edge.
-
Elimina o rimuovi tutte le macchine virtuali del nodo cluster and/or server. Riutilizzare le risorse di elaborazione e l'hardware in base alle esigenze. Queste risorse non sono più necessarie per i servizi di segreteria telefonica e di messaggistica unificata.
-
Ripulire: Dopo aver migrato l'accesso PSTN a Cloud Connected PSTN, i trunk PSTN, i gateway PSTN e il gateway locale possono essere dismessi.
-
Per qualsiasi soluzione E911 locale esistente, eliminare tutte le sedi o i numeri migrati e, una volta completata la transizione, rimuovere le macchine virtuali o i server dell'applicazione. Riutilizzare le risorse di elaborazione e l'hardware in base alle esigenze. Queste risorse non sono più necessarie per i servizi di chiamata di emergenza e di localizzazione.
-
I DN appartenenti agli utenti migrati devono essere inseriti in una partizione nascosta per evitare errori di routing delle chiamate e per garantire che tutti i CSS abbiano accesso prioritario al percorso cloud degli stessi DN.
-
Aggiornare la posizione fisica di dispatching e l'elemento di rete in Horizon Mobility ogni volta che si verificano modifiche. Le attività comuni che richiedono aggiornamenti sono:
-
Sostituzione dello switch di rete
-
Sostituzione del punto di accesso wireless
-
Modifiche all'ambito DHCP
-
Cambiamenti fisici all'interno dell'edificio (se si decide di cubical/office)
-
Espansione o contrazione dello spazio fisico adibito a ufficio all'interno di un edificio.
-
Utilizzare analisi e risoluzione dei problemi
fornisce funzionalità complete di analisi e risoluzione dei problemi per aiutarti a visualizzare e monitorare la tua distribuzione. Questi includono la qualità dei media, la cronologia dettagliata delle chiamate, la coda delle chiamate, il gruppo di ricerca e l'analisi del risponditore automatico. Un esempio di analisi della qualità dei media è mostrato nella figura analisi della qualità dei media.
Nella risoluzione dei problemi, ogni chiamata effettuata può essere visualizzata con informazioni dettagliate sulla qualità dei media e sui problemi principali relativi alla segnalazione per aiutare a individuare i problemi dei media e le chiamate non riuscite, come mostrato nella figura risoluzione dei problemi di qualità dei media.
la risoluzione dei problemi può anche essere integrata con altri prodotti Cisco come gli switch ThousandEyes e Meraki per offrire un'esperienza integrata ancora più ricca in Control Hub. Per ulteriori informazioni sull'utilizzo dell'analisi e della risoluzione dei problemi di Webex Calling, vedere Risoluzione dei problemi delle chiamate Webex Calling in Control Hub.
