Charge utile du protocole de transport en temps réel (RTP)
pour le bruit de confort (CN)

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 l'errata n° 285)

Déclaration de copyright

Copyright (C) The Internet Society (2002). Tous droits réservés

Résumé

Le présent document décrit un format de charge utile du protocole de transport en temps réel (RTP, Real-time Transport Protocol) pour transporter le bruit de confort (CN, comfort noise). Le type de charge utile CN est principalement destiné à être utilisé avec les codecs audio qui ne prennent pas en charge le bruit de confort au titre du codec lui-même comme ceux des Recommandations UIT-T G.711, G.726, G.727, G.728 et G.722.

1.   Conventions utilisées dans ce document

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 ma RFC 2119 [7].

2.   Introduction

Le présent document décrit un format de charge utile RTP [1] pour le transport du bruit de confort. Le format de charge utile se fonde sur l'Appendice II de la Recommandation UIT-T G.711 [8] qui définit un format de charge utile de bruit de confort (ou flux binaire) pour l'usage des systèmes de communication multimédia fondés sur le paquet selon la Recommandation UIT-T G.711 [2]. Le format de charge utile est générique et peut aussi être utilisé avec d'autres codecs audio sans capacités de transmission discontinue (DTX, Discontinuous Transmission) incorporée comme ceux des Recommandations UIT-T G.726 [3], G.727 [4], G.728 [5] et G.722 [6]. Le format de charge utile fournit une spécification d'inter fonctionnement minimum pour la communication des paramètres de bruit de confort. L'analyse et la synthèse du bruit de confort aussi bien que les algorithmes de détection d'activité vocale (VAD, Voice Activity Detection) et de DTX ne sont pas spécifiées et laissées à la discrétion de la mise en œuvre.

Cependant, un exemple de solution pour G.711 a été essayé et est décrit dans l'Appendice [8]. Il utilise la VAD et la DTX de l'Annexe B de la Recommandation UIT-T G.729 [9] et un algorithme de génération de bruit de confort (CNG, comfort noise generation) qui est fourni pour information en annexe

La charge utile de bruit de confort, qui est aussi appelée une trame de descripteur d'insertion de silence (SID, Silence Insertion Descriptor) consiste la description d'un seul octet du niveau de bruit et PEUT contenir des informations spectrales dans les octets suivants. Une version antérieure du format de charge utile CN comportant seulement l'octet de niveau de bruit était définie dans les projets de révision de la RFC 1890. Le format de charge utile étendu défini dans le présent document devrait être rétro compatible avec les mises en œuvre de la version antérieure en supposant que seul le premier octet est interprété et que tous les octets d'information spectrale sont ignorés.

3.   Définition de charge utile CN

La charge utile de bruit de confort consiste en une description du niveau de bruit et les informations spectrales sous la forme de coefficients de réflexion pour un modèle tous pôles du bruit. L'inclusion des informations spectrales est FACULTATIVE et l'ordre du modèle n'est pas spécifié (le nombre des coefficients). Le codeur peut choisir un ordre de modèle approprié sur la base de considérations telles que la qualité, la complexité, le bruit environnemental espéré, et la bande passante du signal. L'ordre du modèle n'est pas transmis explicitement dans la mesure où le nombre des coefficients peut être déduit de la longueur de la charge utile chez le receveur. Le décodeur peut réduire l'ordre du modèle en établissant des coefficients de réflexion d'ordre plus élevé à zéro si c'est souhaité pour réduire la complexité ou pour d'autres raisons.

3.1   Niveau de bruit

L'ampleur du niveau de bruit est mise en paquet dans les bits de moindre poids de l'octet de niveau de bruit dont le bit de poids fort reste inutilisé et est toujours réglé à 0 comme montré à la Figure 1 ci-dessous. Le bit de moindre poids de l'ampleur du niveau de bruit est mis en paquet dans le bit de moindre poids de l'octet.

