Appels VoIP hachés ou coupés : diagnostiquer la qualité audio en Belgique

Commencer par le symptôme, pas par une solution

Décrire précisément ce que chaque interlocuteur entend réduit immédiatement le nombre d’hypothèses. « Mauvaise qualité » peut désigner au moins six phénomènes qui ne suivent pas la même piste.

Voix hachée ou mots manquants

Des fragments audio disparaissent lorsque des paquets arrivent trop tard, dans le désordre ou pas du tout. Si seule la personne distante vous entend mal, examinez d’abord le trajet montant depuis votre site. Si vous seul l’entendez mal, regardez le trajet descendant. La distinction évite de moyenner deux flux dont un seul est dégradé.

Voix robotique ou métallique

Le codec et le mécanisme de dissimulation tentent de reconstruire un son incomplet. Une brève perturbation Wi-Fi, une file d’attente saturée ou un changement de réseau peut produire cette impression sans couper l’appel. Notez si le phénomène apparaît au début, pendant un transfert, lorsque la vidéo démarre ou à heure fixe.

Délai et personnes qui se coupent la parole

Un délai aller-retour élevé ne supprime pas nécessairement des mots, mais casse le rythme naturel. Il peut provenir d’un accès Internet lent, d’un VPN qui détourne le média, d’un chemin géographique inutilement long ou de files d’attente chargées. Demandez si le délai est constant ou seulement présent pendant les périodes de pointe.

Écho, audio à sens unique ou appel qui tombe

L’écho peut être acoustique — haut-parleur et micro — ou lié à une adaptation du terminal. L’audio à sens unique pointe souvent vers le trajet média, le NAT, un pare-feu ou une négociation d’adresses. Une coupure après une durée régulière suggère plutôt un délai d’expiration, une session ou une signalisation qu’une simple gigue. Chaque motif doit être consigné sans conclure trop tôt.

La page GVISION dédiée à la téléphonie VoIP pour les organisations belges présente le service et les architectures possibles. Ici, l’objectif est différent : construire un diagnostic réutilisable sur Teams Phone, un PBX Yeastar, un softphone ou un téléphone IP.

Collecter les preuves minimales pour chaque appel

Un ticket « ça coupe depuis hier » est presque impossible à corréler ; un appel horodaté avec contexte peut être retrouvé dans les journaux. Préparez un formulaire court que le support peut compléter en moins de deux minutes.

Conservez l’heure locale à la minute près et le fuseau si plusieurs pays interviennent, les numéros ou comptes concernés, le sens entrant ou sortant, l’appel interne ou externe, le site, l’appareil, le casque, l’application, la connexion Ethernet, Wi-Fi, 4G/5G ou VPN, ainsi que la personne qui entend le défaut. Ajoutez une phrase littérale : « l’appelant externe ne m’entend plus pendant dix secondes », par exemple.

Demandez ensuite si le problème est reproductible, s’il touche un utilisateur, une salle, un étage, un site, un opérateur ou tous les appels. Un incident isolé mérite d’être enregistré, mais un motif permet de choisir la prochaine mesure. Trois appels témoins réussis sont aussi utiles que trois échecs : ils montrent ce qui distingue un trajet sain.

Ne collectez pas inutilement le contenu de la conversation. Les métadonnées techniques suffisent généralement. Si un enregistrement est envisagé, appliquez les règles internes de confidentialité et d’information. Le but est d’identifier les interfaces, pas d’écouter les échanges professionnels.

Dans Microsoft Teams, le Call Quality Dashboard et les données par appel aident à distinguer utilisateurs, sous-réseaux, types de connexion et flux. Le guide Microsoft sur l’examen de la qualité d’expérience avec CQD, mis à jour le 16 juin 2026, recommande d’observer les tendances et les zones problématiques, pas seulement une plainte individuelle.

Latence, gigue, perte et MOS : ce que les mesures disent réellement

Aucune mesure ne suffit seule : l’interprétation doit relier le chiffre au sens du flux, au moment de l’appel et à la plateforme.

Perte de paquets

