En el modelo de implementación de sitio único, en el que se implementa un nodo de supervivencia mejorada (ESN) dentro de un sitio junto con una puerta de enlace local para el enrutamiento de llamada de PSTN. Se pueden registrar 7500 dispositivos como máximo 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 del requisito empresarial para la supervivencia del sitio. Los requisitos de una puerta de enlace local y DNS siempre son necesarios y se puede agregar un total de 8 nodos ESN a un grupo de Unified CM.

Este modelo de implementación es relevante para un cliente en 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 los sitios, no se recomienda. Si hay una interrupción de la red, el sitio puede aislarse y, en ese caso, el ESN no podrá comunicarse con la puerta de enlace local para enrutar las llamadas a PSTN.

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

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

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

Supervisamos y administramos el nodo de supervivencia mejorada como otros nodos que se implementan en el centro de datos de la instancia dedicada. Durante un evento de supervivencia, cuando el ESN se desconecta de la nube de Cisco es cuando perdemos el acceso al nodo y volvemos a conectarnos automáticamente cuando se resuelve la interrupción y se restaura la conectividad.

Administramos los certificados de la aplicación de UC y durante la activación del nodo de supervivencia mejorada actualizamos el certificado del clúster de Dedicated Instance Unified CM se actualiza con el ESN.

Durante el evento de supervivencia, el nodo de supervivencia mejorada almacena todos los datos de CDR/CMR de forma local. Cuando se restaure la conectividad, los datos se sincronizarán de nuevo 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 mejorada en ese momento. El espacio máximo de asignación de disco que se puede establecer para CDR es de 3328 MB. Esto puede ser con el tamaño del archivo CDR pequeño a grande en función del intervalo de CDR que está configurado. La purga se realiza en función de lo siguiente:

• Cuando el uso del disco excede el espacio de disco asignado o configurado, elimina los registros procesados. Si el uso del disco sigue siendo mayor, entonces también se purgan los registros no procesados.

• Marca de agua alta % que está configurada en los ajustes “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) que está configurada en la configuración “Administración de CDR”, los archivos CDR se depurarán. De forma predeterminada, se establece en 30 días.

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

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

• RemoteSurvivableNodeNotReachable : la alarma se activa cuando no se puede acceder a un Nodo de supervivencia mejorada desde el editor de Dedicated Instance de Unified CM.

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

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

Durante un evento de supervivencia, solo se modifican las funciones orientadas al usuario en los dispositivos que están registrados en el Nodo de supervivencia mejorada y, por lo general, las funciones orientadas al usuario se caracterizan utilizando el hecho de que puede habilitar o deshabilitar una función directamente en el teléfono presionando uno o más botones, en lugar de cambiar una función a través de una GUI basada en la web. Por lo tanto, el nodo de supervivencia mejorada permite la interfaz gráfica de usuario de administración web y de atención automática como operaciones de solo lectura. Los dispositivos del usuario registrados en ESN solo pueden realizar cambios en las características que llegan al usuario enumeradas a continuación durante la recuperación de fallas. Sin embargo, estos cambios no se sincronizarán de nuevo con el editor de DI Unified CM cuando se restablezca la conectividad.

Las funciones orientadas al usuario son todas las funciones que se pueden activar o desactivar presionando botones en el teléfono e incluyen las siguientes:

• Reenvío de llamadas a todos (CFA)

• Habilitar o deshabilitar privacidad

• Activar o desactivar No molestar (Do Not Disturb, DND)

• Conexión a Cisco Extension Mobility

• Conexión o desconexión del grupo de búsqueda

• Movilidad del dispositivo

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

La autenticación de los clientes de software (aplicación de Cisco Jabber y Webex) para iniciar sesión durante la recuperación de fallas al nodo de supervivencia mejorada es la siguiente:

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

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

   Debe asegurarse de que el directorio LDAP sea accesible 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 IDP. A continuación, durante el evento de supervivencia, la autenticación de los clientes de software funciona siempre que se pueda acceder al servidor de IDP desde el nodo de supervivencia mejorada.

   Para el inicio de sesión en la interfaz de usuario web de Unified CM habilitado con SSO, se requiere la disponibilidad de IDP o se debe utilizar el inicio de sesión URL basado en recuperación.

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

