Merci pour votre commentaire.

Cet article est destiné à l'équipe de support technique des fournisseurs de services qui subvient à ses besoins et à ceux de ses clients. Ils devraient être familiarisés avec le dépannage général, la lecture des journaux et le traitement des dossiers des abonnés.

Cet article est divisé en trois sections principales :

• Ressources : fournit une liste d'outils, de matériel de lecture, de journaux et de contacts dont vous pourriez avoir besoin.
• Processus : décrit certaines des mesures que vous pouvez prendre pour résoudre un problème client.
• Problèmes spécifiques : classe et répertorie les problèmes connus, comment les détecter et comment vous pouvez les résoudre.

Fichiers journaux utiles

Liste de lecture

• Portail de connaissances des partenaires Webex pour Cisco BroadWorks
• Guide de configuration de la plateforme XSP (R23)
• Guide de gestion du logiciel BroadWorks (R23)
• Guide de configuration de la gestion des appareils Cisco BroadWorks (R23)
• Guide d'administration de l'interface de ligne de commande Broadworks Xsp
• Description des fonctionnalités du jeton d'authentification à longue durée de vie, version 23.0
• Guide d'intégration de l'authentification SAML, R23
• Guide des options de support SSL Cisco BroadWorks
• Description des fonctionnalités de support Cisco CI
• Serveur de notifications push (description des fonctionnalités)
• Description de la fonctionnalité Support des notifications push pour les appels, version 22.0
• Procédure de migration de Connect (Android) vers Firebase
• Description des fonctionnalités Cisco BroadWorks Storage of Device Tokens pour les notifications push, version 22.0
• Planificateur des capacités du système Cisco Broadworks (feuille de calcul)
• Guide de dimensionnement de la plateforme Cisco BroadWorks
• Guide d'ingénierie du système Cisco Broadworks
• Document relatif aux exigences de prise en charge de l'authentification CI, version 1.0 MR-7136

Problèmes connus et limites

L'article Problèmes et limites connus contient des informations actualisées sur les problèmes connus que nous avons identifiés dans la solution Webex pour BroadWorks.

Connecteur de facilité d'entretien

Le service Webex Serviceability permet au personnel d'assistance technique de Cisco de diagnostiquer plus rapidement les problèmes liés à l'infrastructure. Il automatise les tâches de recherche, de récupération et de stockage des journaux de diagnostic et des informations relatives à un cas de SR. Le service déclenche également une analyse par rapport à des signatures diagnostiques afin que le TAC puisse identifier et résoudre plus efficacement les problèmes liés à votre équipement sur site.

Pour plus de détails sur la manière de déployer le connecteur Serviceability, consultez le Guide de déploiement du connecteur Cisco Webex Serviceability.

Intensification d'un problème

Après avoir suivi certains conseils de dépannage, vous devriez avoir une idée raisonnable de l'origine du problème.

Procédure

1. Collectez le plus d'informations possible auprès des systèmes liés au problème.
2. Contactez l'équipe appropriée de Cisco pour ouvrir un dossier.

Quelles informations sur les clients collecter

Si vous pensez devoir ouvrir un dossier ou signaler un problème, collectez les informations suivantes lors du dépannage avec l'utilisateur :

• Identifiant utilisateur : adresse e-mail CI ou UUID utilisateur (il s'agit de l'identifiant Webex, mais si vous obtenez également l'identifiant BroadWorks de l'utilisateur, incluez-le dans les détails de la coque).
• Identifiant de l'organisation.
• Période approximative pendant laquelle le problème est survenu.
• Plateforme et version clientes.
• Envoyez ou collectez des journaux auprès du client.
• Enregistrez le numéro de suivi s'il figure sur le client.

Vérifiez les informations des utilisateurs dans le service d'assistance

Les administrateurs partenaires qui ont le rôle d'administrateur du service d'assistance (de base ou avancé) peuvent suivre cette procédure pour vérifier les informations des utilisateurs en mode Help Desk.

Procédure

1. Connectez-vous au service d'assistance.
2. Recherchez l'utilisateur, puis cliquez sur celui-ci. Cela ouvre l'écran récapitulatif des utilisateurs.
3. Cliquez sur le nom d'utilisateur pour voir la configuration utilisateur détaillée. Les informations utiles de cette vue incluent l'UUID de l'utilisateur, le cluster Common Identity (CI), le cluster Webex App, le comportement d'appel, le GUID du compte BroadWorks
4. Cliquez sur Copier si vous devez utiliser ces informations dans un autre outil, ou les joindre à un boîtier Cisco.

Afficher l'organisation des clients dans le Help Desk

Les administrateurs partenaires dotés du rôle d'administrateur du service d'assistance (de base ou avancé) peuvent utiliser cette procédure pour consulter les informations relatives à l'organisation du client dans la vue Help Desk.

Procédure

1. Connectez-vous au service d'assistance.
2. Recherchez et cliquez sur le nom de l'organisation cliente.
3. Faites défiler la page vers le bas jusqu'à l'affichage du portail client, puis cliquez sur Afficher le nom du client pour voir une vue en lecture seule de l'organisation client, y compris les utilisateurs et la configuration.

Récupérer les journaux des utilisateurs depuis Partner Hub

Lorsque vous résolvez des problèmes liés aux ordinateurs de bureau et aux clients mobiles, il est important que les partenaires (et le TAC) puissent consulter les journaux des clients.

