Résumé

  • RFC 3158 liait la transformation des médias RTP à celle des preuves RTCP. Changer l’encodage, le découpage en paquets, les numéros de séquence ou la fréquence d’horodatage imposait de corriger les compteurs et rapports correspondants.
  • Un rapport de réception revenait à contre-courant dans l’espace de séquence créé par le traducteur. Si aucune conversion inverse n’avait de sens, supprimer le rapport ou produire un rapport local explicitement synthétique valait mieux que transmettre des chiffres exacts sur le mauvais flux.
  • La méthode de test limitait elle-même sa portée : elle révélait des erreurs communes et une interopérabilité bornée, sans certifier toute la conformité RTP, la sécurité, la qualité en production ou l’expérience humaine.

Une image correcte pouvait voyager avec un compte rendu faux

Prenons deux paquets envoyés sur un réseau rapide. Un traducteur les réencode et les réunit pour franchir une liaison plus étroite. Le récepteur décode l’unique paquet de sortie et affiche l’image. Vu depuis l’écran, l’opération a réussi.

Le rapport RTCP du récepteur appartient pourtant à un autre espace de séquence. Il a observé un paquet là où l’émetteur en avait produit deux. Si l’intermédiaire renvoie ce rapport sans transformation, la source reçoit un document bien formé qui décrit une chronologie qu’elle n’a jamais émise. Une perte après fusion ne correspond plus mécaniquement à une perte avant fusion.

Rien ne doit être corrompu pour que l’erreur existe. Le média peut être lisible, le SSRC peut rester stable, le rapport peut respecter sa syntaxe et son intégrité cryptographique. Ce qui manque est le lien sémantique entre le nombre et les paquets qu’il prétend compter.

RFC 3158 ne testait donc pas seulement la lecture du flux traduit. Il demandait si les modifications du type de charge, de l’horodatage, du numéro de séquence, du remplissage et du marqueur entraînaient les modifications correspondantes dans RTCP. Le canal de contrôle était une preuve compacte du flux, pas un décor.

L’instrument de test créait un point d’observation indépendant

Le dispositif proposé plaçait un relais applicatif entre deux implémentations RTP. Chacune envoyait ses paquets à l’instrument, qui les retransmettait vers l’autre. Il pouvait laisser passer, retarder, supprimer et consigner le contenu.

Cette position permettait de comparer trois traces : ce que le premier terminal disait avoir envoyé, ce que le second recevait et ce que l’instrument avait volontairement fait au milieu. Une suppression aléatoire d’environ un pour cent devait apparaître dans la fraction et le cumul des pertes. Une fois la perte retirée, un délai variable devait augmenter la gigue interarrivée rapportée.

Le protocole de laboratoire ne devenait pas pour autant un témoin universel. Il voyait une construction précise, sur un chemin contrôlé, avec des cas choisis. Dès son introduction, RFC 3158 précisait que sa série n’était pas exhaustive et qu’un succès ne démontrait pas nécessairement la conformité complète à RTP.

Un résultat positif prouvait donc une chose délimitée : deux versions identifiées s’étaient comportées comme attendu face aux scénarios exécutés. Il ne disait rien, sans preuve supplémentaire, des formats non essayés, des entrées malformées, des autres topologies, de la charge réelle ou du résultat pour l’utilisateur.

RTP transportait les données ; RTCP racontait leur observation

Un Sender Report associait un SSRC à une heure NTP, à un horodatage RTP ainsi qu’à des comptes de paquets et d’octets. Un Receiver Report nommait la source observée et conservait pertes, numéro de séquence étendu, gigue, dernier rapport émetteur et délai écoulé depuis celui-ci.

Ces champs n’avaient de sens qu’avec leur population de paquets et leur point d’observation. RFC 3158 vérifiait ainsi la cohérence : même SSRC entre données et rapport, temps RTP compatible avec la ligne temporelle du média, compteurs compatibles avec les envois, perte compatible avec la dégradation introduite.

La simple réception d’un rapport ne suffisait pas. Sa ponctualité, sa validité syntaxique et sa signature éventuelle n’établissaient pas qu’il décrivait le bon flux. Cette limite devient importante lorsque l’exploitation préfère les métriques compactes aux captures volumineuses. Une projection facile à agréger peut être moins fidèle que les événements qu’elle résume.

