Perte de paquets VoIP : impact sur la qualité des appels et rôle du SBC

Lorsqu’un appel se coupe, avale des syllabes ou devient saccadé au milieu d’une phrase, la cause est presque toujours la perte de paquets. Pas un mauvais codec, pas un signal faible, pas le téléphone de l’interlocuteur. Quelque part entre les deux extrémités, des fragments audio ont quitté un côté et ne sont jamais arrivés de l’autre.

Dans cet article, nous détaillons ce qu’est réellement la perte de paquets VoIP, pourquoi la voix en souffre bien plus que les données classiques, comment elle se mesure, les seuils à partir desquels les appels se dégradent, et le rôle d’un session border controller (SBC) pour la détecter et la contenir. Si vous exploitez une infrastructure vocale et recevez des tickets « l’appel était horrible », c’est à ce niveau que ces tickets se résolvent.

Ce qu’est réellement la perte de paquets

La perte de paquets est l’échec d’un ou plusieurs paquets de données à atteindre leur destination sur un réseau IP. Elle se mesure en pourcentage des paquets envoyés : si 1 000 paquets partent et que 980 arrivent, cela représente 2 % de perte. En pratique, « perdu » recouvre trois cas. Un paquet peut ne jamais arriver du tout, arriver si tard que le récepteur est déjà passé à la suite et le rejette, ou arriver corrompu et être écarté. Du point de vue de l’auditeur, les trois sonnent de la même façon.

Il est utile de distinguer la perte de paquets de ses deux proches parentes. La latence est le délai, le temps qu’un paquet met pour voyager d’un bout à l’autre. La gigue est la variation de ce délai, des paquets arrivant à intervalles irréguliers. La perte de paquets est une absence : le paquet n’est tout simplement pas là. Les trois interagissent — une gigue élevée peut se transformer en perte lorsqu’un paquet arrive trop tard pour être utilisé — mais ce sont des problèmes distincts avec des solutions distinctes.

Le média vocal transite par le Real-time Transport Protocol (RTP), défini dans la RFC 3550. Chaque paquet RTP porte un numéro de séquence et un horodatage, ce qui rend la perte détectable : lorsque le récepteur voit le paquet 41 arriver juste après le paquet 39, il sait que le paquet 40 a disparu.

Pourquoi la perte de paquets affecte la voix plus que les données

Le trafic de données ordinaire — un téléchargement de fichier ou une page web — utilise TCP, qui retransmet tout ce qui se perd. Un paquet perdu ? TCP le renvoie tout simplement. Le fichier arrive intact, juste un peu plus lentement, et vous ne vous en apercevez pas.

La voix ne peut pas fonctionner ainsi. Une conversation en direct utilise UDP et RTP sans retransmission, car un paquet audio qui arrive 300 millisecondes en retard est inutile. Le moment qu’il devait combler est déjà passé. Le redemander ne ferait qu’aggraver le délai. Donc quand un paquet RTP est perdu, il reste perdu, et l’audio qu’il transportait est simplement absent.

Chaque paquet RTP contient généralement environ 20 millisecondes de son. Un seul paquet perdu crée un trou de 20 millisecondes, perçu comme un léger clic ou une consonne tronquée. Perdez des paquets de manière dispersée et le cerveau compense la plupart d’entre eux. Le vrai dégât vient de la perte en rafale — plusieurs paquets consécutifs disparus d’un coup — qui laisse un trou suffisamment long pour avaler un mot entier. C’est pourquoi deux appels avec le même taux de perte de 2 % peuvent sonner très différemment : celui qui perd des paquets en rafale est bien pire que celui qui les perd aléatoirement.

Comment la perte de paquets est mesurée et ce qui est acceptable

La perte s’exprime en pourcentage de paquets RTP, et le récepteur la calcule à partir des trous dans les numéros de séquence. Le protocole compagnon de RTP, RTCP, transporte ces statistiques en retour afin que les deux extrémités, ainsi que tout équipement dans le chemin média, puissent voir en temps réel comment un appel se comporte.

L’autre indicateur essentiel est le Mean Opinion Score (MOS), l’échelle standard de 1 à 5 évaluant la qualité vocale perçue. La perte de paquets est l’un des principaux facteurs d’un calcul de MOS, aux côtés de la gigue et de la latence ; elle se manifeste donc généralement par une baisse du MOS avant qu’un utilisateur ne dépose une plainte. Le MOS est au cœur de toute approche sérieuse de la surveillance VoIP.

En règle générale — et ce n’est qu’un repère, car le codec utilisé modifie les chiffres — une perte inférieure à environ 1 % est généralement acceptable pour un appel G.711 standard. Entre 1 % et 3 %, elle devient perceptible, avec des mots occasionnellement tronqués. Au-delà d’environ 5 %, la plupart des appels sont inutilisables. Ces seuils sont largement publiés, mais l’essentiel pour un opérateur est plus simple : vous ne devriez pas deviner où vos appels se situent sur cette échelle. Les chiffres proviennent des statistiques RTP par appel, et si vous ne les collectez pas, vous naviguez à l’aveugle.

Les causes de la perte de paquets sur les réseaux vocaux

