9. Modifications par rapport à la RFC 1890
- Modifications par rapport à la RFC 1890
Cette RFC révise la RFC 1890. Elle est en grande partie rétrocompatible avec la RFC 1890, à l'exception des fonctions supprimées car deux implémentations interopérables n'ont pas été trouvées. Les ajouts à la RFC 1890 codifient la pratique existante dans l'utilisation des formats de charge utile sous ce profil. Puisque ce profil peut être utilisé sans utiliser aucun des formats de charge utile énumérés ici, l'ajout de nouveaux formats de charge utile dans cette révision n'affecte pas la rétrocompatibilité. Les modifications sont énumérées ci-dessous, classées en modifications fonctionnelles et non fonctionnelles.
Modifications fonctionnelles :
o La section 11, "Considérations IANA", a été ajoutée pour spécifier l' enregistrement du nom de ce profil. Cette annexe fait également référence à une nouvelle section 3 "Enregistrement d'encodages supplémentaires" qui établit une politique selon laquelle aucun enregistrement supplémentaire de types de charge utile statiques pour ce profil ne sera effectué au-delà de ceux ajoutés dans cette révision et inclus dans les tableaux 4 et 5. Au lieu de cela, des noms d'encodage supplémentaires peuvent être enregistrés en tant que sous-types MIME pour la liaison à des types de charge utile dynamiques. Des références non normatives ont été ajoutées à la RFC 3555 [7] où les sous-types MIME pour tous les formats de charge utile énumérés sont enregistrés, certains avec des paramètres facultatifs pour l'utilisation des formats de charge utile.
o Les types de charge utile statiques 4, 16, 17 et 34 ont été ajoutés pour intégrer les enregistrements IANA effectués depuis la publication de la RFC 1890, ainsi que les descriptions de format de charge utile correspondantes pour G723 et H263.
o Suite à une discussion du groupe de travail, les types de charge utile statiques 12 et 18 ont été ajoutés avec les descriptions de format de charge utile correspondantes pour QCELP et G729. Le type de charge utile statique 13 a été attribué au format de charge utile Comfort Noise (CN) défini dans la RFC 3389. Le type de charge utile 19 a été marqué réservé car il avait été temporairement alloué à une version antérieure de Comfort Noise présente dans certaines révisions préliminaires de ce document.
o Le format de charge utile pour G721 a été renommé G726-32 suite à la renumérotation de l'UIT-T, et la description du format de charge utile pour G726 a été étendue pour inclure les débits de données -16, -24 et -40. En raison de la confusion concernant les révisions préliminaires de ce document, certaines implémentations de ces formats de charge utile G726 emballaient les échantillons dans des octets en commençant par le bit le plus significatif plutôt que par le bit le moins significatif comme spécifié ici. Pour résoudre partiellement cette incompatibilité, de nouveaux formats de charge utile nommés AAL2-G726-16, -24, -32 et -40 seront spécifiés dans un document séparé (voir la note dans la section 4.5.4), et l'utilisation du type de charge utile statique 2 est obsolète comme expliqué dans la section 6.
o Les formats de charge utile G729D et G729E ont été ajoutés suite à l'ajout par l'UIT-T des annexes D et E à la recommandation G.729. Des listes ont été ajoutées pour les formats de charge utile GSM-EFR, RED et H263-1998 publiés dans d'autres documents postérieurs à la RFC 1890. Ces formats de charge utile supplémentaires sont référencés uniquement par des numéros de type de charge utile dynamiques.
o Les descriptions des formats de charge utile pour G722, G728, GSM, VDVI ont été étendues.
o Le format de charge utile pour l'audio 1016 a été supprimé et son attribution de type de charge utile statique 1 a été marquée "réservée" car deux implémentations interopérables n'ont pas été trouvées.
o Des exigences pour le contrôle de la congestion ont été ajoutées dans la section 2.
o Ce profil suit la suggestion de la spécification RTP révisée selon laquelle la bande passante RTCP peut être spécifiée séparément de la bande passante de la session et séparément pour les expéditeurs actifs et les récepteurs passifs.
o Le mappage d'une chaîne de phrase de passe utilisateur en une clé de chiffrement a été supprimé de la section 2 car deux implémentations interopérables n'ont pas été trouvées.
o La convention d'ordre des échantillons "quadriphonique" pour l'audio à quatre canaux a été supprimée pour éliminer une ambiguïté comme indiqué dans la section 4.1.
Modifications non fonctionnelles :
o Dans la section 4.1, il est maintenant explicitement indiqué que la suppression du silence est autorisée pour tous les formats de charge utile audio. (Cela a toujours été le cas et découle d'un aspect fondamental de la conception de RTP et des motivations pour l'audio par paquets, mais n'était pas explicitement indiqué auparavant.) L'utilisation du bruit de confort est également expliquée.
o Dans la section 4.1, le niveau d'exigence pour le réglage du bit marqueur sur le premier paquet après le silence pour l'audio a été modifié de "est" à "DEVRAIT être", et il a été précisé que le bit marqueur est défini uniquement lorsque les paquets ne sont intentionnellement pas envoyés.
o De même, du texte a été ajouté pour spécifier que le bit marqueur DEVRAIT être mis à un sur le dernier paquet d'une image vidéo, et que les images vidéo sont distinguées par leurs horodatages.
o Des références RFC sont ajoutées pour les formats de charge utile publiés après la RFC 1890.
o Les considérations de sécurité et les sections complètes sur les droits d'auteur ont été ajoutées.
o Selon Peter Hoddie d'Apple, seuls les Macintosh d'avant 1994 utilisaient le taux de 22254,54 et aucun le taux de 11127,27, donc ce dernier a été supprimé de la discussion sur les fréquences d'échantillonnage suggérées.
o Le tableau 1 a été corrigé pour déplacer certaines valeurs de la colonne "ms/paquet" vers la colonne "ms/paquet par défaut" où elles appartenaient.
o Puisque l'Interactive Multimedia Association a cessé ses activités, une ressource alternative a été fournie pour un document IMA référencé.
o Une note a été ajoutée pour G722 afin de clarifier une divergence entre le taux d'échantillonnage réel et le taux d'horloge de l'horodatage RTP.
o De petites clarifications du texte ont été apportées à plusieurs endroits, certaines en réponse à des questions de lecteurs. En particulier :
- Une définition de "type de média" est donnée dans la section 1.1 pour permettre
à l'explication du multiplexage des sessions RTP dans la section 6 d'être
plus claire concernant le multiplexage de plusieurs médias.
- L'explication de la manière de déterminer le nombre de trames audio
dans un paquet à partir de la longueur a été étendue.
- Plus de description de l'allocation de bande passante aux éléments SDES
est donnée.
- Une note a été ajoutée indiquant que la convention pour l'ordre des canaux
spécifiée dans la section 4.1 peut être annulée par une spécification
d'encodage ou de format de charge utile particulière.
- Les termes DOIT, DEVRAIT, PEUT, etc. sont utilisés tels que définis dans la RFC
2119.
o Un deuxième auteur pour ce document a été ajouté.