Consideraciones sobre la integración con RTPC

Esta sección se aplica a los clientes que están considerando integrar el módulo ZPLS con un SBC y una conexión RTPC para mayor supervivencia. Los clientes que no planean integrar el módulo ZPLS con conectividad RTPC pueden omitir esta sección sin consecuencia.

Consideraciones de integración del SBC

Requisitos del SBC

Para integrar un SBC con Zoom para supervivencia, un SBC debe cumplir los siguientes requisitos:

• TLS 1.2 y SRTP

• Compatibilidad con TLS mutuo

• Protocolo de inicio de sesión de sesión (SIP)

• DTMF (RFC-2833)

• Ocultación de topología (RFC-5853)

• Oferta temprana de SIP (obligatorio)

• Códecs Opus, G.711 μ-law, G.711 A-law y G.729

Las integraciones RTPC requieren un SBC y un proveedor externo fiable

Para la conectividad RTPC, los clientes deben proporcionar un controlador de borde de sesión (SBC) conectado ya sea a una conexión heredada, o a un trunk SIP con una conexión celular o alternativa (p. ej., ADSL). Los clientes deben tener en cuenta que cualquier trunk SIP implementado en el SBC puede depender del mismo servicio de Internet que esté experimentando una interrupción. Debido a esta posibilidad, los clientes deberían considerar una conexión terciaria fiable para la conectividad RTPC.

Se puede usar cualquier SBC certificado BYOC de Zoom Phone

Cualquier controlador de borde de sesión (SBC) que esté certificado para Zoom Phone también puede usarse con el módulo ZPLS. Los clientes con un plan BYOC de Zoom Phone existente no necesitan un SBC adicional o separado con fines de supervivencia.

Los certificados DigiCert de Zoom deben instalarse en el SBC

Para establecer conectividad TLS tanto con el módulo ZPLS como con la nube de Zoom, los certificados raíz e intermedios DigitCert deben instalarse en el SBC.

Los SBC deben enrutar las llamadas entrantes a los centros de datos de Zoom Phone como primera y segunda opciones de enrutamiento, y el módulo ZPLS en tercer lugar

Los SBC de los clientes deben enrutar las llamadas entrantes desde la RTPC a la zona SIP primaria y secundaria antes de intentar el módulo ZPLS. Con esta configuración, las llamadas solo se enrutarán al módulo ZPLS durante un evento de supervivencia, ya que el SBC y los centros de datos de Zoom Phone deberían mantener conectividad estable por lo demás.

El incumplimiento de esta lógica puede provocar fallos en la entrega de llamadas, ya que el módulo ZPLS no puede enrutar llamadas a dispositivos registrados en la nube.

Una vez que la nube de Zoom Phone esté disponible tras un evento de supervivencia, un SBC puede intentar temporalmente enrutar números BYOC a la nube de Zoom mientras el dispositivo cliente del número afectado está registrado en el módulo ZPLS. Si esto ocurre, el enrutamiento de llamadas seguirá la configuración de Cuando una llamada no es contestada durante este periodo interino.

Las llamadas salientes desde el módulo ZPLS deben enrutar al SBC y al trunk SIP RTPC

Cuando el modo de supervivencia está activo, las llamadas desde ZPLS hacia el SBC deben enrutar al trunk SIP RTPC para establecer conexiones telefónicas externas. Todas las llamadas a números que no estén registrados en el módulo ZPLS se envían al SBC configurado para supervivencia en formato E.164.

Consideraciones de supervivencia local para el desvío de llamadas

Durante un evento de supervivencia, los números telefónicos proporcionados por Zoom Phone no serán accesibles externamente a menos que se reencaminen mediante desvío de llamadas

Durante un evento de supervivencia, los números telefónicos proporcionados por Zoom no serán accesibles externamente desde la perspectiva de la nube. En consecuencia, los usuarios ubicados dentro de las ubicaciones afectadas pueden no ser alcanzables a menos que las llamadas a sus números principales se desvíen a un número alternativo asociado con un SBC local.

Ejemplos comunes de números afectados pueden incluir números asignados a: usuarios, áreas comunes, recepciones automáticas (AR), grupos de línea compartida (SLG) y colas de llamadas (CQ).

