Considérations relatives à l'intégration PSTN

Cette section s'applique aux clients qui envisagent d'intégrer le module ZPLS avec un SBC et une connexion PSTN pour une résilience supplémentaire. Les clients qui ne prévoient pas d'intégrer le module ZPLS avec une connectivité PSTN peuvent passer cette section sans conséquence.

Considérations d'intégration du SBC

Exigences du SBC

Pour intégrer un SBC avec Zoom pour la résilience, un SBC doit satisfaire aux exigences suivantes :

• TLS 1.2 et SRTP

• Prise en charge du TLS mutuel

• Session Initiation Protocol (SIP)

• DTMF (RFC-2833)

• Masquage de topologie (RFC-5853)

• SIP Early Offer (obligatoire)

• Codecs Opus, G.711 μ-law, G.711 A-law et G.729

Les intégrations PSTN nécessitent un SBC et un fournisseur tiers fiable

Pour la connectivité PSTN, les clients doivent fournir un session border controller (SBC) connecté soit à une connexion héritée, soit à une liaison SIP avec une connexion cellulaire ou alternative (par ex. DSL). Les clients doivent garder à l'esprit que toute liaison SIP déployée sur le SBC peut 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é PSTN.

Tout SBC certifié BYOC pour Zoom Phone peut être utilisé

Tout session border controller (SBC) qui est certifié pour Zoom Phone peut également être utilisé avec le module ZPLS. Les clients disposant d'un plan BYOC Zoom Phone existant n'ont pas besoin d'un SBC supplémentaire ou distinct aux fins de résilience.

Les certificats DigiCert de Zoom doivent être installés sur le SBC

Afin d'établir une connectivité TLS à la fois vers le module ZPLS et le cloud Zoom, les certificats racine et intermédiaires DigitCert de Zoom doivent être installés sur le SBC.

Les SBC doivent acheminer les appels entrants vers les centres de données Zoom Phone en premier et deuxième choix, et le module ZPLS en troisième

Les SBC clients doivent acheminer les appels entrants depuis le PSTN 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 que lors d'un événement de résilience, car le SBC et les centres de données Zoom Phone devraient par ailleurs maintenir une connectivité stable.

Le non-respect de cette logique peut entraîner des échecs de livraison des appels, car le module ZPLS ne peut pas acheminer les appels vers des appareils enregistrés dans le cloud.

Une fois que le cloud Zoom Phone est disponible après un événement de résilience, un SBC peut temporairement tenter d'acheminer les numéros BYOC vers le cloud Zoom pendant que le dispositif client du numéro concerné est enregistré auprès du module ZPLS. Si cela se produit, le routage des appels suivra les paramètres pour Quand un appel n'est pas répondu pendant cette période intérimaire.

Les appels sortants depuis le module ZPLS doivent être acheminés vers le SBC et la liaison SIP PSTN

Lorsque le mode de résilience est actif, les appels du ZPLS vers le SBC doivent être acheminés vers la liaison SIP PSTN pour é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 résilience au format E.164.

Considérations locales de renvoi d'appel pour la résilience

Lors d'un événement de résilience, 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 renvoi d'appel

Lors d'un événement de résilience, les numéros de téléphone fournis par Zoom ne seront pas joignables depuis la perspective du cloud. Par conséquent, les utilisateurs situés dans des sites affectés peuvent être injoignables à moins que les appels vers leurs numéros principaux ne soient renvoyés vers un numéro alternatif associé à un SBC sur site.

Des exemples courants de numéros impactés peuvent inclure des numéros attribués à : utilisateurs, espaces communs, réceptionnistes automatiques (AR), groupes de lignes partagées (SLG) et files d'attente d'appels (CQ).

Les clients utilisant un BYOC sur site ne nécessitent pas de configurations avancées et peuvent contourner le renvoi 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 chez Zoom Phone) ne nécessitent pas de configurations avancées pour activer le renvoi d'appel. Au lieu de cela, les clients BYOC peuvent ajouter une route tertiaire vers le module ZPLS depuis le SBC situé dans les locaux.

