# Consideraciones de Integraciones de RTPC
Esta sección se aplica a los clientes que estén considerando integrar el módulo ZPLS con una SBC y una conexión RTPC para mayor supervivencia. Los clientes que no planeen 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 una SBC con Zoom para supervivencia, una SBC debe cumplir con los siguientes requisitos:
* TLS 1.2 y SRTP
* Soporte para TLS mutuo
* Protocolo de inicio de sesión (SIP)
* DTMF (RFC-2833)
* Ocultación de topología (RFC-5853)
* Oferta temprana SIP (**obligatorio**)
* Códecs Opus, G.711 μ-law, G.711 A-law y G.729
#### Las Integraciones RTPC requieren una 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 la 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.
#### Cualquier SBC certificada por Zoom Phone BYOC puede usarse
Cualquier controlador de borde de sesión (SBC) que esté [certificada para Zoom Phone](https://support.zoom.us/hc/en-us/articles/360001299063-Zoom-Phone-Certified-Hardware#h_ec5008d4-3581-46e7-a06d-32599511d089) también puede usarse con el módulo ZPLS. Los clientes con un plan Zoom Phone BYOC existente no requieren una SBC adicional o separada a efectos de supervivencia.
#### Los certificados DigiCert de Zoom deben instalarse en la SBC
Para establecer conectividad TLS tanto con el módulo ZPLS como con la nube de Zoom, los [certificados raíz e intermedios de DigitCert](https://support.zoom.us/hc/en-us/articles/360044092031) de Zoom deben instalarse en la SBC.
#### Las 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 como tercera
Las 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 la SBC y los centros de datos de Zoom Phone deberían mantener de lo contrario una conectividad estable.
No seguir esta lógica puede resultar en fallos en la entrega de llamadas, ya que el módulo ZPLS no puede enrutar llamadas a dispositivos registrados en la nube.
{% hint style="info" %}
Una vez que la nube de Zoom esté Disponible tras un evento de supervivencia, una 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 respondida**](https://support.zoom.us/hc/en-us/articles/360059966372-Customizing-call-handling-settings#h_86f4bf1b-51ea-4d70-9e40-4a84a5ca1c2c) durante este período intermedio.
{% endhint %}
#### Las llamadas Salientes desde el módulo ZPLS deben enrutar a la SBC y al troncal SIP RTPC
Cuando el modo de supervivencia está activo, las llamadas desde ZPLS hacia la SBC deben enrutar al troncal 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 a la SBC configurada para supervivencia en formato E.164.
### Consideraciones de Desvío de llamadas de supervivencia local
#### 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 dentro de las ubicaciones afectadas pueden no estar disponibles a menos que las llamadas a sus números principales se desvíen a un número alternativo asociado con una SBC local.
{% hint style="info" %}
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).
{% endhint %}
#### Los clientes que usan un BYOC basado en local no requieren configuraciones avanzadas, y pueden omitir el desvío de llamadas añadiendo una ruta terciaria a su módulo ZPLS desde su SBC
Los clientes que usan un plan BYOC basado en 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 añadir una ruta terciaria al módulo ZPLS desde la 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](#_1od0waijmvaz) desde el portal web mediante [entrada manual o una carga masiva de CSV](#_aezu04x8z043).
#### 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á *al menos* tres números:
1. Una extensión interna con el código del sitio antepuesto
2. Un número RTPC proporcionado por Zoom
3. Un número RTPC BYOC
#### Los números de teléfono pueden desviarse a un máximo de un número BYOC
Cada número de Zoom Phone puede desviarse a un máximo de **un** otro número BYOC. Sin embargo, puede desviar varios 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 desviarse al número de operador de su edificio en X99-999-9999. De manera similar, los compañeros de trabajo 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 de teléfono 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 anticipació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 rutinarias, todas las llamadas Entrantes a un número registrado en Zoom Phone se redirigirán a la SBC local y al número de teléfono BYOC asociado, omitiendo los servicios de Zoom Phone. Por lo tanto, para mantener el enrutamiento normal de Zoom Phone, el desvío de llamadas debe permanecer deshabilitado durante las operaciones rutinarias.
#### El desvío de llamadas solo puede ser Habilitar por un usuario autorizado o un administrador con una conexión a internet funcional
Durante un Evento de modo 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 Habilitar por un usuario autorizado o un administrador con una conexión a internet funcional, como un plan de datos del teléfono o una conexión a internet alternativa dentro de una Ubicación diferente.
{% hint style="info" %}
Para minimizar el tiempo de inactividad y garantizar la continuidad del negocio, 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 supervivencia.
{% endhint %}
#### 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á Habilitar para el número de teléfono de un usuario, Zoom no hará sonar un cliente registrado en la nube de un usuario, incluso si mantiene una conexión independiente a la nube
Cuando el desvío de llamadas está Habilitar 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 RTPC al SBC de la empresa.
Por ejemplo, un sitio está experimentando un Evento de 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 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 enrutándose a través de la RTPC al SBC del cliente.
#### Si el desvío de llamadas no está Habilitar para un usuario durante un Evento 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á Habilitar durante un Evento de supervivencia, las llamadas entrantes se tratarán de acuerdo con la [lógica de administración de llamadas](https://support.zoom.us/hc/en-us/articles/360059966372-Customizing-call-handling-settings) 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 las llamadas entrantes de la 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 en segundo lugar por la RTPC si hay un SBC conectado. Las llamadas que no puedan conectarse 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 Habilitar) 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 Habilitar *después de* que se restablezcan las operaciones Estándar, las llamadas desviadas harán hairpin desde la nube de Zoom Phone, al SBC, y de regreso a la nube, antes de ser entregadas al Dispositivo de un usuario. Por esta razón, el desvío de llamadas debe deshabilitarse rápidamente después de un Evento de supervivencia.
1. Una persona que llama externamente inicia una llamada a un número registrado en Zoom Phone, y esta se enruta a través de la RTPC.
2. 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.
{% hint style="info" %}
Si el desvío de llamadas no está Habilitar, Zoom Phone seguirá la **Cuando una llamada no es respondida** lógica para ese usuario o extensión en particular.
{% endhint %}
3. Debido a que el desvío de llamadas está Habilitar, Zoom no intentará alerta 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.
4. La llamada se enruta desde la RTPC al SBC de supervivencia.
5. El SBC de supervivencia reenvía la llamada al módulo ZPLS.
6. 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 de RTPC para mapear una dirección a un número de teléfono, lo que ayuda a garantizar que la dirección figure dentro de una base de datos de identificación automática de Ubicación (ALI) cuando la llamada sea recibida por un operador del PSAP.
Por ejemplo, considere un campus universitario que abarca varios edificios, con cada edificio representado por un sitio de Zoom Phone independiente. Si un usuario marca a los servicios de emergencia durante un Evento de supervivencia desde un teléfono o Dispositivo [asociado con el sitio](#_ggwzik1hd9xi), los servicios de emergencia recibirán automáticamente la dirección completa grabar para el sitio, siempre que la Ubicación esté configurada y actualizada con el proveedor de servicios.
#### Cada sitio puede admitir varios ELIN
Clientes pueden Asignar varios ELIN a un sitio para un conjunto de recursos de números de emergencia. En caso de una emergencia durante un Evento de supervivencia, esto permitirá que varios usuarios que llaman tengan cada uno 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 una llamada.
Además, un ELIN puede Asignar 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 y 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 de llamada del usuario, si hay uno disponible, será reemplazado por el ELIN 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 contactados para devolución de llamada por el operador de emergencia.
#### Un número ELIN debe ser un número BYOC asociado con el troncal RTPC SBC del sitio
El ELIN de un sitio **debe** debe ser un número BYOC que termine en un troncal de RTPC ubicado en el SBC de conmutación por error del sitio. No se puede utilizar ningún otro tipo de número.
#### El módulo ZPLS enrutará automáticamente las llamadas del proveedor de emergencias al ELIN de regreso a la extensión del usuario que marcó originalmente durante hasta 2 horas
Si un operador de emergencia devuelve una llamada al ELIN, el módulo ZPLS enrutará la llamada de regreso al usuario original que realizó la llamada de emergencia. El módulo ZPLS continuará enrutando las devoluciones de llamada del PSAP al llamante original durante hasta 2 horas. En este momento, esta funcionalidad está limitada a la primera persona que llama.
#### 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 Asignar 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.
#### 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 con direcciones físicas a los operadores BYOC que se correlacionan con cada ELIN. Clientes son responsables de garantizar que las direcciones de emergencia estén correctamente asignadas a la dirección física correspondiente.
### 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 “hairpin” a través del módulo ZPLS, sin soporte para 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 enrutarse localmente primero
Siempre que sea posible, el módulo ZPLS intentará enrutar las llamadas originadas desde clientes de Zoom registrados a destinos registrados localmente. Las llamadas solo se reenvían al SBC si el destino contenido en el campo URI de solicitud del SIP Invitar entrante no coincide con una extensión registrada.
{% hint style="info" %}
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 registrado en Zoom asignado 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](#_54gf3fuxcnk5).
{% endhint %}
#### Durante un Evento de supervivencia, las llamadas externas Salientes mostrar 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 enrutarse 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 enrutarse a través de la nube [si se configura la prioridad de Enrutamiento correcta](#_zgofkpkt74xr). Sin embargo, si el Evento sigue en curso, el SBC enrutará la llamada al módulo ZPLS y al Dispositivo registrado por el 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 cambio de tasa de los códecs de audio. Todas las partes involucradas 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 analiza consideraciones para los grupos de distribución de supervivencia (SDG). Los Clientes que no planeen utilizar SDG ni integrar el módulo ZPLS con conectividad RTPC pueden omitir esta sección sin consecuencias.
#### Los grupos de distribución de supervivencia proporcionan opciones matizadas de enrutamiento de llamadas durante un Evento de supervivencia
Los grupos de distribución de supervivencia (SDG) proporcionan a las empresas opciones matizadas de enrutamiento de llamadas —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 respaldando los servicios principales de telefonía y las configuraciones de enrutamiento de llamadas (similares a las colas de llamadas, los contestadores automáticos y los 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 crearse y mantenerse por separado
Aunque los SDG ofrecen una funcionalidad de enrutamiento de llamadas similar a la de los grupos de distribución de operación estándar, los SDG son únicos y específicos para los Eventos de supervivencia y, por lo tanto, deben crearse y mantenerse por separado. En otras palabras, los SDG **no** heredan la Configuración o las 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 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 a el número de teléfono SDG designado, y la llamada seguirá el perfil de Enrutamiento configurado. Esto permite a una empresa ofrecer una experiencia de flujo de llamadas coherente para los autores de llamadas externos 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 pueden personalizarse de las siguientes maneras
Los SDG admiten las siguientes opciones:
* Número de extensión dedicado
* Número de marcación directa entrante 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 y configuraciones de red necesarias para una implementación de ZPLS.
{% hint style="info" %}
Esta sección está dedicada a la implementación de hardware y al diseño de red *consideraciones de diseño*. Consulte la sección sobre [implementar ZPLS](#_wrba5u2ahyc) para obtener instrucciones de implementación paso a paso.
{% endhint %}
#### Consideraciones de implementación y redes 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 cuenta y la Configuración del usuario](#_54gf3fuxcnk5).
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, en algunas circunstancias se puede usar una red DMZ; sin embargo, los administradores de red deben asegurarse de que sea posible la comunicación 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á en un estado inactivo, el módulo ZPLS debe mantener un ping keepalive 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 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 del 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 con el módulo ZPLS y 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 existan reglas NAT estáticas 1:1 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 utiliza para enrutar cualquier llamada potencial a un número de teléfono BYOC [a través de la nube de Zoom Phone](#_zgofkpkt74xr). El mecanismo keepalive OPTIONS se habilita automáticamente entre ZPLS y el SBC y es Opcional entre el SBC y la nube.
#### Consideraciones para los clientes de Zoom y los 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](#_ah8xua8wdq10) 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 de telefonía](#_k11n5zxkx1pq) con una dirección IPv4 detectable internamente.
**Los dispositivos deben tener una IP estática o se les debe asignar 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 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 regular 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 puede deshabilitarse.
#### Firewall y flujo de datos de red
Vea la sección sobre [Puertos de red y flujo de datos](#_pswiusfsww6t).
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://library.zoom.com/technical-library/es/zoom-workplace/zoom-phone/zoom-phone-local-survivability-field-guide/before-you-begin/pstn-integration-considerations.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.