- Préparer votre environnement
- Points de décision
- Architecture &infrastructure
- Provisioning des clients et des utilisateurs
- Charte graphique
- Modèles des clients
- Accords avec plusieurs partenaires
- Adaptateur et modèles de provisioning
- Configuration minimale requise
- Comptes
- Serveurs dans votre réseau et exigences logicielles
- Plateformes des clients Teams
- Téléphones physiques et accessoires
- Profils des périphériques
- Commander des certificats
- Exigences de certificat pour l’authentification TLS
- Exigences du certificat TLS pour le proxy TLS-bridge
- Exigences du certificat TLS pour le Proxy inter-accès TLS ou XSP dans DMZ
- Exigences de certificats supplémentaires pour l’authentification TLS mutuelle contre AuthService
- Exigences du certificat TLS mutuel pour le proxy TLS-bridge
- Exigences du certificat TLS mutuel pour le Proxy d’accès TLS ou XSP dans DMZ
- Exigences de certificats supplémentaires pour l’authentification TLS mutuelle sur l’interface CTI
- Préparez votre réseau
- Plan de connexion
- Configuration du pare-feu
- Règles EMEA Ingress
- Règles EMEA Egress
- Règles d’entrée aux Etats-Unis
- Règles egress (Etats-Unis)
- Configuration DNS
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 à l’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 Teams |
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 | 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 la taille de votre infrastructure XSP, selon le Cisco BroadWorks System Capacity Planner ( https://xchange.broadsoft.com/node/473873 ) et le Guide d’ingénierie du système CiscoBroad Works(https://xchange.broadsoft.com/node/422649).
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 et 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 méthode d’approvisionnement utilisateur 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) au client Webex Teams client. Le portail d’activation des utilisateurs utilise les mêmes paramètres.
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 pour BroadWorks. Vous pouvez configurer plusieurs modèles clients comme requis. Certains des paramètres principaux 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 adpaters 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 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 |
|
|
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 Webex Control Hub leur permettre de fournir la solution pour leur 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 sont accordés au 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 savoirplus sur l’échelle XSP.
Plateformes des clients Teams
https://www.webex.com/downloads.html
PC/ordinateurs portables Windows
PC Apple/ordinateurs portables avec MacOS
iOS (boutique Apple)
Android (Play store)
Navigateurs Web(en https://teams.webex.com/)
Téléphones physiques et accessoires
Téléphones IP Cisco :
Cisco IP Phone série 6800 avec microprogrammes multiplatformes
Cisco IP Phone série 7800 avec microprogrammes multiplatformes
Cisco IP Phone série 8800 avec microprogrammes multiplatformes
Voir la https://www.cisco.com/c/en/us/products/collaboration-endpoints/ip-phones/multiplatform-firmware.html pour plus d’informations sur les modèles.
Nous ons en charge les téléphones tiers de la même façon que avec d’autres intégrations BroadWorks. Cependant, ils n’ont pas encore de contacts et d’intégration de présence avec Webex pour BroadWorks.
Adaptateurs
Adaptateur pour téléphone analogique Cisco ATA 191 multiplatformes
Adaptateur pour téléphone analogique Cisco ATA 192 multiplatformes
Voir la https://www.cisco.com/c/en/us/products/unified-communications/ata-190-series-analog-telephone-adapters/index.html pour plus d’informations sur les modèles.
Casques
L’Casque série 500 Cisco
Voir la https://www.cisco.com/c/en/us/products/collaboration-endpoints/headset-500-series/index.html pour plus d’informations sur les modèles.
Profils des périphériques
Ce sont les fichiers DTAF que vous devez charger sur vos serveurs d’applications pour prendre en charge Webex Teams clients appelants. Ce sont les mêmes fichiers DTAF que ceux utilisés pour UC-One SaaS, cependant il y a un nouveau fichier config-wxt.xml.template qui est utilisé
pour Webex Teams.
Nom du client | Type de profil du périphérique et nom du pack |
Webex Teams modèle mobile https://xchange.broadsoft.com/support/uc-one/connect/software |
Identité/Type de profil du périphérique : Connecter - Mobile DTAF : Fichier de config : |
Webex Teams de bureau À partir de https://xchange.broadsoft.com/support/uc-one/communicator/software |
Identité/Type de profil du périphérique : Communication professionnelle - PC DTAF : Fichier de config : |
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 prend Webex Teams en charge pour l’authentification sont listées dans Autorités de certification supportées 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 contre AuthService
Cisco Webex du service d’authentification sur une connexion authentification TLS mutuelle authentifiée. Ceci signifie que Webex présente un certificat client et que le XSP doit le valider. Pour faire confiance à ce certificat, utilisez la chaine de certificats de l’AC Webex pour créer une ancre d’autorisation sur le serveur XSP (ou proxy). La chaine de certificats est disponible au téléchargement via partner hub :
Allez dans Paramètres > BroadWorks Calling.
Cliquez sur le lien télécharger le certificat.
Vous pouvez également obtenir la chaine de certificats à partir https://bwks-uap.webex.com/assets/public/CombinedCertChain.txt. |
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 l’endroit où la chaine de certificats de l’AC Webex doit être déployée dans ces trois cas.

Exigences du certificat TLS mutuel pour le proxy TLS-bridge
Webex présente un certificat client Signé par une AC Webex au proxy.
La chaine de certificats de l’AC Webex est déployée sur le magasin de confiance des proxys, donc le proxy fait confiance au certificat du client.
Le certificat du serveur XSP signé publiquement est également chargé dans le proxy.
Le proxy présente un certificat de 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.:
Extensions X509v3 :
Utilisation étendue de la clé X509v3 :
1.3.6.1.4.1.6431.1.1.8.2.1.3, Authentification TLS du client Web
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 XSP font confiance à l’AC interne.
Les XSP présentent un certificat de serveur signé en interne.
Le proxy fait confiance à l’AC interne.
Exigences du certificat TLS mutuel pour le Proxy d’accès TLS ou XSP dans DMZ
Webex présente un certificat client Signé par une AC Webex aux XSP.
La chaine de certificats des AC Webex est déployée sur le magasin de confiance des XSP, donc les XSP font confiance au certificat du client.
Le certificat du serveur XSP signé publiquement est également 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
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 :

(Option) Exigences de certificat pour le proxy du pont 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.:
Extensions X509v3 : Utilisation étendue de la clé X509v3 : 1.3.6.1.4.1.6431.1.1.8.2.1.3, Authentification TLS du client Web
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 de l’application du serveur 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 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 cependant 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 à partir 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 Teams et le Cloud Webex, qui sont documentées à l’adresse :
Exigences réseau pour Webex Teams services (tout sauf les réunions).
Comment puis-je autoriser Webex Meetings du trafic sur mon réseau ?(exigences du réseau de réunions).
Règles EMEA Ingress
(Dans votre réseau)
Objet | Source | Protocole | 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 |
Webex Teams Client App Xsi/DMS |
Tous |
HTTPS |
Votre XSP |
443 |
Webex Teams VoIP de terminaison SIP |
Tous |
SIP |
Votre SBC |
SP A configuré le protocole TCP |
Règles EMEA Egress
(Hors de votre réseau)
Objet |
Source |
Protocole |
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 |
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 exacte de provisioning 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 |
Protocole |
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 |
Webex Teams Client App Xsi/DMS |
Tous |
HTTPS |
Votre XSP |
443 |
Webex Teams VoIP de terminaison SIP |
Tous |
SIP |
Votre SBC |
SP A configuré le protocole TCP |
Règles egress (Etats-Unis)
(Hors de votre réseau)
Objet |
Source |
Protocole |
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 |
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 exacte de provisioning 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.
Configuration DNS
Les clients de Webex pour BroadWorks doivent pouvoir trouver votre/vos serveur(s) BroadWorks XSP pour authentification, autorisation, contrôle des appels et gestion des périphériques.
Le Cloud Webex doit pouvoir trouver votre/vos serveur(s) BroadWorks XSP pour se connecter aux interfaces Xsi et au service d’authentification.
Vous devrez peut-être enregistrer plusieurs entrées DNS si vous avez des serveurs XSP différents pour des raisons différentes.
Nous vous recommandons vivement de configurer SRV enregistrements pour résoudre les XSP que vous utilisez avec Webex pour BroadWorks. L’utilisation d’enregistrements A/AAAA uniquement cause le trafic interne inutile entre vos XSP, réduisant ainsi les performances. |
Comment Cisco Webex Cloud trouve les adresses XSP
Cisco Webex services 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, l’entrée initiale dans la liste sera sélectionnée.
Exemples 2 &3 ci-dessous capturez le mappage des enregistrements A/AAAA sur les adresses IP individuelles et multiples respectivement.
Dans le scénario de plusieurs adresses IP, nous vous recommandons de configurer vos entrées DNS pour qu’elles pivotent de manière ronde, pour distribuer les connexions client à partir de Webex.
Comment les clients trouvent-ils les adresses XSP ?
Le client tente de localiser les nodes XSP en utilisant le flux DNS suivant :
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 :
Le client effectue une recherche SRV des
_xsi-client._tcp.<xsi domain="">
(Voir l’exemple suivant 1)
Si la recherche SRV l’équipe renvoie une ou plusieurs cible :
Le client fait une recherche A/AAAA pour ces cible et met en cache les adresses IP renvoyées.
Le client se connecte au port SRV port de connexion sur l’une des adresses IP renvoyées. Il choisit une adresse en fonction de la priorité SRV, puis le poids (ou aléatoire si elles sont toutes égales).
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.
(Voir les exemples suivants 2 et 3)
(Facultatif) Vous pouvez ensuite fournir des détails personnalisés sur XSI-Actions/XSI-Events dans la configuration du périphérique pour le client Webex Teams, 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>
Ces paramètres de configuration précédentent sur toute configuration dans votre cluster BroadWorks dans Control Hub.
S’ils existent, le client sera comparé à l’adresse XSI d’origine qu’il a reçue via la configuration du cluster BroadWorks.
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 utilisant le paramètre %XSI_ROOT_WXT% du fichier
de configuration.
Assurez-vous de créer les enregistrements SRV graphiques si vous utilisez cette balise pour modifier les interfaces Xsi.
Exemple d’enregistrements DNS
Type d’enregistrement |
Enregistrer |
Cible |
Objet |
SRV |
|
|
Découverte de l’interface Xsi par le client |
SRV |
|
|
Découverte de l’interface Xsi par le client |
A |
|
|
Recherche de l’IP XSP |
A |
|
|
Recherche de l’IP XSP |
Type d’enregistrement |
Nom |
Cible |
Objet |
A |
|
|
Recherche de l’IP du balanceur de charge Edge |
Type d’enregistrement |
Nom |
Cible |
Objet |
A |
|
|
Recherche de l’IP XSP |
A |
|
|
Recherche de l’IP XSP |
Recommandations DNS des nodes XSP
Vous devez utiliser un seul enregistrement A/AAAA :
si vous devez résoudre un proxy inverse de équilibrage de charge vers les serveurs XSP
Vous devez utiliser les enregistrements round-robin A/AAAA :
si vous avez plusieurs serveurs Internet XSP
Vous devez utiliser la détection des services DNS si vous :
Recherche de répertoire nécessaire dans les environnements avec plusieurs XSP.
Vous avez des intégrations pré-existantes qui nécessitent SRV découverte.
Ont des configurations uniques où les enregistrements standard A/AAAA sont insuffisants.