Qu’est-ce que le SIP ALG et pourquoi le désactiver

Vous installez un nouveau téléphone VoIP, il s’enregistre correctement, et le premier appel test se connecte. Puis l’audio est unidirectionnel, ou l’appel se coupe à exactement trente secondes, ou le téléphone affiche « Aucun service » une heure plus tard sans raison apparente. Vous vérifiez le fournisseur SIP, les identifiants, les codecs, les règles du pare-feu, et tout semble correct. La cause n’est presque jamais dans aucun de ces éléments. Il s’agit d’un seul paramètre sur le routeur situé devant le téléphone, activé par défaut, appelé SIP ALG.

Le SIP ALG (Application Layer Gateway) est une fonctionnalité intégrée à la plupart des routeurs grand public et de petites entreprises qui inspecte le trafic SIP en transit et réécrit certaines parties du message. L’intention est de faciliter le fonctionnement de la VoIP à travers la traduction d’adresses réseau (NAT). En pratique, c’est la cause la plus courante de pannes VoIP inexpliquées sur les réseaux d’entreprise, et la recommandation standard de l’industrie est de le désactiver. Dans les sections ci-dessous, nous verrons ce que le SIP ALG tente de faire, pourquoi il corrompt le SIP au lieu de l’aider, comment reconnaître et confirmer les symptômes, comment le désactiver sur les routeurs courants, et ce qui gère correctement le problème sous-jacent une fois qu’il est désactivé.

Ce que le SIP ALG fait réellement

Pour comprendre pourquoi le SIP ALG pose problème, il faut commencer par le problème qu’il a été conçu pour résoudre. Le SIP transporte les adresses IP et les ports à l’intérieur du corps du message, pas uniquement dans les en-têtes de paquets, ce qui découle de la façon dont le standard SIP (RFC 3261) et le payload SDP décrivent une session. Un téléphone sur un réseau privé (par exemple 192.168.1.50) inscrit cette adresse privée dans sa signalisation SIP et dans le SDP qui décrit où il souhaite recevoir l’audio. Lorsque le routeur effectue le NAT et envoie le paquet sur l’internet public, il réécrit l’en-tête IP pour que la source apparaisse comme l’adresse publique du routeur. L’adresse privée enfouie dans le message SIP reste inchangée, car le NAT ordinaire ne modifie que les en-têtes de paquets, pas les payloads.

Le résultat est un message SIP qui indique à l’autre partie d’envoyer la signalisation et l’audio vers 192.168.1.50, une adresse qui n’a aucune signification sur l’internet public. Les réponses et l’audio ne vont nulle part. Le SIP ALG a été créé pour combler cette lacune. Il lit l’intérieur du message SIP lorsqu’il traverse le routeur, trouve les adresses privées dans les en-têtes et le SDP, et les réécrit avec l’adresse publique du routeur afin que l’autre partie ait une destination joignable pour répondre. Sur le papier, c’est une idée raisonnable, et c’est la raison pour laquelle les fabricants de routeurs l’activent par défaut : cela permet à un seul téléphone VoIP derrière un routeur basique de fonctionner sans configuration supplémentaire.

Le problème est que pour le faire correctement, il faut analyser le SIP de manière complète et cohérente, un protocole avec de nombreux types de messages, des en-têtes optionnels, le pliage de lignes, des formes d’en-têtes compactes et des variations propres à chaque fabricant. Les firmwares de routeurs grand public en font une analyse rapide et superficielle, et c’est là que tout dérape.

Pourquoi le SIP ALG perturbe le SIP

Le SIP ALG échoue non pas parce que réécrire les adresses est une mauvaise idée, mais parce que les implémentations le font de manière incomplète et incohérente. Quelques modes de défaillance distincts reviennent systématiquement.

Réécritures d’adresses incomplètes et incohérentes

Un ALG qui réécrit l’adresse dans un en-tête mais la manque dans un autre laisse le dialogue SIP décrire deux chemins de retour différents. L’en-tête Via peut être corrigé tandis que l’en-tête Contact ne l’est pas, ou l’adresse de signalisation est corrigée tandis que l’adresse média du SDP est oubliée. Les deux côtés de l’appel ne sont alors plus d’accord sur la destination des paquets, et les symptômes dépendent de l’en-tête qui a été altéré.

SDP altéré et audio unidirectionnel ou absent

