Problèmes de qualité des appels VoIP : comment diagnostiquer les cinq zones de défaillance et les corriger

Lorsqu’un client signale un appel de mauvaise qualité, la première information utile est de savoir quel type de problème est en cause. Un appel qui ne s’est jamais connecté relève de la signalisation. Un appel connecté sans audio est un problème de chemin média. Un appel connecté, avec de l’audio dans les deux directions, qui sonne quand même mal est le sujet de cet article : un problème de qualité audio, où chaque couche sous-jacente semble fonctionner et le résultat audible reste médiocre.

Les plaintes relatives à la qualité audio se résolvent presque toujours par une cause unique : l’une des cinq zones de qualité est défaillante le long du chemin d’appel. Chaque zone laisse une empreinte différente dans les statistiques média par appel, chacune sonne différemment pour l’auditeur, et chacune possède son propre correctif. La discipline diagnostique consiste à associer le symptôme à la zone, puis à appliquer le correctif qui traite cette cause spécifique.

Cet article prend le relais là où le guide de dépannage VoIP plus général s’arrête et approfondit chaque zone. Pour le volet opérationnel de détection de ces problèmes avant les abonnés, le guide des meilleures pratiques de surveillance VoIP est la référence complémentaire.

Ce que signifie réellement un « audio de mauvaise qualité » : les cinq zones

Une plainte du type « l’appel sonnait mal » se résout presque toujours en l’un de cinq problèmes de qualité distincts. Les traiter séparément fait la différence entre un diagnostic efficace et un diagnostic qui modifie aléatoirement des paramètres jusqu’au prochain ticket.

Les cinq zones sont la perte de paquets, la gigue, le délai unidirectionnel, les artefacts de codec et de transcodage, et l’écho. Chacune possède une signature audible différente, une piste de preuves différente dans RTCP et le CDR, et un chemin de remédiation différent. Plus d’une zone peut être défaillante sur le même appel, mais en pratique opérationnelle, une zone est presque toujours le contributeur dominant et la corriger suffit à ramener l’appel à une qualité acceptable.

La suite de cet article parcourt chaque zone dans l’ordre : ce qui produit la défaillance, comment elle sonne, comment la confirmer à partir des preuves disponibles, et ce qu’il faut réellement modifier.

Zone 1 : perte de paquets

La voix est en temps réel. Il n’y a pas de retransmission. Un paquet qui n’arrive pas à temps est perdu, et le récepteur doit soit synthétiser un remplacement, soit jouer du silence pour cet intervalle. Toute perte soutenue au-dessus d’environ 1 pour cent devient audible, et au-dessus de 3 pour cent, l’appel est difficile à suivre.

La signature audible se caractérise par des mots tronqués, de courts silences, des claquements occasionnels ou des artefacts d’attaque, et une sensation « robotique » lorsque le PLC tente de compenser. Les abonnés décrivent cela comme « l’appel n’arrêtait pas de couper » ou « toutes les quelques secondes, je perdais un mot ».

La première preuve à consulter est le rapport de réception RTCP de chaque côté, ou le pourcentage de perte équivalent dans le CDR par appel du SBC. Si la perte dépasse 1 pour cent dans une direction et est proche de zéro dans l’autre, le chemin dans la direction affectée est le suspect. Si la perte est bilatérale, les deux directions partagent un nœud congestionné, généralement quelque part au milieu du chemin opérateur.

Les causes se regroupent en un ensemble restreint en exploitation réelle. La congestion WAN sur une route opérateur spécifique est la plus courante, et elle se manifeste généralement par des pics de perte pendant les heures de bureau sur les appels acheminés via cette jonction tandis que les autres jonctions restent propres. Les microrafales sur un lien surchargé produisent le même résultat audible mais avec des rafales de perte trop brèves pour apparaître dans les moyennes, visibles uniquement en PCAP. Les incompatibilités MTU et la fragmentation IP tendent à détruire des tailles de paquets spécifiques de manière systématique. L’instabilité de route sur le chemin BGP en amont produit des fenêtres de perte brèves mais sévères qui se répètent. Le Wi-Fi côté LAN est sa propre source de perte et n’est presque jamais visible depuis le SBC.

