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

Les problèmes VoIP derrière un Sophos Firewall peuvent sembler sans rapport : les téléphones ne s’enregistrent pas, les appels sont interrompus, le téléphone sonne sans audio ou le son ne passe que dans un sens. La cause tient rarement à un seul réglage. La signalisation SIP, les flux RTP, le NAT, les règles de pare-feu, les délais UDP et le routage interagissent.

Cet article présente le dépannage VoIP sur Sophos Firewall sous la forme d’un processus structuré. Les solutions rapides courantes, comme désactiver SIP Helper ou augmenter un délai UDP, ne sont que des tests contrôlés. Il faut d’abord identifier le chemin des paquets, les règles de pare-feu et NAT réellement utilisées, puis analyser SIP et RTP séparément.

Comprendre SIP, RTP et les symptômes

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 sont l’absence de son, le son unidirectionnel ou une coupure après un court délai.

SIP utilise souvent UDP ou TCP 5060, et SIP chiffré utilise fréquemment 5061. Ces valeurs ne sont pas universelles. De nombreux fournisseurs utilisent d’autres ports, des serveurs proxy ou des exigences NAT keepalive supplémentaires.

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.

Sophos Firewall prend également en charge H.323 en plus de SIP. Ce runbook se concentre sur la signalisation SIP et RTP. Si le système téléphonique utilise réellement H.323, le service H.323 et le H.323 Helper doivent être vérifiés séparément ; les paramètres du SIP Helper ne sont alors pas automatiquement le bon levier.

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.

Relever la situation initiale avant toute modification

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 parlant qu’un simple Policy Test. Les valeurs CLI globales ne doivent être modifiées qu’une fois cette situation initiale et un appel test reproductible disponibles.

Vérifier le chemin des paquets, le routage et la qualité

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
• aucune Application Control, IPS ou Web Filtering inattendue sur ce trafic

La nécessité d’une règle DNAT pour un trunk SIP entrant dépend de la conception du fournisseur. Un trunk basé sur un enregistrement peut utiliser la session sortante existante. Un trunk remis directement à une adresse publique ou un système téléphonique publié nécessite généralement une règle DNAT strictement limitée. Les exigences du fournisseur ou de l’opérateur SBC font foi.

Si DNAT est nécessaire, vérifier également les points suivants :

• 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. Si un PBX doit être accessible depuis Internet, Serveur de publication via DNAT constitue la meilleure base pour la publication proprement dite.

Analyser le RTP dans les deux sens

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. Limitez Packet Capture à l’adresse IP du PBX ou du téléphone et à la plage de ports RTP. Couvrez les deux sens, car l’équipement interne est la source ou la destination selon le sens du paquet.
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, Out interface et Gateway ID. En cas de paquet manquant, contrôlez aussi Status et Reason ; Violation signale un flux rejeté.

Si RTP n’est visible qu’en sortie et que rien ne revient, le problème peut provenir du fournisseur, du chemin de retour, du NAT ou d’un équipement en amont. Si RTP revient mais n’est pas transmis au PBX, la règle de pare-feu, le DNAT, le routage ou l’affectation de zone sont plus probablement en cause.

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.

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 convient. Sophos Firewall Dépannage IPsec 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. 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.

Tester SIP Helper, UDP Timeout et DoS de manière contrôlée

Les paramètres suivants affectent plus qu’une seule règle VoIP. Ils ne doivent être testés qu’après avoir circonscrit la cause, avec un état initial documenté, une fenêtre de maintenance et un rollback clair.

Vérifier le SIP Helper

Le SIP Helper, également appelé SIP ALG, détecte par défaut SIP sur UDP 5060, traduit les adresses locales dans l’en-tête SIP et ouvre dynamiquement le canal vocal attendu. Il faut vérifier sur le flux d’appel réel si ces interventions correspondent à la conception du fournisseur et du PBX. Certains constructeurs de PBX exigent explicitement la désactivation de SIP ALG, tandis que d’autres déploiements ont besoin du Helper.