Conserver le SSRC ne conservait pas l’espace de mesure

Le traducteur et le mélangeur avaient des rôles différents. Le premier gardait les sources séparées et transmettait leur SSRC. Le second réunissait les flux, créait sa propre synchronisation et utilisait son propre SSRC, avec éventuellement les contributeurs en CSRC.

Le SSRC stable d’un traducteur permettait de suivre la source à travers l’intermédiaire. Il n’immobilisait pas le reste. Un réencodage pouvait changer le type de charge et le volume d’octets. Un nouveau rythme d’échantillonnage changeait la progression des horodatages. Une fusion ou une division de paquets créait une nouvelle suite de numéros. Le remplissage, le marqueur et le chiffrement pouvaient aussi évoluer.

La continuité de source n’était donc pas la continuité des mesures. Sous un même identifiant vivaient potentiellement deux histoires de paquets. Si RTCP restait attaché à la première alors que le récepteur voyait la seconde, l’identifiant familier masquait précisément la rupture que l’exploitation devait connaître.

Chaque transformation imposait son écriture comptable

RFC 3158 reliait des modifications concrètes. Un changement d’encodage appelait une correction du compte d’octets dans le Sender Report. Réunir plusieurs paquets imposait de corriger le compte de paquets. Modifier la fréquence d’échantillonnage exigeait de transformer l’horodatage RTP du rapport.

Un flux compressé transportant moins d’octets ne devait pas continuer à annoncer le débit de l’entrée. Trois paquets devenus un ne devaient pas conserver un compteur donnant l’illusion de trois transmissions sur la liaison de sortie. Sans cette réécriture, les outils pouvaient produire des taux cohérents mathématiquement et faux physiquement.

Le chemin inverse était plus exigeant. Le récepteur observait la séquence de sortie. Son rapport sur les pertes et le plus grand numéro reçu devait être ramené, si possible, vers l’histoire d’entrée. Cette opération exigeait la correspondance entre les paquets, pas une simple addition constante.

Perdre un paquet fusionné peut englober plusieurs contributions d’entrée. Perdre un fragment après division peut ne supprimer qu’une partie d’un paquet original. Le mot « paquet perdu » change de dénominateur en franchissant l’intermédiaire.

Le rapport remontait une transformation qui n’était pas toujours réversible

Le média avançait de l’émetteur vers le récepteur. Le Receiver Report revenait dans l’autre sens. Le traducteur devait donc inverser, pour la preuve, une opération conçue d’abord pour produire un nouveau flux.

Une fusion plusieurs-vers-un efface des distinctions. Après la perte du paquet de sortie, le récepteur ne peut pas savoir quelles unités d’entrée auraient été perdues si elles étaient restées séparées. Le réencodage peut également déplacer les limites d’image et de paquet de manière non bijective.

RFC 3550, qui remplaça la spécification RTP d’origine, transforma ce principe en obligation normative : un traducteur qui modifie la charge doit modifier SR et RR et ne doit pas se contenter de les transférer. Il reconnaissait en même temps la complexité de la conversion inverse.

La capacité de fabriquer une sortie correcte ne conférait donc pas automatiquement la capacité d’expliquer tout le trajet à rebours. Le pouvoir de transformation et le pouvoir de témoignage étaient liés mais non identiques.

L’absence déclarée valait mieux qu’une fausse précision

RFC 3158 autorisait la suppression des blocs de réception, avec des SR ou RR vides, lorsque la traduction sensée était impossible. RFC 3550 distinguait ensuite l’absence de rapport et un rapport synthétique fondé sur ce que le traducteur avait lui-même reçu.

Ces deux résultats n’établissaient pas une perte nulle. L’absence disait qu’aucune projection défendable n’était disponible. Le rapport synthétique décrivait un segment et un observateur locaux. Il ne devenait pas le témoignage du récepteur final sur la séquence de la source.

Préserver un champ à tout prix aurait offert une complétude numérique trompeuse. La lacune explicite conservait au contraire la portée des autres preuves. La discrétion laissée au traducteur concernait la méthode adaptée à sa transformation, pas le droit d’inventer une précision.