Les configurations de renvoi d'appel sont définies par un administrateur ou un utilisateur autorisé depuis le portail web

Un administrateur de compte ou un utilisateur autorisé peut configurer la logique de renvoi d'appel depuis le portail web via saisie manuelle ou un téléchargement CSV en masse.

Les utilisateurs configurés pour le renvoi d'appel auront trois numéros attribués

Après avoir appliqué un numéro BYOC à un utilisateur pour la résilience via renvoi d'appel, l'appareil client se verra attribuer au moins trois numéros :

1. Une extension interne avec le code du site préfixé

2. Un numéro PSTN fourni par Zoom

3. Un numéro PSTN BYOC

Les numéros de téléphone peuvent être renvoyés vers au maximum un numéro BYOC

Chaque numéro Zoom Phone peut être renvoyé vers un maximum de un autre numéro BYOC. Cependant, vous pouvez renvoyer plusieurs numéros de téléphone vers le même numéro BYOC.

Par exemple, si John se voit attribuer le numéro X55-555-5555, le numéro de John peut être renvoyé vers le numéro de l'opérateur de son bâtiment au X99-999-9999. De même, les collègues de John peuvent également voir leurs numéros (X55-555-5554, X55-555-5553, etc.) renvoyés vers X99-999-9999. Alternativement, chaque utilisateur peut voir son numéro renvoyé vers un numéro totalement unique, tel que X55-555-5554 redirigeant vers X99-999-9998, et X55-555-5553 redirigeant vers X99-999-9997. Toutefois, aucun utilisateur individuel ne peut voir son numéro renvoyé à la fois vers X99-999-9999 et X99-999-9998.

Le renvoi d'appel doit rester désactivé jusqu'à ce qu'un événement de résilience se produise

Bien qu'un administrateur puisse préconfigurer la logique de renvoi d'appel pour un site à l'avance, la fonctionnalité de renvoi d'appel doit rester désactivée jusqu'à ce qu'un événement de résilience se produise. Si le renvoi d'appel est activé pendant les opérations normales, tous les appels entrants vers un numéro enregistré sur Zoom Phone seront redirigés vers le SBC sur site et le numéro BYOC associé, contournant les services Zoom Phone. Par conséquent, pour maintenir le routage normal de Zoom Phone, le renvoi d'appel doit être désactivé pendant les opérations normales.

Le renvoi d'appel ne peut être activé que par un utilisateur autorisé ou un administrateur disposant d'une connexion Internet fonctionnelle

Lors d'un événement de mode résilience, la connexion Internet d'un site est supposée indisponible. Cependant, parce que le renvoi d'appel doit rester désactivé pour le fonctionnement standard, il ne peut être activé que par un utilisateur autorisé ou un administrateur disposant d'une connexion Internet fonctionnelle telle qu'un forfait de données téléphoniques, ou une connexion Internet alternative depuis un autre emplacement.

Pour minimiser les temps d'arrêt et assurer la continuité des activités, 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 résilience.

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 résilience, 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 de l'utilisateur, même s'il maintient une connexion cloud indépendante

Lorsque le renvoi d'appel est activé pour un numéro enregistré sur 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 renvoi d'appel, tous les appels seront acheminés via le PSTN vers le SBC de l'entreprise.

Par exemple, un site connaît un événement de mode résilience 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 cellulaire. Si le numéro de téléphone d'un utilisateur est marqué pour le renvoi d'appel, le cloud Zoom Phone ne fera pas

sonner leur numéro Zoom Phone via l'application mobile, malgré la connexion stable. Au lieu de cela, tous les appels continueront d'être acheminés via le PSTN vers le SBC du client.