SIP Helper constitue donc un point de test utile, mais pas une solution permanente et universelle. Sophos indique que le module SIP est activé par défaut. Les modifications effectuées avec load ou unload persistent après un redémarrage.

Les commandes sont exécutées via SSH sur Sophos Firewall, dans 4. Device Console. L’accès SSH ne doit être autorisé que depuis des réseaux de confiance. Les bases sont décrites dans Se connecter à Sophos Firewall via SSH.

Afficher l’état actuel avant et après chaque modification avec une commande en lecture seule :

system system_modules show

La sortie correspondant à l’entrée sip doit être consignée. Il reste ainsi possible de vérifier si le Helper était chargé avant le test et quel état est attendu après le rollback.

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 la modification n’aide pas, rétablissez exactement l’état précédent :

• Si sip était unloaded, exécutez system system_modules sip unload.
• S’il était chargé sur le port UDP 5060 par défaut, exécutez system system_modules sip load.
• S’il était chargé sur un port personnalisé, exécutez system system_modules sip load ports <previous_custom_port>. <previous_custom_port> doit être le port consigné avant la modification.

Ne commencez pas le test si un ancien port personnalisé n’est pas connu avec certitude. Un simple load ne serait pas un retour arrière exact, puisqu’il chargerait le Helper sur son port par défaut.

Si le fournisseur utilise un port de signalisation SIP personnalisé au lieu d’UDP 5060, le Helper peut être chargé avec ce port précis :

system system_modules sip load ports <custom_port>

<custom_port> est remplacé par le port SIP spécifié par le fournisseur ou le constructeur du PBX, et non par une plage complète de ports RTP. Le SIP Helper prend en charge les ports multimédias de 1024 à 65535. Si un port multimédia se trouve hors de cette plage, le pare-feu peut rejeter le trafic et afficher Invalid Traffic dans le journal des événements.

SIP sur TCP présente une autre limite : le Helper ne prend pas en charge les messages SIP ou SDP répartis sur plusieurs paquets. Si Packet Capture montre exactement ce schéma, le transport doit être clarifié avec le fournisseur et le constructeur du PBX. Le passage à SIP sur UDP n’est pertinent que si les deux côtés le prennent en charge.

Vérifier et ajuster 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.

Sophos distingue deux valeurs globales :

• udp-timeout s’applique aux connexions UDP qui ne sont pas encore reconnues comme un flux bidirectionnel.
• udp-timeout-stream s’applique aux flux UDP établis lorsque les deux extrémités ont envoyé du trafic sur le même port entre des segments réseau.

Dans SFOS 22, les deux valeurs acceptent une plage de 30 à 3600 secondes. Afficher les valeurs Advanced Firewall actuelles dans Device Console :

show advanced-firewall

L’aide actuelle de SFOS 22 indique 60 secondes comme valeur par défaut de UDP Timeout Stream et recommande 150 secondes pour la VoIP. La valeur réellement affichée et les exigences du fournisseur restent toutefois déterminantes. Si Packet Capture et l’heure de coupure indiquent un délai de flux trop court, la valeur documentée peut être testée de manière contrôlée :

set advanced-firewall udp-timeout-stream 150

Exécutez immédiatement de nouveau show advanced-firewall. Ne répétez l’appel de test identique que si UDP Timeout Stream : 150 s’affiche. Après le retour arrière, le même contrôle doit afficher la valeur consignée auparavant.

⚠️ udp-timeout-stream n’est pas une option propre à une règle VoIP. Elle affecte tous les flux UDP correspondants. Ne pas l’augmenter par supposition ou de façon arbitraire. Noter l’ancienne valeur depuis show advanced-firewall et la restaurer avec la même commande set si le test échoue.

Par exemple, si l’état initial indique UDP Timeout Stream : 60, le retour arrière exact est :

