La gigue (jitter), c’est la variation du moment d’arrivée des paquets de voix. Un appel VoIP découpe votre voix en petits paquets, en envoie un toutes les 20 millisecondes et s’attend à les voir arriver sur le même tempo. Quand ils arrivent en retard, en avance ou dans le désordre, cette irrégularité est la gigue, et votre interlocuteur l’entend comme des mots hachés, un son robotique ou des blancs.
Si vous exploitez un agent vocal, la gigue compte double. Elle dégrade le son de l’appelant à l’entrée, donc votre modèle de reconnaissance vocale entend un signal de moins bonne qualité, et elle dégrade le son de l’agent à la sortie, donc l’appelant conclut que votre produit est cassé. Quand un agent sonne robotique au téléphone mais bien dans le navigateur, examinez le réseau avant de toucher au modèle.
Ce guide couvre ce qu’est la gigue, ce qui la cause, comment la mesurer sur un appel réel et comment la corriger, y compris les parties du chemin qu’un développeur d’agents vocaux contrôle vraiment.
La gigue en bref
| Métrique | Confortable | Perceptible | Inutilisable |
|---|---|---|---|
| Gigue | Moins de 30 ms | 30–50 ms | Plus de 50 ms |
| Perte de paquets | Moins de 1 % | 1–3 % | Plus de 3 % |
| Latence aller simple | Moins de 150 ms | 150–400 ms | Plus de 400 ms |
Ce sont des repères, pas des garanties. Les chiffres de latence de 150 ms et 400 ms viennent de la Recommandation G.114 de l’UIT sur le délai aller simple acceptable, et le seuil de 30 ms de gigue est la consigne qu’on trouve dans la documentation des équipementiers, comme la note de Cisco sur la gigue. Un bon tampon de gigue adaptatif peut masquer plus de 30 ms de gigue, au prix d’un délai supplémentaire. L’écoute globale de ces métriques réunies est ce qu’un mean opinion score essaie de compresser en un seul chiffre.
Ce qu’est vraiment la gigue
La voix sur IP circule sur RTP, le Real-time Transport Protocol. L’expéditeur marque chaque paquet d’un numéro de séquence et d’un horodatage (RFC 3550), donc le récepteur connaît à la fois l’ordre d’envoi des paquets et l’instant exact où chaque tranche de 20 ms d’audio doit être jouée.
La gigue est l’écart entre ce planning et la réalité. Si le paquet 41 arrive 20 ms après le 40 mais que le 42 arrive 60 ms après le 41, le flux a de la gigue. La même RFC définit aussi comment les extrémités la rapportent : chaque flux RTP est accompagné de messages de contrôle RTCP, et le récepteur renvoie périodiquement un rapport de récepteur dont les champs incluent la gigue inter-arrivée mesurée. Voilà pourquoi tout système téléphonique sérieux peut vous donner sa gigue sans instrumentation supplémentaire : le protocole tient le score depuis le début.
Deux voisines méritent d’être distinguées, parce qu’elles lui ressemblent et se réparent différemment :
- Latence. C’est le retard global des paquets. Elle fait que les gens se coupent la parole sans le vouloir, mais elle ne déforme pas le son lui-même.
- Perte de paquets. Ce sont les paquets qui n’arrivent jamais (ou trop tard pour servir, ce que le récepteur compte comme perdus). La perte enlève des tranches d’audio ; la gigue les livre seulement de façon irrégulière. Une rafale de paquets désordonnés ressemble à de la perte pour le récepteur, car le décodeur ne peut pas attendre les retardataires.
Ce que la gigue donne à l’oreille
Sur un appel dont la gigue monte, tout le monde décrit la même progression. Les mots commencent à se couper sur les bords. Les voix deviennent métalliques ou robotiques quand le décodeur interpole par-dessus les trames manquantes. Puis viennent les blancs : des silences d’une demi-seconde pendant que le récepteur attend des paquets qui débarquent en paquet un instant plus tard. À l’extrême, l’appel tombe.
Chacun de ces symptômes est le tampon de gigue qui fait son travail et arrive à bout de marge. Ce qui pose la question évidente.
Le tampon de gigue, et son prix
Un tampon de gigue est une petite file côté réception. Au lieu de jouer chaque paquet dès qu’il arrive, le récepteur retient les paquets un instant et les relâche à cadence régulière, de sorte qu’un paquet qui arrive avec 30 ms de retard tient encore son créneau. Les tampons typiques retiennent 30 à 50 ms d’audio ; les adaptatifs grandissent et rétrécissent avec les conditions, parfois jusqu’à 100 ou 200 ms.
Le marché, c’est du délai contre de la fluidité. Chaque milliseconde de tampon est une milliseconde ajoutée à l’aller-retour, et passé environ 150 ms de délai ajouté, une conversation commence à ressembler à un échange au talkie-walkie : chacun attend, parle, puis attend de nouveau. Un tampon trop petit jette les paquets en retard et vous entendez des coupures. Un tampon trop grand masque la gigue et vous laisse la latence. Aucun réglage ne donne les deux, et c’est pourquoi réparer le réseau bat le réglage du tampon.
L’emplacement du tampon dépend de l’appel :
- Les appels navigateur et applicatifs (WebRTC) incluent par défaut un tampon de gigue adaptatif et un masquage des pertes, comme l’explique le guide WebRTC ou WebSocket. Vous ne le réglez presque jamais vous-même.
- Les téléphones SIP, PBX et session border controllers ont des tampons configurables, et la valeur par défaut n’est pas toujours la bonne pour votre réseau.
- Les intégrations RTP brutes font de vous l’auteur du tampon. Si vous tirez le son d’un trunk SIP vers votre propre stack, dimensionner ce tampon est votre travail.
D’où vient la gigue
La gigue est presque toujours un problème de files d’attente : des paquets qui attendent des durées différentes quelque part sur le chemin.
- Congestion. Un port de routeur ou de switch qui se remplit et se vide retient les paquets des durées imprévisibles. C’est la cause classique, et elle apparaît aux heures de pointe.
- Wi-Fi et cellulaire. Les liaisons sans fil ordonnancent le temps d’antenne et retransmettent silencieusement, donc les temps d’arrivée varient bien plus qu’en Ethernet. L’appelant sur le Wi-Fi d’un hôtel ne rêve pas.
- Absence de QoS. Sans marquage de qualité de service, les paquets vocaux font la queue derrière les téléchargements massifs. Marquer le trafic vocal (typiquement en DSCP EF) permet à vos routeurs et aux backbones de nombreux opérateurs de le prioriser, même si le marquage survit rarement à l’internet public.
- Changements de route. Quand le trafic bascule sur un autre chemin au milieu d’un appel, le nouveau chemin a un autre timing, et le flux bégaie jusqu’à ce que le tampon s’adapte.
- Tampons surdimensionnés. Le bufferbloat est le cousin discret de la gigue : une énorme file quelque part ajoute un délai permanent qui varie avec la charge, et il n’apparaît comme perte de paquets nulle part.
Comment mesurer la gigue
Pas besoin de matériel spécial ; l’appel se mesure déjà lui-même.
- Lisez les rapports de récepteur RTCP. Le champ gigue est le chiffre de référence pour ce que l’autre extrémité a vécu, exprimé dans les unités d’horodatage du flux : sur un appel G.711, on divise par 8 pour obtenir des millisecondes (la plupart des consoles font la conversion pour vous). Les PBX, SBC et consoles CPaaS l’affichent par appel.
- Capturez le flux dans Wireshark. Telephony → RTP → Stream Analysis rapporte gigue et pertes par direction et vous permet d’écouter exactement ce avec quoi le récepteur a dû travailler.
- Pour WebRTC, ouvrez chrome://webrtc-internals pendant l’appel et regardez
jitter,packetsLostetjitterBufferDelayen direct. - En sonde rapide, piquez l’extrémité distante. Un grand écart entre les temps aller-retour moyen et maximal suggère de la gigue sur le chemin. C’est une estimation, pas la métrique, car la gigue RTP se mesure dans les unités d’horodatage du flux audio lui-même.
Mesurez pendant de vrais appels à votre heure la plus chargée. Mesurer un dimanche calme un problème de mardi congestionné vous dira que tout va bien.
Comment la corriger
Travaillez du segment que vous contrôlez vers l’extérieur :
- Priorisez la voix sur votre propre réseau. Marquez le RTP en DSCP EF et assurez-vous que vos routeurs l’honorent. Passez le trafic d’appels sur des connexions filaires avant de toucher quoi que ce soit d’autre.
- Dimensionnez le tampon de gigue délibérément. Commencez autour de 30 à 50 ms sur les appareils qui le permettent, et préférez les tampons adaptatifs quand ils existent.
- Choisissez des codecs qui tolèrent la perte. Sur les segments où vous choisissez le codec, Opus embarque une correction d’erreurs directe (RFC 6716). Sur le réseau téléphonique public, vous aurez G.711, qui n’a pas cette protection et repose entièrement sur le tampon.
- Raccourcissez le chemin. Choisissez des fournisseurs avec des points de présence près de vos appelants. Chaque segment réseau en plus est une file de plus qui peut se remplir.
- Acceptez le dernier kilomètre. Vous ne réparerez pas le Wi-Fi du café où se trouve l’appelant. Ce que vous pouvez faire, c’est le mesurer, pour arrêter de déboguer votre propre stack à cause de son routeur.
La gigue et les agents vocaux
Un appel d’agent a plus de maillons qu’un appel entre personnes : le téléphone de l’appelant, son opérateur, votre fournisseur de téléphonie ou trunk SIP, puis votre stack d’agent, et retour. La gigue peut entrer à chaque étape, et elle s’ajoute à la latence du modèle dans l’expérience de l’appelant. Personne n’entend « le réseau a ajouté 120 ms de tampon puis le modèle a pris 90 ms ». On entend un seul agent, lent et haché.
Deux habitudes gardent le réseau honnête :
- Mesurez par segment. Lisez les statistiques RTCP de votre fournisseur de téléphonie et chronométrez séparément les étapes de reconnaissance et de synthèse vocale. Cartesia publie une latence de modèle sous 90 ms pour Sonic ; c’est le modèle, et le segment réseau ajoute son propre délai par-dessus, exactement le délai que la mesure P95 et P99 existe pour attraper. Si le modèle est rapide et que l’appel reste lent ou brouillé, vous regardez de la gigue.
- Testez par le vrai chemin téléphonique. Le son téléphonique tourne à 8 kHz en G.711 loi μ ou loi A, à travers le tampon de gigue de quelqu’un d’autre. Un agent qui sonne propre sur votre portable peut sonner cassé sur une route d’opérateur congestionnée, donc passez des appels de test depuis de vrais numéros, aux heures chargées, avant d’accuser le modèle vocal.
Côté Cartesia, Sonic renvoie directement de la loi μ ou A brute à 8 kHz ("encoding": "pcm_mulaw", "sample_rate": 8000), donc le son téléphonique n’a pas de conversion supplémentaire, et Ink accepte les mêmes formats pour la reconnaissance vocale en streaming. Managed Agents répond aux appels sur des numéros Cartesia, Twilio ou votre propre trunk SIP et gère le segment téléphonique pour vous. Les appels d’agent coûtent 0,03 $ la minute, et le supplément téléphonie de 0,014 $ la minute ne s’applique qu’aux numéros fournis par Cartesia. Les régions de déploiement — États-Unis, UE, Royaume-Uni, Inde et Australie — gardent le chemin réseau court. Les trunks SIP se connectent en TLS avec des médias SRTP, et le guide des trunks SIP couvre la configuration.
Et si votre gigue s’avère bonne et que l’agent sonne toujours robotique, alors oui, vous avez notre permission d’accuser le modèle.