En el modelo de implementación de un solo sitio, donde se implementa un nodo de supervivencia mejorado (ESN) dentro de un sitio junto con una puerta de enlace local para el enrutamiento de llamadas de PSTN. Se puede registrar un máximo de 7500 dispositivos en el ESN durante una interrupción.

En el modelo de implementación de varios sitios, donde hay varios sitios y se puede implementar ESN en cada sitio depende de los requisitos empresariales para la supervivencia del sitio. Los requisitos de una puerta de enlace local y DNS siempre son una necesidad y se pueden agregar un total de 8 nodos ESN a un grupo de Unified CM.

Este modelo de implementación es relevante para un cliente de una región con varios sitios y la supervivencia es un requisito para varios de esos sitios. Si bien es posible compartir la puerta de enlace local de PSTN entre sitios, no se recomienda. Si hay una interrupción de la red, el sitio puede aislarse y, en ese caso, ESN no podrá comunicarse con la puerta de enlace local para enrutar las llamadas a PSTN.

A continuación, se incluyen 2 opciones de implementación para una implementación en varios sitios:

• Opción 1: Nodo de supervivencia mejorado implementado en cada sitio.

• Opción 2: nodo de supervivencia mejorado común compartido entre varios sitios.

Supervisamos y administramos el nodo de supervivencia mejorado como otros nodos que se implementan en el centro de datos de Dedicated Instance. Durante un evento de supervivencia, cuando el ESN se desconecta de la nube de Cisco es cuando perdemos el acceso al nodo y nos conectamos automáticamente cuando se resuelve la interrupción y se restablece la conectividad.

Administramos los certificados de la aplicación UC y, durante la activación del nodo de supervivencia mejorado, actualizamos el certificado de clúster de Unified CM de instancia exclusiva con ESN.

Durante el evento de supervivencia, el nodo de supervivencia mejorado almacena todos los datos de CDR/CMR localmente. Cuando se restaure la conectividad, los datos se sincronizarán nuevamente con Dedicated Instance Unified CM Publisher. La cantidad de datos que se pueden almacenar se basa en el tamaño del disco del nodo de supervivencia mejorado. El espacio máximo de asignación de disco que se puede establecer para CDR es de 3328 MB. Esto puede ser con un tamaño de archivo CDR pequeño o grande en función del intervalo CDR que esté configurado. La purga se realiza en función de:

• Cuando el uso del disco supera el espacio asignado o configurado en disco, elimina los registros procesados. Si el uso del disco sigue siendo mayor, es cuando también se purgan los registros sin procesar.

• Marca de agua % configurada en la configuración de “Administración de CDR”, los archivos CDR se depurarán. Por ejemplo, si la “Marca de agua alta %” is configured as 80% y el uso del disco es del 80 %, los archivos CDR se depurarán.

• Duración de la conservación de archivos CDR/CMR (días) configurada en la configuración de “Administración de CDR”, los archivos CDR se depurarán. De forma predeterminada, se establece en 30 días.

A continuación se muestran las alertas en RTMT relacionadas con el nodo de supervivencia mejorado:

• SurvivabilityEvent: la alarma se activa cuando no se puede acceder a todos los nodos de Dedicated Instance desde el nodo de supervivencia mejorado.

• RemoteSurvivableNodeNotReachable: la alarma se activa cuando no se puede acceder a un nodo de supervivencia mejorado desde Dedicated Instance Unified CM Publisher.

Durante el evento de supervivencia, debe conectar RTMT al nodo de supervivencia mejorado para supervisar el rendimiento del ESN. Lo mismo no estará disponible si RTMT está conectado a los nodos de Dedicated Instance, ya que no se podrá acceder a ESN desde la nube durante el evento de supervivencia.

Durante el funcionamiento normal, la replicación de la base de datos está totalmente interconectada entre todos los servidores, incluido el nodo de supervivencia mejorado dentro del grupo de Unified CM. Los datos de configuración estática, ya que se crean a través de movimientos, adiciones y cambios, se almacenan siempre en el editor y se replican de una manera desde el editor a cada suscriptor y nodo de supervivencia mejorado del grupo.