Répliquer, traduire et mélanger réclamaient trois lectures

Un relais qui reproduisait les données sans les modifier pouvait aussi transmettre RTCP sans modification. Le devoir naissait de la transformation effective, pas de la seule présence d’un intermédiaire.

Le traducteur de charge conservait les sources mais devait aligner les rapports sur sa nouvelle représentation. S’il émettait des rapports sur ce qu’il recevait lui-même, ceux-ci appartenaient à son point d’observation.

Le mélangeur créait une nouvelle source de synchronisation. Il ne pouvait pas transférer vers un autre nuage les rapports comme si les sources d’origine y restaient des SSRC. Confondre ces rôles sous le mot « relais » effaçait l’autorité de mesure propre à chacun.

Même l’agrégation de rapports pouvait changer leur sens. RFC 3550 la déconseillait généralement pour plusieurs sources parce que LSR et DLSR participaient à la mesure du délai. Garder les champs en modifiant leur calendrier pouvait altérer le résultat sans toucher un seul nombre.

L’intégrité protégeait l’énoncé, pas son bon périmètre

SRTP et SRTCP ajoutèrent ensuite confidentialité, intégrité et protection contre le rejeu. Ils permettaient d’identifier une altération extérieure au contexte de sécurité. Ils ne validaient pas la règle avec laquelle un traducteur avait converti les compteurs.

Un rapport authentique pouvait être synthétique. Un rapport intact pouvait décrire la réception du traducteur et non celle du destinataire. Une signature correcte ne transformait pas des comptes d’entrée en comptes de sortie.

La vérification cryptographique restait donc un reçu distinct. Elle protégeait l’auteur et les octets de la déclaration. Il fallait encore demander quelle observation cet auteur pouvait réellement faire et quelle population la métrique couvrait.

Le document de test devait lui aussi être testé

RFC 3158 couvrait beaucoup de cas, mais refusa d’en faire une certification absolue. Sa section sur l’aléa des SSRC illustre cette prudence et une autre nécessité. Elle annonçait 2 500 échantillons répartis en 25 classes, puis une espérance de 40 par classe. La division directe donne 100. La recherche d’errata RFC Editor figée pour ce travail n’en retourne aucun.

Ce constat n’est pas un erratum officiel et ne condamne pas RTP. Il montre qu’une méthode publiée doit conserver ses paramètres exacts et faire vérifier ses calculs. Le numéro RFC ne remplace pas la reproductibilité.

RFC 2762 expliquait pourquoi une distribution uniforme intéressait l’échantillonnage de groupe ; RFC 3158 qualifiait d’ailleurs son propre contrôle d’approximatif. Une réussite à ce contrôle ne prouvait pas 32 bits d’aléa parfait, comme une réussite aux scénarios de traduction ne prouvait pas toute la conformité.

Davantage de métriques n’abolissait pas la provenance

Les Extended Reports de RFC 3611 enrichirent les observations. RFC 7667 décrivit davantage de topologies et d’intermédiaires. RFC 3551 rappelait que type de charge, fréquence d’horloge et marqueur dépendaient du profil et du format.

Ces ajouts amélioraient le vocabulaire, non l’ubiquité de l’observateur. Toute métrique gardait un auteur, un intervalle, une population, un espace de séquence et un emplacement. Une valeur post-traduction ne devenait pas pré-traduction parce qu’un format plus récent savait la transporter.

L’archive durable devait donc joindre capture d’entrée, règle et version du traducteur, correspondance entre paquets, capture de sortie, réécriture SR, conversion inverse RR ou motif d’absence, origine d’un éventuel rapport synthétique, puis preuve de décodage et résultat applicatif. Ni la lecture du média ni la correction des compteurs ne remplaçait l’autre.

La leçon historique de RFC 3158 tient en une discipline : lorsqu’un intermédiaire détruit le sens ancien d’un nombre, il doit aussi abandonner l’apparence que ce nombre n’a pas changé. Le rapport doit suivre le paquet, ou dire honnêtement jusqu’où il ne peut plus le suivre.

Sources