Groupe de travail Réseau |
P. Luthi, Tandberg |
Request for Comments : 5577 |
R. Even, Gesher Erove Ltd |
RFC rendue obsolète : 3047 |
juillet 2009 |
Catégorie : En cours de normalisation |
Traduction Claude Brière de L'Isle |
Format de charge utile RTP pour la Recommandation UIT-T G.722.1
Résumé
La Recommandation UIT-T G.722.1 est une norme de codec audio large bande. Le présent document décrit le format de charge utile pour inclure des flux binaires générés par G.722.1 au sein d'un paquet RTP. Le document décrit aussi la syntaxe et la sémantique des paramètres du protocole de description de session (SDP, Session Description Protocol) nécessaires à la prise en charge du codec audio G.722.1.
Statut du présent mémoire
Le présent document spécifie un protocole de normalisation Internet pour la communauté Internet, et appelle à discussion et suggestions en vue de son amélioration. Prière de s'en rapporter à l’édition en cours des "Internet Official Protocol Standards" (normes officielles du protocole Internet) (STD 1) pour connaître l’état de la normalisation et le statut du présent protocole. La distribution du présent mémoire n’est soumise à aucune restriction.
(La présente traduction incorpore les errata n° 1826 et 1827)
Déclaration de copyright
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.
Le présent mémoire est soumis selon le BCP 78 aux dispositions légales de l'IETF Trust qui se rapportent aux documents de l'IETF en vigueur à la date de publication de celui-ci (http://trustee.ietf.org/license-info). Prière de relire attentivement ces documents car ils décrivent vos droits et obligations à l'égard du présent document.
Le présent document peut contenir des matériaux provenant de documents de l'IETF ou contributions à l'IETF publiés ou rendus publiquement disponibles avant le 10 novembre 2008. La ou les personnes qui détiennent les droits de reproduction attachés à certains de ces matériaux peuvent ne pas avoir accordé à l'IETF Trust le droit de permettre leur modification en dehors du processus de normalisation de l'IETF. Sans avoir obtenu une licence adéquate de la ou des personnes qui détiennent les droits de reproduction de tels matériaux, il se peut que le présent document ne puisse pas être modifié en dehors du processus de normalisation de l'IETF, et que des travaux dérivés ne puissent être créés en dehors du processus de normalisation de l'IETF, excepté pour le formater pour sa publication comme RFC ou le traduire dans un langage autre que l'anglais.
Table des Matières
3.1 Champs d'en-tête RTP G.722.1
3.2 Format de charge utile RTP pour G.722.1
3.3 Trames G.722.1 multiples dans un paquet RTP
3.4 Calcul du nombre de trames G.722.1
4. Considérations relatives à l'IANA
4.1 Enregistrement du type de support
4.1.1 Enregistrement du type de support audio/G7221
5.1 Usage avec le modèle SDP d'offre/réponse
6. Considérations pour la sécurité
7. Changements depuis la RFC 3047
9.2 Références pour information
Le codec UIT-T G.722.1 [G7221] est un codeur à faible complexité ; il compresse des signaux audio à 50 Hz - 14 kHz en un des débits binaires suivants : 24 kbit/s, 32 kbit/s ou 48 kbit/s.
Le codeur peut être utilisé pour la parole, la musique, et d'autres types audio.
Certaines des applications pour lesquelles convient ce codeur sont :
o des communications en temps réel telles que la visioconférence et la téléphonie,
o la reproduction de flux audio,
o l'archivage et la messagerie.
La Recommandation UIT-T G.722.1 [G7221] utilise des trames de 20 ms et une horloge de taux d'échantillonnage de 16 kHz ou 32 kHz. L'algorithme de codage et de décodage peut changer le débit binaire à toute frontière de trame de 20 ms, mais aucune notification de changement du débit binaire n'est fournie dans la bande avec le flux binaire.
Pour tout débit binaire donné, le nombre de bits dans une trame est constant. Au sein de cette trame fixe, G.722.1 utilise un codage de longueur variable (par exemple, le codage Huffman) pour représenter la plupart des paramètres codés. Tous les codes de longueur variable sont transmis dans l'ordre du bit le plus à gauche (bit de poids fort -- MSB) au bit le plus à droite (bit de moindre poids -- LSB), voir [G7221] pour les détails.
Les débits binaires normalisés par l'UIT-T pour G.722.1 sont 24 kbit/s ou 32 kbit/s à 16 kHz de taux d'échantillon, et 24 kbit/s, 32 kbit/s ou 48 kbit/s à 32 kHz de taux d'échantillon. Cependant, l'algorithme de codage lui-même a la capacité de fonctionner à tout débit binaire spécifié par l'utilisateur (et pas seulement 24, 32, et 48 kbit/s) tout en maintenant une bande passante audio de 50 Hz à 14 kHz. Ce changement de taux est réalisé par un échelonnement linéaire du fonctionnement du codec, qui résulte en des trames dont la taille en bits est égale à 1/50 du débit binaire correspondant.
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT" et "FACULTATIF" dans le présent document sont à interpréter comme décrit dans la [RFC2119] et indiquent les niveaux d'exigence pour les mises en œuvre RTP conformes.
3.1 Champs d'en-tête RTP G.722.1
L'en-tête RTP est défini dans la spécification RTP [RFC3550]. Cette section définit comment sont utilisés les champs dans l'en-tête RTP.
Type de charge utile (PT) : L'allocation d'un type de charge utile RTP pour ce format de paquet sort du domaine d'application de ce document ; il est spécifié par le profil RTP sous lequel est utilisé ce format de charge utile, ou il est signalé de façon dynamique hors bande (par exemple, en utilisant SDP).
Bit marqueur (M) : Le bit M est mis à zéro.
Bit d'extension (X) : Défini par le profil RTP utilisé.
Horodatage : Un mot de 32 bits qui correspond à l'instant d'échantillonnage pour la première trame dans le paquet RTP. La fréquence d'échantillonnage peut être de 16 kHz ou de 32 kHz. La fréquence d'horloge de l'horodatage RTP de 32 kHz DEVRAIT être utilisée sauf si un seul flux RTP échantillonné à 16 kHz va être envoyé.
3.2 Format de charge utile RTP pour G.722.1
La charge utile RTP pour G.722.1 a le format indiqué à la Figure 1. Aucun champ d'en-tête supplémentaire spécifique de ce format de charge utile n'est exigé.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| En-tête RTP |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+ une ou plusieurs trames de G.722.1 |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 : Charge utile RTP pour G.722.1.
Comme le débit binaire n'est pas signalé dans la bande, une méthode hors bande distincte est EXIGÉE pour indiquer le débit binaire (voir à la Section 5 un exemple d'informations de signalisation de débit binaire qui utilise SDP). Pour le format de charge utile spécifié ici, le débit binaire DOIT rester constant pour une valeur de type de charge utile particulière. Une application PEUT changer le débit binaire et le débit d'horloge d'un paquet à l'autre en définissant des valeurs différentes de type de charge utile et en les changeant de paquet à paquet.
L'utilisation du codage de Huffman signifie qu'il n'est pas possible d'identifier les divers paramètres/champs codés contenus au sein du flux binaire sans décoder d'abord complètement la trame entière. Pour les besoins de la mise en paquet du flux binaire dans RTP, il est seulement nécessaire de considérer la séquence de bits en sortie du codeur G.722.1 et de présenter la même séquence au décodeur. Le format de charge utile décrit ici maintient cette séquence.
En fonctionnement à 24 kbit/s, 480 bits (60 octets) sont produits par trame. En fonctionnement à 32 kbit/s, 640 bits (80 octets) sont produits par trame. En fonctionnement à 48 kbit/s, 960 bits (120 octets) sont produits par trame. Et donc, les trois débits binaires permettent tous l'alignement sur l'octet sans qu'il soit besoin de bits de bourrage.
La Figure 2 illustre comment le flux binaire G.722.1 DOIT être transposé en une charge utile RTP alignée sur l'octet.
premier bit dernier bit
transmis transmis
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ séquence de bits (480, 640, ou 960) générés par le |
| codeur G.722.1 pour la transmission |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| | | ... | |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+
|MSB... LSB |MSB... LSB | |MSB... LSB |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+
octet RTP 1 octet RTP 2 octet RTP
60, 80, 120
Figure 2 : Le flux binaire de codeur G.722.1 est partagé en une séquence d'octets (60, 80, ou 120 selon le débit binaire, et chaque octet est transposé à son tour en un octet RTP.
En fonctionnement à des débits non standard, le format de charge utile DOIT suivre les lignes directrices illustrées à la Figure 2. Il est RECOMMANDÉ que les valeurs dans la gamme 16 000 à 48 000 soient utilisées. Les débits non standard DOIVENT avoir une valeur qui soit un multiple de 400 (cela conserve l'alignement sur l'octet et n'exige donc pas de bits de bourrage (non définis) pour chaque trame si elle n'est pas alignés sur l'octet). Par exemple, un débit binaire de 16,4 kbit/s résulterait en une taille de trame de 328 bits ou 41 octets, ce qui est transposé dans RTP par la Figure 2.
3.3 Trames G.722.1 multiples dans un paquet RTP
Un envoyeur peut inclure plus d'une trame G.722.1 consécutive dans un seul paquet RTP.
Les restrictions supplémentaires suivantes s'appliquent aux envoyeurs :
o Les envoyeurs NE DEVRAIENT PAS inclure dans un seul paquet RTP plus de trames G.722.1 qu'il n'en tiendra dans la MTU du protocole de transport RTP.
o Toutes les trames contenues dans un seul paquet RTP DOIVENT être de la même longueur et échantillonnées au même débit d'horloge. Elles DOIVENT avoir le même débit binaire (octets par trame).
o Les trames NE DOIVENT PAS être partagées entre des paquets RTP.
Il est RECOMMANDÉ que le nombre de trames contenues dans un paquet RTP soit cohérent avec l'application. Par exemple, dans une application de téléphonie où le délai est important, moins il y a de trames par paquet, plus faible est le délai ; tandis que pour un flux insensible au délai ou une application de messagerie, de nombreuses trames par paquet pourraient être acceptables.
3.4 Calcul du nombre de trames G.722.1
Les informations qui décrivent le nombre de trames contenues dans un paquet RTP ne sont pas transmises au titre de la charge utile RTP. La seule façon de déterminer le nombre de trames G.722.1 est de compter le nombre total d'octets au sein du paquet RTP et de diviser le compte d'octets par le nombre d'octets attendus par trame. Ce compte attendu d'octets par trame est déduit du débit binaire et est donc une fonction du type de charge utile.
4. Considérations relatives à l'IANA
Le présent document met à jour le type de support G7221 décrit dans la [RFC 3047].
4.1 Enregistrement du type de support
Cette section décrit les types et noms de supports associés à ce format de charge utile. La section enregistre les types de supports, conformément à la [RFC4288].
Nom du type de support : audio
Nom du sous-type de support : G7221
Paramètres exigés :
bitrate : le débit de données du flux binaire audio. Ce paramètre est obligatoire parce que le débit binaire n'est pas signalé au sein du flux binaire G.722.1. Aux débits binaires G.722.1 standard, la valeur DOIT être 24 000 ou 32 000 au taux d'échantillon de 16 kHz, et 24 000, 32 000, ou 48 000 au taux d'échantillon de 32 kHz . Si des débits binaires non standard sont utilisés, il est alors RECOMMANDÉ que soient utilisées des valeurs dans la gamme 16 000 à 48 000. Les débits non standard DOIVENT avoir une valeur qui est un multiple de 400 (cela conserve l'alignement sur l'octet et n'exige donc pas de bits de bourrage (indéfinis) pour chaque trame).
Paramètres facultatifs :
rate : débit d'horloge de l'horodatage RTP, qui est égal au taux d'échantillon. Si le paramètre n'est pas spécifié, on suppose un débit d'horloge de 16 kHz.
ptime : voir la [RFC4566]. DEVRAIT être un multiple de 20 ms.
maxptime : voir la [RFC4566]. DEVRAIT être un multiple de 20 ms.
Considérations pour le codage :
Ce type de support est en trames et binaire, voir le paragraphe 4.8 de la [RFC4288].
Considérations pour la sécurité : Voir à la Section 6.
Considérations d'interopérabilité :
Les terminaux DEVRAIENT offrir un type de support à un taux d'échantillon de 16 kHz afin d'interopérer avec les terminaux qui ne prennent pas en charge le nouveau taux d'échantillon de 32 kHz.
Spécification publiée : RFC 5577.
Applications qui utilisent ce type de support : Applications audio et vidéo de flux directs et de conférence.
Informations supplémentaires : Aucune
Nom et adresse de messagerie de la personne à contacter pour des information complémentaires :
Roni Even: ron.even.tlv@gmail.com
Utilisation prévue : Courante
Restrictions d'usage :
Ce type de support dépend du tramage RTP, et n'est donc défini que pour le transfert via RTP [RFC3550]. Le transport au sein d'autres protocoles de tramage n'est pas défini pour l'instant.
Auteur : Roni Even
Contrôleur des modifications : Groupe de travail Audio/Video Transport de l'IETF sur délégation de l'IESG.
Les types de supports audio/G7221 sont transposés dans les champs du protocole de description de session (SDP) [RFC4566] comme suit :
o le nom du support dans la ligne "m=" de SDP DOIT être audio ;
o le nom du codage dans la ligne "a=rtpmap" de SDP DOIT être G7221 (le sous-type de support) ;
o le paramètre "rate" va dans "a=rtpmap" comme paramètre de débit d'horloge ;
o un seul bitrate DEVRA être défini (en utilisant le paramètre "bitrate=" dans la ligne a=fmtp) pour chaque type de charge utile.
5.1 Usage avec le modèle SDP d'offre/réponse
Les considérations suivantes sont nécessaires pour le service de G.722.1 sur RTP en utilisant SDP dans un modèle d'offre/réponse [RFC3264] :
La combinaison du débit d'horloge dans les paramètres rtpmap et bitrate définit la configuration de chaque type de charge utile. Chaque configuration destinée à l'utilisation DOIT être déclarée.
Deux débits d'horloge d'échantillonnage sont définis pour G.722.1 dans le présent document. La [RFC3047] ne prend en charge que le débit d'horloge à 16 kHz. Donc, un système qui veut utiliser G.722.1 DEVRAIT offrir un type de charge utile avec un débit d'horloge de 16 000 pour la rétro interopérabilité.
Un exemple d'offre comportant les débits d'horloge de 16 000 et 32 000 est :
m=audio 49000 RTP/AVP 121 122
a=rtpmap:121 G7221/16000
a=fmtp:121 bitrate=24000
a=rtpmap:122 G7221/32000
a=fmtp:122 bitrate=48000
6. Considérations pour la sécurité
Les paquets RTP qui utilisent le format de charge utile défini dans la présente spécification sont soumis aux considérations pour la sécurité exposées dans la spécification RTP [RFC3550] et dans tout profil RTP approprié. Les principaux soucis de sécurité pour le paquet RTP qui porte le format de charge utile RTP défini dans le présent mémoire sont la confidentialité, l'intégrité, et l'authenticité de la source. La confidentialité est réalisée par le chiffrement de la charge utile RTP. L'intégrité des paquets RTP est réalisé par un mécanisme convenable de protection de l'intégrité par le chiffrement. Un tel système cryptographique peut aussi permettre l'authentification de la source de la charge utile. Un mécanisme de sécurité convenable pour ce format de charge utile RTP devrait fournir la protection de la confidentialité, de l'intégrité, et au moins une authentification de source capable de déterminer si un paquet RTP provient d'un membre de la session RTP.
Noter que le mécanisme approprié pour la fourniture de la sécurité à RTP et aux charges utiles qui suivent le présent mémoire peut varier. Il dépend de l'application, du transport, et du protocole de signalisation employé. Donc, un seul mécanisme est insuffisant, quoique, s'il convient, l'usage du protocole de transport sécurisé en temps réel (SRTP) [RFC3711] soit recommandé. Un autre mécanisme qui peut être utilisé est IPsec [RFC4301] ou la sécurité de couche Transport (TLS) [RFC5246] (RTP sur TCP) ; d'autres solutions de remplacement peuvent exister.
Ce format de charge utile RTP et son décodeur de support ne présentent aucune non uniformité significative dans la complexité calculatoire du côté receveur pour le traitement de paquet, et donc il est peu vraisemblable qu'il subisse des menaces de déni de service dues à la réception de données pathologiques. Le format de charge utile RTP ne contient pas non plus de contenu actif.
7. Changements depuis la RFC 3047
La présente spécification rend obsolète la RFC 3047, en y ajoutant la prise en charge de l'audio à très large bande (14 kHz) défini dans l'Annexe C de la nouvelle révision de la Recommandation UIT-T G.722.1.
Autres modifications : Mise à jour du texte pour l'aligner sur les règles actuelles des RFC et l'enregistrement de type de support conformes à la RFC 4288.
Les auteurs tiennent à remercier Tom Taylor de sa contribution à ce travail.
(Les liens hypertextes en tête de référence sont pointés sur le texte anglais original. Les liens dans le corps du titre sont sur la traduction française éventuelle.)
[G7221] Union Internationale des Télécommunications , "Codage à faible complexité à 24 et 32 kbit/s pour fonctionnement en main libre dans des systèmes à faible perte de trame", Recommandation UIT-T G.722.1, 2005.
[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.
[RFC3264] J. Rosenberg et H. Schulzrinne, "Modèle d'offre/réponse avec le protocole de description de session (SDP)", juin 2002.
[RFC3550] H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson, "RTP : un protocole de transport pour les applications en temps réel", STD 64, juillet 2003.
[RFC4566] M. Handley, V. Jacobson et C. Perkins, "SDP : Protocole de description de session", juillet 2006. (P.S.)
9.2 Références pour information
[RFC3047] P. Luthi, "Format de charge utile RTP pour la Recommandation UIT-T G.722.1", janvier 2001. (Obsolète)
[RFC3711] M. Baugher et autres, "Protocole de transport sécurisé en temps réel (SRTP)", mars 2004.
[RFC4288] N. Freed et J. Klensin, "Spécifications du type de support et procédures d'enregistrement", BCP 13, décembre 2005.
[RFC4301] S. Kent et K. Seo, "Architecture de sécurité pour le protocole Internet", décembre 2005. (P.S.)
[RFC5246] T. Dierks, E. Rescorla, "Version 1.2 du protocole de sécurité de la couche Transport (TLS)", août 2008. (P.S.)
Adresse des auteurs
Patrick Luthi |
Roni Even |
Tandberg |
Gesher Erove Ltd |
Philip Pedersens vei 22 |
14 David Hamelech |
1366 Lysaker |
Tel Aviv 64953 |
Norway |
Israel |
mél : patrick.luthi@tandberg.no |
mél : ron.even.tlv@gmail.com |