Comment un appel voyage sur internet en petits paquets

C'est la durée habituelle fixée par l'IETF, l'organisme qui rédige les normes d'internet. Un paquet plus long consacrerait une plus petite part de lui-même aux étiquettes, mais chacun ajouterait du délai, et un paquet perdu laisserait un trou plus long dans ce que votre ami entend.

Un appel standard mesure votre voix 8 000 fois par seconde et range chaque mesure dans un octet. Vingt millisecondes de son remplissent donc 160 octets.

Sources: IETF RFC 3551: the audio and video profile for RTP (2003); ITU-T G.711: pulse code modulation of voice frequencies (1988)

Parce qu'internet ne promet pas de livrer les paquets dans l'ordre, ni même de les livrer. Le protocole internet, rédigé en 1981, le dit sans détour : il n'y a ni accusé de réception ni retransmission, et rien ne garantit l'ordre des paquets.

Les règles d'envoi de la voix ajoutent donc un numéro qui augmente d'une unité à chaque paquet. L'autre bout s'en sert pour repérer un paquet manquant et remettre les autres dans l'ordre.

Sources: IETF RFC 791: Internet Protocol (1981); IETF RFC 3550: RTP, a transport protocol for real-time applications (2003)

Ils le peuvent. Chaque routeur décide pour chaque paquet séparément, comme Paul Baran l'a décrit à la RAND dans les années 1960 : il stocke le paquet, calcule la meilleure route vers sa destination et l'envoie à l'étape suivante sur cette route.

En pratique, la plupart des paquets d'un appel suivent la même route, parce que les routeurs qui ont le choix entre plusieurs routes gardent chaque conversation sur l'une d'elles. L'ordre se dérègle quand même de temps en temps, quand une route change ou qu'un routeur chargé retient certains paquets. L'IETF le formule ainsi : internet perd et réordonne parfois des paquets, et les retarde de durées variables.

Sources: RAND: Paul Baran and the origins of the internet (2018); IETF RFC 2992: analysis of an equal-cost multi-path algorithm (2000); IETF RFC 3550: RTP, a transport protocol for real-time applications (2003)

Il a établi l'appel. Votre ordinateur lui a demandé d'appeler votre ami, le standard a trouvé le téléphone de votre ami et l'a fait sonner, et les deux bouts se sont mis d'accord sur la façon d'envoyer la voix. Ces messages suivent SIP, le Session Initiation Protocol, que l'IETF a publié en 2002.

L'établissement de l'appel tient en une poignée de messages. La voix voyage ensuite dans les paquets que vous suivez.

Sources: IETF RFC 3261: SIP, the Session Initiation Protocol (2002)

Pas longtemps. Chaque millième de seconde passé sur le plateau s'ajoute au délai entre votre bouche et l'oreille de votre ami, et les ingénieurs télécoms visent à garder ce délai total sous 150 ms. Une attente plus longue rattraperait plus de paquets en retard, mais l'appel paraîtrait lent et vous vous couperiez la parole.

Les ingénieurs appellent cette salle d'attente une mémoire tampon de gigue (jitter buffer, en anglais). La gigue, c'est l'arrivée des paquets à intervalles irréguliers, et les règles de la voix sur IP indiquent à chaque bout comment la mesurer.

Sources: ITU-T G.114: one-way transmission time (2003); IETF RFC 3550: RTP, a transport protocol for real-time applications (2003)

Il invente un court morceau de son à partir de la voix qui précède. Cette technique s'appelle le masquage des pertes de paquets, et l'Union internationale des télécommunications, l'agence des Nations unies pour les télécoms, a publié en 1999 une façon de le faire pour les appels standard.

Les paquets courts aident aussi. L'IETF note que des paquets plus longs rendent une perte plus audible, et c'est l'une des raisons pour lesquelles les appels envoient 20 ms à la fois.

Sources: ITU-T G.711 Appendix I: packet loss concealment with G.711 (1999); IETF RFC 3551: the audio and video profile for RTP (2003)