En téléphonie IP, on ne corrige bien que ce que l’on observe. Un appel qui « ne marche pas », une voix qui se hache, un poste qui ne s’enregistre pas : derrière chaque symptôme, des messages SIP et des paquets média circulent et racontent précisément ce qui se passe. Deux outils permettent de les lire. sngrep offre un diagnostic immédiat en console, idéal pour un problème en cours. Homer conserve l’historique sur la durée et mesure la qualité, indispensable pour comprendre les incidents intermittents. Ce tutoriel vous apprend à utiliser les deux, du dépannage ponctuel à la supervision continue.
Prérequis
- Un serveur de téléphonie sous Asterisk (FreePBX ou Issabel inclus) accessible en SSH.
- Des droits root pour installer les outils et capturer le trafic réseau.
- Pour Homer, un second serveur ou une machine dédiée à la collecte est recommandé.
- Les notions de signalisation SIP et de média RTP (voir le guide principal).
- Niveau : avancé. Temps estimé : 1 heure.
Signalisation et qualité : deux choses à observer
Avant de capturer quoi que ce soit, distinguons ce que l’on cherche. Les problèmes de téléphonie se rangent en deux familles. Les problèmes de signalisation concernent l’établissement de l’appel : un poste qui ne s’enregistre pas, un appel rejeté, un transfert qui échoue. Ils se lisent dans les messages SIP. Les problèmes de qualité média concernent la voix elle-même : son haché, écho, coupures. Ils se mesurent via les statistiques RTCP, qui renseignent la gigue, la perte de paquets et le score de qualité MOS.
sngrep excelle sur la première famille : il montre les dialogues SIP en temps réel. Homer couvre les deux et, surtout, les conserve dans le temps, ce qui permet de corréler un appel de mauvaise qualité signalé hier avec les mesures correspondantes. On commence donc par sngrep pour le diagnostic immédiat, puis on déploie Homer pour la vision durable.
Étape 1 — Installer et lancer sngrep
sngrep est un petit outil en ligne de commande, disponible dans les dépôts des distributions courantes. Son installation est immédiate.
apt -y install sngrep
Une fois installé, lancez-le simplement en tapant son nom. Il commence aussitôt à capturer le trafic SIP sur les interfaces réseau du serveur et affiche, en temps réel, la liste des dialogues en cours.
sngrep
L’écran se remplit alors d’une liste de dialogues SIP, chacun correspondant à un appel ou à un enregistrement. Chaque ligne indique la méthode, les participants et l’état. C’est déjà une mine d’informations : si un poste tente de s’enregistrer et échoue, vous verrez apparaître le REGISTER et la réponse d’erreur du serveur, ce qui pointe immédiatement la cause.
Étape 2 — Lire un dialogue SIP
La force de sngrep est sa vue en diagramme de flux. Sélectionnez un dialogue dans la liste et validez : sngrep affiche alors la chronologie complète des messages échangés entre les parties, de l’INVITE initial jusqu’au BYE final, avec les codes de réponse intermédiaires. On lit l’appel comme une conversation : qui a dit quoi, dans quel ordre, et où ça a coincé.
Cette lecture rend le diagnostic limpide. Un appel qui se termine par un 403 Forbidden signale un problème d’autorisation ; un 486 Busy Here indique un poste occupé ; l’absence de réponse à un INVITE trahit un trunk injoignable. Vous pouvez aussi sauvegarder un dialogue au format pcap pour l’analyser ailleurs ou le joindre à un ticket. Pour quitter les différentes vues, les touches de retour vous ramènent à la liste, et la touche de sortie ferme l’outil.
Étape 3 — Pourquoi Homer prend le relais
sngrep est parfait pour un problème observé en direct, mais il a une limite : il ne garde rien. Dès que vous le fermez, la capture s’efface. Or beaucoup d’incidents sont intermittents — « hier après-midi, l’appel avec ce client était inaudible » — et impossibles à reproduire à la demande. C’est là qu’intervient Homer : une plateforme qui capture en continu la signalisation et les statistiques de qualité, les stocke en base de données, et offre une interface web pour fouiller l’historique.
Avec Homer, on peut retrouver un appel précis par date, numéro ou identifiant, visualiser son diagramme de flux comme dans sngrep, et surtout consulter ses métriques de qualité. Cette mémoire transforme le diagnostic réactif en analyse posée : on enquête sur un incident passé au lieu d’attendre qu’il se reproduise.
Étape 4 — Comprendre l’architecture de Homer
Homer 7 repose sur trois composants qu’il faut situer. Le premier, heplify-server, est le collecteur : un programme léger, écrit en Go, qui reçoit les données de capture et les écrit en base. Le deuxième est une base de données PostgreSQL qui stocke tout. Le troisième, homer-app, est l’interface web où l’on consulte et recherche les appels. Ces données circulent via un protocole dédié, HEP (Homer Encapsulation Protocol), généralement sur le port 9060 en UDP.
Le principe est donc le suivant : vos serveurs de téléphonie et vos outils de capture envoient une copie de leur trafic, encapsulée en HEP, vers heplify-server, qui la range dans PostgreSQL, et vous la consultez dans homer-app. Cette séparation permet de centraliser la capture de plusieurs serveurs vers un Homer unique, et d’isoler la charge de collecte du serveur de téléphonie lui-même. Installez ces composants sur une machine dédiée pour ne pas alourdir le PBX.
Étape 5 — Envoyer le HEP depuis Asterisk
Asterisk sait nativement envoyer son trafic à Homer, depuis la version 12, grâce au module res_hep et à ses compagnons pour le SIP et les statistiques RTCP. La configuration se fait dans le fichier /etc/asterisk/hep.conf, où l’on indique l’adresse du collecteur Homer.
[general]
enabled = yes
capture_address = IP_DU_SERVEUR_HOMER:9060
capture_password = un_secret
uuid_type = call-id
La ligne enabled = yes active l’envoi, capture_address pointe vers votre collecteur Homer sur le port HEP, et capture_password sécurise la transmission si Homer l’exige. Après avoir sauvegardé, rechargez le module depuis la console Asterisk avec module reload res_hep.so. À partir de cet instant, chaque appel traité par Asterisk est dupliqué vers Homer, qui l’enregistre avec ses statistiques. Vérifiez dans l’interface Homer que de nouveaux appels apparaissent : c’est la preuve que la chaîne fonctionne.
Étape 6 — Envoyer le HEP depuis sngrep
sngrep peut lui aussi alimenter Homer, ce qui est utile pour capturer depuis un point du réseau où Asterisk n’est pas présent. Il dispose d’une option pour relayer en HEP ce qu’il capture, tout en restant utilisable en mode sans interface pour tourner en arrière-plan.
sngrep -H udp:IP_DU_SERVEUR_HOMER:9060
Cette commande capture le SIP local et l’expédie en HEP vers votre collecteur Homer, en plus de l’afficher. Combinée au mode sans interface, elle transforme n’importe quelle machine en sonde de capture discrète. C’est une façon souple de couvrir des points du réseau que les agents natifs ne touchent pas, sans déployer d’agent supplémentaire.
Étape 7 — Lire la qualité dans Homer
Une fois les données qui affluent, l’interface de Homer devient votre poste d’observation. Pour un appel donné, vous retrouvez son diagramme de flux SIP, mais aussi ses indicateurs de qualité issus des rapports RTCP : la gigue, la perte de paquets et le score MOS. Un MOS proche de 4 ou plus indique une bonne qualité ; une chute vers 3 ou moins, corrélée à une perte de paquets élevée, explique une voix hachée.
Cette lecture oriente l’action. Une perte de paquets concentrée sur un site signale un problème réseau localisé ; une gigue généralisée pointe une liaison saturée ; un MOS dégradé uniquement sur les appels passant par un trunk précis incrimine ce trunk ou l’opérateur. En croisant ces indicateurs avec l’heure et le chemin de l’appel, on passe de « la qualité est mauvaise » à un diagnostic précis et donc actionnable. C’est exactement ce que la capture ponctuelle ne permet pas et que la mémoire de Homer rend possible.
Sauvegarder et partager une capture
Quand un incident dépasse vos compétences ou doit être transmis à un opérateur, la capture devient une pièce à conviction. sngrep permet d’enregistrer un ou plusieurs dialogues au format pcap, le format universel des analyseurs réseau. Ce fichier peut ensuite être ouvert dans un outil comme Wireshark pour une analyse approfondie, ou joint à un ticket de support. Un opérateur confronté à « vos appels coupent » réagira bien plus vite face à une capture pcap montrant précisément où la signalisation échoue qu’à une description verbale.
Quelques bonnes pratiques rendent ces captures exploitables. Capturez au plus près du problème : sur le serveur si l’incident concerne la signalisation interne, en frontière si c’est l’opérateur qui est en cause. Notez l’heure exacte et l’identifiant de l’appel concerné, car une capture contient souvent des centaines de dialogues parmi lesquels il faut retrouver le bon. Et limitez la durée de capture au strict nécessaire : un fichier de plusieurs gigaoctets est ingérable, alors qu’une capture ciblée de quelques minutes autour de l’incident se partage et s’analyse facilement.
Gardez enfin à l’esprit la dimension de confidentialité. Une capture de signalisation révèle qui appelle qui, et une capture média contient la voix elle-même. Ces fichiers doivent être traités comme des données sensibles : transmis par un canal sûr, conservés le temps strictement utile, puis supprimés. Le diagnostic ne justifie pas de laisser traîner des enregistrements de conversations sur un disque partagé.
Erreurs fréquentes
| Erreur | Cause | Solution |
|---|---|---|
| sngrep n’affiche aucun dialogue | Mauvaise interface ou pas de trafic | Vérifier l’interface capturée et générer un appel de test |
| Aucun appel dans Homer | res_hep désactivé ou mauvaise adresse |
Activer hep.conf, vérifier capture_address et recharger |
| Signalisation visible mais pas de qualité | RTCP non envoyé à Homer | Activer la capture RTCP côté Asterisk |
| HEP bloqué entre serveurs | Port 9060 fermé au pare-feu | Autoriser le port HEP entre PBX et collecteur |
| MOS toujours bas | Perte de paquets ou gigue réseau | Corriger la QoS réseau, vérifier le codec et la bande passante |
Tutoriels associés
- Le contexte WebRTC : activer WebRTC sur Asterisk.
- Le relais média : déployer un serveur TURN coturn.
Pour aller plus loin
- Retour au guide : Téléphonie IP avancée : 3CX, Issabel et softphones WebRTC.
- Projets officiels : sngrep et SIPCAPTURE / Homer.
Questions fréquentes
sngrep ou Homer, lequel utiliser ?
Les deux, à des moments différents. sngrep pour un diagnostic immédiat sur un problème en cours ; Homer pour l’historique, la qualité et les incidents intermittents. sngrep peut d’ailleurs alimenter Homer, les deux sont complémentaires.
Faut-il un serveur dédié pour Homer ?
C’est recommandé. La capture continue et le stockage en base sollicitent des ressources ; les isoler du PBX évite que la supervision ne pèse sur le traitement des appels. Pour un petit volume, une cohabitation reste possible.
Que signifie un MOS de 3,5 ?
Une qualité moyenne, perceptible comme « correcte mais imparfaite ». L’objectif est 4 ou plus. En dessous de 3,5, la gêne devient nette ; il faut alors examiner la perte de paquets et la gigue pour en trouver la cause.
Capturer le trafic respecte-t-il la confidentialité ?
La capture porte sur la signalisation et les métriques, pas nécessairement sur le contenu audio. Si vous capturez aussi le média, traitez ces données comme sensibles : accès restreint, conservation limitée, et information des utilisateurs conformément aux règles applicables.
sngrep fonctionne-t-il avec FreePBX et Issabel ?
Oui, puisque tous deux reposent sur Asterisk. sngrep capture le trafic SIP du serveur quelle que soit l’interface d’administration ; il s’installe et s’utilise de la même manière, et reste l’outil de diagnostic en console le plus rapide sur ces plateformes.
Quels indicateurs surveiller en priorité dans Homer ?
Trois suffisent pour l’essentiel : le score MOS pour la qualité ressentie, la perte de paquets pour repérer un problème réseau, et la gigue pour détecter une liaison instable. Suivis dans le temps et croisés avec le chemin de l’appel, ils orientent presque toujours vers la cause réelle.
Peut-on capturer le trafic chiffré (TLS) ?
Le SIP sur TLS est chiffré sur le réseau, donc une capture passive ne le révèle pas en clair. Pour l’observer, on s’appuie sur les agents natifs comme res_hep dans Asterisk, qui envoient la signalisation à Homer avant chiffrement, plutôt que sur une capture réseau brute.