Sophos Firewall Résoudre les problèmes de VoIP avec SIP et RTP

Les problèmes VoIP derrière un Sophos Firewall ont souvent un effet diffus : les téléphones ne s’enregistrent pas, les appels sont interrompus, il sonne sans son ou la parole ne peut être entendue que dans une seule direction. En pratique, la cause est rarement due à un seul interrupteur. La signalisation SIP, le flux multimédia RTP, le NAT, les règles de pare-feu, les délais d’attente UDP ou le routage fonctionnent généralement ensemble.

L’article classe le dépannage VoIP sur le Sophos Firewall comme un processus structuré. Les mesures immédiates connues telles que la désactivation de SIP Helper ou l’augmentation du délai d’attente UDP restent importantes. Toutefois, ces modifications ne doivent pas être effectuées aveuglément, mais plutôt dans le cadre d’un processus de dépannage propre.

Qu’est-ce qui traverse le pare-feu avec la VoIP

La VoIP se compose grosso modo de deux parties :

• SIP : contrôle l’enregistrement, l’établissement des appels, la libération des appels et la négociation des paramètres multimédias. Les erreurs typiques incluent l’échec de l’enregistrement, les appels non établis ou les boîtes de dialogue SIP rejetées par le fournisseur.
• RTP : transporte les données vocales pendant la conversation. Les erreurs typiques incluent l’audio manquant, l’audio unilatéral ou l’interruption de l’audio après une courte période de temps.SIP fonctionne souvent via UDP ou TCP 5060, avec SIP crypté souvent via 5061. Mais ce n’est pas une loi. De nombreux fournisseurs utilisent leurs propres ports, leurs propres serveurs proxy ou des exigences supplémentaires pour les keepalives NAT.

RTP utilise généralement des plages de ports UDP spécifiées par le fournisseur, le système téléphonique ou les appareils finaux. Pour une analyse claire, vous avez besoin des serveurs SIP spécifiques, des plages de ports RTP et des protocoles de transport du fournisseur ou de la documentation du PBX.

Classer correctement les symptômes

Avant d’apporter des modifications, vous devez classer le symptôme aussi précisément que possible.

• Échec de l’enregistrement : Vérifiez le DNS, le routage, la règle de pare-feu, le NAT, les informations d’identification du fournisseur ou le transport SIP.
• L’appel ne se connecte pas : Vérifiez la signalisation SIP, la règle de pare-feu, Application Control et les éventuels blocages du fournisseur.
• L’appel fonctionne mais pas d’audio : Vérifiez la plage de ports RTP, NAT, l’itinéraire de retour, SD-WAN et SIP Helper.
• L’audio n’est audible que dans une seule direction : Vérifiez le chemin de retour RTP, NAT, le routage, le VPN et le SD-WAN.
• La conversation s’interrompt après 30, 60 ou 120 secondes : Vérifiez le délai d’expiration UDP, le maintien NAT, l’actualisation de la session et les attentes du fournisseur.
• Seuls les appels entrants ne fonctionnent pas : Vérifiez le DNAT, la règle de pare-feu, les réseaux sources du fournisseur et le partage de port PBX.
• Une seule ligne WAN pose problème : Vérifiez l’itinéraire SD-WAN, le chemin de réponse, la passerelle et la liaison IP du fournisseur.

Cette classification vous empêche de modifier les paramètres SIP même si le problème réel réside dans le chemin de retour RTP ou une route SD-WAN.

Vérifiez avant d’apporter des modifications

Avant d’apporter des modifications à la CLI, vous devez documenter l’état actuel :

• Quels téléphones, PBX ou SBC sont concernés ?
• Les appareils finaux s’enregistrent-ils directement auprès du fournisseur ou tout se déroule-t-il via un système téléphonique interne ?
• Quels serveurs SIP et plages de ports RTP le fournisseur nomme-t-il ?
• Quelle règle de pare-feu traite le trafic VoIP ?
• Log firewall traffic est-il activé dans cette règle ?
• Quelle règle NAT s’applique au trafic VoIP sortant et entrant ?
• Existe-t-il plusieurs lignes WAN, routes SD-WAN ou VPN basés sur des routes ?
• Le problème est-il devenu visible après une mise à niveau du micrologiciel, un changement de fournisseur ou une mise à jour du PBX ?

Tester les règles de pare-feu sur Sophos Firewall aide à l’analyse des règles. Pour le flux de paquets réel, Packet Capture dans WebAdmin est généralement plus significatif qu’un simple test de politique.

Vérifiez l’assistance SIP