La voix temps réel ne peut pas attendre longtemps une retransmission. Une perte brève peut être masquée ; une rafale produit des syllabes manquantes ou un son robotique. Une moyenne sur une journée peut cacher trente secondes désastreuses. Cherchez la distribution, les pics et le sens affecté.

Gigue

La gigue est la variation du délai entre paquets. Le tampon de gigue remet le flux dans l’ordre et absorbe une variation raisonnable, au prix d’un peu de délai. S’il est trop petit, les paquets tardifs sont rejetés ; trop grand, la conversation devient lente. La documentation Yeastar sur le jitter buffer décrit ce compromis et distingue les modes fixes et adaptatifs.

Latence et aller-retour

La latence influence l’interactivité. Un ping vers un serveur quelconque ne représente pas nécessairement le chemin média réel. Mesurez vers la plateforme ou les points pertinents et séparez, si possible, poste vers réseau, accès Internet et service. Le test de connectivité Microsoft utilise comme objectifs de réussite moins de 1 % de perte UDP, moins de 100 ms de latence et moins de 30 ms de gigue ; ce sont des seuils propres à ce test, pas une loi universelle pour chaque opérateur ou PBX.

MOS

Le Mean Opinion Score condense plusieurs paramètres en une estimation de qualité. Il facilite le tri, mais peut être calculé différemment selon les produits. Yeastar classe dans son rapport QoS un MOS inférieur à 3,5 comme mauvais, de 3,5 à moins de 4 comme moyen et de 4 à 5 comme bon. Utilisez cette classification dans son contexte, et gardez les mesures brutes pour expliquer le score.

Isoler cinq domaines de panne

Le diagnostic devient gérable lorsqu’on attribue chaque test à un domaine : terminal, LAN/Wi-Fi, WAN/Internet, sécurité média ou plateforme/opérateur.

1. Terminal et audio

Testez un autre casque, un autre port USB, le combiné et un autre appareil. Vérifiez les pilotes, la charge CPU, les économies d’énergie, le firmware et l’application. Si le défaut suit le casque, inutile de modifier la QoS du routeur. Si plusieurs appareils d’un même bureau échouent, remontez vers le réseau.

2. Réseau local et Wi-Fi

Comparez le même appel sur Ethernet. Contrôlez couverture, interférences, itinérance, occupation des canaux, erreurs de ports, duplex, alimentation PoE et files d’attente. Un signal Wi-Fi fort ne garantit ni faible contention ni absence de retransmissions. Un téléphone IP câblé et un softphone sans fil empruntent aussi des chemins locaux différents.

3. WAN, Internet et VPN

Regardez saturation montante et descendante, pertes, changements de route, double accès, SD-WAN et incidents opérateur. La sauvegarde cloud, la synchronisation ou une visioconférence peut remplir une file malgré un bon débit contractuel. Un VPN qui centralise inutilement le média ajoute parfois latence et points de panne ; vérifiez le dessin de la plateforme avant toute exception.

4. Pare-feu, NAT et SBC

Le média RTP ou SRTP doit passer dans les deux sens avec les ports, adresses et durées de session attendus. Les inspections, transformations SIP, délais NAT ou plages trop étroites peuvent produire audio unidirectionnel et coupures. Microsoft avertit qu’une plage de ports média trop restrictive peut provoquer des appels abandonnés et une mauvaise qualité. Ne désactivez cependant pas une fonction comme SIP ALG au hasard : validez d’abord la recommandation du fournisseur et la topologie.

5. PBX, cloud, trunk et réseau téléphonique

Un appel interne sain et un appel externe dégradé oriente vers le SBC, le trunk, l’opérateur ou la terminaison distante. Comparez entrants et sortants, destinations, codecs, transcodages et routes. Les journaux du PBX et du fournisseur doivent être corrélables à l’appel témoin. Sans numéros et heure exacte, l’analyse s’arrête souvent à une impression.

Matrice de décision : quel test effectuer ensuite ?

Le meilleur test change une seule variable et produit une interprétation claire. Cette matrice évite les modifications simultanées qui rendent le résultat inutilisable.

Une procédure de diagnostic en trente minutes

