Comment lire une trace SIP : guide pratique

Une trace SIP est le seul relevé fiable de ce que votre réseau voix a réellement fait. Les CDR mentent par omission, les tableaux de bord accusent un retard et les rapports d’utilisateurs sont de seconde main. La trace est directe, octet par octet. Pourtant, la plupart des ingénieurs ouvrent un fichier et fixent 8 000 lignes de trafic UDP pendant une demi-heure avant de trouver le message qui explique la panne, alors qu’un lecteur méthodique y parvient en trois minutes.

Ce guide est un flux de travail praticien, pas une référence protocolaire. Il suppose que vous savez déjà ce qu’est un INVITE et ce que signifie un 486. Si ce n’est pas le cas, l’article complémentaire Flux d’appel SIP expliqué étape par étape détaille chaque message d’un appel typique, et Codes de réponse SIP : le guide complet couvre chaque code en détail. Cet article traite de tout ce qui se passe entre « ouvrir la capture » et « j’ai trouvé la cause racine » : d’où viennent les traces, les outils qui les rendent lisibles, la méthode en quatre étapes pour atteindre rapidement le message décisif, les signatures à reconnaître en premier et comment emballer vos preuves dans un ticket qu’un opérateur traitera réellement.

Ce qu’est réellement une trace SIP

L’expression « trace SIP » désigne trois choses différentes, et les confondre fait perdre le plus de temps au début d’une investigation. Un PCAP complet contient chaque octet sur le fil, y compris les en-têtes TCP/UDP, le RTP, le RTCP et tout le reste qui partage la même interface ; c’est ce que produisent tcpdump et Wireshark. Une trace SIP uniquement correspond aux mêmes données filtrées pour ne garder que les messages SIP, souvent stockée sous forme de flux HEP vers une base de données centrale, capturée par le journal interne d’un SBC ou exportée depuis Wireshark avec les trames non-SIP retirées. Un journal SIP est un rendu textuel qu’une application a produit à partir de sa propre pile SIP, généralement avec des horodatages et des en-têtes décodés mais sans les paquets sous-jacents ; utile pour l’état mais pas pour la pathologie protocolaire.

Pour la plupart des pannes, la trace SIP uniquement est le bon artefact : elle capture chaque message de signalisation, permet la corrélation entre les segments et évite la pénalité de taille des paquets audio. Pour les problèmes de média (audio unidirectionnel, voix hachée, DTMF intra-bande manquant), vous avez besoin du PCAP complet, car c’est le seul endroit où le RTP vit réellement. Pour « je ne comprends pas ce que le SBC a fait », la trace interne du SBC est imbattable, car elle montre le message tel que le SBC l’a reçu sur un segment, les modifications appliquées au milieu et le message tel qu’il est reparti sur l’autre segment, le tout dans un seul fichier.

Le corollaire est que lorsque quelqu’un vous remet une trace et vous demande de la regarder, la première question est « quel type de trace, et depuis quel point du chemin ? » Un export SIP uniquement depuis un softswitch ne vous montrera jamais un problème de RTP manquant, peu importe combien de temps vous le fixez.

Où capturer et avec quoi

Le choix du point de capture compte plus que le choix de l’outil. Capturez là où le problème est suspecté, pas là où c’est pratique. Si l’opérateur insiste sur le fait que l’appel a quitté son réseau proprement, capturez sur l’interface côté opérateur du SBC et prouvez quel message est arrivé. Si un appel Teams Direct Routing échoue sur le retour de sonnerie, capturez sur le segment côté Teams du SBC et regardez ce que Teams a envoyé.

Sous Linux, tcpdump est le moteur de capture par défaut et écrit des PCAP que n’importe quel outil peut lire. Une commande typique pour un SBC chargé est tcpdump -i any -s 0 -w trace.pcap, qui capture à la fois le SIP en UDP et TLS plus la plage RTP configurée sur le SBC. Le drapeau -s 0 désactive la troncature snaplen pour que les paquets complets soient écrits ; sans lui, un INVITE de 1 500 octets est tronqué à 96 octets et le corps est manquant. Sur le SBC lui-même, la capture native est presque toujours préférable : elle voit le message au niveau de la couche application, pas seulement le fil, ce qui signifie que le SIP chiffré est déjà déchiffré et que la corrélation des segments B2BUA est automatique.

