VoIP sur VPN : arrêter l’audio robotique avec MTU, gigue et notions de QoS

novembre 30, 2025 • février 3, 2026 • Lecture : 27 min • Views: 7

Cet article vous a aidé ?

Vous connaissez ce son. L’appel commence bien, puis quelqu’un se met à ressembler à un fax qui auditionne pour un film de robots.
Tout le monde accuse « le VPN », puis le FAI, puis le softphone, puis la phase de la lune. En réalité, le coupable est souvent ennuyeux :
un décalage MTU/MSS, de la gigue due au bufferbloat, ou une QoS qui ne survit pas au passage dans le tunnel.

J’exploite des réseaux en production où la voix n’est qu’une charge de travail — jusqu’à ce qu’elle cesse de l’être. La voix punit les hypothèses paresseuses.
Elle se fiche que votre test de débit soit excellent ; elle exige que les petits paquets arrivent à l’heure, de façon constante, avec peu de pertes et sans réordonnancement.

Un modèle mental qui prédit vraiment les pannes

Si vous ne retenez qu’une chose : la voix est un flux temps réel qui circule sur un réseau best-effort. Un VPN ajoute des en-têtes, masque les marquages QoS internes à moins que vous ne les préserviez volontairement, et peut altérer le rythme d’envoi des paquets.
Les modes de défaillance habituels ne sont pas mystérieux. Ce sont de la physique et des files d’attente.

Ce que « audio robotique » signifie généralement

« Robotique » est rarement un problème de qualité du codec. C’est l’action de la perte de paquets et du mécanisme de dissimulation.
L’audio RTP arrive en petits paquets (souvent 20 ms d’audio par paquet). Perdre quelques paquets, subir des pics de gigue, le jitter buffer s’allonge, le décodeur devine, et vous entendez le robot.
La voix peut tolérer un peu de perte ; elle ne peut tout simplement pas bien la masquer.

La pile VoIP-sur-VPN en un diagramme (conceptuel)

Pensez au paquet comme à un ensemble d’enveloppes imbriquées :

Interne : signalisation SIP + média RTP (souvent UDP) avec des marquages DSCP que vous souhaitez conserver
Ensuite : votre enveloppe VPN (WireGuard/IPsec/OpenVPN) ajoute une surcharge et peut modifier le MTU
Externe : files d’attente de l’ISP et d’internet (où vit le bufferbloat) et où la QoS peut ne pas s’appliquer
Points de terminaison : softphone ou téléphone IP, et un PBX/ITSP

La casse se produit généralement dans un des trois endroits :
(1) taille (MTU/fragmentation),
(2) temporisation (gigue/files d’attente),
(3) priorisation (QoS/DSCP et shaping).

Paraphrase d’une idée de W. Edwards Deming : « Sans données, vous n’êtes qu’une autre personne avec une opinion. » Traitez les problèmes de voix comme des incidents : mesurez, isolez, changez une variable, re-mesurez.

Playbook de diagnostic rapide

Quand le PDG dit « les appels sont cassés », vous ne commencez pas par débattre des codecs. Vous commencez par réduire le périmètre affecté et localiser la file d’attente.
Voici l’ordre qui trouve rapidement les causes racines.

Première étape : confirmer s’il s’agit de perte, de gigue ou de MTU

Vérifiez les statistiques RTP dans le client/PBX : pourcentage de perte, gigue, paquets en retard. Si vous n’avez pas cela, capturez des paquets et calculez-les (ensuite).
Si vous observez même 1–2% de perte pendant les moments « robotiques », traitez-le comme un problème réseau jusqu’à preuve du contraire.
Exécutez un test rapide de path MTU à travers le VPN. Si PMTUD est cassé, vous aurez des paquets trop grands mis en black-hole, surtout sur des VPN basés sur UDP.
Vérifiez le délai de mise en file sous charge sur le lien le plus étroit (généralement l’upload de l’utilisateur). Le bufferbloat est le tueur silencieux de la voix.

Deuxième étape : isoler où ça se casse

Contournez le VPN pour un appel test (split tunnel ou politique temporaire). Si la voix s’améliore drastiquement, concentrez-vous sur la surcharge du tunnel, le MTU, et la gestion QoS aux bords du tunnel.
Comparez filaire vs Wi‑Fi. Si le Wi‑Fi est pire, vous êtes dans la contention d’airtime et les retransmissions. Corrigez cela séparément.
Testez depuis un réseau connu bon (un circuit de labo, un autre FAI, ou une VM cloud exécutant un softphone). Si c’est propre, le problème est au bord utilisateur.

Troisième étape : appliquer les « correctifs ennuyeux »

