Architecture

Présentation de Webex pour BroadWorks

Qu’y a-t-il dans le diagramme ?

Clients

  • Le client d’application Webex fait office d’application principale dans Webex pour les offres Cisco BroadWorks. Le client est disponible sur les ordinateurs de bureau, les périphériques mobiles et les plateformes Web.

    Le client a la messagerie d’origine, la présence et les réunions audio/vidéo multipartie fournies par le Cloud Webex. Le client Webex utilise l’infrastructure de BroadWorks pour SIP et RTCP appels.

  • Les téléphones IP Cisco et accessoires connexes utilisent également votre infrastructure BroadWorks pour les appels RTCP SIP. Nous prévoyons d’être en mesure de prendre en charge les téléphones tiers.

  • Portail d’activation des utilisateurs pour que les utilisateurs se connectent à Webex en utilisant leurs identifiants BroadWorks.

  • Partner Hub est une interface Web pour administrer votre organisation Webex et les organisations de vos clients. Partner Hub est l’endroit où vous configurez l’intégration entre votre infrastructure BroadWorks et Webex. Vous utilisez également Partner Hub pour gérer la configuration et la facturation du client.

Prestataire de service réseau

Le bloc vert à gauche du diagramme représente votre réseau. Les composants hébergés dans votre réseau fournissent les services et interfaces suivants à d’autres parties de la solution :

  • XSP|ADP orienté vers le public, pour Webex pour Cisco BroadWorks : (La boîte représente une ou plusieurs fermes XSP|ADP, éventuellement frontalisées par des répartiteurs de charge.)

    • Héberge l’interface des services Xtended (XSI-Actions &XSI-Events), le périphérique Service de gestion (DMS), l’interface CTI et le service d’authentification. Ensemble, ces applications permettent aux téléphones et aux clients Webex de s’authentifier eux-mêmes, de télécharger leurs fichiers de configuration d’appel, de effectuer et de recevoir des appels et de voir l’état d’hook (présence téléphonique) des uns et des autres historique des appels.

    • Le répertoire est publié aux clients Webex.

  • XSP|ADP orienté vers le public, NPS en cours d’exécution :

    • organisateur Notifications d’appel Push Server : Un serveur push de notification sur un XSP|ADP dans votre environnement. Il est interface entre votre serveur d’applications et notre proxy NPS. Le proxy fournit des jetons de courte durée à votre NPS pour autoriser les notifications pour les services du Cloud. Ces services (APNS &FCM) envoient des notifications d’appel aux clients Webex sur les appareils Apple iOS et Google Android.

  • Serveur d’applications :

    • Fournit le contrôle des appels et des interfaces à d’autres systèmes BroadWorks (généralement)

    • Pour le provisioning de flux, l’AS est utilisé par l’administrateur partenaire pour provisioner les utilisateurs dans Webex

    • Transforme Profil d’utilisateur en BroadWorks

  • OSS/BSS : Votre système d’assistance opérationnelle/services SIP professionnels pour administrer vos entreprises BroadWorks.

Cloud Webex

Le bloc bleu dans le diagramme représente le Cloud Webex. Les microservices Webex supportent le spectre complet des capacités de collaboration Webex :

  • Cisco Identité commune (CI) est le service d’identité Webex.

  • Webex pour Cisco BroadWorks représente l’ensemble des microservices qui supportent l’intégration entre Webex et Prestataire de service Hosted BroadWorks :

    • API de provisioning de l’utilisateur

    • configuration Prestataire de service la configuration

    • Connexion de l’utilisateur à l’aide des identifiants BroadWorks

  • Boite de messagerie Webex pour les microservices liés à la messagerie.

  • Webex Meetings de réunion représentant des serveurs de traitement média et des SCS pour les réunions vidéo de plusieurs participants (SIP &SRTP)

Services Web d’une tierce partie

Les composants tiers suivants sont représentés dans le diagramme :

  • APNS (Service de notification Apple Push) envoie les notifications d’appel et de messages vers les applications Webex sur les périphériques Apple.

  • FCM (FireBase Cloud Messaging) envoie les notifications d’appel et de messages vers les applications Webex sur les périphériques Android.