En trente minutes, on ne résout pas chaque incident, mais on peut produire un périmètre, deux comparaisons propres et une escalade exploitable.

1. Minutes 0–5 : qualifier. Relevez trois appels récents, le sens affecté, les sites, appareils, réseaux et symptômes.
2. Minutes 5–10 : reproduire. Appelez une destination stable avec le même utilisateur. Notez l’heure exacte et ce que chacun entend.
3. Minutes 10–15 : changer une variable. Passez de Wi-Fi à Ethernet ou changez de casque, sans modifier le compte et la destination.
4. Minutes 15–20 : comparer le trajet. Testez un appel interne puis externe, ou entrant puis sortant.
5. Minutes 20–25 : lire les preuves. Ouvrez CQD, le rapport PBX/SBC et les compteurs réseau correspondant à l’heure.
6. Minutes 25–30 : décider. Attribuez un domaine probable, consignez ce qui est exclu et désignez le prochain propriétaire.

Un test de vitesse grand public n’est qu’un indice. Il mesure souvent un serveur proche, sur quelques flux parallèles, sans représenter le trafic UDP, la route vers le service, les microcoupures ou la file montante au moment précis. Complétez-le par une mesure continue, un appel témoin et les outils de la plateforme. L’outil IP Ping de Yeastar peut par exemple vérifier reachabilité, latence et perte depuis le PBX vers une cible pertinente.

Quand la QoS améliore réellement les appels

La qualité de service est utile quand des paquets voix concurrencent d’autres flux sur un lien ou une file que vous contrôlez. Elle ne crée pas de capacité et ne garantit pas le traitement au-delà de votre domaine.

Commencez par classifier correctement le média, marquer les paquets aux points cohérents et configurer les équipements qui mettent effectivement les flux en file. Microsoft recommande DSCP 46 pour l’audio Teams et précise que le marquage au terminal doit être accompagné d’une configuration correspondante sur les équipements réseau. Si un commutateur efface le marquage ou si le routeur ignore la classe, l’étiquette n’apporte rien.

Dimensionnez aussi la file. Une priorité absolue sans limite peut affamer d’autres services ; une classe trop petite laisse tomber la voix pendant un pic. Sur Internet, les marquages peuvent être modifiés ou ignorés. La QoS reste surtout déterminante dans le LAN, sur un WAN privé, un SD-WAN ou un accès où l’organisation et l’opérateur ont convenu du traitement.

Avant de déployer, identifiez où se produit la congestion. Les recommandations QoS de Microsoft pour Teams expliquent la classification et les plages. Appliquez-les à Teams, pas automatiquement à chaque PBX. Pour un trunk SIP ou Yeastar, utilisez les exigences documentées de l’éditeur et de l’opérateur.

GVISION peut rapprocher téléphonie et architecture réseau et Wi-Fi afin que VLAN, files, couverture, accès Internet et supervision racontent la même histoire. Cette étape est pertinente quand les tests montrent un problème récurrent de transport, pas lorsqu’un seul casque est défectueux.

Les erreurs qui prolongent les incidents VoIP

Changer plusieurs paramètres à la fois, se fier au débit ou escalader sans appel témoin détruit la valeur du diagnostic.

• Redémarrer avant de noter : les journaux et l’heure utile disparaissent.
• Confondre signal Wi-Fi et qualité : un bon niveau radio peut cacher contention et retransmissions.
• Utiliser un seul speed test : il ne représente ni le chemin média ni les rafales de perte.
• Appliquer des seuils universels : les outils, codecs et méthodes de calcul diffèrent.
• Activer la QoS sans congestion mesurée : la complexité augmente sans traiter la cause.
• Désactiver SIP ALG systématiquement : le comportement dépend du pare-feu, du PBX et du fournisseur.
• Ignorer le sens du défaut : les deux interlocuteurs peuvent vivre des qualités différentes.
• Oublier les appels réussis : ils constituent le groupe de comparaison.
• Accuser l’opérateur trop tôt : aucun numéro, horaire ou trajet ne permet la recherche.
• Déclarer résolu après un seul appel : testez le pic et les fonctions qui échouaient.