Grazie per il feedback.

Nel modello di distribuzione a sito singolo, in cui un Enhanced Survivability Node (ESN) viene distribuito all'interno di un sito insieme a un gateway locale per il routing delle chiamate PSTN. È possibile registrare un massimo di 7500 dispositivi sull'ESN durante un'interruzione.

Nel modello di distribuzione su più siti, dove sono presenti più siti e l'ESN può essere implementato in ogni sito dipende dai requisiti aziendali per la sopravvivenza del sito. I requisiti di un gateway locale e del DNS sono sempre necessari e un totale di 8 nodi ESN possono essere aggiunti a un cluster. Unified CM

Questo modello di implementazione è rilevante per un cliente in una regione con più siti e la sopravvivenza è un requisito per più di questi siti. Sebbene sia possibile condividere il gateway locale PSTN tra i siti, non è consigliato. In caso di interruzione della rete, il sito può isolarsi e in tal caso, ESN non sarà in grado di raggiungere il gateway locale per instradare le chiamate verso PSTN.

Di seguito sono riportate 2 opzioni di distribuzione per una distribuzione su più siti:

• Opzione 1: Enhanced Survivability Node distribuito in ogni sito.

• Opzione 2 — Nodo di sopravvivenza avanzato comune condiviso tra più siti.

Monitoriamo e gestiamo l'Enhanced Survivability Node come gli altri nodi distribuiti nel datacenter di istanze dedicate. Durante un evento di sopravvivenza, quando l'ESN viene disconnesso Cisco Cloud è quando perdiamo l'accesso al nodo e ci ricolleghiamo automaticamente quando l'interruzione viene risolta e la connettività viene ripristinata.

Gestiamo i certificati delle applicazioni UC e durante l'attivazione dell'Enhanced Survivability Node abbiamo aggiornato il certificato del Unified CM cluster Dedicated Instance viene aggiornato con l'ESN.

Durante l'evento di sopravvivenza, l'Enhanced Survivability Node memorizza tutti i dati CDR/CMR localmente. Una volta ripristinata la connettività, i dati verranno sincronizzati nuovamente con il Dedicated Instance Unified CM Publisher. La quantità di dati che può essere archiviata si basa sulla dimensione del disco dell'allora Enhanced Survivability Node. Lo spazio massimo di allocazione su disco che può impostare per CDR è 3328 MB. Può trattarsi di file CDR di dimensioni da piccole a grandi in base all'intervallo CDR configurato. L'epurazione avviene in base a:

• Quando l'utilizzo del disco supera lo spazio su disco allocato o configurato, elimina i record elaborati. Se l'utilizzo del disco rimane maggiore, è allora che vengono eliminati anche i record non elaborati.

• High WaterMark% configurato nelle impostazioni di «Gestione CDR», i file CDR verranno eliminati. Ad esempio, se «High Water Mark%» è configurato all'80% e l'utilizzo del disco è all'80%, i file CDR verranno eliminati.

• Durata della conservazione dei file CDR/CMR (giorni) configurata nelle impostazioni di «Gestione CDR», i file CDR verranno eliminati. Per impostazione predefinita, è impostato su 30 giorni.

Di seguito sono riportati gli avvisi in RTMT relativi all'Enhanced Survivability Node:

• SurvivabilityEvent: l'allarme si attiva quando tutti i nodi dell'istanza dedicata non sono raggiungibili dall'Enhanced Survivability Node.

• RemoteSurvivableNodeNotReachable: l'allarme si attiva quando un Enhanced Survivability Node non è raggiungibile dall'editore dell'istanza dedicata. Unified CM

Durante l'evento di sopravvivenza, deve connettere RTMT all'Enhanced Survivability Node per monitorare le prestazioni dell'ESN. Lo stesso non sarà disponibile, se RTMT è connesso ai nodi dell'istanza dedicata poiché l'ESN non sarà raggiungibile dal cloud durante l'evento di sopravvivenza.

Durante il normale funzionamento, la replica del database è completamente integrata tra tutti i server, incluso l'Enhanced Survivability Node all'interno del cluster. Unified CM I dati di configurazione statici, poiché vengono creati tramite spostamenti, aggiunte e modifiche, vengono sempre archiviati nel publisher e replicati in un modo dall'editore a ciascun abbonato e al nodo di sopravvivenza migliorato nel cluster.

