Résumé

  • RFC 3119 demandait à SDP d’employer mp3, alors que le sous-type enregistré et l’exemple rtpmap voisin indiquaient mpa-robust ; RFC 5219 a aligné le nom d’encodage.
  • Le texte révisé conserve la conception RTP fondée sur les ADU et qualifie ses retouches au pseudocode de mineures et non normatives. Les RFC ne disent pas si un logiciel déployé a utilisé le nom contradictoire ni si une session a échoué.

Deux noms dans le même paragraphe

La contradiction est facile à laisser passer. RFC 3119, publié en 2001, enregistre mpa-robust comme sous-type média du format MP3 pour RTP. Pourtant, sa section sur SDP impose le nom d’encodage mp3. L’exemple juste en dessous attribue le type de payload dynamique 121 et écrit a=rtpmap:121 mpa-robust/90000.

Ces lignes décrivent le format à deux endroits différents. RTP transporte un numéro de type de payload ; pour un numéro dynamique, l’attribut SDP rtpmap indique à l’autre extrémité l’encodage et la fréquence d’horloge associés. RFC 4566 définit cette correspondance. RFC 3119 donnait donc deux noms incompatibles pour la description de session, alors que son sous-type média et son exemple concordaient entre eux.

Le problème dépasse la typographie. Un numéro dynamique n’explique pas de lui-même le contenu transporté. Les deux extrémités ont besoin de la même correspondance entre le numéro inscrit dans les paquets RTP et le format attendu par le récepteur. La disposition des paquets peut être cohérente alors que le point de négociation qui la décrit ne l’est pas. Le document prouve une incohérence de spécification, pas la réaction d’un équipement en service.

Pourquoi une autre disposition RTP

La proposition d’origine répondait à une caractéristique précise du MP3 Layer III. Une trame peut pointer vers des données encodées dans des trames antérieures ; elle ne constitue donc pas toujours une unité de décodage indépendante. RFC 3119 expliquait que des paquets RTP alignés sur les trames pouvaient rendre inutilisables des données d’autres trames pourtant reçues.

Le format alternatif réorganisait le flux en unités de données applicatives (ADU). Chaque ADU recevait un descripteur indiquant sa taille et la poursuite éventuelle de son contenu dans un autre paquet. L’émetteur pouvait aussi entrelacer les ADU : des unités consécutives circulaient alors dans des paquets non consécutifs. Il ne s’agissait pas simplement d’ajouter de la redondance, mais de placer les frontières de paquets par rapport aux unités traitées par le décodeur, tout en conservant les données encodées.

Publié en février 2008, RFC 5219 reprend cette approche. Son introduction rappelle le pointeur arrière des trames, les ADU, leurs descripteurs et l’entrelacement facultatif. Le résumé dit que le RFC remplace RFC 3119 pour corriger des erreurs typographiques dans SDP et les appendices de pseudocode. L’appendice C précise que la correction du nom SDP est le changement principal ; les appendices A et B reçoivent des corrections et clarifications mineures à un pseudocode non normatif.

Le correctif est explicite : RFC 5219 impose mpa-robust, en accord avec le sous-type enregistré, et son exemple associe toujours le type dynamique 121 à mpa-robust/90000. Un erratum vérifié par l’éditeur des RFC consigne aussi l’erreur antérieure ainsi que plusieurs réparations d’exemples : le pointeur arrière est une valeur, non une taille ; une variable devient prevADU au lieu de curADU ; deux limites de tableau passent de 32 à 256. Ces changements précisent la recette écrite. Ils ne démontrent pas que les payloads employés en production ont changé en 2008.

Un numéro de RFC ne documente pas un incident

RFC 5219 montre que les standards peuvent être corrigés à plusieurs niveaux. Le nom SDP relève d’une consigne normative de description de session : la révision précise le nom que les participants doivent donner à l’encodage. Les modifications d’appendice concernent un pseudocode que RFC 5219 lui-même qualifie de non normatif. Aucun de ces éléments ne mesure l’ampleur d’un problème opérationnel.

Les documents ne contiennent ni recensement d’implémentations, ni capture de paquets, ni trace d’appel échoué, ni note de version d’un fournisseur, ni essai comparatif. Ils ne disent pas qu’un équipement a annoncé mp3, qu’un autre l’a rejeté ou que la nouvelle graphie a amélioré l’interopérabilité dans des déploiements mesurés. L’acceptation d’un erratum prouve un défaut du texte, pas la fréquence à laquelle un logiciel l’a reproduit.

La limite historique est donc claire. RFC 5219 a remplacé un document parce que sa consigne de description de session devait être corrigée et que des indications d’implémentation demandaient des précisions. Il a conservé le modèle de payload avec ADU. Le dossier des standards établit les corrections des auteurs ; pour savoir si elles ont compté dans des systèmes réels, il faudrait des traces distinctes provenant des implémentations et des sessions.

Sources

  1. https://www.rfc-editor.org/rfc/rfc3119.html
  2. https://www.rfc-editor.org/info/rfc3119/
  3. https://www.rfc-editor.org/rfc/rfc5219.html
  4. https://www.rfc-editor.org/info/rfc5219/
  5. https://datatracker.ietf.org/doc/rfc5219/
  6. https://www.rfc-editor.org/errata/eid331
  7. https://www.rfc-editor.org/rfc/rfc4566.html
  8. https://www.rfc-editor.org/rfc/rfc2250.html
  9. https://www.rfc-editor.org/rfc/rfc3550.html
  10. https://www.rfc-editor.org/rfc/rfc3551.html
  11. https://www.rfc-editor.org/rfc/rfc2736.html