Le niveau de bruit est exprimé en -dBov, avec des valeurs de 0 à 127 qui représentent 0 à -127 dBov. dBov est le niveau par rapport à la surcharge du système. (Note : La représentation par rapport au point de surcharge d'un système est particulièrement utile pour les mises en œuvre numériques, car on n'a pas besoin de connaître la calibration relative d'un circuit analogique.) Par exemple, dans le cas d'un système à loi µ, la référence serait un signal carré avec les valeurs
+/- 8031, et ce signal carré représente 0 dBov. Cela se traduit par 6,18 dBm0.

                                                                     0 1 2 3 4 5 6 7

                                                                    +-+-+-+-+-+-+-+-+

                                                                    |0|   niveau    |

                                                                    +-+-+-+-+-+-+-+-+

Figure 1 : Mise en paquet du niveau de bruit

3.2   Informations spectrales

Les informations spectrales sont transmises en utilisant des coefficients de réflexion [8]. Chaque coefficient de réflexion peut avoir des valeurs entre -1 et 1 et est quantifié de façon uniforme sur 8 bits. La valeur quantifiée est représentée par l'indice N à 8 bits, où N=0..,254, et l'indice N=255 est réservé pour une utilisation future. Chaque indice N est mis en paquet dans un octet distinct avec le bit de poids fort (MSB) en premier. La valeur quantifiée de chaque coefficient de réflexion, k i, peut être obtenue à partir de l'indice correspondant à l'aide de :

k_ i(N_ i) = 258*(N_i-127)/32 768   pour N_i = 0...254 ; -1 < k_ i < 1

3.3   Mise en paquet de la charge utile

Le premier octet de la charge utile DOIT contenir le niveau de bruit comme indiqué à la Figure 1. Les coefficients de réflexion quantifiés sont mis en paquet dans les octets suivants en ordre croissant comme dans la Figure 2 où M est l'ordre du modèle. La longueur totale de la charge utile est M+1 octets. Noter qu'un modèle d'ordre 0 (c'est-à-dire pas d'information d'enveloppe spectrale) revient à ne transmettre que le niveau d'énergie.

                                                    Octet      1     2       3     ...    M+1

                                                            +------+------+------+------+------+

                                                            |niveau|   N1 |   N2 |  ... |   NM |

                                                            +------+------+------+------+------+

Figure 2 : Format de mise en paquet de la charge utile CN

4.   Utilisation de RTP

L'en-tête RTP pour le paquet de bruit de confort DEVRAIT être construit comme si le bruit de confort était un codec indépendant. Et donc, l'horodatage RTP désigne le début de la période de bruit de confort. Lorsque ce format de charge utile est utilisé sous le profil RTP spécifié dans la RFC 1890 [10], un type de charge utile statique de 13 est alloué au débit d'horloge de l'horodatage RTP de 8 000 Hz ; si d'autres taux sont nécessaires, ils DOIVENT être définis à travers de types dynamiques de charge utile. Le paquet RTP NE DEVRAIT PAS avoir le bit marqueur mis.

Chaque paquet RTP contenant du bruit de confort DOIT contenir exactement une charge utile CN par canal. Ceci est exigé parce que la charge utile CN est de longueur variable. Si plusieurs canaux audio sont utilisés, chaque canal DOIT utiliser le même ordre de modèle spectral 'M'.

5.   Lignes directrices pour l'utilisation

