Merci pour votre commentaire.

Dans le modèle de déploiement sur site unique, où un nœud de survie amélioré (ESN) est déployé sur un site ainsi qu'une passerelle locale pour le routage des appels PSTN. Un maximum de 7 500 appareils peuvent être enregistrés sur l'ESN en cas de panne.

Dans le modèle de déploiement sur plusieurs sites, où il y a plusieurs sites et où l'ESN peut être déployé sur chaque site, cela dépend des exigences commerciales en matière de survie du site. Les exigences d'une passerelle locale et d'un DNS sont toujours indispensables et un total de 8 nœuds ESN peuvent être ajoutés à un Unified CM cluster.

Ce modèle de déploiement est pertinent pour les clients d'une région qui compte plusieurs sites et la capacité de survie est une exigence pour plusieurs de ces sites. Bien qu'il soit possible de partager la passerelle locale PSTN entre les sites, ce n'est pas recommandé. En cas de panne de réseau, le site peut être isolé et dans ce cas, ESN ne sera pas en mesure de joindre la passerelle locale pour acheminer les appels vers le PSTN.

Voici deux options de déploiement pour un déploiement sur plusieurs sites :

• Option 1 : Un nœud de survie amélioré est déployé sur chaque site.

• Option 2 — Nœud de survie amélioré commun partagé entre plusieurs sites.

Nous surveillons et gérons le nœud de survie amélioré comme les autres nœuds déployés dans un centre de données d'instance dédié. Lors d'un événement de survie, lorsque l'ESN est déconnecté, nous perdons l'Cisco Cloudaccès au nœud et nous nous reconnectons automatiquement lorsque la panne est résolue et que la connectivité est rétablie.

Nous gérons les certificats d'application UC et, lors de l'activation du nœud de survie amélioré, nous avons mis à jour le certificat de Unified CM cluster d'instances dédiées avec l'ESN.

Pendant l'événement de survie, le nœud de survie amélioré stocke toutes les données CDR/CMR en local. Une fois la connectivité rétablie, les données seront synchronisées avec l'Unified CMéditeur d'instance dédié. La quantité de données pouvant être stockée dépend de la taille du disque du nœud de survie amélioré de l'époque. L'espace disque maximum que vous pouvez définir pour le CDR est de 3 328 Mo. Cela peut se faire avec des fichiers CDR de petite ou grande taille en fonction de l'intervalle CDR configuré. La purge se fait sur la base de :

• Lorsque l'utilisation du disque dépasse l'espace disque alloué ou configuré, les enregistrements traités sont supprimés. Si l'utilisation du disque continue à augmenter, c'est à ce moment-là que les enregistrements non traités sont également purgés.

• High Water Mark % configuré dans les paramètres de « Gestion des CDR », les fichiers CDR seront purgés. Par exemple, si le « High Water Mark % » est configuré à 80 % et que l'utilisation du disque est de 80 %, les fichiers CDR seront purgés.

• Durée de conservation des fichiers CDR/CMR (jours) configurée dans les paramètres de « Gestion des CDR », les fichiers CDR seront purgés. Par défaut, il est réglé sur 30 jours.

Voici les alertes en RTMT concernant le nœud de survie amélioré :

• SurvivabilityEvent : l'alarme se déclenche lorsque tous les nœuds d'instance dédiés ne sont pas accessibles depuis le nœud de survie amélioré.

• RemoteSurvivableNodeNotReachable : l'alarme se déclenche lorsqu'un nœud de survie amélioré n'est pas accessible depuis l'éditeur de l'instance dédiée. Unified CM

Pendant l'événement de survie, vous devez connecter RTMT au nœud Enhanced Survivability pour suivre les performances de l'ESN. Il n'en sera pas de même si le RTMT est connecté aux nœuds d'instance dédiés, car l'ESN ne sera pas accessible depuis le cloud pendant l'événement de survie.

En fonctionnement normal, la réplication de la base de données est entièrement maillée entre tous les serveurs, y compris le nœud de survie amélioré du Unified CM cluster. Les données de configuration statiques, créées par le biais de déplacements, d'ajouts et de modifications, sont toujours stockées sur l'éditeur et répliquées dans un sens de l'éditeur à chaque abonné et au nœud de survie amélioré du cluster.

