- Accueil
- /
- Article
Dépannage des appels Webex dans le Centre de contrôle
La vue de dépannage dans Webex Calling permet aux administrateurs de résoudre les problèmes de connectivité et de qualité liés aux médias pour les appels Webex Calling. Vous pouvez rechercher des informations relatives à l'appel, voir s'il a été réussi, refusé ou échoué, consulter ses statistiques médias, identifier où le problème s'est produit, et résoudre le problème.
Aperçu
La fonction de dépannage de Webex Calling vous permet de résoudre les problèmes liés à la qualité des médias et à la connectivité des appels Webex Calling spécifiques. Vous pourriez avoir besoin de résoudre les problèmes d'appels pour diverses raisons, notamment en cas de plaintes de clients concernant la mauvaise qualité des appels. Dans ce cas, vous pouvez accéder directement à la vue de dépannage, rechercher ces appels spécifiques, puis consulter les détails du saut pour identifier l'origine du problème. Vous pouvez également utiliser le dépannage pour surveiller de manière proactive la qualité des appels pour l'organisation et anticiper les problèmes spécifiques avant même que les utilisateurs ne les remarquent.
Pour accéder à la vue de dépannage, vous devez disposer du rôle d'administrateur complet, d'administrateur en lecture seule ou d'administrateur de support dans Control Hub.
Le dépannage des appels Webex vous permet de :
-
Rechercher les appels aboutis, infructueux et refusés.
-
Afficher l’expérience de bout en bout des participants de l’appel.
-
Afficher un détail de saut de l’appel.
-
Voir si le média traversera la Webex Calling cloud, ou directement entre les utilisateurs (en utilisant l’Interactive Connectivity Connectivity Passe (ICE)).
-
Consultez les statistiques si aucun média n'est présent lors de l'appel ou si la configuration d'optimisation du chemin a échoué.
-
Afficher les appels pour les 21 derniers jours.
-
Consultez les échecs et les rejets d'appels liés à la signalisation.
-
Analysez les métriques de 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 connectés à des réseaux Wi-Fi, mais la perte de paquets et la latence peuvent être acceptables.
-
Détecter si le problème est avec l’appelant ou le demandeur.
Les appels utilisant le Webex Calling’affichent à la fin de l’appel.
La vue de dépannage permet d'identifier la zone problématique en fournissant toutes les métriques pertinentes, mais ne peut pas nécessairement vous indiquer la cause première d'un appel de mauvaise qualité. Ces pointeurs identifient différents facteurs et déterminent les options de résolution :
-
l’expérience de bout en bout de l’utilisateur.
-
L’affichage détails Hop.
-
Envoyer ou recevoir des métriques de l’utilisateur ou du point de relais média.
-
Si l’appel est survenu vers ou à partir d’un réseau externe ou entre les Webex Calling points de terminaison enregistrés.
Affichage de recherche
Vous pouvez effectuer une recherche en utilisant les critères suivants pour obtenir une liste des appels où une session multimédia a été utilisée avec au moins un point de terminaison enregistré auprès de Webex Calling :
-
Adresses électroniques
-
Numéros de téléphone
-
adresses MAC
-
Identifiants d’appel
-
Identifiants de corrélation
La recherche partielle est prise en charge pour le numéro de téléphone, le nom d'utilisateur et le nom de l'appareil. Pour les numéros de téléphone, vous pouvez saisir les deux premiers chiffres pour afficher une liste de numéros possibles. Si vous entrez des chiffres et appuyez directement sur Entrée, la recherche tentera de trouver une correspondance exacte.
Lorsque vous recherchez l'adresse e-mail d'un utilisateur, ses réunions et ses appels sont séparés dans leurs onglets respectifs :
-
Réunions — Contient toutes les réunions auxquelles l'utilisateur a participé.
-
Appels Webex — Contient tous les appels Webex.
-
Appel sur Webex — Contient les appels Call on Webex.
Lorsque vous effectuez une recherche par identifiant de corrélation ou par numéro de téléphone, seul l'onglet correspondant (dans ce cas, appel Webex) s'affiche, ne présentant que les résultats pertinents.
Lorsque vous recherchez un appel, les segments d'appel pertinents sont affichés dans l'onglet Webex Calling. Les données suivantes sont disponibles :
| Nom de la colonne | Définition |
|---|---|
|
Statut |
Si la tentative d'appel a réussi ou non. Lorsque la tentative d'appel a un statut Refus ou Échec, vous pouvez survoler le statut pour voir le code correspondant. Les valeurs possibles sont :
|
|
Qualité globale |
La qualité Webex Calling tous les appels est noté. Cependant, cette notation ne s'applique pas aux réunions Webex ni aux sessions Call on Webex. L’expérience d’appel est noté comme :
|
|
Qualités personnelles |
Qualité du segment d'appel individuel de l'utilisateur. |
|
Horodatage |
Heure de début de l'appel. |
|
numéro de l'appelant |
Numéro d'appel Webex attribué à l'appelant. |
|
Nom de l'appelant |
Nom de l’appelant. |
|
Numéro de l'appelé |
Numéro Webex Calling attribué à l’appelé. |
|
Nom de l'appelé |
Nom de l'appelé. |
|
Durée |
Durée de l'appel. |
|
Emplacement |
Webex : localisation de l’appelant. |
|
ID de corrélation |
Identifiant de corrélation pour relier plusieurs appels segments/call jambes du même appel. |
Indicateurs clés de performance (KPI) de l'utilisateur recherché
Les indicateurs de performance clés (KPI) suivants sont disponibles pour l'onglet Webex Calling lorsque vous recherchez un utilisateur :
-
Nombre total d'appels — Nombre total d'appels.
-
Nombre total de segments d'appel — Nombre total de segments d'appel.
-
Segments d'appel ayant échoué — Nombre de segments d'appel ayant échoué.
-
Segments d'appel refusés — Nombre de segments d'appel qui ont été refusés.
-
Segments d'appels de mauvaise qualité — Nombre de segments d'appels de mauvaise qualité.
Qu’est-ce qu’un segment d’appel ?
Un segment d'appel représente une portion distincte d'un appel Webex Calling. En substance, chaque liaison directe ou connexion entre deux participants constitue un segment d'appel unique.
Par exemple, si Alice appelle un standard automatique qui redirige l'appel vers Bob, l'appel d'Alice vers le standard automatique est considéré comme un segment de l'appel, tandis que l'appel du standard automatique vers Bob est considéré comme un autre segment du même flux d'appel. Un appel unique et complexe peut donc comprendre plusieurs segments d'appel.
En général, un segment d'appel est composé de deux branches d'appel (CDR) : une jambe d'origine et une jambe d'arrivée. Toutefois, dans les scénarios impliquant des appels RTC, une seule liaison d'appel (la liaison de terminaison pour l'utilisateur Webex) peut être générée du point de vue de l'appel Webex.
Chaque segment d'appel peut avoir un résultat distinct (par exemple, succès, échec, refus). Par conséquent, il est crucial de représenter les événements de communication sous forme de segments d'appel dans la vue de dépannage du Control Hub. Cela permet aux clients d'observer une ventilation complète en segments individuels, permettant une identification précise des problèmes au sein d'un flux d'appels complexe.
Résumé de l’appel
La section « résumé de l'appel » sur la page des détails de l'appel représente visuellement le déroulement complet et de bout en bout d'une séquence d'appels entière. Cette vue d'ensemble permet aux clients de visualiser l'intégralité du flux d'un appel, même lorsqu'il englobe plusieurs « appels » logiques (tels que définis par des identifiants de corrélation communs) ou des scénarios de transfert complexes. Le résumé des appels assemble intelligemment tous les sauts intermédiaires et les « appels » associés pour fournir une vue d'ensemble cohérente.
Le résumé d'appel vous permet de comprendre rapidement le déroulement de l'appel du début à la fin grâce à une vue chronologique visuelle. Chaque participant à gauche représente le type d'utilisateur (PSTN, groupe de recherche, file d'attente d'appels, etc.) tandis que les lignes devant lui représentent l'interaction d'appel pour ce participant. Les interactions entre deux participants sont appelées segments d'appel. En survolant un participant, vous pouvez consulter des informations détaillées telles que son nom, son type d'utilisateur, la durée et l'horodatage, et plus encore. Vous pouvez cliquer sur des participants spécifiques pour afficher les détails du segment d'appel dans la vue détaillée située sous la fiche récapitulative de l'appel sur la même page. Notez que certains participants de type utilisateur PSTN et Passerelle locale ne sont pas cliquables.
Le résumé des appels met également en évidence les actions effectuées sur l'appel, telles que composer un numéro, mettre en attente, transférer, etc. Et l'état de la connectivité, comme une panne ou un refus. Vous pouvez survoler des panneaux spécifiques pour obtenir plus de détails, ce qui vous aide à identifier et à résoudre les problèmes à l'endroit précis où ils se sont produits.
La capture d'écran ci-dessus, par exemple, représente un appel où un utilisateur externe du réseau téléphonique public commuté (PSTN) a composé un numéro vers un standard automatique qui a dirigé l'appel vers une file d'attente d'appels. L'appel a ensuite été transféré à deux agents, parmi lesquels le second a décroché et s'est entretenu avec l'utilisateur du réseau téléphonique public commuté (PSTN). Les superpositions de qualité média représentent la qualité du média aux points d'extrémité. La section Légende fournit des détails supplémentaires pour vous aider à comprendre le résumé de l'appel.
Pour une explication plus détaillée de la section résumé de l'appel, vous pouvez regarder cette vidéo
Les scénarios suivants ne sont pas pris en charge par le diagramme de résumé des appels :
- Flux d'appels de conférence tels que Conférence, Intervention forcée, Pont d'appel et Fusion d'appels.
- fonctions de supervision de la file d'attente d'appels telles que la surveillance silencieuse, le coaching, l'intervention, la prise de contrôle, etc.
- Informations concernant les annonces diffusées aux terminaux.
- Informations concernant les appels mis en attente puis repris au cours d'un appel actif.
- Les situations d'échec et de refus d'appel peuvent afficher des raisons différentes de part et d'autre des segments d'appel en raison des états internes de l'appel.
Afficher les détails de Hop