Si le renvoi d'appel n'est pas activé pour un utilisateur lors d'un événement de résilience, les appels entrants suivront les préférences de gestion d'appels de chaque utilisateur Si le renvoi d'appel n'est pas activé pendant un événement de résilience, les appels entrants seront traités conformément à la logique de gestion des appels 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 Quand un appel n'est pas répondu

section des préférences de gestion des appels.

Le renvoi d'appel ne s'applique qu'aux appels PSTN entrants 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 Le renvoi d'appel pour la résilience ne s'applique qu'aux appels acheminés via le PSTN et/ou le cloud Zoom Phone. Les appels provenant d'extensions enregistrées Zoom au sein du même site tenteront d'abord de se connecter via le module ZPLS, et via le PSTN en second lieu si un SBC est connecté. Les appels qui ne peuvent pas se connecter seront autrement soumis au traitement défini par la

section des règles de gestion des appels dans les paramètres téléphoniques d'un utilisateur.

Flux de renvoi d'appel Le diagramme suivant détaille la logique du renvoi d'appel (une fois activé) lors d'un événement de résilience. Cette logique restera en vigueur jusqu'à ce que le renvoi d'appel soit désactivé ou que les opérations normales soient rétablies. Cependant, si le renvoi d'appel reste activé après

1. la restauration des opérations normales, les appels transférés feront une boucle (hairpin) depuis le cloud Zoom Phone, vers le SBC, puis de nouveau vers le cloud, avant d'être délivrés à l'appareil d'un utilisateur. Pour cette raison, le renvoi d'appel doit être désactivé rapidement après un événement de résilience.

2. Un appelant externe initie un appel vers un numéro enregistré sur Zoom Phone, et est acheminé via le PSTN.

L'appel est acheminé vers le cloud Zoom Phone, et le numéro composé est identifié comme impacté par le renvoi d'appel. 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 Si le renvoi d'appel n'est pas activé, Zoom Phone suivra la

1. logique pour cet utilisateur ou cette extension particulière.

2. Parce que le renvoi d'appel est activé, Zoom n'essaiera pas d'alerter l'utilisateur et redirigera plutôt l'appel vers le numéro de renvoi d'appel désigné via le PSTN.

3. L'appel est acheminé depuis le PSTN vers le SBC de résilience.

4. Le SBC de résilience transmet l'appel au module ZPLS.

Le module ZPLS transmet l'appel aux clients enregistrés de l'utilisateur, si connectés.