Procédure

1. Demandez à l'utilisateur d'envoyer des journaux. Pour obtenir de l'aide, voir : Application Webex | Signaler un problème.
2. Demandez à l'utilisateur d'exporter l'environnement d'appel et de vous envoyer le fichier ced.dat.
3. Consultez les journaux des clients sur Partner Hub ou Help Desk.

   Option Partner Hub :

   1. Connectez-vous au Partner Hub et recherchez l'organisation client de l'utilisateur.
   2. Sélectionnez Résolution des problèmes.
   3. Sélectionnez Journaux.
   4. Recherchez l'utilisateur (par e-mail).
   5. Consultez et téléchargez les journaux des clients sous forme de fichier zip.

   Option du service d'assistance :

   1. Connectez-vous au service d'assistance.
   2. Recherchez l'organisation.
   3. Cliquez sur l'organisation (ouvre l'écran de résumé).
   4. Faites défiler la page vers le bas pour cliquer sur Voir le client.
   5. Sélectionnez Résolution des problèmes.
   6. Sélectionnez Journaux.
   7. Recherchez l'utilisateur (par e-mail).
   8. Consultez et téléchargez les journaux des clients sous forme de fichier zip.

Comment trouver la version client

Procédure

1. Partagez ce lien avec l'utilisateur : https://help.webex.com/njpf8r5
2. Demandez à l'utilisateur de vous envoyer le numéro de version.

Vérification du service d'appels par le client

Procédure