Les pistes de correction suivent approximativement cet ordre. Vérifiez que le marquage DSCP est appliqué sur l’interface du SBC et que ce marquage est effectivement respecté par chaque nœud intermédiaire. De nombreux opérateurs découvrent lors d’une investigation qualité que DSCP avait été configuré il y a des années et qu’une mise à jour de routeur quelque part sur le chemin a cessé de le respecter. Réacheminez les appels affectés via une jonction alternative pour confirmer que la perte est spécifique au chemin, pas à la plateforme. Si le SBC le prend en charge, activez la correction d’erreur directe (FEC) sur le segment faisant face au réseau défaillant. Examinez la charge sur le lien en amont et déchargez le trafic non vocal si voix et transfert en masse partagent la même file. Pour la perte Wi-Fi, le seul correctif réel est l’Ethernet filaire sur les postes concernés, ce qui relève d’une intervention de l’équipe LAN plutôt que d’une modification du SBC.

Une note spécifique sur le comportement des codecs sous perte. G.711 (PCM) envoie des échantillons audio bruts non compressés et ne dispose d’aucun PLC natif intégré au flux binaire standard, donc lorsqu’un paquet est perdu, un bloc d’audio brut est perdu avec lui. G.729 et les codecs prédictifs similaires incluent des mécanismes PLC qui tentent de maintenir la continuité du signal vocal lorsque des trames sont perdues.

Zone 2 : gigue

Si la perte de paquets concerne les paquets qui n’arrivent jamais, la gigue concerne les paquets qui arrivent au mauvais moment. Les codecs vocaux envoient un paquet toutes les 20 millisecondes (à un ptime typique de 20 ms), et le récepteur les attend à cette cadence. Lorsque le temps inter-arrivée varie, le tampon de gigue côté réception absorbe la variation jusqu’à sa taille configurée, puis soit rejette les paquets en retard, soit étire l’audio pour les attendre.

La signature audible est un audio instable et ondulant avec des pertes occasionnelles, parfois décrit comme « robotique » ou « sous l’eau ». Elle coexiste souvent avec un faible niveau de perte de paquets, car un tampon de gigue qui a dépassé sa capacité rejette les paquets arrivant en retard, lesquels apparaissent comme de la perte dans le rapport RTCP.

La preuve à consulter est le champ de gigue dans le rapport de réception RTCP et le CDR. En dessous de 20 ms, la situation est confortable pour presque tous les tampons. Entre 20 et 50 ms, la qualité perçue dépend fortement de la configuration du tampon. Au-dessus de 50 ms, le MOS descendra sous 3,5 pour la plupart des codecs, quel que soit le réglage du tampon.

Les causes diffèrent de celles de la perte de paquets, ce qui explique que les deux zones se distinguent nettement. La profondeur de file variable sur un nœud intermédiaire est la source principale : un routeur qui priorise la voix quand sa file est courte mais ignore la priorité quand la file se remplit. Un ordonnancement QoS incohérent sur un nœud virtualisé produit le même effet à l’intérieur d’un hyperviseur. La privation de CPU sur un PBX, SBC ou passerelle média virtualisé introduit de la gigue même lorsque le réseau sous-jacent est propre, car les paquets restent dans la pile réseau de l’hôte en attendant du temps vCPU. Le routage asymétrique, où les deux moitiés de l’appel empruntent des chemins différents, peut produire une gigue unidirectionnelle que le rapport RTCP bidirectionnel rend difficile à attribuer.

Le tampon de gigue est lui-même un contributeur fréquent à la qualité perçue, dans les deux sens. Sous-dimensionné, il rejette les paquets en retard et produit des pertes audibles. Surdimensionné, il ajoute de la latence que l’auditeur perçoit alors comme la zone 3 (délai unidirectionnel) et signale comme un problème distinct dans un ticket ultérieur. La plupart des récepteurs modernes utilisent des tampons de gigue adaptatifs qui se redimensionnent dans des limites configurées. Un tampon adaptatif ne reste pas simplement à son plafond de 200 ms ; il s’ajuste à la gigue réellement observée et tend à se stabiliser autour de 60 à 80 ms, la profondeur initiale plus une marge. Le plafond de 200 ms est un maximum, pas une cible, et une latence inutile n’apparaît que lorsque le tampon est mal réglé ou que l’algorithme surbuffèrise de manière agressive.

Les pistes de correction commencent par le tampon de gigue lui-même si le récepteur est sous le contrôle de l’opérateur. Définissez des limites adaptatives correspondant au profil réel du chemin, mesuré sur un échantillon représentatif. Si le nœud variable est identifiable par traceroute ou télémétrie par nœud, appliquez ou corrigez le QoS sur ce nœud. Si le SBC ou le PBX est virtualisé et qu’une privation de CPU est suspectée, fixez les vCPUs et réservez la mémoire, ou déplacez la charge vers du matériel dédié. Si le chemin traverse une zone connue de routage asymétrique (les clients d’entreprise multi-hébergés sont les cas les plus fréquents), ancrer le média sur le SBC divise l’appel en deux segments réseau distincts et gérables, ce qui isole la gigue sur un segment spécifique et empêche sa propagation de bout en bout.

