Résumé

  • RFC 5285, remplacée par RFC 8285, distingue le numéro local placé dans chaque paquet de l’URI qui définit réellement l’extension ; extmap réalise l’association dans le contexte SDP.
  • Une preuve exploitable doit conserver le paquet, l’époque de négociation, la portée média ou BUNDLE et le décodeur utilisé. La réception, l’interprétation, l’action et le résultat sont des constats différents.

Le premier symptôme n’était pas une perte de paquets. C’était une courbe trop propre. Le système d’analyse avait classé toutes les extensions portant le numéro 3 comme des niveaux audio, même lorsqu’un nouvel appel avait négocié ce numéro pour un décalage temporel. Les paquets archivés étaient fidèles. La légende ne l’était pas.

Cette panne est presque une illustration pédagogique de RFC 5285. Pour éviter de répéter un nom long dans chaque paquet RTP, la norme met un petit identifiant à côté de chaque élément d’extension. Ce nombre ne nomme pas l’extension à l’échelle mondiale. Il sert d’index local vers une URI absolue, déclarée par exemple en SDP sous la forme a=extmap:<valeur> <URI>.

RFC 8285 a remplacé le texte de 2008 en 2017. Elle a notamment assoupli l’usage des formats d’en-tête à un et deux octets. Elle n’a pas transformé l’identifiant compact en code universel. Le sens demeure attaché à l’association négociée.

L’IANA enregistre l’URI, pas le chiffre du paquet

Le registre IANA des extensions compactes RTP contient des URI stables : décalage de transmission, horodatage de synchronisation, niveaux audio, identifiants SDES, marquage de trame. Ces noms peuvent être documentés, examinés et réutilisés. Le numéro court utilisé pendant un appel est une autre couche.

Dans le format à un octet, quatre bits identifient l’élément et les valeurs utiles vont de 1 à 14. Le format à deux octets offre un espace plus grand. Ce sont des ressources rares à l’intérieur d’une session, pas un plan mondial de numérotation. Il est donc normal que deux sessions donnent au même numéro des significations différentes.

Un outil qui applique un dictionnaire global crée une collision là où le protocole avait précisément organisé la réutilisation. Le bon enregistrement ne dit pas seulement « ID 3 ». Il conserve l’URI correspondante, les attributs de l’extension, la direction, la section média concernée et la version de l’offre et de la réponse qui était en vigueur lorsque le paquet a été observé.

Si cette association manque, l’extension n’est pas fausse. Son statut est « sens non résolu ». Elle peut encore prouver qu’un octet est arrivé à une heure donnée, avec un SSRC et un numéro de séquence déterminés. Elle ne permet pas d’inventer ce que l’émetteur voulait dire.

Reconnaître la grammaire ne suffit pas à connaître le vocabulaire

Le champ de profil de l’extension RTP indique si le paquet emploie la forme à un octet ou à deux octets. Un analyseur peut donc parcourir correctement les éléments, lire leur longueur et isoler leur valeur. Ce succès prouve la conformité de la forme.

Il ne prouve pas que le numéro a été rattaché à la bonne URI. RFC 8285 dit que les identifiants locaux doivent avoir été négociés ou définis hors bande et qu’il n’existe pas d’attribution statique de ces numéros. La syntaxe et la sémantique ont des autorités différentes.

Le passage de RFC 5285 à RFC 8285 rend cette distinction encore plus visible. Le texte initial interdisait de mélanger les formes à un et deux octets dans un même flux. Le nouveau texte permet leur alternance lorsque tous les destinataires la prennent en charge, généralement après négociation de extmap-allow-mixed. Chaque paquet reste dans une seule forme. L’autorisation porte sur le comportement du flux dans le temps.

Il faut donc deux preuves : celle du format effectivement reçu et celle de la capacité convenue. Une trace montrant un paquet à deux octets ne démontre pas que l’autre extrémité l’avait accepté. Une offre contenant extmap-allow-mixed ne démontre pas que la réponse l’a retenu ni qu’un paquet de ce type a été envoyé.