Los clientes que utilizan un BYOC basado en las instalaciones no requieren configuraciones avanzadas, y pueden omitir el desvío de llamadas agregando una ruta terciaria desde su SBC al módulo ZPLS

Los clientes que utilizan un plan BYOC basado en las instalaciones (es decir, clientes que no usan números registrados en Zoom Phone) no requieren configuraciones avanzadas para habilitar el desvío de llamadas. En su lugar, los clientes BYOC pueden agregar una ruta terciaria desde el SBC en las instalaciones al módulo ZPLS.

Las configuraciones de desvío de llamadas las establece un administrador o usuario autorizado desde el portal web

Un administrador de cuenta o un usuario autorizado puede configurar la lógica de desvío de llamadas desde el portal web mediante entrada manual o una carga masiva CSV.

Los usuarios configurados para desvío de llamadas tendrán tres números asignados

Después de aplicar un número BYOC a un usuario para la supervivencia mediante desvío de llamadas, el dispositivo cliente recibirá al menos tres números:

1. Una extensión interna con el código del sitio prefijado

2. Un número RTPC proporcionado por Zoom

3. Un número RTPC BYOC

Los números telefónicos se pueden desviar a un máximo de un número BYOC

Cada número de Zoom Phone se puede desviar a un máximo de uno otro número BYOC. Sin embargo, puede desviar varios números telefónicos al mismo número BYOC.

Por ejemplo, si a John se le asigna el número X55-555-5555, el número de John puede desviarse al número del operador del edificio X99-999-9999. De manera similar, los compañeros de John también pueden tener sus números (X55-555-5554, X55-555-5553, etc.) desviados a X99-999-9999. Alternativamente, cada usuario puede tener su número desviado a un número completamente único, como X55-555-5554 que se enruta a X99-999-9998, y X55-555-5553 que se enruta a X99-999-9997. Sin embargo, ningún usuario individual puede tener su número desviado tanto a X99-999-9999 como a X99-999-9998.

El desvío de llamadas debe permanecer deshabilitado hasta que ocurra un evento de supervivencia

Aunque un administrador puede preaprovisionar la lógica de desvío de llamadas para un sitio con antelación, la funcionalidad de desvío de llamadas debe permanecer deshabilitada hasta que ocurra un evento de supervivencia. Si el desvío de llamadas está habilitado durante las operaciones habituales, todas las llamadas entrantes a un número registrado en Zoom Phone se reenviarán al SBC en las instalaciones y al número BYOC asociado, evitando los servicios de Zoom Phone. Por lo tanto, para mantener el enrutamiento normal de Zoom Phone, el desvío de llamadas debe estar deshabilitado durante las operaciones habituales.

El desvío de llamadas solo puede habilitarse por un usuario autorizado o administrador con una conexión a Internet funcional

Durante un evento en modo supervivencia, se asume que la conexión a Internet de un sitio no está disponible. Sin embargo, debido a que el desvío de llamadas debe permanecer deshabilitado para la operación estándar, solo puede habilitarse por un usuario autorizado o administrador con una conexión a Internet funcional, como un plan de datos del teléfono, o una conexión a Internet alternativa en una ubicación diferente.

Para minimizar el tiempo de inactividad y garantizar la continuidad del negocio, Zoom recomienda que las empresas establezcan procedimientos fiables para habilitar la lógica de desvío de llamadas desde el portal web durante un evento de supervivencia.

Las reglas de desvío de llamadas pueden aplicarse al sitio completo o a números individuales

Durante un evento de supervivencia, un administrador o usuario autorizado puede habilitar reglas de desvío de llamadas para todo el sitio o para números específicos desde el portal web.

Una vez que el desvío de llamadas esté habilitado para el número telefónico de un usuario, Zoom no hará sonar el cliente registrado en la nube del usuario, aunque mantenga una conexión independiente a la nube

Cuando el desvío de llamadas está habilitado para un número registrado en Zoom Phone, Zoom no intentará enrutar ninguna llamada al usuario a través de la nube. En consecuencia, incluso si un usuario afectado tiene un dispositivo registrado en la nube, como un teléfono móvil, si el número telefónico está marcado para desvío de llamadas, todas las llamadas se enrutarán a través de la RTPC al SBC de la empresa.

