Préparer votre environnement

Points de décision

Considération Questions à répondre Ressources

Architecture &infrastructure

Combien de XSP ?

Comment font-ils pour prendre mTLS ?

Planificateur de la capacité du système Cisco BroadWorks

Guide d’ingénierie du système Cisco BroadWorks

Référence CLI XSP

Ce document

Provisioning des clients et des utilisateurs

Pouvez-vous affirmez que vous faites confiance aux emails dans BroadWorks ?

Voulez-vous que les utilisateurs fournissent des adresses électroniques pour activer leurs propres comptes ?

Pouvez-vous créer des outils pour utiliser notre API ?

Docs API publics à https://developer.webex.com

Ce document

Charte graphique Quelle est la couleur et le logo que vous souhaitez utiliser ? Article sur la stratégie de marque de l’application Webex
Modèles Quels sont vos différents cas d’utilisation client ? Ce document
Fonctionnalités de l’abonné par client/entreprise/groupe Choisissez un pack pour définir le niveau de service par modèle. Basique, Standard, Premium ou Softphone.

Ce document

Matrice des fonctionnalités/packs

Authentification de l’utilisateur BroadWorks ou Webex Ce document
Adaptateur de provisioning (pour les options de provisioning sans fil)

Utilisez-vous déjà la MI intégrée&P, par exemple pour UC-One SaaS ?

Avez-vous l’intention d’utiliser plusieurs modèles ?

Un cas d’utilisation plus courant est-il prévu ?

Ce document

Référence CLI du serveur d’applications

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.

  • Travaillez avec le gestionnaire de compte/représentant des ventes Cisco de taille de votre infrastructure XSP, selon le Cisco BroadWorks System Capacity Planner ( ) et le Ciscohttps://xchange.broadsoft.com/node/1051462BroadWorks System Engineering Guide (https://xchange.broadsoft.com/node/1051496).

  • Comment puis-Cisco Webex des connexions TLS mutuelles vers vos XSP ? Directement vers le XSP dans une DMZ, ou via un proxy TLS ? Ceci affecte votre gestion des certificats, ainsi que les URL que vous utilisez pour les interfaces. (Nous ne supportons pas les connexions TCP non cryptées au bord de votre réseau).

Provisioning des clients et des utilisateurs

Quelle est la méthode d’approvisionnement en utilisateurs qui vous convient le mieux ?

  • Approvisionnement de flux avec des courriers électroniques de confiance: En attribuant le service de « MI&P intégré » sur BroadWorks, l’abonné est automatiquement provisionné dans Cisco Webex.

    Si vous pouvez également affirme que les adresses électroniques de l’abonné dans BroadWorks sont valides et uniques à Webex, alors vous pouvez utiliser la variante du « courrier électronique de confiance » du provisioning de service. Les comptes Webex des abonnés sont créés et activés sans intervention ; ils téléchargent simplement le client et se connectent.

    L’adresse électronique est un attribut utilisateur clé sur Cisco Webex. L’Prestataire de service donc fournir une adresse électronique valide pour l’utilisateur afin de Cisco Webex services. Ceci doit être dans l’attribut ID de messagerie électronique de l’utilisateur dans BroadWorks. Nous vous recommandons de le copier également dans l’attribut Autre ID.

  • Approvisionnement de l’accès au flux sans courriers électroniques de confiance: Si vous ne pouvez pas faire confiance aux adresses électroniques de l’abonné, vous pouvez toujours attribuer le service de MI&P intégré dans BroadWorks pour provisioniser les utilisateurs dans Webex.

    Avec cette option, les comptes sont créés lorsque vous attribuez le service, mais les abonnés doivent fournir et valider leurs adresses électroniques pour activer les comptes Webex.

  • Auto-provisioning de l’utilisateur: Cette option ne nécessite pas d’affectation de service de MI&P dans BroadWorks. Vous (ou vos clients) distribuez à la place un lien de provisioning, et les liens pour télécharger les différents clients, avec votre stratégie de marque et vos instructions.

    Les abonnés suivent le lien, puis fournissent et valident leurs adresses électroniques pour créer et activer leurs comptes Webex. Puis ils téléchargent le client et se connectent, et Webex récupère une configuration supplémentaire les concernant de BroadWorks (y compris leurs numéros principaux).

  • Provisioning contrôlé par SP via des API: Cisco Webex exposez un ensemble d’API publiques qui permettent aux fournisseurs de services d’inscrire les utilisateurs/abonnés dans leurs workflows existants.

Charte graphique

Vous pouvez appliquer un logo et une couleur unique (pour le barre de navigation) à l’application Webex. Le portail d’activation des utilisateurs utilise les mêmes paramètres.

Pour des détails sur la façon de personnaliser la stratégie de marque, reportez-vous à https://help.webex.com/en-us/n0cswhcb/Customize-Branding-for-Customers.

Modèles des clients

Les modèles des clients vous permettent de définir les paramètres par lesquels les clients et les abonnés associés sont automatiquement provisionnés sur Cisco Webex BroadWorks. Vous pouvez configurer plusieurs modèles clients comme requis, mais lorsque vous onboard un client il est associé à un seul modèle (vous ne pouvez pas appliquer plusieurs modèles à un seul client).

