> For the complete documentation index, see [llms.txt](https://library.zoom.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://library.zoom.com/technical-library/fr/zoom-workplace/zoom-phone/zoom-phone-local-survivability-field-guide/before-you-begin/pstn-integration-considerations.md).
# Considérations relatives à l’intégration RTC
Cette section s’applique aux clients qui envisagent d’intégrer le module ZPLS à un SBC et à une connexion RTC pour une survivabilité supplémentaire. Les clients qui ne prévoient pas d’intégrer le module ZPLS à une connectivité RTC peuvent ignorer cette section sans conséquence.
### Considérations relatives aux Intégrations SBC
#### Exigences SBC
Pour intégrer un SBC avec Zoom pour la survivabilité, un SBC doit satisfaire aux exigences suivantes :
* TLS 1.2 et SRTP
* Assistance pour TLS mutuel
* Protocole d’initiation de session (SIP)
* DTMF (RFC-2833)
* Masquage de topologie (RFC-5853)
* Offre SIP anticipée (**obligatoire**)
* codecs Opus, G.711 μ-law, G.711 A-law et G.729
#### Les Intégrations RTC requièrent un SBC et un fournisseur tiers fiable
Pour la connectivité RTC, les clients doivent fournir un contrôleur de frontière de session (SBC) connecté soit à une connexion héritée, soit à un trunk SIP avec une connexion cellulaire ou alternative (p. 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 devraient envisager une connexion tertiaire fiable pour la connectivité RTC.
#### N’importe quel SBC certifié BYOC pour Zoom Phone peut être utilisé
Tout contrôleur de frontière 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 plan Zoom Phone BYOC existant n’ont pas besoin d’un SBC supplémentaire ou distinct aux fins de la survivabilité.
#### Les certificats DigiCert de Zoom doivent être installés sur le SBC
Afin d’établir une connectivité TLS avec le module ZPLS et le cloud Zoom, les [certificats racine et intermédiaires DigitCert](https://support.zoom.us/hc/en-us/articles/360044092031) 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 le module ZPLS en troisième
Les SBC des clients doivent acheminer les appels entrants provenant du RTC vers la zone SIP primaire et secondaire avant d’essayer le module ZPLS. Avec cette configuration, les appels ne seront acheminés vers le module ZPLS qu’en cas d’é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 de distribution 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 le cloud Zoom Phone Disponible à la suite d’un événement de survivabilité, un SBC peut temporairement tenter d’acheminer les numéros BYOC vers le cloud Zoom pendant 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’est pas répondu**](https://support.zoom.us/hc/en-us/articles/360059966372-Customizing-call-handling-settings#h_86f4bf1b-51ea-4d70-9e40-4a84a5ca1c2c) pendant cette période intermédiaire.
{% endhint %}
#### Les appels sortants du module ZPLS doivent être acheminés vers le SBC et le trunk SIP RTC
Lorsque le mode de survivabilité est Actif, les appels 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 d’être rerouté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 concernés peuvent être injoignables à moins que les appels vers leurs numéros principaux ne soient transférés vers un numéro alternatif associé à un SBC sur site.
{% hint style="info" %}
Les exemples courants de numéros concernés peuvent inclure des numéros attribués à : des utilisateurs, des espaces communs, des réceptions automatiques (AR), des groupes de ligne partagée (SLG) et des files d’attente d’appels (CQ).
{% endhint %}
#### Les clients utilisant un BYOC sur site ne nécessitent pas de configurations avancées et peuvent contourner le transfert d’appel en ajoutant une route tertiaire vers leur module ZPLS depuis leur SBC
Les clients utilisant un plan BYOC sur site (c.-à-d. les clients qui n’utilisent pas de numéros enregistrés auprès de Zoom Phone) ne nécessitent pas de configurations avancées pour Activer le transfert d’appel. À la place, les clients BYOC peuvent ajouter une route tertiaire vers le module ZPLS depuis le SBC sur site.
#### 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 import CSV en masse](#_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 de 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 seul 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 se voit attribuer le 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 immeuble au X99-999-9999. De même, les collègues de John peuvent aussi voir 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 acheminé vers X99-999-9998, et X55-555-5553 acheminé vers X99-999-9997. Cependant, aucun utilisateur individuel ne peut voir 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 Activer pendant les opérations courantes, tous les appels entrants vers un numéro enregistré auprès de Zoom Phone seront rerouté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 Activer que par un utilisateur autorisé ou un admin disposant d’une connexion Internet fonctionnelle
Lors d’un événement de mode de survie, la connexion Internet d’un site est supposée indisponible. Toutefois, comme le renvoi 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 fonctionnelle, telle qu’un forfait de données téléphoniques ou une autre connexion Internet dans un Emplacement différent.
{% hint style="info" %}
Afin de réduire au minimum les interruptions et d’assurer la continuité des Affaires, Zoom recommande aux entreprises d’établir des procédures fiables pour Activer la logique de renvoi d’appel depuis le portail Web lors d’un événement de survie.
{% endhint %}
#### Les règles de renvoi d’appel peuvent s’appliquer à l’ensemble du site ou à des numéros individuels
Lors d’un événement de survie, un administrateur ou un utilisateur autorisé peut Activer des règles de renvoi d’appel pour l’ensemble du site ou pour des numéros spécifiques depuis le portail Web.
#### Une fois le renvoi 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 d’un utilisateur, même s’il maintient une connexion cloud indépendante
Lorsque le renvoi d’appel est Activé pour un numéro enregistré auprès de Zoom Phone, Zoom ne tentera pas d’acheminer un appel vers l’utilisateur via le cloud. Par conséquent, même si un utilisateur concerné dispose d’un Appareil enregistré dans le cloud, tel qu’un téléphone mobile, si le numéro de téléphone est marqué pour le renvoi d’appel, tous les appels seront acheminés via le RTC vers le SBC de l’entreprise.
Par exemple, un site connaît un événement de mode de survie et le téléphone mobile d’un utilisateur est connecté au cloud Zoom Phone via la connexion de données de son opérateur mobile. Si le numéro de téléphone d’un utilisateur est marqué pour le renvoi d’appel, le cloud Zoom Phone **ne le fera pas** fera sonner son numéro Zoom Phone via l’application mobile, malgré la connexion stable. Tous les appels continueront plutôt d’être acheminés via le RTC vers le SBC du client.
#### Si le renvoi d’appel n’est pas Activé pour un utilisateur lors d’un événement de survie, les appels entrants suivront les préférences de traitement des appels de chaque utilisateur
Si le renvoi d’appel n’est pas Activé lors d’un événement de survie, les appels entrants seront traités conformément à 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, tel qu’un téléphone mobile, les appelants seront soumis aux règles définies par la **Lorsqu’un appel ne reçoit pas de réponse** section des préférences de traitement des appels.
#### Le renvoi d’appel s’applique uniquement aux appels RTC entrants
Le renvoi d’appel pour la survie s’applique uniquement aux appels acheminés via le RTC et/ou le cloud Zoom Phone. Les appels provenant d’extensions enregistrées auprès de 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 ne reçoit pas de réponse** section des règles de traitement des appels dans les Paramètres téléphoniques d’un utilisateur.
### Flux de renvoi d’appel
Le diagramme suivant détaille la logique de renvoi d’appel (une fois Activé) lors d’un événement de survie. Cette logique restera en vigueur jusqu’à ce que le renvoi d’appel soit désactivé ou que les opérations Standard soient rétablies. Toutefois, si le renvoi d’appel reste Activé *après* le rétablissement des opérations Standard, les appels transférés effectueront un aller-retour entre le cloud Zoom Phone, le SBC, puis le cloud, avant d’être acheminés vers l’Appareil d’un utilisateur. Pour cette raison, le renvoi d’appel doit être désactivé rapidement après un événement de survie.
1. Un appelant externe initie un appel vers un numéro enregistré auprès de Zoom Phone, qui 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 concerné par le renvoi d’appel.
{% hint style="info" %}
Si le renvoi d’appel n’est pas Activé, Zoom Phone suivra la **Lorsqu’un appel ne reçoit pas de réponse** logique de cet utilisateur ou de cette extension en particulier.
{% endhint %}
3. Comme le renvoi d’appel est Activé, Zoom ne tentera pas d’alerter l’utilisateur et redirigera plutôt l’appel vers le numéro de renvoi d’appel désigné via le RTC.
4. L’appel est acheminé du RTC vers le SBC de survie.
5. Le SBC de survie transfère l’appel vers le module ZPLS.
6. Le module ZPLS transfère l’appel vers le ou les clients enregistrés de l’utilisateur, s’ils sont connectés.
### Considérations relatives au numéro d’identification d’Emplacement d’urgence (ELIN)
#### Un ELIN est un numéro de téléphone exclusif à un site qui transmet des informations d’Emplacement aux services d’urgence lorsqu’il est composé
Un numéro d’identification d’Emplacement d’urgence (ELIN) est un numéro de téléphone dédié utilisé par les points de réponse de sécurité publique (PSAP) pour identifier l’adresse physique d’un appelant lorsqu’il appelle les services d’urgence. Pour cette Fonctionnalités, les entreprises doivent travailler avec leur fournisseur de services RTC afin d’associer une adresse à un numéro de téléphone, pour contribuer à garantir que l’adresse est répertoriée dans une base de données d’identification automatique d’Emplacement (ALI) lorsque l’appel est reçu par un opérateur PSAP.
Par exemple, considérons 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 lors d’un événement de survie 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 pool de ressources de numéros d’urgence. En cas d’urgence lors d’un événement de survie, cela permettra à plusieurs appelants de disposer chacun d’un ELIN attribué de manière unique, ce qui peut aider les services d’urgence à joindre l’appelant initial en cas de rappel.
En outre, un ELIN peut être attribué à un utilisateur ou à un téléphone de l'espace commun, offrant une attribution d’ELIN plus granulaire que celle au niveau du site et un Emplacement plus précis pour les services d’urgence.
#### Lors d’un événement de survie, tous les appels d’urgence sont remplacés par l’ELIN
Lorsqu’un utilisateur effectue un appel d’urgence lors d’un événement de survie, le numéro appelant de l’utilisateur, s’il est Disponible, sera remplacé par l’ELIN désigné au niveau du site. Cela permet aux utilisateurs qui ne disposent pas d’un numéro direct d’appeler les services d’urgence et d’être joignables en cas de rappel de l’opérateur d’urgence.
#### Un numéro ELIN doit être un numéro BYOC associé au faisceau RTC SBC du site
L’ELIN d’un site **doivent** doit être un numéro BYOC qui se termine sur un faisceau RTC situé sur le SBC de basculement du site. Aucun autre type de numéro ne peut être utilisé.
#### Le module ZPLS acheminera automatiquement les appels du fournisseur d’urgence vers l’ELIN, puis vers l’extension de l’utilisateur qui a composé initialement, pendant une durée maximale de 2 heures
Si un opérateur d’urgence rappelle l’ELIN, le module ZPLS acheminera l’appel vers l’utilisateur initial qui a effectué l’appel d’urgence. Le module ZPLS continuera d’acheminer les rappels PSAP vers l’appelant initial pendant une durée maximale de 2 heures. Pour le moment, cette Fonctionnalités est limitée au premier appelant.
#### Une fois qu’un numéro de téléphone est désigné comme 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 de la maintenance et de la mise à jour des adresses physiques associées à leur ELIN pour chaque site
Zoom n’est pas responsable de la mise à jour des opérateurs BYOC avec les 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 ou d'autres clients internes ; à la place, les paquets multimédias sont ancrés ou « hairpinned » via le module ZPLS, sans prise en charge du déchargement des médias.
Le schéma suivant illustre le chemin de signalisation et de médias pour les appels internes et externes actifs.
#### Les appels tenteront d'abord d'être acheminés localement
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 vers le SBC que si la destination contenue dans le champ Request URI de l'invitation SIP entrante ne correspond pas à un numéro de poste enregistré.
{% hint style="info" %}
Un numéro de poste enregistré est un numéro de poste court sans le code du site, un numéro de poste long avec le code du site, un numéro enregistré attribué à Zoom ou un numéro BYOC attribué. Les administrateurs doivent garder à l'esprit que le module ZPLS met à jour ces données [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 ZPLS contiendront le numéro d'appel BYOC. Le schéma suivant illustre le flux d'appels en mode de survivabilité pour un utilisateur :
#### Les appels de retour peuvent être acheminés vers le numéro BYOC d'un utilisateur
Comme les appels externes sortants passés pendant un événement de survivabilité utiliseront un numéro BYOC, les appelants externes peuvent rappeler en utilisant un numéro BYOC au lieu du numéro de téléphone enregistré auprès de Zoom de l'utilisateur. Si l'événement de survivabilité est terminé, les appels seront à nouveau acheminés via le cloud [si la priorité de routage correcte est configurée](#_zgofkpkt74xr). Cependant, si l'événement est en cours, le SBC acheminera l'appel vers le module ZPLS et l'appareil enregistré du 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 transcodage 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 ou d'intégrer le module ZPLS avec une connectivité RTC peuvent passer cette section sans conséquence.
#### Les groupes de distribution de survivabilité offrent des options nuancées de routage des appels lors d'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 du Serveur vocal interactif (SVI) — lors d'un événement de survivabilité. Avec les SDG, les entreprises peuvent continuer à prendre en charge les services de base de téléphonie et les configurations de routage des appels (semblables aux files d'attente des appels, aux fonctionnalités de réceptionniste automatique et de ligne partagée) jusqu'à ce que les opérations standard soient rétablies.
#### Les SDG ne sont pas identiques aux groupes de distribution en mode standard et doivent être créés et maintenus séparément
Bien que les SDG offrent une fonctionnalité de routage des appels similaire à celle des groupes de distribution en mode standard, les SDG sont uniques et propres aux événements de survivabilité et doivent donc être créés et maintenus 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 en mode standard (c.-à-d. file d'attente des appels, réceptionniste automatique, SVI, etc.)
#### Les SDG sont idéalement associés à une Intégrations BYOC-RTC et avec le transfert d'appels activé
Bien que les SDG puissent fournir une prise en charge interne uniquement (c.-à-d. des appels non RTC), ils sont idéalement associés à une Intégrations BYOC-RTC. Avec un SDG avec RTC activé, une fois que le transfert d'appels est activé lors d'un événement de survivabilité, un numéro principal de l'entreprise peut être acheminé vers le numéro de téléphone SDG désigné, et l'appel suivra le profil de routage configuré. Cela permet à une entreprise d'offrir une expérience cohérente de flux d'appel aux appelants externes jusqu'à ce que les opérations standard soient rétablies.
Le schéma suivant démontre la logique de routage des appels pour un SDG avec RTC activé :
#### 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 de numérotation directe entrante attribué
* fuseau horaire
* heures d'ouverture
* messages d'accueil enregistrés
* membres du groupe
* Acheminer vers :
* utilisateur
* menu du 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*. Reportez-vous à 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 du module ZPLS et au réseau
**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 pour le moment.
**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. Sinon, un réseau DMZ peut être utilisé dans certaines circonstances ; toutefois, les administrateurs réseau doivent s'assurer que la communication est possible via le pare-feu de l'entreprise. Dans les deux cas, les administrateurs doivent ajuster la politique de pare-feu de l'entreprise afin de permettre la communication entre le module ZPLS et le cloud Zoom.
**Le module ZPLS doit maintenir un ping OPTIONS régulier avec le cloud de Zoom Phone**
À l'état inactif, le module ZPLS doit maintenir un ping keepalive OPTIONS avec le cloud de Zoom Phone afin de surveiller la connectivité. Dans l'événement où les appareils clients et le module ZPLS au sein d'un site perdent la connectivité avec le cloud de Zoom Phone, les clients et appareils pris en charge s'enregistreront auprès du module ZPLS à l'aide de l'authentification SIP Digest sur TLS v1.2.
#### Considérations relatives au déploiement du SBC et au réseau
**Un SBC doit être joignable depuis ZPLS et cloud Zoom lorsque cela est possible**
Les Clients doivent s'assurer que le SBC maintient la connectivité avec le module ZPLS et le cloud de Zoom Phone, lorsque cela est possible. Les Clients peuvent provisionner un SBC à double interface 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 une connectivité TLS et UDP entre le cloud de Zoom Phone et le module ZPLS**
Lors des opérations courantes, un SBC doit maintenir une connectivité TLS et UDP avec le cloud de Zoom Phone et le module ZPLS du site associé. Cette connexion est utilisée pour acheminer tout appel potentiel vers un numéro de téléphone répertorié BYOC [via le cloud de Zoom Phone](#_zgofkpkt74xr). Le mécanisme keepalive OPTIONS est activé automatiquement 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 pouvoir découvrir le module ZPLS du site au sein du réseau local**
Clients et appareils pris en charge [activés pour la survivabilité téléphonique](#_ah8xua8wdq10) découvrir le module ZPLS de basculement approprié depuis le cloud de Zoom Phone pendant le processus de démarrage. Toutefois, le module doit déjà être [rattaché au site du système de téléphonie](#_k11n5zxkx1pq) avec une adresse IPv4 détectable en interne.
**Les appareils devraient 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 devraient se voir attribuer une IP statique ou une IP interne via un serveur DHCP local. Si un appareil ne se voit pas attribuer d'IP statique, ou si un serveur DHCP n'est pas disponible lors d'un événement de survivabilité, les appareils téléphoniques peuvent ne pas réussir à s'enregistrer.
**Les clients et les appareils doivent maintenir un ping OPTIONS régulier avec le cloud de Zoom Phone**
À l'image du module ZPLS, les clients et appareils pris en charge doivent maintenir un ping keepalive OPTIONS vers le cloud de Zoom Phone afin de déterminer l'état de connectivité du data center. Lors d'un événement de panne, le client continue d'envoyer des messages keepalive 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
Voir la section sur [Ports réseau et flux de données](#_pswiusfsww6t).
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## 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, and the optional `goal` 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=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.