Le SIP Helper, souvent également appelé SIP ALG, tente de reconnaître les paquets SIP et d’adapter les informations SIP pertinentes pour le NAT. Cela peut être utile dans des environnements simples. Cependant, cela peut également être perturbateur dans de nombreuses configurations VoIP modernes avec le fournisseur SBC, votre propre PBX, TLS, un keepalive NAT propre ou des plages de ports RTP plus complexes.

C’est pourquoi le SIP Helper est un point de test utile, mais pas une solution générale permanente à chaque problème.Les commandes sont exécutées via SSH sur le Sophos Firewall. Pour ce faire, connectez-vous au pare-feu et sélectionnez 4. Device Console. L’accès SSH ne doit être autorisé qu’à partir de réseaux de confiance. Les bases sont dans Connectez-vous à Sophos Firewall via SSH.

Afficher l’état actuel du module :

system system_modules show

Désactivez le module SIP :

system system_modules sip unload

Réactivez le module SIP :

system system_modules sip load

⚠️ Ce changement doit être effectué dans une fenêtre de maintenance ou avec des tests clairement définis. Après avoir désactivé ou activé, l’enregistrement, les appels sortants, les appels entrants et l’audio doivent être vérifiés dans les deux sens.

Si le changement ne vous aide pas, vous devriez le retirer. Il est important de documenter l’état avant et après le test.

Vérifiez et ajustez le délai d’expiration UDP

La VoIP utilise souvent UDP. Si le NAT ou les entrées de session expirent trop tôt, un enregistrement peut sembler fonctionner, mais les appels sont interrompus ou les appels entrants n’atteignent pas le PBX de manière fiable.

L’état actuel du pare-feu avancé est affiché dans le Device Console :

show advanced-firewall