Durante un evento di sopravvivenza, solo le funzionalità rivolte all'utente vengono modificate sui dispositivi registrati nell'Enhanced Survivability Node e le funzionalità rivolte all'utente sono in genere caratterizzate dal fatto che è possibile abilitare o disabilitare una funzione direttamente sul telefono premendo uno o più pulsanti, anziché modificare una funzionalità tramite una GUI basata sul web. Quindi, l'Enhanced Survivability Node consente l'assistenza personale e la GUI di amministrazione web come operazioni di sola lettura. I dispositivi dell'utente registrati su ESN sono in grado di apportare modifiche solo alle funzionalità di accesso utente elencate di seguito durante il failover. Tuttavia, queste modifiche non verranno sincronizzate con l'Unified CMeditore DI una volta ristabilita la connettività.

Le funzionalità rivolte all'utente sono tutte le funzionalità che possono essere abilitate o disabilitate premendo i pulsanti sul telefono e includono quanto segue:

• Inoltra tutti (CFA)

• Attivazione o disattivazione della privacy

• Attivazione o disattivazione della funzione Non disturbare (DND)

• Cisco Extension MobilityAccedi

• Accedi o si disconnette dal gruppo Hunt

• Mobilità dei dispositivi

• Status CTI CAPF per utenti finali e utenti delle applicazioni.

L'autenticazione dei soft client (Cisco Jabbere dell'applicazione Webex) per l'accesso durante il failover su Enhanced Survivability Node è la seguente:

1. Autenticazione locale: Quando l'autenticazione degli utenti viene eseguita localmente all'interno diUnified CM, durante l'evento di sopravvivenza, l'Enhanced Survivability Node sarà in grado di autenticare i client registrati.

2. Autenticazione LDAP: In questo caso l'autenticazione degli utenti viene effettuata utilizzando il server LDAP locale. Quindi, durante l'evento di sopravvivenza, l'autenticazione dei soft client funzionerà a condizione che il server LDAP sia raggiungibile dall'Enhanced Survivability Node.

   Dovrebbe garantire la raggiungibilità della directory LDAP a ESN durante l'evento di sopravvivenza.

3. Autenticazione Single Sign On (SSO): L'autenticazione di accesso SSO degli utenti viene eseguita utilizzando il server IDP. Quindi, durante l'evento di sopravvivenza, l'autenticazione dei soft client funziona a condizione che il server IDP sia raggiungibile dall'Enhanced Survivability Node.

   Per l'accesso all'interfaccia utente Unified CM web abilitato per SSO, è richiesta la raggiungibilità dell'IDP o è necessario utilizzare l'accesso URL basato sul ripristino.

   I clienti già autenticati continuano ad accedere poiché l'autenticazione si basa sul token ottenuto prima dell'evento di sopravvivenza. Tuttavia, per i nuovi accessi quando il cliente non dispone di un token valido dell'autenticazione precedente, l'ESN reindirizzerà al server IDP per l'autenticazione. Quindi è sempre necessario garantire la raggiungibilità del server IDP a ESN durante l'evento di sopravvivenza.

Le risorse multimediali sono necessarie per le Unified CM funzionalità di base, come Music on Hold, Announcement, Conference Bridge (software) che devono essere abilitati sull'ESN. Se sono state implementate risorse multimediali basate su hardware, durante l'evento di sopravvivenza deve assicurarsi che i server multimediali siano raggiungibili dall'ESN.

Durante le normali operazioni del Unified CM cluster ID, le chiamate di emergenza (in particolare nella regione AMER) vengono instradate attraverso il cloud RedSky dove è presente un trunk SIP configurato tra il cluster CM unificato Dedicated Instance e il cloud RedSky.

Se si verifica un evento di sopravvivenza, il cloud RedSky non sarà raggiungibile dall'ESN e quindi è necessario che Lei configuri il piano di chiamata di emergenza in modo tale che, se RedSky non è disponibile, instradare le chiamate di emergenza attraverso il GW PSTN locale configurato in quel sito. Il gruppo di rotte deve essere composto dal GW PSTN locale per gestire l'instradamento delle chiamate durante l'evento di sopravvivenza.

Configura il dial plan per il routing delle chiamate intrasite, intersite, intercluster e PSTN durante l'evento di sopravvivenza. In generale, l'ESN può indirizzare le chiamate solo per i dispositivi che vi sono registrati. Tutte le altre chiamate devono essere indirizzate al GW PSTN locale (configurato in ogni sito in cui è distribuito ESN) e da lì al PSTN. Di seguito sono spiegati alcuni scenari:

