Consideraciones de Integraciones con RTPC

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

Consideraciones de Integración de SBC

Requisitos de SBC

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

TLS 1.2 y SRTP
Compatibilidad con Mutual TLS
Protocolo de Iniciación de Sesión (SIP)
DTMF (RFC-2833)
Ocultación de topología (RFC-5853)
Oferta anticipada 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 confiable

Para la conectividad RTPC, los Clientes deben proporcionar un controlador de borde de sesión (SBC) conectado 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 implementado en el SBC puede depender del mismo servicio de Internet que está sufriendo una interrupción. Debido a esta posibilidad, los Clientes deben considerar una conexión terciaria confiable para la conectividad RTPC.

Se puede usar cualquier SBC certificado de Zoom Phone BYOC

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 existente de Zoom Phone no requieren un SBC adicional o independiente 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 de Zoom de 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 opción 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 usar 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, de otro modo, una conectividad estable.

No seguir 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 esté disponible tras un evento de supervivencia, un SBC puede intentar temporalmente enrutar los 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 período intermedio.

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

Cuando el modo de supervivencia está activo, las llamadas desde ZPLS al SBC deben enrutar al troncal SIP de 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 de 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 el 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 dentro de los sitios afectados podrían no estar disponibles a menos que las llamadas a sus números principales se desvíen a un número alternativo asociado con un SBC local.