Por ejemplo, un sitio está experimentando un evento en modo supervivencia y el teléfono móvil de un usuario está conectado a la nube de Zoom Phone a través de la conexión de datos del proveedor celular. Si el número de teléfono de un usuario está marcado para desvío de llamadas, la nube de Zoom Phone no hará sonar su número de Zoom Phone a través de la aplicación móvil, a pesar de la conexión estable. En su lugar, todas las llamadas seguirán enroutándose a través de la RTPC al SBC del cliente.

Si no se habilita el desvío de llamadas para un usuario durante un evento de supervivencia, las llamadas entrantes seguirán las preferencias de manejo de llamadas de cada usuario

Si el desvío de llamadas no está habilitado durante un evento de supervivencia, las llamadas entrantes se tratarán de acuerdo con la lógica de manejo de llamadas para cada usuario individual. Si un usuario no tiene un cliente telefónico de respaldo registrado en la nube, como un teléfono móvil, los llamantes estarán sujetos a las reglas definidas por la Cuando una llamada no es contestada sección de las preferencias de manejo de llamadas.

El desvío de llamadas solo se aplica a llamadas entrantes RTPC

El desvío de llamadas para supervivencia solo se aplica a las llamadas enrutadas a través de la RTPC y/o la nube de Zoom Phone. Las llamadas originadas desde extensiones registradas en Zoom dentro del mismo sitio intentarán conectarse primero a través del módulo ZPLS, y al RTPC en segundo lugar si hay un SBC conectado. Las llamadas que no puedan conectarse estarán sujetas al tratamiento definido por la Cuando una llamada no es contestada sección de las reglas de manejo de llamadas dentro de la configuración telefónica de un usuario.

Flujo de desvío de llamadas

El diagrama siguiente detalla la lógica para el desvío de llamadas (una vez habilitado) durante un evento de supervivencia. Esta lógica permanecerá en efecto hasta que el desvío de llamadas se deshabilite o se restablezcan las operaciones normales. Sin embargo, si el desvío de llamadas permanece habilitado después de que se restablezcan las operaciones normales, las llamadas desviadas harán un retorno en U desde la nube de Zoom Phone, al SBC y de vuelta a la nube, antes de entregarse al dispositivo del usuario. Por esta razón, el desvío de llamadas debe deshabilitarse con prontitud después de un evento de supervivencia.

1. Un llamante externo inicia una llamada a un número registrado en Zoom Phone y se enruta a través de la RTPC.

2. La llamada se enruta a la nube de Zoom Phone y el número marcado se identifica como afectado por el desvío de llamadas.

Si el desvío de llamadas no está habilitado, Zoom Phone seguirá la Cuando una llamada no es contestada lógica para ese usuario o extensión en particular.

1. Debido a que el desvío de llamadas está habilitado, Zoom no intentará alertar al usuario y en su lugar redirigirá la llamada hacia el número designado de desvío de llamadas a través de la RTPC.

2. La llamada se enruta desde la RTPC al SBC de supervivencia.

3. El SBC de supervivencia reenvía la llamada al módulo ZPLS.

4. El módulo ZPLS reenvía la llamada a los clientes registrados del usuario, si están conectados.

Consideraciones sobre el número de identificación de ubicación de emergencia (ELIN)

Un ELIN es un número telefónico exclusivo del sitio que comunica información de ubicación a los servicios de emergencia cuando se marca

Un número de identificación de ubicación de emergencia (ELIN) es un número telefónico dedicado que utilizan los puntos de respuesta de seguridad pública (PSAP) para identificar la dirección física de un llamante cuando se comunican con los servicios de emergencia. Para esta función, las empresas deben trabajar con su proveedor de servicio RTPC para asignar una dirección a un número telefónico, para ayudar a garantizar que la dirección esté listada dentro de una base de datos de identificación automática de ubicación (ALI) cuando la llamada sea recibida por un operador de PSAP.

