Considérations d'intégration PSTN

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

Considérations d'intégration du SBC

Exigences pour les SBC

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

• TLS 1.2 et SRTP

• Prise en charge de Mutual TLS

• 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 RTC nécessitent un SBC et un fournisseur tiers fiable

Pour la connectivité RTC, 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 les trunks SIP déployés sur le 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.

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 vers le cloud Zoom, les certificats racine et intermédiaires DigiCert 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 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 de tenter le module ZPLS. Avec cette configuration, les appels ne seront routés vers le module ZPLS que pendant un événement de résilience, car le SBC et les centres de données Zoom Phone devraient sinon 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 router 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 de router les numéros BYOC vers le cloud Zoom pendant que l'appareil client du numéro affecté est enregistré sur le module ZPLS. Si cela se produit, le routage des appels suivra les paramètres pour Lorsque un appel n'est pas répondu pendant cette période intérimaire.

Les appels sortants du module ZPLS doivent être routés vers le SBC et le trunk SIP RTC

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

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

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 sauf s'ils sont 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 de la perspective du cloud. Par conséquent, les utilisateurs situés dans des emplacements affecté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.

Des exemples courants de numéros impactés peuvent inclure des 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 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 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. Au lieu de cela, les clients BYOC peuvent ajouter une route tertiaire au module ZPLS depuis le SBC sur site.

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 affecté un numéro BYOC à un utilisateur pour la résilience par 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 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 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 faire rediriger son numéro vers un numéro complètement unique, par exemple X55-555-5554 redirigeant vers X99-999-9998, et X55-555-5553 redirigeant vers X99-999-9997. Cependant, aucun utilisateur individuel ne peut faire rediriger son numéro à 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é-provisionner 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 courantes, tous les appels entrants vers un numéro enregistré sur Zoom Phone seront réacheminé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 courantes.

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 en mode résilience, la connexion Internet d'un site est supposée indisponible. Cependant, puisque 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 comme 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 de router 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 renvoi d'appel, tous les appels seront routés via le RTC vers le SBC de l'entreprise.

Par exemple, un site subit un événement en 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 de l'utilisateur est marqué pour renvoi d'appel, le cloud Zoom Phone ne serez pas 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 routés via le RTC vers le SBC du client.

Si le renvoi d'appel n'est pas activé pour un utilisateur pendant un événement de résilience, les appels entrants suivront les préférences de gestion des 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 Lorsque 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 entrants RTC

Le renvoi d'appel pour la résilience ne s'applique qu'aux appels routés via le RTC et/ou le cloud Zoom Phone. Les appels provenant d'extensions enregistrées sur Zoom au sein du même site tenteront de se connecter via le module ZPLS en premier, et via le RTC en second si un SBC est connecté. Les appels qui ne peuvent pas se connecter seront autrement soumis au traitement défini par la Lorsque un appel n'est pas répondu section des règles de gestion 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 de renvoi d'appel (une fois activé) pendant 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 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 feront un 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.

1. Un appelant externe initie un appel vers un numéro enregistré sur Zoom Phone, et est routé via le RTC.

2. L'appel est routé vers le cloud Zoom Phone, et le numéro composé est identifié comme impacté par le renvoi d'appel.

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

1. 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 RTC.

2. L'appel est routé depuis le RTC vers le SBC de résilience.

3. Le SBC de résilience transfère l'appel vers le module ZPLS.

4. Le module ZPLS transfère l'appel vers le(s) client(s) enregistré(s) de l'utilisateur, s'ils sont connectés.

Considérations relatives au 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é qui est utilisé par les centres d'appels de sécurité publique (PSAP) pour identifier l'adresse physique d'un appelant lorsqu'il appelle les services d'urgence. Pour cette fonctionnalité, les entreprises doivent travailler avec leur fournisseur de services RTC pour mapper une adresse à un numéro de téléphone, afin de s'assurer que l'adresse est répertoriée dans une base de données d'identification automatique de la 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 appareil associé au site, les services d'urgence recevront automatiquement l'adresse complète enregistrée pour le site, à condition que la localisation soit configurée 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 disposer d'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 d'origine 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 celle au niveau du site, et fournissant une localisation plus précise aux services d'urgence.

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

Lorsque un utilisateur effectue un appel d'urgence pendant un événement de résilience, le numéro appelant de l'utilisateur, si disponible, sera remplacé par l'ELIN désigné au niveau du site. Cela permet aux utilisateurs n'ayant pas de numéro direct d'appeler les services d'urgence et d'être joignables en retour par l'opérateur d'urgence.

Un numéro ELIN doit être un numéro BYOC associé au trunk PSTN du SBC du site