Zone 3 : latence (délai unidirectionnel)

Le délai de bout en bout est la plus discrète des cinq zones, car elle ne dégrade pas nécessairement le son de l’audio. Ce qu’elle fait, c’est rendre la conversation impraticable. Au-dessus de 150 ms en unidirectionnel, les interlocuteurs commencent à se couper la parole ; au-dessus de 250 ms, la conversation ressemble à un appel satellite ; au-dessus de 400 ms, une conversation normale est impossible. La recommandation ITU-T G.114 définit ces seuils, et ils s’appliquent à l’ensemble du chemin de la bouche à l’oreille, pas uniquement au segment de l’opérateur.

La signature audible n’est pas une distorsion. L’appelant et l’appelé signalent des pauses gênantes, des chevauchements de parole, des « vous êtes là ? » répétés, et une impression générale que la conversation est désynchronisée. Ils décriront rarement l’audio lui-même comme mauvais.

La preuve à rechercher est le champ de délai unidirectionnel dans les statistiques de qualité du SBC. L’opérateur ne voit et ne contrôle que le segment du chemin qui traverse le SBC. Les segments restants (traitement du codec côté LAN, restitution du tampon de gigue, chemin opérateur côté distant) doivent être estimés ou mesurés séparément.

Les causes sont largement additives. La distance géographique contribue au délai de propagation physique (environ 1 ms pour 100 km sur fibre, davantage si le chemin emprunte des détours de routage). Les cycles d’encodage et de décodage ajoutent 10 à 30 ms par passage selon le codec, chaque passage de transcodage ajoutant un cycle complet supplémentaire. Le tampon de gigue est lui-même un élément de délai, typiquement 40 à 100 ms sur un chemin bien réglé et considérablement plus s’il est surdimensionné. Les segments satellite ajoutent 240 à 280 ms dans chaque direction. L’accès mobile (3G en particulier, mais aussi LTE et 5G) ajoute 50 à 150 ms côté radio que l’opérateur filaire ne peut pas réduire.

Les pistes de correction visent à raccourcir les contributeurs que l’opérateur contrôle. Réduisez les passages de transcodage en ajustant la politique de codec par NAP pour que le SBC négocie un codec commun lorsque c’est possible, éliminant entièrement le passage de transcodage. Déployez un SBC régional plus proche de la base de clients pour que le segment de l’opérateur soit court. Réajustez le tampon de gigue s’il a été identifié comme le contributeur dominant. Pour un centre de contact hébergé desservant des appelants sur plusieurs continents, répartir le trafic sur plusieurs SBC régionaux est souvent le seul chemin vers un délai conversationnel acceptable.

Zone 4 : artefacts de codec et de transcodage

Parfois l’appel bénéficie de conditions réseau propres, d’une gigue normale, d’une faible perte, d’un délai unidirectionnel raisonnable, et l’audio sonne quand même mal. Le suspect restant est le codec lui-même, ou la chaîne de codecs que l’audio a traversée.

Les signatures audibles varient. L’encodage en tandem à travers un codec à faible débit produit une qualité creuse et traitée que les abonnés décrivent comme « métallique » ou « téléphonique ». L’effondrement de la bande large vers la bande étroite produit une chute soudaine de fidélité évidente pour quiconque entendait le même correspondant sur un chemin large bande auparavant. Les codecs CS-ACELP (famille G.729) gèrent bien la voix propre et se dégradent fortement sur le bruit de fond, la musique d’attente, les sibilantes et tout signal intrabande comme les tonalités de fax ou le DTMF intrabande.

La preuve se trouve dans le SDP et le CDR. La trace d’appel du SBC montre le codec négocié sur chaque segment de l’appel. Si le segment entrant est en G.711, le segment sortant en G.729, et qu’un troisième saut en aval ré-encode en G.711, cela représente deux passages en tandem à travers un codec avec perte sur un seul appel. Le champ MOS dans le CDR reflétera la perte cumulée même si toutes les autres métriques de qualité sont propres. La comparaison G.711 vs G.729 approfondit l’arithmétique MOS par codec.