Fixez explicitement le MTU de l’interface VPN et appliquez le clamp MSS TCP quand pertinent.
Appliquez une gestion de file intelligente (fq_codel/cake) au point de goulot réel et shapez légèrement en-dessous du débit nominal.
Marquez le trafic voix et priorisez-le là où vous contrôlez la file (souvent le bord WAN), pas seulement en souhaitant que ça marche.

Blague #1 : Un VPN, c’est comme une valise — si vous continuez d’empiler des en-têtes, la fermeture éclair (MTU) finira par lâcher au pire moment.

MTU, MSS et fragmentation : pourquoi « robotique » signifie souvent « petite perte »

Les problèmes de MTU ne ressemblent pas toujours à un « impossible de se connecter ». Ils peuvent ressembler à « ça se connecte, mais parfois ça sonne hanté ».
C’est parce que la signalisation peut survivre alors que certains paquets média ou re-invites sont perdus, ou parce que la fragmentation augmente la sensibilité aux pertes.

Ce qui change quand vous ajoutez un VPN

Chaque tunnel ajoute une surcharge :

WireGuard ajoute un en-tête UDP/IP externe plus l’overhead WireGuard.
IPsec ajoute overhead ESP/AH (plus éventuellement encapsulation UDP pour NAT-T).
OpenVPN ajoute un overhead en espace utilisateur et peut ajouter du framing supplémentaire selon le mode.

Le paquet interne qui passait en MTU 1500 peut ne plus rentrer. Si votre chemin ne gère pas la fragmentation comme vous le pensez, quelque chose est supprimé.
Et UDP ne retransmet pas ; il vous déçoit en temps réel.

Path MTU discovery (PMTUD) et ses échecs

PMTUD dépend des messages ICMP « Fragmentation Needed » (IPv4) ou Packet Too Big (IPv6). Beaucoup de réseaux bloquent ou limitent ICMP.
Résultat : vous envoyez des paquets trop grands, les routeurs les jettent, et l’expéditeur ne l’apprend jamais. C’est ce qu’on appelle un « PMTUD black hole ».

Pourquoi le RTP n’est généralement pas « trop gros » — mais souffre quand même

Les paquets voix RTP sont typiquement petits : des dizaines à quelques centaines d’octets de payload, plus en-têtes. Pourquoi le MTU affecte-t-il donc les appels ?

Signalisation et changements de session (SIP INVITE/200 OK avec SDP, enregistrements TLS) peuvent devenir volumineux.
L’encapsulation VPN peut fragmenter des paquets même modérés, augmentant la probabilité de perte.
Des pics de gigue surviennent quand fragmentation et réassemblage interagissent avec des files congestionnées.
Certains softphones agrègent ou envoient des paquets UDP plus grands selon certains réglages (comfort noise, SRTP, ou ptime inhabituel).

Conseils exploitables

Pour WireGuard, commencez par MTU 1420 si vous n’êtes pas sûr. Ce n’est pas magique ; c’est une valeur conservatrice qui évite les pièges d’overhead courants.
Pour OpenVPN, soyez explicite avec le MTU du tunnel et le clamp MSS pour les flux TCP qui traversent le tunnel.
Ne « baissez pas le MTU partout » aveuglément. Vous pouvez corriger un chemin et en nuire à un autre. Mesurez, puis définissez.

Gigue, bufferbloat et pourquoi les tests de vitesse mentent

Vous pouvez avoir 500 Mbps en download et toujours sonner comme si vous appeliez depuis un sous-marin. La voix a besoin d’une faible variation de latence, pas de chiffres impressionnants.
L’ennemi pratique numéro un est le bufferbloat : des files trop profondes dans routeurs/modems qui se remplissent sous charge et ajoutent des centaines de millisecondes de délai.

Gigue vs latence vs perte de paquets

Latence : le temps qu’un paquet met pour aller d’un bout à l’autre.
Gigue : la variation de cette latence paquet par paquet.
Perte : paquets qui n’arrivent jamais (ou arrivent trop tard pour être utiles).

Les codecs vocaux utilisent des jitter buffers. Ces buffers peuvent lisser la variation jusqu’à un certain point, au prix d’un délai ajouté.
Quand la gigue devient importante, les buffers s’allongent (augmentant la latence) ou laissent tomber les paquets en retard (augmentant la perte). Dans les deux cas : audio robotique.

Où naît la gigue

La plupart des gigue liées à la VoIP-sur-VPN ne viennent pas « d’internet ». Elles viennent de la file d’attente du bord :

Routeur domicile de l’utilisateur avec un buffer monté en amont
Pare-feu de succursale effectuant inspection et buffering
Concentrateur VPN saturé côté CPU provoquant des délais d’ordonnancement des paquets
Contention/retransmissions Wi‑Fi (semblera comme de la gigue et de la perte)

Gestion de file qui fonctionne réellement

Si vous contrôlez le goulot, vous pouvez corriger la voix.
Les algorithmes SQM comme fq_codel et cake empêchent activement les files de s’allonger indéfiniment et maintiennent une latence stable sous charge.