La congestion réseau est la cause la plus fréquente. Quand un lien arrive à saturation, les files d’attente débordent et le routeur n’a d’autre choix que de rejeter des paquets. La voix, petite et constante, est prise dans le même débordement que tout le reste, sauf si elle est protégée.

Cette protection est le deuxième enjeu. Sur un lien sans politique de Quality of Service (QoS) et sans marquage DSCP, les paquets vocaux sont en concurrence à armes égales avec le trafic de masse comme les sauvegardes et les transferts de fichiers, et un seul transfert volumineux peut affamer un appel. Au-delà de la congestion, les suspects habituels sont les transitions sans fil et de dernier kilomètre — interférences Wi-Fi et circuits d’accès surchargés —, les anomalies de routage qui envoient les paquets par un chemin détourné ou dans un trou noir, et les pannes matérielles classiques comme une NIC défaillante ou un port switch instable. Enfin, il y a la perte auto-infligée : pousser plus d’appels simultanés à travers un équipement média que ce pour quoi il a été dimensionné, le faisant lui-même rejeter des paquets. Quand une perte apparaît, une démarche structurée de dépannage VoIP est ce qui distingue une résolution rapide d’une panne prolongée.

Comment un SBC détecte et contient la perte de paquets

C’est ici qu’un session border controller gagne sa place dans un réseau vocal. Un SBC fonctionne comme un back-to-back user agent (B2BUA), ce qui signifie qu’il termine la relation de signalisation d’un côté et en crée une nouvelle de l’autre, plutôt que de simplement transférer les paquets. Lorsqu’il se trouve dans le chemin média, il peut mesurer la perte RTP sur chaque segment indépendamment.

Cette indépendance est l’apport le plus précieux d’un SBC pour le dépannage de la perte de paquets. Une plainte brute comme « l’appel sonnait mal » ne vous dit rien sur l’origine du problème. Mais si le SBC montre un RTP propre sur le segment d’accès vers votre client et une perte importante sur le segment opérateur, le problème vient de l’opérateur, et vous pouvez escalader avec des preuves au lieu d’ouvrir un jeu de devinettes. Inversez les lectures et le problème est de votre côté.

ProSBC expose cette visibilité directement. Il produit des scores MOS par appel ainsi que des mesures de gigue et de perte de paquets, et les rend disponibles via SNMP et CDR (Call Detail Record), de sorte que les données s’intègrent à la plateforme de surveillance que vous utilisez déjà. Pour une inspection approfondie, il prend également en charge la capture de paquets en direct et le traçage complet des appels SIP et RTP, permettant à un ingénieur d’extraire les paquets réels d’un appel problématique plutôt que de travailler à partir de compteurs récapitulatifs. TelcoBridges dispose de plus de vingt ans d’expérience en déploiement SIP et média derrière cette capacité, et ProSBC gère le média à l’échelle opérateur.

Le SBC vous offre également deux leviers pour prévenir la perte plutôt que simplement l’observer. La négociation de codec permet au SBC de choisir un codec adapté au lien, puisqu’un codec à débit réduit sur une connexion contrainte sollicite moins la bande passante et laisse plus de marge. Le contrôle d’admission d’appels plafonne le nombre de sessions simultanées, ce qui empêche le chemin média d’être poussé vers la perte induite par la congestion décrite plus haut. Utilisés ensemble, ils éliminent la perte auto-infligée.

Un avertissement honnête : un SBC ne peut pas créer de la bande passante, et il ne peut pas récupérer de l’audio qu’un réseau tiers a déjà perdu. Ce qu’il fait, c’est mesurer la perte avec précision, la localiser sur un segment spécifique, et prévenir les conditions de surcharge qui causent la perte au sein de votre propre infrastructure. Au quotidien, c’est l’essentiel de la bataille.

Réduire la perte de paquets en pratique

Quelques bonnes pratiques maintiennent la perte sous contrôle. Dimensionnez et priorisez d’abord : marquez le RTP avec la bonne valeur DSCP pour qu’il bénéficie de la priorité QoS, et conservez une marge de bande passante réelle plutôt que de faire tourner les liens à la limite. Calibrez votre capacité d’appels simultanés et appliquez-la avec le contrôle d’admission, afin qu’un pic de trafic soit rejeté à l’entrée plutôt que de dégrader chaque appel en cours. Adaptez les codecs au lien en choisissant une option à débit réduit lorsque la bande passante est limitée. Par-dessus tout, surveillez en continu plutôt que de manière réactive, car les statistiques par appel révèlent une tendance avant les clients. Et quand une perte apparaît, localisez-la avec des données par segment avant d’escalader, afin que la conversation avec votre opérateur parte de faits.

Foire aux questions

Conclusion

La perte de paquets, c’est de l’audio manquant — du son que le réseau était censé transmettre et n’a pas transmis. La voix la ressent de manière aiguë car, contrairement à un téléchargement de fichier, elle ne peut pas attendre un deuxième essai. Un taux de perte de quelques pour cent suffit à ruiner un appel, et la perte en rafale est pire que ne le suggère le pourcentage seul. La solution passe par la mesure et la localisation : connaissez vos chiffres de perte par appel, et identifiez le segment responsable avant d’agir.