Les causes découlent du fonctionnement de la négociation SDP. Lorsque chaque côté propose un codec commun, l’appel procède sans transcodage. Lorsque les offres ne se recoupent pas, le SBC doit transcoder, ce qui signifie un cycle complet de décodage et ré-encodage pour chaque tranche de 20 ms d’audio pendant toute la durée de l’appel. L’encodage en tandem se produit lorsque le même appel est transcodé à nouveau à un saut en aval, généralement parce que la politique d’un autre opérateur impose un codec différent sur le segment suivant. L’effondrement de la bande large survient lorsqu’un segment en bande étroite se trouve quelque part dans le chemin ; Opus ou AMR-WB sur les terminaux ne survit pas à un segment de transit G.711 au milieu.

Les pistes de correction se concentrent sur la politique de codec. Configurez les préférences de codec par NAP pour que le SBC négocie un codec commun chaque fois que les deux côtés en supportent un, éliminant entièrement le passage de transcodage. Pour les routes premium où la bande passante n’est pas la contrainte, forcez G.711 de bout en bout pour éviter la perte perceptuelle des codecs compressés. Lorsque le transcodage est inévitable, centralisez-le en un seul point du chemin et empêchez les segments en aval de ré-encoder. Pour les chemins mobile-vers-IP, le guide de transcodage SBC AMR vers G.711 couvre les considérations spécifiques de qualité et de DSP.

Zone 5 : écho

L’écho est la zone la plus susceptible d’être mal diagnostiquée comme autre chose. Les abonnés se plaignent de s’entendre eux-mêmes, ou que le correspondant distant s’entend lui-même, et le premier réflexe est souvent de consulter les métriques de codec ou de réseau. Aucune d’entre elles ne montrera quoi que ce soit d’anormal, car l’écho est un artefact du chemin média qui se situe à un niveau différent des quatre zones déjà couvertes.

La signature audible est l’appelant qui entend une copie retardée de sa propre voix. L’écho n’affecte qu’une seule direction de l’appel à la fois : la partie dont l’audio est renvoyé en écho perçoit le problème, et l’autre partie ne perçoit rien. Un écho toujours présent à faible niveau devient audible lorsque la latence sur le chemin augmente, car l’oreille humaine cesse de percevoir l’écho lorsque le délai descend en dessous d’environ 25 ms (l’audio fusionne avec la parole originale) et commence à le percevoir nettement au-dessus de 50 ms.

La preuve est plus difficile à lire dans RTCP et le CDR. Le MOS peut refléter ou non l’écho, selon que l’estimation de qualité par appel inclut la mesure d’écho. La preuve la plus claire est le caractère unilatéral de la plainte : la partie A entend sa propre voix, la partie B n’entend rien d’anormal, et les métriques des deux moitiés de l’appel sont normales.

Les causes se situent presque toujours à la frontière analogique. Une conversion 2 fils vers 4 fils à un hybride analogique produit un écho électrique qui devrait être annulé par un annuleur d’écho sur la passerelle côté jonction. Lorsque l’annuleur est absent, mal réglé, ou dispose d’une longueur de queue insuffisante pour le chemin, l’écho résiduel passe à travers. L’autre source est l’écho acoustique au niveau du terminal : un haut-parleur ouvert, un casque mal réglé, ou un combiné tenu éloigné de l’oreille, avec l’audio du correspondant distant qui revient dans le microphone local.

Les pistes de correction commencent par l’identification du segment qui introduit l’hybride. Les passerelles PSTN et les frontières TDM-vers-IP sont les responsables habituels. Vérifiez que l’annuleur d’écho est activé sur ce segment, que sa longueur de queue est configurée pour le délai du chemin, et que les mesures d’ERL (echo return loss) et d’ERLE (echo return loss enhancement) sont dans les plages acceptables. Si l’écho n’est apparu que sur des appels auparavant propres, recherchez un changement récent qui a ajouté de la latence au chemin ; l’écho était toujours présent à faible niveau et la nouvelle latence l’a démasqué. Pour l’écho acoustique, le seul correctif réel est de modifier l’utilisation du terminal ou de remplacer le casque.

Le processus de diagnostic

Parcourir les cinq zones dans l’ordre fournit un arbre de décision fiable pour toute plainte active.