L’astuce : vous devez shapez légèrement en-dessous du débit réel du lien pour que votre appareil — et non le modem ISP — devienne le goulot et contrôle donc la file.
Sinon, vous demandez poliment au modem de se contenir. Il ne le fera pas.

Blague #2 : Le bufferbloat, c’est ce qui arrive quand votre routeur thésaurise des paquets comme s’ils étaient des antiquités de collection.

Notions de QoS/DSCP pour la voix via VPN (et ce qui est supprimé)

La QoS n’est pas une case magique « rendre ça bon ». C’est une façon de décider ce qui souffre en premier quand le lien est congestionné.
C’est tout. S’il n’y a pas de congestion, la QoS ne change rien.

DSCP et le mythe de la « QoS de bout en bout »

La voix marque souvent le RTP en DSCP EF (Expedited Forwarding) et le SIP en CS3/AF31 selon votre politique.
Dans votre LAN, cela peut aider. Sur Internet, la plupart des fournisseurs l’ignorent. À travers un VPN, il se peut qu’il ne survive même pas à l’encapsulation.

Ce que vous pouvez contrôler

LAN edge : prioriser la voix depuis les téléphones/softphones vers votre passerelle VPN.
WAN egress de la passerelle VPN : shaper et prioriser les paquets externes correspondant aux flux voix.
Succursale/edge utilisateur : si vous le gérez, déployez SQM et marquez la voix localement.

Spécificités VPN : marquages internes vs externes

Beaucoup d’implémentations de tunnel encapsulent les paquets internes dans un paquet externe. Le paquet externe est celui que l’ISP voit et forwarde.
Si le paquet externe n’est pas marqué (ou s’il est marqué puis supprimé), votre « EF » interne n’est que décoratif.

L’approche praticable :

Classez la voix avant le chiffrement quand c’est possible, puis appliquez la priorité au flux chiffré (en-tête externe) à la sortie.
Préservez DSCP à travers le tunnel si votre équipement le supporte et si la politique le permet.
Ne faites pas confiance à Wi‑Fi WMM pour vous sauver si votre file d’attente d’upload fond.

Prudence QoS : vous pouvez empirer les choses

Une mauvaise politique QoS peut priver le trafic de contrôle, ou créer des micro-bursts et du réordonnancement. La voix aime la priorité, mais elle aime aussi la stabilité.
Gardez les classes simples : voix, interactif, bulk. Ensuite shapez.

Tâches pratiques : commandes, sorties et décisions

Voici des tâches « lancez-les maintenant ». Chacune inclut une commande, ce que la sortie vous dit, et la décision à prendre.
Utilisez-les sur des endpoints Linux, des passerelles VPN, ou des hôtes de dépannage. Adaptez les noms d’interfaces et IP à votre environnement.

Task 1: Confirm interface MTU on the VPN tunnel

cr0x@server:~$ ip link show dev wg0
4: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none

Signification : le MTU de wg0 est 1420. Bon point de départ conservateur pour WireGuard.
Décision : Si le MTU d’un tunnel est 1500, supposez un problème sauf si vous avez prouvé que le chemin le supporte. Si l’audio robotique corrèle avec certains chemins, testez un MTU plus bas.

Task 2: Measure path MTU with “do not fragment” ping (IPv4)

cr0x@server:~$ ping -M do -s 1372 -c 3 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 1372(1400) bytes of data.
1380 bytes from 10.20.30.40: icmp_seq=1 ttl=63 time=18.4 ms
1380 bytes from 10.20.30.40: icmp_seq=2 ttl=63 time=18.7 ms
1380 bytes from 10.20.30.40: icmp_seq=3 ttl=63 time=18.2 ms

--- 10.20.30.40 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms

Signification : un paquet de 1400 octets (headers inclus) passe sans fragmentation.
Décision : Augmentez -s jusqu’à l’échec pour trouver le maximum. Réglez le MTU du tunnel en dessous de cela moins l’overhead d’encapsulation.

Task 3: Observe PMTUD failure symptoms (IPv4)

cr0x@server:~$ ping -M do -s 1472 -c 2 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1420
ping: local error: message too long, mtu=1420

--- 10.20.30.40 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1013ms

Signification : votre MTU d’interface locale est 1420 ; le noyau refuse d’envoyer plus grand avec DF activé.
Décision : Si des applications envoient quand même des paquets plus grands (l’encapsulation VPN UDP peut le faire), clamp ou configurez MTU/MSS pour les empêcher.

Task 4: Check TCP MSS clamping rules (iptables)

