Résumé

  • Dans RFC 5215, le champ Ident de 24 bits relie chaque charge Vorbis à une Configuration de décodage. Il nomme l'état requis, mais n'atteste ni sa réception ni son installation chez le client.
  • Si l'Ident change et que cette Configuration manque, le client ne doit pas décoder les données brutes associées. La livraison RTP et la disponibilité du son sont donc deux résultats distincts, qui exigent deux chaînes de preuve.

Le jour où le zéro perte n'a produit aucun son

Le rapport d'exploitation semblait irréprochable. Les numéros de séquence se suivaient, le débit restait stable et les paquets audio postérieurs au changement de programme avaient tous atteint le lecteur. On pouvait conclure à une livraison réussie—à condition de confondre transport et interprétation.

Au même instant, l'Ident inscrit dans les charges Vorbis avait changé. La petite valeur de 24 bits indiquait que les paquets suivants dépendaient d'une nouvelle Configuration. Or l'un des fragments de cette Configuration n'était jamais parvenu au lecteur. Les paquets audio formaient une file complète devant un décodeur auquel il manquait la grammaire du flux.

La bonne réaction n'était pas d'essayer au hasard. RFC 5215 impose au client qui ne dispose pas de la Configuration correspondante de ne pas décoder les données brutes. Le silence était donc la preuve d'un contrôle correctement appliqué, pas celle d'une absence de trafic.

Le nom d'une configuration n'est pas la configuration

Vorbis ne part pas d'un modèle probabiliste statique partagé par tous les flux. Les modèles de Huffman, la quantification vectorielle et les paramètres du décodage entropique sont regroupés dans un bloc propre au contenu. Le décodeur doit aussi connaître des caractéristiques telles que le nombre de canaux. Les en-têtes Identification et Setup sont ainsi nécessaires avant que la première trame audio puisse être interprétée.

Le champ Ident permet de ne pas répéter ce bloc volumineux dans chaque paquet. Il sert d'index : les données brutes portent une valeur et le récepteur recherche la Configuration associée dans son état de session. Ce mécanisme est efficace tant que l'association existe des deux côtés.

Une mesure de l'Ident n'établit pourtant que le choix de l'émetteur. Elle ne prouve pas que le récepteur a reçu tous les fragments, reconstitué le paquet de configuration, validé les en-têtes ou installé les mêmes octets. Un tableau de bord peut afficher un Ident, un type de charge et une cadence parfaitement cohérents tout en ignorant l'absence décisive dans la mémoire du décodeur.

Cette limite rejoint une règle plus large de l'exploitation : une référence visible n'acquiert pas les propriétés de l'objet qu'elle désigne. Un identifiant n'est ni une livraison ni une exécution.

Les indices SDP ne remplacent pas l'état du décodeur

La description de session annonce le sous-type Vorbis, une cadence d'horloge et un nombre de canaux dans rtpmap. RFC 5215 qualifie ces informations d'indices. L'information exacte provient de la Configuration, dont le paramètre est obligatoire dans fmtp. Pour un flux non chaîné, la norme recommande de placer la Configuration compactée dans le SDP initial.

Le paquet compacté conserve les en-têtes Identification et Setup. L'en-tête Comment peut être factice : les métadonnées de titre ou d'artiste ne commandent pas le décodage des trames. Cette hiérarchie est utile pour l'audit. La partie la plus lisible par un humain peut être facultative, alors que le modèle mathématique, presque invisible dans l'interface, est indispensable.

Un flux peut changer de configuration en cours de session. Le nouvel état peut être livré dans le canal RTP, dans une nouvelle description de session ou par un chemin hors bande. Les mises à jour dans la bande doivent être prises en charge; le secours hors bande devrait l'être. L'horodatage RTP de la Configuration indique la première donnée à laquelle elle s'applique.

Cet horodatage fixe une frontière. Il ne confirme pas que le lecteur l'a franchie avec le bon état.

Une panne minuscule gouverne un long flux

Les configurations peuvent être beaucoup plus grosses qu'une trame audio ordinaire. Elles peuvent donc être fragmentées et retransmises périodiquement. Perdre une trame brute enlève un morceau de signal. Perdre un seul fragment de Configuration peut rendre indécodables toutes les données qui en dépendent.

Le bilan par volume devient trompeur. Des milliers de petits paquets correctement livrés écrasent statistiquement l'unique objet qui donne leur sens. Un indicateur de disponibilité pondéré par les paquets peut afficher presque 100 % tandis que le service audible reste à zéro.

Le récepteur dispose de plusieurs réponses : demander à nouveau la Configuration, récupérer une copie hors bande, attendre une retransmission, mettre en mémoire les données brutes, réinitialiser ou terminer la session. Chaque option crée son propre risque. Une récupération tardive peut rendre les paquets décodables mais inutiles pour une lecture en temps réel. Une mémoire tampon peut préserver le contenu tout en dépassant la latence promise. Une réinitialisation peut rétablir le service en effaçant la cause.

Le reçu d'autorité de décodage

Il faut donc conserver plus qu'une trace RTP. Un reçu opérationnel devrait relier la génération de l'offre et de la réponse, le type de charge, l'empreinte exacte de la Configuration, l'Ident, le premier horodatage concerné et les hachages des en-têtes Identification et Setup.

Il devrait ensuite montrer le chemin de livraison, l'assemblage complet des fragments, le résultat de l'analyse syntaxique, l'heure d'installation et la table Ident-vers-empreinte effectivement utilisée. Pendant l'absence, il faut savoir quels paquets ont été mis en attente ou supprimés. La première trame décodée, les échantillons confiés à la lecture et la sortie observée ferment la chaîne.

Ce reçu est une proposition éditoriale de BTW, pas une extension de RFC 5215. Son intérêt est de borner les affirmations. RTP témoigne du transport. SDP témoigne de ce qui a été proposé. L'Ident témoigne de ce qui a été sélectionné. Le décodeur seul témoigne de l'état qu'il a réellement consommé.

La doctrine du running code formulée par Heng Lu fournit ici un test précis : la visibilité d'une déclaration ne lui donne pas autorité sur l'exécution. Une configuration annoncée n'agit qu'une fois reçue et installée par le composant qui en dépend. Aucun consensus entre les graphiques réseau ne peut fabriquer les codebooks absents.

La question de direction n'est donc plus « avons-nous livré les paquets ? », mais « pouvons-nous prouver que le récepteur détenait, à temps, le droit technique de les interpréter ? »

Sources

  1. RFC 5215
  2. IETF Datatracker — RFC 5215
  3. Fiche RFC 5215
  4. Historique RFC 5215
  5. RFC 3550 — RTP
  6. RFC 4566 — SDP
  7. RFC 3264 — offre/réponse
  8. RFC 4588 — retransmission RTP
  9. RFC 3611 — RTCP XR
  10. RFC 3533 — encapsulation Ogg
  11. RFC 4648 — codages Base
  12. RFC 3986 — URI
  13. RFC 3551 — profil RTP
  14. RFC 1191 — découverte du MTU
  15. RFC 1981 — MTU en IPv6
  16. Spécification Vorbis I
  17. RFC 8088 — coupe-circuits RTP
  18. RFC 8866 — SDP
  19. Heng Lu — primauté du running code