Résumé

  • La RFC 5577 remplace l’ancien format de charge utile RTP afin de prendre en charge l’audio à 14 kHz de l’annexe C de G.722.1, une horloge d’échantillonnage à 32 kHz et un débit de 48 kbit/s.
  • Elle n’impose pas de rupture nette : le texte recommande de continuer à proposer le profil historique à 16 kHz pour l’interopérabilité, et exige que chaque combinaison de fréquence d’horloge et de débit prévue soit déclarée dans SDP.

Une RFC remplacée n’efface pas les terminaux qui la connaissent

Publiée en juillet 2009, la RFC 5577 porte dans son en-tête la mention « Obsoletes: 3047 ». On pourrait y voir un basculement : une spécification sort, la suivante prend sa place. Mais la section consacrée à l’interopérabilité décrit une transition plus nuancée. La RFC 3047 définissait G.722.1 avec une horloge d’échantillonnage de 16 kHz. La révision suivante ajoute la prise en charge de l’audio superlarge bande de l’annexe C de la recommandation UIT-T révisée : la bande audio atteint 14 kHz, une configuration à 32 kHz apparaît et le débit de 48 kbit/s s’ajoute.

Ces chiffres ne mesurent pas la même chose. Les 14 kHz caractérisent la bande de l’audio encodé ; 16 ou 32 kHz désignent l’horloge d’échantillonnage des horodatages RTP ; 24, 32 ou 48 kbit/s désignent le débit du codec. La RFC 5577 ne les rassemble pas en un unique réglage de « qualité ». La signalisation de session sert à décrire une combinaison utilisable.

Le flux du codec ne signale pas dans la bande un changement de débit. La RFC 5577 impose donc une méthode de signalisation distincte et un débit constant pour chaque type de charge utile RTP. Une application peut changer de profil d’un paquet à l’autre, mais elle doit utiliser des valeurs de type de charge utile distinctes. Dans SDP, a=rtpmap indique l’encodage et la fréquence d’horloge ; a=fmtp précise le débit. Ensemble, ils décrivent la configuration proposée au terminal destinataire.

Le modèle Offer/Answer rend cette déclaration déterminante. La RFC exige que l’offre énumère chaque configuration que l’émetteur entend utiliser. Elle nomme ensuite directement la lacune de compatibilité : l’ancienne RFC ne prenait en charge que l’horloge de 16 kHz ; un système qui recherche l’interopérabilité devrait donc également proposer un type de charge utile à 16 kHz. L’exemple de la RFC distingue l’option 16 kHz/24 kbit/s de l’option 32 kHz/48 kbit/s par deux types différents.

Cela ne signifie pas que tout ancien terminal pouvait négocier sans difficulté, ni que le nouveau profil revenait automatiquement au précédent. Une offre énumère des choix pris en charge ; elle ne prouve ni la réponse du correspondant ni l’arrivée du son à l’auditeur. Le terminal destinataire doit sélectionner une configuration qu’il sait traiter, puis la session doit transporter le profil convenu. La RFC 5577 préserve une voie ; elle ne certifie pas qui l’a empruntée.

La structure des paquets conserve une autre limite. Les trames durent toujours 20 millisecondes. Aux débits normalisés, une trame occupe 60, 80 ou 120 octets. Un paquet peut agréger des trames successives, à condition qu’elles gardent le même débit et la même horloge ; une trame ne peut pas être répartie sur deux paquets. Le récepteur déduit le nombre de trames de la taille utile et du nombre d’octets attendu par trame, sans champ supplémentaire dans la charge utile.

La RFC recommande moins de trames lorsque le délai importe et en autorise davantage pour le streaming ou la messagerie moins sensibles au délai ; elle ne fixe aucune latence universelle.

Vue sous l’angle de la migration, la RFC 5577 ne raconte donc pas le remplacement d’un codec par un autre, mais la façon de garder les choix visibles. La ligne « Obsoletes » remplace le texte normatif. L’offre à 16 kHz maintient la compatibilité antérieure dans le champ des possibles. Aucun de ces faits ne mesure la part des terminaux ayant adopté l’un ou l’autre profil.

Sources