Considérations relatives à l’architecture XSP|ADP

Le rôle des serveurs XSP|ADP orientés public dans Webex pour Cisco BroadWorks

Le XSP|ADP tourné vers le public dans votre environnement fournit les interfaces/services suivants à Webex et aux clients :

  • Service d’authentification (AuthService), sécurisé par TLS, qui répond aux demandes Webex pour BroadWorks JWT (Jeton Web JSON) pour le compte d’un utilisateur

  • Interface CTI, sécurisée par mTLS, à laquelle Webex s’abonne pour les événements historique des appels et le statut de présence téléphonique à partir de BroadWorks (statut de l’hook).

  • Actions Xsi et interfaces d’événements (Interface des services eXtended) pour le contrôle des appels de l’abonné, les répertoires des contacts et de la liste des appels, ainsi que la configuration des services téléphoniques de l’utilisateur final

  • Service de MD (Gestion des périphériques) pour que les clients récupèrent leurs fichiers de configuration d’appel

Fournissez les URL pour ces interfaces lorsque vous configurez Webex pour Cisco BroadWorks. (Voir Configurer vos clusters BroadWorks dans Partner Hub dans ce document.) Pour chaque cluster, vous ne pouvez fournir qu’une URL pour chaque interface. Si vous avez plusieurs interfaces dans votre infrastructure BroadWorks, vous pouvez créer plusieurs clusters.

Architecture XSP|ADP

Architecture XSP|ADP : Option 1
Architecture XSP|ADP : Option 2

Nous vous demandons d'utiliser une instance XSP|ADP ou une grappe dédiée séparée pour héberger votre application NPS (Notification Push Server). Vous pouvez utiliser le même NPS avec UC-One SaaS ou UC-One Collaborate. Cependant, vous ne pouvez pas héberger les autres applications requises pour Webex pour Cisco BroadWorks sur le même XSP|ADP que celui qui héberge l’application NPS.

Nous vous recommandons d’utiliser une instance/ferme XSP|ADP dédiée pour héberger les applications requises pour l’intégration Webex pour les raisons suivantes

  • Par exemple, si vous proposez UC-One SaaS, nous vous recommandons de créer une nouvelle ferme XSP|ADP pour Webex pour Cisco BroadWorks. De cette façon les deux services peuvent fonctionner indépendamment pendant que vous migrez les abonnés.

  • Si vous collocalisez les applications Webex pour Cisco BroadWorks sur une ferme XSP|ADP utilisée à d’autres fins, il est de votre responsabilité de surveiller l’utilisation, de gérer la complexité qui en résulte et de planifier l’augmentation de l’échelle.

  • Le planificateur de capacité du système Cisco BroadWorks suppose une ferme XSP|ADP dédiée et peut ne pas être exacte si vous l'utilisez pour les calculs de colocalisation.

Sauf indication contraire, le Webex dédié pour Cisco BroadWorks XSP|ADP doit héberger les applications suivantes :

  • AuthService (TLS avec validation du jeton CI ou mTLS)

  • CTI (mTLS)

  • XSI-Actions (TLS)

  • XSI-Events (TLS)

  • DMS (TLS) : facultatif. Il n’est pas obligatoire que vous déployiez une instance DMS ou une ferme distincte spécifiquement pour Webex pour Cisco BroadWorks. Vous pouvez utiliser la même instance DMS que celle que vous utilisez pour UC-One SaaS ou UC-One Collaborate.

  • Vue Web des paramètres d'appel (TLS)—Facultatif. Paramètres d’appel Webview (CSW) n’est requise que si vous souhaitez que les utilisateurs de Webex pour Cisco BroadWorks puissent configurer les fonctions d’appel sur l’application Webex.

