Préparer votre environnement
Points de décision
Considération | Questions auxquelles répondre | Ressources |
Architecture et infrastructure |
Combien de XSP ? Comment prennent-ils le mTLS ? |
Planificateur de capacité du système Cisco BroadWorks Guide d’ingénierie système Cisco BroadWorks Référence CLI XSP Le présent document |
Mise à disposition des clients et des utilisateurs | Pouvez-vous affirmer que vous faites confiance aux e-mails 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 publiques sur https://developer.webex.com Le présent document |
Charte graphique | Quelle couleur et quel logo voulez-vous utiliser ? | Article de charte graphique de l’application Webex |
Modèles | Quels sont vos différents cas d’utilisation client ? | Le présent document |
Fonctionnalités de l’abonné par client/entreprise/groupe | Choisissez le pack pour définir le niveau de service par modèle. Basic, Standard, Premium ou Softphone. | Le présent document Matrice des fonctionnalités/packs |
Authentification de l'utilisateur | BroadWorks ou Webex | Le présent document |
Adaptateur de mise à disposition (pour les options de mise à disposition en flux continu) | Utilisez-vous déjà IM&P intégré, par exemple pour UC-One SaaS ? Avez-vous l’intention d’utiliser plusieurs modèles ? Y a-t-il un cas d’utilisation plus courant prévu ? |
Le présent document Référence CLI du serveur d'applications |
Architecture et infrastructure
Avec quelle échelle comptez-vous commencer ? Il est possible d’augmenter à l’avenir, mais votre estimation actuelle de l’utilisation devrait guider la planification de l’infrastructure.
Collaborez avec votre responsable de compte/représentant commercial Cisco pour dimensionner votre infrastructure XSP, conformément au Cisco BroadWorks System Capacity Planner et au Guide d'ingénierie système Cisco BroadWorks.
Comment Webex établira-t-il des connexions TLS mutuelles à 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 prenons pas en charge les connexions TCP non chiffrées à la périphérie de votre réseau).
Mise à disposition des clients et des utilisateurs
Quelle méthode de mise à disposition des utilisateurs vous convient le mieux ?
Provisionnement fluide avec des courriers électroniques de confiance : En attribuant le service « IM&P intégré » sur BroadWorks, l’abonné est automatiquement provisionné dans Webex.
Si vous pouvez également affirmer que les adresses électroniques des abonnés dans BroadWorks sont valides et uniques à Webex, alors vous pouvez utiliser la variante « e-mail de confiance » du provisionnement Flowthrough. Les comptes Webex des abonnés sont créés et activés sans leur intervention ; ils téléchargent simplement le client et se connectent.
L’adresse électronique est un attribut utilisateur clé sur Webex. Par conséquent, le fournisseur de services doit fournir une adresse électronique valide pour l’utilisateur afin de les fournir pour les services Webex. Ceci doit se trouver dans l’attribut ID de l’adresse électronique de l’utilisateur dans BroadWorks. Nous vous recommandons de le copier également dans l'attribut ID secondaire.
Provisionnement fluide sans courriers électroniques de confiance : Si vous ne pouvez pas faire confiance aux adresses électroniques des abonnés, vous pouvez toujours affecter le service IM&P intégré dans BroadWorks à la mise à disposition des 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-approvisionnement de l'utilisateur : Cette option ne nécessite pas d’attribution de service IM&P dans BroadWorks. Vous (ou vos clients) distribuez plutôt un lien de mise à disposition et les liens pour télécharger les différents clients, avec votre charte graphique 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 à leur sujet à partir de BroadWorks (y compris leurs numéros principaux).
Mise à disposition contrôlée par le FS via les API : Webex expose un ensemble d’API publiques qui permettent aux fournisseurs de services d’intégrer le provisionnement des utilisateurs/abonnés dans leurs flux de travail existants.
Exigences de mise à disposition
Le tableau suivant résume les exigences pour chaque méthode de mise à disposition. En plus de ces exigences, votre déploiement doit répondre aux exigences système générales décrites dans ce guide.
Méthode de mise à disposition |
Exigences requises |
---|---|
Provisionnement du flux intermédiaire (Courriers électroniques approuvés ou non approuvés) |
L’API de provisionnement Webex ajoute automatiquement les utilisateurs existants de BroadWorks à Webex une fois que l’utilisateur répond aux exigences requises et que vous activez le service IM+P intégré. Il y a deux flux (courriers électroniques approuvés ou non approuvés) que vous attribuez via le modèle client sur Webex. Exigences de BroadWorks :
Exigences requises pour Webex : Le modèle client comprend les paramètres suivants :
|
Mise à disposition automatique de l’utilisateur |
L’administrateur fournit à un utilisateur BroadWorks existant un lien vers le portail d’activation de l’utilisateur. L’utilisateur doit se connecter au portail à l’aide des identifiants BroadWorks et fournir une adresse électronique valide. Une fois le courrier électronique validé, Webex récupère des informations supplémentaires sur l’utilisateur pour terminer le provisionnement. Exigences de BroadWorks :
Exigences requises pour Webex : Le modèle client comprend les paramètres suivants :
|
Mise à disposition contrôlée par le fournisseur de services via l’API (Courriers électroniques approuvés ou non approuvés) |
Webex expose un ensemble d’API publiques qui vous permettent d’intégrer le provisionnement des utilisateurs dans vos workflows et outils existants. Il existe deux flux :
Exigences de BroadWorks :
Exigences requises pour Webex :
Pour utiliser les API, allez dans Abonnés BroadWorks. |
Correctifs requis avec mise à disposition continue
Si vous utilisez le provisionnement continu, vous devez installer un correctif système et appliquer une propriété CLI. Consultez la liste ci-dessous pour obtenir les instructions qui s'appliquent à votre version BroadWorks :
Pour R22 :
Poser l'AP.as.22.0.1123.ap376508.
Après l’installation, configurez la propriété
bw.msg.includeIsEnterpriseInOSSschema
àtrue
de l'interface de ligne de commande dans Maintenance/ContainerOptions.Pour plus d’informations, voir les notes du patch https://www.cisco.com/web/software/286326332/154309/AP.as.22.0.1123.ap376508.txt.
Pour R23 :
Installer AP.as.23.0.1075.ap376509
Après l’installation, configurez la propriété
bw.msg.includeIsEnterpriseInOSSschema
àtrue
de l'interface de ligne de commande dans Maintenance/ContainerOptions.Pour plus d’informations, voir les notes du patch https://www.cisco.com/web/software/286326332/154325/AP.as.23.0.1075.ap376509.txt.
Pour R24 :
Installer AP.as.24.0.944.ap375100
Après l’installation, configurez la propriété
bw.msg.includeIsEnterpriseInOSSschema
àtrue
de l'interface de ligne de commande dans Maintenance/ContainerOptions.Pour plus d’informations, voir les notes du patch https://www.cisco.com/web/software/286326332/154326/AP.as.24.0.944.ap375100.txt.
Une fois ces étapes terminées, vous ne pourrez pas fournir les services UC-One Collaborate aux nouveaux utilisateurs. Les utilisateurs nouvellement provisionnés doivent être des utilisateurs de Webex pour Cisco BroadWorks.
|
Paramètres linguistiques pris en charge
Au cours du provisionnement, la langue qui a été attribuée dans BroadWorks au premier utilisateur administrateur provisionné est automatiquement attribuée en tant que paramètres régionaux par défaut pour cette organisation cliente. Ce paramètre détermine la langue par défaut utilisée pour les courriers électroniques d'activation, les réunions et les invitations à des réunions sous cette organisation cliente.
Cinq langues locales de caractères au format (ISO-639-1)_(ISO-3166) sont prises en charge. Par exemple, en_US correspond à English_UnitedStates. Si une seule langue de deux lettres est demandée (en utilisant le format ISO-639-1), le service génère une langue locale de cinq caractères en combinant la langue demandée avec un code de pays du modèle, c'est-à-dire « requestedLanguage_CountryCode », s'il est impossible d'obtenir une langue locale valide, alors la langue sensible par défaut utilisée en fonction du code de langue requis.
Le tableau suivant répertorie les paramètres locaux pris en charge et le mappage qui convertit un code de langue à deux lettres en paramètres locaux à cinq caractères pour les situations où les paramètres locaux à cinq caractères ne sont pas disponibles.
Paramètres linguistiques pris en charge (ISO-639-1)_(ISO-3166) |
Si seulement un code de langue à deux lettres est disponible... |
|
---|---|---|
Code de langue (ISO-639-1) ** |
Utilisez plutôt les paramètres locaux sensibles par défaut (ISO-639-1)_(ISO-3166) |
|
en_États-Unis en_AU en_Go en_CA |
en cours |
en_États-Unis |
fr_FR fr_CA |
fr |
fr_FR |
cs_CZ |
CS |
cs_CZ |
da_NSP |
DA |
da_NSP |
de_de |
de |
de_de |
hu_HU |
hu |
hu_HU |
id_ID |
ID |
id_ID |
it_it |
il |
it_it |
ja_jp |
ja |
ja_jp |
ko_KR |
ko |
ko_KR |
es_es es_CO es_MX |
es |
es_es |
nl_nl |
nl |
nl_nl |
nb_NON |
nb |
nb_NON |
pl_PL |
PL |
pl_PL |
pt_PT pt_BR |
pt |
pt_PT |
ru_ru |
ru |
ru_ru |
ro_RO |
roulé |
ro_RO |
zh_CN zh_TW |
zéh |
zh_CN |
sv_SE |
sv |
sv_SE |
ar_SA |
ar |
ar_SA |
tr_TR |
très |
tr_TR |
Les paramètres locaux es_CO, id_ID, nb_NO et pt_PT ne sont pas pris en charge par les sites de réunion Webex. Pour ces localités, Les sites Webex Meetings seront en anglais uniquement. L'anglais est la langue par défaut pour les sites si aucune langue/non valide/non prise en charge est requise pour le site. Ce champ de langue s’applique lors de la création d’une organisation et d’un site Webex Meetings. Si aucune langue n'est mentionnée dans une publication ou dans l'API de l'abonné, la langue du modèle sera utilisée comme langue par défaut. |
Charte graphique
Les administrateurs partenaires peuvent utiliser les personnalisations avancées de la marque pour personnaliser l’apparence de l’application Webex pour les organisations clientes gérées par le partenaire. Les administrateurs partenaires peuvent personnaliser les paramètres suivants pour s’assurer que l’application Webex reflète la marque et l’identité de leur entreprise :
Logos de l’entreprise
Schémas de couleurs uniques pour le mode clair ou le mode sombre
URL d'assistance personnalisées
Pour plus de détails sur la personnalisation de la charte graphique, reportez-vous à Configurer les personnalisations avancées de la charte graphique.
|
Modèles des clients
Les modèles clients vous permettent de définir les paramètres par lesquels les clients et les abonnés associés sont automatiquement provisionnés sur Webex pour Cisco BroadWorks. Vous pouvez configurer plusieurs modèles client si nécessaire, mais lorsque vous intégrez 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 énuméré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 de détails). Tous les utilisateurs qui sont provisionnés avec ce modèle, que ce soit par flux continu ou par auto-provisionnement, reçoivent le pack par défaut.
Vous avez le contrôle sur la sélection des packs pour différents clients en créant plusieurs modèles et en sélectionnant différents packs par défaut dans chacun d'entre eux. Vous pouvez ensuite distribuer différents liens de mise à disposition, ou différents adaptateurs de mise à disposition par entreprise, en fonction de la méthode de mise à disposition des utilisateurs que vous avez choisie pour ces modèles.
Vous pouvez modifier le pack d’abonnés spécifiques à partir de cette valeur par défaut, à l’aide de l’API de mise à disposition (voir Documentation de l’API Cisco BroadWorks ou via Partner Hub (voir Changer le pack utilisateur dans Partner Hub).
Vous ne pouvez pas modifier le pack d’un abonné à partir de BroadWorks. L’attribution du service IM&P intégré est activée ou désactivée ; si l’abonné se voit attribuer ce service dans BroadWorks, le modèle Partner Hub associé à l’URL de mise à disposition de l’entreprise de cet abonné définit le package.
Revendeur et entreprises ou prestataire de services et groupes ?
La façon dont votre système BroadWorks est configuré a un impact sur le flux via la mise à disposition. Si vous êtes un revendeur avec Entreprises, vous devez activer le mode Entreprise lorsque vous créez un modèle.
Si votre système BroadWorks est configuré en mode Fournisseur de services, vous pouvez laisser le commutateur de mode Entreprise désactivé dans vos modèles.
Si vous prévoyez de provisionner les organisations clientes en utilisant les deux modes BroadWorks, vous devez utiliser des modèles différents pour les groupes et les entreprises.
Assurez-vous que vous avez appliqué les correctifs BroadWorks qui sont nécessaires pour le provisionnement continu. Pour plus de détails, voir Correctifs requis avec mise à disposition directe.
|
Mode d’authentification
Décidez comment vous souhaitez que les abonnés s’authentifient lorsqu’ils se connectent à Webex. Vous pouvez affecter le mode à l'aide du paramètre Mode d'authentification du modèle client. Le tableau suivant présente certaines des options.
Ce paramètre n’a aucun effet sur la connexion au portail d’activation de l’utilisateur. Les utilisateurs qui se connectent au portail doivent saisir leur ID utilisateur et leur mot de passe BroadWorks, tels que configurés sur BroadWorks, quelle que soit la façon dont vous configurez le mode d'authentification sur le modèle client.
|
Mode d’authentification | BroadWorks | Webex |
Identité de l’utilisateur principal | ID utilisateur BroadWorks | Adresse électronique |
Fournisseur d’identité | BroadWorks.
|
Identité commune Cisco |
Authentification multifactorielle ? | Non | Nécessite un IdP client prenant en charge l'authentification multifactorielle. |
Chemin de validation des informations d'authentification |
|
|
Pour une répartition plus détaillée du flux de connexion SSO avec authentification directe à BroadWorks, voir Flux de connexion SSO.
|
Codage UTF-8 avec authentification BroadWorks
Avec l'authentification BroadWorks, nous vous recommandons de configurer le codage UTF-8 pour l'en-tête d'authentification. UTF-8 résout un problème qui peut se produire avec les mots de passe qui utilisent des caractères spéciaux, le navigateur Web n'encodant pas les caractères correctement. L'utilisation d'un en-tête codé UTF-8, codé en base 64, résout ce problème.
Vous pouvez configurer l'encodage UTF-8 en exécutant l'une des commandes CLI suivantes sur XSP ou ADP :
XSP_CLI/Applications/WebContainer/Tomcat/GeneralSettings> set authenticationEncoding UTF-8
ADP_CLI/Applications/WebContainer/Tomcat/GeneralSettings> set authenticationEncoding UTF-8
Pays
Vous devez sélectionner un pays lorsque vous créez un modèle. Ce pays sera automatiquement affecté en tant que pays d'organisation pour tous les clients qui sont provisionnés avec le modèle dans Common Identity. En outre, le pays de l’organisation déterminera les numéros d’appel internationaux par défaut pour le RTCP Cisco dans les sites de réunion Webex.
Les numéros d’appel internationaux par défaut du site seront configurés sur le premier numéro d’appel disponible défini dans le domaine téléphonique en fonction du pays de l’organisation. Si le pays de l’organisation ne se trouve pas dans le numéro d’appel défini dans le domaine téléphonique, le numéro par défaut de cet emplacement sera utilisé.
N° S |
Emplacement |
Indicatif du pays |
Nom du pays |
---|---|---|---|
1 |
AMER |
+1 |
NOUS, CA |
2 |
APAC |
+65 |
Singapour |
3 |
ÉCHANTILOPE |
+61 |
Australie |
4 |
EMEA |
+44 |
Royaume-Uni |
5 |
EURO-EURO |
+49 |
Allemagne |
Accords avec plusieurs partenaires
Allez-vous sous-licencier Webex pour Cisco BroadWorks à un autre fournisseur de services ? Dans ce cas, chaque fournisseur de services aura besoin d’une organisation partenaire distincte dans Webex Control Hub pour lui permettre de fournir la solution à sa clientèle.
Adaptateur et modèles de mise à disposition
Lorsque vous utilisez la mise à disposition en flux continu, l’URL de mise à disposition que vous saisissez dans BroadWorks provient du modèle dans Control Hub. Vous pouvez avoir plusieurs modèles et donc plusieurs URL de mise à disposition. Cela vous permet de sélectionner, entreprise par entreprise, quel paquet appliquer aux abonnés lorsqu'ils reçoivent le service IM&P intégré.
Vous devez déterminer si vous souhaitez définir une URL de mise à disposition au niveau du système comme chemin de mise à disposition par défaut et quel modèle vous souhaitez utiliser pour cela. De cette façon, il vous suffit de définir explicitement l’URL de mise à disposition 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 mise à disposition au niveau du système, par exemple avec UC-One SaaS. Si tel est le cas, vous pouvez choisir de conserver l’URL au niveau du système pour provisionner les utilisateurs sur UC-One SaaS, et de l’annuler pour les entreprises qui se déplacent vers Webex pour Cisco BroadWorks. Sinon, vous pouvez aller dans l’autre sens et configurer l’URL de niveau système pour Webex pour BroadWorks et reconfigurer les entreprises que vous souhaitez conserver 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 mise à disposition.
Proxy de l'adaptateur de mise à disposition
Pour plus de sécurité, le proxy de l'adaptateur de mise à disposition vous permet d'utiliser un proxy HTTP(S) sur la plate-forme de distribution d'applications pour le déploiement en flux continu entre le AS et Webex. La connexion proxy crée un tunnel TCP de bout en bout qui relaie le trafic entre le AS et Webex, éliminant ainsi la nécessité pour le AS de se connecter directement à l’Internet public. Pour des connexions sécurisées, TLS peut être utilisé.
Cette fonctionnalité nécessite que vous configuriez le proxy sur BroadWorks. Pour plus d'informations, voir Description de la fonctionnalité de proxy de l'adaptateur de mise à disposition Cisco 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 un numéro principal ou un numéro de poste.
Webex utilise les adresses électroniques comme identifiants principaux pour tous les utilisateurs. Si vous utilisez le provisionnement Flowthrough avec des courriers électroniques de confiance, alors vos utilisateurs doivent avoir des adresses valides dans l’attribut de courrier électronique dans BroadWorks.
Si votre modèle utilise l'authentification BroadWorks, vous pouvez copier les adresses électroniques des abonnés dans l'attribut ID secondaire dans BroadWorks. Cela permet aux utilisateurs de se connecter à Webex en utilisant leurs adresses électroniques et leurs mots de passe BroadWorks.
Vos administrateurs doivent utiliser leurs comptes Webex pour se connecter à Partner Hub.
L’intégration d’un administrateur BroadWorks à Webex pour Cisco BroadWorks n’est pas prise en charge. Vous ne pouvez intégrer que les utilisateurs appelants BroadWorks qui ont un numéro principal et/ou un numéro de poste. Si vous utilisez le provisionnement en flux continu, les utilisateurs doivent également se voir attribuer le service IM&P intégré.
|
Serveurs dans votre réseau et exigences logicielles
Instance(s) BroadWorks avec la version minimum R22. Voir les exigences logicielles de BroadWorks (dans ce document) pour les versions et les correctifs pris en charge. Pour plus d’informations, voir Politique de cycle de vie des produits BroadSoft dans la section Politique de cycle de vie BroadSoft et Matrice de compatibilité logicielle BroadWorks.
La ou les instances BroadWorks doivent inclure au moins les serveurs suivants :
Serveur d'applications (AS) avec la version BroadWorks ci-dessus
Serveur réseau (NS)
Serveur de profil (PS)
Serveur(s) XSP ou Application Delivery Platform (ADP) en contact avec le public répondant aux exigences suivantes :
Service d'authentification (BWAuth)
Interfaces actions et événements XSI
DMS (application Web de gestion des périphériques)
Interface CTI (Computer Telephony Intergration)
TLS 1.2 avec un certificat valide (non auto-signé) et tous les intermédiaires requis. Nécessite l'administrateur de niveau système pour faciliter la recherche d'entreprise.
Authentification TLS mutuelle (mTLS) pour le service d'authentification (Nécessite l'installation de la chaîne de certificats client Webex publique comme ancres de confiance)
Authentification TLS mutuelle (mTLS) pour l'interface CTI (Nécessite l'installation de la chaîne de certificats du client Webex publique comme ancres de confiance)
Un serveur XSP/ADP distinct agissant comme un « Call Notifications Push Server » (un NPS dans votre environnement utilisé pour les notifications d’appel push vers 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 R22 ou version ultérieure.
Nous mandatons un serveur XSP/ADP distinct pour CNPS car l’imprévisibilité de la charge de Webex pour les connexions cloud BWKS pourrait avoir un impact négatif sur les performances du serveur NPS, avec pour conséquence une latence accrue des notifications. Reportez-vous au Guide d'ingénierie système Cisco BroadWorks pour en savoir plus à l'échelle XSP.
Plateformes de l’application Webex
Pour télécharger la version anglaise de l’application Webex, rendez-vous sur https://www.webex.com/webexfromserviceproviders-downloads.html. L’application Webex est disponible sur :
PC/ordinateurs portables Windows
PC/ordinateurs portables Apple avec MacOS
iOS (Apple store)
Android (Play Store)
Navigateurs web (allez à https://teams.webex.com/)
Versions localisées
Pour télécharger une version localisée de l’application Webex, utilisez l’un des liens suivants :
https://origin-webex-uat.cisco.com/ko/webexfromserviceproviders-downloads.html (Coréen)
https://origin-webex-uat.cisco.com/fr/webexfromserviceproviders-downloads.html (français)
https://origin-webex-uat.cisco.com/pt/webexfromserviceproviders-downloads.html (Portugais)
https://origin-webex-uat.cisco.com/zh-tw/webexfromserviceproviders-downloads.html (chinois traditionnel)
https://origin-webex-uat.cisco.com/zh-cn/webexfromserviceproviders-downloads.html (chinois simplifié)
https://origin-webex-uat.cisco.com/ja/webexfromserviceproviders-downloads.html (Japon)
https://origin-webex-uat.cisco.com/es/webexfromserviceproviders-downloads.html (Espagne)
https://origin-webex-uat.cisco.com/de/webexfromserviceproviders-downloads.html (Allemand)
https://origin-webex-uat.cisco.com/it/webexfromserviceproviders-downloads.html (Italien)
Téléphones physiques et accessoires
Téléphones IP Cisco :
téléphone IP Cisco série 6800 avec micrologiciel multiplateforme
téléphone IP Cisco série 7800 avec micrologiciel multiplateforme
téléphone IP Cisco série 8800 avec micrologiciel multiplateforme
Voir https://www.cisco.com/c/en/us/products/collaboration-endpoints/ip-phones/multiplatform-firmware.html pour les modèles et plus d'informations.
Nous prenons en charge les téléphones tiers de la même manière que pour les autres intégrations BroadWorks. Cependant, ils n'ont pas encore d'intégration des contacts et de la présence avec Webex pour Cisco BroadWorks.
Adaptateurs :
Adaptateur de téléphone analogique multiplateforme Cisco ATA 191
Adaptateur de téléphone analogique multiplateforme Cisco ATA 192
Voir https://www.cisco.com/c/en/us/products/unified-communications/ata-190-series-analog-telephone-adapters/index.html pour les modèles et plus d'informations.
Casques :
casque Cisco série 500
Voir https://www.cisco.com/c/en/us/products/collaboration-endpoints/headset-500-series/index.html pour les modèles et plus d’informations.
- Périphériques du système d’exploitation de salle :
Série Webex Room et Kit de salle
Série Webex Desk
Webex Board Series
Intégration des périphériques
Pour plus d’informations sur la façon d’intégrer et d’entretenir les périphériques Room OS et MPP pour Webex pour Cisco BroadWorks, voir le Guide d’intégration des périphériques pour Webex pour Cisco BroadWorks.
Profils des périphériques
Vous trouverez ci-dessous les fichiers DTAF que vous devez charger sur vos serveurs d’applications pour prendre en charge l’application Webex en tant que client appelant. Ce sont les mêmes fichiers DTAF que ceux utilisés pour UC-One SaaS, mais il existe un nouveau config-wxt.xml.template
qui est utilisé pour l’application Webex.
Pour télécharger les derniers profils de périphérique, rendez-vous sur le site Téléchargements de logiciels de la plateforme de livraison d'applications pour obtenir les derniers fichiers DTAF. Ces téléchargements fonctionnent à la fois pour ADP et XSP.
Nom du client |
Type de profil du périphérique et nom du pack |
---|---|
Modèle mobile Webex |
Identité/Type de profil de périphérique : Connexion - Mobile DTAF : Fichier de configuration : |
Modèle de tablette Webex |
Identité/Type de profil de périphérique : Connecter - Tablette DTAF : Fichier de configuration : |
Modèle de bureau Webex |
Identité/Type de profil de périphérique : Communicateur d'entreprise - PC DTAF : Fichier de configuration : |
Identifier/profil du périphérique
Tous les utilisateurs de Webex pour Cisco BroadWorks doivent avoir un profil d’identité/de périphérique attribué dans BroadWorks qui utilise l’un des profils de périphérique ci-dessus afin de passer des appels à l’aide de l’application Webex. Le profil fournit la configuration qui permet à l'utilisateur de passer des appels.
Obtention des identifiants OAuth pour votre Webex pour Cisco BroadWorks
Effectuez une demande de service auprès de votre agent d'intégration ou auprès du CAT Cisco pour provisionner Cisco OAuth pour votre compte Cisco Identity Provider Federation.
Utilisez le titre de demande suivant pour les fonctionnalités respectives :
XSP AuthService Configuration » pour configurer le service sur XSP.
« Configuration NPS pour l’installation du proxy d’authentification » pour configurer NPS pour utiliser le proxy d’authentification.
Synchronisation UUID utilisateur CI » pour la synchronisation UUID utilisateur CI. Pour plus de détails sur cette fonctionnalité, voir : Prise en charge de Cisco BroadWorks pour CI UUID.
Configurez BroadWorks pour activer la facturation Cisco pour BroadWorks et Webex Pour les abonnements BroadWorks.
Cisco vous donne un ID client OAuth, un secret client et un jeton d’actualisation qui est valide pendant 60 jours. Si le jeton expire avant de l’utiliser, vous pouvez faire une autre demande.
Si vous avez déjà obtenu les informations d'identification du fournisseur d'identité Cisco OAuth, effectuez une nouvelle demande de service pour mettre à jour vos informations d'identification. |
Certificats de commande
Exigences du 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 XSP publics, pour toutes les applications requises. Ils seront utilisés pour prendre en charge la vérification du certificat TLS pour toutes les connexions entrantes vers vos serveurs XSP.
Ces certificats doivent inclure votre nom de domaine public entièrement qualifié XSP comme 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 face au public sont déployés :
Via un proxy de passerelle TLS
Via un proxy TLS pass-through
Directement dans le XSP
Le schéma suivant résume où le certificat du serveur public signé par une autorité de certification doit être chargé dans ces trois cas :
Les autorités de certification prises en charge publiquement que l’application Webex prend en charge pour l’authentification sont répertoriées dans Autorités de certification prises en charge pour les services hybrides Webex.
Exigences du certificat TLS pour le proxy de pont TLS
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'autorité de certification publique qui a signé le certificat du serveur du proxy.
Un certificat signé par une autorité de certification 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'autorité de certification interne qui a signé le certificat du serveur XSP.
Exigences du certificat TLS pour le proxy TLS-passthrough 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’autorité de certification publique qui a signé les certificats du serveur XSP.
Exigences de certificat supplémentaires pour l'authentification mutuelle TLS sur l'interface CTI
Lors de la connexion à l'interface CTI, Webex présente un certificat client dans le cadre de l'authentification TLS mutuelle. Le certificat d’autorité de certification/de chaîne du client Webex peut être téléchargé via le Control Hub.
Pour télécharger le certificat :
Connectez-vous à Partner Hub, accédez à
et cliquez sur le lien de téléchargement du certificat.Les exigences exactes pour le déploiement de cette chaîne de certificats d'autorité de certification Webex dépendent de la manière dont vos XSP en contact avec le public sont déployés :
Via un proxy de passerelle TLS
Via un proxy TLS pass-through
Directement dans le XSP
Le schéma suivant résume les exigences en matière de certificat dans ces trois cas :
(Option) Exigences du certificat pour le proxy du pont TLS
Webex présente un certificat client signé publiquement au proxy.
Le proxy fait confiance à l'autorité de certification interne de Cisco qui a signé le certificat client. Vous pouvez télécharger cette autorité de certification/chaîne à partir du Control Hub et l’ajouter au magasin de confiance 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'autorité de certification publique qui a signé le certificat du serveur du proxy.
Le proxy présente un certificat client signé en interne aux XSP.
Ce certificat doit avoir le champ d'extension x509.v3 Utilisation étendue de la clé renseigné avec l'OID BroadWorks 1.3.6.1.4.1.6431.1.1.8.2.1.3 et l'objectif TLS clientAuth. 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 de certificats clients internes pour le proxy, notez que les certificats SAN ne sont pas pris en charge. Les certificats de serveur internes pour le XSP peuvent être SAN.
Les autorités de certification publiques peuvent ne pas être disposées à signer des certificats avec l'OID BroadWorks propriétaire qui est requis. Dans le cas d'un proxy de passerelle, vous pouvez être forcé d'utiliser une autorité de certification interne pour signer le certificat 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'autorité de certification interne.
L'IdentitéClient du serveur d'applications contient le NC du certificat client signé en interne présenté au XSP par le proxy.
(Option) Exigences de certificat pour le proxy TLS-passthrough ou XSP dans DMZ
Webex présente un certificat client interne Cisco signé par une autorité de certification aux XSP.
Les XSP font confiance à l'autorité de certification interne Cisco qui a signé le certificat client. Vous pouvez télécharger cette autorité de certification/chaîne à partir du Control Hub et l’ajouter au magasin de confiance 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’autorité de certification publique qui a signé les certificats du serveur XSP.
L'IdentitéClient du serveur d'applications contient le NC du certificat client signé Cisco présenté au XSP par Webex.
Préparez votre réseau
Pour plus d’informations sur les connexions utilisées par Webex pour Cisco BroadWorks, voir : Configuration réseau requise pour Webex pour Cisco BroadWorks. Cet article contient la liste des adresses IP, des ports et des protocoles requis pour configurer les règles d’entrée et de sortie de votre pare-feu.
Configuration réseau requise pour les services Webex
Les tables de pare-feu des règles d’entrée et de sortie précédentes ne documentent que les connexions spécifiques à Webex pour Cisco BroadWorks. Pour des informations générales sur les connexions entre l’application Webex et le Cloud Webex, voir Configuration réseau requise pour les services Webex. Cet article est générique de Webex, mais le tableau suivant identifie les différentes sections de l’article et la pertinence de chaque section pour Webex pour Cisco BroadWorks.
Section de l'article Exigences réseau |
Pertinence des informations |
---|---|
Résumé des types de périphériques et des protocoles pris en charge par Webex |
Informationnel |
Informationnel |
|
Doit lire |
|
Doit lire |
|
Domaines et URL auxquels il faut accéder pour les services Webex |
Doit lire |
Facultatif |
|
Facultatif |
|
Facultatif |
|
Configuration minimale du réseau requise pour les services Webex basés sur SIP |
Facultatif |
Facultatif |
|
Résumé des autres services hybrides Webex et de leur documentation |
Facultatif |
Services Webex pour les clients FedRAMP |
N/A |
Informations complé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 services Cloud Webex et les applications du client Webex qui doivent accéder au réseau du partenaire prennent entièrement en charge la redondance Broadworks XSP fournie par le partenaire. Lorsqu’un XSP ou un site est indisponible pour une maintenance planifiée ou pour une raison imprévue, les services et applications Webex peuvent passer à un autre XSP ou site fourni par le partenaire afin de répondre à une demande.
Topologie du réseau
Les XSP Broadworks peuvent être déployés directement sur Internet, ou peuvent résider dans une zone démilitarisée (DMZ) traversée par un élément de répartition 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 pouvant être précédé par un répartiteur de charge, chacun ayant une adresse IP publique. Si les XSP sont derrière un répartiteur de charge, les microservices et l’application Webex ne voient que l’adresse IP du répartiteur de charge et Broadworks semble n’avoir qu’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 frontés par un répartiteur de charge sur chaque site. Le site A a XSP1 et XSP2 fronté par LB1, et le site B a XSP3 et XSP4 fronté par LB2. Seuls les répartiteurs de charge sont exposés sur le réseau public et les XSP sont dans les réseaux privés DMZ.
Services Cloud Webex
Configuration DNS
Les microservices du Cloud Webex doivent être en mesure de trouver le(s) serveur(s) XSP Broadworks pour la connexion aux interfaces Xsi, au service d'authentification et au CTI.
Les microservices du Cloud Webex effectueront la recherche DNS A/AAAA du nom d'hôte XSP configuré et se connecteront à l'adresse IP renvoyée. Il peut s'agir d'un élément d'équilibrage de charge ou du serveur XSP lui-même. Si plusieurs adresses IP sont renvoyées, la première adresse IP de la liste sera sélectionnée. La recherche SRV n'est actuellement pas prise en charge.
Exemple : Le DNS du partenaire est Un Record pour la découverte de serveurs XSP équilibrés orientés Internet Round-Robin.
Type d'enregistrement |
Nom |
Cible |
Objet |
---|---|---|---|
R |
|
|
Points sur LB1 (Site A) |
R |
|
|
Points sur LB2 (Site B) |
Basculement
Lorsque les microservices Webex envoient une demande au répartiteur de charge/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'adresse IP comme étant bloquée et effectuent immédiatement une avance de routage vers l'adresse IP suivante.
Si un code d'erreur (HTTP 5xx) est renvoyé, les microservices Webex marquent l'IP comme étant bloquée et effectuent immédiatement une avance de routage vers l'IP suivante.
Si aucune réponse HTTP n'est reçue dans les 2 secondes, la demande expire et les microservices Webex marquent l'IP comme bloquée et effectuent une avance de routage vers l'IP suivante.
Chaque demande est testée 3 fois avant qu'une panne ne soit signalée au microservice.
Lorsqu'une adresse IP figure dans la liste bloquée, 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 de temps prédéterminée, une adresse IP bloquée expire et revient dans la liste pour essayer lorsqu'une autre demande est effectuée.
Si toutes les adresses IP sont bloquées, le microservice tentera toujours d’envoyer la demande en sélectionnant une adresse IP de manière aléatoire dans la liste bloquée. En cas de succès, cette adresse IP est supprimée de la liste bloquée.
Statut
L’état de la connectivité des services Webex Cloud aux XSP ou aux répartiteurs de charge peut être affiché dans le Control Hub. Sous un cluster d’appel BroadWorks, un état de connexion est affiché pour chacune de ces interfaces :
Actions XSI
Événements XSI
Service d’authentification
L'état de la connexion est mis à jour lorsque la page est chargée ou lors des mises à jour de saisie. Les états des connexions peuvent être :
Vert : Lorsque l'interface peut être atteinte sur l'une des adresses IP de la recherche d'enregistrement A.
Rouge : Lorsque toutes les adresses IP de la recherche d'enregistrement A 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
E-mail/auto-activation non fiable
Contrôle de santé du service Broadworks
Application Webex
Configuration DNS
L'application Webex accède aux services Xtended Services Interface (XSI-Actions & XSI-Events) et Device Management Service (DMS) sur XSP.
Pour trouver le service XSI, l’application Webex effectue la recherche DNS SRV pour _xsi-client._tcp.<webex app xsi domain>
. Le SRV pointe vers l'URL configurée pour les hôtes XSP ou les répartiteurs de charge pour le service XSI. Si la recherche SRV n’est pas disponible, l’application Webex repasse à la recherche A/AAAA.
Le SRV peut se résoudre à plusieurs cibles A/AAAA. Cependant, chaque enregistrement A/AAAA ne doit correspondre qu'à une seule adresse IP. S'il y a plusieurs XSP dans une DMZ derrière le répartiteur de charge/périphérique, il est nécessaire que le répartiteur de charge soit configuré pour maintenir la persistance de session pour acheminer toutes les demandes de la même session vers le même XSP. Nous mandatons cette configuration car les battements de cœur d'événement XSI du client doivent aller au même XSP qui est utilisé pour établir le canal d'événement.
Dans l'exemple 1, l'enregistrement A/AAAA pour webex-app-xsp.example.com n'existe pas et n'a pas besoin de le faire. Si votre DNS exige qu'un enregistrement A/AAAA soit défini, alors seulement 1 adresse IP doit être renvoyée. Quoi qu’il en soit, le SRV doit toujours être défini pour l’application Webex. Si l’application Webex utilise le nom A/AAAA qui résout plus d’une adresse IP, ou si l’élément de répartition de charge/bordure ne maintient pas la persistance de la session, le client finit par envoyer des battements à un XSP où il n’a pas établi de canal d’événement. Il en résulte un déchirement du canal et un trafic interne beaucoup plus important, ce qui nuit aux performances de votre cluster XSP. Étant donné que le Cloud Webex et l’application Webex ont des exigences différentes dans la recherche d’enregistrement A/AAAA, vous devez utiliser un FQDN distinct pour le Cloud Webex et l’application Webex pour accéder à vos XSP. Comme le montrent les exemples, le Cloud Webex utilise Un enregistrement |
Exemple 1–Plusieurs XSP, chacun derrière des équilibreurs de charge distincts
Dans cet exemple, le SRV pointe vers des enregistrements A mutilés, chaque enregistrement A pointant vers un équilibreur de charge différent sur un site différent. L’application Webex utilisera toujours la première adresse IP de la liste et ne passera à l’enregistrement suivant que si le premier est en panne.
Type d'enregistrement |
Enregistrer |
Cible |
Objet |
---|---|---|---|
SRV |
|
|
Découverte client de l'interface Xsi |
SRV |
|
|
Découverte client de l'interface Xsi |
R |
|
|
Points sur LB1 (site A) |
R |
|
|
Points sur LB2 (site B) |
Exemple 2—Plusieurs XSP derrière un seul répartiteur de charge (avec pont TLS)
Pour la demande initiale, le répartiteur de charge sélectionne un XSP aléatoire. Ce XSP renvoie un cookie que l’application Webex inclut dans les futures demandes. Pour les demandes futures, le répartiteur de charge utilise le cookie pour acheminer la connexion vers le bon XSP, en veillant à ce que le canal de l’événement ne se rompe pas.
Type d'enregistrement |
Enregistrer |
Cible |
Objet |
---|---|---|---|
SRV |
|
|
Équilibreur de charge |
R |
LB.exemple.com |
|
Adresse IP du répartiteur de charge (les XSP sont derrière le répartiteur de charge) |
URL DMS
Au cours du processus de connexion, l’application Webex récupérera également l’URL DMS pour télécharger son fichier de configuration. L’hôte dans l’URL sera analysé et l’application Webex effectuera une recherche DNS A/AAAA de l’hôte pour se connecter au XSP qui héberge le service DMS.
Exemple : DNS Un enregistrement pour la découverte de Round-Robin équilibré serveur XSP orienté Internet/équilibreurs de charge par l’application Webex pour télécharger des fichiers de configuration via DMS :
Type d'enregistrement |
Nom |
Cible |
Objet |
---|---|---|---|
R |
|
|
Points sur LB1 (site A) |
R |
|
|
Points sur LB2 (site B) |
Comment l’application Webex trouve les adresses XSP
Le client tente de localiser les nœuds XSP en utilisant le flux DNS suivant :
Le client récupère initialement les URL Xsi-Actions/Xsi-Events à partir du Cloud Webex (vous les avez saisies lors de la création du cluster d’appel BroadWorks associé). Le nom d'hôte/domaine Xsi est analysé à partir de l'URL et le client effectue la recherche SRV comme suit :
Le client effectue une recherche SRV pour _xsi-client._tcp.<xsi domain="">
Si la recherche SRV renvoie une ou plusieurs cibles A/AAAA :
Le client effectue une recherche A/AAAA pour ces cibles et met en cache les adresses IP renvoyées.
Le client se connecte à l’une des cibles (et donc à son enregistrement A/AAAA avec une seule adresse IP) en fonction de la priorité SRV, puis du poids (ou au hasard si elles sont toutes égales).
Si la recherche SRV ne renvoie pas de cibles :
Le client effectue une recherche A/AAAA du paramètre racine Xsi et tente ensuite de se connecter à l'adresse IP renvoyée. Il peut s'agir d'un élément d'équilibrage de charge ou du serveur XSP lui-même.
Comme indiqué, l'enregistrement A/AAAA doit être résolu à une adresse IP pour les mêmes raisons.
(Facultatif) Vous pouvez ensuite fournir des détails personnalisés 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>
Ces paramètres de configuration ont la priorité sur toute configuration dans votre cluster BroadWorks dans Control Hub.
S'ils existent, le client comparera avec l'adresse XSI d'origine qu'il a reçue via la configuration du cluster BroadWorks.
Si une différence est détectée, le client réinitialisera sa connectivité XSI Actions/XSI Events. La première étape consiste à effectuer le même processus de recherche DNS répertorié à l'étape 1 – cette fois-ci en demandant une recherche pour la valeur du paramètre %XSI_ROOT_WXT% à partir de son fichier de configuration.
Assurez-vous de créer les enregistrements SRV correspondants si vous utilisez cette balise pour modifier les interfaces Xsi.
Basculement
Pendant la connexion, l’application Webex effectue une recherche DNS SRV pour _xsi-client._tcp.<xsi domain="">, crée une liste d’hôtes et se connecte à l’un des hôtes en fonction de la priorité SRV, puis du poids. Cet hôte connecté devient l'hôte sélectionné pour toutes les futures demandes. Un canal d'événement est ensuite ouvert à l'organisateur sélectionné et un battement est envoyé régulièrement pour vérifier le canal. Toutes les demandes envoyées après la première incluent un cookie qui est retourné dans la réponse HTTP, par conséquent, il est important que le répartiteur de charge garde la persistance de la session (affinité) et envoie toujours les demandes au même serveur XSP backend.
Si une demande ou une demande de battement à un organisateur échoue, plusieurs choses peuvent se produire :
Si la panne est due à une erreur réseau (ex : TCP, SSL), la route de l’application Webex passe immédiatement à l’organisateur suivant de la liste.
Si un code d’erreur (HTTP 5xx) est renvoyé, l’application Webex marque cette adresse IP comme étant bloquée et la route passe à l’organisateur suivant de la liste.
Si une réponse n'est pas reçue dans un délai donné, la demande est considérée comme ayant échoué en raison d'un délai d'expiration et les demandes suivantes sont envoyées à l'organisateur suivant. Cependant, la demande expirée est considérée comme ayant échoué. Certaines demandes sont retentées après échec (avec un temps de nouvelle tentative croissant). Les demandes que les non-vitaux supposés ne sont pas retentées.
Lorsqu'un nouvel organisateur est essayé 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é essayé, l’application Webex passe au premier.
Dans le cas des battements de cœur, 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 en arrière et que la détection du service DNS est effectuée une seule fois lors de la connexion.
Pendant la connexion, l’application Webex tente de télécharger le fichier de configuration 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 d'abord d'envoyer la demande de téléchargement du fichier de configuration à l'aide d'un jeton SSO. Si cela échoue pour une raison quelconque, il réessaiera, mais avec le nom d'utilisateur et le mot de passe du périphérique.