Une valeur de test courante est 180 secondes :```shell set advanced-firewall udp-timeout-stream 180

> ⚠️ `udp-timeout-stream` n'est pas une pure option de contrôle VoIP, mais a un effet plus large sur les sessions UDP. La valeur ne doit pas être fixée arbitrairement à un niveau élevé. Il est préférable d'avoir un test défini avec une documentation de l'ancienne valeur, des exigences du fournisseur et un contrôle ultérieur de la session et de la qualité de la voix.

Si le fournisseur ou le système téléphonique prend en charge NAT keepalive, ce paramètre doit également être vérifié. Un keepalive propre du côté du PBX ou du fournisseur est souvent préférable à une valeur de délai d'attente globale très élevée.

## Vérifiez les règles de pare-feu et le NAT

NAT est souvent impliqué dans les problèmes de VoIP. Le Sophos Firewall doit non seulement autoriser le SIP, mais aussi traduire et renvoyer correctement les flux RTP associés dans les deux sens.

Ces points sont généralement pertinents pour les téléphones sortants ou un PBX interne :

- règle de pare-feu appropriée de la zone VoIP ou de la zone PBX vers le WAN
- règle SNAT ou MASQ appropriée
- Connexion à la règle de pare-feu
- pas de règle trop large ou mal positionnée au dessus de la règle VoIP
- pas de Application Control inattendu, IPS ou filtrage web sur ce traficDes points supplémentaires sont ajoutés pour les lignes réseau SIP entrantes ou les systèmes téléphoniques publiés :

- DNAT vers le PBX ou SBC interne
- Règle de pare-feu avec zone cible et réseau cible appropriés
- Restriction aux réseaux sources du fournisseur, si possible
- uniquement les ports SIP et RTP requis
- Journalisation et Packet Capture pour les tests

Une règle NAT n'autorise pas le trafic, mais traduit uniquement les adresses ou les ports. Les connexions sont expliquées dans [Comprendre NAT sur Sophos Firewall](/fr/kb/sophos-firewall-nat-basics/). Si un PBX doit être accessible depuis Internet, [Serveur de publication via DNAT](/fr/kb/sophos-firewall-publier-serveur-dnat/) constitue la meilleure base pour la publication proprement dite.

## Analyser le RTP et la direction du langage

Si l’appel est établi mais que l’audio manque, le SIP n’est généralement plus le problème principal. Ensuite, vous devez vérifier si le RTP circule dans les deux sens.

Processus typique :

1. Notez la plage de ports RTP du fournisseur ou du PBX.
2. Démarrez Packet Capture avec l'IP source du PBX ou du téléphone et la plage de ports RTP.
3. Effectuez un appel test.
4. Vérifiez si les paquets UDP du périphérique interne vers le fournisseur sont visibles.
5. Vérifiez si les paquets UDP reviennent du fournisseur.
6. Comparez NAT ID, Rule ID, In interface et Out interface.Si RTP n'est visible que sortant mais que rien ne revient, le problème peut provenir du fournisseur, du chemin de retour, du NAT ou d'une station distante en amont. Si RTP revient mais n'est pas transmis au PBX, une règle de pare-feu, un DNAT, un routage ou un mappage de zone sont plus probables.

Pour des enregistrements plus précis ou un export PCAP, `tcpdump` via SSH peut être utile. Le processus est décrit dans [Sophos Firewall Utiliser tcpdump pour les journaux et les analyses](/fr/kb/sophos-firewall-tcpdump-tool-collecter-les-logs/).

## SD-WAN, VPN et plusieurs lignes WAN

La VoIP est sensible aux chemins asymétriques. Si SIP s'exécute sur une ligne WAN mais que RTP revient sur une ligne différente ou qu'un VPN basé sur un itinéraire est acheminé différemment, des erreurs typiques telles qu'un son unilatéral se produisent.

Un bug corrigé dans SFOS 22.0 MR1 montre la connexion typique : après une mise à niveau vers SFOS 22.0 GA, l'audio VoIP ne pouvait fonctionner que dans un sens sur un VPN basé sur le routage avec un routage SD-WAN. En pratique, cela signifie : le SD-WAN doit toujours être vérifié lors de l'utilisation de VoIP sur VPN ou de plusieurs chemins WAN.

Points de contrôle importants :

- Une route SD-WAN accède-t-elle au trafic VoIP ?
- SIP et RTP sont-ils acheminés sur la même ligne WAN attendue ?
- Existe-t-il des spécifications du fournisseur concernant l'adresse IP source ou l'adresse publique de l'expéditeur ?
- Une route VPN basée sur une route avec une interface XFRM est-elle utilisée ?
- Les routes de retour et NAT correspondent-elles au chemin choisi ?
- Packet Capture affiche-t-il différentes passerelles ou interfaces pour les directions aller et retour ?

Pour les options SD-WAN spécifiques à Sophos, [Paquet de réponse de routage SD-WAN et trafic système](/fr/kb/sophos-firewall-sd-wan-routing-reply-packet-system-traffic/) convient. [Sophos Firewall Dépannage IPsec](/fr/kb/sophos-firewall-ipsec-troubleshooting/) aide également avec les connexions IPsec.

## Mise en forme du trafic pour la VoIP

La gestion du trafic peut stabiliser la VoIP lorsque les lignes sont étroites ou que des téléchargements volumineux déplacent les paquets vocaux. Cependant, cela ne résout pas les règles NAT incorrectes, les ports RTP manquants et les routes de retour incorrectes.

La gestion du trafic est particulièrement utile si :

- La VoIP s'aggrave lorsque la ligne Internet est en charge,
- Les téléchargements ou les sauvegardes perturbent les conversations,
- plusieurs applications utilisent la même ligne,
- La VoIP doit être spécifiquement prioritaire.

La configuration est décrite dans [Mise en forme du trafic applicatif sur Sophos Firewall](/fr/kb/sophos-firewall-application-traffic-shaping/). Pour la VoIP, vous ne devez pas seulement vérifier les tests de vitesse après la mise en œuvre, mais également effectuer de véritables appels de test avec charge simultanée.

## Flux de dépannage pratique

1. Documenter les symptômes : enregistrement, configuration de l'appel, audio, heure d'abandon, direction.
2. Collectez les données du fournisseur : serveur SIP, transport, plage de ports RTP, exigences NAT.
3. Identifiez la règle de pare-feu et la règle NAT.
4. Activez la journalisation dans la règle de pare-feu concernée.
5. Ouvrez Log Viewer et Packet Capture lors d'un appel test.
6. Vérifiez si la signalisation SIP fonctionne dans les deux sens.
7. Vérifiez si RTP fonctionne dans les deux sens.
8. S'il existe plusieurs lignes WAN, vérifiez le SD-WAN et le chemin de retour.
9. Testez spécifiquement SIP Helper et documentez les résultats.
1
0. Ajustez uniquement le délai d'expiration UDP de manière consciente et documentée avec l'ancienne valeur.
1
1. Après chaque changement, testez l'enregistrement, les appels sortants, les appels entrants et l'audio dans les deux sens.

Si plusieurs modifications sont apportées en même temps, la cause ultérieure est difficile à comprendre. Un test par changement est préférable.

## Recueillir des preuves lors d'un appel test

Un test VoIP n'est utile que si l'heure, la direction et le flux des paquets correspondent. Surtout dans le cas des fournisseurs, la déclaration « L’audio ne fonctionne pas » n’est pas suffisante. Vous avez besoin d’un petit cas de test reproductible.
- **Heure exacte avec fuseau horaire :** Log Viewer, Packet Capture et les journaux du fournisseur peuvent être facilement comparés ultérieurement.
- **Direction des appels :** les appels entrants, les appels sortants et les renvois internes ne sont pas mélangés.
- **Numéros de téléphone ou extensions :** Les fournisseurs et les PBX trouvent l'appel spécifique plus rapidement.
- **IP interne du PBX ou du téléphone :** Packet Capture peut être filtré de manière étroite.
- **Serveur SIP du fournisseur et plage de ports RTP :** Les analyses SIP et RTP restent séparées.
- **Rule ID, NAT ID, In interface et Out interface :** vous pouvez voir quelle règle et quel chemin ont été réellement utilisés.
- **Résultat par test :** L'enregistrement, la sonnerie, l'établissement de l'appel, l'audio gauche/droite et l'heure de fin restent traçables.

En cas d'erreurs sporadiques, vous devez également sauvegarder les journaux concernés avant qu'ils ne soient écrasés. Pour un package de journaux propre, [Sophos Firewall Sauvegarder les journaux pour l'assistance et l'analyse](/fr/kb/journaux-sophos-firewall-support-analyse/) convient. Quel fichier journal appartient à quel service est décrit dans [Sophos Firewall Dépannage : services et journaux](/fr/kb/sophos-firewall-services-logs/).

## Erreurs courantes
- **Seul le port SIP est activé, plage de ports RTP oubliée :** L'appel est établi mais l'audio est manquant.
- **Une règle NAT existe, mais aucune règle de pare-feu correspondante :** Le trafic est traduit mais n'est pas autorisé.
- **Règle de pare-feu sans journalisation :** Le dépannage dans Log Viewer reste aveugle.
- **SIP Helper désactivé ou activé à tous les niveaux :** Le problème est déplacé de manière aléatoire au lieu d'être analysé.
- **Délai d'expiration UDP très élevé :** Les sessions UDP globales restent ouvertes inutilement longtemps.
- **Plusieurs chemins WAN sans règle SD-WAN claire :** Le trafic audio unidirectionnel ou le trafic rejeté par le fournisseur deviennent plus probables.
- **Réseaux sources du fournisseur non restreints :** Le service SIP est inutilement largement accessible depuis Internet.
- **Traffic shape compris comme remplacement du NAT/routage :** La qualité de la voix reste mauvaise car la cause est ailleurs.

## Restauration et documentation

Lorsque vous effectuez des modifications VoIP, il doit toujours être clair comment revenir en arrière :- ancienne valeur `udp-timeout-stream` documentée
- Statut du module SIP documenté avant le test
- Modification des règles de pare-feu et NAT notées avec date et raison
- Testez les appels enregistrés avec la direction et l'heure
- Packet Capture ou journaux pertinents sécurisés pour les cas de support

Si le changement n’aide pas, il ne faut pas le laisser comme un héritage accidentel. Les solutions de contournement VoIP en particulier deviendront autrement difficiles à comprendre plus tard.

## Liste de contrôle

- Les informations SIP et RTP du fournisseur sont disponibles.
- La règle de pare-feu pour VoIP est identifiée et la journalisation est active.
- La règle NAT correspond au sens de la circulation.
- SIP et RTP ont été vérifiés séparément.
-Packet Capture affiche la direction aller-retour.
- SIP Helper n'a été testé que spécifiquement.
- Le délai d'expiration UDP n'a été modifié qu'avec une valeur initiale documentée.
- SD-WAN, VPN et plusieurs lignes WAN ont été vérifiées.
- La mise en forme du trafic est utilisée uniquement pour le contrôle qualité, et non pour remplacer le routage ou les corrections NAT.

## Questions fréquemment posées





  

    
Faut-il toujours désactiver le SIP Helper sur Sophos Firewall ?
    

      Non. Le SIP Helper peut aider ou gêner selon le fournisseur et le système téléphonique. Il convient de le tester spécifiquement. Si la désactivation n’apporte aucune amélioration, vous devez restaurer l’état précédent.
    
  









  

    
Pourquoi l'appel fonctionne mais vous n'entendez rien ?
    

      Ensuite, la signalisation SIP fonctionne au moins partiellement, mais le flux multimédia RTP ne s’exécute pas correctement. Vous vérifiez la plage de ports RTP, le NAT, la règle de pare-feu, la route de retour et, s’il existe plusieurs chemins WAN, le SD-WAN.
    
  









  

    
Un délai d'expiration UDP plus élevé aide-t-il à résoudre les problèmes de VoIP ?
    

      Parfois oui, notamment en cas d’appels interrompus ou d’inscriptions instables. Cependant, la valeur a un impact plus large sur les sessions UDP et doit donc être consciente, documentée et ne pas être inutilement élevée.
    
  









  

    
Qu'est-ce qui est important dans la VoIP sur SD-WAN ?
    

      SIP et RTP doivent s’exécuter via le chemin attendu. Si les allers-retours utilisent des lignes WAN ou des chemins VPN différents, des connexions audio unilatérales ou rejetées peuvent se produire.