Webex nécessite l’accès à CTI via une interface sécurisée par une authentification TLS mutuelle authentification unique. Pour prendre en charge cette exigence, nous recommandons l’une de ces options :

  • (Diagramme étiqueté Option 1) Une instance XSP|ADP ou une grappe pour toutes les applications, avec deux interfaces configurées sur chaque serveur : une interface mTLS pour CTI et une interface TLS pour d’autres applications telles que le service Auth.

  • (Diagramme étiqueté Option 2) Deux instances ou fermes XSP|ADP, l'une avec une interface mTLS pour CTI, et l'autre avec une interface TLS pour d'autres applications, telles que AuthService.

Réutilisation XSP|ADP

Si vous avez une ferme XSP|ADP existante qui est conforme à l’une des architectures suggérées ci-dessus (Option 1 ou 2) et qu’elle est légèrement chargée, alors il est possible de réutiliser vos ADP XSP|existantes. Vous devrez vérifier qu’il n’y a pas d’exigences de configuration conflictuelles entre les applications existantes et les nouvelles exigences de l’application pour Webex. Les deux considérations principales sont :

  • Si vous devez prendre en charge plusieurs organisations partenaires Webex sur XSP|ADP, cela signifie que vous devez utiliser mTLS sur le service d’authentification (La validation du jeton CI n’est prise en charge que pour une seule organisation partenaire sur un XSP|ADP). Si vous utilisez MTLS sur le service d’authentification, cela signifie que vous ne pouvez pas avoir des clients qui utilisent l’authentification de base sur le service d’authentification en même temps. Cette situation empêcherait la réutilisation de XSP|ADP.

  • Si le service CTI existant est configuré pour être utilisé par les clients avec le port sécurisé (généralement 8012) mais sans mTLS (c’est-à-dire l’authentification du client), alors cela entre en conflit avec l’exigence Webex d’avoir mTLS.

Étant donné que les ADP XSP|ont de nombreuses applications et que le nombre de permutations de ces applications est important, il peut y avoir d'autres conflits non identifiés. Pour cette raison, toute réutilisation potentielle des ADP XSP|doit être vérifiée dans un laboratoire avec la configuration prévue avant d'engager la réutilisation.

Configurer la synchronisation NTP sur XSP|ADP

Le déploiement nécessite une synchronisation temporelle pour tous les ADP XSP|que vous utilisez avec Webex.

Installez le pack ntp après l’installation du se et avant d’installer le logiciel BroadWorks. Vous pouvez ensuite configurer NTP pendant l'installation du logiciel XSP|ADP. Voir le Guide de gestion de BroadWorks Software pour plus de détails.

Lors de l’installation interactive du logiciel XSP|ADP, vous avez la possibilité de configurer NTP. Procédez comme suit :

  1. Lorsque le programme d’installation demande, Voulez-vous configurer NTP ?, saisissez y.

  2. Lorsque le programme d’installation demande, Est-ce que ce serveur va être un serveur NTP ?, saisissez n.

  3. Lorsque le programme d’installation demande, Qu’est-ce que l’adresse NTP, le nom d’hôte, ou FDQN ? , saisissez l’adresse de votre serveur NTP, ou d’un service NTP public, par exemple, pool.ntp.org .

Si vos ADP XSP|utilisent une installation silencieuse (non interactive), le fichier de configuration du programme d’installation doit inclure les paires Key=Value suivantes :

NTP
NTP_SERVER=

Exigences en matière d’identité et de sécurité XSP|ADP

Arrière-plan

Les protocoles et ciphers des connexions Cisco BroadWorks TLS sont configurables à différents niveaux de spécifiques. Ces niveaux vont de la plus générale (fournisseur SSL) à la plus spécifique (interface individuelle). Un paramètre plus spécifique remplace toujours un paramètre plus général. Si elles ne sont pas spécifiées, les paramètres SSL de niveau plus bas sont hérités des niveaux « plus élevés ».

Si aucun paramètre n’est changé à partir de leurs paramètres par défaut, tous les niveaux héritent des paramètres par défaut du fournisseur SSL (Extension Java Secure Sockets).