Los 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 local 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 local (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 local.

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 mediante entrada manual o una carga masiva de 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 del desvío de llamadas, al dispositivo cliente se le asignarán al menos tres números:

Una extensión interna con el código de sitio antepuesto
Un número RTPC proporcionado por Zoom
Un número RTPC BYOC

Los números de teléfono 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 reenviar múltiples Números de teléfono al mismo número BYOC.

Por ejemplo, si a John se le asigna el número de teléfono X55-555-5555, el número de teléfono de John puede reenviarse al número de operadora de su edificio al X99-999-9999. Del mismo modo, los compañeros de trabajo de John también pueden hacer que sus números (X55-555-5554, X55-555-5553, etc.) se reenvíen al X99-999-9999. Alternativamente, cada usuario puede hacer que su número de teléfono se reenvíe a un número completamente único, como X55-555-5554 Enrutamiento al X99-999-9998, y X55-555-5553 Enrutamiento al X99-999-9997. Sin embargo, ningún usuario individual puede hacer que su número se reenvíe tanto al X99-999-9999 como al X99-999-9998.

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

Aunque un administrador puede preaprovisionar la lógica de desvío de llamadas para un sitio con anticipación, la funcionalidad de desvío de llamadas debe permanecer deshabilitada hasta que ocurra un Evento de capacidad de supervivencia. Si el desvío de llamadas está habilitado 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 de teléfono BYOC asociado, omitiendo 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 un administrador con una conexión a internet funcional

Durante un Evento de modo de capacidad de 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 ser habilitado por un usuario autorizado o un administrador con una conexión a internet funcional, como un plan de datos telefónicos, o una conexión a internet alternativa dentro de una Ubicación diferente.

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

Las reglas de desvío de llamadas pueden aplicarse a todo el sitio o a números individuales

Durante un Evento de capacidad 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 de teléfono de un usuario, Zoom no hará sonar un 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á Enrutamiento de 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 RTPC al SBC de la empresa.

Por ejemplo, un sitio está experimentando un Evento de modo de capacidad 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 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 cambio, todas las llamadas continuarán Enrutamiento a través de la RTPC hacia el SBC del cliente.

Si el desvío de llamadas no está habilitado para un usuario durante un Evento de capacidad de supervivencia, las llamadas Entrantes seguirán las preferencias de administración de llamadas de cada usuario

Si el desvío de llamadas no está habilitado durante un Evento de capacidad de supervivencia, las llamadas Entrantes se tratarán de acuerdo con la lógica de administración 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, las personas que llaman estarán sujetas a las reglas definidas por la Cuando una llamada no es respondida sección de preferencias de administración de llamadas.

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

El desvío de llamadas para capacidad de supervivencia solo se aplica a las llamadas Enrutamiento a través de la RTPC y/o la nube de Zoom Phone. Las llamadas que se originan desde extensiones registradas en Zoom dentro del mismo sitio intentarán conectarse a través del módulo ZPLS primero, y por la RTPC en segundo lugar si un SBC está conectado. Las llamadas que no puedan conectarse, de otro modo, estarán sujetas al tratamiento definido por la Cuando una llamada no es respondida sección de las reglas de administración de llamadas dentro de la Configuración del teléfono 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 capacidad de supervivencia. Esta lógica permanecerá en vigor 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 reenviadas harán hairpin desde la nube de Zoom Phone, al SBC, y de vuelta a la nube, antes de ser entregadas al Dispositivo de un usuario. Por esta razón, el desvío de llamadas debe deshabilitarse de inmediato después de un Evento de capacidad de supervivencia.

Una persona que llama desde el exterior inicia una llamada a un número registrado en Zoom Phone, y se enruta a través de la RTPC.
La llamada se enruta a la nube de Zoom Phone, y el número de teléfono 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 respondida lógica para ese usuario o extensión en particular.

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 para desvío de llamadas a través de la RTPC.
La llamada se enruta desde la RTPC al SBC de capacidad de supervivencia.
El SBC de capacidad de supervivencia reenvía la llamada al módulo ZPLS.
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 una persona que llama al llamar a los servicios de emergencia. Para esta Características, las empresas deben trabajar con su proveedor de servicios RTPC para asignar una dirección a un número de teléfono, con el fin de ayudar a garantizar que la dirección figure en 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 múltiples 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 capacidad 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 ELIN

Clientes pueden Asignar múltiples ELIN a un sitio para un conjunto de recursos de números de emergencia. En caso de una emergencia durante un Evento de capacidad de supervivencia, esto permitirá que múltiples personas que llaman tengan cada una un ELIN asignado de forma única, lo que puede ayudar a los servicios de emergencia a comunicarse con la persona que llamó originalmente si devuelven la llamada.

Además, un ELIN puede asignarse a un usuario o a un teléfono de área común, lo que proporciona una asignación de ELIN más granular que la del nivel de sitio, y ofrece una Ubicación más precisa para los servicios de emergencia.

Durante un Evento de capacidad de supervivencia, todas las llamadas de emergencia se reemplazan por el ELIN

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

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

El ELIN de un sitio debe ser un número BYOC que termina en un troncal de RTPC que está ubicado en el SBC de conmutación por error del sitio. No se puede usar ningún otro tipo de número.

El módulo ZPLS enrutará automáticamente las llamadas del proveedor de emergencias al ELIN de vuelta a la extensión del usuario que marcó originalmente durante un máximo de 2 horas

Si un operador de emergencias devuelve una llamada al ELIN, el módulo ZPLS enrutará 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 autor original de la llamada durante un máximo de 2 horas. En este momento, esta funcionalidad está limitada al primer autor de la llamada.

Una vez que un número de teléfono se designa como ELIN, no se puede asignar a un usuario o Dispositivo

Una vez que un administrador ha asignado un número BYOC como el ELIN designado para un sitio, el número BYOC no se puede asignar a ningún usuario ni a ninguna 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 asume la responsabilidad de actualizar las direcciones físicas de los operadores BYOC que se correlacionan con cada ELIN. Los Clientes son responsables de garantizar que las direcciones de emergencia estén correctamente asignadas a la dirección física adecuada.

Consideraciones de Enrutamiento de RTPC

Cuando el modo de supervivencia está activo, los paquetes multimedia 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 ni con otros clientes internos; en su lugar, los paquetes multimedia se anclan o se «hairpinnean» a través del módulo ZPLS, sin compatibilidad con la descarga de medios.

El siguiente diagrama muestra la ruta de señalización y medios para las 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 Zoom registrados a destinos registrados localmente. Las llamadas solo se reenvían al SBC si el destino contenido en el campo Request URI de la SIP Invitar 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 una vez 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 siguiente diagrama muestra el flujo de llamadas en modo de supervivencia para un usuario:

Las llamadas devueltas pueden dirigirse 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 usando un número BYOC en lugar del número de teléfono registrado en Zoom de un usuario. Si el Evento de supervivencia ha terminado, las llamadas volverán a Enrutamiento a través de la nube si la prioridad de Enrutamiento correcta está configurada. Sin embargo, si el Evento está en curso, el SBC enrutará la llamada al módulo ZPLS y al Dispositivo registrado por el cliente.

Códecs de supervivencia admitidos

Los códecs de supervivencia admitidos son Opus, G.711 μ-law, G.711 A-law y G.729. No se admite la transcodificación ni la tarificación de audio de códecs de audio. Todas las partes involucradas en una llamada activo deben admitir el mismo códec y la misma tasa de muestreo.

Consideraciones sobre el grupo de distribución de supervivencia

Esta sección analiza las consideraciones para los Grupos de distribución de supervivencia (SDGs). Clientes que no planeen utilizar SDGs o integrar el módulo ZPLS con conectividad RTPC pueden omitir esta sección sin consecuencia.

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 (SDGs) ofrecen a las empresas opciones de Enrutamiento de llamadas matizadas —como cola de llamadas y menús de Respuesta de voz interactiva (IVR)— durante un evento de supervivencia. Con SDGs, las empresas pueden continuar dando Soporte a los servicios básicos de telefonía y a las configuraciones de Enrutamiento de llamadas (similares a cola de llamadas, contestador automático y grupos de línea compartida) hasta que se restablezcan las operaciones estándar.

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

Aunque los SDGs ofrecen una funcionalidad de Enrutamiento de llamadas similar a la de los grupos de distribución de operación Estándar, los SDGs son únicos y específicos para eventos de supervivencia y, en consecuencia, deben crearse y mantenerse por separado. En otras palabras, los SDGs no heredan las Configuración o configuraciones de un grupo de distribución de operación estándar (es decir, cola de llamadas, contestador automático, IVR, etc.)

Los SDG se combinan mejor con una Integraciones BYOC-RTPC y el desvío de llamadas habilitado

Aunque los SDG pueden proporcionar soporte solo interno (es decir, llamadas que no son de RTPC), se combinan mejor con una Integraciones 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 de teléfono del SDG designado, y la llamada seguirá el perfil de Enrutamiento configurado. Esto permite que una empresa proporcione una experiencia de flujo de llamadas coherente para las personas que llaman desde el exterior hasta que se restablezcan las operaciones estándar.

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

Los SDG se pueden personalizar de las siguientes maneras

Los SDG admiten las siguientes opciones:

Número de número de extensión dedicado
Número de marcado interno directo asignado
Zona horaria
horario comercial
Saludos grabados
Miembros del grupo
Enrutar 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 analiza las consideraciones de hardware y redes para el módulo ZPLS, una Integraciones de SBC, los clientes de Zoom y los dispositivos telefónicos. Después de leer esta sección, puede esperar comprender las comunicaciones de red y configuraciones necesarias para una implementación de ZPLS.

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

Consideraciones de implementación y red del módulo ZPLS

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

El módulo ZPLS debe implementarse en una LAN interna con una dirección IPv4 estática accesible para los dispositivos de Zoom Phone y los 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 el usuario.

En la mayoría de los casos, un módulo ZPLS puede implementarse 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 asegurarse de que la comunicación sea posible a través del firewall Empresarial. En cualquiera de los casos, los administradores deben ajustar 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 periódico con la nube de Zoom Phone

Mientras está en estado inactivo, el módulo ZPLS debe mantener un ping keepalive OPTIONS con la nube de Zoom Phone para supervisar la conectividad. En el caso de que tanto los dispositivos cliente como el módulo ZPLS dentro de un sitio pierdan la 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 implementación y red de SBC

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

Los Clientes deben asegurarse de que el SBC mantenga la conectividad tanto con el módulo ZPLS como con la nube de Zoom Phone, siempre que sea posible. Los Clientes pueden aprovisionar un SBC de doble NIC configurado con una dirección IPv4 privada y pública, o asegurarse de 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 la conectividad TLS y UDP entre la nube de Zoom Phone y el módulo ZPLS

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

Consideraciones para clientes de Zoom y dispositivos telefónicos

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

Clientes y dispositivos compatibles habilitados para la supervivencia telefónica descubren el módulo ZPLS de conmutación por error adecuado desde la nube de Zoom Phone durante el proceso de arranque. Sin embargo, el módulo ya debe estar vinculado al sitio del sistema de telefonía con una dirección IPv4 detectable internamente.

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

Para mitigar posibles problemas, 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 si no hay un servidor DHCP disponible durante un evento de supervivencia, es posible que los dispositivos telefónicos no puedan registrarse.

Los clientes y dispositivos deben mantener un ping OPTIONS periódico con la nube de Zoom Phone

De forma similar al módulo ZPLS, los clientes y dispositivos compatibles deben mantener un ping keepalive 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 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 se puede deshabilitar.

Firewall y flujo de datos de red

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

Última actualización hace 4 meses

¿Te fue útil?