cr0x@server:~$ sudo iptables -t mangle -S | grep -i mss
-A FORWARD -o wg0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Signification : les paquets SYN TCP voient leur MSS clampée selon le PMTU.
Décision : Si vous transportez SIP sur TCP/TLS via le VPN et observez des blocages ou retransmissions, activez ceci. Cela ne résoudra pas RTP (UDP), mais stabilisera la signalisation.

Task 5: Verify DSCP markings on outbound packets

cr0x@server:~$ sudo tcpdump -ni eth0 -vv udp and portrange 10000-20000 -c 5
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:10:41.112233 IP (tos 0xb8, ttl 63, id 44211, offset 0, flags [DF], proto UDP (17), length 214) 192.0.2.10.14562 > 198.51.100.20.10012: UDP, length 186
12:10:41.132244 IP (tos 0xb8, ttl 63, id 44212, offset 0, flags [DF], proto UDP (17), length 214) 192.0.2.10.14562 > 198.51.100.20.10012: UDP, length 186

Signification : TOS 0xb8 correspond à DSCP EF (46). Votre hôte marque le RTP.
Décision : Vérifiez ensuite si le marquage survit à l’encapsulation et si votre file WAN l’honore. S’il disparaît sur le paquet externe, vous devez faire de la QoS à la sortie du tunnel, pas espérer.

Task 6: Confirm DSCP on the VPN outer packet

cr0x@server:~$ sudo tcpdump -ni eth0 -vv udp port 51820 -c 5
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:12:03.220011 IP (tos 0x00, ttl 64, id 12001, offset 0, flags [DF], proto UDP (17), length 208) 203.0.113.5.51820 > 203.0.113.9.51820: UDP, length 180
12:12:03.240022 IP (tos 0x00, ttl 64, id 12002, offset 0, flags [DF], proto UDP (17), length 208) 203.0.113.5.51820 > 203.0.113.9.51820: UDP, length 180

Signification : les paquets externes ne sont pas marqués (tos 0x00). Même si le RTP interne est EF, l’ISP ne voit que l’externe.
Décision : Appliquez la classification sur la passerelle VPN : identifiez les flux voix avant le chiffrement (ou par heuristiques de port/peer) et définissez DSCP/priorité à la sortie.

Task 7: Identify the real bottleneck and current qdisc

cr0x@server:~$ tc qdisc show dev eth0
qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn

Signification : fq_codel est actif. C’est une bonne base pour la latence sous charge.
Décision : Si vous voyez pfifo_fast ou un qdisc fournisseur profond en bord WAN, prévoyez de déployer shaping + fq_codel/cake là où la congestion survient.

Task 8: Check qdisc stats for drops/overlimits (shaping trouble)

cr0x@server:~$ tc -s qdisc show dev eth0
qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
 Sent 98234123 bytes 84521 pkt (dropped 213, overlimits 0 requeues 12)
 backlog 0b 0p requeues 12
  maxpacket 1514 drop_overlimit 213 new_flow_count 541 ecn_mark 0

Signification : Quelques drops sont survenus. Les drops ne sont pas toujours mauvais — les drops contrôlés peuvent prévenir une latence massive. Mais drops + audio robotique suggèrent que vous perdez du RTP, pas du bulk.
Décision : Ajoutez de la classification pour que la voix ait la priorité (ou au moins l’isolation), et assurez-vous que le taux de shaping correspond à l’uplink réel.

Task 9: Quick jitter and loss check with mtr (baseline)

cr0x@server:~$ mtr -rwzc 50 203.0.113.9
Start: 2025-12-28T12:20:00+0000
HOST: server                          Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 192.0.2.1                         0.0%    50    1.1   1.3   0.9   3.8   0.6
  2. 198.51.100.1                      0.0%    50    8.2   8.5   7.9  13.4   1.1
  3. 203.0.113.9                       0.0%    50   19.0  19.2  18.6  26.8   1.4

Signification : Pas de perte, latence stable, faible gigue (StDev). Bon baseline.
Décision : Si vous voyez de la perte au saut 1 sous charge, c’est votre LAN/Wi‑Fi/routeur. Si la perte commence plus loin, c’est en amont — encore peut-être corrigeable avec du shaping à votre bord.

Task 10: See if VPN gateway CPU is causing packet scheduling delays

cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.5.0 (vpn-gw) 	12/28/2025 	_x86_64_	(8 CPU)

12:21:01     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
12:21:02     all   18.20    0.00   22.40    0.10    0.00   21.70    0.00    0.00    0.00   37.60
12:21:02       0   20.00    0.00   28.00    0.00    0.00   30.00    0.00    0.00    0.00   22.00

Signification : Un softirq élevé peut indiquer un fort traitement de paquets (chiffrement, forwarding).
Décision : Si softirq est saturé pendant les problèmes d’appel, envisagez d’activer le multiqueue, passer à un crypto plus rapide, ajouter de la marge CPU, ou réduire l’overhead VPN (MTU et offloads).

