Qu’est-ce que la gigue ? Comment tester la gigue et la perte de paquets avant un appel

La gigue correspond aux variations du délai de votre connexion d’un instant à l’autre. La perte de paquets correspond à la proportion de données qui n’arrivent jamais à destination. Pendant un appel, une gigue élevée donne aux voix un son robotique, tandis que la perte fait disparaître des mots et des syllabes, même avec une connexion rapide. Microsoft indique que, pour l’audio dans Teams, les valeurs typiques sont inférieures à 30 ms de gigue et à 2 % de perte de paquets. Zoom recommande une gigue de 40 ms ou moins et une perte de 2 % ou moins. Vous pouvez mesurer ces deux paramètres dans un navigateur, depuis l’invite de commandes de Windows ou dans les statistiques intégrées à l’application de réunion.

Le guide sur les appels qui ralentissent malgré une connexion Internet rapide explique pourquoi le débit ne fait pas tout, et le guide sur la vérification de la connexion Internet avant un appel indique quand effectuer le test. Le présent guide explique la signification de ces deux valeurs et comment les mesurer.

Gigue et perte de paquets pendant un appel

L’audio et la vidéo sont transmis sous forme de petits paquets, à raison de nombreux paquets par seconde. Si chaque paquet mettait exactement 40 ms à arriver, l’appel aurait simplement 40 ms de retard et personne ne le remarquerait. La gigue correspond à l’irrégularité : un paquet met 20 ms, le suivant 70 ms. L’application de réunion stocke les paquets dans une mémoire tampon pour lisser ces variations. Microsoft indique que Teams peut s’adapter à une certaine gigue grâce à la mise en mémoire tampon, et que vous ne la remarquez que lorsqu’elle dépasse ce que la mémoire tampon peut absorber.

La perte de paquets est plus grave, car un paquet perdu ne peut pas être récupéré et l’application doit combler le vide. Le guide de Microsoft sur la qualité des appels décrit le son produit par chaque problème :

Quelles valeurs sont bonnes ?

Les applications de réunion publient leurs propres valeurs de référence. Elles correspondent aux objectifs pour le trafic d’appel de l’application elle-même ; utilisez-les comme échelle pour interpréter les résultats d’autres tests :

Une mesure isolée supérieure à ces valeurs ne signifie pas que l’appel va échouer. Une valeur qui reste élevée pendant plusieurs minutes, ou qui augmente dès qu’une autre personne commence à utiliser la connexion, mérite d’être corrigée avant l’appel.

Comment la gigue est calculée

Les outils mesurent la gigue de façons légèrement différentes ; comparez donc les résultats obtenus avec le même outil. Par exemple, le test de vitesse Cloudflare calcule la gigue comme la différence moyenne entre des mesures de latence consécutives. Avec cinq mesures de 20, 24, 19, 45 et 21 ms, les différences sont de 4, 5, 26 et 24 ms, soit une gigue d’environ 15 ms. La latence moyenne de 26 ms masque le fait qu’une mesure a pris environ deux fois plus de temps que les autres.

Trois façons de tester avant un appel

1. Un test dans le navigateur qui indique les deux valeurs

Ouvrir speed.cloudflare.com sur le PC que vous utiliserez pour rejoindre l’appel. Cloudflare explique que son test mesure la gigue lorsque la connexion est au repos et lorsqu’elle est occupée par des téléchargements et des envois, et qu’il mesure la perte de paquets en relayant des paquets par l’intermédiaire d’un serveur TURN WebRTC. Observez l’écart entre les résultats au repos et sous charge. Si la gigue augmente lorsque la connexion est occupée, une sauvegarde, une synchronisation dans le cloud ou l’envoi de données depuis un autre appareil remplit peut-être la ligne ; un appel subirait les mêmes effets.

2. Ligne de commande Windows : ping et pathping

Ouvrez l’invite de commandes ou le Terminal et exécutez :

ping -n 100 1.1.1.1

Par défaut, ping envoie quatre requêtes; -n 100 en envoie cent, ce qui prend une minute ou deux. La ligne de récapitulatif indique combien de requêtes ont été perdues et le pourcentage correspondant. Les durées minimale et maximale montrent l’écart entre les réponses les plus rapides et les plus lentes.

Pour repérer où les pertes commencent, exécutez :

pathping 1.1.1.1

pathping envoie 100 requêtes à chaque routeur de l’itinéraire et indique les pertes pour chacun d’eux. L’opération prend quelques minutes. Lisez attentivement les résultats : l’exemple de Microsoft montre des routeurs qui abandonnent les requêtes qui leur sont adressées, mais qui transmettent toutes les autres. Une perte qui apparaît sur un routeur et ne se poursuit pas jusqu’à la fin de l’itinéraire n’a pas d’importance. Une perte qui commence sur un routeur et se poursuit jusqu’à destination est réelle.

• Des pertes dès le premier saut, qui correspond à votre propre routeur, indiquent un problème de Wi-Fi ou de réseau domestique.
• Des pertes qui commencent plus loin indiquent un problème chez votre fournisseur d’accès ou au-delà.

3. Les propres mesures de l’application de réunion

C’est la seule méthode qui mesure l’appel lui-même. Dans Teams, ouvrez Plus d’actions → Paramètres → État de l’appel pendant un appel ; Microsoft indique que les valeurs sont mises à jour toutes les 15 secondes. Dans l’application de bureau Zoom, ouvrez Paramètres → Statistiques. Un appel de test suffit. Le guide sur les les appels de test Teams et les réunions de test Zoom indique où en lancer un.

Pour Teams, Microsoft propose également l’outil gratuit Teams Network Assessment Tool. Il envoie des paquets au relais Teams le plus proche, puis les renvoie, et indique la perte, la gigue et le temps aller-retour.

Que faire lorsque les valeurs sont élevées

Ce que mesure CallReady

CallReady vérifie la connexion dans le cadre de son contrôle avant appel, depuis la zone de notification de Windows. Il mesure la latence, la gigue et le débit approximatif en téléchargement et en envoi vers Cloudflare, puis affiche les résultats à côté de ceux de la caméra et du microphone. Il ne mesure pas la perte de paquets. Si les participants vous disent que des mots disparaissent, utilisez le test Cloudflare, pathping ou les statistiques de l’application de réunion pour le vérifier.

CallReady mesure l’itinéraire jusqu’à Cloudflare, et non le trajet des données multimédias jusqu’à un serveur Teams ou Zoom. Un bon résultat indique que votre propre connexion est stable. Pour tout ce qui concerne spécifiquement Teams ou Zoom, utilisez les statistiques de l’application lors d’un appel de test.

Questions fréquentes