set advanced-firewall udp-timeout-stream 60

La valeur 60 n’est correcte que pour cet état initial. Si le pare-feu affichait une autre valeur, reprenez-la sans la modifier dans la commande de retour arrière.

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érifier les seuils UDP flood

La VoIP génère de nombreux paquets UDP. Si les seuils sous Intrusion prevention > DoS & spoof protection > DoS settings sont trop bas, le pare-feu peut rejeter du trafic SIP ou RTP légitime comme UDP flood. Avant toute modification, consigner les valeurs actuelles de Packet rate, Burst rate et Apply flag, ainsi que les compteurs de paquets rejetés.

Sophos mentionne la suppression temporaire de l’Apply flag pour UDP flood comme test de diagnostic. Cette opération réduit la protection DoS pendant le test et doit donc être réalisée dans une fenêtre de maintenance avec un cas de test strictement défini. Si la VoIP s’améliore, adapter Packet rate et Burst rate à la charge légitime mesurée, puis réactiver Apply flag. Si le problème ne change pas, restaurer immédiatement l’état initial.

Une exception ciblée pour des hôtes ou ports connus peut être plus sûre qu’une désactivation globale. Spoof Protection et protection DoS sur Sophos Firewall explique l’interaction entre les seuils et les DoS bypass rules. La protection ne doit pas rester désactivée après le test.

H.323, VPN et conntrack comme cas particuliers

Les indications Sophos suivantes ne s’appliquent qu’à un problème clairement confirmé. Elles modifient des paramètres globaux du helper, d’IPS ou du VPN, ou une session active, et ne constituent pas un réglage général de la VoIP.

Avec H.323, le Helper chargé peut être en cause lorsque l’audio ou la vidéo s’interrompt ou ne fonctionne que dans un sens malgré des règles de pare-feu et DNAT correctes. Consignez d’abord l’état initial avec system system_modules show. Sophos indique le test contrôlé suivant :

system system_modules h323 unload

Relisez ensuite l’état du module et répétez le même appel de test avec l’audio ou la vidéo dans les deux sens. Si h323 était déjà déchargé, la commande n’a créé aucun nouvel état de test.

Si le module était chargé auparavant et que le problème persiste, revenez en arrière avec :

system system_modules h323 load

La conception de passerelle de sous-réseau transparente avec proxy ARP également citée par Sophos représente une modification d’architecture, et non une prochaine étape universelle. Seuls les chemins ARP et de routage vérifiés permettent de déterminer si Proxy ARP sur Sophos Firewall convient à cette topologie.

Pour les problèmes VoIP via un VPN site-to-site ou avec IPS, Sophos mentionne deux paramètres globaux. sip_preproc analyse les sessions SIP à la recherche d’attaques réseau et est activé par défaut. conn-remove-tunnel-up détermine si les connexions sont supprimées lorsqu’un tunnel IPsec est établi.

Avant le test, corrélez l’interruption de l’appel avec un événement du tunnel. Lisez la valeur IPS initiale dans Device Console :

show ips-settings

Si sip_preproc est clairement affiché comme enable, vous pouvez effectuer le test documenté par Sophos dans une fenêtre de maintenance :

set ips sip_preproc disable

Exécutez de nouveau show ips-settings et répétez le même appel de test. La désactivation réduit globalement l’inspection des attaques SIP. Si le test n’apporte aucune amélioration, le retour exact pour la valeur enable relevée auparavant est set ips sip_preproc enable ; show ips-settings doit ensuite afficher de nouveau enable. Si la valeur initiale est déjà disable ou ne peut pas être lue sans ambiguïté, ne la modifiez pas.