Task 11: Inspect NIC offloads (can break captures, sometimes timing)

cr0x@server:~$ sudo ethtool -k eth0 | egrep 'tso|gso|gro'
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on

Signification : Les offloads sont activés. Généralement OK, mais peuvent perturber les captures et dans certains cas interagir mal avec les tunnels.
Décision : Pour un dépannage précis, désactivez temporairement GRO/LRO sur un hôte test, puis retestez. Ne désactivez pas les offloads sur des passerelles chargées sans plan.

Task 12: Check UDP receive errors and drops

cr0x@server:~$ netstat -su
Udp:
    128934 packets received
    12 packets to unknown port received
    0 packet receive errors
    4311 packets sent
UdpLite:
IpExt:
    InOctets: 221009331
    OutOctets: 198887112

Signification : Les erreurs de réception UDP sont nulles. Bien.
Décision : Si les erreurs de réception augmentent pendant les appels, vous pourriez atteindre des limites de buffers de sockets ou des drops noyau ; ajustez les buffers, corrigez la saturation CPU, ou réduisez la contention du trafic.

Task 13: Verify SIP/RTP packet rate during a call (sanity check)

cr0x@server:~$ sudo tcpdump -ni any udp portrange 10000-20000 -ttt -c 10
tcpdump: listening on any, link-type LINUX_SLL2, snapshot length 262144 bytes
 0.000000 IP 192.0.2.10.14562 > 198.51.100.20.10012: UDP, length 186
 0.019884 IP 192.0.2.10.14562 > 198.51.100.20.10012: UDP, length 186
 0.020042 IP 192.0.2.10.14562 > 198.51.100.20.10012: UDP, length 186
 0.019901 IP 192.0.2.10.14562 > 198.51.100.20.10012: UDP, length 186

Signification : Un timing inter-paquets autour de 20 ms suggère ptime=20ms (commun). De grands écarts indiquent de la gigue ou des délais d’ordonnancement.
Décision : Si le timing est irrégulier au point de capture proche de l’expéditeur, examinez CPU/ Wi‑Fi de l’émetteur. S’il est régulier à l’émetteur mais irrégulier au récepteur, c’est le réseau/les files d’attente.

Task 14: Identify whether traffic is going through the VPN or bypassing it

cr0x@server:~$ ip route get 198.51.100.20
198.51.100.20 via 10.10.0.1 dev wg0 src 10.10.0.2 uid 1000
    cache

Signification : La route vers le point média utilise wg0.
Décision : Si votre test « bypass VPN » route encore via wg0, vous n’avez rien contourné. Corrigez le policy routing/split tunnel, puis comparez la qualité d’appel.

Task 15: Confirm MTU on the physical WAN interface (and spot jumbo mismatch)

cr0x@server:~$ ip link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff

Signification : L’interface WAN est en MTU standard 1500.
Décision : Si vous êtes en PPPoE ou certains liens cellulaires, le MTU WAN peut être plus petit (1492, 1428, etc.). Cela vous pousse à abaisser le MTU du tunnel.

Task 16: Spot bufferbloat under load with a simple ping while saturating uplink

cr0x@server:~$ ping -i 0.2 -c 20 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=18.9 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=210.4 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=245.7 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=198.1 ms

--- 1.1.1.1 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 3812ms
rtt min/avg/max/mdev = 18.4/156.2/265.1/72.9 ms

Signification : Les latences explosent sous charge : bufferbloat classique.
Décision : Déployez du SQM shaping sur l’uplink et priorisez la voix ; ne perdez pas de temps à chasser les codecs.

Trois mini-récits d’entreprise depuis le terrain

Incident #1 : La mauvaise hypothèse (MTU « ça ne peut pas être, on utilise 1500 partout »)

Une entreprise de taille moyenne a migré un centre d’appels vers des softphones sur un VPN full-tunnel. Ça a fonctionné en pilote. Puis ils l’ont déployé à quelques centaines d’agents distants.
En moins d’une journée, la file d’assistance est devenue un second centre d’appels — mais avec un audio pire.

L’équipe réseau a d’abord tenu l’hypothèse classique : « Le MTU ne peut pas être en cause ; Ethernet c’est 1500, et le VPN est bien configuré. »
Ils se sont concentrés sur le fournisseur SIP, puis ont accusé le Wi‑Fi domestique, puis ont tenté de changer les codecs.
Les améliorations étaient aléatoires, ce qui est le pire type d’amélioration car cela encourage les superstitions.

Le motif qui a résolu l’affaire : l’audio robotique montait pendant certains flux d’appel — transferts, appels consultatifs, et lors des renégociations SRTP du softphone.
C’est à ces moments que les paquets de signalisation grossissaient, et dans certains scénarios le chemin VPN requérait de la fragmentation. Les messages ICMP « fragmentation needed » étaient bloqués sur le bord utilisateur par un réglage « sécurité ».
PMTUD black holes. Pas glamour. Très réel.