Les données suivantes sont disponibles dans la vue détaillée du houblon :
| Terme | Définition |
|---|---|
| Point de terminaison |
Affiche l’une des affichages suivants :
|
| Matériel |
Affiche l’une des affichages suivants :
|
| Emplacement |
Emplacement des appels Webex configuré pour l'utilisateur. Le pays dans lequel Webex Calling a été déployé est également indiqué entre parenthèses. |
| IP locale |
L’adresse IP locale du client pour l’interface réseau qu’il utilise pour transmettre les médias. Les adresses IP sont partiellement masquées pour préserver l’identité personnelle des utilisateurs. |
| IP publique |
Ceci est l’IP publique du client telle qu’elle est vue par le Cloud. Pour les entreprises, ceci est 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 est inexacte si la connexion se fait via PNC. Si l’utilisateur utilise l’application Webex et se connecte à l’entreprise via un VPN, l’emplacement n’est pas précis. |
| ISP |
Internet Prestataire de service qui fournit une connectivité réseau au Cloud Webex Calling cloud. |
| Réseau |
type de connexion réseau que le client a utilisée pour échanger des médias. Les valeurs possibles sont :
|
| Codec audio |
(Envoyer ou recevoir) Format d’encodage et de décodage média en cours d’utilisation pour les médias transmis par un client. |
| Codec vidéo |
(Envoyer ou recevoir) Format d’encodage et de décodage média en cours d’utilisation pour les médias transmis par un client. S’applique uniquement à un appel vidéo. |
| ID de session SIP |
Identifiants de session d'origine (ou initiale) et finale. |
| Trunk |
Disponible uniquement lorsqu'une passerelle locale est impliquée dans le saut. Nom de la liaison entrante et sortante. |
| Groupe de routage |
Disponible uniquement lorsqu'une passerelle locale est impliquée dans le saut. Nom du groupe de routes. |
| Nom du fournisseur PSTN |
Disponible uniquement lorsque le réseau téléphonique public commuté (PSTN) est impliqué dans la transmission. Nom du fournisseur. |
Certaines métriques sont masquées dans les captures d’écran de l’article pour préserver l’identité de l’utilisateur.
D'après les informations sur le houblon, vous pouvez :
-
Vérifiez si le saut a été acheminé via le réseau téléphonique public commuté (RTPC) ou une passerelle locale.
-
Consultez le type d'utilisateur qui a émis ou reçu l'appel. Quelques exemples incluent
HuntGroup,VoiceMailGroup, etRoutePoint. Le rapport Historique détaillé des appels fournit une liste de tous les types d'utilisateurs possibles. -
Consultez les informations relatives à l'appel dans ces scénarios :
-
Aucun média n'a couvert les différentes étapes de l'appel.
-
La configuration d'optimisation du chemin a échoué.
-
L'un des relais a échoué ou a refusé l'appel. Les houblons non conformes sont marqués en rouge et les houblons refusés sont marqués en jaune. Une raison est également fournie pour expliquer pourquoi le saut a échoué ou a été refusé.
-
-
Survolez le périphérique pour afficher l’expérience d’appel de bout en bout.

