Lors de la maintenance d’un téléphone SIP antidéflagrant, une réponse 200 OK à une transaction REGISTER confirme uniquement que le terminal a correctement établi une liaison d’adresse authentifiée avec le serveur d’enregistrement. Elle ne garantit pas qu’un INVITE puisse être correctement routé, que SDP puisse négocier un codec compatible ni que les médias RTP puissent circuler dans les deux sens entre le téléphone antidéflagrant et le correspondant distant. Autrement dit, l’état « Enregistré » ne décrit qu’une partie de la joignabilité du plan de contrôle SIP, et non la capacité complète d’appel de bout en bout.
C’est pourquoi un téléphone antidéflagrant peut apparaître correctement enregistré tout en ne sonnant pas, en se connectant sans audio, en n’ayant du son que dans un seul sens ou en se déconnectant immédiatement après le décrochage. Dans de nombreux cas, le serveur d’enregistrement n’est pas la véritable source de la panne. Le problème se situe dans le chemin de signalisation, le chemin média ou la chaîne audio locale après l’enregistrement. Un diagnostic en trois couches — signalisation, médias et audio du terminal — transforme une plainte vague du type « enregistré mais impossible d’appeler » en une série d’étapes vérifiables indépendamment et évite les redémarrages répétés de l’équipement dans une mauvaise direction.
Pourquoi « Enregistré » ne signifie-t-il pas que le téléphone peut forcément appeler ?
Il faut d’abord comprendre ce que fait réellement l’enregistrement. Une requête REGISTER envoyée par le terminal contient généralement plusieurs champs importants : Request-URI, qui identifie le domaine d’enregistrement ; To, qui représente le compte enregistré, ou Address-of-Record (AOR) ; Contact, qui indique l’adresse actuellement joignable du terminal, généralement une adresse IP et un port ; et Expires, qui définit la durée de validité de l’enregistrement.
L’enregistrement n’est pas une opération unique. La plateforme conserve dans son service de localisation une relation indiquant qu’un AOR donné est actuellement joignable via un Contact précis. Cette liaison possède une durée d’expiration, souvent configurée autour d’une heure. Le terminal doit renouveler son enregistrement avant l’expiration. Sinon, la plateforme peut finir par considérer ce poste comme hors ligne.
L’authentification nécessite souvent deux échanges. Le terminal envoie d’abord REGISTER sans identifiants, puis le serveur répond par 401 Unauthorized avec des paramètres de challenge tels que realm et nonce. Le terminal calcule alors le digest d’authentification à partir des identifiants du compte et envoie un nouveau REGISTER avec un en-tête Authorization. Ce n’est qu’ensuite qu’il reçoit normalement 200 OK. Du point de vue de la signalisation, « enregistrement réussi » signifie donc que le terminal et le serveur viennent d’achever une transaction REGISTER authentifiée.
Un véritable appel téléphonique exige beaucoup plus. Lorsque l’utilisateur compose un numéro, le terminal doit générer un INVITE. Le PBX, le serveur SIP ou la plateforme de répartition des communications doit router le numéro appelé selon les règles de numérotation et d’autorisation. Les deux extrémités utilisent ensuite SDP pour négocier un codec, une adresse média et un port RTP avant que la voix puisse réellement circuler.
La signalisation et les médias suivent également des chemins distincts. La signalisation SIP utilise couramment UDP/TCP 5060 ou TLS 5061, tandis que RTP emploie normalement une plage séparée de ports UDP dynamiques. Si un pare-feu autorise 5060 mais bloque la plage RTP, l’enregistrement peut parfaitement fonctionner alors que l’appel reste sans audio.
REGISTER réussit
→ Le compte SIP apparaît en ligne
→ INVITE peut toujours être rejeté
→ Même si 200 OK est renvoyé
→ RTP peut encore être bloqué par un pare-feu, un NAT ou une adresse média incorrecte
→ Même si RTP atteint le terminal
→ Le microphone ou le haut-parleur local peut encore être défectueux
Le point essentiel est simple : l’état d’enregistrement est un instantané montrant qu’une transaction a réussi à un moment donné ; il ne prouve pas que la voix de bout en bout est disponible. Il ne prouve même pas que le réseau est joignable à cet instant précis, car l’enregistrement est renouvelé périodiquement et l’état Enregistré affiché peut simplement refléter le dernier renouvellement réussi.
Déterminez d’abord si la panne concerne l’établissement de l’appel ou les médias vocaux
Lorsqu’une personne signale qu’un téléphone est « enregistré mais ne peut pas appeler », la première étape ne doit pas être de modifier les codecs ou les paramètres réseau. Il faut d’abord déterminer précisément ce que signifie « ne peut pas appeler ». Quelques questions suffisent généralement à orienter le diagnostic avant même d’utiliser des outils.
Un appel SIP complet peut être divisé en deux grandes phases. La première est l’établissement de l’appel, qui commence par INVITE et se poursuit jusqu’à ce que le correspondant réponde par 200 OK et que l’appelant envoie ACK. La seconde concerne les médias vocaux : la négociation SDP est alors terminée et le RTP bidirectionnel doit effectivement circuler. La ligne de séparation la plus simple consiste à vérifier si l’interface utilisateur affiche l’appel comme connecté.
Si la composition provoque immédiatement une erreur, s’il n’y a pas de sonnerie ou si le correspondant ne voit jamais d’appel entrant, le problème se situe plus probablement dans la signalisation SIP ou le routage des appels. Si les deux extrémités indiquent que l’appel est connecté et que le compteur d’appel fonctionne, mais qu’il n’y a pas d’audio ou seulement dans un sens, le diagnostic doit se déplacer vers le chemin média SDP et RTP.
| Symptôme | Étape probable | Premières vérifications |
|---|---|---|
| Erreur immédiate à la composition / pas de sonnerie / le correspondant ne reçoit rien | Établissement de l’appel | Routage des numéros, autorisations, codes de réponse SIP, joignabilité de la signalisation |
| L’appel est affiché comme connecté mais il n’y a pas d’audio | Médias vocaux | Adresse média SDP, ports RTP, pare-feu, NAT, codec |
| L’appel se connecte mais l’audio est unidirectionnel | Médias vocaux | Comparer SDP, RTP, les mappages NAT et les flux médias capturés par direction |
| L’appel se coupe après quelques secondes | Établissement + médias | ACK, Session Timer, expiration NAT, politique de libération de la plateforme |
| L’audio est haché ou intermittent | Qualité du transport média | Perte de paquets, gigue, latence, bande passante et changements de ports RTP |
Deux autres schémas sont également utiles. Si le téléphone peut appeler mais ne peut pas recevoir d’appels, la cause est souvent liée au routage des numéros entrants, à l’adresse Contact, au NAT ou au routage de la plateforme. S’il peut recevoir mais pas appeler, il faut plutôt vérifier le plan de numérotation, les autorisations sortantes, le format des numéros ou la configuration du trunk SIP.
Si des extensions SIP ordinaires peuvent s’appeler entre elles mais que les appels vers la console de conduite, le système de diffusion ou le PSTN échouent, le domaine de panne devient beaucoup plus restreint et concerne probablement une route ou une interface particulière.
Un compte rendu terrain utile doit donc répondre à quatre questions :
La panne concerne-t-elle les appels sortants ou entrants ?
L’appel sonne-t-il ?
L’interface affiche-t-elle l’appel comme connecté ?
N’y a-t-il aucun son, un son dans un seul sens, ou l’appel se coupe-t-il après quelques secondes ?
Ces quatre réponses sont bien plus utiles que de simplement dire « le téléphone ne fonctionne pas ».
Quand l’établissement échoue, faut-il vérifier d’abord le numéro, les autorisations ou la réponse SIP ?
Si le problème survient pendant l’établissement de l’appel, suivez d’abord le chemin de signalisation SIP avant de suspecter le matériel du téléphone antidéflagrant. Un ordre pratique est : numéro → autorisations → code de réponse → joignabilité de la signalisation.
Commencez par le numéro et le plan de numérotation. Le Request-URI envoyé par le terminal correspond-il à ce qu’attend la plateforme ? Le poste nécessite-t-il un préfixe ? La numérotation intersystème exige-t-elle un indicatif, un code d’accès ou une traduction de numéro ? De nombreux cas « enregistré mais impossible d’appeler » proviennent finalement d’une différence entre le format de numéro envoyé par le téléphone et les règles de routage configurées dans le PBX.
Par exemple, le téléphone peut envoyer 8001, alors que le PBX attend 8#8001 ou un numéro complet au format E.164. Une capture de paquets montrant le Request-URI de l’INVITE permet de le confirmer immédiatement.
Vérifiez ensuite les autorisations du compte. Certains postes ne peuvent effectuer que des appels internes et n’ont aucun droit vers le PSTN. D’autres peuvent appeler des extensions SIP ordinaires mais pas des lignes d’urgence, des groupes de conduite ou des zones de diffusion. Ce type de configuration de classe de service est particulièrement facile à oublier dans les projets industriels, car l’enregistrement ne teste pas ces autorisations métier. REGISTER répond à « ce compte est-il en ligne ? », tandis que la tentative d’appel répond à « ce compte est-il autorisé à appeler cette destination ? ».
Les codes de réponse SIP permettent ensuite de réduire encore la zone de panne :
| Classe | Réponses courantes | Orientation typique |
|---|---|---|
| 1xx Information | 100 Trying, 180 Ringing, 183 Session Progress | L’établissement progresse ; le problème peut être plus loin ou lié aux médias |
| 2xx Succès | 200 OK | Établissement réussi ; passer au diagnostic média |
| 4xx Échec client | 401/407 authentification, 403 autorisation, 404 introuvable, 408 délai dépassé, 480 indisponible, 486 occupé, 488 incompatibilité de codec | Souvent lié à la configuration du terminal, au routage ou à la politique de service |
| 5xx Échec serveur | 500, 503 Service Unavailable | Côté PBX, SBC ou plateforme de répartition des communications |
| 6xx Échec global | 603 Decline | La destination rejette explicitement l’appel |
Plusieurs réponses reviennent souvent en diagnostic. 401/407 orientent généralement vers le traitement du challenge d’authentification : identifiants, algorithme ou association du compte. 403 doit conduire vers les règles d’autorisation, la politique du compte ou la raison du rejet par la plateforme. 404 peut signifier que le numéro n’existe pas ou qu’aucune route ne correspond. 408 et 480 indiquent plutôt un délai dépassé ou une indisponibilité utilisateur. 488 est souvent associé à des capacités média incompatibles ou à l’échec de négociation d’un codec.
Si la configuration SIP paraît correcte mais que l’INVITE n’atteint jamais le système de destination, revenez au chemin réseau. Vérifiez VLAN, passerelle, pare-feu, règles ACL et adresse de destination réellement utilisée par le téléphone. Le test le plus rapide consiste à capturer le trafic côté serveur. Si l’INVITE arrive mais n’est pas transmis, examinez le routage du PBX ou de la plateforme de répartition des communications. S’il n’arrive jamais, concentrez-vous sur le terminal ou sur le chemin réseau entre le terminal et le serveur.
Si l’appel est connecté mais sans audio ou avec audio unidirectionnel, que faut-il vérifier ?
« Les deux côtés sont connectés, mais il n’y a pas de son » est l’une des pannes SIP les plus fréquentes. À ce stade, la signalisation d’appel est généralement terminée correctement. Le problème est plus probablement lié à la négociation SDP ou au transport RTP. Le diagnostic doit passer du plan de signalisation au plan média.
Commencez par les informations média transportées dans SDP. Plusieurs lignes sont particulièrement importantes : c= identifie l’adresse de connexion, m= définit le média et le port, a=rtpmap associe les types de charge utile aux codecs, et a=sendrecv/sendonly/recvonly définit la direction des médias.
L’adresse audio annoncée par le terminal dans l’INVITE ou le 200 OK doit être joignable depuis le correspondant. Si le terminal place dans SDP une adresse privée non routable telle que 192.168.x.x alors que le pair se trouve sur un autre réseau, l’appel SIP peut tout de même être établi alors que le flux RTP n’atteint jamais sa destination. C’est un cas classique de « connecté mais sans audio ».
Les environnements NAT sont particulièrement exposés à ce problème, et le traitement dépend de l’architecture réseau. La signalisation SIP peut traverser correctement le NAT tandis que le chemin média échoue complètement. Les comportements NAT courants incluent NAT à cône complet, NAT à cône restreint, NAT à cône restreint par port et NAT symétrique, avec des difficultés de traversée croissantes.
Les réseaux industriels résolvent souvent ce problème en utilisant un SBC comme relais média afin d’ancrer RTP sur un point connu. D’autres environnements peuvent utiliser STUN pour découvrir les mappages d’adresse publique, et les déploiements plus complexes TURN ou ICE. Le mécanisme approprié dépend de la topologie réelle. Un REGISTER réussi ne prouve pas que RTP peut traverser le NAT.
Les pare-feu sont une autre cause fréquente. Certains projets n’autorisent que 5060 ou 5061 parce qu’il s’agit des ports SIP évidents, alors que la voix utilise une plage RTP complètement distincte. De nombreux appareils attribuent dynamiquement les ports RTP dans des plages telles que 10000–20000. Si SIP est autorisé mais que RTP est bloqué par une ACL, le résultat est exactement ce que les utilisateurs décrivent : « l’appel est connecté mais il n’y a pas de son ».
L’audio unidirectionnel doit être analysé par sens. Si le poste de contrôle entend le téléphone de terrain mais que l’utilisateur de terrain n’entend pas le poste de contrôle, au moins un sens RTP ou un chemin audio local fonctionne déjà. Au lieu de revérifier tout le réseau, comparez les deux adresses SDP, les ports RTP, les mappages NAT et les flux médias capturés. Les différences selon le sens pointent souvent directement vers le mappage NAT, la règle de pare-feu ou l’adresse SDP incorrecte d’un côté.
Après avoir vérifié le réseau, contrôlez le codec et la chaîne audio locale
La présence de paquets RTP ne garantit pas une voix intelligible. L’étape suivante consiste à confirmer que les deux côtés ont réellement négocié un codec compatible.
La négociation de codec suit le modèle offre/réponse SDP. Le terminal appelant énumère dans le SDP de l’INVITE les codecs qu’il prend en charge, généralement par ordre de préférence. Le terminal appelé en choisit un qu’il prend également en charge et le renvoie dans le 200 OK. Si les deux listes de capacités n’ont aucun codec en commun, la négociation média échoue.
Les codecs courants des téléphones industriels antidéflagrants comprennent G.711 (PCMU/PCMA, 64 kbps et largement compatible avec les environnements PSTN), G.729 pour les liaisons à plus faible bande passante, G.722 pour la voix large bande et Opus sur certains appareils récents. Si le téléphone n’active qu’un groupe de codecs tandis que le PBX, le système d’enregistrement ou la plateforme de répartition des communications en prend en charge un autre, le résultat peut être 488 Not Acceptable Here ou, dans certaines implémentations, un appel connecté avec des médias anormaux.
La bonne méthode consiste à comparer les Payload Types et les listes de codecs dans les deux messages SDP, plutôt que de se limiter à une page d’administration indiquant qu’un codec est activé.
Une fois la négociation de codec et le transport RTP confirmés, passez au chemin audio physique du terminal. Les téléphones antidéflagrants fonctionnent souvent pendant de longues périodes dans des environnements bruyants, humides, poussiéreux ou corrosifs. Un microphone, combiné, haut-parleur, module amplificateur, connecteur ou câble de terrain peut tomber en panne même si la pile SIP fonctionne parfaitement.
Une méthode pratique consiste à comparer les statistiques RTP avec ce qui est réellement entendu sur le site. Si la capture montre un RTP bidirectionnel continu avec un nombre de paquets et une temporisation normaux, mais qu’un côté reste sans audio, vérifiez l’état de coupure du son, le niveau audio et le microphone ou haut-parleur physique. Si RTP est bien transmis mais que le contenu audio est pratiquement silencieux, il faut également examiner la captation du microphone ou la chaîne d’acquisition audio.
Lorsque l’analyse quantitative des médias est disponible, trois indicateurs sont particulièrement utiles : perte de paquets, gigue et latence aller simple. La qualité vocale se dégrade lorsque la perte augmente ; une gigue excessive peut nécessiter un tampon plus important ; et une forte latence aller simple rend la conversation naturelle plus difficile. Si la perte est concentrée sur un saut réseau particulier, une congestion de liaison ou un transport radio peut être en cause.
Pour les postes de diffusion antidéflagrants avec sortie amplifiée, distinguez également le chemin du haut-parleur intégré de toute sortie vers un pavillon externe ou un amplificateur. Ils n’utilisent pas nécessairement exactement le même chemin audio. Le fonctionnement normal du combiné ou du mode mains libres ne prouve pas que l’audio de diffusion externe fonctionne, et l’inverse est également vrai. La mise en service et le dépannage doivent vérifier séparément chaque chemin audio requis au lieu de traiter toute plainte « pas d’audio de diffusion » comme une panne SIP.
Comment une capture de paquets peut-elle réduire rapidement le domaine de panne ?
Pour une panne SIP complexe, changer constamment les paramètres est généralement moins efficace que de capturer un appel en échec complet et de le suivre chronologiquement de REGISTER à BYE. Wireshark suffit dans la plupart des cas. Les points de capture utiles comprennent le côté téléphone, un port miroir du commutateur et le côté SBC ou PBX.
L’emplacement de capture détermine ce qui peut être prouvé. Une trace au niveau du terminal montre exactement ce que le téléphone a envoyé et reçu, ce qui aide à déterminer si le défaut est local. Une trace au niveau du SBC ou PBX montre si la plateforme a correctement reçu et transmis la signalisation. Pour les déploiements traversant des VLAN, des sites ou un SBC, il est préférable de capturer à plusieurs points, car un point unique prouve seulement qu’un message est passé à cet endroit, pas que le segment réseau suivant a fonctionné correctement.
Une fois la trace disponible, suivez l’appel dans cet ordre :
1. REGISTER a-t-il réussi ?
→ 2. INVITE a-t-il réellement été envoyé ?
→ 3. Le PBX l’a-t-il reçu et correctement routé ?
→ 4. Le correspondant a-t-il renvoyé 18x / 200 OK ?
→ 5. SDP a-t-il négocié un codec commun ?
→ 6. Un RTP bidirectionnel est-il réellement présent ?
→ 7. Les adresses IP et ports de destination RTP sont-ils corrects ?
→ 8. Le microphone et le haut-parleur de terrain transmettent-ils réellement l’audio ?
Wireshark fournit des outils utiles. Les messages SIP peuvent être filtrés avec des expressions comme sip ou sip.CSeq. Dans Telephony → VoIP Calls, un appel peut être examiné avec sa séquence de signalisation et les flux RTP associés. L’analyse RTP permet également de mettre en évidence la perte de paquets, la gigue et d’autres indicateurs de qualité média.
L’ordre de dépannage doit rester signalisation d’abord, médias ensuite. Si la signalisation échoue, le problème se situe dans l’établissement de l’appel. Si elle aboutit mais que les médias sont absents, l’analyse doit porter sur le chemin média.
Pour un cas « appels sortants OK, entrants KO », vérifiez si l’INVITE entrant atteint réellement le téléphone antidéflagrant. Si l’appel se coupe systématiquement après quelques secondes ou quelques dizaines de secondes, vérifiez ACK, Session Timer, le mappage NAT et si la plateforme libère la session faute d’avoir reçu un message attendu.
Un autre cas moins évident est la renégociation des médias pendant l’appel. Un re-INVITE peut modifier l’adresse ou le port RTP. Si un mappage NAT échoue pendant cette renégociation, le symptôme peut être « l’appel a fonctionné quelques secondes puis l’audio a disparu ».
L’objectif n’est pas de mémoriser tous les codes de réponse SIP. Posez toujours la même question : quelle est la dernière couche que cet appel a franchie correctement, et où le premier comportement anormal est-il apparu ? Une fois le premier point de panne localisé, une grande partie du dépannage est déjà accomplie.
FAQ
Si un téléphone SIP est affiché comme enregistré, cela prouve-t-il au moins que le réseau fonctionne ?
Non. L’état Enregistré montre seulement que le terminal a pu terminer une transaction d’enregistrement SIP avec le Registrar à un moment donné. Il ne prouve pas que le routage des appels, la joignabilité de la destination, les médias RTP, le NAT, les règles de pare-feu ou le matériel audio du terminal fonctionnent tous. Il ne garantit pas non plus l’absence de perte de paquets ou de forte latence pendant un véritable appel. Comme l’enregistrement est périodique, l’état Enregistré affiché peut simplement refléter le dernier renouvellement réussi.
Les deux côtés sont connectés mais il n’y a pas d’audio. Que vérifier en premier ?
Vérifiez d’abord les adresses IP média, les ports RTP et la négociation de codec dans SDP. Confirmez ensuite que le pare-feu, l’équipement NAT ou le SBC autorise le RTP bidirectionnel. Si le RTP bidirectionnel atteint bien les deux terminaux, passez au microphone, au haut-parleur, à l’état de coupure du son et aux réglages de sortie audio locale. L’ordre pratique est : chemin média d’abord, matériel local ensuite.
Pourquoi le même téléphone antidéflagrant peut-il appeler en interne mais échouer vers le PSTN ?
Les appels entre extensions internes et les appels PSTN utilisent généralement des routes différentes. Les appels externes impliquent aussi des autorisations sortantes, la traduction des numéros, la configuration du trunk SIP, le routage opérateur et les règles d’identification de l’appelant. Le succès d’un appel extension-à-extension prouve seulement qu’une partie du chemin SIP et média fonctionne. Les appels PSTN doivent encore traverser le trunk et le réseau de l’opérateur, ce qui ajoute des exigences de routage et de politique.
L’enregistrement est normal, mais le son est haché ou l’appel se coupe en cours de route. Quelles causes possibles ?
Le problème se situe souvent dans la qualité du transport média : perte de paquets, gigue excessive, bande passante insuffisante ou mappage NAT expiré peuvent interrompre RTP pendant l’appel. Vérifiez d’abord la perte et la gigue RTP, puis la capacité de liaison et la couverture radio le cas échéant. Si les appels se coupent systématiquement après un intervalle prévisible, examinez également la renégociation média par re-INVITE et le comportement du Session Timer.
Pourquoi le remplacement du téléphone résout-il le problème alors que l’unité d’origine échoue toujours ?
Cela pointe souvent vers la configuration, le firmware ou le matériel local du téléphone d’origine plutôt que vers le réseau. Les causes possibles comprennent un défaut de firmware, des paramètres SIP incorrects comme l’expiration d’enregistrement, la gestion NAT ou la plage de ports RTP, ou une panne du DSP ou du module audio. Comparez les deux appareils paramètre par paramètre, notamment les listes de codecs, ports SIP et réglages NAT, plutôt que d’attribuer immédiatement la différence à un réseau instable.
Redémarrer un téléphone SIP antidéflagrant est-il une méthode de dépannage valable ?
Un redémarrage peut parfois restaurer temporairement l’enregistrement, renouveler un mappage NAT ou débloquer un processus, mais il ne doit pas remplacer l’isolation de la panne. Si la cause est la configuration du plan de numérotation, les autorisations SIP, les règles de pare-feu, la négociation des codecs ou le routage média, le redémarrage peut seulement masquer brièvement le problème ou ne rien changer. Une meilleure méthode de maintenance consiste à consigner les symptômes, conserver les traces de signalisation et les journaux, puis déterminer si le premier défaut se trouve dans le terminal, le réseau ou la plateforme de communication.
Becke Telcom peut contribuer au dépannage en fonction de l’architecture réelle du terminal, de l’IP PBX, du trunk SIP, de la commutation réseau, du SBC et du système de conduite. Becke Telcom propose également des téléphones antidéflagrants, des téléphones de diffusion antidéflagrants, des passerelles SIP, des systèmes de diffusion IP et des équipements de conduite unifiée pour les environnements industriels pétrochimiques, énergétiques, miniers, de tunnels et autres.