Liste des exigences

  • L'ADP XSP| doit s'authentifier auprès des clients à l'aide d'un certificat signé par une autorité de certification dans lequel le nom commun ou le nom alternatif du sujet correspond à la partie du domaine de l'interface XSI.

  • L’interface Xsi doit prendre en charge le protocole TLSv1.2.

  • L’interface Xsi doit utiliser une suite de chiffrement qui répond aux exigences suivantes.

    • Diffie-Hellman Éphémère (DHE) ou Elliptic Curves Diffie-Hellman Ephemeral (ECDHE) échange de touches

    • Chiffrement AES (Advanced Encryption Standard) avec une taille de bloc minimum de 128 bits (par exemple AES-128 ou AES-256)

    • Mode GCM (Mode Galois/Counter) ou CCP (Chaine de blocage de cipher)

      • Si un cipher (cipher) SHA2 est utilisé, seule la famille SHA2 des fonctions de hachage est autorisée pour le système derivation de clés (SHA256, SHA384, SHA512).

Par exemple, les ciphers suivants répondent aux exigences requises :

  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

  • TLS_DHE_PSK_WITH_AES_256_CBC_SHA384

L'interface de ligne de commande XSP|ADP CLI nécessite la convention d'appellation IANA pour les suites de chiffrement, comme indiqué ci-dessus, et non la convention openSSL.

Ciphers TLS pris en charge pour les interfaces AuthService et XSI

Cette liste est sujette à des changements au mesure où nos exigences de sécurité sur le cloud vont évoluer. Suivez les recommandations de sécurité actuelles de Cisco sur le Cloud sur la sélection de chiffrement, comme décrit dans la liste des exigences requises dans ce document.

  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

  • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

  • TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256

  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA256

  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA

  • TLS_RSA_PSK_WITH_AES_256_GCM_SHA384

  • TLS_DHE_PSK_WITH_AES_256_GCM_SHA384

  • TLS_RSA_PSK_WITH_CHACHA20_POLY1305_SHA256

  • TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256

  • TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256

  • TLS_RSA_WITH_AES_256_GCM_SHA384

  • TLS_PSK_WITH_AES_256_GCM_SHA384

  • TLS_PSK_WITH_CHACHA20_POLY1305_SHA256

  • TLS_RSA_PSK_WITH_AES_128_GCM_SHA256

  • TLS_DHE_PSK_WITH_AES_128_GCM_SHA256

  • TLS_RSA_WITH_AES_128_GCM_SHA256

  • TLS_PSK_WITH_AES_128_GCM_SHA256

  • TLS_RSA_WITH_AES_256_CBC_SHA256

  • TLS_RSA_WITH_AES_128_CBC_SHA256

  • TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384

  • TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA

  • TLS_RSA_PSK_WITH_AES_256_CBC_SHA384

  • TLS_DHE_PSK_WITH_AES_256_CBC_SHA384

  • TLS_RSA_PSK_WITH_AES_256_CBC_SHA

  • TLS_DHE_PSK_WITH_AES_256_CBC_SHA

  • TLS_RSA_WITH_AES_256_CBC_SHA

  • TLS_PSK_WITH_AES_256_CBC_SHA384

  • TLS_PSK_WITH_AES_256_CBC_SHA

  • TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256

  • TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA

  • TLS_RSA_PSK_WITH_AES_128_CBC_SHA256

  • TLS_DHE_PSK_WITH_AES_128_CBC_SHA256

  • TLS_RSA_PSK_WITH_AES_128_CBC_SHA

  • TLS_DHE_PSK_WITH_AES_128_CBC_SHA

  • TLS_RSA_WITH_AES_128_CBC_SHA

  • TLS_PSK_WITH_AES_128_CBC_SHA256

  • TLS_PSK_WITH_AES_128_CBC_SHA

Paramètres d’échelle Xsi Events

Vous devez augmenter la taille de la file d’attente Xsi-Events et le nombre de fils de discussion pour gérer le volume d’événements dont la solution Webex pour Cisco BroadWorks a besoin. Vous pouvez augmenter les paramètres aux valeurs minimum affichées, comme suit (ne pas les diminuer s’ils sont au dessus de ces valeurs minimum) :

XSP|ADP_CLI/Applications/Xsi-Events/BWIntegration> eventQueueSize = 2000

XSP|ADP_CLI/Applications/Xsi-Events/BWIntegration> eventHandlerThreadCount = 50