Une négociation produit une époque, pas une vérité éternelle

Dans la portée concernée, un identifiant valide ne peut pas être attribué deux fois. Une mise à jour peut ajouter ou retirer des extensions et changer leur direction. Elle ne peut pas réaffecter un identifiant valide déjà établi à une autre extension. Cette stabilité protège les implémentations en cours d’exécution.

Elle oblige aussi les archives à dater le contexte. Un paquet reçu avant une mise à jour doit être lu avec l’ancienne époque de négociation. Copier seulement le dernier SDP dans un dossier d’incident peut réinterpréter le passé. L’erreur est silencieuse parce que la structure du paquet reste valide.

Les valeurs 4096 à 4351 constituent un autre piège. Elles peuvent servir dans une offre à présenter des alternatives ou des extensions trop nombreuses pour l’espace utilisable. Le répondant choisit et remappe une option vers un identifiant libre du domaine valide. La grande valeur de négociation n’est pas envoyée telle quelle dans le paquet. Elle exprime une possibilité, non une extension active.

Les qualifications sendonly, recvonly, sendrecv et inactive ajoutent encore une dimension. Une carte peut exister sans autoriser l’émission dans le sens observé. L’analyse doit relier présence sur le fil, permission négociée et capacité du récepteur sans les confondre.

BUNDLE transforme une erreur locale en erreur collective

BUNDLE permet à plusieurs descriptions média de partager un même transport. Pour distinguer rapidement les flux, MID peut être porté dans une extension RTP. RFC 9143 impose cette extension dans les descriptions RTP groupées.

Dans un groupe BUNDLE, RFC 8285 considère les descriptions comme partageant un espace d’identifiants locaux. Une même URI avec la même configuration doit porter le même ID dans les différentes sections du groupe. Les sections peuvent néanmoins annoncer des ensembles d’extensions différents. Le modèle n’est donc ni totalement global ni purement indépendant pour chaque ligne média.

Cette nuance affecte les répartiteurs, les enregistreurs et les fonctions de surveillance. Une carte aplatie pour toute la machine peut faire déborder une signification d’un groupe vers un autre. Une carte strictement séparée par section peut ignorer la cohérence exigée à l’intérieur d’un groupe. Il faut stocker la topologie de négociation, pas seulement une table clé-valeur.

RID montre que les portées peuvent s’emboîter. RFC 8852 précise que RtpStreamId est délimité par la source et la session média, puis par MID quand BUNDLE intervient. Le petit ID de l’extension choisit d’abord une URI ; la valeur RID choisit ensuite un flux dans un autre espace. Réduire les deux à une colonne « identifiant » est une perte de modèle, pas une simplification.

Chiffrement et observabilité changent la nature du reçu

RFC 6904 a proposé le chiffrement sélectif de certaines valeurs d’extension. RFC 9335 a ensuite souligné que les identifiants et longueurs eux-mêmes pouvaient aider à reconnaître une application ou un terminal. Cryptex protège donc une partie plus large de la structure.

Après activation, une sonde intermédiaire peut cesser de voir une information qu’elle extrayait auparavant. Cela ne prouve pas la disparition de l’extension. Cela prouve une modification de visibilité. À l’inverse, un point terminal autorisé à déchiffrer ne possède pas automatiquement la bonne carte extmap.

Le registre de preuve doit distinguer six étapes : paquet reçu ; forme analysée ; carte de négociation retrouvée ; valeur décodée selon l’URI ; utilisation par un composant autorisé ; résultat observé indépendamment. Une étiquette unique telle que « traité » efface les endroits où une conclusion peut devenir fausse.

La discipline est simple à formuler : conserver les octets originaux, conserver le dictionnaire applicable et faire de toute interprétation un objet dérivé, versionné et révocable. Quand l’un manque, dire ce qui reste connaissable au lieu de combler le vide par habitude.