Pour le même problème, Sophos indique aussi set vpn conn-remove-tunnel-up disable. Toutefois, l’aide CLI actuelle de SFOS 22 ne documente ni commande de lecture correspondante ni valeur initiale universelle. Ne modifiez pas ce paramètre sur la seule base de cet article. Sophos Support doit d’abord confirmer sa valeur réelle et le retour exact pour le build installé. Utiliser les paramètres VPN globaux en toute sécurité explique l’effet du paramètre.

Si un téléphone s’enregistre auprès du PBX avec l’adresse IP du pare-feu au lieu de sa propre adresse, il faut d’abord comparer Log Viewer, Firewall Rule ID, NAT Rule ID et l’état du helper entre un téléphone fonctionnel et un téléphone affecté. La création d’une nouvelle session normale du téléphone ou du PBX est plus sûre qu’une intervention dans conntrack. Si une entrée TCP manifestement incorrecte persiste, Sophos indique comme dernière étape ciblée dans l’Advanced Shell :

conntrack -D --src <IP_ADDRESS_OF_PHONE> --dst <IP_ADDRESS_OF_PBX> -p tcp

Les espaces réservés sont uniquement remplacés par les adresses vérifiées. La commande supprime la session TCP active correspondante et l’interrompt immédiatement ; elle ne doit être ni élargie ni adaptée à UDP. Live Connections sur Sophos Firewall explique comment limiter d’abord le flux sous Diagnostics > Connection list.

Le téléphone concerné doit ensuite s’enregistrer de nouveau. Le test n’est concluant que si Log Viewer affiche l’adresse IP propre du téléphone et qu’un nouvel appel fonctionne. Si l’adresse du pare-feu réapparaît, ne répétez pas la suppression ; analysez le NAT et le Helper avec Sophos Support.

Dépannage et éléments de preuve

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. Vérifiez l’état du SIP Helper, testez les modifications de manière ciblée et consignez les résultats.
10. Ajustez un délai UDP uniquement de manière délibérée et après avoir documenté l’ancienne valeur.
11. En cas de rejets UDP ou de problèmes de qualité sous charge, vérifiez les seuils UDP flood de manière contrôlée.
12. 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.
• Journal des événements et compteurs DoS : Invalid Traffic ou une augmentation des rejets UDP flood permettent de circonscrire la plage de ports du Helper et les seuils DoS.
• 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 convient. Quel fichier journal appartient à quel service est décrit dans Sophos Firewall Dépannage : services et journaux.

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é.
• Port SIP personnalisé confondu avec la plage de ports RTP : Le Helper est chargé sur le mauvais port de signalisation.
• Délai d’expiration UDP très élevé : Les sessions UDP globales restent ouvertes inutilement longtemps.
• Protection UDP flood trop stricte ou désactivée en permanence : Des paquets vocaux légitimes sont rejetés ou la protection reste inutilement réduite après le test.
• 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.

Annuler proprement les modifications

Pour toute modification VoIP, le retour arrière doit être clair :

• anciennes valeurs de udp-timeout et udp-timeout-stream documentées si elles sont modifiées
• test SIP load, unload ou de port personnalisé et état final attendu documentés
• états initiaux de H.323 et de sip_preproc consignés et restaurés après l’échec d’un test particulier ; conn-remove-tunnel-up laissé inchangé sans valeur initiale confirmée
• seuils UDP flood et Apply flags d’origine documentés et restaurés après le test
• règles de pare-feu et NAT modifiées consignées avec la date et la raison
• appels test consignés avec leur direction et leur heure
• Packet Capture ou journaux pertinents conservé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 opérationnelle

• 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 montre le trafic dans les deux sens.
• L’état du SIP Helper a été vérifié avant et après le test ciblé.
• Un port SIP personnalisé correspond aux spécifications du fournisseur ou du PBX et n’est pas confondu avec la plage de ports RTP.
• Le délai d’expiration UDP n’a été modifié qu’avec une valeur initiale documentée.
• Les seuils UDP flood et la protection DoS ont été ramenés à un état final sûr après le test.
• 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équentes