Certains des paramètres principaux du modèle sont répertoriés ci-dessous.

Pack

  • Vous devez sélectionner un pack par défaut lorsque vous créez un modèle (Voir Packs dans la section Aperçu pour plus d’informations). Tous les utilisateurs qui ont reçu ce modèle, que ce soit par l’auto-provisioning ou le flux, reçoivent le pack par défaut.

  • Vous avez le contrôle du choix du pack pour différents clients en créant plusieurs modèles et en sélectionnant différents packs par défaut dans chacun d’eux. Vous pouvez ensuite distribuer différents liens de provisioning, ou différents adaptateurs de provisioning par entreprise, selon la méthode d’approvisionnement de l’utilisateur que vous avez choisie pour ces modèles.

  • Vous pouvez modifier le pack des abonnés spécifiques à partir de cette valeur par défaut, en utilisant l’API de provisioning (voir Intégrer avec Webex pour l’API de provisioning BroadWorks dans la section Référence) ou via le Hub partenaire.

  • Vous ne pouvez pas modifier le pack d’un abonné à partir de BroadWorks. L’affectation du service de MI&P intégré est soit on soit off ( on) ; si l’abonné se voit attribuer ce service dans BroadWorks, le modèle de Partner Hub associé à l’URL de provisioning de l’entreprise de cet abonné définit le pack.

Revendeur et entreprises ou Prestataire de service et groupes ?

  • La façon dont votre système BroadWorks est configuré a un impact sur le flux par le provisioning. Si vous êtes un revendeur des Entreprises, alors vous devez activer le mode Entreprise lorsque vous créez un modèle.
  • Si votre système BroadWorks est configuré en mode Prestataire de service, vous pouvez quitter la commuter le mode Entreprise de vos modèles.
  • Si vous prévoyez d’provisioner les organisations des clients en utilisant les deux modes BroadWorks, vous devez utiliser différents modèles pour les groupes et les entreprises.

Mode d’authentification

Comment les abonnés des clients vont-ils s’authentifier ?

Mode d’authentification BroadWorks Webex
Identité d’utilisateur principale BroadWorks ID utilisateur Adresse électronique
Fournisseur d'identité

BroadWorks.

L’authentification est facilitée par un service hébergé par un prestataire de service Cisco Webex.

L’Identité commune Cisco
Authentification multifacteur ? Non Nécessite l’IdP du client qui prend en charge l’authentification multifacteur.

Chemin de validation des informations d’identification

  1. Un navigateur est lancé, où l’utilisateur envoie un courrier électronique au flux de connexion initial et découvrez son mode d’authentification.

  2. Le navigateur est ensuite redirigé vers une page Cisco Webex de connexion hébergée par BroadWorks (Cette page peut avoir une marque)

  3. L’utilisateur fournit l’id utilisateur et le mot de passe BroadWorks sur la page de connexion.

  4. Les identifiants utilisateur sont validés par BroadWorks.

  5. Avec le succès, un code d’autorisation est obtenu à partir Cisco Webex. Ceci est utilisé pour obtenir les jetons d’accès nécessaires pour Cisco Webex services.

  1. Un navigateur est lancé, où l’utilisateur envoie un courrier électronique au flux de connexion initial et découvrez son mode d’authentification.

  2. Le navigateur est redirigé vers l’IdP (Cisco Identité commune ou Customer IdP) où un portail de connexion leur sera présenté.

  3. L’utilisateur fournit les identifiants appropriés sur la page de connexion

  4. L’authentification multifacteur peut avoir lieu si l’IdP du client la prend en charge.

  5. Avec le succès, un code d’autorisation est obtenu à partir Cisco Webex. Ceci est utilisé pour obtenir les jetons d’accès nécessaires pour Cisco Webex services.

Accords avec plusieurs partenaires

Allez-vous sous-licencer Webex pour BroadWorks à un autre fournisseur de service ? Dans ce cas, chaque fournisseur de services aura besoin d’une organisation partenaire distincte dans l’Webex Control Hub de lui permettre de fournir la solution pour sa base de clients.

Adaptateur et modèles de provisioning

Lorsque vous utilisez le provisioning de flux, l’URL de provisioning que vous saisissez dans BroadWorks provient du modèle dans Control Hub. Vous pouvez avoir plusieurs modèles et donc plusieurs URL de provisioning. Ceci vous permet de sélectionner, d’entreprise par entreprise, le pack à appliquer aux abonnés lorsqu’ils ont le service de MI&P intégré.

Vous devez considérer si vous souhaitez configurer une URL de provisioning au niveau du système en tant que chemin d’approvisionnement par défaut et le modèle que vous souhaitez utiliser pour cela. De cette façon, il vous suffit de définir explicitement l’URL de provisioning pour les entreprises qui ont besoin d’un modèle différent.

Gardez également à l’esprit que vous utilisez peut-être déjà une URL de provisioning de niveau système, par exemple avec UC-One SaaS. Si c’est le cas, vous pouvez choisir de conserver l’URL au niveau du système pour le provisioning des utilisateurs sur UC-One SaaS et remplacer les entreprises qui vont chez Webex pour BroadWorks. Sinon, vous voudrez peut-être aller dans l’autre sens et configurer l’URL au niveau du système pour Webex pour BroadWorks et reconfigurer les entreprises que vous souhaitez garder sur UC-One SaaS.

