3. Enregistrement d'encodages supplémentaires

3. Enregistrement d'encodages supplémentaires

   Ce profil énumère un ensemble d'encodages, chacun étant composé d'une compression ou d'une représentation de données multimédia particulière plus un format de charge utile pour l'encapsulation dans RTP. Certains de ces formats de charge utile sont spécifiés ici, tandis que d'autres sont spécifiés dans des RFC distinctes. Il est attendu que des encodages supplémentaires au-delà de l'ensemble énuméré ici soient créés à l'avenir et spécifiés dans des RFC de format de charge utile supplémentaires.

   Ce profil attribue également à chaque encodage un nom court qui PEUT être utilisé par des protocoles de contrôle de niveau supérieur, tels que le protocole de description de session (SDP), RFC 2327 [6], pour identifier les encodages sélectionnés pour une session RTP particulière.

   Dans certains contextes, il peut être utile de faire référence à ces encodages sous la forme d'un type de contenu MIME. Pour faciliter cela, la RFC 3555 [7] fournit des enregistrements pour tous les noms d'encodages énumérés ici en tant que noms de sous-types MIME sous les types MIME "audio" et "video" par le biais de la procédure d'enregistrement MIME spécifiée dans la RFC 2048 [8].

   Tout encodage supplémentaire spécifié pour une utilisation sous ce profil (ou d'autres) peut également se voir attribuer des noms enregistrés en tant que sous-types MIME auprès de l'Internet Assigned Numbers Authority (IANA). Ce registre fournit un moyen de garantir que les noms attribués aux encodages supplémentaires restent uniques. La RFC 3555 spécifie les informations requises pour l'enregistrement des encodages RTP.

   En plus d'attribuer des noms aux encodages, ce profil attribue également des numéros de type de charge utile RTP statiques à certains d'entre eux. Cependant, l'espace de numéros de type de charge utile est relativement petit et ne peut pas accueillir d'attributions pour tous les encodages existants et futurs. Au cours des premières étapes du développement de RTP, il était nécessaire d'utiliser des types de charge utile attribués de manière statique car aucun autre mécanisme n'avait été spécifié pour lier les encodages aux types de charge utile. Il était prévu que des moyens non RTP dépassant le cadre de ce mémo (tels que des services d'annuaire ou des protocoles d'invitation) seraient spécifiés pour établir un mappage dynamique entre un type de charge utile et un encodage. Maintenant, des mécanismes pour définir des liaisons de type de charge utile dynamiques ont été spécifiés dans le protocole de description de session (SDP) et dans d'autres protocoles tels que la recommandation ITU-T H.323/H.245. Ces mécanismes associent le nom enregistré du format d'encodage/de charge utile, ainsi que tous les paramètres supplémentaires requis, tels que la fréquence d'horloge de l'horodatage RTP et le nombre de canaux, à un numéro de type de charge utile. Cette association n'est efficace que pour la durée de la session RTP dans laquelle la liaison de type de charge utile dynamique est effectuée. Cette association ne s'applique qu'à la session RTP pour laquelle elle est effectuée, ainsi les numéros peuvent être réutilisés pour différents encodages dans différentes sessions, évitant ainsi la limitation de l'espace numérique.

   Ce profil réserve les numéros de type de charge utile dans la plage 96-127 exclusivement pour une attribution dynamique. Les applications DEVRAIENT d'abord utiliser des valeurs dans cette plage pour les types de charge utile dynamiques. Les applications qui doivent définir plus de 32 types de charge utile dynamiques PEUVENT lier des codes inférieurs à 96, auquel cas il est RECOMMANDÉ d'utiliser d'abord des numéros de type de charge utile non attribués. Cependant, les types de charge utile attribués de manière statique sont des liaisons par défaut et PEUVENT être liés dynamiquement à de nouveaux encodages si nécessaire. Redéfinir les types de charge utile inférieurs à 96 peut entraîner un fonctionnement incorrect si une tentative est faite pour rejoindre une session sans obtenir d'informations de description de session définissant les types de charge utile dynamiques.

   Les types de charge utile dynamiques NE DEVRAIENT PAS être utilisés sans un mécanisme bien défini pour indiquer le mappage. Les systèmes qui s'attendent à interopérer avec d'autres fonctionnant sous ce profil NE DEVRAIENT PAS faire leurs propres attributions d'encodages propriétaires à des types de charge utile fixes particuliers.

   Cette spécification établit la politique selon laquelle aucun type de charge utile statique supplémentaire ne sera attribué au-delà de ceux définis dans ce document. L'établissement de cette politique évite le problème d'essayer de créer un ensemble de critères pour accepter des attributions statiques et encourage la mise en œuvre et le déploiement des mécanismes de type de charge utile dynamique.

   L'ensemble final d'attributions de type de charge utile statique est fourni dans les tableaux 4 et 5.