Un codec audio avec des capacités de DTX comporte généralement des algorithmes de VAD, DTX et CNG. La tâche de VAD est de différencier les segments de voix actifs et inactifs dans le signal entrant. Durant les segments vocaux inactifs, le rôle de la CNG est de suffisamment décrire le bruit ambiant tout en minimisant le taux de transmission. Une charge utile CN (ou une trame SID) qui contient une description du bruit est envoyée au receveur pour piloter le CNG. L'algorithme de DTX détermine quand une charge utile CN est transmise. Durant les segments vocaux actifs, les paquets du codec vocal sont transmis et indiqués dans l'en-tête RTP par le type de charge utile statique ou dynamique pour ce codec. Au début d'un segment de voix inactif (période de silence) un paquet CN est transmis dans le même flux RTP et est indiqué par le type de charge utile CN. Le taux de mise à jour de paquet CN est laissé à la discrétion de la mise en œuvre. Par exemple, le paquet CN peut être envoyé périodiquement ou seulement lorsque il y a un changement significatif des caractéristiques du bruit de fond. L'algorithme CNG chez le receveur utilise les informations de la charge utile CN pour mettre à jour son modèle de génération de bruit et produit alors une quantité appropriée de bruit de confort.

Le format de charge utile CN fournit une spécification minimum d'interopérabilité pour la communication des paramètres de bruit de confort. L'analyse et la synthèse du bruit de confort ainsi que des algorithmes de VAD et de DTX ne sont pas spécifiés et laissés à la discrétion de la mise en œuvre. Cependant, un exemple de solution pour G.711 a été vérifié et est décrit à l'Appendice II de la Recommandation UIT-T G.711 [8]. Il utilise l'algorithme VAD et DTX de l'annexe B de G.729 [9] et un algorithme de génération de bruit de confort (CNG), qui est fourni dans l'Appendice pour information. Des lignes directrices d'utilisation supplémentaires comme les facteurs qui affectent les performances système dans la conception des algorithmes VAD/DTX/CNG sont décrits dans l'Appendice [8].

5.1   Utilisation de SDP

Lorsque on utilise le protocole de description de session (SDP, Session Description Protocol) [11] pour spécifier des informations de charge utile RTP, l'utilisation du bruit de confort est indiquée par l'inclusion d'un type de charge utile pour CN sur la ligne de description du support. Lorsque on utilisé CN avec le profil RTP/AVP [10] et un codec dont le débit d'horloge d'horodatage RTP est de 8000 Hz, tel que G.711 (MICU, type de charge utile statique 0), le type de charge utile statique 13 pour CN peut être utilisé :

m=audio 49230 RTP/AVP 0 13

Lorsque on utilise CN avec un codec qui a un débit d'horloge d'horodatage RTP différent, une transposition de type de charge utile dynamique (attribut rtpmap) est requis.

Cet exemple montre CN utilisé avec le codec G.722.1 (voir la RFC 3047 [12]):

m=audio 49230 RTP/AVP 101 102

a=rtpmap:101 G7221/16000

a=fmtp:101 bitrate=24000

a=rtpmap:102 CN/16000

L'omission d'un type de charge utile pour CN sur la ligne de description du support implique que ce format de charge utile de bruit de confort ne sera pas utilisé, mais elle n'implique pas que le silence ne sera pas supprimé. RTP permet la transmission discontinue (suppression du silence) sur tout format de charge utile audio. Le receveur peut détecter la suppression de silence sur le premier paquet reçu après le silence en observant que l'horodatage RTP n'est pas contigu avec la fin de l'intervalle couvert par le paquet précédant m^me si le numéro de séquence RTP a été seulement incrémenté de un. Le bit marqueur RTP est aussi normalement mis à un sur un tel paquet.

6.   Considérations relatives à l'IANA

Cette section définit un nouveau nom de charge utile RTP et le type MIME associé, CN (audio/CN). Le format de charge utile spécifié dans le présent document est aussi le type de charge utile 13 alloué dans le tableau des types de charge utile RTP du registre des paramètres RTP tenu par l'Autorité d'allocation des numéros de l'Internet (IANA).

6.1   Enregistrement du type de support MIME audio/CN

Nom du type de support MIME : audio

Nom de sous-type MIME : CN

Paramètres exigés : Aucun

Paramètres facultatifs :