Se requieren recursos de medios para que las características básicas de Unified CM, como música en espera, anuncio y servicios de puente de conferencia (software) deben estar habilitados en el ESN. Si se implementaron recursos de medios basados en hardware, durante el evento de supervivencia debe asegurarse de que los servidores de medios sean accesibles desde el ESN.

Durante las operaciones normales del clúster de DI Unified CM, las llamadas de emergencia (particularmente en la región de AMER) se enrutan a través de la nube de RedSky, donde hay un enlace troncal SIP que está 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, se requiere 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 de la PSTN GW local configurada en ese sitio. El grupo de rutas debe constar del PSTN GW local para gestionar el enrutamiento de llamada durante el evento de supervivencia.

Configure el plan de marcado para el enrutamiento de llamadas dentro del sitio, entre sitios, entre clústeres y PSTN durante el evento de supervivencia. En general, el ESN puede enrutar llamadas solo para dispositivos que están registrados en él. Todas las demás llamadas deben enrutarse al PSTN GW local (configurado en todos los sitios en los que se implemente ESN) y de allí al PSTN. A continuación, se explican algunos escenarios:

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

• Teléfono 1 inscrito en ESN y teléfono 2 inscrito en el clúster de Dedicated Instance Unified CM: el plan de marcado debe enrutar las llamadas desde ESN al PSTN GW 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 PSTN GW local. Lo mismo debería aplicarse a las llamadas entrantes a ESN desde dispositivos de DI Unified CM.

• El teléfono 1 se inscribió a ESN y el teléfono 2 es un dispositivo PSTN: Durante un 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 en el enrutamiento de llamada y volver a enrutar 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 instancia exclusiva esté inactiva (interrupción de conectividad o WAN), las características del correo de voz y del asistente automático no funcionarán para los dispositivos que se inscriban en el ESN, ya que el servidor de Cisco Unity Connection está alojado en la nube de instancia exclusiva en la que la conectividad de ESN está inactiva. Si su dispositivo está configurado con “Reenvío de llamadas no registrado (CFU)” y la llamada se recibe en DI Unified CM, la persona que llama puede depositar un correo de voz en Dedicated Instance Unity Connection. Que se puede recuperar cuando los dispositivos vuelven 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 clúster de Unified CM en DI no funciona, en ese caso las características del correo de voz y del asistente automático funcionan para los dispositivos que están registrados en el ESN, ya que ESN tendrá conectividad con el servidor de Unity Connection implementado en la nube de DI.

Durante el evento de supervivencia, el ESN no podrá acceder a 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 inscribirse. Sin embargo, si el dispositivo MRA tiene Internet y puede conectarse a Cisco Expressways en la nube de DI, puede inscribirse en DI Unified CM siempre que el grupo en DI sea funcional.

Para que las integraciones basadas en CTI funcionen con el nodo de supervivencia mejorada, debe agregar el nodo de supervivencia mejorada como parte de la lista de servidores de CTI. Se realizan mejoras de CTI para aplicaciones que usan JTAPI para permitir el Nodo de supervivencia mejorada como servidor de CTI al que la aplicación puede conectarse solo en el caso de que no se pueda acceder a los servidores de CTI primarios o secundarios de la lista configurada. Durante una operación normal, las aplicaciones CTI en el sitio pueden conectarse con los servidores CTI primarios y secundarios en la nube de DI y, durante el evento de supervivencia, pueden conectarse con el nodo de supervivencia mejorada para obtener una experiencia CTI continua. Las aplicaciones deben adaptarse a las nuevas API expuestas a través de la interfaz de JTAPI para garantizar que se produzca el respaldo del nodo de supervivencia mejorada cuando se restaure 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

Las aplicaciones de terceros que se conectan a través de los enlaces troncales SIP son compatibles con el nodo de supervivencia mejorada. En las configuraciones del enlace troncal SIP, la configuración ‘Ejecutar en todos los nodos’ debe estar habilitada.

Se admiten dispositivos de terceros que tienen capacidad TFTP terciario.