Circonscrire un problème d'appel : la démarche pas à pas

À quoi cela sert

« L'appel de 10 h 42 n'a pas abouti. » La plupart des signalements d'incident commencent ainsi ou de façon similaire. Ce chapitre décrit une démarche fixe pour transformer un tel signalement en constat documenté : de quel appel il s'agissait, comment il s'est terminé, où il a échoué et quelles en sont les preuves.

EasyUC propose plusieurs outils à cet effet. La liste des appels montre les appels terminés à partir des CDR. Le diagnostic d'appel récupère dans les traces le flux SIP d'un appel connu. L'analyse d'appels extrait tous les appels d'une période, y compris ceux qui n'ont jamais abouti. Live Calls montre ce qui est en cours à l'instant. Pour les appels Teams passant par le SBC intégré, il existe l'historique des appels.

Le temps est décisif. Les traces du CUCM sont écrasées après quelques heures. Commencez donc l'examen le jour même si possible.

Prérequis

Rôle ROLE_APP_CALL_DIAGNOSTICS. Il inclut l'accès en lecture à la liste des appels.
L'import CDR de la connexion CUCM fonctionne.
Sur le CUCM, Cisco CallManager utilise le niveau de trace Detailed avec Enable SIP Call Processing Trace.
De la part de la personne qui signale le problème : l'heure aussi précise que possible, son propre numéro, le numéro de l'autre participant, le sens de l'appel et ce qu'elle a entendu ou vu.
Pour les appels passant par un CUBE : capture de débogage activée sur le CUBE si vous souhaitez voir le segment vers l'opérateur.

Pas à pas : consigner le signalement

Demandez l'heure et prévoyez une imprécision de quelques minutes.
Notez le numéro de l'appelant et le numéro composé, sous la forme dans laquelle il a été composé.
Clarifiez le sens : externe vers interne, interne vers externe ou interne.
Demandez ce que la personne a remarqué : tonalité d'occupation, retour d'appel sans réponse, annonce, silence, coupure immédiate ou coupure pendant la conversation.
Demandez si le problème s'est produit une seule fois ou s'il peut être reproduit.
Dans EasyUC, sélectionnez dans l'en-tête la connexion CUCM par laquelle l'appel est passé.

Pas à pas : retrouver l'appel

Ouvrez Reporting → Nutzung & Erreichbarkeit → Calls.
Restreignez la période à quelques minutes avant et après l'heure indiquée et recherchez l'un des deux numéros.
Si l'appel figure dans la liste, cliquez sur Analyze dans sa ligne et lancez le diagnostic d'appel. Poursuivez à la section suivante.
Si l'appel ne figure pas dans la liste, ouvrez Logs → Call Analysis.
Choisissez la période, par exemple Custom period avec 15 minutes autour de l'heure indiquée, et les deux sources de données.
Sous Filters (optional), saisissez le Number connu et cliquez sur Pull calls.
Recherchez le numéro dans la liste des appels de l'exécution. Les appels dont la source est SIP only sont des appels que le CUCM n'a pas écrits dans les CDR.
Si vous n'y trouvez rien non plus, l'appel n'a pas atteint le CUCM. Poursuivez alors la recherche sur la passerelle, sur le CUBE ou auprès de l'opérateur.

Pas à pas : évaluer l'appel

Lisez le Result de l'appel : répondu, occupé, sans réponse, rejeté, injoignable, abandonné par l'appelant ou échoué.
Lisez les Causes des deux côtés et Ended by.
Comparez Dialled et Reached. S'ils diffèrent, lisez la Redirect chain.
Ouvrez le flux d'appel. Recherchez la première réponse rouge et établissez de quelle voie elle provient.
Cliquez sur cette réponse et sur l'INVITE qui la précède. Lisez le numéro de destination, l'émetteur et le SDP.
Pour les réclamations portant sur la qualité audio, ouvrez l'onglet Media / quality dans l'analyse d'appels et lisez le codec, la perte de paquets, la gigue et le MOS.
Dans l'onglet Devices, ouvrez le téléphone ou l'utilisateur concerné pour vérifier sa configuration.
Exportez les preuves : dans le diagnostic d'appel SIP messages (text) et Download SVG, dans l'analyse d'appels Export → Everything (JSON).

Champs et options : quel outil pour quel usage