Wireshark est le standard graphique, et malgré sa courbe d’apprentissage abrupte, c’est l’outil le plus puissant une fois que vous connaissez trois menus. sngrep est l’outil adapté lorsque vous ne disposez que d’un accès SSH et d’un terminal ; son interface ncurses affiche le trafic SIP en direct et les diagrammes en échelle sans avoir besoin de copier un PCAP sur votre poste de travail. HOMER est la bonne réponse pour la rétention et la recherche à travers un parc : chaque SBC et proxy envoie le SIP via HEP vers un nœud de capture central, et une seule interface web vous permet de retrouver un appel d’hier par numéro de téléphone, IP ou Call-ID. ProSBC intègre une trace SIP native, une fonctionnalité de capture Wireshark en direct et un score MOS par appel, faisant du SBC lui-même le point de capture de premier recours pour tout appel l’ayant traversé.

Le flux de lecture en quatre étapes

Chaque session de lecture de trace productive suit les mêmes quatre étapes dans le même ordre. Sauter une étape vous laisse généralement dans l’incertitude.

Étape 1 : limiter le périmètre au seul dialogue qui vous intéresse

Un PCAP typique d’un SBC sur une fenêtre de cinq minutes peut contenir des centaines de dialogues. Essayer de lire le fichier de bout en bout est l’erreur la plus courante. Filtrez agressivement. Si vous avez le Call-ID, filtrez directement dessus : dans Wireshark, sip.Call-ID == "[email protected]". Si vous n’avez qu’un numéro de téléphone, sip.from contains "+15145551234" or sip.to contains "+15145551234" vous amènera en quelques secondes à l’appel. Une fois que vous avez un paquet du dialogue, faites un clic droit et « Suivre » la conversation SIP pour extraire l’échange complet dans sa propre fenêtre.

Si l’appel a traversé un B2BUA, cette étape ne vous donne qu’un segment. Le segment complémentaire a un Call-ID différent. Vous pouvez le retrouver en faisant correspondre les deux sur le temps et le numéro de téléphone, ou sur l’en-tête Contact que le SBC a inséré, ou en consultant la trace interne du SBC où la relation est enregistrée explicitement.

Étape 2 : classifier la phase de défaillance

Avant de lire un message en détail, déterminez quelle phase de l’appel a échoué. Les trois options sont l’établissement d’appel (tout, depuis l’INVITE initial jusqu’au ACK final confirmant la connexion), le mi-appel (après que la session média est pleinement établie mais avant un raccrochage intentionnel) et la libération (BYE et sa réponse). Les défaillances d’établissement sont de loin les plus courantes, et le diagramme en échelle vous indique la phase d’un coup d’œil : si vous ne voyez jamais de 200 OK à l’INVITE, vous êtes en établissement ; si vous voyez un 200 OK suivi de RTP puis un BYE plus tôt que prévu, vous êtes en mi-appel ; si le BYE survient au bon moment mais que l’appel est compté comme échoué dans le CDR, vous êtes en libération ou en comptabilité post-appel.

Étape 3 : lire l’en-tête ou le code décisif

Les défaillances d’établissement se résolvent presque toujours sur l’un de ces trois éléments : le code de réponse final, le corps SDP du 200 OK (ou son absence) et les en-têtes d’authentification dans tout 401 ou 407. Un 488 Not Acceptable Here pointe vers le SDP ; un deuxième 401 ou 407 consécutif ou un 407 suivi d’aucun second INVITE pointe vers une incompatibilité d’authentification ou d’identifiants ; un 408 sans aucune réponse provisoire pointe vers le transport. Les défaillances en mi-appel se résolvent sur l’en-tête Reason du BYE ou son absence, la chronologie RTP et tout re-INVITE intermédiaire. Les défaillances de libération sont inhabituelles ; quand elles surviennent, la numérotation CSeq et les tags From/To vous indiqueront si vous regardez le même dialogue que celui que le CDR pense avoir fermé.