La correction fut ennuyeuse et décisive : définir un MTU conservateur pour le tunnel, clamp MSS pour la signalisation TCP, et documenter « ne pas bloquer tout ICMP » dans la baseline d’accès distant.
Ils ont aussi ajouté un test d’une page : DF ping à travers le tunnel vers un endpoint connu. Ça a permis d’attraper des régressions plus tard.

Leçon : « 1500 partout » n’est pas une conception. C’est un souhait.

Incident #2 : L’optimisation qui s’est retournée contre eux (prioriser la voix… en accélérant tout)

Une autre organisation disposait d’une passerelle VPN capable et voulait « une qualité voix premium ». Quelqu’un a activé l’accélération matérielle et les fast-paths sur le pare-feu bord.
Le débit a augmenté. La latence dans un test synthétique a baissé. Tout le monde a célébré.

Deux semaines plus tard, plaintes : « Audio robotique seulement pendant les gros uploads. » Ce détail comptait.
Sous charge, le fast path contournait des parties de la pile QoS et de gestion de file. Le bulk et la voix atterrissaient dans la même file profonde côté WAN.
L’accélération a amélioré le pic de débit, mais elle a supprimé le mécanisme qui gardait la latence stable.

Les ingénieurs ont fait ce que font les ingénieurs : ils ont ajouté plus de règles QoS. Plus de classes. Plus de correspondances. Ça a empiré.
La classification coûtait du CPU sur le slow path, tandis que le fast path continuait de renvoyer la majeure partie du trafic dans la même file de goulot.
Maintenant ils avaient de la complexité et toujours du bufferbloat.

La solution finale n’était pas « plus de QoS ». C’était : shaper l’uplink juste en dessous de la capacité réelle, activer un qdisc moderne, et garder le modèle de classes simple.
Puis décider si l’accélération était compatible avec cette politique. Là où ce n’était pas le cas, la voix a gagné.

Leçon : optimiser le débit sans respecter le comportement des files est la recette pour construire un moyen plus rapide de sonner terriblement.

Incident #3 : La pratique ennuyeuse qui a sauvé la situation (tests standard + contrôle de changement)

Une entreprise globale utilisait la voix sur IPsec entre succursales et le siège. Rien d’extraordinaire. La différence clé : ils traitaient la voix comme un service de production.
Chaque changement réseau avait une checklist pré-flight et post-flight, incluant quelques tests VoIP pertinents.

Un vendredi, un FAI a remplacé du matériel d’accès dans un bureau régional. Les utilisateurs ont remarqué un « léger robot » sur les appels.
L’équipe locale a exécuté les tests standards : ping idle vs ping sous charge uplink, DF pings pour MTU, et un rapide check DSCP sur la sortie WAN.
Ils n’ont pas débattu. Ils ont mesuré.

Les données ont montré que PMTUD était cassé sur le nouvel accès, et que le buffer upstream était plus profond qu’avant. Deux problèmes. Tous deux actionnables.
Ils ont légèrement abaissé le MTU du tunnel, activé MSS clamping, et ajusté le shaping pour maintenir la latence stable. Les appels se sont stabilisés immédiatement.

Lundi, ils ont escaladé vers le FAI avec des preuves nettes : horodatages, seuil d’échec MTU, et graphiques de latence sous charge.
Le FAI a fini par corriger la gestion d’ICMP plus tard. Mais l’entreprise n’a pas eu à attendre pour retrouver une voix utilisable.

Leçon : la fonctionnalité de fiabilité la plus efficace est un test répétable que vous lancez réellement.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom: robotic audio during uploads or screen sharing

Root cause: bufferbloat on upstream; voice packets stuck behind bulk traffic in a deep queue.
Fix: enable SQM (fq_codel/cake) and shape slightly below uplink; add simple priority for RTP/SIP on WAN egress.

2) Symptom: call connects, then audio drops or becomes choppy after a minute

Root cause: MTU/PMTUD black hole triggered by rekey, SRTP renegotiation, or SIP re-INVITE size increase.
Fix: set tunnel MTU explicitly; allow ICMP “frag needed”/PTB; for TCP signaling, clamp MSS.

3) Symptom: one-way audio (you hear them, they don’t hear you)

Root cause: NAT traversal issue or asymmetric routing; RTP pinned to wrong interface; firewall state/timeouts for UDP.
Fix: ensure correct NAT settings (SIP ALG usually off), confirm routes, increase UDP timeout on stateful devices, validate symmetric RTP if supported.

4) Symptom: fine on wired, bad on Wi‑Fi

Root cause: airtime contention, retries, or power-save behavior; VPN adds overhead and jitter sensitivity.
Fix: move calls to 5 GHz/6 GHz, reduce channel contention, disable aggressive client power save for voice devices, prefer wired for call-heavy roles.

