Webex pour les processus de dépannage BroadWorks

Escalade d’un problème

Après avoir suivi quelques conseils de dépannage, vous devriez avoir une idée raisonnable de l’endroit où le problème est racine.

1

Collectez le plus d’informations possible à partir des systèmes liés au problème

2

Contactez l’équipe appropriée à Cisco pour ouvrir un cas (voir la section Contacts)

Quelles sont les informations du client à collecter

Si vous pensez avoir besoin d’ouvrir un cas ou de faire escalader un problème, collectez les informations suivantes lors du dépannage avec l’utilisateur :

  • Identificateur de l’utilisateur : Adresse électronique CI ou UUID utilisateur (il s’agit de l’identificateur Webex, mais si vous obtenez également l’identificateur BroadWorks de l’utilisateur, ce qui vous aidera)

  • Identificateur de l’organisation

  • Période approximative pendant laquelle le problème a été expérimenté

  • Plateforme client et version

  • Envoyer ou collecter les journaux du client

  • Enregistrer l’ID de suivi s’il est affiché sur le client

Vérifier les détails de l’utilisateur dans Bureau d’assistance

1

Connectez-vous à https://admin.webex.com/helpdesk.

2

Recherchez et cliquez sur l’utilisateur. Ceci ouvre l’écran de synthèse de l’utilisateur.

3

Cliquez sur le nom d’utilisateur pour voir la configuration détaillée de l’utilisateur.

Les informations utiles dans cette vue incluent le cluster UUID, l’identité commune (IC) de l’utilisateur, le cluster de l’application Webex, le comportement d’appel, le GUID du compte BroadWorks.

4

Cliquez sur Copier si vous devez utiliser ces informations dans un autre outil, ou joignez-les à un cas Cisco.

Afficher l’organisation du client dans Bureau d’assistance

1

Connectez-vous à https://admin.webex.com/helpdesk.

2

Recherchez et cliquez sur le nom de l’organisation du client.

3

Faites défiler jusqu’à ce que vous lisez Affichage du portail du client et cliquez sur Afficher le nom du client pour afficher un affichage en lecture seule de l’organisation du client – y compris les utilisateurs et la configuration.

Récupérer les journaux des utilisateurs à partir de Partner Hub

Lors du dépannage des problèmes de bureau et du client mobile, il est important pour les partenaires (et le CAT) d’afficher les journaux du client.

1

Demandez à l’utilisateur d’envoyer les journaux.

2

Demandez à l’utilisateur d’exporter l’environnement d’appel pour vous envoyer le fichier ced.dat.

3

Obtenez les journaux du client à partir de Hub partenaire ou Bureau d’assistance (voir ci-dessous).

Option Hub partenaire :

  1. Connectez-vous au Hub partenaire et recherchez l’organisation du client de l’utilisateur.

  2. Sélectionnez Dépannage.

  3. Sélectionnez Journaux.

  4. Rechercher l’utilisateur (par courrier électronique).

  5. Afficher et télécharger les journaux du client sous la tant que fichier zip.

Bureau d’assistance option :

  1. Connectez-vous à l Bureau d’assistance.

  2. Rechercher l’organisation.

  3. Cliquez sur l’organisation (ouvre l’écran de synthèse).

  4. Faites défiler vers le bas pour cliquer sur Afficher le client .

  5. Sélectionnez Dépannage.

  6. Sélectionnez Journaux.

  7. Rechercher l’utilisateur (par courrier électronique).

  8. Afficher et télécharger les journaux du client sous la tant que fichier zip.

Comment trouver la version du client

1

Partager ce lien avec l’utilisateur : https://help.webex.com/njpf8r5Inscription complète au programme de partenariat en SaaS

2

Demandez à l’utilisateur de vous envoyer le numéro de version.

Vérification du client pour le service d’appel

1

Connectez-vous au client Webex.

2

Vérifiez que l’icône des Options d’appel (un combiné avec un engrenage au dessus) se trouve sur la barre latérale.

Si l’icône n’est pas présente, l’utilisateur n’est peut-être pas encore activé pour le service d’appel dans Control Hub.

3

Ouvrez le menu Paramètres/Préférences et allez à la section Services téléphoniques. Vous devriez voir le statut SSO Session Vous êtes inscrit(0).