Étape 4 : confirmer dans le média si nécessaire

Si la trace indique que l’appel s’est connecté mais que l’utilisateur n’a rien entendu, la signalisation SIP est innocente et le RTP est coupable. Ouvrez Telephony → RTP → Stream Analysis dans Wireshark, sélectionnez le flux pour le segment concerné et examinez le nombre de paquets, la gigue et le delta. Zéro paquet reçu avec des paquets envoyés non nuls signifie un audio unidirectionnel causé par un problème de NAT. Des paquets réguliers avec des pics de delta de 60 ms ou plus signifient de la gigue causée par une mise en tampon quelque part en amont. Un flux qui dure deux secondes puis s’arrête est une passerelle média qui a planté en plein appel. La signalisation semble correcte dans les trois cas.

Wireshark en pratique

Trois menus portent la quasi-totalité du poids analytique : VoIP Calls, Flow Sequence et la barre de filtre d’affichage. Tout le reste est accessoire.

Telephony → VoIP Calls analyse la capture à la recherche de dialogues SIP et H.323 et les liste dans un tableau avec l’heure de début, la durée, le statut et le codec. C’est le premier endroit où aller sur tout nouveau PCAP, car cela vous indique en cinq secondes combien d’appels sont dans le fichier, lesquels ont réussi et lesquels ont échoué. En sélectionnant un appel et en cliquant sur « Flow Sequence », vous générez un diagramme en échelle montrant chaque message SIP et chaque flux RTP dans l’ordre chronologique, avec horodatages et direction des flèches. Cette vue seule résout la majorité des questions « que s’est-il passé pendant cet appel ».

Le filtre d’affichage est le levier qui transforme des captures de 8 000 paquets en captures de 30 paquets. Les filtres qui valent la peine :

• sip affiche uniquement les paquets SIP.
• sip.Call-ID == "..." isole un dialogue.
• sip.Method == "INVITE" liste chaque tentative d’appel dans le fichier.
• sip.Status-Code >= 400 liste chaque défaillance.
• rtp affiche uniquement les paquets RTP ; rtcp affiche les rapports de qualité.
• tcp.analysis.retransmission révèle les retransmissions TCP lorsque le SIP fonctionne sur TCP.
• frame.time >= "2026-05-25 14:30:00" découpe par temps absolu lorsque vous savez approximativement quand la panne s’est produite.

Pour l’analyse RTP, Telephony → RTP → RTP Streams liste chaque flux audio détecté par Wireshark, avec le nombre de paquets, la gigue, les paquets perdus et les estimations MOS dérivées de ces métriques. Un clic droit sur un flux et le choix « Analyze » vous donne les valeurs de gigue et de delta par paquet ; « Play Streams » décode l’audio lorsque le codec est G.711, ce qui est le moyen le plus rapide de confirmer si l’audio reçu était réellement intelligible.

sngrep quand vous n’avez qu’un terminal

Lorsque la seule chose entre vous et le SBC est une session SSH, sngrep est l’outil adapté. Exécutez sngrep sans arguments et il capture le SIP en direct depuis toutes les interfaces ; exécutez sngrep -I trace.pcap et il ouvre un fichier précédemment capturé. L’interface affiche une liste de dialogues en haut, un diagramme en échelle pour le dialogue sélectionné en bas, et vous permet d’appuyer sur Entrée sur n’importe quel message pour voir les en-têtes complets. Le flux de travail complet décrit ci-dessus (périmètre, classification, décision sur l’en-tête décisif) fonctionne dans sngrep aussi bien que dans Wireshark, et l’avantage de latence du travail directement sur le SBC est significatif quand l’alternative est de copier un PCAP de plusieurs gigaoctets à travers un WAN.

La seule limitation concerne le média. sngrep ne gère que la signalisation, donc lorsqu’une investigation RTP est nécessaire, vous devez revenir à un PCAP. La plupart des flux de production utilisent les deux : sngrep pour le triage rapide sur le SBC, Wireshark pour l’analyse approfondie une fois qu’un appel spécifique a été identifié.