5) Symptom: only remote users on a certain ISP have issues

Root cause: ISP upstream shaping/CGNAT behavior, poor peering, or ICMP filtering affecting PMTUD.
Fix: reduce tunnel MTU, enforce shaping at user edge if managed, test alternative transport/port, and collect evidence to escalate.

6) Symptom: “QoS is enabled” but voice still degrades under load

Root cause: QoS configured on the LAN while congestion is on the WAN; or DSCP marked on inner packets but not on outer tunnel packets.
Fix: prioritize at the egress queue that is actually congested; map/classify voice to outer packets; verify with tcpdump and qdisc stats.

7) Symptom: sporadic bursts of robot, especially at peak hours

Root cause: microbursts and queue oscillation; VPN concentrator CPU contention; or upstream congestion.
Fix: check softirq/CPU, enable pacing/SQM, ensure adequate gateway headroom, and avoid overcomplicated class hierarchies.

8) Symptom: calls are fine, but “hold/resume” breaks or transfers fail

Root cause: SIP signaling fragmentation or MTU issues affecting larger SIP messages; sometimes SIP over TCP/TLS affected by MSS.
Fix: MSS clamping, reduce MTU, allow ICMP PTB, and validate SIP settings (and disable SIP ALG where it mangles packets).

Listes de contrôle / plan étape par étape

Étape par étape : stabiliser la VoIP sur VPN en une semaine (pas un trimestre)

Choisissez un utilisateur représentatif en échec et reproduisez le problème à la demande (upload pendant un appel suffit généralement).
Pas de reproductibilité, pas de progrès.
Collectez les statistiques voix (depuis softphone/PBX) : gigue, perte, dissimulation, RTT si disponible.
Décidez : perte (réseau) vs CPU (endpoint) vs signalisation (SIP/MTU).
Confirmez le routage : assurez-vous que les médias traversent bien le VPN comme vous le pensez. Corrigez la confusion split tunnel tôt.
Mesurez le path MTU à travers le tunnel en utilisant des DF pings vers des endpoints connus.
Décidez d’un MTU sûr (conservateur vaut mieux que théorique).
Définissez le MTU du tunnel explicitement aux deux extrémités (et documentez pourquoi).
Évitez le réglage « auto » sauf si vous l’avez testé sur tous les types d’accès (ADSL, LTE, Wi‑Fi d’hôtel, etc.).
Clamp MSS TCP sur le tunnel pour les flux TCP forwardés (SIP/TLS, provisioning, management).
Trouvez le vrai goulot (généralement l’uplink). Utilisez ping-under-load pour confirmer le bufferbloat.
Déployez du SQM shaping au goulot, légèrement en dessous du débit, avec fq_codel ou cake.
Gardez les classes QoS simples et priorisez la voix uniquement là où cela compte : la file de sortie.
Vérifiez la gestion DSCP avec des captures : marquage interne, marquage externe, et si la file respecte cela.
Retestez le cas d’échec original (appel + upload) et confirmez les améliorations de gigue/perte.
Déployez progressivement avec un groupe canari et un plan de rollback. Les changements voix sont visibles par les utilisateurs immédiatement ; traitez-les comme un déploiement en production.

Checklist opérationnelle : à chaque intervention sur VPN ou WAN

Enregistrez les réglages MTU actuels (WAN + tunnel) et les politiques qdisc/shaping.
Exécutez un test DF ping MTU à travers le tunnel vers un endpoint stable.
Exécutez ping idle vs ping sous charge pour mesurer la régression bufferbloat.
Capturez 30 secondes de RTP pendant un appel test et vérifiez pertes/pics de gigue.
Confirmez DSCP sur le paquet externe côté WAN (si vous comptez sur le marquage).
Vérifiez softirq CPU de la passerelle sous charge.

Faits intéressants et contexte historique

Fait 1 : RTP (Real-time Transport Protocol) a été normalisé au milieu des années 1990 pour transporter des médias temps réel sur IP.
Fait 2 : SIP a gagné en popularité en partie parce qu’il ressemblait à HTTP pour les appels — textuel, extensible — parfait pour les fonctionnalités, parfois pénible pour le MTU.
Fait 3 : Une grande partie de la douleur PMTUD vient des pratiques de filtrage ICMP devenues courantes comme réponse de sécurité à l’époque précoce d’internet.
Fait 4 : Les premiers déploiements VoIP s’appuyaient souvent sur les marquages DiffServ (DSCP) en entreprise, mais la « QoS sur l’internet public » n’est jamais devenue fiable à grande échelle.
Fait 5 : L’adoption des VPN a explosé pour le travail à distance, et les plaintes sur la qualité voix ont suivi car les uplinks grand public sont typiquement le segment le plus étroit et le plus sujet au bufferbloat.
Fait 6 : WireGuard est devenu populaire en partie parce qu’il est léger et rapide, mais le « crypto rapide » n’annule pas les « mauvaises files ».
Fait 7 : Le bufferbloat a été identifié et nommé parce que le matériel grand public livrait des buffers trop profonds qui amélioraient les benchmarks de débit tout en détruisant les applications sensibles à la latence.
Fait 8 : Les qdiscs Linux modernes comme fq_codel ont été conçus pour maintenir la latence bornée sous charge, ce qui est crucial pour la voix et le gaming.
Fait 9 : Beaucoup de designs VPN d’entreprise supposaient historiquement un underlay 1500 octets ; la généralisation de PPPoE, LTE, et l’empilement de tunnels a rendu cette hypothèse fragile.