1. Connectez-vous au client Webex.
2. Vérifiez que l'icône des options d'appel (un appareil surmonté d'un engrenage) est présente dans la barre latérale. Si l'icône n'est pas présente, l'utilisateur n'a peut-être pas encore accès au service d'appel de Control Hub.
3. Ouvrez le menu Paramètres/Préférences et accédez à la section Services téléphoniques. Vous devriez voir le statut de la session SSO. Vous êtes connectée. (Si un autre service téléphonique, tel queWebex Calling, est affiché, l'utilisateur n'utilise pas Webex pour Cisco BroadWorks.)

   Cette vérification signifie :

   • Le client a utilisé avec succès les microservices Webex requis.
   • L'utilisateur s'est authentifié avec succès.
   • Le client reçoit un jeton Web JSON à longue durée de vie par votre système BroadWorks.
   • Le client a récupéré le profil de son appareil et s'est inscrit sur BroadWorks.

Consultez les journaux des clients ou leurs 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 des journaux. Pour obtenir de l'aide, voir : Application Webex | Signaler un problème.
• Demandez aux utilisateurs de clients mobiles d'envoyer des journaux, puis vous pourrez les obtenir via Partner Hub ou Help Desk.
  Send Logs est muet. Cependant, si un utilisateur envoie des commentaires, ceux-ci sont transmis à l'équipe DevOps de l'application Webex. Veillez à enregistrer le numéro de commentaire de l'utilisateur si vous souhaitez faire un suivi auprès de Cisco. Par exemple :

  

Obtenir des données sur l'environnement d'appel

Les journaux des clients Webex sont fortement expurgés pour supprimer les informations personnelles identifiables. Vous devriez exporter les données de l'environnement d'appel depuis le client au cours de la même session que vous remarquez le problème.

Procédure

1. Sur le client, cliquez sur Aide > Health Checker.
2. Sélectionnez Réinitialiser la base de données. Cela déclenche une réinitialisation complète du client et charge l'écran de connexion de l'application Webex.

Vérifiez que Webex doit s'enregistrer auprès de BroadWorks

L'application Webex vérifie les informations suivantes pour déterminer si vous souhaitez vous inscrire à BroadWorks :

• Droit des utilisateurs à Broadworks-Connector.
• Comportement des appels pour l'organisation et l'utilisateur.

Vérifier le comportement d'appel d'un utilisateur et ses droits au connecteur

1. Connectez-vous au Help Desk à l'aide des informations d'identification de l'administrateur de votre partenaire.
2. Recherchez l'utilisateur.
3. Cliquez sur l'utilisateur et vérifiez l'entrée Comportement d'appel. Ça devrait être « Calling in Webex ».

   

4. Cliquez sur le nom d'utilisateur pour ouvrir l'écran Informations sur l'utilisateur.
5. Faites défiler la page vers le bas pour accéder à la section des droits et vérifiez que le connecteur Broadworks est inclus

   

   Un utilisateur de Webex pour Cisco BroadWorks ne devrait pas avoir le droit bc-sp-standard s'il a l'intention d'utiliser Webex pour Cisco BroadWorks. C'est le droit à « Webex Calling (Broadcloud) », qui est l'application Webex qui appelle via un service d'appels dans le cloud géré par Cisco.

Vérifiez le comportement d'appel de l'organisation

1. Connectez-vous au Help Desk à l'aide des informations d'identification de l'administrateur de votre partenaire.
2. Recherchez l'organisation.
3. Cliquez sur l'organisation et vérifiez l'entrée Comportement d'appel. Ça devrait être « Calling in Webex ».

Analyser PSLog pour détecter les problèmes d'approvisionnement des utilisateurs

Utilisez le PSLog du serveur d'applications pour voir la requête HTTP POST adressée au pont d'approvisionnement et la réponse de Webex. Dans un cas de fonctionnement correct, la réponse est 200 OK et au bout de quelques minutes, vous pouvez voir que l'utilisateur, et la nouvelle organisation client s'il s'agit du premier utilisateur, a été créée dans Webex. Vous pouvez le vérifier en consultant le service d'assistance pour trouver l'adresse e-mail que vous voyez dans le POST.

Avant de commencer

Collectez un PSLog sur le serveur d'applications lors d'une tentative de provisionnement direct avec un utilisateur test.

Procédure

1. Vérifiez d'abord le code de réponse HTTP :
   • Tout résultat autre que 200 OK est un échec de provisionnement des utilisateurs.
   • 200 OK peut tout de même indiquer un échec si le profil de l'abonné ne fonctionne pas dans les services Webex en amont du pont d'approvisionnement.
   • 400 peut contenir un nœud de message dans la réponse. Le pont d'approvisionnement n'a pas pu traiter quelque chose dans le profil de l'abonné. Il y a peut-être un problème avec les informations de l'abonné ou une incompatibilité avec un paramètre du modèle.
   • 401 signifie que les informations d'approvisionnement saisies sur l'AS ne correspondent pas à celles saisies sur le modèle de Partner Hub.
   • 403 peut indiquer une erreur de configuration sur le serveur d'applications. Vérifiez la cible de la demande. Il ne doit pas s'agir d'une adresse IP, mais de l'URL du pont d'approvisionnement que vous pouvez voir sur votre modèle dans Partner Hub.
   • 409 indique un conflit entre le profil d'abonné fourni et les données Webex existantes. Il se peut qu'un utilisateur possède déjà cette adresse e-mail. Vérifiez le message dans la réponse.
2. Vous pouvez également consulter le HTTP POST d'origine pour détecter toute valeur suspecte susceptible d'entraîner un échec de l' approvisionnement. Le POST contient une structure XML SubscriberProfile. À l'intérieur, les nœuds utiles à vérifier sont les suivants :
   • bwuserid : Utilisez-le pour trouver le profil de l'abonné si vous devez le modifier dans BroadWorks.
   • groupe : Si le modèle est en « mode fournisseur de services », il est en minuscules et devient le nom de l'organisation cliente que vous voyez dans Partner Hub.
   • ServiceProvider : Si le modèle est en « mode entreprise », il est mis en minuscules et devient le nom de l'organisation cliente que vous voyez dans Partner Hub.
   • Numéro de téléphone principal : doit exister. L'approvisionnement échoue sans cela.
   • e-mail : devient le nom d'utilisateur dans Webex. Doit être valide et propre à Webex, sinon le provisionnement échouera.

     Ignorez la strophe des services : elle est créée par AS et acceptée mais pas utilisée par Webex.

Analysez les journaux XSP pour résoudre les problèmes de connexion des abonnés

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

Le diagramme suivant montre l'interaction entre l'utilisateur, le client, les services Webex et le système BroadWorks, lorsque l'utilisateur s'authentifie 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 à quoi vous pouvez vous attendre lorsque vous examinez les journaux pour une connexion réussie.

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

• L'utilisateur fournit son adresse e-mail à l'application Webex (1 sur le schéma).
• CI sait qu'il faut rediriger cet utilisateur pour qu'il saisisse son mot de passe BroadWorks (via UAP) (2 sur le schéma).
• Le proxy IDP envoie une demande d'accès au profil sur l'interface Xsi du XSP.

Dans le tomcat access_log :

• Recherchez la requête GET pour le profil de l'abonné, depuis Webex vers l'interface Xsi-Actions (2.1 dans le schéma). Il possède le nom d'utilisateur Webex. Par exemple :

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

Dans le journal des actions XSI :

• Recherchez la demande GET de profil de Webex (2.1 dans le schéma). Il possède le nom d'utilisateur Webex. Par exemple :

  GET /com.broadsoft.xsi-actions/v2.0/user/ webexuserid@example.com /profile Les en-têtes incluent l'autorisation : Basic et l'agent utilisateur : BroadworkSteamsClient

• Le XSP effectue ensuite l'authentification OCI-P Basic par rapport à BroadWorks (AuthenticationVerifyRequest et AuthenticationVerifyResponse, comme toute autre application effectuant une authentification de base via Xsi) et utilise également UserGetRequest et ServiceProviderGetRequest pour recueillir les informations sur les abonnés.
• La réponse Xsi à Webex contient un bloc de profil XML contenant l'identifiant utilisateur (BroadWorks) et d'autres informations (2.2 dans le schéma).

Interactions entre les clients et les services Webex :

• Le proxy IDP correspond au profil utilisateur reçu de BroadWorks et envoie une assertion SAML au client (2.3 dans le schéma).
• Le client échange une assertion SAML contre un jeton CI (3 sur le schéma).
• Le client vérifie que l'utilisateur connecté possède les droits Broadworks Connector (4 sur le schéma). Vous pouvez vérifier les droits des utilisateurs dans le Help Desk.
• Le client utilise un jeton CI pour demander un jeton Web JSON (JWT) auprès du proxy IDP (5 sur le schéma).
• Le proxy IDP valide le jeton CI au CI.
• Le proxy IDP demande JWT au service d'authentification.

Dans le journal AuthenticationService :

• Recherchez la demande de jeton émanant de Webex (5.2 dans le schéma), par exemple : GET /AuthService/Token qui contient l'en-tête http_bw_userid et d'autres.
• Le XSP utilise OCI-P UserGetLoginInfoRequest, pour vérifier que l'identifiant utilisateur fourni correspond à un utilisateur BroadWorks (5.3 dans le schéma). AuthService a établi une relation de confiance avec Webex grâce à la connexion mTLS. Elle peut donc émettre LLT.
• Recherchez la réponse (5,4 dans le schéma) de LongLivedTokenManager : Token generated, sujet : bwksUserId@example.com, émetteur : BroadWorks... et StatusCode=200 que vous pouvez associer à la demande initiale à l'aide de l'en-tête trackingid : CLIENT...

Dans le journal des actions XSI :

• Le client est en mesure de présenter le jeton à longue durée de vie sur l'interface Xsi-Actions pour obtenir le profil de son appareil (6 sur le schéma). Par exemple : GET /com.broadsoft.XSI-Actions/v2.0/user/BWKsUserId %40example.com/profile/device Avec autorisation des en-têtes : jeton du porteur et agent utilisateur : WebExTeams (variante/version)
• L'interface Xsi-Actions envoie le jeton au service d'authentification (configuré pour être intégré à l'interface de bouclage) Par exemple : 127.0.0. 1:80 POST http://127.0.0.1:80/authService/token que vous pouvez mettre en corrélation avec l'en-tête trackingid : CLIENT... dans le GET et l'en-tête X-BROADSOFT-CORRELATION-ID : CLIENT... dans le POST.

Dans le journal AuthenticationService :

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

• Un code d'état = 200 pour revenir à Xsi

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

• Corrélé à l'aide de l'identifiant de suivi : CLIENT...

Dans le journal des actions XSI :

• Après avoir reçu 200 OK du service d'authentification, qui a validé le jeton du client, l'application Xsi-Actions envoie désormais des requêtes OCI-P pour UserPrimary et SCADeviceGetListRequest
• Reçoit OCI-P UserPrimary et SCADeviceGetListResponse contenant la structure XML AccessDeviceTable.
• La réponse OCI-P est codée sous forme de réponse Xsi au client, y compris la structure XML AccessDevices, qui contient les DeviceTypes. Par exemple : Business Communicator — PC et les URL où le client peut récupérer les fichiers de configuration de l'appareil.

Le client continue comme d'habitude :

• Sélectionne une entrée d'appareil et interagit avec DMS pour obtenir le profil de l'appareil (6 sur le schéma).
• Les registres de BroadWorks via SBC ont été récupérés dans la configuration auprès de DMS (7 sur le schéma).

Problèmes liés au Partner Hub

1. L'administrateur ne peut pas voir les organisations clientes

En tant qu'administrateur de votre organisation partenaire sur Webex, vous devriez avoir le rôle d'administrateur à part entière. Ce rôle est utilisé pour gérer votre organisation partenaire, y compris pour vous attribuer des privilèges administratifs à vous-même et à d'autres personnes. Pour gérer les organisations de clients, vous devez vous attribuer (ou attribuer à d'autres personnes) le rôle d'administrateur complet des ventes ou le rôle d'administrateur des ventes. Pour plus de détails, voir Attribuer des rôles aux comptes de l'organisation dans Control Hub.

Problèmes de provisionnement pour les utilisateurs

1. Erreurs IM&P intégrées pour des entreprises/clients spécifiques

Si plusieurs entreprises utilisent différents services de collaboration dans le cloud, par exemple UC-One SaaS et Webex pour Cisco BroadWorks, vous avez peut-être choisi de modifier l'adaptateur d'approvisionnement par entreprise.

Pour vérifier ce qui est configuré pour Integrated IM&P (par défaut pour les entreprises, sauf si un paramètre plus spécifique existe), exécutez AS_CLI/Interface/Messaging> get. Pour les paramètres d'approvisionnement d'une entreprise en particulier, ouvrez l'entreprise et accédez à Services > Integrated IM&P.

Vérifiez que la configuration IM&P intégrée de cette entreprise correspond exactement à ce qui est indiqué dans le modèle client de Partner Hub. Les paramètres suivants doivent correspondre, sinon le provisionnement échoue pour tous les utilisateurs de l'entreprise :

2. Erreurs IM&P intégrées pour des utilisateurs spécifiques

Cela s'applique si vous utilisez le provisionnement direct, et en supposant que le provisionnement fonctionne pour certains utilisateurs ou pour la plupart des utilisateurs (vous pouvez donc exclure tout problème de configuration). Si vous rencontrez des erreurs IM&P intégrées dans BroadWorks, par exemple « [Erreur 18215] Erreur d'approvisionnement avec le serveur de messagerie » et « [Erreur 18211] Erreur de communication avec le serveur de messagerie », vous devriez rechercher les causes potentielles suivantes :

• L'adresse e-mail de l'utilisateur existe peut-être déjà CI. Recherchez l'utilisateur dans le service d'assistance pour vérifier si son adresse e-mail y figure déjà. Ce n'est pas nécessairement concluant, car l'utilisateur fait peut-être partie d'une organisation dont vous n'êtes pas autorisée à consulter les données dans le service d'assistance.
• L'utilisateur s'est inscrit indépendamment à Webex, avant de se voir attribuer le service IM&P intégré. Dans ce cas, l'une des options est de demander à l'utilisateur de supprimer ses comptes gratuits afin qu'il puisse intégrer l'organisation client que vous approvisionnez. Les instructions se trouvent sur https://help.webex.com/5m4i4y
• L'utilisateur n'a pas de numéro de téléphone principal associé à son profil (tous les abonnés à Webex pour Cisco BroadWorks doivent avoir un DID principal). Voir la rubrique sur l'analyse de PSLog depuis AS.

3. Échecs de provisionnement des utilisateurs en réponse à Provisioning Bridge

Si les utilisateurs n'apparaissent pas dans Control Hub, quelques minutes après avoir assigné Integrated IM&P, jetez un œil aux codes de réponse du service de passerelle d'approvisionnement. Lancez un PSLog pour consulter les codes de réponse HTTP.

200 OK

Une réponse 200 OK ne signifie pas que l'utilisateur est correctement configuré. Cela signifie que le service d'approvisionnement a reçu la demande et a soumis avec succès la demande de création d'utilisateur correspondante aux services en amont. La transaction d'approvisionnement est conçue de manière asynchrone. Le service répond 200 OK parce que le processus de création d'utilisateur peut prendre plusieurs minutes et, pour des raisons de performances, nous ne voulons pas recevoir plusieurs demandes pour créer le même utilisateur. Cependant, si l'utilisateur n'apparaît pas dans l'organisation cliente après avoir reçu 200 OK, cela peut indiquer que sa création a échoué dans les services Webex en amont du service d'approvisionnement. Vous devez signaler un échec d'approvisionnement qui reçoit une réponse OK de 200.

400 mauvaises demandes

Consultez la réponse HTTP qui devrait contenir plus de détails sur les problèmes potentiels qui pourraient être à l'origine de cette réponse de la part du service d'approvisionnement. Quelques exemples de nœud :

• « Je ne peux pas faire confiance à BroadWorks Email avec l'ancienne API d'approvisionnement. » L'adresse e-mail associée à l'échec de la demande d'approvisionnement de l'utilisateur n'est pas valide ou a été mal saisie, mais vous avez indiqué dans le modèle que les adresses e-mail étaient fiables. Consultez les profils des utilisateurs dans BroadWorks, en particulier leur adresse e-mail.
• L'organisation cliente est introuvable dans la base de données et l'indicateur de création d'une nouvelle organisation n'est pas activé. » L'échec de cette demande d'approvisionnement devrait créer une nouvelle organisation cliente dans Webex, mais votre modèle est configuré pour empêcher la création de nouvelles organisations clientes. Si vous souhaitez autoriser de nouvelles organisations, pour des domaines de messagerie qui ne correspondent pas à des clients existants sur Webex, vous pouvez reconfigurer votre modèle dans Partner Hub et retester la demande d'approvisionnement. Cependant, si vous ne vous attendez pas à ce qu'une nouvelle organisation soit créée pour cet utilisateur, c'est peut-être que l'adresse e-mail a été mal saisie (en particulier la partie domaine). Vérifiez l'adresse e-mail de l'utilisateur dans BroadWorks.

403 Interdit

La demande d'approvisionnement ne peut aboutir tant que vous n'avez pas corrigé la configuration. Dans ce cas, vous devrez examiner la demande et la réponse. Par exemple, si vous voyez une adresse IP comme cible de la demande de provisioning, au lieu de l'URL du pont de provisioning appropriée pour votre organisation (voir les rubriques relatives à la configuration du pare-feu dans le Guide des solutions), cela peut indiquer qu'il ne manque pas le correctif requis sur votre serveur d'applications (ap373197).

Vérifiez que tous les correctifs requis sont appliqués au serveur d'applications et que vous avez effectué la configuration correspondante pour un provisionnement continu réussi.

409 Conflits

La demande d'approvisionnement ne peut pas être traitée car Webex possède déjà un utilisateur qui correspond à l'adresse e-mail indiquée dans la demande.

4. Utilisateur déjà inscrit à CI

Récupérez l'e-mail de l'abonné à partir de la requête HTTP POST et recherchez-le dans le Help Desk. Vous ne verrez peut-être pas l'utilisateur si vous n'y êtes pas autorisée, mais vous pouvez aussi constater qu'il fait partie d'une organisation « libre », par exemple « Consommateur ». Vous pouvez demander à cet utilisateur de supprimer son compte gratuit, ou vous pouvez utiliser une autre adresse e-mail pour le configurer. Voir https://help.webex.com/ndta402.

Problèmes de connexion des utilisateurs

1. Le portail d'activation utilisateur ne se charge pas

Le flux de connexion normal de Webex pour Cisco BroadWorks inclut un portail d'activation utilisateur où les utilisateurs saisissent leur mot de passe. Parfois, ce portail ne se charge pas une fois que l'utilisateur a fourni son adresse e-mail sur l'écran de connexion de l'application Webex. Ce problème peut être dû au client ou au service. Du côté client, cela est généralement dû au fait que le navigateur natif du client est incompatible d'une manière ou d'une autre avec le service.

2. Échec de l'authentification unique

• Dans BroadWorks, vérifiez que les types d'appareils pour l'application Webex ont été attribués à l'utilisateur (voir la section Profils des appareils dans la section Préparez votre environnement du Guide des solutions).
• Vérifiez que l'utilisateur utilise le bon mot de passe. Si le modèle que vous avez utilisé pour approvisionner l'organisation cliente de l'utilisateur (dans Partner Hub) est configuré pour l' authentification BroadWorks, l'utilisateur doit saisir son mot de passe « Web Access » BroadWorks. L' utilisateur devra peut-être également saisir son nom d'utilisateur BroadWorks si son adresse e-mail n'est pas configurée comme identifiant utilisateur alternatif. Assurez-vous que l'utilisateur a correctement saisi des majuscules et des minuscules.

Problèmes de configuration et d'enregistrement des appels

Une fois qu'un utilisateur a été configuré dans Webex et qu'il s'est connecté avec succès à l'application Webex, l'application s'enregistre auprès de BroadWorks. Voici la séquence d'enregistrement attendue et les signes d'un enregistrement sain qui en résultent (comme le montre l'application Webex) :

1. Séquence d'inscription attendue

1. Le client appelle XSI pour obtenir un jeton de gestion de l'appareil et l'URL du DMS.
2. Le client demande le profil de son appareil à DMS en présentant le jeton de l'étape 1.
3. Le client lit le profil de l'appareil et récupère les informations d'identification, les adresses et les ports SIP.
4. Le client envoie un SIP REGISTER à SBC en utilisant les informations de l'étape 3.
5. Le SBC envoie le SIP REGISTER à l'AS (SBC peut effectuer une recherche dans le NS pour localiser un AS si SBC ne connaît pas déjà l'utilisateur SIP.).

2. Signes attendus d'une inscription réussie des clients

L'icône des options d'appel apparaît dans l'interface Webex.

Dans l'onglet des services téléphoniques de l'application Webex (par exemple Paramètres > Services téléphoniques sous Windows, Préférences > Services téléphoniques sur Mac), le message « Session SSO : vous êtes connectée » signifie que l'application s'est correctement enregistrée (pour BroadWorks dans ce cas).

3. Le client n'a pas d'icône d'appel

La plupart du temps, cela signifie que l'utilisateur ne possède pas la licence ou les droits appropriés.

Cette inscription a échoué. Les raisons pour lesquelles un client Webex App échoue à s'enregistrer auprès de BroadWorks sont multiples :

4. Plusieurs services d'appels sont testés auprès des mêmes clients

Ce problème connu peut être dû au fait que le client passe d'un backend d'appel à un autre. Cela se produit probablement lors des essais de différents services d'appel proposés via (les mêmes) clients de l'application Webex. Vous pouvez réinitialiser la base de données clients (lien) pour remédier à ce problème.

5. Mauvaise configuration du service d'authentification

Vérifiez le ou les XSP hébergeant le service d'authentification en consultant le Guide des solutions (voir Configurer les services sur votre Webex pour les XSP Cisco BroadWorks). Plus précisément :

• Les clés RSA (que vous générez sur un XSP) sont copiées sur tous les XSP
• L'URL du service d'authentification a été fournie au conteneur Web de tous les XSP et saisie correctement dans le cluster de Partner Hub
• L'authentification externe par certificats est configurée :

  XSP_CLI/System/CommunicationUtility/DefaultSettings/ExternalAuthentication/CertificateAuthentication>Obtenir

  allowUserApp = false

  allowClientApp = true

• Lorsque vous utilisez MTLS, vous devez télécharger le certificat du client Webex sur les xSP (vous pouvez l'obtenir sur Partner Hub, sur la page des paramètres de BroadWorks).

6. Mauvaise configuration des balises BroadWorks

Vérifiez que vous avez configuré les balises BroadWorks requises pour l'application Webex. Consultez le guide de configuration Webex pour Cisco BroadWorks pour plus d'informations sur les balises de configuration. Assurez-vous qu'il n'y a pas de conflits ou de valeurs incorrectes. Plus précisément, le tag %SBC_ADDRESS_WXT% doit être le SBC vers votre bureau d'enregistrement SIP pour les clients Webex App.

7. Un client de bureau déconnecte les services téléphoniques une fois la connexion SSO réussie

Ce problème peut être dû au fait que le même utilisateur se connecte à plusieurs clients sur le même type de plateforme. Par exemple, si un utilisateur se connecte avec succès à l'application Webex sur Windows, puis se connecte à l'application Webex sur une autre machine Windows, il n'y a qu'une session SSO active sur l'une des machines. C'est intentionnel. Si vous devez absolument contourner ce problème, vous pouvez configurer BroadWorks pour qu'il dispose de plusieurs instances du même type d'appareil, mais elles doivent avoir des adresses SIP uniques. Cette configuration dépasse le cadre de Webex pour Cisco BroadWorks.

8. Appareil de bureau non configuré pour l'utilisateur

Cette signature figure dans le journal client :

[0x70000476b000] BroadWorksConfigDownloader.cpp:106 <Error>

OnAccessDeviceListSucceed:BWC:scf : ConfigDownload - le profil de l'appareil « Business Communicator - PC » est introuvable.

9. Les appels entrants sonnent une fois ou il est impossible de répondre

Les appels entrants vers le mobile Webex ne sonnent qu'une seule fois, sinon l'utilisateur ne peut pas répondre à l'appel entrant. Les autres terminaux du même utilisateur peuvent continuer à sonner.

Comment s'identifier ?

Dans les journaux du client mobile Webex, recherchez le code d'erreur XSI 101002 dans le flux d'appels push. Par exemple :

Code de réponse : 400

<callID>HandlePushCallInfoFailure:BWC:Internal : Appel push : état xsi pour CallID : code d'erreur xsi : 101002

<callID>ClosePushCallWithReason:BWC:Internal : Essayez de fermer l'appel push avec id =, reason = CallAbandoned

Cause : Le code d'erreur 101002 peut indiquer que le mauvais serveur d'applications (AS) est renvoyé dans la réponse LocateUser. Cela peut se produire lorsque l'utilisateur a migré vers un système d'exploitation secondaire.

Contrôles recommandés :

Depuis l'ADP ou le XSP où Push est déployé, lancez LocateUser pour l'utilisateur concerné :

<FQDN or IP address of NS Server>curl « http : //:80/Servlet/LocateUser ? <BW userID @domain >URL=&ReturnCompatibleXSP=True&CallPrequest=True »

Exemple : curl « http://1.1.1.1:80/servlet/LocateUser ? url= 9721112222@gmail.com &ReturnCompatibleXSP=True&CallPrequest=true »

Solution : Si LocateUser renvoie l'AS secondaire à l'utilisateur, exécutez le script MigrateUserToDefaultNode.pl sur le serveur NS principal pour rediriger les utilisateurs vers le serveur d'applications principal du cluster.

Connectez-vous au serveur NS via SSH, accédez au répertoire /usr/local/broadworks/bw_base/bin et exécutez : MigrateUserToDefaultNode.pl <hostingNE>

Exemple : MigrateUserToDefaultNode.pl bwas1

Pour obtenir la valeur HostingNE, exécutez : NS_CLI/System/Device/HostingNE> get

Le script vérifie d'abord s'il trouve le NE d'hébergement que vous fournissez en argument. Après avoir vérifié la validité du NE d'hébergement, il met à jour le DN, l'extension et l'URL vers le nœud par défaut de ce NE d'hébergement.

Exécutez le script lorsque c'est possible en période de faible trafic. Cependant, il est généralement acceptable d'exécuter le script à tout moment si nécessaire pour rétablir le service pour les utilisateurs concernés.

Le script ne peut pas être exécuté pour un seul utilisateur. Il migre tous les utilisateurs répertoriés dans la sortie LocateUser. Si vous n'arrivez pas à exécuter le script, supprimez et reconstruisez l'utilisateur concerné dans BroadWorks afin qu'il soit reconstruit sur le bon AS.

Tout message SIP envoyé depuis l'appareil de l'utilisateur vers le système d'exploitation secondaire peut inciter l'utilisateur à migrer. Les utilisateurs reviennent généralement à l'AS principal après l'intervalle de 15 minutes par défaut, sauf si les demandes entrantes continuent d'atteindre le SA secondaire. Par exemple, si le SBC n'arrive pas à se connecter à l'AS1 et qu'il revient à l'AS secondaire, les utilisateurs concernés peuvent passer à l'AS secondaire. Selon le déploiement, un seul groupe ou utilisateur peut rester connecté à l'AS secondaire si le SBC n'arrive toujours pas à atteindre l'AS principal.

Pour plus d'informations, consultez les documents suivants :

• Sections 3.4.5 Capacité de restauration par les utilisateurs des serveurs d'applications et 5.4.5 Guide de restauration automatique dans le guide de redondance Cisco BroadWorks

• Description des fonctionnalités améliorées de Cisco BroadWorks ASR

9. Services téléphoniques déconnectés

Si les services téléphoniques apparaissent comme étant déconnectés une fois que l'utilisateur s'est connecté à l'application Webex, ou si les services téléphoniques se déconnectent alors que l'utilisateur utilise le client, vérifiez le type de client et le flux d'enregistrement.

Pour les clients Windows et Mac, l'application Webex enregistre le SIP et conserve un enregistrement SIP actif tant que l'utilisateur est connecté.

Vérifiez les points suivants :

1. Vérifiez que le fichier config-wxt.xml a bien été téléchargé.

Dans les journaux des clients, recherchez ConfigDownload.

Un téléchargement réussi montre :

ConfigDownload : terminé avec succès

Si les journaux contiennent l'erreur suivante, consultez les journaux AuthService pour détecter les erreurs liées aux jetons :

ConfigDownload : échec avec le code d'erreur 1511

2. Vérifiez que le profil de l'appareil Webex est trouvé.

Dans les journaux des clients, vérifiez que le dispositif d'accès est trouvé et que used_value est égal à 1. Si used_value vaut 0, vérifiez si la ligne principale est activée ou désactivée et vérifiez la valeur de la balise. Pour plus de détails, consultez la section 6.1.44 Profil principal du guide de configuration de Webex pour BroadWorks.

Exemples d'entrées de journal :

:BWC:SCF : ConfigDownload, appareil d'accès trouvé

:BWC:SCF : ConfigDownload - appareil d'accès : DeviceType=Business Communicator - PC, DeviceLevel=Group, AllowTermination=1, IsDeviceOwner [has_value : 0, used_value : 1], HasOwnerDevice : 1, Endpoint Type : Apparence des appels partagés

:BWC:SCF : ConfigDownload - appareil d'accès : DeviceType=Connect - Mobile, DeviceLevel=Group, AllowTermination=1, IsDeviceOwner [has_value : 0, used_value : 1], HasOwnerDevice : 1, Endpoint Type : Apparence des appels partagés

:BWC:SCF : ConfigDownload - appareil d'accès : DeviceType=Connect - Tablet, DeviceLevel=Group, AllowTermination=1, IsDeviceOwner [has_value : 0, used_value : 1], HasOwnerDevice : 1, Endpoint Type : Apparence des appels partagés

3. Vérifiez s'il y a des défaillances DNS lors de la résolution de l'adresse proxy SIP.

Pour plus de détails sur la découverte des proxys SIP, consultez la section 6.1.6 Découverte dynamique des proxys SIP du guide de configuration de Webex pour BroadWorks.

La découverte réussie d'un proxy montre que :

La découverte du proxy est terminée, j'ai obtenu <number>des résultats

4. Vérifiez si l'enregistrement SIP échoue.

Si les journaux indiquent MRegistration : TCPTimeout ou Reason : SIP ; cause=200 ; text="last=TCP-Timeout », le client Webex n'arrive pas à établir de connexion TCP de bas niveau avec le SBC. L'enregistrement SIP ne se termine pas lorsque cette erreur se produit. Vérifiez si le protocole TCP est bloqué sur le réseau de l'utilisateur ou si le SBC rejette la connexion TCP.

Si la demande SIP REGISTER est rejetée ou ne reçoit pas de réponse, recherchez REGISTER sip dans les journaux et vérifiez que SIP/2.0 200 OK est renvoyé. S'il n'est pas renvoyé, vérifiez si le réseau de l'utilisateur bloque le SIP ou si le SBC rejette la demande.

Dans BroadWorks Admin, allez dans Utilisateur > Utilitaires > Enregistrements, et vérifiez qu'un enregistrement SIP valide est présent pour le client Webex.

Pour les clients mobiles Android et iOS, l'application Webex ne s'enregistre pas au SIP tant qu'un appel n'est pas passé ou reçu. L'inscription est supprimée une fois l'appel terminé. Les clients mobiles s'enregistrent pour recevoir des notifications push.

Pour les clients mobiles, vérifiez les points suivants :

1. Vérifiez que config-wxt.xml se télécharge correctement et que le profil de l'appareil est trouvé, comme décrit pour les clients Windows et Mac.

2. Vérifiez que l'enregistrement push est réussi.

Dans les journaux Webex, recherchez l'état de l'enregistrement push :

OnPushRegistrationStateChanged : :État d'enregistrement Push modifié, State=Non enregistré

OnPushRegistrationStateChanged : :État d'enregistrement Push modifié, State=Registered

Dans BroadWorks Admin, allez dans Utilisateur > Utilitaires > Enregistrements par notifications push et vérifiez qu'un enregistrement push valide est présent pour le client Webex.

Paramètres des appels, problèmes de visualisation sur le Web

1. Le bouton/lien Self Care n'apparaît pas dans l'application Webex

Un autre symptôme de ce problème est que le bouton ou le lien s'affiche, mais que le fait de cliquer dessus ouvre un navigateur externe.

• Vérifiez que le modèle de configuration client requis est déployé et que les balises CSW sont correctement définies. (Voir la section Webview des paramètres d'appel dans le guide des solutions Webex pour Cisco BroadWorks).
• Vérifiez que l'application Webex est enregistrée pour les appels dans BroadWorks.
• Vérifiez que l'application Webex est une version récente qui prend en charge le CSWV.

2. Page blanche ou erreur après avoir cliqué sur le bouton/lien Self Care

En général, ce comportement dans l'application Webex indique un problème de configuration ou de déploiement avec l'application CSWV sur BroadWorks XSP. Collectez des informations pour une enquête plus approfondie, y compris les journaux CSWV, les journaux d'accès, le référentiel config-wxt.xml et le fichier modèle, puis soulevez une affaire.

Problèmes de réclamation de domaine

Des erreurs d'enregistrement des utilisateurs peuvent survenir à la suite d'erreurs commises lors de la revendication de domaines. Avant de revendiquer un domaine, assurez-vous de bien comprendre les points suivants :

• Les fournisseurs de services ne devraient pas revendiquer les domaines des organisations clientes qu'ils gèrent. Ils ne devraient revendiquer que les domaines des utilisateurs qui font partie de l'organisation interne du fournisseur de services. Le fait de revendiquer le domaine des utilisateurs au sein d'une organisation distincte (même si elle est gérée par le fournisseur de services) peut entraîner des erreurs d'enregistrement pour les utilisateurs de l'organisation cliente, car les demandes d'authentification des utilisateurs sont acheminées par le fournisseur de services plutôt que par l'organisation cliente.
• Si deux organisations clientes (l'entreprise A et l'entreprise B) partagent le même domaine et que l' entreprise A a revendiqué le domaine, l'enregistrement des utilisateurs de la société B risque d'échouer car les demandes d'authentification des utilisateurs sont acheminées via l'organisation qui détient le domaine revendiqué (société A).

  Si vous revendiquez un domaine par erreur et que vous devez supprimer une demande, consultez l'article Webex sur la gestion de vos domaines.

Codes d'erreur de l'utilisateur final

Le tableau suivant présente les codes d'erreur des utilisateurs finaux qui peuvent être consultés sur le portail d' activation des utilisateurs clients.

Codes d'erreur pour Directory Sync

Les codes d'erreur suivants s'appliquent à Directory Sync.