Durante un evento de supervivencia, solo se modifican las características de cara al usuario en los dispositivos registrados en el nodo de supervivencia mejorado y, por lo general, las características de cara al usuario se caracterizan mediante el hecho de que puede habilitar o deshabilitar una característica directamente en su teléfono pulsando uno o más botones, en lugar de cambiar una característica a través de una GUI basada en la Web. Por lo tanto, el nodo de supervivencia mejorado permite el autocuidado y la interfaz gráfica de usuario de administración web como operaciones de solo lectura. Los dispositivos del usuario registrados en ESN solo pueden realizar cambios en las características de cara al usuario enumeradas a continuación durante la conmutación por error. Sin embargo, estos cambios no se sincronizarán de nuevo con el editor de DI Unified CM cuando se restablezca la conectividad.

Las características de cara al usuario son todas las que se pueden habilitar o deshabilitar pulsando botones en el teléfono e incluyen las siguientes:

• Desviar todas las llamadas (CFA)

• Habilitar o deshabilitar la privacidad

• Activar o desactivar no molestar (DND)

• Inicio de sesión en Cisco Extension Mobility

• Inicio de sesión o cierre de sesión en grupo de búsqueda

• Movilidad del dispositivo

• Estado de CTI CAPF para usuarios finales y usuarios de aplicaciones.

La autenticación de los clientes de software (Aplicación de Cisco Jabber y Webex) para el inicio de sesión durante la conmutación por error al nodo de supervivencia mejorado es la siguiente:

1. Autenticación local: Cuando la autenticación de usuarios se realiza localmente dentro de Unified CM, durante el evento de supervivencia el nodo de supervivencia mejorado podrá autenticar los clientes registrados en él.

2. Autenticación de LDAP: En este caso, la autenticación de usuarios se realiza mediante el servidor LDAP local. A continuación, durante el evento de supervivencia, la autenticación de clientes de software funcionará siempre que se pueda acceder al servidor LDAP desde el nodo de supervivencia mejorado.

   Debe garantizar la disponibilidad del directorio LDAP a ESN durante todo el evento de supervivencia.

3. Autenticación de inicio de sesión único (SSO): La autenticación de inicio de sesión SSO de los usuarios se realiza mediante el servidor de IDP. A continuación, durante el evento de supervivencia, la autenticación de clientes de software funciona siempre que se pueda acceder al servidor de IDP desde el nodo de supervivencia mejorado.

   Para el inicio de sesión en la interfaz de usuario web de Unified CM habilitado para SSO, se requiere la capacidad de acceso de IDP o se debe utilizar el inicio de sesión en la URL basada en la recuperación.

   Los clientes ya autenticados siguen iniciándose sesión, ya que la autenticación se basa en el token que se obtiene antes del evento de supervivencia. Sin embargo, para los inicios de sesión nuevos cuando el cliente no tenga un token válido de la autenticación anterior, el ESN redirigirá al servidor de IDP para la autenticación. Por lo tanto, siempre es necesario garantizar la disponibilidad del servidor de IDP a ESN durante todo el evento de supervivencia.

Se requieren recursos de medios para las características básicas de Unified CM, como Música en espera, Anuncio, Puente de conferencia (software) deben estar habilitados en el ESN. Si se implementaron recursos multimedia basados en hardware, durante el evento de supervivencia debe asegurarse de que se pueda acceder a los servidores multimedia desde ESN.

Durante las operaciones normales del clúster de DI Unified CM, las llamadas de emergencia (especialmente en la región AMER) se enrutan a través de la nube de RedSky, donde hay un enlace troncal SIP configurado entre el clúster de Dedicated Instnace unified CM y la nube de RedSky.

Si hay un evento de supervivencia, no se podrá acceder a la nube de RedSky desde el ESN y, por lo tanto, es necesario que configure el plan de marcado de llamadas de emergencia de manera que, si RedSky no está disponible, enrute las llamadas de emergencia a través del GW PSTN local configurado en ese sitio. El grupo de rutas debe estar formado por el GW PSTN local para gestionar el enrutamiento de llamada durante el evento de supervivencia.

Configure el plan de marcado para enrutar llamadas intrasitas, entre sitios, entre grupos y PSTN durante el evento de supervivencia. En general, el ESN puede enrutar llamadas solo para los dispositivos que están registrados en él. Todas las demás llamadas deben enrutarse al GW de la PSTN local (configurado en todos los sitios donde se implementa ESN) y desde allí al PSTN. A continuación se explican algunos escenarios:

• Teléfonos 1 y 2 registrados en el mismo ESN: la llamada se enruta dentro del ESN.