Le SDP contient l’adresse et le port où chaque partie s’attend à recevoir l’audio RTP. Lorsqu’un ALG réécrit l’adresse SDP de manière incorrecte, ou réécrit la signalisation mais pas le SDP, l’appel se connecte et les téléphones sonnent, mais l’audio n’a nulle part où aller. Cela produit le défaut classique d’audio unidirectionnel, où une partie peut entendre et l’autre non, ou des appels qui se connectent dans un silence complet. La même famille de symptômes est couverte du côté opérateur dans le guide de dépannage VoIP.

Enregistrement et réécriture du Contact défaillants

Lorsqu’un téléphone s’enregistre, l’en-tête Contact indique au fournisseur où envoyer les appels entrants. Un ALG qui réécrit l’adresse Contact de manière incohérente, ou qui perd le suivi de l’enregistrement lorsqu’il réécrit la gestion de l’expiration, provoque l’échec des enregistrements ou leur expiration silencieuse. Le téléphone affiche « Aucun service », les appels entrants ne sonnent jamais parce que le fournisseur les envoie à une adresse qui ne fonctionne plus, et les enregistrements se rétablissent et tombent selon un cycle qui semble aléatoire vu de l’extérieur.

Appels qui coupent après environ trente secondes

Un appel qui s’établit correctement puis coupe à un intervalle constant, souvent autour de trente secondes, est une signature caractéristique d’une signalisation en cours de dialogue altérée. Le rafraîchissement de session ou l’acquittement qui devrait maintenir l’appel actif est envoyé à une adresse que l’ALG a réécrite incorrectement, il n’arrive donc jamais et l’un des côtés met fin à l’appel.

Le SIP chiffré le rend inutile et nuisible

Lorsque la signalisation SIP est protégée par TLS, le routeur ne peut pas lire le corps du message du tout, l’ALG n’a donc rien à inspecter ou réécrire. Au mieux, il n’apporte aucune assistance utile à la signalisation ; au pire, il interfère avec la gestion du NAT ou l’état de session d’une manière qui perturbe l’appel. Tout déploiement utilisant TLS et SRTP, ce qui inclut Microsoft Teams Direct Routing et la plupart des interconnexions opérateur modernes, ne tire aucun bénéfice du SIP ALG et n’en hérite que les effets secondaires.

Symptômes qui indiquent le SIP ALG

Le SIP ALG s’annonce rarement. Il se manifeste par un ensemble de pannes intermittentes, difficiles à reproduire, qui survivent à chaque modification que vous apportez au téléphone, au fournisseur et aux identifiants. Les symptômes suivants, surtout combinés, pointent fortement vers un ALG dans le chemin :

• Audio unidirectionnel où une partie peut entendre l’autre mais pas l’inverse, ou des appels qui se connectent dans le silence.
• Appels qui coupent à un intervalle constant, fréquemment autour de trente secondes, après un établissement réussi.
• Échecs d’enregistrement où les téléphones affichent « Aucun service » ou alternent entre enregistré et hors ligne sans schéma apparent.
• Appels entrants qui ne sonnent pas tandis que les appels sortants fonctionnent, parce que le fournisseur ne peut pas joindre l’adresse annoncée par l’ALG.
• Transfert d’appel, mise en attente ou DTMF défaillants, où la signalisation en cours d’appel qui modifie la session est la partie corrompue.
• Pannes qui suivent le routeur, où les mêmes téléphones et le même fournisseur fonctionnent parfaitement sur un autre réseau.

Comment confirmer que le SIP ALG est en cause

Les symptômes se recoupant avec des défauts ordinaires de NAT et de pare-feu, il vaut la peine de confirmer spécifiquement le SIP ALG plutôt que de désactiver des paramètres au hasard. La méthode fiable consiste à comparer les messages SIP de chaque côté du routeur. Capturez le trafic SIP tel que le téléphone l’envoie côté privé, puis capturez les mêmes messages tels qu’ils sortent du routeur côté public, et comparez les adresses Contact, Via et SDP.

Si les adresses à l’intérieur du message ont été modifiées entre les deux captures, et modifiées de manière incohérente ou pointant vers une adresse inaccessible, un ALG réécrit le trafic. Un équipement NAT propre laisse le payload SIP intact et ne réécrit que les en-têtes de paquets. La lecture de ces captures est un savoir-faire en soi, et la même technique localise la plupart des défauts de signalisation, pas seulement le comportement de l’ALG. Pour l’outillage côté opérateur couvrant les traces d’appels et la capture de paquets, le guide de dépannage VoIP détaille le processus de diagnostic.

