Consideraciones de integración con la RTPC

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

Consideraciones de integración del SBC

Requisitos de SBC

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

• TLS 1.2 y SRTP

• Compatibilidad con Mutual TLS

• Session Initiation Protocol (SIP)

• DTMF (RFC-2833)

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

• SIP Early Offer (obligatorio)

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

Las integraciones PSTN requieren un SBC y un proveedor externo confiable

Para la conectividad PSTN, los clientes deben proporcionar un controlador de frontera de sesión (SBC) conectado ya sea a una conexión heredada, o a un troncal SIP con una conexión celular o alternativa (por ejemplo, DSL). Los clientes deben tener en cuenta que cualquier troncal SIP desplegada en el SBC puede depender del mismo servicio de internet que está sufriendo una interrupción. Debido a esta posibilidad, los clientes deberían considerar una conexión terciaria confiable para la conectividad PSTN.

Cualquier SBC certificado BYOC de Zoom Phone puede utilizarse

Cualquier controlador de frontera de sesión (SBC) que esté certificado para Zoom Phone también puede utilizarse con el módulo ZPLS. Los clientes en un plan BYOC de Zoom Phone existente no requieren un SBC adicional o separado para 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 como tercera

Los SBC de los clientes deben enrutar las llamadas entrantes desde la PSTN 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 en otras circunstancias.

No seguir esta lógica puede resultar en fallos de 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 para Cuando una llamada no es contestada durante este periodo interino.

Las llamadas salientes desde el módulo ZPLS deben enrutar al SBC y al troncal SIP PSTN

Cuando el modo de supervivencia está activo, las llamadas desde ZPLS hacia el SBC deben enrutar al troncal SIP PSTN 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 de teléfono proporcionados por Zoom Phone no serán accesibles externamente a menos que se redirijan mediante desvío de llamadas

Durante un evento de supervivencia, los números de teléfono proporcionados por Zoom no serán accesibles externamente desde la perspectiva de la nube. En consecuencia, los usuarios ubicados en ubicaciones afectadas pueden no ser localizables a menos que las llamadas a sus números principales se reenví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 usan un BYOC basado en las instalaciones no requieren configuraciones avanzadas y pueden omitir el desvío de llamadas agregando una ruta terciaria a su módulo ZPLS desde su SBC

Los clientes que usan 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 al módulo ZPLS desde el SBC ubicado en las instalaciones.

Las configuraciones de desvío de llamadas son establecidas por un administrador o usuario autorizado desde el portal web

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

Los usuarios configurados para el 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, al dispositivo cliente se le asignará al menos tres números:

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

2. Un número PSTN proporcionado por Zoom

3. Un número PSTN BYOC

Los números de teléfono pueden ser desviados a un máximo de un número BYOC

Cada número de Zoom Phone puede ser desviado a un máximo de uno otro número BYOC. Sin embargo, puede desviar múltiples números de teléfono 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 de su edificio en 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 enrutar a X99-999-9998, y X55-555-5553 enrutar 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 se habilita durante las operaciones rutinarias, todas las llamadas entrantes a un número registrado en Zoom Phone se redirigirán al SBC local y al número BYOC asociado, pasando por alto los servicios de Zoom Phone. Por lo tanto, para mantener el enrutamiento regular de Zoom Phone, el desvío de llamadas debe estar deshabilitado durante las operaciones rutinarias.

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

Durante un evento en modo de supervivencia, se supone que la conexión a internet de un sitio no está disponible. Sin embargo, dado 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 telefónicos, o una conexión a internet alterna 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 a todo el sitio 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, incluso si mantiene 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 de teléfono está marcado para desvío de llamadas, todas las llamadas se enrutarán a través de la PSTN hacia el SBC de la empresa.

Por ejemplo, un sitio está experimentando un evento en modo de 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 de su 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 será 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 enrutándose a través de la PSTN hacia el SBC del cliente.

Si el desvío de llamadas no está habilitado 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 alternativo 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 PSTN

El desvío de llamadas para supervivencia solo se aplica a llamadas enrutadas a través de la PSTN y/o la nube de Zoom Phone. Las llamadas que se originan desde extensiones registradas en Zoom dentro del mismo sitio intentarán conectarse primero a través del módulo ZPLS, y a la PSTN 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 siguiente diagrama 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 estándar. Sin embargo, si el desvío de llamadas permanece habilitado después de que se restablezcan las operaciones estándar, las llamadas desviadas harán un hairpin desde la nube de Zoom Phone, al SBC y de vuelta a la nube, antes de ser entregadas al dispositivo del usuario. Por esta razón, el desvío de llamadas debe deshabilitarse de forma pronta 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 PSTN.

2. La llamada se enruta a la nube de Zoom Phone y se identifica que el número marcado está 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 PSTN.

