Résumé

  • Le numéro de séquence RTP suit l’ordre d’émission des paquets ; l’horodatage situe le média sur une horloge d’échantillonnage propre au format. Aucun des deux ne certifie à lui seul l’heure absolue d’envoi.
  • Pour accorder plusieurs flux, un rapport émetteur RTCP associe ponctuellement un compteur RTP à une valeur de référence au format NTP. La preuve est dans cette correspondance, pas dans la ressemblance des nombres.

Le mot « horodatage » invite à poser une question trop large : à quelle heure ce paquet a-t-il été envoyé ? RFC 3550 répond à une autre question. Son champ de 32 bits indique l’instant d’échantillonnage du premier octet de média contenu dans le paquet. Il décrit une position dans une continuité audio ou vidéo, non le passage du datagramme à travers la machine.

Cette nuance vient du Real-time Transport Protocol signé par Henning Schulzrinne, Stephen Casner, Ron Frederick et Van Jacobson. RFC 1889 en a publié la première spécification normalisée en 1996 ; RFC 3550 l’a remplacée en 2003. L’Information Sciences Institute attribue à Casner un rôle directeur dans le développement et la normalisation de RTP. Ce rôle justifie le portrait, sans effacer l’écriture collective du protocole.

Deux axes qui ne progressent pas de la même manière

Le numéro de séquence, sur 16 bits, augmente d’une unité pour chaque paquet de données RTP envoyé. Le récepteur peut repérer une lacune ou remettre les paquets dans leur ordre d’émission. Sa valeur initiale est aléatoire : même ce compteur n’est pas un numéro de dossier commençant à un.

L’horodatage, sur 32 bits, suit l’horloge du média. Sa fréquence dépend du format transporté. Pour un son à cadence fixe, un bloc couvrant 160 périodes d’échantillonnage fait avancer le compteur de 160. Il l’avance aussi si le bloc silencieux n’est finalement pas envoyé. La timeline sonore continue pendant que le réseau ne reçoit rien.

La vidéo révèle une autre conséquence. Une image peut être découpée en plusieurs paquets. Leurs numéros de séquence sont différents, car ils sont émis l’un après l’autre, mais leurs horodatages peuvent être identiques, car ils appartiennent au même instant vidéo. À l’inverse, certains codages transmettent des images dans un ordre différent de celui de leur échantillonnage. Les numéros de séquence restent croissants alors que les horodatages consécutifs peuvent ne pas l’être.

Une sonde qui confond ces axes inventera des incidents. Elle appellera « doublon » un horodatage partagé par les fragments d’une image. Elle appellera « réordonnancement réseau » une différence créée par l’ordre du codec. Le protocole n’a pas produit cette conclusion ; le logiciel d’observation a supprimé le contexte qui l’aurait empêchée.

Le compteur démarre lui aussi sur une valeur aléatoire. Pour transformer sa différence en durée, il faut connaître sa fréquence. Pour savoir à quelle source il appartient, il faut conserver le SSRC. Pour le raccorder à une heure commune, il faut encore une preuve distincte.

Une piste audio ne partage pas naturellement l’horloge de l’image

Le son et l’image d’une même scène peuvent être captés au même moment tout en portant des compteurs RTP sans rapport numérique. Les fréquences diffèrent, tout comme leurs décalages initiaux aléatoires. RFC 3550 avertit qu’une comparaison directe des horodatages de médias différents ne permet pas de les synchroniser.

Cette limitation est utile. Le paquet de données conserve une horloge adaptée au média, assez précise pour ordonner la présentation et calculer la gigue par rapport au rythme d’échantillonnage. Il n’est pas obligé d’embarquer partout une date absolue, ni de dépendre d’une horloge civile dont certaines applications n’ont pas besoin.

Le raccord passe par RTCP. De temps à autre, un rapport émetteur place côte à côte une valeur au format NTP et la valeur RTP correspondant au même instant. Le couple décrit la relation entre le compteur local et le temps de référence. Le récepteur peut alors projeter chaque flux vers la même horloge et aligner l’audio avec la vidéo.

Ce couple n’accompagne pas chaque paquet. Il circule à un débit inférieur dans les rapports RTCP, puis le récepteur utilise la fréquence connue pour prolonger la relation. La valeur RTP du rapport n’est généralement pas égale à celle d’un paquet voisin : elle est calculée pour l’instant exact que représente la valeur NTP. Exiger une égalité avec le paquet précédent ou suivant reviendrait à rejeter une correspondance correcte.

La forme NTP ne garantit pas non plus l’UTC. RFC 3550 autorise une machine dépourvue d’heure absolue à utiliser une horloge relative commune au système, par exemple son temps de fonctionnement. Si elle ne connaît ni heure civile ni temps écoulé, elle peut inscrire zéro. Le format indique comment exprimer la référence ; il ne certifie ni sa source ni sa précision.

RFC 7273 a par la suite décrit explicitement ce couple RTP/NTP comme une correspondance et rappelé que l’alignement de plusieurs sources dépend toujours de références elles-mêmes synchronisées. Le rapport RTCP est donc un reçu de corrélation, pas une machine à rendre juste une horloge défaillante.

Des paquets de voix à une grammaire du temps

Casner avait rencontré le problème avant que la vidéo sur Internet devienne banale. L’ISI retrace son travail sur la voix en paquets dans l’ARPANET : comprimer un signal continu, le découper pour un réseau étroit, puis le reconstruire à l’arrivée. Il a ensuite travaillé sur la vidéo en paquets, participé au MBONE et conduit la normalisation de RTP. Le rapport annuel de l’institut relie ce protocole au Network Voice Protocol et au Packet Video Protocol développés à l’ISI.

Ce passé éclaire l’économie de la norme. RTP n’offre ni réservation de ressources ni garantie de qualité de service. Il transporte juste assez d’indices pour que l’application retrouve la chronologie du média et observe la livraison. Les délais, pertes et réordonnancements restent possibles ; le protocole évite de les confondre avec la structure propre du contenu.

La révision de 2003 a conservé les formats sur le fil. RFC 3550 présente comme changement principal un meilleur calcul du moment où envoyer les rapports RTCP lorsqu’un grand nombre de participants rejoignent une session. Les champs du chemin de données sont restés stables ; la cadence de la preuve de contrôle a été renforcée pour passer à l’échelle.

Conserver le domaine de l’horloge avec la mesure

Archiver seulement l’horodatage RTP revient à jeter une partie du fait. Une capture exploitable conserve aussi le SSRC, le type de charge, la fréquence d’horloge, le numéro de séquence, l’heure locale d’observation et les couples RTP/NTP valides les plus proches. Si la référence est relative ou nulle, cela appartient également au reçu.

Cette matière permet des diagnostics distincts. Une lacune de séquence signale une perte possible. Une rupture du compteur média peut accompagner un redémarrage de source ou un changement de cadence. Un rapport émetteur trop ancien élargit l’incertitude de conversion. Une dérive après projection sur la référence commune peut enfin révéler un problème d’alignement.

Sans ces éléments, l’outil fabrique sa propre certitude. Il divise tous les compteurs par une fréquence supposée, trie la vidéo par une valeur qui n’est pas l’ordre d’envoi, compare deux flux à décalages aléatoires ou imprime une valeur au format NTP comme une date garantie.

La leçon de Casner n’est pas qu’il faut ajouter davantage d’horloges aux paquets. Elle est plus rigoureuse : garder chaque champ dans son domaine, puis conserver le pont qui autorise le passage d’un domaine à l’autre.

Sources