Un téléphone SIP antidéflagrant peut afficher l’état Enregistré alors que les appels ne sonnent pas, se connectent sans son ou se coupent après la réponse. L’enregistrement, l’établissement d’appel, le transport des médias et le circuit audio physique nécessitent des vérifications distinctes. Identifiez la première étape défaillante avant de modifier les réglages ou de remplacer le téléphone.
Commencez par les journaux distants et un appel d’essai autorisé. L’inspection physique en zone dangereuse exige du personnel compétent, les permis du site, la consignation et le respect des instructions de l’équipement. N’ouvrez pas une enveloppe sous tension et ne raccordez pas un ordinateur portable ou un instrument de test ordinaire en zone dangereuse sans les mesures requises. Le diagnostic réseau n’établit pas l’intégrité de la protection contre les explosions.
Ce que prouve l’enregistrement et ce qu’il ne teste pas
Une transaction REGISTER réussie confirme l’acceptation de la demande par le serveur d’enregistrement ; examinez les associations Contact et leur expiration pour en comprendre le résultat. L’authentification est courante, mais 200 OK ne prouve pas à lui seul qu’elle a eu lieu. L’état affiché peut correspondre à un rafraîchissement antérieur plutôt qu’à l’accessibilité actuelle.
Un appel exige encore qu’INVITE atteigne la bonne destination, qu’une description de session soit acceptable et qu’un circuit audio fonctionne. Le Contact du terminal, le routage du PBX, une passerelle ou un SBC et la destination des médias peuvent faire intervenir des adresses et politiques différentes. Un téléphone analogique antidéflagrant raccordé par une passerelle FXS doit être diagnostiqué à travers cette passerelle ; il ne constitue pas lui-même un terminal SIP natif.
Classez le symptôme avant de modifier la configuration
| Symptôme observé | Premiers éléments à recueillir |
|---|---|
| Absence de sonnerie ou erreur immédiate | INVITE sortant, destination, réponse finale et route du PBX. |
| Connexion sans audio ou audio unidirectionnel | Adresses et ports SDP, puis arrivée des médias dans chaque sens. |
| Coupure après la réponse | Réception d’ACK, émetteur de BYE, temporisateurs de transaction et journaux de la plateforme. |
| Voix hachée ou intermittente | Lacunes de séquence RTP, gigue, charge de liaison et comportement audio local. |
Consignez l’heure, les numéros appelant et appelé, le sens, le micrologiciel, la topologie et les changements récents. Vérifiez si les destinations internes, externes, de dispatch et de sonorisation échouent de la même manière. Un défaut propre à une route diffère d’un défaut touchant tous les appels ; conservez une trace de l’échec avant de redémarrer ou de modifier la configuration.
Étape 1 : suivez la signalisation jusqu’à la première défaillance
Comparez le numéro composé au Request-URI réel et au plan de numérotation du PBX. Vérifiez les préfixes, la traduction des numéros, les droits de sortie et la route vers le poste ou le trunk prévu. Pour les échecs entrants, vérifiez le Contact actuellement enregistré et l’arrivée de l’INVITE entrant au téléphone.
Les codes de réponse sont des indices, pas des diagnostics complets. Un premier 401 ou 407 peut être un défi d’authentification normal ; recherchez une boucle ou le rejet d’une nouvelle tentative authentifiée. Un 403 signifie un refus, 404 indique que l’utilisateur ou le domaine visé est introuvable, 408 un délai dépassé et 480 une indisponibilité temporaire. Un 488 peut rejeter des caractéristiques de session au-delà d’une simple incompatibilité de codecs. Lisez les détails de la réponse et les journaux du système qui l’a générée.
Si le PBX ne reçoit jamais INVITE, comparez les résultats DNS, le VLAN, la passerelle, le transport, le port de destination et les règles d’accès. S’il reçoit la demande sans la transférer, examinez son routage et ses politiques. Pour un INVITE auquel il a été répondu, vérifiez 200 OK et ACK sur les segments d’appel concernés ; l’affichage d’une connexion ne prouve pas l’achèvement de tous les échanges.
SIP utilise souvent le port 5060, ou 5061 avec TLS, mais d’autres ports sont possibles. Vérifiez le transport et les points d’écoute configurés plutôt que d’ouvrir une plage présumée. Avec TLS, une capture réseau ordinaire ne révèle pas le contenu SIP chiffré ; utilisez les diagnostics autorisés du terminal ou du serveur.
Étape 2 : comparez SDP au chemin réel des médias
Examinez le SDP négocié, notamment c=, m=, a=rtpmap et les attributs de direction tels que a=sendrecv. Vérifiez les informations de connexion au niveau session et média, les formats acceptés et les flux rejetés ou inactifs. L’offre/réponse peut figurer dans différents messages SIP ; ne supposez pas qu’INVITE et 200 OK contiennent toujours toute la négociation.
Vérifiez que chaque adresse et port de média annoncé est accessible dans la topologie déployée. Une adresse privée pose problème lorsque le correspondant ne peut pas la joindre par routage, et non simplement parce qu’elle est privée. Comparez les paquets de part et d’autre d’un pare-feu ou d’une frontière NAT afin de situer l’arrêt d’un sens. Autorisez les flux de médias configurés ; aucune plage de ports RTP n’est universelle pour tous les téléphones.
Un SBC peut ancrer les médias s’il est configuré pour cela. STUN, TURN et ICE ont des rôles différents et exigent une prise en charge compatible du terminal et de la plateforme ; aucun n’est une option universelle de résolution du NAT. Examinez la conception avant de modifier SIP ALG ou le comportement du pare-feu, et conservez une procédure de retour arrière.
Comparez les types de charge utile acceptés, les paramètres de codecs, la mise en paquets et les exigences RTP/SRTP sur chaque segment. Une passerelle ou un PBX ne peut transcoder que si cette fonction est prise en charge et activée. Une réponse SDP peut accepter plusieurs formats ; il est inexact de supposer qu’elle sélectionne toujours exactement un codec. Ne déduisez pas les codecs pris en charge de l’enveloppe antidéflagrante ou d’un autre modèle.
Si les médias s’arrêtent après une mise en attente, un transfert ou un re-INVITE, comparez les nouvelles adresses, les nouveaux ports et la direction SDP à la session initiale. Pour les coupures à intervalle fixe, examinez le message de libération et les journaux avant d’incriminer un temporisateur de session ou une expiration NAT. Perte RTP et gigue décrivent le transport ; aucune ne prouve qu’un microphone produit une parole exploitable.
Étape 3 : vérifiez la chaîne audio locale et les services requis
Une fois les médias reçus par les bons terminaux, vérifiez la coupure du son, le gain, le combiné, le microphone, le haut-parleur et la sortie audio sélectionnée selon les procédures approuvées. Des paquets bidirectionnels peuvent transporter du silence ou des données indécodables. Comparez avec un appel et un terminal fonctionnels sans supposer que la substitution prouve un défaut matériel ; identifiants, micrologiciel, port de commutateur et réglages réseau peuvent aussi différer.
Testez séparément le combiné, le mains libres et les sorties de sonorisation externe, lorsqu’ils existent. Un combiné fonctionnel ne prouve pas le fonctionnement d’un amplificateur externe, d’un circuit de pavillons ou d’un relais de sonorisation. L’affichage de localisation au dispatch, l’enregistrement, la priorité et le couplage aux alarmes relèvent de la plateforme ou de l’intégration, sauf mise en œuvre explicite par le terminal concerné.
Utilisez des captures synchronisées à des points appropriés et autorisés : diagnostic du terminal, port miroir d’un commutateur, PBX ou SBC. Corrélez le Call-ID SIP et les horodatages, en gardant à l’esprit qu’un SBC peut créer différents segments d’appel. Ne capturez que le trafic nécessaire et protégez journaux et enregistrements. Le SRTP chiffré ne peut être écouté à partir d’une capture ordinaire sans éléments de clé autorisés et méthode d’analyse adaptée.
Après une modification contrôlée, retestez la route défaillante et les deux sens audio, puis les fonctions de sonorisation ou de dispatch affectées et la reprise après tout basculement planifié. Conservez les réglages finaux, la référence de trace et le résultat. Pour les pratiques de supervision et de configuration à plus long terme, consultez la maintenance à distance des téléphones de sonorisation antidéflagrants.
Questions fréquentes
Pourquoi les appels internes fonctionnent-ils alors que les appels externes échouent ?
Les appels externes ajoutent le routage du trunk, les droits, la traduction des numéros et les politiques amont. Comparez le chemin interne fonctionnel à l’appel de trunk défaillant, y compris la signalisation retour et les segments de médias, au lieu de supposer que l’enregistrement teste le trunk.
Faut-il considérer chaque absence d’audio comme un problème de codec ?
Non. Établissez d’abord la session négociée et l’arrivée des médias à chaque terminal. Routage, NAT, règles d’accès, compatibilité SRTP et audio local peuvent tous produire du silence. Un paramètre de codec sur une page web ne prouve pas ce qui a été négocié lors de l’appel.
Un redémarrage constitue-t-il une réparation ?
Un redémarrage peut rétablir un processus ou rafraîchir une association, mais il n’identifie pas la cause. Préservez d’abord les éléments disponibles lorsque c’est possible, puis vérifiez une reprise reproductible. Consignez toute interruption de service et prévoyez le moyen de communication alternatif du site pendant la maintenance.
Références techniques
Base protocolaire : IETF RFC 3261, SIP et IETF RFC 3264, offre/réponse SDP. Contexte de maintenance en zone dangereuse : conseils du HSE sur l’électricité en atmosphères potentiellement explosives.