Cinq signatures à reconnaître avant de lire les en-têtes

La plupart des pannes en production correspondent à l’une de cinq signatures de trace. Reconnaître la signature en premier économise le temps que vous passeriez autrement à lire chaque en-tête en séquence.

La tempête de retransmission apparaît sous forme de requêtes SIP identiques répétées avec le même paramètre branch et des intervalles croissants (500 ms, 1 000 ms, 2 000 ms, 4 000 ms, 8 000 ms, 16 000 ms, 32 000 ms avant le déclenchement du Timer B). Cela signifie que le prochain saut n’a jamais envoyé de réponse provisoire. Soit le prochain saut est hors service, soit un pare-feu supprime silencieusement la requête, soit le prochain saut l’a reçue mais ne peut pas la router.

L’abandon du Timer B à 32 secondes est la conséquence de la tempête de retransmission. L’agent utilisateur émetteur abandonne exactement 32 secondes après le premier INVITE et retourne un 408 Request Timeout à l’application. Les appels qui « sonnent pendant 32 secondes puis échouent » sans jamais atteindre le point d’extrémité appelé suivent presque toujours cette signature.

La boucle d’authentification apparaît sous la forme INVITE, 401 Unauthorized (ou 407 Proxy Authentication Required), second INVITE avec un en-tête Authorization, suivi immédiatement d’un deuxième 401 ou 407 consécutif. Le destinataire rejette les identifiants digest. Presque toujours une chaîne realm incompatible entre le SBC et le fournisseur en amont, ou un décalage d’horloge qui invalide le nonce.

L’incompatibilité de codecs apparaît sous la forme INVITE avec une offre SDP listant plusieurs codecs, 488 Not Acceptable Here, aucun média. Les deux côtés n’ont pas pu s’accorder sur un codec. Soit l’offre SDP liste des codecs que le destinataire ne prend pas en charge, soit le destinataire est configuré pour n’accepter qu’un codec que l’émetteur n’a pas offert. La capacité de transcodage d’un SBC correctement configuré masque ce problème aux deux parties.

L’audio unidirectionnel avec signalisation correcte apparaît sous la forme d’une séquence INVITE-200-ACK complète, du RTP circulant dans une direction, aucun RTP dans l’autre, et un BYE 30 à 90 secondes plus tard lorsqu’un côté abandonne. La trace SIP est innocente. La cause est presque toujours un problème de NAT dans la ligne SDP c=, un pare-feu asymétrique ou un chemin média qui ne s’est jamais ouvert d’un côté.

Traces chiffrées et le fichier key-log

Un appel transitant par TLS sur le port 5061 n’est pas lisible dans Wireshark sans les clés de déchiffrement. Il existe trois façons de retrouver la lisibilité. La première est de capturer sur un SBC qui déchiffre le SIP au niveau de la couche application, ce qui rend le chiffrement invisible pour l’outil de trace. La deuxième est de capturer sur le fil et de déchiffrer ultérieurement en utilisant un fichier TLS key-log, défini via la variable d’environnement SSLKEYLOGFILE sur un client qui la prend en charge ; Wireshark lit le journal sous Preferences → Protocols → TLS → « Pre-Master-Secret log filename ». La troisième est d’inspecter le point intermédiaire non chiffré sur un SBC B2BUA, qui termine le TLS en entrée et peut ré-émettre en TLS en sortie ; la trace du journal interne du SBC voit le texte en clair entre les deux.

Le SRTP suit le même principe. L’échange de clés se fait soit dans le corps SDP (SDES, où la clé maître est intégrée en texte clair dans le message SIP), soit via DTLS-SRTP sur le chemin média. Avec SDES, une trace SIP non chiffrée plus la capture RTP correspondante vous donne tout ce dont vous avez besoin pour décoder l’audio. Avec DTLS-SRTP, pas de fichier key-log signifie pas de décodage, et la capture interne du SBC est à nouveau le chemin de moindre résistance.

Le piège du B2BUA : un appel, deux traces