Plusieurs ADP XSP|

Élément Edge de la équilibrage de charge

Si vous avez un élément de répartition de charge sur votre périphérie de réseau, il doit gérer de manière transparente la répartition du trafic entre vos plusieurs serveurs XSP|ADP et le Cloud et les clients Webex pour Cisco BroadWorks. Dans ce cas, vous fourniriez l’URL du soldeur de charge à la configuration de Webex pour Cisco BroadWorks.

Notes sur cette architecture :

  • Configurez le DNS pour que les clients peuvent trouver le équilibre de charge lors de la connexion à l’interface Xsi (voir configuration DNS).

  • Nous vous recommandons de configurer l’élément Edge en mode proxy SSL inverse, pour assurer un point d’accès au chiffrement des données.

  • Les certificats de XSP|ADP01 et XSP|ADP02 doivent tous deux avoir le domaine XSP|ADP, par exemple votre-XSP|ADP.example.com, dans l'autre nom du sujet. Ils doivent avoir leurs propres FDQN, par exemple XSP|ADP01.example.com, dans le nom commun. Vous pouvez utiliser des certificats génériques , mais nous ne les recommandons pas.

Serveurs XSP orientés vers Internet|ADP

Si vous exposez les interfaces Xsi directement, utilisez DNS pour distribuer le trafic vers les plusieurs serveurs XSP|ADP.

Notes sur cette architecture :

  • Deux enregistrements sont nécessaires pour se connecter aux serveurs XSP|ADP :

    • Pour les microservices Webex : Les enregistrements A/AAAA sont nécessaires pour cibler les adresses IP XSP|ADP multiples. La raison est que les microservices Webex ne peuvent pas effectuer de recherches SRV. Pour des exemples, voir Services Webex sur le Cloud.

    • Pour l’application Webex : Un enregistrement SRV qui se résout en enregistrements A où chaque enregistrement A se résout en un seul XSP|ADP. Pour des exemples, voir Application Webex.

      Utilisez les enregistrements SRV prioritaires pour cibler le service XSI pour les multiples adresses XSP|ADP. Donnez la priorité à vos enregistrements SRV afin que les microservices aillent toujours vers le même enregistrement A (et l'adresse IP suivante) et ne passent vers l'enregistrement A suivant (et l'adresse IP) que si la première adresse IP est en panne. N’utilisez PAS une approche circulaire pour l’application Webex.

  • Les certificats de XSP|ADP01 et XSP|ADP02 doivent tous deux avoir le domaine XSP|ADP, par exemple votre-XSP|ADP.example.com, dans l'autre nom du sujet. Ils doivent avoir leurs propres FDQN, par exemple XSP|ADP01.example.com, dans le nom commun.

  • Vous pouvez utiliser des certificats génériques , mais nous ne les recommandons pas.

Éviter les redirections HTTP

Parfois, DNS est configuré pour résoudre l'URL XSP|ADP vers un répartiteur de charge HTTP, et le répartiteur de charge est configuré pour rediriger vers les serveurs XSP|ADP via un proxy inverse.

Webex ne suit pas une redirection lors de la connexion aux URL que vous fournissez, donc cette configuration ne fonctionne pas.

Architecture &infrastructure

  • Quel type d’échelle prévoyez-vous de commencer ? Il est possible d’aller plus vite, mais l’estimation actuelle de votre utilisation devrait stimuler la planification de l’infrastructure.

  • Collaborez avec votre gestionnaire de compte/représentant commercial Cisco pour dimensionner votre infrastructure XSP|ADP, conformément au Planificateur de capacité du système Cisco BroadWorks et au Guide d'ingénierie du système Cisco BroadWorks.

  • Comment Webex établira-t-il des connexions TLS mutuelles avec vos ADP XSP| ? Directement vers l'ADP XSP|dans une DMZ, ou via un proxy TLS ? Cela affecte votre gestion des certificats et les URL que vous utilisez pour les interfaces. (Nous ne prenons pas en charge les connexions TCP non chiffrées vers la périphérie de votre réseau).