Por ejemplo, considere un campus universitario que abarca varios edificios, con cada edificio representado por un sitio de Zoom Phone separado. Si un usuario marca a los servicios de emergencia durante un evento de supervivencia desde un teléfono o dispositivo asociado con el sitio, los servicios de emergencia recibirán automáticamente la dirección completa registrada para el sitio, siempre que la ubicación esté configurada y actualizada con el proveedor de servicios.

Cada sitio puede admitir múltiples ELINs

Los clientes pueden asignar múltiples ELINs a un sitio para disponer de una reserva de números de emergencia. En caso de una emergencia durante un evento de supervivencia, esto permitirá que varios llamantes tengan asignado de forma única un ELIN, lo que puede ayudar a los servicios de emergencia a localizar al llamante original si devuelven una llamada.

Además, un ELIN puede asignarse a un usuario o a un teléfono de área común, proporcionando una asignación de ELIN más granular que a nivel de sitio, ofreciendo una ubicación más precisa para los servicios de emergencia.

Durante un evento de supervivencia, todas las llamadas de emergencia son reemplazadas por el ELIN

Cuando un usuario realiza una llamada de emergencia durante un evento de supervivencia, el número desde el que llama el usuario, si hay uno disponible, será reemplazado por el ELIN designado a nivel de sitio. Esto permite que los usuarios que no tienen un número directo puedan llamar a los servicios de emergencia y ser localizables para devolución de llamada por parte del operador de emergencias.

Un número ELIN debe ser un número BYOC asociado con el trunk RTPC del SBC del sitio

El ELIN de un sitio debe ser un número BYOC que esté terminado en un trunk RTPC que se encuentre en el SBC de conmutación por error del sitio. Ningún otro tipo de número puede usarse.

El módulo ZPLS enrutarán automáticamente las llamadas de proveedores de emergencia al ELIN de vuelta a la extensión del usuario que marcó originalmente durante hasta 2 horas

Si un operador de emergencias devuelve una llamada al ELIN, el módulo ZPLS enrutarán la llamada de vuelta al usuario original que realizó la llamada de emergencia. El módulo ZPLS continuará enrutando las devoluciones de llamada de PSAP al llamante original durante hasta 2 horas. En este momento esta funcionalidad está limitada al primer llamante.

Una vez que un número telefónico se designa como ELIN, no puede asignarse a un usuario o dispositivo

Una vez que un administrador haya asignado un número BYOC como ELIN designado para un sitio, dicho número BYOC no podrá asignarse a ningún usuario u otra entidad de Zoom Phone a menos que se desasigne.

Los clientes son responsables de mantener y actualizar las direcciones físicas asociadas con su ELIN para cada sitio

Zoom no se responsabiliza de actualizar a los operadores BYOC con las direcciones físicas que correspondan a cada ELIN. Los clientes son responsables de garantizar que las direcciones de emergencia estén correctamente mapeadas a la dirección física correspondiente.

Consideraciones de enrutamiento RTPC

Cuando el modo de supervivencia está activo, los paquetes de medios se enrutan a través del módulo ZPLS

Cuando el modo de supervivencia está habilitado, los clientes no se comunican directamente con un SBC u otros clientes internos; en su lugar, los paquetes de medios se anclan o “hairpinned” a través del módulo ZPLS, sin soporte para descarga de medios.

El diagrama siguiente representa la ruta de señalización y medios para llamadas internas y externas activas.

Las llamadas intentarán enrutar localmente primero

Siempre que sea posible, el módulo ZPLS intentará enrutar las llamadas originadas desde clientes registrados de Zoom a destinos registrados localmente. Las llamadas solo se reenvían al SBC si el destino contenido en el campo Request URI de la invitación SIP entrante no coincide con una extensión registrada.

Una extensión registrada es una extensión corta sin el código del sitio, una extensión larga con el código del sitio, un número asignado registrado en Zoom o un número BYOC asignado. Los administradores deben tener en cuenta que el módulo ZPLS actualiza estos datos cada 10 horas.

Durante un evento de supervivencia, las llamadas externas salientes mostrarán el número BYOC del usuario

Durante un evento de supervivencia, las llamadas externas salientes desde dispositivos registrados en ZPLS contendrán el número de llamada BYOC. El diagrama siguiente representa el flujo de llamadas en modo de supervivencia para un usuario:

