Network Working Group J

Voix de qualité supérieure – enregistrement du sous-type MIME en modulation par impulsions et codage différentiel adaptatif à 32 kbit/s (MICDA)

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Le présent document décrit l'enregistrement du sous type MIME audio/32KADPCM en modulation par impulsions et codage différentiel adaptatif pour l'audio de qualité supérieure. Ce codage audio est défini par l'UIT-T dans la Recommandation G.726.

Table des Matières

1. Introduction

2. Définition UIT-T

3. Définition MIME

3.1. audio/32KADPCM

3.2. Usage VPIM

4. Enregistrement par l'IANA

5. Considérations sur la sécurité

6. Références

6.1. Références normatives

6.2. Références pour information

7. Changements par rapport à la RFC2422

8. Adresse des auteurs

9. Déclaration complète de droits de reproduction

Le présent document décrit l'enregistrement du sous type MIME audio/32KADPCM pour l'audio de qualité supérieure. Ce codage audio est défini par l'UIT-T dans la Recommandation G.726. Le présent document rend obsolète un enregistrement de sous type antérieur contenu dans la RFC 1911. Le présent document rend aussi obsolète la RFC 2422.

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

La Recommandation G.726 [G726] définit les caractéristiques qui sont recommandées pour la conversion d'un canal à 64 kbit/s en modulation par impulsion et codage (MIC) en Loi A ou Loi µ à 8000 échantillons/s en et d'un canal à 40, 32, 24 ou 16 kbit/s. La conversion est appliquée au flux binaire MIC en utilisant une technique de transcodage de la modulation par impulsions et codage différentiel adaptatif (MICDA). La présente Recommandation rend obsolète la Recommandation G.721 qui ne définissait que les caractéristiques du 32 kbit/s.

La Recommandation G.726 a été préparée par le groupe d'études 15 du secteur de la normalisation des télécommunications de l'Union Internationale des Télécommunication (UIT-T) et a été approuvée selon la procédure de résolution n° 2 de l'UIT-T le 14 décembre 1990.

La Recommandation UIT-T G.726 [G726] décrit l'algorithme recommandé pour la conversion d'un canal MIC à 64 kbit/s en Loi A ou en Loi µ de et vers un canal à 32 kbit/s (c'est le même algorithme que décrit dans la Recommandation G.721 déconseillée). La conversion est appliquée au flux MIC en utilisant une technique de transcodage de modulation par impulsions et codage différentiel adaptatif (ADPCM, Adaptive Differential Pulse Code Modulation).

Le sous type MIME audio/32KADPCM est défini comme contenant des données binaires audio codées en ADPCM à 32 kbit/s exactement comme défini par la Recommandation UIT-T G.726. Aucune information d'en-tête ne devra être incluse au titre des données audio. Le codage de transfert de contenu est normalement soit binaire, soit base64.

Une considération supplémentaire que définit le présent document à titre de précision est le choix de l'ordre petit boutien des codets de quatre bits. Cet ordre par défaut est défini dans la Recommandation UIT-T X.420 [X420] pour la partie de corps X.400 équivalente, mais il est aussi précisé ci-dessous dans l'enregistrement de l'IANA.

Le sous type audio/32KADPCM est un composant principal de la spécification VPIM [RFC3801]. Dans ce contexte, les en-têtes Content-Description et Content-Disposition sont utilisés pour décrire de façon succincte le contenu du corps audio. De ce fait, seul l'ordre petit boutien est valide. Voir dans la spécification VPIM l'usage approprié.

Considérations de codage : préférence générale pour le binaire ou le base-64

Considérations de sécurité : Il n'y a pas de risque de sécurité connu avec l'envoi ou l'exécution de données audio brutes. Les données audio ne sont normalement interprétées que par un codec audio. Les informations non prévues introduites dans le flux de données vont résulter en un bruit.

Considérations d'interopérabilité : L'ordre des codets de quatre bits au sein d'un octet peut différer slon les mises en œuvre existantes de codecs G.726. Comme ce contenu permet seulement l'ordre petit boutien, les codecs qui prennent en charge l'ordre opposé doivent réarrranger les codets avant de les mémoriser ou de les restituer de ce type de contenu.

Applications qui utilisenth ce type de support : Principalement la messagerie vocale

Ordre petit boutien : Les codets de 4 bits du codage G.726 DOIVENT être groupés en octets comme suit : le premier codet (A) est placé dans les quatre bits de moindre poids du premier octet, avec le bit de moindre poids (LSB, least significant bit) du codet (A0) dans le bit de moindre poids de l'octet ; le second codet (B) est placé dans les quatre bits de poids fort du premier octet, avec le bit de poids fort (MSB, most significant bit) du codet (B3) dans le bit de poids fort de l'octet. Les paires suivantes de codets devront être groupées de la même façon dans les octets successifs, avec le premier codet de chaque paire placé dans les quatre bits de moindre poids de l'octet. On préfère que l'échantillon vocal soit étendu avec du silence afin sue la valeur codée comporte un nombre pair de codets. Cependant, si l'échantillon vocal comporte un nombre impair de codets, le dernier codet devra être éliminé.

Adresse personnelle & de messagerie à contacter pour plus d'informations : Glenn W. Parsons gparsons@NortelNetworks.com

Il n'y a pas de risque pour la sécurité connu à l'envoi ou l'exécution de donénes audio brutes. Les données audio ne sont normalement interprétées que par un codec audio. Les informations non prévues introduites dans le flux de données cont résulter en un bruit.

[G726] Recommandation UIT-T G.726 (1990), "Aspects généraux des systèmes de transmission numérique, équipement terminal – modulation par impulsions et codage adaptative à 40, 32, 24, 16 kbit/s (ADPCM)".

[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[RFC3801] G. Vaudreuil, G. Parsons, "Profil vocal pour la messagerie Internet - version 2 (VPIMv2)", juin 2004. (D.S.)

[RFC1911] G. Vaudreuil, "Profil vocal pour la messagerie Internet", février 1996. (Obsolète, voir RFC2421, RFC2422, RFC2423) (Expérimentale)

[RFC2421] G. Vaudreuil, G. Parsons, "Profil vocal pour la messagerie Internet - version 2", septembre 1998. (Obsolète, voir RFC3801) (P.S.)

[RFC3023] M. Murata, S. St.Laurent et D. Kohn, "Types de support XML", janvier 2001. (Obsolète, voir RFC7303)

[X420] Recommandation UIT-T X.420 (1996) - ISO/CEI 10021-7:1996, "Systèmes de traitement de message : messagerie inter personnelle".

Seuls des changements rédactionnels et de présentation ont été apportés à la RFC 2422 pour faire le présent document.

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci-encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP 78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur le répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf- ipr@ietf.org .

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.

Groupe de travail Réseau	G. Vaudreuil, Lucent Technologies
Request for Comments : 3802	G. Parsons, Nortel Networks
RFC rendue obsolète : 2422	juin 2004
Catégorie : En cours de normalisation	Traduction Claude Brière de L'Isle

Gregory M. Vaudreuil	Glenn W. Parsons
Lucent Technologies	Nortel Networks
7291 Williamson Rd	P.O. Box 3511, Station C
Dallas, TX 75214	Ottawa, ON K1Y 4H7
United States	Canada
mél : gregv@ieee.org	mél : gparsons@nortelnetworks.com