(Si un autre service téléphonique, tel que Webex Calling, est démontré, l’utilisateur n’utilise pas Webex pour BroadWorks.)

Cette vérification signifie :

  • Le client a réussi la traversée des microservices Webex requis.
  • L’utilisateur s’est authentifié avec succès.
  • Le client a reçu un jeton Web JSON depuis longtemps par votre système BroadWorks.
  • Le client a récupéré le profil de son périphérique et s’est inscrit dans BroadWorks.

Obtenir des Journaux client ou des commentaires

  • Consultez la section Ressources pour trouver des journaux de clients spécifiques sur les clients de bureau Webex, ou demandez aux utilisateurs d’envoyer les journaux.

  • Demandez aux utilisateurs de clients mobiles d’envoyer les journaux, puis vous pouvez les obtenir via le concentrateur partenaire ou le bureau d’aide.


L’envoi des journaux est silencieux. Cependant, si un utilisateur envoie un commentaire, il est envoyé à l’équipe Cisco Webex devops de l’application. Assurez-vous d’enregistrer le numéro de commentaires de l’utilisateur si vous souhaitez en assurer le suivi avec Cisco. Par exemple :

Obtenir les données de l’environnement d’appel

Les journaux du client Webex sont fortement retentés pour supprimer des informations personnellement identifiables. Vous devez exporter les données d’environnement d’appel à partir du client dans la même session que vous remarquez le problème.

1

Dans le client, cliquez sur le bouton image de profil, puis cliquez sur Aide > Exporter les données d’environnement d’appel.

2

Enregistrez le fichier ced.dat pour résoudre les problèmes d’appel de cet utilisateur.

Important : Se déconnecter ou redémarrer le client effacera le cache interne. Si vous exportez ced.dat après cela, les données exportées ne correspondront à aucun journal qui a été envoyé avant le cache.

Réinitialiser la base de données Webex

1

Dans le client, cliquez sur Aide >'état de santé.

2

Sélectionnez Réinitialiser la base dedonnées .

Ceci déclenche une réinitialisation complète du client et charge l’écran de connexion de l’application Webex.

Vérifier que Webex doit s’inscrire sur BroadWorks

L’application Webex vérifie les informations suivantes pour déterminer si elle doit s’inscrire à BroadWorks :

  • Droit de l’utilisateur à broadworks-connector

  • Comportement d’appel pour l’organisation et l’utilisateur

