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 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 TLS mutuel
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 exemple, DSL). Les Clients doivent garder à l’esprit que tout trunk SIP déployé sur le SBC peut 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.

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

Tout contrôleur de bordure de session (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 séparé aux fins de 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 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 depuis le 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 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 de livraison des appels, car le module ZPLS ne peut pas acheminer les appels vers des appareils enregistrés sur le cloud.

Une fois que le cloud Zoom Phone est disponible à la suite d’un événement de survivabilité, un SBC peut tenter temporairement d’acheminer les numéros BYOC vers le cloud Zoom pendant que l’appareil client du numéro concerné est enregistré sur le module ZPLS. Si cela se produit, le routage des appels suivra les Paramètres pour Lorsqu’un appel n’est pas répondu pendant cette période intermédiaire.

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 du 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 sur le module ZPLS sont envoyés au SBC configuré pour la survivabilité au format E.164.

Considérations relatives à la survivabilité locale du Renvoi 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, sauf s’ils sont réacheminés par le renvoi 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 sites concernés peuvent être injoignables, sauf si les appels vers leurs numéros principaux sont renvoyés vers un numéro alternatif associé à un SBC sur site.

Les exemples courants de numéros impactés peuvent inclure les numéros attribués à : Utilisateurs, Espaces communs, Réceptions automatiques (AR), Groupes de lignes partagées (SLG) et Files d’attente d’appels (CQ).

Les Clients utilisant un BYOC basé sur site n’ont pas besoin 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 basé sur site (c.-à-d. les Clients qui n’utilisent pas de numéros enregistrés sur Zoom Phone) n’ont pas besoin de configurations avancées pour activer le renvoi d’appel. À la place, les Clients BYOC peuvent ajouter une route tertiaire vers le module ZPLS depuis le SBC sur site.

Les configurations de renvoi 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 configurer la logique de renvoi d’appel depuis le portail web via une saisie manuelle ou un téléversement 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 survivabilité du renvoi d’appel, l’appareil client se verra attribuer au moins trois numéros :

Une extension interne avec le code du site préfixé
Un numéro RTC fourni par Zoom
Un numéro RTC BYOC

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

Chaque numéro Zoom Phone peut être renvoyé 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 le numéro de téléphone X55-555-5555 est attribué à John, le numéro de téléphone de John peut être transféré vers le numéro de l'opérateur de son bâtiment au X99-999-9999. De même, les numéros de téléphone de ses collègues (X55-555-5554, X55-555-5553, etc.) peuvent également être transférés vers le X99-999-9999. Sinon, chaque utilisateur peut avoir son numéro de téléphone transféré vers un numéro complètement unique, comme X55-555-5554 avec un routage vers X99-999-9998, et X55-555-5553 avec un routage vers X99-999-9997. Cependant, aucun utilisateur individuel ne peut avoir son numéro transféré à 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 survivabilité se produise

Bien qu'un administrateur puisse préconfigurer à l'avance la logique de renvoi d'appel pour un site, la fonctionnalité de renvoi d'appel doit rester désactivée jusqu'à ce qu'un événement de survivabilité se produise. Si le renvoi d'appel est activé pendant les opérations de routine, tous les appels entrant vers un numéro enregistré sur 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 régulier de Zoom Phone, le renvoi d'appel doit être désactivé pendant les opérations de routine.

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

Pendant un événement de mode survivabilité, la connexion Internet d'un site est supposée indisponible. Cependant, 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, comme un forfait de données téléphoniques, ou une autre connexion Internet dans un Emplacement différent.

Pour minimiser les temps d'arrêt et garantir 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 pendant un événement de survivabilité.

Les règles de renvoi d'appel peuvent s'appliquer à un site entier ou à des numéros individuels

Pendant un événement de survivabilité, un administrateur ou un utilisateur autorisé peut activer les 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é sur 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é possède 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 passeront par la RTC vers le SBC de l'entreprise.

Par exemple, un site subit un événement de 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 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 son numéro Zoom Phone via l'application mobile, malgré la connexion stable. À la place, tous les appels continueront d'être acheminés via la RTC vers le SBC du client.

Si le renvoi 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 renvoi d'appel n'est pas activé pendant un événement de survivabilité, les appels entrants seront traités conformément à la logique de traitement 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 Lorsqu'un appel n'obtient 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 survivabilité ne s'applique qu'aux appels acheminés via la RTC et/ou le cloud Zoom Phone. Les appels provenant d'extensions enregistrées sur Zoom au sein du même site tenteront d'abord de se connecter via le module ZPLS, puis via la 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'obtient 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 schéma suivant détaille la logique du renvoi d'appel (une fois activé) pendant un événement de survivabilité. Cette logique restera en vigueur jusqu'à ce que le renvoi d'appel soit désactivé ou que les opérations Standard soient rétablies. Cependant, si le renvoi d'appel reste activé après le rétablissement des opérations Standard, les appels transférés feront un aller-retour depuis le cloud Zoom Phone, vers le SBC, puis de retour vers le cloud, avant d'être remis à l'Appareil d'un utilisateur. Pour cette raison, le renvoi d'appel doit être désactivé rapidement après un événement de survivabilité.

Un appelant externe lance un appel vers un numéro enregistré sur Zoom Phone, et celui-ci est acheminé via la RTC.
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.

Si le renvoi d'appel n'est pas activé, Zoom Phone suivra la Lorsqu'un appel n'obtient pas de réponse logique pour cet utilisateur ou cette extension particulière.

Étant donné que le renvoi d'appel est activé, Zoom ne tentera pas d'envoyer une alerte à l'utilisateur et redirigera plutôt l'appel vers le numéro de renvoi d'appel désigné via la RTC.
L'appel est acheminé de la RTC vers le SBC de survivabilité.
Le SBC de survivabilité transfère l'appel au module ZPLS.
Le module ZPLS transfère l'appel au(x) client(s) enregistré(s) de l'utilisateur, s'il(s) est/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 communique 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 centres d'appels d'urgence (PSAP) pour identifier l'adresse physique d'un appelant lors d'un appel aux 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 aider à garantir que l'adresse figure 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, prenons un campus universitaire réparti 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 survivabilité à partir d'un téléphone ou d'un Appareil associé 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 services.

Chaque site peut prendre en charge plusieurs ELIN

Clients peuvent Attribuer plusieurs ELIN à un site pour un pool de ressources de numéros d'urgence. En cas d'urgence pendant un événement de survivabilité, cela permettra à plusieurs appelants de se voir attribuer chacun un ELIN unique, ce qui peut aider les services d'urgence à joindre l'appelant d'origine s'ils doivent retourner un appel.

De plus, un ELIN peut être attribué à un utilisateur ou à un téléphone de l'espace commun, offrant une attribution d'ELIN plus granulaire qu'au niveau du site et fournissant un Emplacement plus précis pour les 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 appelant 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é 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 vers le poste de l’utilisateur qui a composé initialement, pendant jusqu’à 2 heures

Si un opérateur d’urgence renvoie un appel à l’ELIN, le module ZPLS acheminera l’appel vers l’utilisateur d’origine qui a passé l’appel d’urgence. Le module ZPLS continuera à acheminer les rappels PSAP vers l’appelant d’origine pendant jusqu’à 2 heures. À ce stade, 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 ê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’assume aucune responsabilité quant à la mise à jour des opérateurs BYOC avec les adresses physiques qui correspondent à chaque ELIN. Les Clients sont responsables de veiller à ce que les adresses d’urgence soient correctement associées à l’adresse physique appropriée.

Considérations de routage RTC

Lorsque le mode de survie est Actif, les paquets multimédias sont acheminés via le module ZPLS

Lorsque le mode de survie 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 Assistance pour le déchargement des médias.

Le diagramme suivant illustre le chemin de signalisation et de média pour les appels internes et externes Actif.

Les appels tenteront d’abord de se router localement

Dans la mesure du possible, le module ZPLS tentera de router les appels provenant des clients Zoom enregistrés vers des destinations enregistrées localement. Les appels ne sont transmis au SBC que si la destination contenue dans le champ Request URI de l'Zoom Inviter SIP entrant ne correspond pas à une extension enregistrée.

Une extension enregistrée est une extension courte sans le code du site, une extension longue avec le code du site, un numéro Zoom enregistré attribué 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.

Lors d’un événement de survivabilité, les appels externes sortant afficheront le numéro BYOC de l’utilisateur

Lors d’un événement de survivabilité, les appels externes sortant provenant d’appareils enregistrés ZPLS contiendront le Calling Number BYOC. Le diagramme suivant illustre le flux d’appel en mode survivabilité pour un utilisateur :

Les appels retournés peuvent être routés vers le numéro BYOC d’un utilisateur

Parce que les appels externes sortant passés pendant un événement de survivabilité utiliseront un numéro BYOC, les appelants externes peuvent retourner un appel à l’aide d’un numéro BYOC au lieu du numéro de téléphone Zoom enregistré de l’utilisateur. Si l’événement de survivabilité est terminé, les appels repasseront par le cloud si 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 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. La conversion 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 le même taux d'échantillonnage.

Considérations relatives aux groupes de distribution de survivabilité

Cette section traite des 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 ignorer cette section sans conséquence.

Les Groupes de distribution de survivabilité offrent des options de routage des appels nuancées pendant un événement de survivabilité

Les groupes de distribution de survivabilité (SDG) offrent aux entreprises des options de routage des appels nuancées — 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 essentiels et les configurations de routage des appels (similaires aux files d'attente des appels, aux réceptionnistes automatiques et aux groupes de ligne partagée) jusqu'à ce que les opérations standard soient rétablies.

Les SDG ne sont pas les mêmes que les groupes de distribution en fonctionnement standard, et doivent être créés et maintenus séparément

Bien que les SDG offrent des fonctionnalités de routage des appels similaires à celles des groupes de distribution en fonctionnement standard, les SDG sont uniques et spécifiques aux événements de survivabilité, et doivent par conséquent être créés et maintenus séparément. En d'autres termes, les SDG ne héritent des Paramètres ou des configurations d'un groupe de distribution en fonctionnement standard (c'est-à-dire file d'attente des appels, réceptionniste automatique, SVI, etc.)

Les SDG sont mieux associés à une Intégrations BYOC-RTC avec le renvoi d'appel activé

Bien que les SDG puissent fournir une prise en charge interne uniquement (c.-à-d. des appels non RTC), ils sont mieux associés à une Intégrations BYOC-RTC. Avec un SDG compatible RTC, une fois le renvoi d'appel activé pendant un événement de continuité, 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 de flux d'appel cohérente 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 compatible RTC :

Les SDG peuvent être personnalisés des manières 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 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 traite des considérations relatives au matériel et au réseau pour le module ZPLS, une Intégrations SBC, les clients Zoom et les téléphones. Après avoir lu cette section, vous devriez comprendre les communications réseau nécessaires et les configurations requises pour un déploiement ZPLS.

Cette section est consacrée au déploiement du matériel et aux considérations de réseau de conception. Reportez-vous à la section sur le déploiement de ZPLS pour des instructions de déploiement étape par étape.

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.

Dans la plupart des cas, un module ZPLS peut être déployé sur un LAN interne au sein du réseau d’un Client. À titre alternatif, un réseau DMZ peut être utilisé dans certaines circonstances ; toutefois, les administrateurs réseau doivent s’assurer que la communication est possible à travers le pare-feu Entreprise. Dans tous les cas, les administrateurs doivent ajuster la stratégie de 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

En état d’inactivité, le module ZPLS doit maintenir un ping OPTIONS de maintien de session avec le cloud Zoom Phone pour surveiller la connectivité. Dans le cas où à la fois les appareils clients et le module ZPLS au sein 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 sur TLS v1.2.

Considérations relatives au déploiement et au réseau du SBC

Un SBC doit être joignable depuis ZPLS et 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 à double NIC configuré avec une adresse IPv4 privée et publique, ou s’assurer que des règles NAT 1:1 statiques sont en place sur le pare-feu de bordure, en plus de l’ouverture des ports requis.

Un SBC doit maintenir la connectivité TLS et UDP entre le cloud Zoom Phone et le module ZPLS

Lors des opérations courantes, un SBC doit maintenir la connectivité TLS et UDP avec le cloud 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 Zoom Phone. Le mécanisme de maintien de session 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 appareils doivent être capables de découvrir le module ZPLS du site au sein du réseau local

Les clients et les appareils pris en charge activés pour la survivabilité téléphonique découvrent le module ZPLS de basculement approprié depuis le cloud Zoom Phone pendant le 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 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 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 Zoom Phone

À l’image du module ZPLS, les clients et appareils pris en charge doivent maintenir un ping OPTIONS de maintien de session vers le cloud Zoom Phone afin de déterminer l’état de connectivité du data center. En cas de panne, le client continue d’envoyer des messages de maintien de session afin de détecter le rétablissement 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 le Ports réseau et flux de données.

Mis à jour il y a 4 mois

Ce contenu vous a-t-il été utile ?