• Telefono 1 e telefono 2 registrati sullo stesso ESN — La chiamata viene instradata all'interno dell'ESN.

• Telefono 1 registrato su ESN e Telefono 2 registrato nel Unified CM cluster di istanze dedicate — Il dial plan dovrebbe indirizzare le chiamate da ESN al GW PSTN locale, da lì al DI tramite PSTN. Unified CM Durante l'evento di sopravvivenza, il dial plan dovrebbe rilevare l'errore di routing delle chiamate e reindirizzare le chiamate tramite il GW PSTN locale. Lo stesso dovrebbe valere per le chiamate in arrivo verso ESN da dispositivi DIUnified CM.

• Il telefono 1 registrato su ESN e il telefono 2 è un dispositivo PSTN: durante l'evento di sopravvivenza, le chiamate PSTN devono essere indirizzate al gateway PSTN locale. Deve assicurarsi che il dial plan sia in grado di rilevare gli errori di routing delle chiamate e reindirizzare la chiamata attraverso il gateway PSTN locale disponibile.

• Durante l'evento di sopravvivenza, quando la connettività dal suo sito al cloud Dedicated Instance è inattiva (WAN o interruzione della connettività), le funzioni di segreteria telefonica e assistente automatico non funzioneranno per i dispositivi che si registrano all'ESN, poiché il Cisco Unity Connection server è ospitato nel cloud dell'istanza dedicata a cui la connettività di ESN è inattiva. Se il suo dispositivo è configurato con «Call Forward Unregistered (CFU)» e la chiamata viene ricevuta in DIUnified CM, allora il chiamante è in grado di depositare un messaggio vocale nella Dedicated Instance Unity Connection. Che può essere recuperato quando i dispositivi tornano agli abbonati DI Unified CM.

• Tuttavia, durante un evento di sopravvivenza in cui la connettività al cloud Dedicated Instance è disponibile ma il Unified CM cluster in DI è inattivo, in tal caso le funzionalità di segreteria telefonica e assistente automatico funzionano per i dispositivi registrati sull'ESN, poiché ESN avrà la connettività al server Unity Connection distribuito nel cloud DI.

Durante l'evento di sopravvivenza, l'ESN non sarà in grado di raggiungere l'Cisco ExpresswayE & C in DI cloud e viceversa. Quindi, in questo caso gli utenti MRA non possono ottenere il servizio da ESN e quindi non potranno registrarsi. Tuttavia, se il dispositivo MRA dispone di Internet e può connettersi alle Cisco Expressways nel cloud DI, può registrarsi presso il DI a Unified CM condizione che il cluster in DI sia funzionante.

Affinché le integrazioni basate su CTI funzionino con Enhanced Survivability Node, deve aggiungere Enhanced Survivability Node come parte dell'elenco dei server di CTI. CTI Enhancements è stato progettato per le applicazioni che utilizzano JTAPI per consentire Enhanced Survivability Node come server CTI a cui l'applicazione può connettersi solo nel caso in cui i server CTI primari o secondari nell'elenco configurato non siano raggiungibili. Durante un normale funzionamento, le applicazioni CTI in loco possono connettersi con i server CTI primari e secondari nel cloud DI e, durante gli eventi di sopravvivenza, possono connettersi con Enhanced Survivability Node per un'esperienza CTI continua. Le applicazioni devono adattarsi alle nuove API esposte tramite l'interfaccia JTAPI per garantire che il fallback dall'Enhanced Survivability Node avvenga quando la connettività viene ripristinata.

Per ulteriori informazioni sulle nuove API aggiunte, consulti la sezione sulla ridondanza, https://www.cisco.com/c/en/us/td/docs/ voice_ip_comm /cucm/ /14_0_1/ -unified-jtapi-developers-guide-14/ -unified-jtapi-developers-guide-1251_chapter_00.html jtapi_dev cucm_b_cisco cucm_b_cisco

Applicazioni di terze parti che si interfacciano tramite i trunk SIP supportate con Enhanced Survivability Node. Nelle configurazioni del trunk SIP, la configurazione «Esegui su tutti i nodi» deve essere abilitata.

Sono supportati dispositivi di terze parti con funzionalità TFTP terziaria.