# Considérations relatives aux Intégrations RTC
Cette section s’applique aux Clients qui envisagent d’intégrer le module ZPLS avec un SBC et une connexion RTC pour une survivabilité supplémentaire. Les Clients qui ne prévoient pas d’intégrer le module ZPLS avec une connectivité RTC peuvent ignorer cette section sans conséquence.
### Considérations relatives aux Intégrations SBC
#### Exigences relatives au SBC
Pour intégrer un SBC avec Zoom pour la survivabilité, un SBC doit répondre aux exigences suivantes :
* TLS 1.2 et SRTP
* Assistance pour Mutual TLS
* Protocole d’initiation de session (SIP)
* DTMF (RFC-2833)
* Masquage de topologie (RFC-5853)
* Offre anticipée SIP (**obligatoire**)
* Codecs Opus, G.711 μ-law, G.711 A-law et G.729
#### Les Intégrations RTC nécessitent un SBC et un fournisseur tiers fiable
Pour la connectivité RTC, les Clients doivent fournir un contrôleur de bordure de session (SBC) connecté soit à une connexion héritée, soit à un trunk SIP avec une connexion cellulaire ou alternative (par ex. DSL). Les Clients doivent garder à l’esprit que tous les trunks SIP déployés au niveau du SBC peuvent dépendre du même service Internet qui subit une panne. En raison de cette possibilité, les Clients doivent envisager une connexion tertiaire fiable pour la connectivité RTC.
#### Tout SBC certifié BYOC Zoom Phone peut être utilisé
Tout contrôleur de bordure de session (SBC) qui est [certifié pour Zoom Phone](https://support.zoom.us/hc/en-us/articles/360001299063-Zoom-Phone-Certified-Hardware#h_ec5008d4-3581-46e7-a06d-32599511d089) peut également être utilisé avec le module ZPLS. Les Clients disposant d’un forfait BYOC Zoom Phone existant n’ont pas besoin d’un SBC supplémentaire ou distinct à des fins de survivabilité.
#### Les certificats DigiCert de Zoom doivent être installés sur le SBC
Afin d’établir une connectivité TLS à la fois avec le module ZPLS et le cloud Zoom, les [certificats racine et intermédiaires DigitCert](https://support.zoom.us/hc/en-us/articles/360044092031) de Zoom doivent être installés sur le SBC.
#### Les SBC doivent acheminer les appels entrants vers les centres de données Zoom Phone comme premier et deuxième choix de routage, et vers le module ZPLS en troisième
Les SBC du client doivent acheminer les appels entrants depuis le RTC vers la zone SIP primaire et secondaire avant de tenter le module ZPLS. Avec cette configuration, les appels ne seront acheminés vers le module ZPLS que pendant un événement de survivabilité, car le SBC et les centres de données Zoom Phone devraient autrement maintenir une connectivité stable.
Le non-respect de cette logique peut entraîner des échecs d’acheminement des appels, car le module ZPLS ne peut pas acheminer les appels vers des Appareils enregistrés dans le cloud.
{% hint style="info" %}
Une fois que le cloud Zoom Phone est disponible après un événement de survivabilité, un SBC peut tenter temporairement d’acheminer les numéros BYOC vers le cloud Zoom tandis que l’Appareil client du numéro concerné est enregistré auprès du module ZPLS. Si cela se produit, le routage des appels suivra les Paramètres de [**Lorsqu’un appel n’obtient pas de réponse**](https://support.zoom.us/hc/en-us/articles/360059966372-Customizing-call-handling-settings#h_86f4bf1b-51ea-4d70-9e40-4a84a5ca1c2c) pendant cette période intérimaire.
{% endhint %}
#### Les appels sortants du module ZPLS doivent être acheminés vers le SBC et le trunk SIP RTC
Lorsque le mode survivabilité est actif, les appels provenant de ZPLS vers le SBC doivent être acheminés vers le trunk SIP RTC afin d’établir des connexions téléphoniques externes. Tous les appels vers des numéros qui ne sont pas enregistrés auprès du module ZPLS sont envoyés au SBC configuré pour la survivabilité au format E.164.
### Considérations relatives à la survivabilité locale du transfert d’appel
#### Pendant un événement de survivabilité, les numéros de téléphone fournis par Zoom Phone ne seront pas joignables de l’extérieur à moins qu’ils ne soient redirigés via le transfert d’appel
Pendant un événement de survivabilité, les numéros de téléphone fournis par Zoom ne seront pas joignables de l’extérieur du point de vue du cloud. Par conséquent, les utilisateurs situés dans les emplacements affectés peuvent être injoignables à moins que les appels vers leurs numéros principaux ne soient transférés vers un autre numéro associé à un SBC sur site.
{% hint style="info" %}
Les exemples courants de numéros affectés peuvent inclure des numéros attribués à : Utilisateurs, Espaces communs, Réception automatiques (AR), Groupes de lignes partagées (SLG) et Files d’attente d’appels (CQ).
{% endhint %}
#### Les Clients utilisant un BYOC basé sur site ne nécessitent pas de configurations avancées et peuvent contourner le transfert d’appel en ajoutant une route tertiaire à leur module ZPLS depuis leur SBC
Les Clients utilisant un forfait BYOC basé sur site (c.-à-d. les clients qui n’utilisent pas de numéros enregistrés sur Zoom Phone) ne nécessitent pas de configurations avancées pour Activer le transfert d’appel. À la place, les clients BYOC peuvent ajout une route tertiaire vers le module ZPLS depuis le SBC basé sur les locaux.
#### Les configurations de transfert d’appel sont définies par un admin ou un utilisateur autorisé depuis le portail web
Un admin de compte ou un utilisateur autorisé peut [configurez la logique de transfert d’appel](#_1od0waijmvaz) depuis le portail web via [une saisie manuelle ou un téléversement groupé CSV](#_aezu04x8z043).
#### Les utilisateurs configurés pour le transfert d’appel auront trois numéros attribués
Après l’application d’un numéro BYOC à un utilisateur pour la survivabilité du transfert d’appel, l’Appareil client se verra attribuer *au moins* trois numéros :
1. Une extension interne avec le code site préfixé
2. Un numéro RTC fourni par Zoom
3. Un numéro RTC BYOC
#### Les numéros de téléphone peuvent être transférés vers un maximum d’un numéro BYOC
Chaque numéro Zoom Phone peut être transféré vers un maximum de **un** autre numéro BYOC. Cependant, vous pouvez transférer plusieurs numéros de téléphone vers le même numéro BYOC.
Par exemple, si John est attribué au numéro de téléphone X55-555-5555, le numéro de téléphone de John peut être transféré vers le numéro d’opérateur de son bâtiment au X99-999-9999. De même, les collègues de John peuvent également avoir leurs numéros (X55-555-5554, X55-555-5553, etc.) transférés vers X99-999-9999. Sinon, chaque utilisateur peut voir son numéro de téléphone transféré vers un numéro complètement unique, par exemple X55-555-5554 vers X99-999-9998, et X55-555-5553 vers X99-999-9997. Toutefois, aucun utilisateur individuel ne peut avoir son numéro transféré à la fois vers X99-999-9999 et X99-999-9998.
#### Le transfert d’appel doit rester désactivé jusqu’à ce qu’un événement de survivabilité se produise
Bien qu’un administrateur puisse préconfigurer à l’avance la logique de transfert d’appel pour un site, la fonctionnalité de transfert d’appel doit rester désactivée jusqu’à ce qu’un événement de survivabilité se produise. Si le transfert d’appel est activé pendant les opérations courantes, tous les appels entrants vers un numéro enregistré dans Zoom Phone seront redirigés vers le SBC sur site et le numéro de téléphone BYOC associé, en contournant les services Zoom Phone. Par conséquent, pour maintenir le routage normal de Zoom Phone, le transfert d’appel doit être désactivé pendant les opérations courantes.
#### Le transfert d’appel ne peut être activé que par un utilisateur autorisé ou un admin disposant d’une connexion Internet active
Lors d’un événement en mode survivabilité, la connexion Internet d’un site est supposée indisponible. Cependant, comme le transfert d’appel doit rester désactivé pour le fonctionnement standard, il ne peut être activé que par un utilisateur autorisé ou un admin disposant d’une connexion Internet active, comme un forfait de données téléphoniques, ou par une connexion Internet alternative depuis un autre Emplacement.
{% hint style="info" %}
Pour minimiser les temps d’arrêt et garantir la continuité des activités, Zoom recommande aux entreprises d’établir des procédures fiables pour activer la logique de transfert d’appel depuis le portail web lors d’un événement de survivabilité.
{% endhint %}
#### Les règles de transfert d’appel peuvent s’appliquer à l’ensemble du site ou à des numéros individuels
Lors d’un événement de survivabilité, un administrateur ou un utilisateur autorisé peut activer les règles de transfert d’appel pour l’ensemble du site ou pour des numéros spécifiques depuis le portail web.
#### Une fois le transfert d’appel activé pour le numéro de téléphone d’un utilisateur, Zoom ne fera pas sonner le client enregistré dans le cloud de l’utilisateur, même s’il maintient une connexion cloud indépendante
Lorsque le transfert d’appel est activé pour un numéro enregistré dans Zoom Phone, Zoom n’essaiera pas d’acheminer un appel vers l’utilisateur via le cloud. Par conséquent, même si un utilisateur impacté dispose d’un appareil enregistré dans le cloud comme un téléphone mobile, si le numéro de téléphone est marqué pour le transfert d’appel, tous les appels seront acheminés via le RTC vers le SBC de l’entreprise.
Par exemple, un site subit un événement en mode survivabilité et le téléphone mobile d’un utilisateur est connecté au cloud Zoom Phone via la connexion de données de son fournisseur de téléphonie mobile. Si le numéro de téléphone d’un utilisateur est marqué pour le transfert d’appel, le cloud Zoom Phone **ne le fera pas** sonner son numéro Zoom Phone via l’application mobile, malgré la connexion stable. À la place, tous les appels continueront d’être acheminés via le RTC vers le SBC du client.
#### Si le transfert d’appel n’est pas activé pour un utilisateur pendant un événement de survivabilité, les appels entrants suivront les préférences de traitement des appels de chaque utilisateur
Si le transfert d’appel n’est pas activé pendant un événement de survivabilité, les appels entrants seront traités selon la [logique de traitement des appels](https://support.zoom.us/hc/en-us/articles/360059966372-Customizing-call-handling-settings) pour chaque utilisateur individuel. Si un utilisateur n’a pas de client téléphonique de secours enregistré dans le cloud, comme un téléphone mobile, les appelants seront soumis aux règles définies par la **Lorsqu’un appel n’est pas répondu** section des préférences de traitement des appels.
#### Le transfert d’appel s’applique uniquement aux appels entrants du RTC
Le transfert d’appel pour la survivabilité s’applique uniquement aux appels acheminés via le RTC et/ou le cloud Zoom Phone. Les appels provenant d’extensions enregistrées dans Zoom au sein du même site tenteront d’abord de se connecter via le module ZPLS, puis via le RTC si un SBC est connecté. Les appels qui ne peuvent pas se connecter seront autrement soumis au traitement défini par la **Lorsqu’un appel n’est pas répondu** section des règles de traitement des appels dans les paramètres du téléphone d’un utilisateur.
### Flux de transfert d’appel
Le schéma suivant détaille la logique du transfert d’appel (une fois activé) pendant un événement de survivabilité. Cette logique restera en vigueur jusqu’à ce que le transfert d’appel soit désactivé ou que les opérations standard soient rétablies. Cependant, si le transfert d’appel reste activé *après* que les opérations standard aient été rétablies, les appels transférés feront un aller-retour entre le cloud Zoom Phone, le SBC, puis de nouveau vers le cloud, avant d’être remis à l’appareil d’un utilisateur. Pour cette raison, le transfert d’appel doit être désactivé rapidement après un événement de survivabilité.
1. Un appelant externe initie un appel vers un numéro enregistré dans Zoom Phone et est acheminé via le RTC.
2. L’appel est acheminé vers le cloud Zoom Phone, et le numéro de téléphone composé est identifié comme étant impacté par le transfert d’appel.
{% hint style="info" %}
Si le transfert d’appel n’est pas activé, Zoom Phone suivra la **Lorsqu’un appel n’est pas répondu** logique pour cet utilisateur ou cette extension particulière.
{% endhint %}
3. Étant donné que le transfert d’appel est activé, Zoom n’essaiera pas d’alerter l’utilisateur et redirigera plutôt l’appel vers le numéro de transfert d’appel désigné via le RTC.
4. L’appel est acheminé du RTC vers le SBC de survivabilité.
5. Le SBC de survivabilité transfère l’appel vers le module ZPLS.
6. Le module ZPLS transfère l’appel vers le ou les client(s) enregistré(s) de l’utilisateur, s’ils sont connectés.
### Considérations relatives au Numéro d’Identification de l’Emplacement d’Urgence (ELIN)
#### Un ELIN est un numéro de téléphone exclusif au site qui communique des informations de localisation aux services d’urgence lorsqu’il est composé
Un Numéro d’Identification de l’Emplacement d’Urgence (ELIN) est un numéro de téléphone dédié utilisé par les Public Safety Answering Points (PSAP) pour identifier l’adresse physique d’un appelant lorsqu’il contacte les services d’urgence. Pour cette fonctionnalité, les entreprises doivent travailler avec leur fournisseur de services RTC afin d’associer une adresse à un numéro de téléphone, pour aider à garantir que l’adresse figure dans une base de données d’identification automatique de l’emplacement (ALI) lorsque l’appel est reçu par un opérateur PSAP.
Par exemple, imaginez un campus universitaire qui s’étend sur plusieurs bâtiments, chaque bâtiment étant représenté par un site Zoom Phone distinct. Si un utilisateur appelle les services d’urgence pendant un événement de survivabilité depuis un téléphone ou un appareil [associé au site](#_ggwzik1hd9xi), les services d’urgence recevront automatiquement l’adresse complète enregistrée pour le site, à condition que l’emplacement soit configuré et à jour auprès du fournisseur de services.
#### Chaque site peut prendre en charge plusieurs ELIN
Les Clients peuvent attribuer plusieurs ELIN à un site pour constituer un ensemble de ressources de numéros d’urgence. En cas d’urgence pendant un événement de survivabilité, cela permettra à plusieurs appelants d’avoir chacun un ELIN attribué de manière unique, ce qui peut aider les services d’urgence à joindre l’appelant d’origine lors d’un rappel.
De plus, un ELIN peut être attribué à un utilisateur ou à un téléphone de l’espace commun, offrant une attribution ELIN plus granulaire que le niveau du site, et fournissant un emplacement plus précis aux services d’urgence.
#### Pendant un événement de survivabilité, tous les appels d’urgence sont remplacés par l’ELIN
Lorsqu’un utilisateur passe un appel d’urgence pendant un événement de survivabilité, le numéro d’appel de l’utilisateur, s’il est disponible, sera remplacé par l’ELIN désigné au niveau du site. Cela permet aux utilisateurs qui n’ont pas de numéro direct d’appeler les services d’urgence et d’être joignables pour un rappel de l’opérateur d’urgence.
#### Un numéro ELIN doit être un numéro BYOC associé au trunk RTC SBC du site
L’ELIN d’un site **doit** être un numéro BYOC terminé sur un trunk RTC situé au SBC de basculement du site. Aucun autre type de numéro ne peut être utilisé.
#### Le module ZPLS acheminera automatiquement les appels des fournisseurs de services d'urgence vers l'ELIN, puis de retour vers le numéro de poste de l’utilisateur qui a initialement composé le numéro, pendant une durée maximale de 2 heures
Si un opérateur d'urgence retourne un appel vers l'ELIN, le module ZPLS acheminera l'appel de retour vers l'utilisateur d'origine qui a passé l'appel d'urgence. Le module ZPLS continuera d'acheminer les rappels du PSAP vers l'appelant d'origine pendant une durée maximale de 2 heures. Pour le moment, cette fonctionnalité est limitée au premier appelant.
#### Une fois qu'un numéro de téléphone est désigné comme étant l'ELIN, il ne peut pas être attribué à un utilisateur ou à un Appareil
Une fois qu'un administrateur a attribué un numéro BYOC comme ELIN désigné pour un site, le numéro BYOC ne peut être attribué à aucun utilisateur ni à aucune autre entité Zoom Phone, sauf s'il est désattribué.
#### Les Clients sont responsables du maintien et de la mise à jour des adresses physiques associées à leur ELIN pour chaque site
Zoom n'assume pas la responsabilité de la mise à jour, auprès des opérateurs BYOC, des adresses physiques correspondant à chaque ELIN. Les Clients sont responsables de s'assurer que les adresses d'urgence sont correctement associées à l'adresse physique appropriée.
### Considérations relatives au routage RTC
#### Lorsque le mode de survivabilité est Actif, les paquets multimédias sont acheminés via le module ZPLS
Lorsque le mode de survivabilité est activé, les clients ne communiquent pas directement avec un SBC ni avec d'autres clients internes ; à la place, les paquets multimédias sont ancrés ou « hairpinnés » via le module ZPLS, sans prise en charge du déchargement multimédia.
Le schéma suivant illustre le chemin de signalisation et le chemin multimédia pour les appels internes et externes actifs.
#### Les appels tenteront d'être acheminés localement en premier
Dans la mesure du possible, le module ZPLS tentera d'acheminer les appels provenant de clients Zoom enregistrés vers des destinations enregistrées localement. Les appels ne sont transférés au SBC que si la destination contenue dans le champ URI de requête du SIP Inviter entrant ne correspond pas à un numéro de poste enregistré.
{% hint style="info" %}
Un numéro de poste enregistré est un numéro court sans le code du site, un numéro long avec le code du site, un numéro attribué enregistré par Zoom, ou un numéro BYOC attribué. Les administrateurs doivent garder à l'esprit que le module ZPLS met à jour ces données [une fois toutes les 10 heures](#_54gf3fuxcnk5).
{% endhint %}
#### Lors d'un événement de survivabilité, les appels externes sortants afficheront le numéro BYOC de l’utilisateur
Lors d'un événement de survivabilité, les appels externes sortants provenant d'Appareils enregistrés sur ZPLS contiendront le numéro d'appel BYOC. Le schéma suivant illustre le flux d'appel en mode de survivabilité pour un utilisateur :
#### Les appels retournés peuvent être acheminés vers le numéro BYOC d’un utilisateur
Étant donné que les appels externes sortants passés lors d'un événement de survivabilité utiliseront un numéro BYOC, les appelants externes peuvent retourner un appel en utilisant un numéro BYOC au lieu du numéro de téléphone de l’utilisateur enregistré par Zoom. Si l'événement de survivabilité est terminé, les appels seront acheminés de nouveau via le cloud [si la bonne priorité de routage est configurée](#_zgofkpkt74xr). Toutefois, si l'événement est toujours en cours, le SBC acheminera l'appel vers le module ZPLS et l'Appareil enregistré par le client.
#### Codecs de survivabilité pris en charge
Les codecs de survivabilité pris en charge sont Opus, G.711 μ-law, G.711 A-law et G.729. Le transcodage ou le changement de débit des codecs audio n'est pas pris en charge. Toutes les parties impliquées dans un appel actif doivent prendre en charge le même codec et la même fréquence d'échantillonnage.
### Considérations relatives aux groupes de distribution de survivabilité
Cette section aborde les considérations relatives aux groupes de distribution de survivabilité (SDG). Les Clients qui ne prévoient pas d'utiliser les SDG ni d'intégrer le module ZPLS à une connectivité RTC peuvent ignorer cette section sans conséquence.
#### Les groupes de distribution de survivabilité offrent des options nuancées de routage des appels pendant un événement de survivabilité
Les groupes de distribution de survivabilité (SDG) offrent aux entreprises des options nuancées de routage des appels — comme les files d'attente des appels et les menus de serveur vocal interactif (SVI) — pendant un événement de survivabilité. Avec les SDG, les entreprises peuvent continuer à prendre en charge les services de téléphonie de base et les configurations de routage des appels (semblables aux files d'attente des appels, aux réceptionnistes automatiques et aux groupes de lignes partagées) jusqu'à ce que les opérations standard soient rétablies.
#### Les SDG ne sont pas identiques aux groupes de distribution des opérations standard et doivent être créés et gérés séparément
Bien que les SDG offrent une fonctionnalité similaire de routage des appels à celle des groupes de distribution des opérations standard, les SDG sont uniques et spécifiques aux événements de survivabilité, et doivent par conséquent être créés et gérés séparément. En d'autres termes, les SDG **ne le fera pas** héritent des Paramètres ou des configurations d'un groupe de distribution des opérations standard (c.-à-d. file d'attente des appels, réceptionniste automatique, SVI, etc.)
#### Les SDG sont mieux associés à une Intégrations BYOC-RTC avec le transfert d'appels activé
Bien que les SDG puissent fournir une prise en charge uniquement interne (c.-à-d. les appels non RTC), ils sont mieux associés à une Intégrations BYOC-RTC. Avec un SDG activé pour le RTC, une fois le transfert d'appels activé pendant un événement de survivabilité, un numéro principal de l'entreprise peut être acheminé vers le numéro de téléphone du SDG désigné, et l'appel suivra le profil de routage configuré. Cela permet à une entreprise d'offrir une expérience de flux d'appels cohérente aux appelants externes jusqu'à ce que les opérations standard soient rétablies.
Le schéma suivant illustre la logique de routage des appels pour un SDG activé pour le RTC :
#### Les SDG peuvent être personnalisés des façons suivantes
Les SDG prennent en charge les options suivantes :
* numéro de poste dédié
* Numéro SDA attribué
* Fuseau horaire
* heures d'ouverture
* Messages d'accueil enregistrés
* Membres du groupe
* Acheminer vers :
* Utilisateur
* Menu de serveur vocal interactif (SVI)
* Membres du groupe
* Numéro de téléphone
* distribution des appels :
* Simultanée
* Séquentielle
### Considérations relatives au matériel et au réseau
Cette section aborde les considérations relatives au matériel et au réseau pour le module ZPLS, une Intégrations SBC, les clients Zoom et les Appareils téléphoniques. Après avoir lu cette section, vous devriez comprendre les communications réseau et les configurations nécessaires pour un déploiement ZPLS.
{% hint style="info" %}
Cette section est consacrée au déploiement du matériel et au réseau *considérations de conception*. Consultez la section sur [le déploiement de ZPLS](#_wrba5u2ahyc) pour des instructions de déploiement étape par étape.
{% endhint %}
#### Considérations relatives au déploiement et au réseau du module ZPLS
**Le module ZPLS nécessite une adresse IPv4 statique au sein de votre réseau**
Le module ZPLS doit être déployé sur un LAN interne avec une adresse IPv4 statique accessible aux appareils Zoom Phone et aux clients de bureau. Le module ZPLS ne prend pas en charge les adresses IPv6 à ce jour.
**Le module ZPLS doit maintenir des connexions HTTPS périodiques avec le cloud Zoom Phone**
Le module ZPLS nécessite des connexions HTTPS périodiques avec le cloud Zoom Phone pour [synchroniser les Paramètres du compte et de l’utilisateur](#_54gf3fuxcnk5).
Dans la plupart des cas, un module ZPLS peut être déployé sur un LAN interne au sein du réseau d’un client. À défaut, un réseau DMZ peut être utilisé dans certains cas ; toutefois, les administrateurs réseau doivent s’assurer que la communication est possible à travers le pare-feu de l’Entreprise. Dans l’un ou l’autre cas, les administrateurs doivent ajuster la politique du pare-feu de l’entreprise pour Activer la communication entre le module ZPLS et le cloud Zoom.
**Le module ZPLS doit maintenir un ping OPTIONS régulier avec le cloud Zoom Phone**
Lorsqu’il est inactif, le module ZPLS doit maintenir un ping de maintien en vie OPTIONS avec le cloud Zoom Phone afin de surveiller la connectivité. Dans l’éventualité où les appareils clients et le module ZPLS d’un site perdent la connectivité avec le cloud Zoom Phone, les clients et appareils pris en charge s’enregistreront auprès du module ZPLS à l’aide de l’authentification SIP Digest via TLS v1.2.
#### Considérations relatives au déploiement et au réseau du SBC
**Un SBC doit être joignable depuis ZPLS et le cloud Zoom chaque fois que possible**
Les Clients doivent s’assurer que le SBC maintient la connectivité avec le module ZPLS et le cloud Zoom Phone, chaque fois que possible. Les Clients peuvent provisionner un SBC à deux cartes réseau configuré avec une adresse IPv4 privée et publique, ou s’assurer que des règles NAT statiques 1:1 sont en place sur le pare-feu en périphérie, en plus d’ouvrir les ports requis.
**Un SBC doit maintenir la connectivité TLS et UDP entre le cloud Zoom Phone et le module ZPLS**
Pendant les opérations de routine, un SBC doit maintenir une connectivité TLS et UDP avec le cloud Zoom Phone et le module ZPLS du site associé. Cette connexion est utilisée pour acheminer les appels potentiels vers un numéro de téléphone répertorié BYOC [via le cloud Zoom Phone](#_zgofkpkt74xr). Le mécanisme de maintien en vie OPTIONS est automatiquement activé entre ZPLS et le SBC et est Optionnel entre le SBC et le cloud.
#### Considérations relatives aux clients Zoom et aux appareils téléphoniques
**Les clients et les appareils doivent être capables de détecter le module ZPLS du site au sein du réseau local**
Les clients et les appareils pris en charge [activés pour la résilience téléphonique](#_ah8xua8wdq10) détectent le module ZPLS de basculement approprié depuis le cloud Zoom Phone pendant le processus de démarrage. Toutefois, le module doit déjà être [lié au site du système de téléphonie](#_k11n5zxkx1pq) avec une adresse IPv4 détectable en interne.
**Les appareils doivent avoir une IP statique ou se voir attribuer une IP privée via un serveur DHCP local**
Pour atténuer les problèmes potentiels, les appareils téléphoniques doivent se voir attribuer une IP statique ou interne via un serveur DHCP local. Si aucun IP statique n’est attribuée à un appareil, ou si un serveur DHCP n’est pas disponible lors d’un événement de résilience, les appareils téléphoniques peuvent ne pas s’enregistrer.
**Les clients et les appareils doivent maintenir un ping OPTIONS régulier avec le cloud Zoom Phone**
À l’instar du module ZPLS, les clients et appareils pris en charge doivent maintenir un ping de maintien en vie OPTIONS vers le cloud Zoom Phone afin de déterminer l’état de la connectivité du data center. En cas de panne, le client continue d’envoyer des messages de maintien en vie afin de détecter le retour du service cloud et d’initier la reprise des opérations normales. Ce processus est automatique et ne peut pas être désactivé.
#### Pare-feu et flux de données réseau
Consultez la section sur [Ports réseau et flux de données](#_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/fr/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.