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 s’authentifier ?

(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 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 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.

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.

Comment les applications Webex trouvent 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’équipe pour_xsi-client._tcp.<xsi domain>

      (Voir l’exemple suivant 1)

   2. 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.

      Chaque enregistrement A/AAAA doit être mapé sur une adresse IP. Nous mandateons cette configuration car les pulsations XSI de l’événement du client doivent aller à la même adresse IP utilisée pour établir la chaine de l’événement. Si vous mappez le nom A/AAAA à plus d’une adresse IP, le client envoie éventuellement des pulsations à une adresse 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.

      Le client se connecte à l’une des cible (et donc son enregistrement A/AAAA avec une seule adresse IP) en fonction de la priorité 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é ci-dessus, l’enregistrement A/AAAA doit résoudre vers une adresse IP pour les mêmes raisons.

      (Voir l’exemple suivant 2)

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 de 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 dans le%XSI_ROOT_WXT%dans son 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

Si vous mappez votre enregistrement DNS A/AAAA sur plusieurs adresses IP (pour fournir des connexions redondantes pour les microservices, comme montré dans le tableau précédent), alors vous ne devez pas utiliser le même enregistrement A/AAAA que l’adresse XSI des clients. Dans ce cas, vous pouvez configurer une Enregistrement SRV pour les clients (comme indiqué dans le tableau 1 ci-dessus), mais l’SRV doit résoudre sur un ensemble différent d’enregistrements A/AAAA. Comme précédemment indiqué, ces enregistrements A/AAAA doivent ma maper sur une adresse IP chacune.

Recommandations DNS des nodes XSP

• Vous devez utiliser un enregistrement A/AAAA unique si vous devez résoudre un proxy de équilibrage de charge inverse vers les serveurs XSP.

• Vous devez utiliser uniquement les enregistrements round-robin A/AAAA si :

  • vous avez plusieurs serveurs XSP internet que vous voulez trouver pour les microservices Webex.

  • vous n’utilisez pas les enregistrements A/AAAA pour résoudre l’adresse XSI du client.

• 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.