Champs et options : quel outil pour quel usage
Champ / action	Signification et utilisation
Liste des appels (Reporting)	Appels terminés à partir des CDR avec heure, numéros, durée et cause. Le premier endroit à consulter lorsque l'heure et le numéro sont connus. Les appels n'apparaissent qu'après l'intervalle CDR du CUCM et l'import.
Diagnostic d'appel	Flux SIP d'un seul appel connu, à partir des traces de tous les nœuds CallManager. Fenêtre de temps d'une seconde à 30 minutes.
Analyse d'appels	Tous les appels d'une période à partir des CDR et des traces, y compris les appels non aboutis ou encore en cours. Avec flux d'appel jusqu'à 60 minutes, avec les CDR seuls jusqu'à 24 heures.
Live Calls	Appels en cours dans le cluster. Adapté lorsque le problème peut être reproduit.
Journal CURRI	Montre si une règle a rejeté ou redirigé l'appel. Le diagnostic d'appel peut être lancé directement depuis ce journal.
Historique des appels dans le tenant Teams	Diagramme en échelle SIP par appel Teams passant par le SBC intégré.
Capture de débogage du CUBE	Ajoute au flux le segment entre le CUBE et l'opérateur.
Historique des enregistrements	Montre si le terminal de destination était enregistré au moment de l'appel.

Champs et options : constats typiques

Champs et options : constats typiques
Champ / action	Signification et utilisation
Occupé alors que personne n'est en communication	`486` vient du CUCM sans `INVITE` vers la destination : le seuil d'occupation (busy trigger) de la ligne est atteint, souvent à cause d'un appel en attente ou bloqué. Vérifiez le seuil d'occupation et Live Calls.
Un appel externe n'arrive pas	Aucun appel dans les CDR ni dans les traces : il n'a pas atteint le CUCM. `404` du CUCM : le numéro arrive dans un format qui ne correspond à aucun modèle. Lisez le numéro de destination dans l'`INVITE`.
Un appel sortant externe échoue immédiatement	`503` ou `403` depuis la voie du trunk : trunk en défaut, canaux occupés ou numéro appelant non admis.
Cela sonne, mais personne ne décroche	`180 Ringing`, puis `CANCEL` de l'appelant ou un renvoi. Ce n'est pas une erreur technique. Vérifiez la durée de sonnerie et le renvoi sur non-réponse.
L'appel aboutit à la mauvaise destination	Dialled et Reached diffèrent. La chaîne de redirection indique qui a redirigé.
Pas d'audio ou audio dans un seul sens	Signalisation complète avec `200 OK` et `ACK`. Comparez le SDP des deux côtés. L'erreur se situe dans le chemin média : pare-feu, routage ou NAT.
Coupure après des durées fixes	`BYE` après la même durée à chaque fois : une temporisation de session (session timer) ou un pare-feu met fin à la connexion. Lisez les écarts dans la colonne de l'heure.
Mauvaise qualité audio	Qualité Fair ou Poor avec perte de paquets ou gigue. Vérifiez le chemin réseau du terminal qui signale ces valeurs.

Contrôler le résultat et circonscrire les erreurs

Un constat est complet lorsqu'il contient cinq éléments : l'heure et les numéros de l'appel, le résultat, la cause, l'endroit du flux avec le message décisif et les preuves exportées.
L'appel date de plus de deux heures et le diagnostic ne trouve aucun message : les traces ont été écrasées sur le CUCM. Les CDR restent disponibles et fournissent le résultat et la cause, mais pas de flux d'appel.
La liste des appels ne montre pas encore l'appel : les CDR arrivent avec un délai. L'analyse d'appels avec la source des traces le montre immédiatement.
Plusieurs appels correspondent à l'heure et au numéro : comparez les terminaux et la durée. Le diagnostic d'appel liste les Other matching calls.
Le flux d'appel manque pour un terminal SCCP ou sur un port analogique : pour ces terminaux, il n'existe que des CDR.
Si le problème peut être reproduit, reproduisez-le et lancez le diagnostic d'appel juste après. Pour les appels passant par le CUBE, activez au préalable sa capture de débogage.
Ne transmettez les exports qu'au destinataire prévu. Ils contiennent des numéros de téléphone et des noms de terminaux. Les identifiants de connexion et les clés sont supprimés.