Commencez par les preuves RTCP et CDR de l’appel concerné. Lisez quatre valeurs : le pourcentage de perte, la gigue, le délai unidirectionnel (ou le RTT divisé par deux) et le MOS. Si la perte dépasse 1 pour cent dans l’une ou l’autre direction, le problème relève de la zone 1 et l’étape suivante est de trouver le chemin emprunté par la direction défaillante. Si la gigue dépasse 20 ms et tend vers 50 ms, le problème relève de la zone 2 et l’étape suivante est d’identifier le nœud variable ou le tampon de gigue mal réglé. Si le délai unidirectionnel dépasse 150 ms, le problème relève de la zone 3 et l’étape suivante est de décomposer le délai en ses contributeurs additifs. Si les quatre valeurs sont normales mais que le MOS est inférieur à 3,5, le problème relève de la zone 4, et la trace d’appel montrera la négociation de codec sur chaque segment. Si la plainte précise qu’une partie s’entend elle-même tandis que l’autre ne perçoit rien, et que les autres métriques sont propres, le problème relève de la zone 5, et la frontière analogique dans la direction affectée est le suspect.

Lorsque plus d’une zone dépasse le seuil, corrigez le contributeur dominant en premier et remesurez. Un appel avec 2 pour cent de perte et 30 ms de gigue s’améliorera après correction de la perte même si la gigue reste inchangée ; traiter les deux simultanément brouille les preuves.

Lorsque les preuves disponibles ne permettent pas d’identifier une zone de manière concluante, l’escalade suivante est un PCAP par appel sur l’interface du SBC pendant la durée de la plainte, ouvert dans Wireshark avec les outils d’analyse RTP. Le PCAP est la vérité de terrain lorsque CDR et RTCP divergent.

Ce qui ne relève PAS du SBC

Le SBC a de la visibilité sur le segment de l’appel qui traverse ses interfaces et très peu de visibilité sur le reste. Cette frontière compte pour deux raisons pratiques.

Les problèmes de terminal côté LAN sont hors de la fenêtre de mesure du SBC. Un poste sur un lien Wi-Fi congestionné, un softphone tournant sur un ordinateur en privation de CPU, un casque avec une annulation d’écho acoustique dégradée, ou un AGC mal configuré sur le terminal produiront tous des plaintes qualité qui semblent non attribuables depuis le SBC. Le SBC peut prouver que l’appel était propre sur son interface ; l’étape suivante incombe à l’équipe LAN ou au fournisseur du terminal.

Les chemins opérateur côté distant sont également hors de la fenêtre de mesure. Si un opérateur en aval perd des paquets dans son cœur de réseau, le SBC verra la perte dans le rapport RTCP entrant mais n’aura aucun détail au-delà. Le meilleur dossier à fournir à un opérateur en aval lors de l’escalade d’un problème de perte sur le réseau cœur est un PCAP à double extrémité, ou une capture prise directement à la frontière entrée/sortie du SBC. Les tickets vagues stagnent dans la file ; les tickets avec des preuves concrètes avancent plus vite. Pour une vue d’ensemble sur le moment et la manière de constituer une escalade, le guide de dépannage VoIP couvre l’escalade auprès des opérateurs en détail.

Comment ProSBC aide à résoudre les problèmes de qualité des appels VoIP plus rapidement

ProSBC est conçu autour de la réalité opérationnelle que les plaintes qualité arrivent et doivent être diagnostiquées rapidement. Le MOS par appel est calculé nativement au niveau du SBC, avec les champs sous-jacents de gigue, perte et délai unidirectionnel exposés dans chaque enregistrement CDR pour l’export texte et RADIUS. La décomposition en zones est ce qui rend le processus de diagnostic décrit ci-dessus utilisable sans sondes externes ni outils de synthèse.

La capture de paquets compatible Wireshark peut être activée en direct par appel ou par NAP sans rien redémarrer, ce qui signifie que la preuve PCAP est disponible dès qu’un ticket arrive. La trace d’appel SIP montre le codec négocié sur chaque segment, révélant l’encodage en tandem et les incompatibilités de codec qui produisent les plaintes de zone 4. Le moteur de routage API programmable prend en charge la politique de codec par NAP, qui est le point de contrôle pratique pour gérer les passages de transcodage sur un réseau multi-opérateur. Le transcodage matériel via Tmedia est disponible pour les environnements où une qualité de niveau DSP sur les transcodages AMR, Opus ou G.729 est requise à grande échelle.

Pour les fournisseurs qui souhaitent le volet tableau de bord sans le construire eux-mêmes, le Monitoring as a Service intègre les métriques de qualité par appel dans un tableau de bord géré avec des alertes en temps réel. Pour les opérateurs qui souhaitent que le travail de diagnostic soit pris en charge intégralement, le niveau Managed Service inclut ProSBC+ avec haute disponibilité 1+1, support niveau 3 en 24×7, modifications de configuration continues et surveillance permanente.