L'ELIN d'un site doivent doit être un numéro BYOC qui est terminé sur un trunk PSTN situé sur le SBC de basculement du site. Aucun autre type de numéro ne peut être utilisé.

Le module ZPLS acheminera automatiquement les rappels des services d'urgence vers l'ELIN vers l'extension de l'utilisateur qui a initialement composé pendant jusqu'à 2 heures

Si un opérateur d'urgence rappelle l'ELIN, le module ZPLS acheminera l'appel vers l'utilisateur d'origine qui a passé l'appel d'urgence. Le module ZPLS continuera à router les rappels PSAP vers l'appelant d'origine pendant 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 être attribué à aucun utilisateur ni à aucune autre entité Zoom Phone à moins d'être 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 corrélées à chaque ELIN. Les clients sont responsables de s'assurer que les adresses d'urgence sont correctement mappées à l'adresse physique appropriée.

Considérations de routage RTC

Lorsque le mode résilience est activé, les paquets média sont routés via le module ZPLS

Lorsque le mode 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édia sont ancrés ou « hairpin » via le module ZPLS, sans prise en charge du déchargement média.

Le diagramme suivant illustre le chemin du signal et des médias pour les appels internes et externes actifs.

Les appels tenteront d'être routés localement en premier

Dans la mesure du possible, le module ZPLS tentera de router 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 Request URI de l'invite SIP entrante 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 attribué enregistré sur 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.

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

Lors d'un événement de résilience, les appels externes sortants depuis des appareils enregistrés sur 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 retournés peuvent être routés vers le numéro BYOC d'un utilisateur

Parce que les appels externes sortants passés pendant 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 routés de nouveau via 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é du client.

Codecs pris en charge en mode résilience

Les codecs pris en charge en mode résilience 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 la même fréquence d'échantillonnage.

Considérations relatives aux groupes de distribution de résilience

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

Les groupes de distribution de résilience offrent des options de routage d'appels nuancées pendant 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 de réponse vocale interactive (IVR) — pendant un événement de résilience. Grâce aux SDG, les entreprises peuvent continuer à prendre en charge les services téléphoniques de base et les configurations de routage d'appels (similaires aux files d'attente d'appels, réceptions automatiques et groupes de lignes partagées) jusqu'au rétablissement des opérations standard.

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

Bien que les SDG offrent une fonctionnalité de routage d'appels similaire à celle des groupes de distribution en opération standard, les SDG sont uniques et spécifiques aux événements de résilience, et doivent par conséquent être créés et maintenus séparément. En d'autres termes, les SDG ne serez pas héritent des paramètres ou des configurations d'un groupe de distribution en opération standard (par ex. 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 uniquement interne (c.-à-d. appels non RTC), 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 être routé 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 standard.

Le diagramme suivant montre la logique de routage d'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 DID attribué

• Fuseau horaire

• Heures d'ouverture

• Messages d'accueil enregistrés

• Membres du groupe

• Acheminer vers :

  • Utilisateur

  • Menu de réponse vocale interactive (IVR)

  • Membres du groupe

  • Numéro de téléphone

• Distribution des appels :

  • Simultanée

  • Séquentiel

Considérations matérielles et réseau

Cette section traite des 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 la lecture de cette section, vous devriez comprendre les communications réseau et les configurations nécessaires pour un déploiement ZPLS.

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

Considérations de déploiement et de mise en 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 de l'entreprise. Dans les deux cas, les administrateurs doivent ajuster la politique du pare-feu d'entreprise pour autoriser 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

Au repos, le module ZPLS doit maintenir un ping OPTIONS de maintien en vie 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 sur le module ZPLS en utilisant l'authentification SIP Digest sur TLS v1.2.

Considérations de déploiement et de mise en réseau du SBC

Un SBC doit être joignable depuis ZPLS et le cloud Zoom dans la mesure du possible

Les clients doivent s'assurer que le SBC maintient la connectivité avec à la fois le module ZPLS et le cloud Zoom Phone, dans la mesure du 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 de bord 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 courantes, un SBC doit maintenir une connectivité TLS et UDP vers à la fois le cloud Zoom Phone et le module ZPLS du site associé. Cette connexion est utilisée pour router tout appel potentiel vers un numéro téléphonique répertorié BYOC via le cloud Zoom Phone. Le mécanisme OPTIONS keepalive 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 pouvoir 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écouverte en interne.

Les appareils devraient disposer d'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 reçoit pas d'IP statique ou si un serveur DHCP n'est pas disponible pendant un événement de résilience, les appareils téléphoniques peuvent ne pas pouvoir 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 OPTIONS de maintien en vie vers le cloud Zoom Phone afin de déterminer l'état de connectivité du centre de données. 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

Voir la section sur Ports réseau et flux de données.