-
Passez votre souris sur le point de terminaison et Webex Calling cloud pour afficher les détails du saut.
L'expérience d'appel de bout en bout est basée sur les données de qualité des médias collectées à partir de chaque point de terminaison enregistré Webex Calling (application Webex ou appareil tel que 8865 ou Desk Pro) à la fin de l'appel. L'appel est jugé bon si le point de terminaison présente les seuils suivants :
-
Perte de paquets inférieure à 5%.
-
Latence ou temps d'aller-retour (RTT) inférieur à 400 ms.
-
Gigue inférieure à 150 ms.
La qualité du saut provient de données collectées à partir du point de relais média dans Webex Calling Cloud. Pour RTCP passer des appels via CCPP ou la passerelle locale, la collecte de données est à partir du Cloud Webex Calling et non du point de RTCP terminaison. Un relais est considéré comme bon si le point de relais multimédia présente les seuils suivants :
-
Perte de paquets inférieure à 2.5 %.
-
Latence ou RTT inférieure à 200 ms.
-
Gigue inférieure à 75 ms.
Vous pouvez également enregistrer les données dans les détails du saut en sélectionnant Actions puis en choisissant l'une des options suivantes :
- Enregistrer les enregistrements des appels de dépannage (CSV)
- Enregistrer le rapport d’appels (JSON)
- Enregistrer les détails du participant (CSV)
Panneau Détails de l'appel
Les données suivantes sont disponibles dans le volet droit « Détails de l'appel » de la vue des détails du saut :
| Terme | Définition |
|---|---|
| ID de corrélation | ID de corrélation pour lier les plusieurs pieds d’appel de la même session d’appel. |
| Date de l’appel | La date à laquelle l’appel a eu lieu. |
| Heure de l’appel | L’heure du début et de la fin de l’appel, affichée dans le fuseau horaire que vous avez sélectionné dans l’affichage 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é au cours de 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'était pas activée du tout, il affiche Non. |
| Optimisation du schéma |
Indique si l’optimisation du chemin d’appel s’applique à l’appel. Les valeurs acceptées sont :
|
| Type d’appel |
Le type d’appel peut être l’un des suivants :
|
| Appel terminé par |
L'utilisateur qui a mis fin à l'appel. |
| Chiffres composés |
Le clavier numérique est composé par l’utilisateur, avant les pré-traductions. |
| Raison connexe |
Indique la raison pour laquelle le houblon a été créé. Par exemple, la valeur |
Accédez à la vue de dépannage des appels Webex
La recherche partielle est prise en charge pour les adresses e-mail, les numéros de téléphone et les identifiants d'appel. Pour les numéros de téléphone, vous pouvez saisir les trois à huit premiers chiffres, puis appuyer sur Entrée pour afficher les correspondances. Si vous saisissez plus de huit chiffres, la recherche tentera de trouver une correspondance exacte. Notez que si vous copiez et collez un numéro de téléphone provenant d'ailleurs, vous devez inclure le +1 pour que la recherche fonctionne.
Pour analyser un appel Webex, effectuez les contrôles suivants :
| 1 |
Connectez-vous à Control Hub et accédez à Monitoring > Dépannage. |
| 2 |
Recherchez l'adresse e-mail, le numéro de téléphone, l'adresse MAC, les identifiants d'appel ou l'identifiant de corrélation que vous souhaitez consulter. Vous pouvez regrouper les appels associés dans la vue de recherche en utilisant l'ID de corrélation. |
| 3 |
Appliquez un filtre de votre choix. Les filtres disponibles sont :
Les filtres ne sont pas disponibles si vous recherchez des numéros de téléphone ou des identifiants de corrélation. |
| 4 |
Cliquez sur un appel spécifique pour consulter les détails du saut. |
Télécharger les résultats de recherche ou les enregistrements d'appels de dépannage au format CSV
Vous pouvez télécharger les résultats de la recherche ou les enregistrements d'appels de dépannage au format CSV. Ces enregistrements fournissent des informations détaillées au niveau de chaque segment d'appel afin de faciliter le dépannage d'un appel.
Vous pouvez exporter jusqu'à 100 enregistrements d'appels de dépannage par fichier CSV.
Lorsque vous cliquez sur télécharger, les résultats de recherche de l'onglet actif seront téléchargés. Pour télécharger les enregistrements des appels Webex, assurez-vous de vous trouver dans l'onglet « Appels Webex ».
| 1 |
Connectez-vous à Control Hub et accédez à Monitoring > Dépannage. |
| 2 |
Une fois que vous avez une liste des appels que vous souhaitez consulter, sélectionnez ou Télécharger les enregistrements d'appels de dépannage (CSV).
Vous pouvez également télécharger les enregistrements de dépannage depuis la page des détails de l'appel. Vous pouvez télécharger ici les enregistrements des appels de dépannage, le rapport d'appel au format JSON et les détails des participants sous forme de fichier CSV. |
Résolution des problèmes de qualité des médias
L’affichage saut par saut vous aide à localiser le problème. Maintenant que vous avez trouvé l’endroit du problème et avec les métriques (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édia sont :
-
Network/ISP/location problèmes spécifiques— En raison du pare-feu, de la configuration du 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 l’affichage de dépannage par appel (identifier l’emplacement associé à la session médiocre) avec l’affichage analytique pour revoir les schémas agrégés pour l’emplacement.
-
Problèmes spécifiques à l'utilisateur— Un utilisateur ou un appareil est connecté à un réseau de mauvaise qualité (par exemple, Wi-Fi ou travail à domicile), ce qui signifie que son expérience est affectée par les capacités du réseau associé. Consultez l'article Utiliser CScan pour tester la qualité du réseau d'appel Webex pour identifier le problème avec le réseau.
-
Problèmes spécifiques au type d'appel— La mauvaise expérience d'un utilisateur est due à la qualité du côté distant. Ceci est typique dans RTCP cas où l’utilisateur parle à un autre utilisateur sur un réseau mobile et que la session a une perte de paquets élevée sur le réseau RTCP cellulaire.
-
Problème d'absence de média— Il se peut qu'il n'y ait pas de transmission de média dans certains sauts. La bannière Insights affiche la cause en haut de la page de détails du houblon et la partie responsable dans l'encadré d'informations de cette même page. Voici quelques-unes des causes possibles de l'absence de médias lors des appels, ainsi que les parties responsables :
-
Webex ne reçoit pas les médias de l'expéditeur.
-
Webex ne reçoit pas de flux multimédia du récepteur.
-
Webex ne reçoit aucun flux multimédia dans les deux sens.
-
Webex n'envoie pas de médias au destinataire. L'équipe d'ingénierie de Webex prend en charge ce problème.
-
Webex ne reçoit pas de flux multimédia du réseau téléphonique public commuté (PSTN) du cloud. L'équipe d'ingénierie de Webex prend en charge ce problème.
-
Webex ne reçoit pas de flux multimédia du service cloud. L'équipe d'ingénierie de Webex prend en charge ce problème.
-
Webex ne reçoit pas de flux multimédia de la passerelle locale. L'administrateur client doit examiner le problème.
-
-
Échec de l'optimisation du chemin média— Peu d'appels ne peuvent pas configurer avec succès l'optimisation du chemin média. La bannière Insights affiche la cause des échecs d'appels ICE et leur résolution en haut de la page de détails Hop.

Voici quelques raisons possibles :
-
Échec de l'authentification ICE en raison d'un problème d'accès au serveur STUN - consultez les informations de référence sur le port d'appel Webex.
-
ICE a échoué en raison d'un contrôle de connectivité - vérifiez la connectivité entre les réseaux.
-
ICE a échoué car le temps d'aller-retour par défaut était de similar/better que n'importe quel chemin optimisé.
-
Limites
Les indicateurs de qualité des médias et les flux d'origine et de destination côté réseau ne sont pas disponibles pour les appareils suivants :
-
Téléphones analogiques
-
Périphériques tiers
-
Points de terminaison IPv6
Flux d’appels pris en charge
Les rapports de qualité média sont collectées à partir des points de terminaison de l’appelant et du point de terminaison du appelant et du relais média. Ceci permet une segmentation de l’expérience média pour affiner et identifier si le problème s’est produit lors de la :
-
Appelant ou appelant
-
Chemin d’accès média vers ou depuis Webex Calling cloud.
Les pieds d’appel s’affichent s’il y a une session média établie avec au moins Webex Calling point de terminaison enregistré sur l’appel. Par exemple, pour un appel sortant de groupe de recherche/groupe de distribution des appels à huit agents, si un seul agent répond, il n’y a aucune expérience média pour le dépannage des sept autres agents.
Il existe cinq types d’expériences média ou de chemins pour Webex Calling dépannage, qui sont :
-
Optimisé sur le réseau – Appels au sein de l'organisation où ICE réussit et les médias circulent directement entre les utilisateurs. Voir Optimisation Webex Calling’environnement média interactif avec connectivité interactive (ICE) pour des informations détaillées.
-
Sur le réseau non optimisé – Appels au sein de l'organisation où l'établissement d'une connectivité interactive (ICE) n'a pas été possible ou établi. Dans ce cas, les médias passe par le Cloud d’appel Webex.
-
Hébergement cloud sur le réseau – Appels au sein d'une organisation où les médias sont fournis par un serveur multimédia hébergé dans le cloud (par exemple, écouter la messagerie vocale, composer un numéro pour un standard automatique).
-
Appel hors réseau vers ou depuis le point de terminaison enregistré Webex Calling -
-
via un fournisseur PSTN connecté au cloud- Appels entrants et sortants d'une organisation où l'autre partie se trouve sur le réseau PSTN. Le média est transmis via un fournisseur RTCP cloud (CCPP), sur une interconnexion de haute qualité.
-
via Local Gateway- Appels entrants et sortants d'une organisation où les médias de l'autre partie passent par l'entreprise. Derrière la passerelle locale la session média peut être à partir de l’utilisateur hébergé par l’entreprise (par exemple, enregistré pour le contrôle des appels dans l’entreprise) ou à partir d’RTCP, où le RTCP est fourni par l’entreprise.
-
S’il y a 1 ou 2 Webex Calling utilisateurs inscrits qui sont impliqués dans un appel point à point sur Internet, alors l’affichage de dépannage présente des métriques 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 l’affichage de dépannage présente uniquement les métriques du client de l’utilisateur 1, en même temps que les métriques prises à partir du point de relais média.
La plupart des scénarios d’appels dans l’affichage de dépannage montrent deux pieds d’appel (appelant et appelant) ; cependant, certains scénarios d’appel (tels que le parcier ou la récupération des appels) n’ont qu’une seule pied de l’appel. Dans ce cas, l’autre phase d’appel s’affiche séparément dans l’affichage de dépannage. Ceci n’empêche pas le dépannage de l’appel et de la détection de l’endroit où le problème s’est produit. Cependant, l’administrateur ne doit pas manuellement corréler les deux pied d’appel en utilisant une entité commune telle que la durée qui se chevauche. Les futures améliorations apportées à l’affichage du dépannage élimineront le besoin d’utiliser les recherches manuelles.
Les métriques de saut varient au cours d’une session en fonction de l’heure d’échantillonnage et de la diversité dans le réseau. Les valeurs qui sont signalé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 bon alignement pour permettre une segmentation le long du chemin.
Nous vous recommandons d’utiliser l’affichage individuel de dépannage des appels avec les informations agrégées obtenues à partir de l’analyse .
Analysez la qualité des appels pour les différents types d’appels en utilisant l’affichage de dépannage.
Appels au sein de l’organisation où ICE a réussi et le relais média dans le Cloud est supprimé du chemin. Le flux média est directement entre les périphériques de l’utilisateur.


Inférence:
| 1 |
L’appel est noté comme étant bon tant que l’appelant et le demandeur ont une bonne expérience de bout en bout. |
| 2 |
L’administrateur peut observer que les flux de médias entre les deux utilisateurs et ne voyagent pas à travers le Cloud d’appel Webex. Les flux optimisés des appels peuvent avoir une expérience médiocre, si l’entreprise ou le réseau local est la source du problème, car le média entre les deux utilisateurs traversera 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 ce qui suit :
| 1 |
L’expérience de l’appelant de bout en bout est classé comme médiocre. |
| 2 |
Il y a un problème avec le saut du réseau de l’appelant qui affecte à la fois le flux de l’envoi et de la réception. |
| 3 |
Le saut du réseau de l’appelant n’a pas de problème. |
| 4 |
L’expérience de bout en bout de l’appelant est classé comme médiocre en raison du problème de l’appelant. |


Inférence:
L’appel est classé comme étant bon car l’expérience de bout en bout de l’appelant se trouve dans les seuils acceptés. L’administrateur peut observer que :
| 1 |
Le saut de réseau pour l’appelant est classé comme médiocre car certaines métriques sont au dessus du seuil acceptable. |
| 2 |
Le flux Envoyer à partir de la messagerie vocale est noté comme bon selon les métriques collectées à partir du point de relais média. |
| 3 |
L problèmes de diffusion média utilisé pour collecter ou déposer la messagerie vocale ne signale actuellement pas de métriques. Cependant, ces serveurs sont hébergés et gérés dans le cadre du Webex Calling Cloud de sorte que la qualité de ce segment de liaison soit interne et toujours de haute qualité, faible latence. |
| 4 |
L’administrateur peut observer que l’expérience de l’appelant de bout en bout est classé bon bien que le saut soit classé comme médiocre. Ceci est dû au saut de l’appelant ayant un bon réseau qui compense la dégradation de la performance du réseau de l’appelant. |
Dans l’exemple, le média du client vient d’un RTCP via le Cloud.


L’appel est classé comme médiocre car l’expérience de bout en bout du client appelant n’est pas au dessous des seuils acceptés. L’administrateur peut observer ce qui suit :
| 1 |
Le problème est avec le point de saut de l’appelant RTCP spécifiquement avec le flux d’envoi. |
| 2 |
Le saut du réseau de l’appelant n’a pas de problème. |
| 3 |
L’expérience de bout en bout de l’appelant est classé comme médiocre en raison du problème de l’appelant. |
| 4 |
L’expérience de bout en bout et les métriques de réception de l’appelant qui est sur le réseau RTCP ne sont actuellement pas disponibles car ces métriques ne sont pas transmises au Cloud Webex Calling. |
Appels depuis et depuis une organisation où le média de l’appelant vient d’une entreprise. La session média peut être à partir d’un utilisateur hébergé par une entreprise (par exemple, enregistré sur UCM) ou à partir d’RTCP, où le RTCP est fourni via 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 ce qui suit :
| 1 |
Il y a un problème avec le saut de l’appelant vers le cloud Webex Calling’appel à la fois sur le flux Envoyer et recevoir. |
| 2 |
L’expérience de l’appelant de bout en bout est classé comme médiocre en raison du problème observé au cours du saut ou des problèmes qui se sont produit à la fin de l’utilisateur (périphériques, réseau, etc.) |
| 3 |
Le trafic entrant vers Webex Calling Cloud à partir de la fin de l’appel est classé comme bon. |
| 4 |
L’expérience de bout en bout et les métriques de réception des flux de l’appelant qui est appelé à partir de la passerelle locale ne sont actuellement pas disponibles car ces métriques ne sont pas transmises vers le Cloud Webex Calling. |
Dépannage ayant échoué et appels de refus
La colonne Statut de l'appel indique si un appel a réussi, a été refusé ou a échoué. Lorsqu'un appel a un statut Refus ou Échec, vous pouvez survoler le statut pour voir le code correspondant.
Lorsque vous examinez la liste des appels d'un utilisateur, un indicateur de performance clé Appels échoués est disponible pour identifier rapidement si cet utilisateur rencontre des problèmes importants. Vous pouvez survoler le statut Refus ou Échec pour afficher le code spécifique associé à chaque statut.
Dans la vue des détails du saut, une bannière s'affiche pour vous montrer plus d'informations sur la raison pour laquelle l'appel a un statut Refus ou Échec. Vous pouvez également voir si l'état de l'appel s'est produit lors du saut d'origine ou de destination.
Exemples de scénarios d'appels ayant échoué
Code d'erreur : Aucun itinéraire vers la destination

Une tentative d'appel a été effectuée depuis un appareil du lieu de travail, mais a échoué faute d'itinéraire disponible vers la destination.
Code d'erreur : Erreur de protocole

Une tentative d'appel a été effectuée depuis un appareil du lieu de travail, mais a échoué en raison d'une erreur liée au protocole.
Code d'erreur : Erreur interne

Un appel a été passé depuis une passerelle locale, mais a échoué en raison d'erreurs internes au niveau du périphérique de travail à destination. La communication a été établie pendant 14 minutes avant de se solder par une erreur interne.
Exemples de scénarios de refus d'appel
Code de refus : Appel rejeté
La tentative d'appel a échoué car la connexion à la destination était impossible ou l'interface avec la destination ne fonctionnait pas correctement. Voici quelques exemples de scénarios rejetés :
-
La tentative d'appel a été rejetée en raison du rejet des appels anonymes.
-
La tentative d'appel a été rejetée en raison des autorisations d'appel entrant.
-
La tentative d'appel a été rejetée en raison des autorisations d'appel sortant.
-
La tentative d'appel a été rejetée en raison des autorisations d'appel sortant.
-
La tentative d'appel a été rejetée en raison de l'interception d'appel configurée.
-
La tentative d'appel a été rejetée en raison d'un échec de mise en attente ou de récupération de l'appel.
-
La tentative d'appel a été rejetée en raison du rejet de la fonction « appuyer pour parler ».
-
La tentative d'appel a été rejetée en raison de l'acceptation sélective des appels.
-
La tentative d'appel a été rejetée en raison du rejet sélectif des appels.
-
La tentative d'appel a été rejetée en raison d'erreurs telles que numéro inconnu, autorisations insuffisantes, etc.
Code d'erreur : Numéro non attribué
Un appel a été tenté par l'appelant, mais il a été rejeté car la destination était un numéro non attribué.
raisons de l'issue de l'appel
Le tableau suivant répertorie les codes Refus et Échec disponibles pour les appels infructueux.
| Raison du résultat de l’appel | Définition |
|---|---|
|
Réussie |
L'appel a réussi. Les codes possibles sont :
|
|
Refus |
L'appel a été refusé. Les codes possibles sont :
|
|
Échec |
L'appel n'a pas abouti. Les codes possibles sont :
|