Las llamadas devueltas pueden enrutar al número BYOC de un usuario

Debido a que las llamadas externas salientes realizadas durante un evento de supervivencia usarán un número BYOC, los llamantes externos pueden devolver una llamada utilizando un número BYOC en lugar del número registrado en Zoom del usuario. Si el evento de supervivencia ha terminado, las llamadas volverán a enrutar a través de la nube si se configura la prioridad de enrutamiento correcta. Sin embargo, si el evento continúa, el SBC enrutará la llamada al módulo ZPLS y al dispositivo registrado del cliente.

Códecs de supervivencia compatibles

Los códecs de supervivencia compatibles son Opus, G.711 μ-law, G.711 A-law y G.729. No se admite la transcodificación ni el transrating de códecs de audio. Todas las partes implicadas en una llamada activa deben admitir el mismo códec y la misma frecuencia de muestreo.

Consideraciones sobre los grupos de distribución de supervivencia

Esta sección trata las consideraciones para los grupos de distribución de supervivencia (SDG). Los clientes que no planean utilizar SDG o integrar el módulo ZPLS con conectividad RTPC pueden omitir esta sección sin consecuencia.

Los grupos de distribución de supervivencia ofrecen opciones de enrutamiento de llamadas matizadas durante un evento de supervivencia

Los grupos de distribución de supervivencia (SDG) brindan a las empresas opciones de enrutamiento de llamadas matizadas, como colas de llamadas y menús de respuesta de voz interactiva (IVR), durante un evento de supervivencia. Con los SDG, las empresas pueden seguir ofreciendo servicios telefónicos básicos y configuraciones de enrutamiento de llamadas (similares a colas de llamadas, recepcionistas automáticos y grupos de línea compartida) hasta que se restablezcan las operaciones normales.

Los SDG no son lo mismo que los grupos de distribución de operación estándar y deben crearse y mantenerse por separado

Aunque los SDG ofrecen una funcionalidad de enrutamiento de llamadas similar a la de los grupos de distribución en operaciones estándar, los SDG son únicos y específicos para eventos de supervivencia y, por consiguiente, deben crearse y mantenerse por separado. En otras palabras, los SDG no heredan los ajustes o configuraciones de un grupo de distribución en operación estándar (p. ej., cola de llamadas, recepcionista automático, IVR, etc.)

Los SDG funcionan mejor emparejados con una integración BYOC-RTPC y con el desvío de llamadas habilitado

Aunque los SDG pueden proporcionar soporte solo interno (es decir, llamadas no RTPC), funcionan mejor emparejados con una integración BYOC-RTPC. Con un SDG habilitado para RTPC, una vez que el desvío de llamadas esté habilitado durante un evento de supervivencia, un número principal de la empresa puede enrutar al número designado del SDG, y la llamada seguirá el perfil de enrutamiento configurado. Esto permite a una empresa ofrecer una experiencia de flujo de llamadas coherente para los llamantes externos hasta que se restablezcan las operaciones normales.

El diagrama siguiente demuestra la lógica de enrutamiento de llamadas para un SDG habilitado para RTPC:

Los SDG pueden personalizarse de las siguientes maneras

Los SDG admiten las siguientes opciones:

• Número de extensión dedicado

• Número de marcación directa interna asignado

• Zona horaria

• Horario comercial

• Saludos grabados

• Miembros del grupo

• Ruta a:

  • Usuario

  • Menú de respuesta de voz interactiva (IVR)

  • Miembros del grupo

  • Número de teléfono

• Distribución de llamadas:

  • Simultánea

  • Secuencial

Consideraciones de hardware y redes

Esta sección trata las consideraciones de hardware y redes para el módulo ZPLS, una integración de SBC, clientes de Zoom y dispositivos telefónicos. Tras leer esta sección, podrá comprender las comunicaciones y configuraciones de red necesarias para una implementación de ZPLS.

Esta sección está dedicada al despliegue de hardware y a las consideraciones de diseño. Consulte la sección sobre implementación de ZPLS para instrucciones de implementación paso a paso.

Despliegue del módulo ZPLS y consideraciones de red