débit : spécifie le débit d'horloge de l'horodatage RTP, qui est normalement (mais pas toujours) égal au taux d'échantillonnage. Ce paramètre devrait avoir la même valeur que le codec utilisé en conjonction avec le bruit de confort. La valeur par défaut est 8000.

Considérations pour le codage :

Ce type n'est défini que pour le transfert via RTP [RFC 1889].

Considérations pour la sécurité : voir la Section 7 "Considérations pour la sécurité".

Considérations d'interopérabilité : aucune

Spécification publiée :

Le présent document et l'Appendice II de la Recommandation UIT-T G.711.

Applications qui utilisent ce type de support :

Outils de reproduction de flux audio et vidéo et de conférences.

Informations supplémentaires : aucune

Adresse électronique de la personne à contacter pour des informations complémentaires :

Robert Zopf

zopf@lucent.com

usage prévu : commun

Auteur/contrôleur des modifications :

Auteur : Robert Zopf

Contrôleur des modifications : groupe de travail AVT de l'IETF.

7.   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 sur la sécurité exposées dans la spécification RTP [1]. Cela implique que la confidentialité des flux de support est réalisée par le chiffrement. Comme le format de charge utile est réalisé de bout en bout, le chiffrement PEUT être effectué après encapsulation de sorte qu'il n'y a pas de conflit entre les deux opérations.

Comme ce format transporte le bruit de fond, l n'y a pas de problème significatif de sécurité, confidentialité ou d'authentification.

8.   Références

(Les liens hypertexte pointent sur les traductions françaises)

[1]   H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson, "RTP : protocole de transport pour applications en temps réel", RFC1889, janvier 1996. (rendue obsolète par la RFC 3550)

[2]   Recommandation UIT-T G.711 (11/88) "Modulation par impulsions codées (MIC) des fréquences vocales".

[3]   Recommandation UIT-T G.726 (12/90) "Modulation par impulsions codées différentielles adaptatives (ADPCM) à 40, 32, 24, 16 kbit/s".

[4]   Recommandation UIT-TG.727 (12/90) "Modulation par impulsions codées différentielles adaptatives (ADPCM) à 5-, 4-, 3- et 2 -bits d'échantillon incorporé"

[5]   Recommandation UIT-T G.728 (09/92) "Codage de la parole à 16 kbit/s utilisant la prédiction linéaire par code à faible retard".

[6]   Recommandation UIT-T G.722 (11/88) "Codage audio à 7 kHz dans les 64 kbit/s.

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

[8]   Appendice II à la Recommandation UIT-T G.711 (02/2000) "Définition de charge utile de bruit de confort pour la Recommandation UIT-T G.711 dans les systèmes de communication multimédia fondés sur le paquet".

[9]   Annexe B (08/97) à la Recommandation UIT-T G.729 "Code source C et vecteurs d'essais pour la vérification de la mise en œuvre de l'algorithme du schéma de compression de silence de la Recommandation G.729".

[10]   H. Schulzrinne, "Profil RTP pour conférences audio et vidéo avec contrôle minimal", RFC1890, janvier 1996. (Obsolète, voirRFC3551) (P.S.)

[11]   M. Handley et V. Jacobson, "SDP : Protocole de description de session", RFC2327, avril 1998.

[12]   P. Luthi, "Format de charge utile RTP pour la Recommandation UIT-T G.722.1", RFC3047, janvier 2001. (Remplacée par la RFC 5577. P.S.)

9.   Adresse de l'auteur

Robert Zopf

Lucent Technologies

INS Access VoIP Networks

2G-234A

101 Crawfords Corner Rd

Holmdel, NJ 07733-3030

USA

téléphone : 1-732-949-1667

Fax : 1-732-949-7016

mél : zopf@lucent.com

10.   Déclaration complète de copyright

Copyright (C) The Internet Society (2003). Tous droits réservés

Le présent document et les informations y contenues sont fournies 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.

Remerciement

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