FAQ

1) Pourquoi l’audio est-il « robotique » et pas juste faible ou retardé ?

Parce que vous entendez la dissimulation de perte de paquets. Le décodeur devine les trames audio manquantes. Un son faible/volume bas est généralement un problème de gain ou de périphérique ; le robotique est généralement perte/gigue.

2) Quel pourcentage de perte devient audible pour la VoIP ?

Cela dépend du codec et de la dissimulation, mais même ~1% de perte peut être perceptible, surtout quand elle est en rafales. 0,1% stable peut passer ; 2% en rafales souvent non.

3) Le MTU n’est-il pas seulement un problème TCP ? RTP, c’est UDP.

Le MTU affecte aussi UDP. Si les paquets dépassent le path MTU et que PMTUD est cassé, ils sont jetés. De plus, la fragmentation augmente la sensibilité aux pertes et la gigue quand les fragments se retrouvent en concurrence dans les files.

4) Dois-je simplement mettre MTU à 1200 et passer à autre chose ?

Non. Vous perdrez en efficacité et vous pourriez casser d’autres protocoles ou chemins inutilement. Mesurez le path MTU, choisissez une valeur sûre et documentez-la. Conservateur, pas extrême.

5) Le marquage DSCP aide-t-il sur l’internet public ?

Parfois dans le domaine d’un FAI, souvent non de bout en bout. La victoire fiable est de prioriser là où vous contrôlez la file : votre sortie WAN et les bords gérés.

6) La QoS peut-elle corriger la perte de paquets due à un mauvais FAI ?

La QoS ne peut pas créer de bande passante. Elle peut empêcher des pertes/gigue auto-infligées en gérant vos propres files. Si l’ISP droppe en amont, il faut un meilleur chemin ou un autre fournisseur.

7) Pourquoi ça casse seulement quand quelqu’un upload un fichier ?

L’upload sature l’amont. Les files en amont s’allongent, la latence et la gigue explosent, et le RTP arrive en retard. Les tests de vitesse masquent souvent ça car ils valorisent les buffers profonds.

8) WireGuard est-il automatiquement meilleur qu’OpenVPN pour la voix ?

WireGuard est généralement moins lourd et plus simple à raisonner, mais la qualité voix dépend surtout de la correction MTU, de la gestion des files, et de la stabilité du routage. On peut casser la voix sur n’importe quel VPN.

9) Quelle est la politique QoS la plus simple qui fonctionne réellement ?

Shapez la sortie WAN légèrement en dessous du débit réel, puis priorisez la voix (RTP) au-dessus du bulk. Gardez le modèle de classes réduit. Vérifiez avec les stats qdisc et des appels réels.

10) Comment prouver que c’est le MTU et pas « le codec » ?

Reproduisez avec des DF ping et observez les échecs autour de tailles de paquets spécifiques ; corrélez avec des événements d’appel qui augmentent la taille de signalisation ; corrigez le MTU et voyez le problème disparaître sans toucher aux codecs.

Étapes pratiques suivantes

Si vous voulez des appels qui sonnent humains, traitez la voix comme un SLO de latence, pas comme une impression.

Exécutez le playbook de diagnostic rapide sur un utilisateur affecté et capturez des preuves : MTU, gigue sous charge, comportement DSCP.
Définissez explicitement le MTU du tunnel (commencez conservateur), et clamp MSS pour les chemins de signalisation TCP.
Déployez du SQM shaping au goulot d’uplink avec fq_codel/cake et priorisez la voix sur cette file.
Vérifiez avec des mesures (stats qdisc, tcpdump DSCP, mtr, et stats de gigue/perte du client), pas avec des impressions.
Documentez : le MTU choisi, pourquoi il a été choisi, et les tests de régression. Le vous du futur sera fatigué et peu impressionné.

La plupart des « mystères » VoIP-over-VPN ne sont que des réseaux qui font ce que font les réseaux. Réduisez la taille des paquets, rendez les files plus intelligentes, et faites en sorte que vos priorités soient réelles là où la congestion se produit.