Considérations concernant le numéro d'identification de localisation 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 localisation d'urgence (ELIN) est un numéro de téléphone dédié utilisé par les points de réponse à la sécurité publique (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 PSTN pour associer une adresse à un numéro de téléphone, afin d'aider à garantir que l'adresse figure dans une base de données d'identification automatique de localisation (ALI) lorsque l'appel est reçu par un opérateur PSAP. Par exemple, considérez 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 compose les services d'urgence pendant un événement de résilience depuis un téléphone ou un appareilassocié au site

, 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 service.

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 pendant un événement de résilience, 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 original en cas de rappel.

De plus, un ELIN peut être attribué à un utilisateur ou à un téléphone d'espace commun, offrant une attribution d'ELIN plus granulaire que le niveau du site, et fournissant une localisation plus précise pour les services d'urgence.

Lors d'un événement de résilience, tous les appels d'urgence sont remplacés par l'ELIN

Lorsqu'un utilisateur passe un appel d'urgence pendant un événement de résilience, 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é à la liaison PSTN du SBC du site Le ELIN d'un site doit

être un numéro BYOC qui est terminé sur une liaison PSTN située sur le SBC de basculement du site. Aucun autre type de numéro ne peut être utilisé.

Le module ZPLS redirigera automatiquement les rappels des prestataires d'urgence vers l'ELIN vers l'extension de l'utilisateur qui a initialement composé pendant une durée pouvant aller jusqu'à 2 heures

Si un opérateur d'urgence rappelle l'ELIN, le module ZPLS acheminera l'appel vers l'utilisateur original qui a passé l'appel d'urgence. Le module ZPLS continuera à acheminer les rappels PSAP vers l'appelant original pendant une durée pouvant aller jusqu'à 2 heures. À l'heure actuelle, cette fonctionnalité 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 pas être attribué à un utilisateur ou à une autre entité Zoom Phone sauf s'il est désaffecté.

Les clients sont responsables de la maintenance 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 des opérateurs BYOC avec les adresses physiques correspondant à chaque ELIN. Les clients sont responsables de veiller à ce que les adresses d'urgence soient correctement mappées à l'adresse physique appropriée.

Considérations sur le routage PSTN

Lorsque le mode de résilience est actif, les paquets médias sont acheminés via le module ZPLS

Lorsque le mode de résilience est activé, les clients ne communiquent pas directement avec un SBC ou d'autres clients internes ; au lieu de cela, les paquets médias sont ancrés ou « hairpinés » via le module ZPLS, sans prise en charge du déchargement des médias.

Le diagramme suivant représente le chemin de signalisation et des médias pour les appels internes et externes actifs.

Les appels tenteront de s'acheminer localement en premier

Chaque fois que possible, le module ZPLS tentera d'acheminer les appels provenant des 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'invite SIP entrante ne correspond pas à une extension enregistrée. Une extension enregistrée est une courte extension sans le code du site, une longue extension avec le code du site, un numéro attribué enregistré chez 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

Pendant un événement de résilience, les appels externes sortants afficheront le numéro BYOC de l'utilisateur

Pendant un événement de résilience, les appels externes sortants depuis des appareils enregistrés auprès du ZPLS contiendront le numéro d'appelant BYOC. Le diagramme suivant illustre le flux d'appel en mode résilience pour un utilisateur :

Les appels de retour peuvent être dirigés vers le numéro BYOC d'un utilisateur Parce que les appels externes sortants passés lors d'un événement de résilience utiliseront un numéro BYOC, les appelants externes peuvent rappeler en utilisant un numéro BYOC au lieu du numéro Zoom enregistré de l'utilisateur. Si l'événement de résilience est terminé, les appels seront renvoyés via le cloudsi la priorité de routage correcte est configurée

. Cependant, si l'événement est en cours, le SBC acheminera l'appel vers le module ZPLS et l'appareil client enregistré.

Codecs de résilience pris en charge

Les codecs de résilience pris en charge sont Opus, G.711 μ-law, G.711 A-law et G.729. La transcodification ou le transrating 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 le même taux d'échantillonnage.

Considérations sur les groupes de distribution de résilience

Cette section aborde les considérations pour les groupes de distribution de résilience (SDG). Les clients qui ne prévoient pas d'utiliser les SDG ou d'intégrer le module ZPLS avec une connectivité PSTN peuvent passer cette section sans conséquence.

Les groupes de distribution de résilience offrent des options de routage d'appels nuancées lors d'un événement de résilience

Les groupes de distribution de résilience (SDG) offrent aux entreprises des options de routage d'appels nuancées — comme des files d'attente d'appels et des menus interactifs de réponse vocale (IVR) — lors d'un événement de résilience. Avec les SDG, les entreprises peuvent continuer à prendre en charge les services téléphoniques essentiels et les configurations de routage d'appels (similaires aux files d'attente d'appels, aux réceptionnistes automatiques et aux groupes de lignes partagées) jusqu'à ce que les opérations normales soient rétablies.

Les SDG ne sont pas identiques aux groupes de distribution en fonctionnement normal et doivent être construits et maintenus séparément ne Bien que les SDG offrent une fonctionnalité de routage d'appels similaire à celle des groupes de distribution en fonctionnement normal, les SDG sont uniques et spécifiques aux événements de résilience et, par conséquent, doivent être construits et entretenus séparément. En d'autres termes, les SDG

héritent des paramètres ou configurations d'un groupe de distribution en fonctionnement normal (c.-à-d. file d'attente d'appels, réceptionniste automatique, IVR, etc.)

Les SDG sont mieux associés à une intégration BYOC-PSTN et au renvoi d'appel activé

Bien que les SDG puissent fournir un support interne uniquement (c.-à-d. appels non PSTN), ils sont mieux associés à une intégration BYOC-PSTN. Avec un SDG activé pour le PSTN, une fois le renvoi d'appel activé pendant un événement de résilience, un numéro principal de l'entreprise peut acheminer vers le numéro SDG désigné, et l'appel suivra le profil de routage configuré. Cela permet à une entreprise d'offrir une expérience de flux d'appel cohérente pour les appelants externes jusqu'au rétablissement des opérations normales.

Le diagramme suivant démontre la logique de routage des appels pour un SDG activé pour le PSTN :

Les SDG peuvent être personnalisés de la manière suivante

• Les SDG prennent en charge les options suivantes :

• Numéro d'extension dédié

• Numéro direct entrant attribué

• Fuseau horaire

• Heures d'ouverture

• Messages d'accueil enregistrés

• Membres du groupe

  • Acheminer vers :

  • Utilisateur

  • Messages d'accueil enregistrés

  • Menu de réponse vocale interactive (IVR)

• Numéro de téléphone

  • Distribution des appels :

  • Simultanée

Séquentielle

Considérations matérielles et réseau

Cette section aborde les considérations matérielles et réseau pour le module ZPLS, une intégration SBC, les clients Zoom et les appareils téléphoniques. Après avoir lu cette section, vous devriez comprendre les communications réseau nécessaires et les configurations pour un déploiement ZPLS. Cette section est dédiée au déploiement matériel et auconsidérations de conception . Reportez-vous à la section sur le déploiement de ZPLS

pour des instructions de déploiement pas à pas.

Considérations de déploiement et de 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 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 de compte et d'utilisateur

Dans la plupart des cas, un module ZPLS peut être déployé sur un LAN interne au sein du réseau d'un client. Alternativement, un réseau DMZ peut être utilisé dans certaines circonstances ; cependant, les administrateurs réseau doivent s'assurer que la communication est possible à travers le pare-feu d'entreprise. Dans les deux cas, les administrateurs sont tenus d'ajuster la politique du pare-feu de l'entreprise pour permettre 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 à l'état inactif, le module ZPLS doit maintenir un ping keepalive OPTIONS avec le cloud Zoom Phone pour surveiller la connectivité. Dans le cas où à la fois 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 en utilisant l'authentification SIP Digest sur TLS v1.2.

Considérations de déploiement et de 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 à la fois le module ZPLS et le cloud Zoom Phone, chaque fois que possible. Les clients peuvent provisionner un SBC à double NIC 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 périphérique en plus de l'ouverture des ports requis.

Un SBC doit maintenir une connectivité TLS et UDP entre le cloud Zoom Phone et le module ZPLS Pendant les opérations habituelles, un SBC doit maintenir une connectivité TLS et UDP à la fois vers le cloud Zoom Phone et vers 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é BYOCvia le cloud Zoom Phone

. Le mécanisme keepalive OPTIONS est automatiquement activé entre ZPLS et le SBC et est optionnel entre le SBC et le cloud.

Considérations pour les clients Zoom et les appareils téléphoniques

Les clients et appareils doivent être capables de découvrir le module ZPLS du site sur le réseau local Les clients et appareils pris en charge activés pour la résilience téléphonique découvrent le module ZPLS de basculement approprié depuis le cloud Zoom Phone lors du processus de démarrage. Cependant, le module doit déjà être lié au site du système téléphonique

avec une adresse IPv4 découvrable 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 une IP statique, 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 réussir à s'enregistrer.

Les clients et appareils doivent maintenir un ping OPTIONS régulier avec le cloud Zoom Phone

Similaire au module ZPLS, les clients et appareils pris en charge doivent maintenir un ping keepalive OPTIONS vers le cloud Zoom Phone pour déterminer l'état de connectivité du centre de données. En cas 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.