• El teléfono 1 está inscrito en ESN y el teléfono 2 está inscrito en el grupo de Unified CM de instancia exclusiva: el plan de marcado debe enrutar las llamadas de ESN al GW de PSTN local, desde allí al DI Unified CM a través de PSTN. Durante el evento de supervivencia, el plan de marcado debe detectar la falla de enrutamiento de llamada y volver a enrutar las llamadas a través del GW de PSTN local. Lo mismo debe aplicarse a las llamadas entrantes a ESN desde dispositivos de DI Unified CM.

• El teléfono 1 está registrado en ESN y el teléfono 2 es un dispositivo PSTN: Durante el evento de supervivencia, las llamadas de PSTN deben enrutarse a la puerta de enlace de PSTN local. Debe asegurarse de que el plan de marcado tenga la capacidad de detectar fallas de enrutamiento de llamada y reenrutar la llamada a través de la puerta de enlace de PSTN local disponible.

• Durante el evento de supervivencia, cuando la conectividad de su sitio a la nube de Dedicated Instance está inactiva (interrupción de WAN o conectividad), las características del correo de voz y del contestador automático no funcionarán para los dispositivos que se registran en ESN, ya que el servidor de Cisco Unity Connection está alojado en la nube de Dedicated Instance a la que está inactiva la conectividad de ESN. Si su dispositivo está configurado con “Desvío de llamadas no registradas (CFU)” y la llamada se recibe en DI Unified CM, la persona que llama puede depositar un correo de voz en la instancia exclusiva Unity Connection. Se puede recuperar cuando los dispositivos regresan a los suscriptores de DI unified CM.

• Sin embargo, durante un evento de supervivencia cuando la conectividad a la nube de Dedicated Instance está disponible pero el grupo de Unified CM en la DI está inactivo, en ese caso las características del correo de voz y del contestador automático funcionan para los dispositivos registrados en el ESN, ya que el ESN tendrá conectividad con el servidor de Unity Connection implementado en la nube de la DI.

Durante el evento de supervivencia, el ESN no podrá comunicarse con Cisco Expressway E y C en la nube de DI y viceversa. Por lo tanto, en este caso los usuarios de MRA no pueden obtener el servicio de ESN y, por lo tanto, no podrán registrarse. Sin embargo, si el dispositivo de MRA tiene Internet y puede conectarse a los Cisco Expressways en la nube de la DI, puede registrarse en la DI Unified CM siempre que el grupo en la DI sea funcional.

Para que las integraciones basadas en CTI funcionen con el nodo de supervivencia mejorado, debe agregar el nodo de supervivencia mejorado como parte de la lista de servidores de CTI. Las mejoras de CTI se realizan para las aplicaciones que utilizan JTAPI para permitir el nodo de supervivencia mejorado como un servidor CTI al que la aplicación puede conectarse solo en el caso de que no se pueda acceder a los servidores CTI primarios o secundarios de la lista configurada. Durante una operación normal, las aplicaciones de CTI en el sitio pueden conectarse con los servidores de CTI primario y secundario en la nube de DI y, durante el evento de supervivencia, pueden conectarse con el nodo de supervivencia mejorado para una experiencia de CTI continua. Las aplicaciones deben adaptarse a las nuevas API expuestas a través de la interfaz JTAPI para garantizar la recuperación desde el nodo de supervivencia mejorado cuando se restaura la conectividad.

Para obtener más información sobre las nuevas API agregadas, consulte la sección de redundancia. https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/jtapi_dev/14_0_1/cucm_b_cisco-unified-jtapi-developers-guide-14/cucm_b_cisco-unified-jtapi-developers-guide-1251_chapter_00.html

El servicio web de AXL está habilitado en el nodo de supervivencia mejorado con privilegios de administrador de solo lectura. Recomendamos que cualquier aplicación de terceros, como el servidor de aprovisionamiento, interactúe solo con el editor de DI Unified CM para cualquier actualización relacionada con la base de datos. Sin embargo, estas aplicaciones pueden ser de solo lectura cuando están conectadas al nodo de supervivencia mejorado.

Las aplicaciones de terceros que interactúan a través de los enlaces troncales SIP son compatibles con el nodo de supervivencia mejorado. En las configuraciones del enlace troncal SIP, la configuración de “ejecutar en todos los nodos” debe estar habilitada.

Se admiten dispositivos de terceros con capacidad de TFTP terciario.