- Accueil
- /
- Article
Dépanner la qualité média de Webex Calling dans Control Hub
Dans cet articleL’affichage de dépannage dans Webex Calling permet aux administrateurs de dépanner les problèmes de qualité média lors d’un appel Webex. Vous pouvez rechercher des informations relatives à l'appel, afficher ses statistiques média, identifier l'emplacement du problème et résoudre le problème.
Vue d’ensemble
Pour déterminer la cause probable, il est recommandé d’utiliser la vue de dépannage avec les informations agrégées dérivées du tableau de bord Webex Calling Analytics. Utilisez le tableau de bord Webex Calling Analytics pour afficher les problèmes affectant plusieurs utilisateurs et ayant une cause commune liée à l’emplacement, au réseau, etc. ; tandis que l’affichage de dépannage de Webex Calling peut identifier les problèmes liés aux appels individuels.
La fonctionnalité de dépannage de la qualité des médias ne nécessite aucune configuration spécifique et est disponible par défaut dans le Control Hub. Il est disponible pour les administrateurs complets des clients, en lecture seule, de l’assistance, des partenaires et des partenaires en lecture seule.
Les administrateurs peuvent effectuer une recherche à l’aide des critères suivants pour obtenir une liste des appels pour lesquels une session média a été utilisée avec au moins un point de terminaison enregistré dans Webex Calling :
Identifiants de courrier électronique
Numéros de téléphone (correspondance exacte de la chaîne)
Adresse MAC
Identifiants d’appel
Le dépannage de la qualité des médias permet aux administrateurs de :
Afficher l'expérience de bout en bout des participants à l'appel.
Afficher les détails de l’appel.
Afficher si le média traverse le Cloud Webex Calling, ou directement entre les utilisateurs (à l’aide de l’établissement de la connectivité interactive (ICE)).
Afficher Insights, s’il n’y a aucun média dans l’appel, ou lorsque la configuration de l’optimisation du chemin a échoué.
Afficher les appels des 21 derniers jours.
Analysez les mesures de la qualité des appels qui ont eu un impact sur l’expérience de l’utilisateur. Par exemple, un administrateur peut observer une gigue élevée sur les clients sur les réseaux Wi-Fi, mais la perte de paquets et la latence peuvent être acceptables.
Détecter si le problème concerne l’appelant ou l’appelé.
Le dépannage de la qualité des médias s’applique uniquement aux sessions média et il n’affiche pas les sessions de signalisation d’appel. Par exemple, Alex appelle Bob qui a configuré le CFA (Call Forward All) à Christina, et Christina a répondu à l'appel. Dans ce scénario, la vue de dépannage des médias montre que l'appel s'est produit entre Alex et Christina, car l'accent est mis sur le dépannage de l'expérience des médias plutôt que sur le flux de signalisation ou le cycle de vie de l'appel.
Les appels utilisant Webex Calling apparaissent une fois l’appel terminé.
La vue de dépannage permet d'identifier la zone du problème en fournissant toutes les mesures pertinentes et ne peut pas nécessairement vous fournir la cause principale d'un appel médiocre. Examinez ces pointeurs pour identifier divers facteurs et déterminer les options de résolution :
L’expérience de bout en bout de l’utilisateur.
La vue Hop Details.
Envoyer ou recevoir des mesures de l'utilisateur ou du point de relais média.
Que l’appel ait eu lieu vers ou depuis un réseau externe ou entre les points de terminaison enregistrés dans Webex Calling.
Flux d'appels pris en charge
Les rapports de qualité média sont collectés à partir des points de terminaison de l'appelant et de l'appelé et des points de relais média. Cela permet une segmentation de l'expérience média pour affiner et identifier si le problème s'est produit au niveau :
Appelant ou appelé
Chemin média vers ou depuis le Cloud Webex Calling.
Les segments d’appel s’affichent s’il y a eu une session média qui est établie avec au moins un point de terminaison enregistré Webex Calling sur l’appel. Par exemple, pour un appel sortant d'un groupe de recherche vers huit agents, si un seul agent répond, il n'y a pas d'expérience média à dépanner pour les sept autres agents.
Il existe cinq types d’expériences ou de chemins média pour le dépannage de Webex Calling, qui sont :
Optimisé sur le réseau – Appels au sein de l’organisation où ICE réussit et où le média circule directement entre les utilisateurs. Voir Optimisation des médias de Webex Calling avec établissement de la connectivité interactive (ICE) pour des informations détaillées.
Non optimisé sur le réseau – Appels au sein de l’organisation pour lesquels l’établissement de la connectivité interactive (ICE) n’a pas été possible ou établi. Dans ce scénario, les médias transitent par le Cloud d’appel Webex.
Hébergé sur le Cloud sur le réseau – Appels au sein d’une organisation où le média est fourni par un serveur média hébergé dans le Cloud (par exemple, écoute de la messagerie vocale, appel vers un standard automatique).
Appel hors réseau vers ou depuis le point de terminaison enregistré Webex Calling -
via le fournisseur RTCP connecté au Cloud- Appels entrants et sortants d’une organisation où l’autre partie est sur le réseau RTCP. Le média est relayé via un fournisseur RTCP connecté au Cloud (CCPP), via une interconnexion de haute qualité.
via la passerelle locale- Appels entrants et sortants d'une organisation où le média de l'autre partie passe par l'entreprise. Derrière la passerelle locale, la session média peut provenir d’un utilisateur hébergé par l’entreprise (par exemple, enregistré pour le contrôle d’appel dans l’entreprise) ou du RTCP, où le RTCP est fourni par l’entreprise.
S’il y a 1 ou 2 utilisateurs enregistrés de Webex Calling qui sont impliqués dans un appel point à point sur le réseau, la vue de dépannage présente des mesures pour l’une ou les deux parties. Si l’appel est hors réseau (l’utilisateur 1 reçoit un appel d’un utilisateur RTCP), alors la vue de dépannage présente uniquement les mesures du client de l’utilisateur 1, ainsi que les mesures prises à partir du point de relais média.
La plupart des scénarios d'appel de la vue de dépannage montrent deux segments d'appel (appelant et appelé) ; cependant, certains des scénarios d'appel (tels que le parcage d'appel ou la récupération) n'affichent qu'un seul segment d'appel. Dans ce cas, l'autre segment d'appel s'affiche séparément dans la vue de dépannage. Cela n'empêche pas de dépanner l'appel et de détecter l'endroit où le problème s'est produit. Cependant, l’administrateur doit corréler manuellement les deux segments d’appel à l’aide d’une entité commune telle que le temps de chevauchement. Les améliorations futures apportées à la vue de dépannage élimineront la nécessité d'utiliser des recherches manuelles.
Accéder à l’affichage de dépannage de Webex Calling
Pour analyser un appel Webex, procédez comme suit :
| 1 | À partir de la vue client de https://admin.webex.com/, accédez à Surveillance > Dépannage. |
| 2 | Sélectionnez Réunions et appels, puis recherchez l’ID de messagerie électronique de l’utilisateur ou du périphérique, le numéro de téléphone (correspondance exacte de la chaîne), l’adresse MAC de l’utilisateur ou du périphérique, ou les ID d’appel du segment d’appel que vous souhaitez afficher. Affiche les informations pour tous les appels et réunions qui sont associés à la recherche.
L’affichage de la liste affiche l’appel passé à l’aide d’au moins un point de terminaison enregistré dans Webex Calling et ayant une session multimédia. |
| 3 | Les appels Webex Calling sont classés pour leur qualité. Cependant, pour les réunions Webex ou les sessions Appel sur Webex, cette notation ne s’applique pas. L'expérience d'appel est notée comme suit :
|
| 4 | Cliquez sur un appel spécifique dans la vue de liste, pour inspecter les détails du saut. La vue détaillée du houblon affiche :
À partir des détails de Hop, vous pouvez :
L’expérience d’appel de bout en bout est basée sur les données de qualité média collectées à partir de chaque point de terminaison enregistré dans Webex Calling (application Webex ou périphérique tel que 8865 ou Desk Pro) à la fin de l’appel. L'appel est classé comme bon, s'il satisfait aux seuils suivants :
La qualité du saut est dérivée des données collectées à partir du point de relais média dans le Cloud Webex Calling. Pour les appels RTCP via CCPP ou la passerelle locale, la collecte de données provient du Cloud Webex Calling et non du point de terminaison RTCP. Un houblon est classé comme bon, s'il satisfait à ces seuils.
Les mesures de saut varient au cours d'une session en fonction du temps d'échantillonnage et de la variabilité dans le réseau. Les valeurs qui sont rapportées par le point de relais média et les clients (expérience de bout en bout) peuvent ne pas s'aligner. Cependant, ils doivent être en alignement étroit pour permettre une segmentation le long du chemin. Nous avons recommandé d'utiliser la vue de dépannage des appels individuels avec les informations agrégées dérivées d'Analytics. Analysons la qualité des appels pour les différents types d’appels à l’aide de la vue de dépannage. |
Les appels au sein de l’organisation où ICE réussit et le relais média dans le Cloud sont supprimés du chemin d’accès. Le flux de média est directement entre les périphériques de l'utilisateur.
Inférence :
| 1 | L’appel est classé comme bon étant donné que l’appelant et l’appelé ont une bonne expérience de bout en bout. |
| 2 | L’administrateur peut observer que les médias circulent directement entre les deux utilisateurs et ne passent pas par le Cloud d’appel Webex. Les flux d’appels optimisés peuvent avoir une expérience médiocre, si l’entreprise ou le réseau local est la source du problème, car les médias entre les deux utilisateurs traverseront le réseau local. La latence ou RTT est toujours plus faible sur un appel optimisé, mais la perte de paquets et la gigue peuvent toujours être un facteur en fonction du réseau entre les deux utilisateurs. |
Inférence :
L'administrateur peut observer les points suivants :
| 1 | L’expérience de bout en bout de l’appelant est considérée comme médiocre. |
| 2 | Il y a un problème avec le saut réseau de l'appelant qui affecte à la fois le flux d'envoi et le flux de réception. |
| 3 | Le saut réseau de l’appelé n’a pas de problème. |
| 4 | L’expérience de bout en bout de l’appelant est considérée comme médiocre en raison du problème de l’appelant. |
Inférence :
L'appel est classé comme bon étant donné que l'expérience de bout en bout de l'appelant se situe dans les seuils acceptés. L'administrateur peut observer que :
| 1 | Le saut réseau de l'appelant est classé comme médiocre car certaines des mesures sont au-dessus du seuil acceptable. |
| 2 | Le flux d'envoi de la messagerie vocale est classé comme bon selon les mesures collectées à partir du point de relais média. |
| 3 | Le serveur média utilisé pour collecter ou déposer la messagerie vocale ne rapporte actuellement pas de mesures. Cependant, ces serveurs sont hébergés et gérés dans le cadre de Webex Calling Cloud, de sorte que la qualité de ce segment de liaison est interne et toujours de haute qualité, avec une faible latence. |
| 4 | L’administrateur peut observer que l’expérience de bout en bout de l’appelant est considérée comme bonne, bien que le saut soit considéré comme médiocre. Ceci est dû au fait que le saut de l'appelé a un bon réseau qui compense la dégradation des performances du réseau de l'appelant. |
Dans l’exemple, le média client provient d’un fournisseur RTCP via le Cloud.
L'appel est classé comme médiocre car l'expérience de bout en bout de l'appelé n'est pas dans les seuils acceptés. L'administrateur peut observer les points suivants :
| 1 | Le problème est avec le saut RTCP de l’appelant spécifiquement avec le flux d’envoi. |
| 2 | Le saut réseau de l’appelé n’a pas de problème. |
| 3 | L’expérience de bout en bout de l’appelant est considérée comme médiocre en raison du problème de l’appelant. |
| 4 | L’expérience de bout en bout et les mesures de flux de réception de l’appelant qui est sur le réseau RTCP ne sont actuellement pas disponibles car ces mesures ne sont pas transmises au Cloud Webex Calling. |
Appels entrants et sortants d’une organisation dont le média de l’appelant provient d’une entreprise. La session média peut provenir d’un utilisateur hébergé par l’entreprise (par exemple, enregistré auprès d’UCM) ou du RTCP, où le RTCP est fourni par l’entreprise.
Inférence
L'appel est classé comme médiocre car l'expérience de bout en bout de l'appelant n'est pas dans les seuils acceptés. L'administrateur peut observer les points suivants :
| 1 | Il y a un problème avec le passage de l’appelant vers le Cloud Webex Calling à la fois sur le flux d’envoi et de réception. |
| 2 | L’expérience de bout en bout de l’appelant est considérée comme médiocre en raison du problème observé dans le saut ou des problèmes du côté de l’utilisateur (périphériques, réseau, etc.). |
| 3 | Le trafic entrant vers le Cloud Webex Calling à partir du côté de l’appelé est classé comme bon. |
| 4 | L’expérience de bout en bout et les mesures de flux de réception de l’appelé qui est appelé à partir de la passerelle locale ne sont actuellement pas disponibles car ces mesures ne sont pas transmises au Cloud Webex Calling. |
Résoudre le problème de qualité des médias
L'affichage saut par saut vous aide à localiser l'endroit où le problème s'est produit. Maintenant que vous avez trouvé où se trouve le problème, et avec les mesures (gigue, perte de paquets, latence), vous pouvez essayer ce qui suit pour résoudre le problème.
Les possibilités typiques pour les problèmes médiatiques sont :
Problèmes spécifiques réseau/FAI/emplacement - En raison du pare-feu, de la configuration réseau ou de la bande passante, il existe un schéma d’expériences médiocres dans un emplacement ou un sous-réseau de réseau particulier. Utilisez la vue de dépannage par appel (identifiez l’emplacement associé à la mauvaise session) avec la vue d’analyse pour examiner les modèles agrégés de l’emplacement.
Problèmes spécifiques à l’utilisateur - Un utilisateur ou un périphérique est connecté sur un réseau médiocre (par exemple, Wi-Fi ou en télétravail), ce qui signifie que son expérience est affectée par les capacités réseau associées. Reportez-vous à l’article Utiliser CScan pour tester la qualité du réseau Webex Calling pour identifier le problème avec le réseau.
Problèmes spécifiques aux types d'appel - La mauvaise expérience d'un utilisateur est due à la qualité à l'extrémité distante. Ceci est typique dans les scénarios RTCP où l’utilisateur parle à un autre utilisateur sur un réseau mobile et la session a une perte de paquets élevée sur le réseau RTCP.
Problème sans média- Il peut n'y avoir aucune transmission média dans certains houblons. Le bandeau Insights affiche la cause en haut de la page des détails du saut et le responsable dans la zone d'informations de la page des détails du saut. Certaines des causes possibles de l'absence de média dans les appels ainsi que les parties responsables sont énumérées ici :
Webex ne reçoit pas de média de l’expéditeur.
Webex ne reçoit pas de média du destinataire.
Webex ne reçoit aucun média d’aucune direction.
Webex n’envoie pas de média au destinataire. L’ingénierie Webex résout ce problème.
Webex ne reçoit pas de média à partir du Cloud RTCP. L’ingénierie Webex résout ce problème.
Webex ne reçoit pas de média à partir du service Cloud. L’ingénierie Webex résout ce problème.
Webex ne reçoit pas de média à partir de la passerelle locale. L'administrateur du client doit enquêter sur le problème.
Échec de l'optimisation du chemin de média- Quelques appels ne peuvent pas réussir à configurer l'optimisation du chemin de média. La bannière Insights affiche la cause des appels ICE infructueux et la résolution en haut de la page des détails du saut.
Certaines des raisons possibles sont :
ICE a échoué en raison de l’interruption de l’accès au serveur - voir les informations de référence du port Webex Calling
ICE a échoué en raison du contrôle de connectivité - vérifier la connectivité entre les réseaux
ICE a échoué car le temps aller-retour du chemin par défaut était similaire/meilleur que tout chemin optimisé
Légendes sur la vue de dépannage
Reportez-vous aux détails d'appel suivants dans le volet de droite de l'affichage hop-by-hop.
| Terme | Définition |
| Date d’appel | La date à laquelle l'appel s'est produit. |
| Durée de l’appel | L'heure à laquelle l'appel a commencé et pris fin, affichée dans le fuseau horaire que vous avez sélectionné dans la vue de recherche. |
| Type de session | Le type de session pris en charge. Par exemple : Appel Webex |
| Participants | Le nombre de participants qui ont rejoint l'appel. |
| Nom de l’appelant | Nom de l'appelant. |
| Adresse électronique de l’appelant | Adresse électronique de l’appelant. |
| Numéro de l’appelant | Numéro de téléphone que l'appelant a utilisé pendant l'appel. |
| Audio | Le type d'audio utilisé. |
| Vidéo | Affiche Oui si la vidéo est activée par un participant. Si la vidéo n’a pas du tout été activée, elle affiche Non. |
| Optimisation du chemin d’accès | Indique si l'optimisation du chemin d'appel s'applique à l'appel. Les valeurs acceptées sont : ICE (Interactive Connectivity Establish) PNC (Private Network Connect). Aucune optimisation |
| Type d’appel | Le type d’appel peut être l’un des suivants : Urgence Enterprise International Mobile Nationales Opérateur Premium Shortcode Sans frais Inconnu URI |
Affichez ces métriques d'appel dans l'affichage saut par saut :
| Terme | Définition |
| Point de terminaison | Affiche l'une des options suivantes :
|
| Matériel | Affiche l'une des options suivantes :
|
| Emplacement | Emplacement Webex Calling qui est configuré pour l’utilisateur. |
| IP locale | L'adresse IP locale du client pour l'interface réseau qu'il utilise pour transmettre le média. Les adresses IP sont partiellement masquées pour préserver l’identité personnelle des utilisateurs. |
| IP publique | Il s'agit de l'adresse IP publique du client telle qu'elle est vue par le cloud. Pour les entreprises, il s’agit de l’adresse du pare-feu fournissant le NAT. Les adresses IP sont partiellement masquées pour préserver l’identité personnelle des utilisateurs. |
| Adresses MAC | L'adresse MAC du point de terminaison du client. |
| Géolocalisation | Recherche géographique de l'adresse IP publique. Cette adresse n'est pas exacte, si elle est connectée via PNC. Si l’utilisateur utilise l’application Webex et se connecte à l’entreprise via un VPN, l’emplacement n’est pas précis. |
| FAI | Fournisseur de service Internet qui fournit une connectivité réseau au Cloud Webex Calling. |
| Réseau | Le type de connexion réseau que le client a utilisé pour échanger des médias. Les valeurs possibles sont :
|
| Codec Audio | (Envoyer ou recevoir) Le format de codage et de décodage de média utilisé pour les médias transmis par un client. |
| Codec vidéo | (Envoyer ou recevoir) Le format de codage et de décodage de média utilisé pour les médias transmis par un client. S'applique uniquement à un appel vidéo. |
| ID d'appel | L'identificateur interne qui est utilisé pour identifier le tronçon d'appel. |
Certaines mesures sont masquées dans les captures d'écran de l'article pour préserver l'identité de l'utilisateur.
Limites
Les mesures de la qualité des médias ne sont pas disponibles à partir des périphériques suivants.
Téléphones analogiques
Périphériques tiers
Points de terminaison IPv6