Lors d'un événement de survie, seules les fonctionnalités destinées aux utilisateurs sont modifiées sur les appareils enregistrés sur le Enhanced Survivability Node et les fonctionnalités destinées aux utilisateurs sont généralement caractérisées par le fait que vous pouvez activer ou désactiver une fonctionnalité directement sur leur téléphone en appuyant sur un ou plusieurs boutons, au lieu de modifier une fonctionnalité via une interface graphique Web. L'Enhanced Survivability Node permet donc de prendre soin de soi et de gérer l'interface graphique d'administration Web en lecture seule. Les appareils de l'utilisateur enregistrés auprès d'ESN ne peuvent modifier que les fonctionnalités destinées aux utilisateurs répertoriées ci-dessous lors du basculement. Cependant, ces modifications ne seront pas synchronisées avec l'Unified CMéditeur DI une fois la connectivité rétablie.

Les fonctionnalités destinées aux utilisateurs sont toutes les fonctionnalités qui peuvent être activées ou désactivées en appuyant sur les boutons du téléphone, notamment les suivantes :

• Call Forward All (CFA)

• Activer ou désactiver la confidentialité

• Activer ou désactiver le mode Ne pas déranger (DND)

• Cisco Extension MobilityLogin

• Connexion ou déconnexion à Hunt-group

• Mobilité des appareils

• Statut CTI CAPF pour les utilisateurs finaux et les utilisateurs des applications.

L'authentification des clients logiciels (Cisco Jabberet de l'application Webex) lors du basculement vers Enhanced Survivability Node est la suivante :

1. Authentification locale : lorsque l'authentification des utilisateurs est effectuée localement dans le cadre de l'événement de survieUnified CM, le nœud de survie amélioré sera en mesure d'authentifier les clients qui y sont enregistrés.

2. Authentification LDAP : Dans ce cas, l'authentification des utilisateurs se fait via le serveur LDAP local. Ensuite, pendant l'événement de survie, l'authentification des clients logiciels fonctionnera à condition que le serveur LDAP soit accessible depuis le nœud de survie amélioré.

   Vous devez vous assurer que l'annuaire LDAP est accessible à ESN tout au long de l'événement de survie.

3. Authentification par connexion unique (SSO) : L'authentification SSO des utilisateurs se fait via le serveur IDP. Ensuite, lors de l'événement de survie, l'authentification des clients logiciels fonctionne à condition que le serveur IDP soit accessible depuis le nœud de survie amélioré.

   Pour la connexion à l'interface utilisateur Unified CM Web activée par SSO, l'accessibilité de l'IDP est requise ou l'URL de connexion basée sur la récupération doit être utilisée.

   Les clients déjà authentifiés continuent d'être connectés car l'authentification est basée sur le jeton obtenu avant l'événement de survie. Cependant, pour les nouvelles connexions alors que le client ne possède pas de jeton valide lors de l'authentification précédente, l'ESN redirigera vers le serveur IDP pour authentification. Il est donc toujours nécessaire de garantir l'accessibilité du serveur IDP à ESN tout au long de l'événement de survie.

Des ressources multimédia sont requises pour que les Unified CM fonctionnalités de base, telles que Music on Hold, Announcement, Conference Bridge (logiciel), soient activées sur l'ESN. Si des ressources multimédia basées sur le matériel ont été déployées, vous devez vous assurer que les serveurs multimédia sont accessibles depuis l'ESN lors de l'événement de survie.

Pendant le fonctionnement normal du Unified CM cluster DI, les appels d'urgence (en particulier dans la région AMER) sont acheminés via le cloud RedSky où un trunk SIP est configuré entre le cluster CM unifié de l'instance dédiée et le cloud RedSky.

En cas d'événement susceptible de survivre, le cloud RedSky ne sera pas accessible depuis l'ESN. Vous devez donc configurer le plan de numérotation des appels d'urgence de telle sorte que, si le RedSky n'est pas disponible, vous puissiez acheminer les appels d'urgence via le PSTN GW local configuré sur ce site. Le groupe de routage doit être composé du PSTN GW local chargé de gérer le routage des appels pendant l'événement de survie.

Configurez le plan de numérotation pour acheminer les appels intrasite, intersite, inter-clusters et PSTN pendant l'événement de survie. En général, l'ESN peut acheminer les appels uniquement pour les appareils qui y sont enregistrés. Tous les autres appels doivent être acheminés vers le PSTN GW local (configuré sur tous les sites où ESN est déployé) et de là vers le PSTN. Voici quelques scénarios expliqués :