Un SBC B2BUA divise un seul appel en deux dialogues SIP complètement indépendants. Le segment d’entrée possède son propre Call-ID, From-tag, To-tag, compteur CSeq et chaîne Via ; le segment de sortie a des valeurs différentes pour chacun de ces champs. Pour Wireshark, les deux segments sont des dialogues non liés qui partagent simplement une fenêtre temporelle et un numéro de téléphone.

Lire correctement une trace B2BUA implique de corréler les segments explicitement. Les signaux qui les lient sont l’en-tête Contact que le SBC insère (la même adresse SBC apparaît sur les deux segments), la chronologie (l’INVITE du second segment suit toujours l’INVITE du premier segment dans un délai de quelques millisecondes) et les numéros de téléphone dans les URI From et To. La source de corrélation la plus propre, lorsqu’elle est disponible, est le propre journal du SBC, qui enregistre les Call-ID d’entrée et de sortie côte à côte et place les deux segments dans un seul fichier de trace. Une capture prise sur un seul segment induira en erreur tout investigateur non familier avec l’architecture, car la moitié de l’appel semble manquante.

Le même principe s’applique à la manipulation d’en-têtes SIP : un en-tête qui existe sur le segment d’entrée peut avoir été réécrit, ajouté ou supprimé avant d’apparaître sur le segment de sortie. Si un système en aval prétend n’avoir jamais reçu un en-tête que vous pouvez voir dans la trace d’entrée, la trace de sortie est celle qui tranche le débat.

Conditionner les preuves pour un ticket opérateur

La moitié du temps passé sur une trace SIP est destinée à quelqu’un d’autre : l’opérateur ouvrant un ticket P2, l’équipe support du fournisseur de plateforme, l’administrateur pare-feu qui a besoin de prouver que son équipement supprime du trafic. Le format des preuves détermine si le ticket est traité aujourd’hui ou reste dans une file d’attente pendant une semaine.

Le bon artefact est un PCAP filtré ne contenant que le dialogue en question. Dans Wireshark, le flux de travail est File → Export Specified Packets, avec « Marked packets only » ou « Displayed packets » sélectionné après qu’un filtre d’affichage a réduit la vue à un seul Call-ID. Le fichier résultant fait généralement quelques centaines de kilo-octets, s’ouvre proprement dans n’importe quel outil compatible SIP et ne contient rien dont le destinataire n’a pas besoin.

Une bonne pièce jointe de ticket comprend trois éléments. Premièrement, le PCAP filtré sur un seul dialogue. Deuxièmement, une annotation en texte clair nommant le saut suspecté, le message suspecté et le comportement suspecté, sous la forme « INVITE au paquet 47 contient le codec G.729 dans le SDP ; la réponse 488 au paquet 49 indique que l’opérateur ne l’a pas accepté ; veuillez confirmer si G.729 est pris en charge sur cette jonction. » Troisièmement, l’heure, le fuseau horaire et l’ID CDR de l’appel, pour que le destinataire puisse corréler avec ses propres journaux sans devoir deviner.

Anonymisez si nécessaire. Les numéros de téléphone et les adresses IP dans les traces réelles de clients sont régulièrement des données réglementées, et un PCAP transmis à un tiers contient tout ce que la capture originale a vu. Des outils comme tcprewrite et les propres plugins d’anonymisation de Wireshark peuvent remplacer les numéros et les adresses sans casser la structure du message SIP.

Questions fréquentes

Conclusion

Lire une trace SIP consiste principalement à limiter agressivement le périmètre, à classifier la phase de défaillance avant de lire les en-têtes, et à reconnaître les cinq signatures courantes pour que le message décisif soit le troisième ou quatrième que vous examinez, pas le quatre-centième. L’outil que vous utilisez compte moins que la discipline du flux de travail. Wireshark sur un poste de travail, sngrep sur un SBC, la trace intégrée du SBC et un déploiement central HOMER pour la rétention lisent tous les mêmes données sous-jacentes, et un opérateur confiant passe de l’un à l’autre selon que la question immédiate porte sur le média, la signalisation, l’historique ou un litige avec un fournisseur.