- Accueil
- /
- Article
Merci pour votre commentaire.
Dépannage des appels Webex Calling dans Control Hub
Dans cet article
Un commentaire ?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 réussi , refusé ou échoué, afficher ses statistiques multimédias, identifier où le problème s'est produit et résoudre le problème.
Aperçu
Le dépannage pour Webex Calling vous permet de résoudre les problèmes de qualité multimédia et de connectivité des appels pour des appels Webex Calling spécifiques. Vous souhaiterez peut-être résoudre des problèmes d'appels pour diverses raisons, telles que des plaintes de clients concernant la mauvaise qualité de leurs appels. Dans ce cas, vous pouvez accéder directement à la vue de dépannage, rechercher ces appels spécifiques, puis afficher les détails du saut pour identifier où le problème pourrait se situer. Vous pouvez également utiliser le dépannage pour surveiller de manière proactive la qualité des appels pour l'organisation et anticiper des problèmes spécifiques avant que les utilisateurs ne s'en rendent compte.
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.
Vous pouvez effectuer une recherche à l'aide des 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é sur Webex Calling :
-
ID de messagerie électronique
-
Numéros de téléphone
-
Adresse MAC
-
Identifiants d’appel
-
ID de corrélation
La recherche partielle est prise en charge pour les identifiants de messagerie, 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 voir les entrées correspondantes. Si vous entrez 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.
Le dépannage de Webex Calling vous permet de :
-
Recherchez les appels réussis, échoués 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 informations, 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 pour les 21 derniers jours.
-
Afficher 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 sur les 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 mesures pertinentes et ne peut pas nécessairement vous fournir la cause première d'un mauvais appel. 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
Lorsque vous recherchez un appel, les données suivantes sont disponibles :
| Nom de la colonne | Définition |
|---|---|
|
Statut de l’appel |
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é |
La qualité Webex Calling tous les appels est noté. Cependant, pour les réunions Webex ou les sessions Call on Webex, cette notation ne s'applique pas. L’expérience d’appel est noté comme :
|
|
Service |
Service utilisé pour l'appel. |
|
Heure de démarrage |
Heure de début de l'appel, en fonction du fuseau horaire sélectionné à côté du sélecteur de plage de dates. |
|
Réunion / Numéro d'appel |
Numéro de téléphone de l'appelant. |
|
Nom |
Afficher le nom de l'appelant et de l'appelé. |
|
Organisateur/Appelant |
Nom d'affichage de l'appelant. |
|
Participants |
Nombre d'utilisateurs dans l'appel. |
|
Durée |
Durée de l'appel. |
|
Site/Emplacement |
Localisation de l'appelant dans Webex Calling. |
|
Conférence / ID de corrélation |
ID de corrélation pour lier les plusieurs pieds d’appel de la même session d’appel. |
Indicateurs clés de performance (KPI) de l'utilisateur recherché
Lorsque vous recherchez un utilisateur, les KPI suivants sont disponibles :
- Appels échoués— Nombre d'appels ayant échoué au cours de la plage de dates sélectionnée.
- Comptes rendus de réunion médiocres— Nombre de minutes pendant les réunions Webex qui ont eu des performances de mauvaise qualité sur la plage de dates sélectionnée.
- Appel sur Webex avec une mauvaise qualité— Nombre d'appels Appel sur Webex qui ont eu des performances de mauvaise qualité sur la plage de dates sélectionnée.
- Appels Webex Calling de mauvaise qualité— Nombre d'appels Webex Calling dont la qualité était médiocre sur la plage de dates sélectionnée.
- Minutes WebRTC médiocres— Nombre de minutes de mauvaise qualité lors de l'utilisation de WebRTC sur la plage de dates sélectionnée.
- Nombre total de minutes de réunions— Nombre total de minutes de réunions Webex sur la plage de dates sélectionnée.
- Nombre total de minutes d'appel sur Webex— Nombre total de minutes d'appel sur Webex sur la plage de dates sélectionnée.
- Total des minutes d'appel Webex Calling— Nombre total de minutes d'appel Webex Calling sur la plage de dates sélectionnée.
- Total des minutes WebRTC— Nombre total de minutes WebRTC sur la plage de dates sélectionnée.
Vue détaillée du houblon
Les données suivantes sont disponibles dans la vue des détails du saut :
| Terme | Définition |
|---|---|
| Point de terminaison |
Affiche l’une des affichages suivants :
|
| Matériel |
Affiche l’une des affichages suivants :
|
| Emplacement |
Emplacement d'appel Webex configuré pour l'utilisateur. Le pays dans lequel Webex Calling a été provisionné 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 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. |
| 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 originaux (ou initiaux) et finaux. |
| Trunk |
Disponible uniquement lorsqu'une passerelle locale est impliquée dans le saut. Nom du tronc entrant et sortant. |
| Groupe de routage |
Disponible uniquement lorsqu'une passerelle locale est impliquée dans le saut. Nom du groupe d'itinéraires. |
| Nom du fournisseur PSTN |
Disponible uniquement lorsque le PSTN est impliqué dans le saut. Nom du vendeur. |
Certaines métriques sont masquées dans les captures d’écran de l’article pour préserver l’identité de l’utilisateur.
À partir des détails du houblon, vous pouvez :
-
Affichez si le saut a été acheminé via le PSTN ou une passerelle locale.
-
Afficher le type d’utilisateur qui a passé ou reçu l’appel. Quelques exemples incluent
HuntGroup,VoiceMailGroupetRoutePoint. Le rapport Historique détaillé des appels fournit une liste de tous les types d'utilisateurs possibles. -
Consultez les informations sur l'appel dans ces scénarios :
-
Il n'y avait aucun média pour aucun des sauts liés à l'appel.
-
La configuration de l'optimisation du chemin a échoué.
-
L'un des sauts a échoué ou a refusé l'appel. Les sauts échoués sont marqués en rouge et les sauts refusés sont marqués en jaune. Une raison est également donnée expliquant 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é multimédia collectées à partir de chaque point de terminaison Webex Calling enregistré (application Webex ou appareil tel que 8865 ou Desk Pro) à la fin de l'appel. L'appel est considéré comme 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 saut 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 d'appels de dépannage (CSV)
- Enregistrer le rapport d’appels (JSON)
- Enregistrer les détails du participant (CSV)
Volet Détails de l'appel
Les données suivantes sont disponibles dans le volet droit Détails de l'appel de la vue 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'a pas été activée du tout, elle 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 |
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, une valeur de |
Accéder à la vue de dépannage de Webex Calling
La recherche partielle est prise en charge pour les identifiants de messagerie, 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 voir les entrées correspondantes. Si vous entrez 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'identifiant de messagerie, le numéro de téléphone, l'adresse MAC, les identifiants d'appel ou l'identifiant de corrélation que vous souhaitez afficher. 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 inspecter la vue des détails du saut. |
Exporter les détails des appels de dépannage sous forme de fichier CSV
Vous pouvez exporter les détails des appels de dépannage sous forme de fichier CSV. L'exportation de ces détails d'appel est utile pour les appels complexes impliquant plusieurs sauts, car elle vous permet d'identifier les problèmes ou les modèles en un coup d'œil. Vous pouvez exporter jusqu'à 100 détails d'appels de dépannage par fichier CSV.
| 1 |
Connectez-vous à Control Hub et accédez à Monitoring > Dépannage. |
| 2 |
Une fois que vous avez une liste d'appels que vous souhaitez afficher, sélectionnez .
|
Dépannage 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 modèle de mauvaises expériences 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 réseau associées. Consultez 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 au type d'appel— La mauvaise expérience d'un utilisateur est due à la qualité à l'autre bout. 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 aucune transmission multimédia dans certains sauts. La bannière Insights affiche la cause en haut de la page des détails du hop et la partie responsable dans la zone d'informations de la page des détails du hop. Certaines des causes possibles de l'absence de média dans les appels ainsi que les parties responsables sont répertoriées ici :
-
Webex ne reçoit pas de média de l'expéditeur.
-
Webex ne reçoit pas de média du récepteur.
-
Webex ne reçoit aucun média dans aucune direction.
-
Webex n'envoie pas de média au récepteur. L’ingénierie Webex résout ce problème.
-
Webex ne reçoit pas de média depuis Cloud PSTN. L’ingénierie Webex résout ce problème.
-
Webex ne reçoit pas de média du service cloud. L’ingénierie Webex résout ce problème.
-
Webex ne reçoit pas de média de la passerelle locale. L'administrateur client doit enquêter sur le problème.
-
-
Échec de l'optimisation du chemin multimédia— Peu d'appels ne parviennent pas à configurer avec succès l'optimisation du chemin multimé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 Hop.
Certaines des raisons possibles sont :
-
Échec de l'ICE en raison d'un accès au serveur paralysant - voir les informations de référence du port d'appel Webex.
-
ICE a échoué en raison d'une vérification de connectivité - vérifiez la connectivité entre les réseaux.
-
ICE a échoué car le temps d'aller-retour du chemin par défaut était similar/better que n’importe quel chemin optimisé.
-
Limites
Les mesures de qualité des médias et les flux d'origine et de terminaison côté réseau ne sont pas disponibles pour les périphériques 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 flux multimé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 de connectivité interactive (ICE) n'était pas possible ou établi. Dans ce cas, les médias passe par le Cloud d’appel Webex.
-
Hébergé dans le cloud sur le réseau – Appels au sein d'une organisation où le contenu multimédia est fourni par un serveur multimédia hébergé dans le cloud (par exemple, écouter la messagerie vocale, composer un numéro dans un standard automatique).
-
Appel hors réseau vers ou depuis le point de terminaison enregistré Webex Calling -
-
via le 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 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 ê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 des appels échoués et refusés
La colonne État 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 accédez à la liste des appels d'un utilisateur, un KPI Appel échoué 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 pendant le saut d'origine ou de fin.
Exemple de scénarios d'appels échoués
Code d'échec : Aucun itinéraire vers la destination
Une tentative d'appel a été effectuée à partir d'un appareil du lieu de travail, mais a échoué en raison de l'absence d'itinéraire disponible vers la destination.
Code d'échec : Erreur de protocole
Une tentative d'appel a été effectuée par un appareil du lieu de travail mais a échoué en raison d'une erreur liée au protocole.
Code d'échec : Erreur interne
Un appel a été effectué à partir d'une passerelle locale mais a échoué en raison d'erreurs internes avec l'appareil du lieu de travail à destination. L'appel a été établi pendant 14 minutes avant de provoquer une erreur interne.
Exemple de scénarios d'appel de refus
Code de refus : Appel rejeté
Une tentative d'appel a échoué car la tentative n'a pas pu atteindre la destination ou l'interface vers la destination ne fonctionnait pas correctement. Voici quelques exemples de scénarios rejetés :
-
La tentative d'appel est rejetée en raison d'un rejet d'appel anonyme.
-
La tentative d'appel est rejetée en raison des autorisations d'appel entrant.
-
La tentative d'appel est rejetée en raison des autorisations d'appel sortant.
-
La tentative d'appel est rejetée en raison des autorisations d'appel sortant.
-
La tentative d'appel est rejetée en raison de l'interception d'appel configurée.
-
La tentative d'appel est rejetée en raison d'un échec de parcage d'appel ou de récupération d'appel.
-
La tentative d'appel est rejetée en raison du rejet du push-to-talk.
-
La tentative d'appel est rejetée en raison d'une acceptation sélective des appels.
-
La tentative d'appel est rejetée en raison d'un rejet d'appel sélectif.
-
La tentative d'appel est rejetée en raison d'erreurs telles qu'un numéro inconnu, des autorisations insuffisantes, etc.
Code d'échec : Numéro non attribué
Une tentative d'appel a été effectuée par un appelant mais a été rejetée car la destination était vers un numéro non attribué.
Motifs du résultat 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 :
|