2. La llamada se enruta desde la PSTN hacia el 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 de teléfono 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 de teléfono dedicado que utilizan los Puntos de Respuesta de Seguridad Pública (PSAP) para identificar la dirección física de un llamante al contactar a los servicios de emergencia. Para esta función, las empresas deben trabajar con su proveedor de servicio PSTN para asignar una dirección a un número de teléfono, 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 separado de Zoom Phone. Si un usuario llama 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 múltiples llamantes tengan cada uno un ELIN asignado de forma única, lo que puede ayudar a los servicios de emergencia a localizar al llamante original si devuelven la 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 el nivel del 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 que llama del usuario, si está disponible, será reemplazado por el ELIN designado a nivel de sitio. Esto permite que los usuarios que no tienen un número directo llamen a los servicios de emergencia y sean localizables para devolución de llamada por parte del operador de emergencia.

Un número ELIN debe ser un número BYOC asociado con el troncal PSTN del SBC del sitio

El ELIN de un sitio deben debe ser un número BYOC que esté terminado en un troncal PSTN ubicado en el SBC de conmutación por error del sitio. Ningún otro tipo de número puede utilizarse.

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

Si un operador de emergencia 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 de teléfono se designa como ELIN, no puede asignarse a un usuario o dispositivo

Una vez que un administrador ha asignado un número BYOC como ELIN designado para un sitio, el número BYOC no puede 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 hace responsable de actualizar a los operadores BYOC con las direcciones físicas que correlacionan con 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 PSTN

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 señalización y la ruta de 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 de sitio, una extensión larga con el código de 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 muestra 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 la llamada usando un número BYOC en lugar del número registrado de Zoom del usuario. Si el evento de supervivencia ha terminado, las llamadas se enrutarán de nuevo a través de la nube si se ha configurado la prioridad de enrutamiento correcta. Sin embargo, si el evento continúa, el SBC enrutarán la llamada al módulo ZPLS y al dispositivo registrado por el cliente.

Códecs compatibles para supervivencia

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

Consideraciones de grupos de distribución de supervivencia

Esta sección trata consideraciones para los Grupos de Distribución de Supervivencia (SDG). Los clientes que no planeen utilizar SDG o integrar el módulo ZPLS con conectividad PSTN pueden omitir esta sección sin consecuencias.

Los grupos de distribución de supervivencia proporcionan 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 continuar soportando los servicios telefónicos básicos y las 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 estándar.

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

Aunque los SDG ofrecen funcionalidades de enrutamiento de llamadas similares a los grupos de distribución de operación estándar, los SDG son únicos y específicos para eventos de supervivencia y, en consecuencia, deben construirse y mantenerse por separado. En otras palabras, los SDG no será heredan los ajustes o configuraciones de un grupo de distribución de operación estándar (es decir, cola de llamadas, recepcionista automático, IVR, etc.)

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

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

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

Los SDG pueden personalizarse de las siguientes maneras

Los SDG admiten las siguientes opciones:

• Número de extensión dedicado

• Número DID (direct inward dial) asignado

• Zona horaria

• Horario comercial

• Saludos grabados

• Miembros del grupo

• Enviar a:

  • Usuario

  • Menú de respuesta de voz interactiva (IVR)

  • Miembros del grupo

  • Número de teléfono

• Distribución de llamadas:

  • Simultáneo

  • Secuencial

Consideraciones de hardware y redes

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

Esta sección está dedicada al despliegue de hardware y al consideraciones de diseño. Consulte la sección sobre despliegue de ZPLS para instrucciones de despliegue 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 de los usuarios.

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, se puede usar una red DMZ en algunas circunstancias; sin embargo, los administradores de red deben garantizar que la comunicación sea posible a través del firewall empresarial. En cualquier caso, 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é inactivo, el módulo ZPLS debe mantener un ping keepalive de OPTIONS con la nube de Zoom Phone para supervisar la conectividad. En caso de que tanto los dispositivos cliente 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 usando autenticación SIP Digest sobre TLS v1.2.

Consideraciones de despliegue y red para el SBC

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

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

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 keepalive de OPTIONS se habilita automáticamente entre ZPLS y el SBC y es opcional entre el SBC y la nube.

Consideraciones para clientes y dispositivos telefónicos de Zoom

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

Los clientes y dispositivos compatibles habilitados para la supervivencia telefónica descubren el módulo ZPLS de conmutación por error apropiado 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 descubrible.

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 un dispositivo no recibe una IP estática, o no hay un servidor DHCP disponible durante un evento de supervivencia, los dispositivos telefónicos pueden fallar al registrarse.

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

Al igual que el módulo ZPLS, los clientes y dispositivos compatibles deben mantener un ping keepalive de OPTIONS con la nube de Zoom Phone para determinar el estado de conectividad con el centro de datos. En caso de una interrupción, el cliente continúa enviando mensajes keepalive 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 puede desactivarse.

Firewall y flujo de datos de red

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