Vérifier le comportement d’appel d’un utilisateur et l’accès au connecteur

  1. Connectez-vous à Bureau d’assistance (https://admin.webex.com/helpdesk) avec vos identifiants d’administrateur partenaire.

  2. Rechercher l’utilisateur.

  3. Cliquez sur l’utilisateur et vérifiez l’entrée Comportement d’appel. Cela devrait être « Appel dans Webex ».

  4. Cliquez sur l nom d’utilisateur pour ouvrir l’écran Détails de l’utilisateur.

  5. Faites défiler pour trouver la section des droits et vérifiez quebroadworks-connector est inclus.


    Un utilisateur de Webex pour BroadWorks ne doit PAS avoir le droit bc-sp-standard s’il prévoit d’utiliser Webex pour BroadWorks. Ceci est le droit pour « Webex Calling (Broadcloud) » qui est l’appel de l’application Webex via un service d’appel géré par Cisco sur le Cloud.

Vérifier le comportement des appels de l’organisation

  1. Connectez-vous à Bureau d’assistance (https://admin.webex.com/helpdesk) avec vos identifiants d’administrateur partenaire.

  2. Rechercher l’organisation.

  3. Cliquez sur l’organisation et vérifiez l’entrée Comportement d’appel. Cela devrait être « Appel dans Webex ».

Analysez PSLog pour les problèmes de provisioning des utilisateurs

Utilisez le PSLog du serveur d’applications pour voir la requête HTTP POST vers le pont de provisioning et la réponse de Webex.

Dans un cas de travail correct, la réponse est 200 OK et après quelques minutes vous pouvez voir l’utilisateur - et le nouvel organisation client s’il s’agit du premier utilisateur – a été créé dans Webex.

Vous pouvez vérifier ceci en recherchant Bureau d’assistance’adresse électronique que vous voyez dans le POST.

Avant de commencer

Collectez un PSLog du serveur d’application au cours d’une tentative de provisioning de flux avec un utilisateur test.

1

La première chose à vérifier est le code de réponse HTTP :

  • Tout ce qui est autre que 200 OK est un échec de provisioning des utilisateurs.

  • 200 OK peut toujours indiquer un échec si quelque chose concernant le profil de l’abonné ne fonctionne pas dans la partie en haut des services Webex du pont d’approvisionnement.

  • 400 peuvent contenir un nœud de message dans la réponse. Le pont de provisioning n’a pas pu traiter quelque chose dans l’abonnéProfile. Il peut y avoir un problème avec les détails de l’abonné, ou l’incompatibilité avec un paramètre dans le modèle.

  • 401 signifie que les identifiants de provisioning entrés sur l’AS ne correspondent pas à ceux entrés dans le modèle dans le Hub partenaire.

  • 403 peut indiquer un erreur de configuration sur le serveur d’applications. Vérifiez la cible de la demande. ne doit pas être une adresse IP, il doit s’agit de l’URL du pont de provisioning que vous pouvez voir sur votre modèle dans partner hub.

  • 409 indique un conflit entre l’abonné fourniProfile et les données Webex existantes. Il peut y avoir un utilisateur existant avec cette adresse électronique. Vérifiez le message dans la réponse.

2

Vous pouvez également vérifier le POST HTTP d’origine pour trouver les valeurs suspectes qui pourraient causer l’échec du provisioning.

Le POST contient une structure XML du fichier d’abonné. À l’intérieur, les nodes utiles à vérifier sont :

  • bwuserid: Utilisez ceci pour trouver le profil de l’abonné si vous devez le modifier dans BroadWorks.

  • groupe: Si le modèle est en « mode Prestataire de service », il est en bas de page et devient le nom de l’organisation Client que vous voyez dans le Hub partenaire.

  • Fournisseur de service: Si le modèle est en « mode Entreprise », il est en bas de page et devient le nom de l’organisation Client que vous voyez dans le Hub partenaire.

  • Numéro de téléphone principal: Doit exister. Le provisioning échoue sans .

  • courrierélectronique : Devient l’ID utilisateur dans Webex. Doit être valide et unique pour Webex, sinon le provisioning échoue.


 

Ignorer les services qu’il vous a été dit : elle est créée par AS et acceptée mais non utilisée par Webex.

Analysez les journaux XSP pour dépanner la connexion de l’abonné

Ce flux décrit le mode d’authentification BroadWorks. Vous pouvez voir le mode d’authentification sur le modèle BroadWorks, dans Partner Hub. Voir Configurer vos modèles clients danshttps://help.webex.com/en-us/z9gt5j/Webex-for-BroadWorks-Solution-Guide#id_137726.

Le diagramme en échelle suivant montre l’interaction entre l’utilisateur, le client, les services Webex et le système BroadWorks, lorsque l’utilisateur fait l’authentification BroadWorks dans l’application Webex. De plus, la connexion entre Webex et le XSP est sécurisée par MTLS.

La discussion qui suit explique ce que vous pouvez voir lorsque vous enquêtez sur les journaux pour une connexion réussie.

Figure 1. Authentification BroadWorks et configuration du périphérique

L’utilisateur interagit avec le client, le client interagit avec les services Webex :

  • L’utilisateur fournit son adresse électronique à l’application Webex (1 en diagramme).

  • CI sait qu’il faut rediriger cet utilisateur pour saisir son mot de passe BroadWorks (via UAP) (2 dans le diagramme).

  • Le proxy IDP envoie une demande de profil à l’interface Xsi sur le XSP.

Dans la access_log :

  • Recherchez la demande GET pour le profil de l’abonné, de Webex vers l’interface Xsi-Actions (2.1 dans le diagramme). Il y a le ID utilisateur Webex. P. ex.

    OBTENIR /com.broadsoft.xsi-actions/v2.0/user/webexuserid@example.com/profile

Dans le XsiActionsLog :

  • Recherchez la demande get profil de Webex (2.1 dans le diagramme). Il y a le ID utilisateur Webex. P. ex.

    OBTENIR /com.broadsoft.xsi-actions/v2.0/user/webexuserid@example.com/profile

    Les en-têtes incluent l’autorisation : Agent de base et utilisateur : broadworksÉteamsclient

  • Le XSP fait ensuite l’authentification de base OCI-P contre BroadWorks (AuthenticationVerifyRequest et AuthenticationVerifyResponse, comme toute autre application authentification de base via Xsi) et également un UserGetRequest et ServiceProviderGetRequest pour collecter les informations de l’abonné.

  • La réponse Xsi à Webex contient un bloc de profil XML contenant l’userId (BroadWorks) et d’autres détails (2.2 dans le diagramme).

Interactions avec les clients et les services Webex :

  • Le proxy IDP correspond Profil d’utilisateur de BroadWorks et des problèmes d’assertion SAML au client (2.3 dans le diagramme)

  • Les clients échangent l’assertion SAML pour un jeton CI (3 en diagramme)

  • Le client vérifie que l’utilisateur connecté a le droit broadworks-connector (4 dans le diagramme). Vous pouvez vérifier les droits des utilisateurs dans Bureau d’assistance)

  • Le client utilise le jeton CI pour demander un jeton Web JSON (JWT) sur le proxy IDP (5 dans le diagramme)

  • Le proxy IDP valide le jeton CI à IC

  • Le proxy IDP demande JWT du service d’authentification

Dans le journal authentificationService :

  • Recherchez la demande de jeton de Webex (5.2 dans le diagramme), par exemple :

    OBTENIR /authService/jeton

    qui a http_bw_userid en-tête et autres personnes.

  • Le XSP fait OCI-P UserGetLoginInfoRequest , pour valider que l’id utilisateur fourni correspond à un utilisateur de BroadWorks (5.3 dans le diagramme). AuthService a établi un confiance avec Webex en vertu de la connexion mTLS, de sorte que peut émettre LLT.

  • Recherchez la réponse (5.4 dans le diagramme) de LongLivedTokenManager - Généré par le jeton, objet : bwksUserId@example.com, émetteur : BroadWorks...

    et StatusCode=200 que vous pouvez associer à la demande initiale en utilisant le trackingid : CLIENT... En-tête.

Dans le XsiActionsLog :

  • Le client est maintenant en mesure de présenter le jeton de long-pouvoir à l’interface Xsi-Actions pour obtenir le profil de son périphérique (6 dans le diagramme). P. ex.:

    GET /com.broadsoft.xsi-actions/v2.0/user/bwksUserId%40example.com/profile/device

    Avec l’autorisation des en-têtes : Jeton d’ours et agent utilisateur : WebexTeams(variante/version)

  • L’interface Xsi-Actions posait le jeton sur le service authservice (configuré pour se trouver sur l’interface de boucle), par exemple : 127.0.0.1:80 POST http://127.0.0.1:80/authService/token

    que vous pouvez corréler avec le trackingid : CLIENT... en-tête dans le GET et leX-BROADSOFT-CORRELATION-ID : CLIENT... en-tête dans le POST .

Dans le journal authentificationService :

  • La réception du POST de Xsi (boucle)

  • Un Code de statut=200 retour à Xsi

  • Et une réponse de validation de jeton, avoir un bloc « jeton » JSON dans le corps.

  • Lié(s) en utilisant l’id de suivi : Client...

Dans le XsiActionsLog :

  • Après avoir reçu 200 OK d’authservice, qui validait le jeton du client, l’application Xsi-Actions envoie maintenant une demande OCI-P pour UserPrimaryAndSCADeviceGetListRequest

  • Reçoit la réponse OCI-P UserPrimaryAndSCADeviceGetListResponse contenant lastructure accessDeviceTable XML.

  • La réponse OCI-P est encodée en tant que réponse Xsi au client, incluant la structure AccessDevices XML, qui a le périphériqueTypes par exemple Business Communicator – PC et les URL où le client peut récupérer les fichiers de configuration du périphérique.

Le client continue normalement :

  • Sélectionne une entrée de périphérique et interagit avec DMS pour obtenir le profil du périphérique (6 en diagramme)

  • S’enregistre dans BroadWorks via SBC récupéré dans la configuration à partir de DMS (7 dans le diagramme)