• Le téléphone 1 et le téléphone 2 sont enregistrés sous le même ESN — L'appel est acheminé au sein de l'ESN.

• Le téléphone 1 est enregistré auprès d'ESN et le téléphone 2 est enregistré auprès d'un Unified CM cluster d'instances dédié — Le plan de numérotation devrait acheminer les appels d'ESN vers le PSTN GW local, de là vers le DI via PSTN. Unified CM Lors de l'événement de survie, le plan de numérotation devrait détecter l'échec du routage des appels et les rediriger via le PSTN GW local. Il devrait en être de même pour les appels entrants vers ESN depuis des Unified CM appareils DI.

• Le téléphone 1 est enregistré auprès d'ESN et le téléphone 2 est un appareil PSTN : lors d'un événement de survie, les appels PSTN doivent être acheminés vers la passerelle PSTN locale. Vous devez vous assurer que le plan de numérotation est capable de détecter les échecs de routage des appels et de les rediriger via la passerelle PSTN locale disponible.

• Pendant l'événement de survie, lorsque la connectivité de votre site au cloud d'instance dédiée est interrompue (panne de réseau étendu ou panne de connectivité), les fonctions de messagerie vocale et d'assistance automatique ne fonctionneront pas pour les appareils qui s'enregistrent auprès de l'ESN, car le Cisco Unity Connection serveur est hébergé dans le cloud d'instance dédiée auquel la connectivité depuis ESN est coupée. Si votre appareil est configuré avec « Call Forward Unregistered (CFU) » et que l'appel est reçu en DIUnified CM, l'appelant peut déposer un message vocal sur l'instance dédiée Unity Connection. Qui peut être récupéré lorsque les appareils reviendront aux abonnés DI Unified CM.

• Cependant, lors d'un événement de survie lorsque la connectivité au cloud d'instances dédiées est disponible mais que le Unified CM cluster de DI est en panne, dans ce cas, les fonctionnalités de messagerie vocale et d'assistance automatique fonctionnent pour les appareils enregistrés auprès de l'ESN, car ESN disposera d'une connectivité au serveur Unity Connection déployé dans le cloud DI.

Pendant l'événement de survie, l'ESN ne sera pas en mesure d'atteindre les Cisco Expressway E et C dans le cloud DI et vice versa. Dans ce cas, les utilisateurs de la MRA ne peuvent pas accéder au service auprès d'ESN et ne pourront donc pas s'inscrire. Cependant, si l'appareil MRA dispose d'Internet et peut se connecter au Cisco Expressways dans le cloud DI, il peut s'enregistrer auprès du DI à Unified CM condition que le cluster de DI soit fonctionnel.

Pour que les intégrations basées sur la CTI fonctionnent avec Enhanced Survivability Node, vous devez ajouter Enhanced Survivability Node à la liste des serveurs de CTI. Les améliorations CTI sont destinées aux applications qui utilisent JTAPI afin d'autoriser Enhanced Survivability Node en tant que serveur CTI auquel l'application ne peut se connecter que si les serveurs CTI principaux ou secondaires de la liste configurée ne sont pas joignables. Pendant un fonctionnement normal, les applications CTI présentes sur site peuvent se connecter aux serveurs CTI principal et secondaire du cloud DI et, en cas d'événement de survie, elles peuvent se connecter au nœud de survie amélioré pour une expérience CTI continue. Les applications doivent s'adapter aux nouvelles API telles qu'elles sont exposées via l'interface JTAPI afin de garantir une solution de repli depuis le nœud de survie amélioré une fois la connectivité rétablie.

Pour plus d'informations sur les nouvelles API ajoutées, consultez la section sur la redondance, https://www.cisco.com/c/en/us/td/docs/ voice_ip_comm /cucm/ /14_0_1/ -unified-jtapi-developers-guide-14/ -unified-jtapi-developers-guide-1251_chapter_00.html jtapi_dev cucm_b_cisco cucm_b_cisco

Les applications tierces qui s'interfacent via les liaisons SIP sont compatibles avec Enhanced Survivability Node. Dans les configurations de jonction SIP, la configuration « Exécuter sur tous les nœuds » doit être activée.

Les appareils tiers dotés de la fonctionnalité TFTP tertiaire sont pris en charge.