El módulo ZPLS requiere una dirección IPv4 estática dentro de su red

El módulo ZPLS debe desplegarse en una LAN interna con una dirección IPv4 estática accesible para dispositivos de Zoom Phone y clientes de escritorio. El módulo ZPLS no admite direcciones IPv6 en este momento.

El módulo ZPLS debe mantener conexiones HTTPS periódicas con la nube de Zoom Phone

El módulo ZPLS requiere conexiones HTTPS periódicas con la nube de Zoom Phone para sincronizar la configuración de la cuenta y del usuario.

En la mayoría de los casos, un módulo ZPLS puede desplegarse en una LAN interna dentro de la red de un cliente. Alternativamente, en algunas circunstancias puede utilizarse una red DMZ; sin embargo, los administradores de red deben garantizar que la comunicación sea posible a través del firewall empresarial. En ambos casos, se requiere que los administradores ajusten la política del firewall corporativo para habilitar la comunicación entre el módulo ZPLS y la nube de Zoom.

El módulo ZPLS debe mantener un ping OPTIONS regular con la nube de Zoom Phone

Mientras está en estado inactivo, el módulo ZPLS debe mantener un ping de mantenimiento OPTIONS con la nube de Zoom Phone para supervisar la conectividad. En caso de que tanto los dispositivos clientes como el módulo ZPLS dentro de un sitio pierdan conectividad con la nube de Zoom Phone, los clientes y dispositivos compatibles se registrarán en el módulo ZPLS mediante autenticación SIP Digest sobre TLS v1.2.

Consideraciones de despliegue y red del SBC

Un SBC debe ser accesible desde ZPLS y la nube de Zoom siempre que sea posible

Los clientes deben garantizar que el SBC mantenga conectividad tanto con el módulo ZPLS como con la nube de Zoom Phone, siempre que sea posible. Los clientes pueden provisionar un SBC con doble NIC configurado con una dirección IPv4 privada y pública, o asegurarse de que existan reglas NAT 1:1 estáticas en el firewall perimetral además de abrir los puertos necesarios.

Un SBC debe mantener conectividad TLS y UDP entre la nube de Zoom Phone y el módulo ZPLS

Durante las operaciones rutinarias, un SBC debe mantener conectividad TLS y UDP tanto con la nube de Zoom Phone como con el módulo ZPLS del sitio asociado. Esta conexión se utiliza para enrutar cualquier llamada potencial a un número de teléfono listado en BYOC a través de la nube de Zoom Phone. El mecanismo de mantenimiento OPTIONS se habilita automáticamente entre ZPLS y el SBC y es opcional entre el SBC y la nube.

Consideraciones sobre clientes de Zoom y dispositivos telefónicos

Los clientes y dispositivos deben poder detectar el módulo ZPLS del sitio dentro de la red de área local

Los clientes y los dispositivos compatibles habilitados para la supervivencia telefónica detectan el módulo ZPLS de conmutación por error correspondiente desde la nube de Zoom Phone durante el proceso de arranque. Sin embargo, el módulo ya debe estar vinculado al sitio del sistema telefónico con una dirección IPv4 interna detectable.

Los dispositivos deben tener una IP estática o recibir una IP privada mediante un servidor DHCP local

Para mitigar problemas potenciales, a los dispositivos telefónicos se les debe asignar una IP estática o una IP interna mediante un servidor DHCP local. Si a un dispositivo no se le asigna una IP estática o no hay disponible un servidor DHCP durante un evento de supervivencia, los dispositivos telefónicos pueden no registrarse.

Los clientes y dispositivos deben mantener un ping OPTIONS regular con la nube de Zoom Phone

Al igual que el módulo ZPLS, los clientes y dispositivos compatibles deben mantener un ping de mantenimiento OPTIONS con la nube de Zoom Phone para determinar el estado de conectividad del centro de datos. En caso de una interrupción, el cliente continúa enviando mensajes de mantenimiento para detectar el retorno del servicio en la nube e iniciar la reanudación de las operaciones normales. Este proceso es automático y no se puede deshabilitar.

Firewall y flujo de datos de la red

Consulte la sección sobre Puertos de red y flujo de datos.