Comment désactiver le SIP ALG

Le SIP ALG se cache sous différents noms selon les équipements, ce qui explique en partie pourquoi il passe si souvent inaperçu. Selon le fabricant, il apparaît sous le nom de SIP ALG, SIP Transformations, SIP Helper, SIP Inspection, VoIP passthrough, ou comme une entrée SIP dans une page de paramètres NAT ou de couche application. Sur les passerelles Linux, il s’agit du module de suivi de connexion nf_conntrack_sip. Le tableau ci-dessous indique où le trouver sur les plateformes courantes.

Après avoir désactivé le SIP ALG, redémarrez le routeur si la modification ne prend pas effet immédiatement, réenregistrez les téléphones et passez des appels tests dans les deux sens pour confirmer l’audio bidirectionnel et que l’appel tient au-delà de l’intervalle où il coupait auparavant. Si les symptômes persistent, la cause est un problème de NAT ou de pare-feu distinct plutôt que l’ALG.

Quand désactiver le SIP ALG ne suffit pas

Désactiver le SIP ALG supprime ce qui corrompt votre signalisation, mais ne fait pas disparaître le problème de NAT d’origine. Les adresses privées à l’intérieur des messages SIP doivent encore être réconciliées avec les adresses publiques que l’autre partie voit réellement. Pour un seul téléphone derrière un routeur basique, le keep-alive NAT du téléphone et la détection de NAT distant du fournisseur comblent généralement cette lacune une fois l’ALG écarté. À l’échelle d’un opérateur, d’un MSP ou de tout fournisseur terminant des trunks SIP provenant de nombreux réseaux qu’il ne contrôle pas, le problème de NAT doit être résolu délibérément en bordure de réseau plutôt que laissé à l’estimation d’un routeur.

C’est le rôle que joue un Session Border Controller (SBC). Un SBC se situe à la frontière entre les réseaux et gère la signalisation et le média de chaque côté en tant que fonction conçue à cet effet. Parce qu’il fonctionne comme un back-to-back user agent, il termine le dialogue de signalisation entrant et en initie un nouveau vers l’autre côté, contrôlant ainsi chaque adresse dans chaque en-tête sur les deux segments de manière déterministe, au lieu de modifier un paquet en transit. Il effectue la détection de NAT distant sur les adresses d’où le trafic provient réellement, ancre le média pour que l’audio transite par sa propre adresse publique joignable, et applique la manipulation des en-têtes SIP sous forme de règles configurées plutôt qu’une estimation figée. C’est la différence entre un ALG de routeur et un SBC : la même catégorie de travail, réalisée comme un contrôle délibéré de la signalisation plutôt qu’une réécriture opaque. Pour voir comment cela s’inscrit dans le tableau plus large de pourquoi un ALG de pare-feu ne remplace pas un SBC, consultez la comparaison approfondie dans le guide sur la sécurité des SBC.

Foire aux questions

Conclusion

Le SIP ALG est une fonctionnalité bien intentionnée qui tente de résoudre un vrai problème (le SIP transporte des adresses privées que le NAT ne réécrit pas) et le résout mal en modifiant la signalisation en direct sur la base d’une analyse superficielle du protocole. Le résultat : audio unidirectionnel, appels qui coupent à intervalle régulier, enregistrements qui expirent et appels entrants qui ne sonnent jamais, autant de symptômes qui survivent à toutes les autres étapes de dépannage. Sur presque tous les réseaux d’entreprise, la bonne démarche est de trouver le paramètre, quel que soit le nom que le fabricant lui a donné, et de le désactiver.

Le désactiver supprime la corruption mais laisse le problème de NAT sous-jacent. Pour un seul téléphone, le réseau s’en accommode généralement ; à l’échelle d’un fournisseur, le travail relève d’un Session Border Controller qui gère la traversée du NAT, le média et l’adressage SIP comme des fonctions délibérées et configurées plutôt qu’une estimation transparente. Connaître la différence, c’est ce qui transforme un après-midi passé à chasser un fantôme en une correction de cinq minutes.