Les choix de configuration liés à cette décision sont détaillés dans Configurer le serveur d’applications avec l’URL du service de déploiement dans la section Déployer Webex pour BroadWorks.

Configuration minimale requise

Comptes

Tous les abonnés que vous provisionnez pour Webex doivent exister dans le système BroadWorks que vous intégrez à Webex. Vous pouvez intégrer plusieurs systèmes BroadWorks si nécessaire.

Tous les abonnés doivent avoir des licences BroadWorks et des numéros principaux.

Webex utilise les adresses électroniques comme identificateurs principaux pour tous les utilisateurs. Si vous utilisez la mise en service de flux avec des adresses électroniques de confiance, alors vos utilisateurs doivent avoir des adresses valides dans l’attribut de messagerie électronique dans BroadWorks.

Si votre modèle utilise l’authentification BroadWorks, vous pouvez copier les adresses électroniques de l’abonné dans l’attribut Autre ID dans BroadWorks. Ceci permet aux utilisateurs de se connectent à Webex en utilisant leur adresse électronique et leurs mots de passe BroadWorks.

Vos administrateurs doivent utiliser leurs comptes Webex pour se connectent à Partner Hub.

Serveurs dans votre réseau et exigences logicielles

  • Instance(s) BroadWorks avec version minimum R21 SP1. Voir Exigences requises pour le logiciel BroadWorks (dans ce document) pour les versions et les patches pris en charge. Voir également Gestion du cycle de vie - Serveurs BroadSoft.


    R21 SP1 est pris en charge uniquement jusqu’à la mi-2021. Même si vous pouvez actuellement intégrer Webex avec R21 SP1, nous vous recommandons fortement R22 ou une ultérieure pour l’intégration avec Webex.

  • La/les instance(s) BroadWorks doivent inclure au moins les serveurs suivants :

    • Serveur d’applications (AS) avec la version de BroadWorks comme ci-dessus

    • Serveur réseau (NS)

    • Serveur de profil (PS)

  • Les serveurs XSP ou la Plateforme de distribution d’applications (ADP) doivent répondre aux exigences suivantes :

    • Service d’authentification (BWAuth)

    • Interfaces d’actions et d’événements XSI

    • DMS (application Web de gestion de périphérique)

    • Interface CTI (Intergration téléphonique de l’ordinateur)

    • TLS 1.2 avec un certificat valide (non auto-signé) et tous les intermédiaires requis. Nécessite une administration au niveau du système pour faciliter la recherche d’entreprise.

    • Authentification TLS mutuelle (mTLS) pour le service d’authentification (Nécessite l’authentification publique Cisco Webex chaine de certificats client installée en tant qu’ancres d’autorisation)

    • Authentification TLS mutuelle (mTLS) pour l’interface CTI (Nécessite l’Cisco Webex chaine de certificats client installée en tant qu’ancres d’autorisation)

  • Un serveur XSP/ADP séparé agissant en tant que « Call Notifications Push Server » (un serveur Push de notifications d’appel) (un NPS dans votre environnement utilisé pour pousser les notifications d’appel sur Apple/Google. Nous l’appelons « CNPS » ici pour le distinguer du service dans Webex qui fournit des notifications Push pour la messagerie et la présence).

    Ce serveur doit être sur la R22 ou plus tard.

  • Nous mandater un serveur XSP/ADP séparé pour CNPS car l’inprédictibilité de la charge de Webex pour les connexions BWKS sur le Cloud peut avoir de mauvaises répercussions sur la performance du serveur NPS, en raison de l’augmentation de la latence des notifications. Voir le Guide d’ingénierie du système Cisco BroadWorks (https://xchange.broadsoft.com/node/422649) pour en savoir plus sur l’échelle XSP.

Téléphones physiques et accessoires

Profils des périphériques

Ce sont les fichiers DTAF que vous devez charger sur vos serveurs d’applications pour prendre en charge les applications Webex en tant que clients appelants. Ce sont les mêmes fichiers DTAF que ceux utilisés pour UC-One SaaS, cependant il y a un nouveau config-wxt.xml.template qui est utilisé pour les applications Webex.

Nom du client

Type de profil du périphérique et nom du pack

Modèle mobile Webex

https://xchange.broadsoft.com/support/uc-one/connect/software

Identité/Type de profil du périphérique : Connecter - Mobile

DTAF : ucone-mobile-ucaas-X.X.XX-wxt-MonthYear_DTAF.zip

Fichier de config : config-wxt.xml

Modèle de tablette Webex

https://xchange.broadsoft.com/support/uc-one/connect/software

Identité/Type de profil du périphérique : Connect - Tablette

DTAF : ucone-tablet-ucaas-X.X.XX-wxt-MonthYear_DTAF.zip

Fichier de config : config-wxt.xml

Modèle de bureau Webex

https://xchange.broadsoft.com/support/uc-one/communicator/software

Identité/Type de profil du périphérique : Communication professionnelle - PC

DTAF : ucone-desktop-ucaas-X.X.XX-wxt-MonthYear_DTAF.zip

Fichier de config : config-wxt.xml

Commander des certificats

Exigences de certificat pour l’authentification TLS

Vous aurez besoin de certificats de sécurité, signés par une autorité de certification bien connue et déployés sur vos XSPs publics, pour toutes les applications requises. Ceux-ci seront utilisés pour prendre en charge la vérification du certificat TLS pour toutes les connectivités entrantes vers vos serveurs XSP.

Ces certificats doivent inclure votre nom public XSP comme nom de domaine entièrement qualifié nom commun du sujet ou autre nom du sujet.

Les exigences exactes pour le déploiement de ces certificats de serveur dépendent de la manière dont vos XSP publics sont déployés :

  • Via un proxy de transition TLS

  • Via un proxy de passage TLS

  • Directement vers le XSP

Le diagramme suivant résume où le certificat du serveur public signé par une AC doit être chargé dans les trois cas suivants :

Les autorités de certification publiquement supportées que l’application Webex prend en charge pour l’authentification sont listées dans Autorités de certification supportées pour Cisco Webex services hybrides.

Exigences du certificat TLS pour le proxy TLS-bridge

  • Le certificat du serveur signé publiquement est chargé dans le proxy.

  • Le proxy présente ce certificat de serveur signé publiquement à Webex.

  • Webex fait confiance à l’AC publique qui a signé le certificat du serveur du proxy.

  • Un certificat ca signé interne peut être chargé sur le XSP.

  • Le XSP présente ce certificat de serveur signé en interne au proxy.

  • Le proxy fait confiance à l’AC interne qui a signé le certificat du serveur XSP.

Exigences du certificat TLS pour le Proxy inter-accès TLS ou XSP dans DMZ

  • Le certificat du serveur signé publiquement est chargé dans les XSP.

  • Les XSP présentent des certificats de serveur signés publiquement à Webex.

  • Webex fait confiance à l’AC publique qui a signé les certificats du serveur XSP.

Exigences de certificats supplémentaires pour l’authentification TLS mutuelle sur l’interface CTI

Lors de la connexion à l’interface CTI, Cisco Webex présente un certificat client dans le cadre de l’authentification TLS mutuelle. Le certificat du client Webex L’AC/le certificat de la chaine peut être téléchargé via Control Hub.

Pour télécharger le certificat :

Connectez-vous à Partner Hub, puis sur Paramètres > BroadWorks Calling et cliquez sur le lien télécharger le certificat.

Les exigences exactes pour le déploiement de cette chaine de certificats d’ac Webex dépend de la manière dont vos XSP publics sont déployés :

  • Via un proxy de transition TLS

  • Via un proxy de passage TLS

  • Directement vers le XSP

Le diagramme suivant résume les exigences de certificat dans les trois cas suivants :

Figure 1. Exchange de certificat mTLS pour CTI via différentes configurations Edge

(Option) Exigences de certificat pour le proxy des ponts TLS

  • Webex présente un certificat client signé publiquement au proxy.

  • Le proxy fait confiance à l’AC interne de Cisco qui a signé le certificat client. Vous pouvez télécharger cette AC/chaine à partir de Control Hub et l’ajouter dans l’trust store du proxy. Le certificat du serveur XSP signé publiquement est également chargé dans le proxy.

  • Le proxy présente le certificat du serveur signé publiquement à Webex.

  • Webex fait confiance à l’AC publique qui a signé le certificat du serveur du proxy.

  • Le proxy présente un certificat client signé en interne aux XPS.

    Ce certificat doit avoir le champ d’extension x509.v3 Utilisation étendue de la clé rempli avec l’OID BroadWorks 1.3.6.1.4.1.6431.1.1.8.2.1.3 et l’objectif unique du client TLS. P. ex.:

    X509v3 extensions:
        X509v3 Extended Key Usage:
            1.3.6.1.4.1.6431.1.1.8.2.1.3, TLS Web Client Authentication

    Le NC du certificat interne doit être bwcticlient.webex.com.


    • Lors de la génération des certificats du client interne pour le proxy, notez que les certificats SAN ne sont pas pris en charge. Les certificats du serveur interne pour le XSP peuvent être SAN.

    • Les autorités de certification publiques ne sont peut-être pas prêtes à signer des certificats avec la propriété BroadWorks OID qui est requise. Dans le cas d’un proxy passerelle, vous pouvez être forcé d’utiliser une AC interne pour signer le certificat du client que le proxy présente au XSP.

  • Les XSP font confiance à l’AC interne.

  • Les XSP présentent un certificat de serveur signé en interne.

  • Le proxy fait confiance à l’AC interne.

  • L’entité Client du serveur d’applications contient le NC du certificat client signé en interne présenté au XSP par le proxy.

(Option) Exigences pour les certificats pour le Proxy d’accès TLS ou XSP dans DMZ

  • Webex présente un certificat client Cisco interne signé par une AC aux XSP.

  • Les XSP font confiance à l’AC interne de Cisco qui a signé le certificat du client. Vous pouvez télécharger cette AC/chaine à partir de Control Hub et l’ajouter dans l’trust store du proxy. Le certificat du serveur XSP signé publiquement est également chargé dans les XSP.

  • Les XSP présentent les certificats de serveur signés publiquement à Webex.

  • Webex fait confiance à l’AC publique qui a signé les certificats du serveur XSP.

  • L’entitéId du client du serveur d’applications contient le NC du certificat client signé par Cisco présenté au XSP par Webex.

Préparez votre réseau

Plan de connexion

Le diagramme suivant illustre les points d’intégration. Le point du diagramme est de montrer que vous devez revoir les IP et les ports pour les connexions dans et hors de votre environnement. Les connexions qui sont utilisées par Webex pour BroadWorks sont décrites dans les tableaux suivants.

Les exigences du pare-feu pour le fonctionnement normal de l’application client sont listées en tant que références, car elles sont déjà documentées sur help.webex.com.

Configuration du pare-feu

La carte de la connexion et les tableaux suivants décrivent les connexions et les protocoles requis entre les clients (sur ou hors du réseau du client), votre réseau et la plate-forme Webex.

Nous documentons uniquement les connexions spécifiques à Webex pour BroadWorks. Nous n’montrons pas les connexions génériques entre l’application Webex et le Cloud Webex, qui sont documentées à l’adresse :

Règles EMEA Ingress

(Dans votre réseau)

Objet Source HTTPS et WSS pour la signalisation et la messagerie. Destination TOUT

Cloud Webex

CTI/auth/XSI

18.196.116.47

35.156.83.118

35.158.206.190

44.232.54.0

52.39.97.25

54.185.54.53

69.26.160.0/19

144.254.96.0/20

173.37.32.0/20

216.151.128.0/19

HTTPS

Cti

Votre XSP

TCP/TLS 8012

443

Application Webex

Xsi/DMS

Tous

HTTPS

Votre XSP

443

Points de terminaison VoIP Webex SIP

Tous

SIP

Votre SBC

Protocole et port SP définis

TCP/UDP


Il est fortement recommandé que le port SIP soit différent de 5060 (par exemple, 5075) en raison des problèmes connus lors de l’utilisation du port SIP standard (5060) avec les appareils mobiles.

Règles EMEA Egress

(Hors de votre réseau)

Objet

Source

HTTPS et WSS pour la signalisation et la messagerie.

Destination

TOUT

Provisioning de l’utilisateur via des API

Votre serveur d’applications

HTTPS

webexapis.com

443

Notifications Proxy Push (service de production)

Votre serveur NPS

HTTPS

https://nps.uc-one.broadsoft.com/

OU 34.64.0.0/10, 35.208.0.0/12, 35.224.0.0/12, 35.240.0.0/13

443

Identité commune Webex

Votre serveur NPS

HTTPS

https://idbroker-eu.webex.com

443

Identité commune Webex

Service d'1ère qualité XSP

HTTPS

https://idbroker-eu.webex.com/idb

https://broadworks-idp-proxy-k.wbx2.com/broadworks-idp-proxy/api/v1/idp/authenticate

443

Services APNS et FCM

Votre serveur NPS

HTTPS

Toutes les adressesIP *

443

Notifications Proxy Push (service de production)

Identité commune Webex

Services APNS et FCM

Votre serveur NPS

HTTPS

https://nps.uc-one.broadsoft.com/ *

https://idbroker-eu.webex.com

Toutes les adressesIP *

443

Provisioning de l’utilisateur via un adaptateur de provisioning BroadWorks

Vos BroadWorks AS

HTTPS

https://broadworks-provisioning-bridge-*.wbx2.com/

(où * pourrait être n’importe quelle lettre. Votre URL de provisioning exacte est disponible dans le modèle que vous créez dans Partner Hub)

443

† ces plages contiennent les hôtes pour le proxy NPS, mais nous ne pouvons pas donner les adresses exactes. Les plages peuvent également contenir des hôtes qui ne sont pas liés à Webex pour BroadWorks. Nous vous recommandons de configurer votre pare-feu pour autoriser le trafic vers la FDQN proxy NPS, pour vous assurer que votre sortie est uniquement vers les hôtes que nous exposeons pour le proxy NPS.

* Le APNS et le FCM n’ont pas d’adresses IP fixes fixes.

Règles d’entrée aux Etats-Unis

(Dans votre réseau)

Objet

Source

HTTPS et WSS pour la signalisation et la messagerie.

Destination

TOUT

Cloud Webex

CTI/auth/XSI

13.58.232.148

18.217.166.80

18.221.216.175

44.232.54.0

52.39.97.25

54.185.54.53

69.26.160.0/19

144.254.96.0/20

173.37.32.0/20

216.151.128.0/19

HTTPS

Cti

Votre XSP

TCP/TLS 8012

TLS 443

Application Webex   

Xsi/DMS

Tous

HTTPS

Votre XSP

443

Points de terminaison VoIP l’application Webex SIP

Tous

SIP

Votre SBC

Protocole et port SP définis

TCP/UDP


Il est fortement recommandé que le port SIP soit différent de 5060 (par exemple, 5075) en raison des problèmes connus lors de l’utilisation du port SIP standard (5060) avec les appareils mobiles.

Règles egress (Etats-Unis)

(Hors de votre réseau)

Objet

Source

HTTPS et WSS pour la signalisation et la messagerie.

Destination

TOUT

Provisioning de l’utilisateur via des API

Votre serveur d’applications

HTTPS

webexapis.com

443

Notifications Proxy Push (service de production)

Votre serveur NPS

HTTPS

https://nps.uc-one.broadsoft.com/

OU 34.64.0.0/10, 35.208.0.0/12, 35.224.0.0/12, 35.240.0.0/13

443

Identité commune Webex

Votre serveur NPS

HTTPS

https://idbroker.webex.com

https://idbroker-b-us.webex.com

443

Identité commune Webex

Service d'1ère qualité XSP

HTTPS

https://idbroker.webex.com/idb

https://idbroker-b-us.webex.com/idb

https://broadworks-idp-proxy-a.wbx2.com/broadworks-idp-proxy/api/v1/idp/authenticate

https://broadworks-idp-proxy-r.wbx2.com/broadworks-idp-proxy/api/v1/idp/authenticate

443

Services APNS et FCM

Votre serveur NPS

HTTPS

Toutes les adressesIP *

443

Provisioning de l’utilisateur via l’adaptateur de provisioning BWKS

Vos BroadWorks AS

HTTPS

https://broadworks-provisioning-bridge-*.wbx2.com/

(où * pourrait être n’importe quelle lettre. Votre URL de provisioning exacte est disponible dans le modèle que vous créez dans Partner Hub)

443

† ces plages contiennent les hôtes pour le proxy NPS, mais nous ne pouvons pas donner les adresses exactes. Les plages peuvent également contenir des hôtes qui ne sont pas liés à Webex pour BroadWorks. Nous vous recommandons de configurer votre pare-feu pour autoriser le trafic vers la FDQN proxy NPS, pour vous assurer que votre sortie est uniquement vers les hôtes que nous exposeons pour le proxy NPS.

* Le APNS et le FCM n’ont pas d’adresses IP fixes fixes.

Exigences réseau pour les services Webex

Le tableau des règles précédentes Ingress et Egress du pare-feu documente uniquement les connexions spécifiques à Webex pour BroadWorks. Pour des informations générales sur les connexions entre l’application Webex et le Cloud Webex, voir Exigences réseau pour les services Webex. Cet article est générique pour Webex, mais le tableau suivant identifie les différentes sections de l’article et la pertinence de chaque section avec Webex pour BroadWorks.

Tableau 1. Exigences réseau pour les connexions de l’application Webex (Génériques)

Section de l’article Exigences réseau

Groupe d’informations

Synthèse des types de périphériques et des protocoles pris en charge par Webex

Informationnel

Protocoles de transport et chiffrement des chiffrements pour les applications et périphériques Webex enregistrés sur le Cloud

Informationnel

Services Webex – Numéros de port et protocoles

Doit être lu

Sous-réseaux IP pour les services média Webex

Doit être lu

Domaines et URL qui doivent être accédés pour les services Webex

Doit être lu

URLs supplémentaires pour les services hybrides Webex

Facultatif

Fonctionnalités du proxy

Facultatif

802.1X – Contrôle d’accès réseau basé sur un port

Facultatif

Exigences réseau pour les services Webex basés sur le réseau SIP

Facultatif

Exigences réseau pour l’audio Webex Edge

Facultatif

Un résumé des autres services hybrides webex et de la documentation

Facultatif

Services Webex pour les clients FedRAMP

N/A

Informations supplémentaires

Pour plus d’informations, voir Livre blanc sur le pare-feu de l’application Webex (PDF).

Prise en charge de la redondance BroadWorks

Les Cisco Webex Cloud et les applications du client Webex qui ont besoin d’accéder au réseau du partenaire supportent totalement la redondance Broadworks XSP fournie par le partenaire. Lorsqu’un XSP ou un site sont indisponibles pour une maintenance programmée ou pour une raison imprévue, les services et applications Cisco peuvent aller sur un autre XSP ou un autre site fourni par le partenaire pour répondre à une demande.

Topologie de réseau

Les XSP Broadworks peuvent être déployés directement sur Internet, ou résider dans une DMZ face à un élément de équilibrage de charge tel que le F5 BIG-IP. Pour fournir une redondance géographique, les XSP peuvent être déployés dans deux centres de données (ou plus), chacun d’eux peut être face à un chargeur de charge, chacun ayant une adresse IP publique. Si les XSP sont derrière un chargeur de charge, les microservices et l’application Webex ne voient que l’adresse IP du solde de charge et Broadworks semble avoir un seul XSP, même s’il y a plusieurs XSP derrière.

Dans l’exemple ci-dessous, les XSP sont déployés sur deux sites, le site A et le site B. Il y a deux XSP face à un chargeur de chaque site. Le site A a XSP1 et XSP2 face à LB1 et le site B a XSP3 et XSP4 face à LB2. Seuls les équilibreurs de charge sont exposé sur le réseau public et les XSP se sont dans les réseaux privés DMZ.

Webex Cloud Services

Configuration DNS

Les microservices du Cloud Webex doivent pouvoir trouver le(s) serveur(s) Broadworks XSP pour se connecter aux interfaces Xsi, au service d’authentification et à CTI.

Cisco Webex microservices Cloud effectueront la recherche DNS A/AAAA du nom d’hôte XSP configuré et se connectera à l’adresse IP renvoyée. Il peut s’agit d’un élément de l’edge de équilibrage de charge, ou il peut s’agit du serveur XSP lui-même. Si plusieurs adresses IP sont renvoyées, la première IP de la liste sera sélectionnée. SRV recherche ne sont actuellement pas pris en charge.

Exemple : Enregistrement DNS A du partenaire pour la découverte de serveurs XSP avec un serveur/balance de charges arrondis à l’autre

Type d’enregistrement

Nom

Cible

Objet

R

xsp.example.com

198.51.100.48

Points sur LB1 (Site A)

R

xsp.example.com

198.51.100.49

Points sur LB2 (Site B)

Basculement

Lorsque les microservices Webex envoient une demande au serveur de balance des charges XSP et que la demande échoue, plusieurs choses peuvent se produire :

  • Si la panne est due à une erreur réseau (ex. : TCP, SSL), les microservices Webex marquent l’IP comme bloquée et effectuent immédiatement une avance de route vers l’IP suivante.

  • Si un code d’erreur (HTTP 5xx) est renvoyé, les microservices Webex marquent l’IP comme bloqué et effectuent une avance immédiate de route vers l’IP suivante.

  • Si aucune réponse HTTP n’est reçue dans les 2 secondes, la demande s’exécute et les microservices Webex marquent l’IP comme bloquée et effectuent une avance de route vers l’IP suivante.

Chaque demande est tentée trois fois avant qu’une défaillance ne soit à nouveau signalée au microservice.

Lorsqu’une IP se trouve dans la liste des adresses bloquées, elle ne sera pas incluse dans la liste des adresses à essayer lors de l’envoi d’une demande à un XSP. Après une période prédéterminée, une IP bloquée expire et revient dans la liste pour essayer lorsqu’une autre demande est fait.

Si toutes les adresses IP sont bloquées, le microservice tentera quand même d’envoyer la demande en sélectionnant aléatoirement une adresse IP dans la liste bloquée. Si la réussite est, cette adresse IP est supprimée de la liste bloquée.

Statut

Le statut de la connectivité des services Webex du Cloud aux XSP ou aux chargeurs de charge peut être vu dans Control Hub. Sous un cluster d’appel BroadWorks, un statut de connexion est affiché pour chacune de ces interfaces :

  • XSI Actions

  • XSI Events

  • Service d’authentification

Le statut de la connexion est mis à jour lorsque la page est chargée ou pendant les mises à jour de saisie. Les statuts des connexions peuvent être :

  • Vert: Lorsque l’interface peut être atteinte sur l’un des IP dans la recherche d’enregistrement A.

  • Rouge: Lorsque toutes les IP de la recherche d’enregistrement sont inaccessibles et que l’interface est indisponible.

Les services suivants utilisent les microservices pour se connecter aux XSP et sont impactés par la disponibilité de l’interface XSP :

  • Connexion à l’application Webex

  • Actualisation du jeton de l’application Webex

  • Adresse électronique/activation automatique non confiance

  • Vérification de l’état du service Broadworks

Application Webex

Configuration DNS

L’application Webex accède aux services Xtended Services Interface (XSI-Actions & XSI-Events) et les services de l’Service de gestion de périphérique (DMS) sur le XSP.

Il effectuera la recherche SRV DNS pour _xsi-client._tcp.<xsi domain> de l’URL configurée pour trouver les hôtes XSP ou les serveurs de charge pour le service XSI.

Vous trouverez ci-dessous un exemple d’enregistrements SRV’enregistrement.

Type d’enregistrement

Enregistrer

Cible

Objet

SRV

_xsi-client._tcp.xsp.example.com

xsp-dc1.example.com

Découverte de l’interface Xsi par le client

SRV

_xsi-client._tcp.xsp.example.com

xsp-dc2.example.com

Découverte de l’interface Xsi par le client

R

xsp-dc1.example.com

198.51.100.48

Pointe vers LB1 (site A)

R

xsp-dc2.example.com

198.51.100.49

Points sur LB2 (site B)


Chaque enregistrement A/AAAA doit être mapé sur une adresse IP. S’il y a plusieurs XSP dans une DMZ derrière le périphérique de solde de charge/edge, il est obligatoire que le soldeur de charge soit configuré pour maintenir la sollicitation de la session pour que toutes les demandes de la même session soient acheminées vers le même XSP.

Nous mandateons cette configuration car les pulsations XSI de l’événement du client doivent aller sur le même XSP que celui utilisé pour établir la chaine de l’événement.

Si vous mappés le nom A/AAAA à plus d’une adresse IP, ou si l’élément de balanceur/edge de la charge ne maintient pas la lourdeur de la session, le client envoie éventuellement des pulsations à un XSP où il n’a pas établi de chaine d’événements. Ceci entraîne la panne du canal, mais aussi un trafic beaucoup plus interne qui affecte la performance de votre cluster XSP.

Pendant le processus de connexion, l’application Webex va également récupérer l’URL DMS pour télécharger le fichier de sa config. L’hôte dans l’URL effectuera une parsage et l’application Webex effectuera la recherche DNS A/AAAA de l’hôte pour se connecter au XSP qui héberge le service DMS.

Exemple : Enregistrement DNS A pour la découverte de serveurs XSP internet/balanceurs de charge arrondis par l’application Webex pour télécharger les fichiers de config via DMS :

Type d’enregistrement

Nom

Cible

Objet

R

xsp-dms.example.com

198.51.100.48

Pointe vers LB1 (site A)

R

xsp-dms.example.com

198.51.100.49

Points sur LB2 (site B)

Comment l’application Webex trouve les adresses XSP

Le client tente de localiser les nodes XSP en utilisant le flux DNS suivant :

  1. Le client récupère initialement les URL Xsi-Actions/Xsi-Events de Cisco Webex cloud (que vous avez saisies lors de la création du cluster d’appel BroadWorks associé). Le nom d’hôte/domaine Xsi est parsé à partir de l’URL et le client effectue SRV recherche comme suit :

    1. Le client effectue une recherche SRV des _xsi-client._tcp.<xsi domain="">

    2. Si la recherche SRV l’équipe renvoie une ou plusieurs cible :

      1. Le client fait une recherche A/AAAA pour ces cible et met en cache les adresses IP renvoyées.

      2. Le client se connecte à l’une des cible (et donc son enregistrement A/AAAA avec une seule adresse IP) en fonction de la priorité du SRV, puis du poids (ou aléatoire si elles sont toutes égales).

    3. Si la recherche SRV de l’équipe ne retourne aucune cible :

      Le client fait une recherche A/AAAA du paramètre racine Xsi et essaie ensuite de se connecter à l’adresse IP renvoyée. Il peut s’agit d’un élément de l’edge de équilibrage de charge, ou il peut s’agit du serveur XSP lui-même.

      Comme indiqué, l’enregistrement A/AAAA doit résoudre une adresse IP pour les mêmes raisons.

  2. (Facultatif) Vous pouvez ensuite fournir des détails personnalisés sur XSI-Actions/XSI-Events dans la configuration du périphérique pour l’application Webex, en utilisant les balises suivantes :

    <protocols>
    	<xsi>
    		<paths>
    			<root>%XSI_ROOT_WXT%</root>
    			<actions>%XSI_ACTIONS_PATH_WXT%</actions>
    			<events>%XSI_EVENTS_PATH_WXT%</events>
    		</paths>
    	</xsi>
    </protocols>
    1. Ces paramètres de configuration précédentent sur toute configuration dans votre cluster BroadWorks dans Control Hub.

    2. S’ils existent, le client sera comparé à l’adresse XSI d’origine qu’elle a reçue via la configuration du groupe BroadWorks.

    3. S’il y a une différence détectée, le client va ré initialiser sa connectivité XSI Actions/XSI Events. La première étape dans ceci est d’effectuer le même processus de recherche DNS répertorié à l’étape 1 – cette fois en demandant une recherche de la valeur du paramètre %XSI_ROOT_WXT% à partir de son fichier de configuration.


      Assurez-vous de créer les enregistrements SRV graphiques si vous utilisez cette balise pour modifier les interfaces Xsi.
Basculement

Au cours de la connexion, l’application Webex effectue une recherche DNS SRV pour _xsi-client._tcp. , crée une liste d’organisateurs et se connecte à l’un des hôtes en fonction de la priorité SRV, puis par<xsi domain="">poids. Cet hôte connecté devient celui qui est sélectionné pour toutes les futures demandes. Une chaine d’événements est ensuite ouverte à l’organisateur sélectionné et une pulsation est envoyée régulièrement pour vérifier la chaine. Toutes les demandes envoyées après le premier incluent un cookie renvoyé dans la réponse HTTP. Il est donc important que le serveur de balance de charge garde la session en permanence (affinité) et envoie toujours des demandes au même serveur backend XSP.

Si une demande ou une pulsation à un organisateur échoue, plusieurs choses peuvent se produire :

  • Si la panne est due à une erreur réseau (ex. : TCP, SSL), l’application Webex avance immédiatement vers l’organisateur suivant sur la liste.

  • Si un code d’erreur (HTTP 5xx) est renvoyé, la demande échoue immédiatement.

  • Si une réponse n’est pas reçue dans un délai donné, alors la demande est considérée comme un échec en raison du délai d’attente et les prochaines demandes sont envoyées au prochain organisateur. Cependant, la demande qui a échoué est considérée comme ina échec. Certaines demandes sont retenées après l’échec (avec l’augmentation du temps de nouvelle tentative). Les demandes que le non essentiel a pris en charge ne sont pas retriées.

Lorsqu’un nouvel organisateur a été tenté avec succès, il devient le nouvel organisateur sélectionné si l’organisateur est présent dans la liste. Lorsque le dernier organisateur de la liste a été tenté, l’application Webex est mise à jour vers le premier.

Dans le cas de pulsations, s’il y a deux échecs de demande consécutifs, l’application Webex ré initialise le canal de l’événement.

Notez que l’application Webex n’effectue pas de retour d’échec et la détection des services DNS est effectuée une seule fois au moment de la inscription.

Pendant la inscription, l’application Webex essaie de télécharger le fichier de config via l’interface XSP/Dms. Il effectue une recherche d’enregistrement A/AAAA de l’hôte dans l’URL DMS récupérée et se connecte à la première IP. Il tentera tout d’abord d’envoyer la demande de téléchargement du fichier de config en utilisant SSO de base. Si cela échoue pour une raison quelconque, il va essayer à nouveau mais avec le nom d’utilisateur et le mot de passe du périphérique.