Groupe de travail Réseau	M. Westerlund, Ericsson AB
Request for Comments : 5404	I. Johansson, Ericsson AB
Catégorie : Sur la voie de la normalisation	
Traduction Claude Brière de L'Isle	janvier 2009

Format de charge utile RTP pour G.719

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. Les composants de code extraits du présent document doivent inclure le texte de licence simplifié de BSD comme décrit au paragraphe 4.e des dispositions légales du Trust et sont fournis sans garantie comme décrit dans la licence de BSD simplifiée.

Résumé
Le présent document spécifie le format de charge utile pour la mise en paquets des signaux audio codés par un codec pleine bande G.719 dans le protocole de transport en temps réel (RTP, Real-time Transport Protocol). Le format de charge utile prend en charge la transmission de plusieurs canaux, de plusieurs trames par charge utile, et l’entrelaçage.
Table des matières
1. Introduction	2
2. Définitions et conventions	2
3. Description de G.719	2
4. Capacités de format  de charge utile	3
4.1 Codage multi-débit et adaptation de débit	3
4.2 Prise en charge de sessions multi-canaux	3
4.3 Robustesse contre la perte de paquets	3
5. Format de charge utile	4
5.1 Usage de l’en-tête RTP	5
5.2 Structure de charge utile	5
5.3 Mode de base	6
5.4 Mode entrelacé	6
5.5 Données audio	7
5.6 Considérations de mise en œuvre	7
6. Exemples de charge utile	8
6.1 Trois mono-trames avec deux débits binaires différents	8
6.2 Deux blocs-trame stéréo de même débit binaire	8
6.3 Quatre mono trames entrelacées	9
7. Paramètres de format  de charge utile	10
7.1 Définition de type de support	10
7.2 Transposition en SDP	11
8 Considérations relatives à l’IANA	13
9. Contrôle d’encombrement	13
10. Considérations sur la sécurité	14
11. Remerciements	14
12. Références	14
12.1 Références normatives	14
12.2 Références pour information	15
Adresse des auteurs	16

 	1.	Introduction

Le présent document spécifie le format de charge utile pour la mise en paquets des signaux audio codés par un codec pleine bande G.719 dans le protocole de transport en temps réel (RTP) [RFC3550]. Le format de charge utile prend en charge la transmission de plusieurs canaux, de plusieurs trames par charge utile, et de méthodes de résistance à la perte de paquet qui utilisent la redondance ou l’entrelaçage.

Le présent document commence par les conventions, une brève description du codec, et les capacités du format de charge utile. Le format de charge utile est spécifié à la Section 5. Des exemples sont donnés à la Section 6. Le type de support et ses transpositions en le protocole de description de session (SDP, Session Description Protocol) et l’usage dans  l’offre/réponse SDP sont ensuite spécifiés. Le document se termine sur des considérations concernant le contrôle d’encombrement et la sécurité.

 	2.	Définitions et conventions

Le terme "bloc de trames" est utilisé dans ce document pour décrire l’ensemble de trames audio synchronisées dans une session audio multi-canaux. En particulier, dans une session de N canaux, un bloc de trames va contenir N trames audio, une provenant de chaque canal, et toutes les N trames de parole représentent exactement la même durée.

Le présent document contient la description des champs binaires. le bit de poids fort est toujours le plus à gauche dans la figure sur chaque ligne et a le plus faible numéro. Pour les champs décrits sur plusieurs lignes, la ligne supérieure est de plus fort poids que la suivante.

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].

 	3.	Description de G.719

Le codec pleine bande UIT-T G.719 est un codec de transformation fondé sur la transformée lissée modulée (MLT, Modulated Lapped Transform). G.719 est un codec de faible complexité de pleine bande passante pour la parole conversationnelle et le codage audio. L’entrée du codeur et la sortie du décodeur sont échantillonnées à 48 kHz. Le codec permet une pleine bande passante de 20 Hz à 20 kHz, codant la parole, la musique, et les contenus audio généraux à des débits allant de 32 kbit/s jusqu’à 128 kbit/s. Le codec fonctionne sur des trames de 20 ms et a un délai algorithmique de 40  ms.

Le codec fournit une excellente qualité pour la parole, la musique, et autres types d’audio. Certaines des applications pour lesquelles ce codeur convient sont :
o	Les communications en temps réel comme la conférence vidéo et la téléphonie.
o	Les flux directs audio.
o	L’archivage et la messagerie.

L’algorithme de codage et décodage peut changer le débit binaire à toute limite de trame de 20 ms. Le codeur reçoit l’audio échantillonné à 48 kHz. La prise en charge d’autres taux d’échantillonnage est possible en ré-échantillonnant le signal d’entrée du taux d’échantillonnage du codec, c’est-à-dire, 48 kHz ; cependant, cette fonction ne fait pas partie de la norme.

Le codage est effectué sur des trames de taille égale. Pour chaque trame, le codeur décide entre deux modes de codage, un mode transitoire et un mode stationnaire. La décision se fonde sur des statistiques déduites du signal d’entrée. Le mode stationnaire utilise une longue MLT qui conduit à un spectre de 960 coefficients, tandis que le mode de codage transitoire utilise une MLT courte (transformées de résolution de temps plus élevée) qui résulte en quatre spectres (4 x 240 = 960  coefficients). Le codage du spectre est fait en deux étapes. D’abord, l’enveloppe spectrale est calculée, quantifiée, et codée selon Huffman. L’enveloppe est calculée sur une subdivision de fréquence non uniforme. À partir de l’enveloppe spectrale codée, une enveloppe spectrale pondérée est déduite et est utilisée pour l’allocation des bits ; ce processus est aussi répété au décodeur. Donc, seule l’enveloppe spectrale est transmise. Le résultat de l’allocation de bits est utilisé afin de quantifier le spectre. De plus, pour les trames stationnaires, le codeur estime la quantité de niveau de bruit. Le décodeur applique l’opération inverse à réception du flux binaire. Les coefficients non codés (c’est-à-dire, pas de bits alloués) sont remplacés par des entrées d’un répertoire de bruit qui est construit sur la base des coefficients décodés.

 	4.	Capacités de format  de charge utile

Ce format de charge utile a un certain nombre de capacités, et cette section les discute en détail.

 	4.1	Codage multi-débit et adaptation de débit
G.719 prend en charge une capacité de codage multi-débits qui permet une variation trame par trame du taux de codage. Cela permet la prise en charge de l’adaptation du débit binaire et du contrôle d’encombrement. La possibilité d’agréger plusieurs trames audio dans une seule charge utile RTP est une autre dimension de l’adaptation. Les frais généraux de RTP et du format de charge utile peuvent donc être réduits par l’agrégation au prix d’un délai accru et d’une robustesse réduite à la perte de paquet.

 	4.2	Prise en charge de sessions multi-canaux
Le format de charge utile RTP défini dans ce document prend en charge un contenu audio multi-canaux (par exemple, des sessions audio stéréophoniques ou d’ambiance). Bien que le codec G.719 lui-même ne prenne pas en charge le codage de contenu audio multi-canaux dans un seul flux binaire, il peut être utilisé pour coder et décoder séparément chaque canal individuel. Pour transporter (ou mémoriser) le contenu multi canaux codé séparément, les trames audio pour tous les canaux qui sont tramés et codés pour la même période de 20 ms sont logiquement collectées dans un "bloc de trames".

À l’établissement de session, une signalisation hors bande doit être utilisée pour indiquer le nombre de canaux dans le type de charge utile. L’ordre des trames audio au sein du bloc de trames dépend du nombre de canaux et suit la définition du paragraphe 4.1 du profil RTP/AVP [RFC3551]. Quand on utilise SDP pour la signalisation, le nombre de canaux est spécifié dans l’attribut rtpmap.

 	4.3	Robustesse contre la perte de paquets
Le format de charge utile prend en charge plusieurs moyens, incluant la correction d’erreur directe (FEC, Forward Error Correction) et l’entrelaçage de trame, pour augmenter la robustesse à la perte de paquet.

 	4.3.1	Utilisation de la correction d’erreur directe (FEC)
La correction générique d’erreur directe au sein de RTP est définie, par exemple, dans la [RFC5109]. Le codage audio redondant est défini dans la [RFC2198]. L’un ou l’autre schéma peut être utilisé pour ajouter des information redondantes au flux de paquets RTP et le rendre plus résiliant à la perte de paquet, au prix d’un débit binaire plus élevé. Voir l’une de ces RFC pour une discussion des implications du débit binaire plus élevé sur l’encombrement du réseau.

En plus de ces mécanismes ignorants du support, le présent mémoire spécifie une forme spécifique de G.719 de codage de redondance audio, qui peut être avantageuse en termes de frais généraux de mise en paquets. Conceptuellement, les trames de transport précédemment transmises sont agrégées avec les nouvelles. Une fenêtre glissante peut être utilisée pour grouper les trames à envoyer dans chaque charge utile. Cependant, des schémas irréguliers ou non consécutifs sont aussi possibles en insérant des trames NO_DATA entre les transmissions primaires et redondantes. La Figure 1 en montre un exemple.

   --+--------+--------+--------+--------+--------+--------+--------+--
     | f(n-2) | f(n-1) |  f(n)  | f(n+1) | f(n+2) | f(n+3) | f(n+4) |
   --+--------+--------+--------+--------+--------+--------+--------+--
      <---- p(n-1) ---->
               <----- p(n) ----->
                        <---- p(n+1) ---->
                                 <---- p(n+2) ---->
                                          <---- p(n+3) ---->
                                                   <---- p(n+4) ---->

Figure 1 : Exemple de transmission redondante

Ici, chaque trame est retransmise une fois dans le paquet de charge utile RTP suivant. f(n-2)...f(n+4) note une séquence de trames audio, et p(n-1)...p(n+4) une séquence de paquets de charge utile.

Le mécanisme décrit n’exige pas réellement de signalisation à l’établissement de la session. Cependant, la signalisation a été définie pour permettre à l’envoyeur de lier volontairement les exigences de mise en mémoire tampon et de délai. Si rien n’est signalé, l’utilisation de ce mécanisme est permise et non limitée. Pour un certain horodatage, le receveur peut recevoir plusieurs copies d’une trame contenant des données audio codées, même à des taux de codage différents. Le coût de ce schéma est de la bande passante et le délai pour le receveur nécessaire pour permettre à la copie redondante d’arriver.

Ce schéma de redondance donne une fonctionnalité similaire à celle décrite dans la RFC 2198, mais qui ne fonctionne que si les deux représentations de trames originales et redondantes sont des trames G.719. Quand l’utilisation d’autres schémas de codage de support est désirable, on doit se rabattre sur la RFC 2198.

L’envoyeur est chargé de choisir une quantité appropriée de redondance sur la base des retours sur les conditions du canal, par exemple, dans les rapports de receveur du protocole de contrôle RTP (RTCP, RTP Control Protocol) [RFC3550]. L’envoyeur est aussi chargé d’éviter l’encombrement, qui peut être exacerbé par la redondance (voir les détails à la Section  9).

 	4.3.2	Utilisation de l’entrelaçage de trame
Pour diminuer les frais généraux du protocole, la conception de la charge utile permet que plusieurs trames de transport audio soient encapsulées dans un seul paquet RTP. Un des inconvénients d’une telle approche est que dans le cas de perte de paquet, plusieurs trames consécutives sont perdues. La perte de trames consécutives rend normalement la dissimulation des erreurs moins efficace et cause généralement des distorsions clairement audibles et perturbantes dans l’audio reconstruit. L’entrelaçage des trames de transport peut améliorer la qualité audio dans ces cas en répartissant les pertes consécutives sur un certain nombre de pertes de trames isolées, ce qui est plus facile à dissimuler.

Cependant, l’entrelaçage et le regroupement de plusieurs trames par charge utile augmente aussi le délai de bout en bout et impose des exigences plus élevées de mise en mémoire tampon. Donc, l’entrelaçage n’est pas approprié pour tous les cas d’utilisation ou tous les appareils. Les applications de flux directs devraient très probablement être capables d’exploiter l’entrelaçage pour améliorer la qualité audio dans des conditions de transmission enclines à la perte.

Noter que cette conception de charge utile prend en charge l’utilisation de l’entrelaçage de trame comme une option. L’usage de cette caractéristique doit être négocié à l’établissement de la session.

L’entrelaçage pris en charge par ce format est assez souple. Par exemple, un schéma continu peut être défini, comme décrit à la Figure 2.

   --+--------+--------+--------+--------+--------+--------+--------+--
     | f(n-2) | f(n-1) |  f(n)  | f(n+1) | f(n+2) | f(n+3) | f(n+4) |
   --+--------+--------+--------+--------+--------+--------+--------+--
              [ p(n)   ]
     [ p(n+1) ]                 [ p(n+1) ]
                       [ p(n+2) ]                 [ p(n+2) ]
                                         [ p(n+3) ]
                                                           [ p(n+4) ]

Figure 2 : Exemple de schéma d’entrelaçage avec délai constant

Dans la Figure 2, les trames consécutives, notées f(n-2) à f(n+4) sont agrégées en paquets p(n) à p(n+4), chaque paquet portant deux trames. Cette approche donne un schéma d’entrelaçage qui permet un délai constant dans les deux processus d’entrelaçage et de désentrelaçage. La mémoire tampon de désentrelaçage a besoin de place pour au moins trois trames, incluant celle qui est prête à être consommée. L’espace de mémorisation pour trois trames est nécessaire, par exemple, quand f(n) est la prochaine trame à décoder : comme la trame f(n) a été reçue dans le paquet p(n+2), qui portait aussi la trame f(n+3) ces deux trames sont mémorisées dans la mémoire tampon. De plus, la trame f(n+1) reçue dans le paquet précédent, p(n+1), est aussi dans la mémoire tampon de désentrelaçage. Noter aussi que dans cet exemple, l’occupation de la mémoire tampon varie : quand la trame f(n+1) est la prochaine à décoder, il y a seulement deux trames, f(n+1) et f(n+3) dans la mémoire tampon.

 	5.	Format de charge utile

Le principal objet de la conception de charge utile pour G.719 est de maximiser le potentiel du codec à son plus haut degré avec le minimum de frais généraux possible. Dans la conception, les deux modes de base et d’entrelaçage ont été inclus, car le codec convient à la fois pour les applications de conversation et autres à faible délai et pour celles en flux directs, où plus de délai est acceptable.

La principale différence structurelle entre le mode de base et le mode entrelacé est l’extension du tableau des entrées de contenus avec des champs de déplacement de trame dans le mode entrelacé. Le mode de base prend en charge l’agrégation de plusieurs trames consécutives dans une charge utile. Le mode entrelacé prend en charge l’agrégation de plusieurs trames qui ne sont pas consécutives dans le temps. Dans les deux modes, il est possible d’avoir des trames codées avec des types de trame différents dans la même charge utile.

Le format de charge utile prend aussi en charge l’usage de G.719 pour porter du contenu multi-canaux en utilisant un codeur discret par canaux utilisant tous le même débit binaire. Dans ce cas, un bloc de trames complet avec des données provenant de tous les canaux est inclus dans la charge utile RTP. Les données sont l’enchaînement de toutes les trames audio données dans l’ordre spécifié pour ce nombre de canaux inclus. Aussi, l’entrelaçage est fait sur des blocs de trames complets plutôt que sur les trames audio individuelles.

 	5.1	Usage de l’en-tête RTP
L’horodatage RTP  correspond à l’instant d’échantillonnage du premier échantillon codé pour le premier bloc de trames du paquet. La fréquence d’horloge de l’horodatage DEVRA être 48  000 Hz. L’horodatage est aussi utilisé pour récupérer l’ordre de décodage correct des blocs de trames.

Le bit marqueur de l’en-tête RTP (M) DEVRA être réglé à 1 chaque fois que le premier bloc de trames porté dans le paquet est le premier bloc de trames d’une salve de parole (voir la définition de la salve de parole au paragraphe 4.1 de la [RFC3551]). Pour tous les autres paquets, le bit marqueur DEVRA être réglé à zéro (M=0).

L’allocation d’un type de charge utile RTP pour le format défini dans le présent mémoire sort du domaine d’application de ce document. Les profils RTP actuellement utilisés rendent obligatoire de lier dynamiquement le type de charge utile pour ce format de charge utile. Ceci est fondamentalement nécessaire parce que le type de charge utile exprime la configuration de la charge utile elle-même, c'est-à-dire, le mode de base ou entrelacé, et le nombre de canaux portés.

Le reste des champs d’en-tête RTP est utilisé comme spécifié dans la [RFC3550].

 	5.2	Structure de charge utile
La charge utile consiste en une ou plusieurs entrées de tableau de contenu (ToC) suivies par les données audio correspondant aux entrées de ToC. Les paragraphes qui suivent décrivent les deux modes de base et d’entrelacement. Chaque entrée de ToC DOIT être bourrée à une limite d’octet pour assurer l’alignement sur l’octet. Les règles concernant la taille de charge utile maximum donnée au paragraphe 3.2 de la [RFC5405] DEVRAIENT être suivies.

 	5.2.1	Élément ToC de base
Tous les différents formats et modes de ce document utilisent un ToC de base commun qui peut être étendu dans les différentes options décrites ci-dessous.

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F|    L    |R|R|
+-+---------+-+-+

Figure 3 : Élément ToC de base

F (1 bit) : réglé à 1, il indique que cette entrée de ToC est suivie par une autre entrée de ToC ; si il est réglé à zéro, cela indique que cette entrée de ToC est la dernière du ToC.

L (5 bits) : champ qui donne la longueur de trame de chaque trame individuelle dans le bloc de trames.

L	Longueur (en octets)
0	0 NO_DATA
1-7	N/A (réservé)
8-22	80 + 10*(L-8)
23-27	240 + 20*(L-23)
28-31	N/A (réservé)

Figure 4 : Comment transposer les valeurs L en longueur de trame

L=0 (NO_DATA) est utilisé pour indiquer une trame vide, ce qui est utile si des trames manquent (par exemple, à la remise en paquets) ou pour insérer des trous lors de l'envoi de trames redondantes avec des trames principales dans la même charge utile. Les gammes de valeurs [1 à 7] et [28 à 31] inclus sont réservées pour une utilisation future dans cette version du document ; si ces valeurs se produisent dans un ToC, le paquet entier DEVRAIT être traité comme invalide et éliminé. Quelques exemples sont donnés ci-dessous où la taille de trame et le débit binaire de codec correspondant sont calculés sur la base de la valeur L.

L	Octets	Débit du codec (kbit/s)
8	80	32
9	90	36
10	100	40
12	120	48
16	160	64
22	220	88
23	240	96
25	280	112
27	320	128

Figure 5 : Exemples de valeurs de L et longueurs de trame correspondantes

Ce codage donne une granularité de 4 kbit/s entre 32 et 88 kbit/s et une granularité de 8 kbit/s entre 88 et 128 kbit/s avec une gamme définie de 32 à 128 kbit/s pour les données du codec.

R (2 bits) : bits réservés. DEVRA être réglé à zéro à l'envoi et DEVRA être ignoré à réception.

 	5.3	Mode de base
L'élément ToC de base montré à la Figure 3 est suivi d'un champ d'un octet pour le nombre de clics de trames (#trames) pour former l'entrée de ToC. Le champ Blocs de trame dit à combien de blocs de trames de la même longueur l'entrée de ToC se rapporte.

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|    #trames    |
+---------------+
Figure 6 : Champ Nombre de blocs de trames

 	5.4	Mode entrelacé
Le ToC de base est suivi d'un champ d'un octet pour le nombre de blocs de trames (#trames) et ensuite du champ DIS pour former une entrée de ToC en mode entrelacé. Le champ de bloc de trames dit à combien de blocs de trames de la même longueur le ToC se rapporte. Le champ DIS, un pour chaque bloc de trames indiqué par le champ #trames, exprime la distance d'entrelaçage entre les trames audio portées dans la charge utile. Si c'est nécessaire pour réaliser l'alignement sur l'octet, un bourrage de 4 bits est ajouté.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    #trames    | DIS1  |  ...  | DISi  |  ...  | DISn  |Bourrg.|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7 : Nombre de blocs de trames + champs entrelacés

DIS1...DISn (4 bits) :  une liste de n (n=#trames) champs de déplacement indiquant le déplacement du i:ème (i=1..n) bloc de trames audio par rapport au bloc de trames précédant dans la charge utile, en unités de blocs de trame audio de 20 ms de long). Les valeurs de déplacement d'entier non signé de 4 bits peuvent être entre zéro et 15, indiquant le nombre de blocs de trames audio dans l'ordre du décodage entre la (i-1):ème et la i:ème trame dans la charge utile. Noter que la première entrée de ToC de la charge utile, la valeur de DIS1, n'a pas de signification. Elle DEVRA être réglée à zéro par un envoyeur et DEVRA être ignorée par un receveur. La localisation de ce bloc de trames dans l'ordre de décodage est uniquement définie par l'horodatage RTP. Noter que pour les entrées de ToC suivantes DIS1 indique le nombre de trames entre la dernière trame du groupe précédent et la première trame de ce groupe.

Bourrage (4 bits) : pour assurer l'alignement sur l'octet, quatre bits de bourrage DEVRONT être inclus à la fin de l'entrée de ToC au cas où il y aurait un nombre impair de blocs de trames dans le groupe référencé par cette entrée de ToC. Ces bits DEVRONT être réglés à zéro et DEVRONT être ignorés par le receveur. Si un groupe contenant un nombre pair de trames est référencé par cette entrée de ToC, ces bits de bourrages NE DEVRONT PAS être inclus dans la charge utile.

 	5.5	Données audio
La partie données audio suit le tableau des contenus. Tous les octets constituant une trame audio DEVRONT être ajoutés à la charge utile comme une unité. Pour chaque bloc de trames, les trames audio sont enchaînées dans l'ordre indiqué par le tableau du paragraphe 4.1 de la [RFC3551] pour le nombre de canaux configurés pour le type de charge utilisée. Ainsi le premier canal (le plus à gauche) indiqué vient en premier suivi par le canal suivant. Les blocs de trames audio sont mis en paquets en ordre d'horodatage croissant au sein de chaque groupe de blocs de trames (par entrée de ToC) c'est-à-dire, le plus vieux bloc de trames en premier. Les groupes de blocs de trames sont mis en paquets dans le même ordre que leurs entrées de ToC correspondantes.

Les trames audio sont spécifiées dans la Recommandation UIT-T [G.719].

Le flux binaire G.719 est partagé en une séquence d'octets et transmis dans l'ordre du bit de gauche (de poids fort (MSB, most significant bit)) au bit de droite (le bit de moindre poids (LSB, least significant bit)).

 	5.6	Considérations de mise en œuvre
Une application qui met en œuvre ce format de charge utile DOIT comprendre tous les paramètres de charge utile spécifiés dans le présent mémoire. Toute transposition des paramètres dans un protocole de signalisation DOIT prendre en charge tous les paramètres. Donc une mise en œuvre de ce format de charge utile dans une application utilisant SDP est obligée de comprendre tous les paramètres de charge utile dans leur forme transposée en SDP. Cette exigence assure qu'une mise en œuvre peut toujours décider si elle est capable de communiquer quand les entités communicantes prennent en charge cette version de la spécification.

Le mode de base DEVRA être mis en œuvre et le mode entrelacé DEVRAIT être mis en œuvre. La charge de mise en œuvre des deux est assez faible, et la prise en charge des deux assure l'interopérabilité. Cependant, l'entrelaçage n'est pas obligatoire car il a une applicabilité limitée pour les applications de conversation qui exigent des limites de délai srtictes.

 	5.6.1	Réception de trames redondantes
La réception de trames audio redondantes, c'est-à-dire, plus d'une trame audio provenant de la même source pour le même intervalle de temps, DOIT être prise en charge par la mise en œuvre. Dans le cas où le receveur obtient plusieurs trames audio dans différents débits binaires pour le même intervalle de temps, il est RECOMMANDÉ que le receveur garde celui qui a le plus fort débit binaire.

 	5.6.2	Entrelaçage
L'utilisation de l'entrelaçage exige un examen plus poussé. Comme il est présenté dans l'exemple du paragraphe 4.3.2, un schéma d'entrelaçage donné exige une certaine quantité de mémoire tampon de désentrelaçage. Cet espace de mémoire tampon, exprimé en nombre d'intervalles de trames de transport, est indiqué par le paramètre de type de support "entrelaçage". Le nombre d'intervalles de trames nécessaire peut être converti en les exigences réelles de mémoire en prenant 320 octets par trame utilisés par le plus fort débit binaire de G.719.

Les informations sur la taille de mémoire tampon de trame ne sont pas toujours suffisantes pour déterminer quand il est approprié de commencer à consommer les trames provenant de la mémoire tampon d'entrelaçage. Des informations supplémentaires sont nécessaires quand le schéma d'entrelaçage change. Le paramètre de type de support "int-delay" est défini pour porter cette information. Il permet à un envoyeur d'indiquer le temps minimal de support qui doit être présent dans la mémoire tampon avant que le décodeur puisse commencer à consommer les trames de la mémoire tampon. Comme l'envoyeur a le plein contrôle du schéma d'entrelaçage, il peut calculer cette valeur. Dans certains cas (par exemple, si il se joint à une session de diffusion groupée avec entrelaçage à mi session) un receveur peut initialement recevoir seulement une partie des paquets dans le schéma d'entrelaçage. Cette réception initiale partielle (dans l'ordre de la séquence de trames) des trames peut donner trop peu de trames pour une qualité acceptable du décodage audio. Ce problème survient aussi quand on utilise le chiffrement pour le contrôle d'accès, et le receveur n'a pas la clé précédente. Bien que G.719 soit robuste et donc tolérant à un taux élevé d'écrasement de trames aléatoire, il aurait des difficultés à traiter des pertes consécutives de trames au démarrage. Donc, des considérations de mise en œuvre particulières sont décrites.

Afin de traiter efficacement ce type de démarrage, le décodage peut commencer pourvu que :
1.	Il y ait au moins deux trames consécutives disponibles.
2.	Au moins la moitié des trames soient disponibles dans la période entre le moment où le début du décodage était prévu et le décodage reçu le plus avancé.

Après la réception d'un certain nombre de paquets, dans le pire des cas, autant de paquets que couvre le schéma d'entrelaçage, les effets précédemment décrits disparaissent et le décodage normal reprend. Des problèmes similaires apparaissent quand un receveur quitte une session ou a perdu l'accès au flux. Si le receveur quitte la session, cela va poser un problème mineur car l'affichage est normalement arrêté. L'envoyeur peut éviter ce type de problème dans de nombreuses sessions en commençant et terminant les schémas d'entrelaçage correctement quand apparaissent des risques de pertes. Un exemple est un changement de clé fait pour le contrôle d'accès à des flux chiffrés. Si seulement quelques clés sont fournies aux clients et qu'il y a un risque qu'ils reçoivent du contenu pour lequel ils n'ont pas la clé, il est recommandé que les schémas d'entrelaçage ne se chevauchent pas avec les changements de clé.

 	5.6.3	Validation du  décodage
Si le receveur trouve une discordance entre la taille d'une charge utile reçue et la taille indiquée par le ToC de la charge utile, le receveur DEVRAIT éliminer le paquet. Ceci est recommandé parce que le décodage d'une trame analysée à partir d'une charge utile fondée sur des données de ToC erronées pourrait dégrader sévèrement la qualité audio.

 	6.	Exemples de charge utile

Exemples pour illustrer le format de charge utile.

 	6.1	Trois mono-trames avec deux débits binaires différents
Le premier exemple est une charge utile consistant en trois mono trames où les deux premières trames correspondent à un débit binaire de 32 kbit/s (80 octets par trame) et la dernière est de 48 kbit/s (120 octets/trame).

Les 32 premiers bits sont les champs de ToC.
Le bit 0 est "1" car d"autres champs de ToC suivent.
Les bits 1 à 5 sont "01000" = 80 octets par trame.
Les bits 8 à 15 sont "00000010" = 2 blocs de trames avec 80 octets par trame.
Le bit 16 est "0", pas d'autre ToC à suivre.
Les bits 17 à 21 sont "01100" = 120 octets/trame.
Les bits 24 à 31 sont "00000001" = 1 bloc de trames avec 120 octets/trame.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0 1 0 0 0|0 0|0 0 0 0 0 0 1 0|0|0 1 1 0 0|0 0|0 0 0 0 0 0 0 1|
+-+-------------+---------------+-+---------+---+---------------+
|d(0)   trame 1                                                 |
.                                                               .
|                                                         d(639)|
+---------------+---------------+---------------+---------------+
|d(0)   trame 2                                                 |
.                                                               .
|                                                         d(639)|
+---------------+---------------+---------------+---------------+
|d(0)   trame 3                                                 |
.                                                               .
|                                                         d(959)|
+---------------+---------------+---------------+---------------+

 	6.2	Deux blocs de trames stéréo de même débit binaire
Le second exemple est une charge utile consistant en deux trames stéréo qui correspondent à un débit binaire de 32 kbit/s (80 octets par trame) par canal. Le receveur calcule le nombre de trames dans le bloc audio en multipliant la valeur du paramètre "channels" (2) par la valeur du champ #trames (2) pour déduire qu'il y a 4 trames audio dans la charge utile.

Les 16 premiers bits sont le champ ToC.
Le bit 0 est "0" parce que aucun champ ToC ne suit.
Les bits 1 à 5 sont "01000" = 80 octets par trame.
Les bits 8 à 15 sont "00000010" = 2 blocs de trames avec 80 octets par trame.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0 1 0 0 0|0 0|0 0 0 0 0 0 1 0| d(0) trame 1 canal gauche     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+---------------+
.                                                               .
|                         d(639)| d(0) trame 1 canal droit      |
+---------------+---------------+---------------+---------------+
.                                                               .
|                         d(639)| d(0) trame 2 canal gauche     |
+---------------+---------------+---------------+---------------+
.                                                               .
|                         d(639)| d(0) trame 2 canal droit      |
+---------------+---------------+---------------+---------------+
|                         d(639)|
+---------------+---------------+

 	6.3	Quatre mono trames entrelacées
Le troisième exemple est une charge utile consistant en 4 mono trames qui correspondent à un débit binaire de 32 kbit/s (80  octets par trame) entrelacées. Un schéma d'entrelaçage pour délai constant quand on agrège 4 trames est utilisé dans l'exemple ci-dessous. Le paquet réel illustré est le paquet n, tandis que le contenu de bloc de trames des paquets précédents et suivants est montré pour illustrer le schéma.

Paquet n-3 :  1,  6, 11, 16
Paquet n-2 :  5, 10, 15, 20
Paquet n-1 :  9, 14, 19, 24
Paquet n : 13, 18, 23, 28
Paquet n+1 : 17, 22, 27, 32
Paquet n+2 : 21, 26, 31, 36

Les 32 premiers bits sont le champ ToC.
Le bit 0 est "0" car il n'y a pas de champ ToC suivant.
Les bits 1 à 5 sont "01000" = 80 octets par trame.
Les bits 8 à 15 sont "00000100" = 4 blocs de trames avec 80 octets par trame.
Les bits 16 à 19 sont "0000" = DIS1 (0).
Les bits 20 à 23 sont "0100" = DIS2 (4).
Les bits 24 à 27 sont "0100" = DIS3 (4).
Les bits 28 à 31 sont "0100" = DIS4 (4).

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0 1 0 0 0|0 0|0 0 0 0 0 1 0 0|0 0 0 0|0 1 0 0|0 1 0 0|0 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| d(0) trame 13                                                 |
.                                                               .
|                                                         d(639)|
+---------------+---------------+---------------+---------------+
| d(0) trame 18                                                 |
.                                                               .
|                                                         d(639)|
+---------------+---------------+---------------+---------------+
| d(0) trame 23                                                 |
.                                                               .
|                                                         d(639)|
+---------------+---------------+---------------+---------------+
| d(0) trame 28                                                 |
.                                                               .
|                                                         d(639)|
+---------------+---------------+---------------+---------------+

 	7.	Paramètres de format de charge utile

Ce format de charge utile RTP est identifié en utilisant le type de support audio/G719, qui est enregistré en accord avec la [RFC4855] et utilise le gabarit de la [RFC4288].

 	7.1	Définition de type de support
Le type de support pour le codec G.719 est alloué dans l'arborescence de l'IETF car G.719 a le potentiel de devenir un codec audio largement utilisé dans la voix sur IP générale (VoIP) la téléconférence, et les applications de flux directs. Cet enregistrement de type de support couvre le transfert en temps réel via RTP.

Noter que tout paramètre non spécifié DOIT être ignoré par le receveur pour assurer que des paramètres supplémentaires peuvent être ajoutés dans toute future révision de cette spécification.

Nom de type : audio
Nom de sous type : G719
Paramètres exigés : aucun
Paramètres facultatifs :
entrelaçage : indique que le mode entrelaçage DEVRA être utilisé pour la charge utile. Le paramètre spécifie le nombre de créneaux de bloc de trames disponibles dans une mémoire tampon de désentrelaçage (incluant la trame qui est prête à être consommée) pour chaque source. Sa valeur est égale à un plus le nombre maximum de trames qui peuvent précéder toute trame dans l'ordre de transmission et suivre la trame dans l'ordre d'horodatage RTP. La valeur DOIT être supérieure à zéro. Si ce paramètre n'est pas présent, le mode entrelaçage NE DEVRA PAS être utilisé.
int-delay : délai minimum de support en millisecondes nécessaire pour éviter un sous emploi dans la mémoire tampon de désentrelaçage avant le début du décodage, c'est-à-dire, la différence des tics d'horodatage RTP entre la première et la dernière trame audio présente dans la mémoire tampon de désentrelaçage exprimée en millisecondes. La valeur est une propriété du flux et est fournie par source. Les valeurs permises sont de zéro à la plus grande valeur exprimable par un entier non signé de 16 bits (65535). Noter qu'en pratique, la plus grande valeur qui peut être utilisée est égale à la taille déclarée de la mémoire tanpon d'entrelaçage du receveur. Si pour une raison quelconque la valeur est supérieure à la mémoire tampon du receveur déclarée par ou pour le receveur, cette valeur prend par défaut la taille de la mémoire tampon du receveur. Pour les sources pour lesquelles cette valeur n'a pas été fournie, la valeur prend par défaut la taille de la mémoire tampon du receveur. Le format est une liste séparée par des virgules de délais de source de synchronisation (SSRC) ":" en paires de millisecondes, qui en ABNF [RFC5234] est exprimé par :
int-delay = "int-delay:" source-delay *("," source-delay)
source-delay = SSRC ":" delay-value
SSRC = 1*8HEXDIG 	; les 32 bits du SSRC codés en format hexadécimal
delay-value = 1*5DIGIT 	; la valeur du délai en millisecondes

Exemple : int-delay=ABCD1234:1000,4321DCB:640

Note : pas d'espace permise dans le paramètre avant la fin de toutes les paires de valeurs.

max-red : durée maximum en millisecondes qui s'écoule entre la transmission primaire (première) d'une trame et toute transmission redondante que l'envoyeur va utiliser. Ce paramètre permet à un receveur d'avoir un délai bordé quand la redondance est utilisée. Les valeurs permises sont entre zéro (aucune redondance ne sera utilisée) et 65535. Si le paramètre est omis, aucune limitation sur l'usage de la redondance n'est présente.

canaux : nombre de canaux audio. Les valeurs possibles (1 à 6) et l'ordre respectif des canaux sont spécifiés au paragraphe 4.1 de la [RFC3551]. Si il est omis, il prend par défaut la valeur 1.

CBR (Constant BitRate) : indique le débit binaire exact du codec en bits par seconde (non inclus les frais généraux de mise en paquets, d'en-tête RTP, ou des couches inférieures) que le codec DOIT utiliser. "CBR" est à utiliser quand le taux dynamique ne peut pas être pris en charge (un cas est, par exemple, celui d'une passerelle à H.320). "CBR" est surtout utilisé pour des passerelles avec des réseaux de commutation de circuits. Donc, le "CBR" est le taux non inclus la FEC spécifiée au paragraphe 4.3.1. Si la FEC doit être utilisée, le paramètre "b=" DOIT être utilisé pour permettre le débit binaire supplémentaire nécessaire à l'envoi des informations redondantes. Il est RECOMMANDÉ que ce paramètre soit seulement utilisé quand il est nécessaire pour établir une communication effective. L'usage de ce paramètre a des implications pour le contrôle d'encombrement qui doivent être prises en compte ; voir la Section 9.

ptime : voir la [RFC4566].

maxptime : voir la [RFC4566].

Considérations de codage : ce type de support est tramé et binaire ; voir au paragraphe 4.8 de la [RFC4288].

Considérations de sécurité :  voir la Section 10 de la RFC 5404.

Considérations d'interopérabilité : la prise en charge du mode Entrelaçage n'est pas obligatoire et doit être négociée. Voir au paragraphe 7.2 comment faire cela pour les protocoles fondés sur SDP.

Spécification publiée :  RFC 5404

Applications qui utilisent ce type de support : applications audio en temps réel comme la voix sur IP et la téléconférence, et les flux multi-média.

Information s supplémentaires : aucune

Personne & adresse de messagerie à contacter pour plus d'informations: Ingemar Johansson <ingemar.s.johansson@ericsson.com>

Usage prévu : COMMUN

Restrictions d'usage : ce type de support dépend du tramage RTP, et donc est seulement défini pour le transfert via RTP [RFC3550]. Le transport dans d'autres protocoles de tramage n'est pas défini pour l'instant.

Auteurs : Ingemar Johansson <ingemar.s.johansson@ericsson.com>
	Magnus Westerlund <magnus.westerlund@ericsson.com>

Contrôleur des changements : groupe de travail IETF Transport Audio/Video sur délégation de l'IESG.

De plus, noter que la mémorisation de fichier d'audio codé en G.719 dans le format ISO de base de fichier de supports est spécifié à l'Annexe A de [G.719]. Donc, les formats de fichier de support tels que MP4 (audio/mp4 ou vidéo/mp4) [RFC4337] et 3GP (audio/3GPP et vidéo/3GPP) [RFC3839] peuvent contenir de l'audio codé en G.719.

 	7.2	Transposition en SDP
Les informations portées dans la spécification de type de supports ont une transposition spécifique en champs dans le protocole de description de session (SDP, Session Description Protocol) [RFC4566], qui est couramment utilisé pour décrire les sessions RTP. Quand SDP est utilisé pour spécifier les sessions qui emploient le codec G.719, la transposition est la suivante :
o	Le type de support ("audio") va dans la ligne SDP "m=" comme nom de support.
o	Le sous type de support (nom de format de charge utile) va dans la ligne SDP "a=rtpmap" comme nom de codage. Le débit d'horloge RTP dans une "a=rtpmap" DOIT être 48000, et le paramètre de codage "channels" (paragraphe 7.1) DOIT soit être explicitement réglé à N, soit être omis, impliquant une valeur par défaut de 1. Les valeurs de N qui sont permises sont spécifiées au paragraphe 4.1 de la [RFC3551].
o	Les paramètres "ptime" et "maxptime" vont respectivement dans les attributs SDP "a=ptime" et "a=maxptime".
o	Tout paramètre restant va dans l'attribut SDP "a=fmtp" en le copiant directement de la chaîne de paramètre de type de supports comme une liste de paires de paramètre=valeur séparées par des caractères deux-points.

 	7.2.1	Considérations d’offre/réponse
Les considérations suivantes s'appliquent quand on utilise les procédures d'offre/réponse de SDP pour négocier l'utilisation de charge utile G.719 dans RTP :

o	Chaque combinaison de paramètres de configuration de format de transport de charge utile RTP ("entrelaçage" et "channels") est unique dans son schéma binaire et non compatible avec toute autre combinaison. Quand il crée une offre dans une application désirant utiliser les caractéristiques les plus avancées (entrelaçage ou plus d'un canal) il est RECOMMANDÉ à l'offreur d'offrir aussi un type de charge utile contenant seulement la configuration avec un seul canal. Si plusieurs configurations intéressent l'application, elles peuvent toutes être offertes ; cependant, on devrait veiller à ne pas offrir trop de types de charge utile. Celui qui répond dans SDP DOIT inclure, dans la réponse SDP pour un type de charge utile, les paramètres suivants non modifiés de l'offre SDP (sauf si il supprime le type de charge utile) : "entrelaçage" et "channels". Cependant, la valeur du paramètre "entrelaçage" PEUT être changée. L'offreur et le répondeur SDP DOIVENT générer des paquets G.719 comme décrit par ces paramètres.

o	Les valeurs des paramètres "entrelaçage" et "int-delay" ont une relation spécifique qui doit être examinée. Elle dépend aussi de la direction des flux et de leur méthode de livraison. L'explication générale qui peut être comprise de la définition est que la valeur de "entrelaçage" déclare la taille de la mémoire tampon de receveur, tandis que "int-delay" est une propriété de flux fournie par l'envoyeur pour informer de l'espace de mémoire tampon qu'il utilise en pratique pour le flux qu'il envoie.

*	Pour les flux de supports envoyés sur une diffusion groupée, la valeur de "entrelaçage" NE DEVRA PAS être changée par le répondeur. Elle devra être acceptée ou le type de charge utile devra être supprimé. La valeur du paramètre "int-delay" est une propriété du flux et est fournie par l'agent d'offre/réponse qui a l'intention d'envoyer des supports avec ce type de charge utile, et pour chaque flux venant de cet agent (un ou plusieurs). La valeur DOIT être entre zéro et ce qui correspond à la taille de mémoire tampon déclarée par la valeur du paramètre "entrelaçage".

*	Pour les flux en envoi individuel que l'offreur déclare comme en envoi seulement, la valeur du paramètre "entrelaçage" est la taille qu'il est est RECOMMANDÉ au répondeur d'utiliser par l'offreur. Le répondeur PEUT la changer pour toute valeur admise. La valeur du paramètre "int-delay" va être celle que l'offreur a l'intention d'utiliser sauf si le répondeur réduit la valeur du paramètre "entrelaçage" en dessous de ce qui est nécessaire pour cette valeur de "int-delay". Si la valeur de "entrelaçage" dans la réponse est plus petite que la valeur de "int-delay" dans l'offre, la valeur de "int-delay" est réduite par défaut à correspondre à la valeur de "entrelaçage". Si l'offreur n'est pas satisfait de cela, il va devoir effectuer un autre tour d'offre/réponse. Comme le répondeur ne va pas envoyer de supports, il n'inclut aucun "int-delay" dans la réponse.

*	Pour les flux en envoi individuel que l'offreur déclare comme en réception seule, la valeur de "entrelaçage" dans l'offre va être la taille de l'offreur de la mémoire tampon d'entrelaçage. Le répondeur indique sa taille préférée de mémoire tampon d'entrelaçage pour tout futur tour d'offre/réponse. L'offreur ne fournira aucun paramètre "int-delay" car il n'envoie aucun supports. Il est recommandé au répondeur d'inclure dans sa réponse un paramètre "int-delay" pour déclarer quelle propriété est pour le flux qu'il va envoyer. La réponse est supposée être capable de choisir une valeur de paramètre valide entre zéro et le nombre maximum déclaré de créneaux dans la mémoire tampon de désentrelaçage.

*	Pour des flux en envoi individuel que l'offre déclare comme des flux en envoi-réception, la valeur du paramètre "entrelaçage" dans l'offre va être la taille de la mémoire tampon d'entrelaçage de l'offreur. Le répondeur va indiquer dans la réponse la taille de sa mémoire tampon d'entrelaçage actuelle. Il est recommandé que cette valeur soit au moins aussi grosse que celle de l'offre. Il est recommandé à l'offreur d'inclure un paramètre "int-delay" choisi sur la base d'un répondeur qui a au moins autant d'espace d'entrelaçage que l'offreur, sauf si rien d'autre n'est connu. Comme la taille de mémoire tampon d'entrelaçage de l'offreur n'est pas encore connue, cela peut échouer, et dans ce cas la règle est de dégrader par défaut la valeur de "int-delay" pour qu'elle corresponde à la pleine taille de la mémoire tampon d' entrelaçage du répondeur. Si l'offreur n'est pas satisfait de cela, il va devoir initier un autre tour d'offre/réponse. Il est recommandé au répondeur d'inclure dans sa réponse un paramètre "int-delay" pour déclarer quelle est la propriété pour le ou les flux qu'il va envoyer. La réponse est supposée être capable de choisir une valeur  de paramètre valide entre zéro et le nombre maximum déclaré d'intervalles dans la mémoire tampon de désentrelaçage.

o	Dans la plupart des cas, les paramètres "maxptime" et "ptime" ne vont pas affecter l'interopérabilité ; cependant, le réglage des paramètres peut affecter les performances de l'application. Le traitement de l'offre/réponse SDP du paramètre "ptime" est décrit dans la [RFC3264]. Le paramètre "maxptime" DOIT être traité de la même façon.

o	Le paramètre "max-red" est un paramètre de propriété de flux. Pour les flux de supports en envoi individuel, en envoi seul, ou en envoi-réception, le paramètre déclare la limitation de redondance que le flux envoyeur va utiliser. Pour les flux en réception seule, il indique la valeur désirée pour le flux envoyé au receveur. Le répondeur PEUT changer la valeur, mais il est RECOMMANDÉ d'utiliser la même limitation que l'offre déclare. Dans le cas de diffusion groupée, l'offreur PEUT déclarer une limitation ; il DEVRA y être répondu en utilisant la même valeur. Il est RECOMMANDÉ qu'un envoyeur de supports qui utilise ce format de charge utile inclue toujours le paramètre "max-red". Cette information va probablement simplifier le traitement du flux de supports chez le receveur. Cela est particulièrement vrai si aucune redondance ne va être utilisée, et dans ce cas "max-red" est réglé à zéro.

o	Tout paramètre inconnu dans une offre DEVRA être supprimé dans la réponse.

o	Le paramètre SDP "b=" DEVRAIT être utilisé pour négocier la bande passante maximale à utiliser pour le flux audio. L'offreur peut offrir un taux maximum et la réponse peut contenir un taux plus faible. Si aucun paramètre "b=" n'est présent dans l'offre ou réponse, cela implique un taux jusqu'à 128 kbit/s.

o	Le paramètre "CBR" est une capacité du receveur; c'est-à-dire, seuls les receveurs qui exigent réellement un débit binaire constant devraient l'utiliser. L'usage de ce paramètre a un impact négatif sur la possibilité d'effectuer le contrôle d'encombrement ; voir à la Section 9. Pour les flux en réception seule et envoi-réception, il indique le désir de débit binaire constant que le receveur veut accepter. Un envoyeur DOIT être capable d'envoyer à un flux de débit binaire  constant car c'est un sous ensemble de la capacité de débit binaire variable. Si l'offre inclut ce paramètre, le répondeur DOIT envoyer l'audio G.719 au débit binaire constant si il est dans le débit binaire de session admis (paramètre "b="). Si le répondeur ne peut pas prendre en charge le CBR déclaré, ce type de charge utile doit être refusé dans la réponse. Le répondeur DEVRAIT seulement inclure ce paramètre si le répondeur lui-même exige de recevoir à un débit binaire constant, même si l'offre n'incluait pas de paramètre "CBR". Dans ce cas, l'offreur DEVRA envoyer au débit binaire constant, mais DEVRA être capable d'accepter des supports à un débit binaire variable. Il est RECOMMANDÉ à un répondeur d'utiliser le même CBR que dans l'offre, car un usage symétrique a plus de chances de fonctionner. Si les deux côtés exigent un CBR particulier, il y a une possibilité d'échec de communication quand un ou les deux côtés ne peuvent pas transmettre au taux demandé. Dans ce cas, l'agent qui détecte ce problème va devoir effectuer un second tour d'offre/réponse pour essayer de trouver une autre configuration qui fonctionne ou terminer la session établie. Dans le cas où l'offre contenait un paramètre "CBR" mais pas la réponse, l'offreur est alors libre de transmettre à n'importe quel taux au répondeur, mais celui-ci est limité au taux déclaré.

 	7.2.2	Considérations de SDP déclaratif
Dans l'usage déclaratif, comme SDP dans le protocole de flux de temps réel (RTSP, Real Time Streaming Protocol) [RFC2326] ou dans le protocole d'annonce de session (SAP, Session Announcement Protocol) [RFC2974], les paramètres DEVRONT être interprétés comme suit :

o	Les paramètres de configuration de format de charge utile ("entrelaçage" et "channels") sont tous déclaratifs, et un participant DOIT utiliser la ou les configurations qui sont fournies pour la session. Plus d'une configuration peut être fournie si nécessaire en déclarant plusieurs types de charge utile RTP ; cependant, le nombre de types devrait rester petit.

o	Il se pourrait qu'il ne soit pas possible de savoir les valeurs de SSRC qui vont être utilisées par les sources au moment de l'envoi du SDP. Ce n'est pas un problème majeur car la taille de la mémoire tampon d'entrelaçage peut être adaptée aux valeurs qui vont être réellement utilisées, assurant donc que les valeurs par défaut pour "int-delay" ne résultent pas en trop de mise en mémoire tampon supplémentaire.

o	Toutes les valeurs de "maxptime" et "ptime" devraient être choisies avec soin pour assurer que les participants à la session peuvent réaliser des performances raisonnables.

o	Le paramètre "CBR", si il est inclus s'applique à tous les flux RTP qui utilisent ce type de charge utile pour lequel un CBR particulier est déclaré. L'usage de ce paramètre a un impact négatif sur la possibilité d'effectuer le contrôle d'encombrement; voir la Section 9.

 	8	Considérations relatives à l’IANA

Un type de support (audio/G719) a été défini et enregistré dans le registre des types de supports; voir au paragraphe 7.1.

 	9.	Contrôle d’encombrement

Les considérations générales de contrôle d'encombrement pour transporter les données RTP s'appliquent ; voir RTP [RFC3550] et tout profil RTP applicable comme AVP [RFC3551]. Cependant, la capacité multi débits du codage audio G.719 donne un mécanisme qui peut aider à contrôler l'encombrement, car la demande de bande passante peut être ajustée (dans les limites du codec) en choisissant un codage différent du débit binaire.

Le nombre de trames encapsulées dans chaque charge utile RTP influence largement la bande passante globale du flux RTP du fait des contraintes de frais généraux d'en-tête. La mise en paquets de plus de trames dans chaque charge utile RTP peut réduire le nombre de paquets envoyés et donc les frais généraux d'en-tête, au prix d'un délai accru et d'une robustesse réduite à l'erreur. Si la correction d'erreur directe (FEC) est utilisée, la quantité de redondance induite par la FEC doit être régulée afin que l'utilisation de la FEC elle-même ne cause pas de problème d'encombrement. En d'autres termes, un envoyeur NE DEVRA PAS augmenter le débit binaire total quand il ajoute de la redondance en réponse à la perte de paquet, et doit plutôt l'ajuster vers le bas en accord avec l'algorithme de contrôle d'encombrement utilisé. Donc, quand on ajoute de la redondance, le débit binaire du support va devoir être réduit pour faire de la place à la redondance.

Le paramètre de signalisation "CBR" permet à un receveur de verrouiller un type de charge utile RTP à utiliser un seul débit de codage. Comme cela empêche le débit de codec d'être diminué quand de l'encombrement est rencontré, l'envoyeur est contraint soit de changer la mise en paquets, soit d'interrompre la transmission. Comme ces réponses à l'encombrement sont sévèrement limitées, les mises en œuvre NE DEVRAIENT PAS utiliser le paramètre "CBR" sauf si il y a une interaction avec un appareil qui ne peut pas prendre en charge un débit binaire variable (par exemple, une passerelle à des systèmes H.320).  Quand on utilise le mode CBR, un receveur DOIT surveiller le taux de perte de paquets pour s'assurer que de l'encombrement n'est pas causé, en suivant les lignes directrices de la Section 2 de la RFC 3551.

 	10.	Considérations sur la sécurité

Les paquets RTP qui utilisent le format de charge utile défini dans cette spécification sont soumis aux considérations sur la sécurité discutées dans la spécification RTP [RFC3550] et dans tout profil RTP applicable. Les principaux soucis de sécurité pour le paquet RTP portant 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ée par un mécanisme cryptographique convenable de protection de l'intégrité. 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 assurer la confidentialité, la protection de l'intégrité, et au moins l'authentification de la source permettant de déterminer si un paquet RTP provient d'un membre de la session RTP.

Noter que le mécanisme approprié pour fournir 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 n'est pas suffisant, mais, si il convient, l'usage du protocole sûr de transport en temps réel (SRTP, Secure Real-time Transport Protocol) [RFC3711] est recommandé. D'autres mécanismes qui peuvent être utilisés sont IPsec [RFC4301] et la sécurité de la couche transport (TLS, Transport Layer Security) [RFC5246] (RTP sur TCP) ; d'autres solutions peuvent exister.

L'utilisation de l'entrelaçage en conjonction avec le chiffrement peut avoir un impact négatif sur la confidentialité pendant un court instant. Si on considère les paquets suivants (dans les accolades) contenant les numéros de trame indiqués : {10, 14, 18}, {13, 17, 21}, {16, 20, 24} (un schéma populaire d'entrelaçage diagonal continu). Le générateur souhaite refuser à certains participants la capacité d'entendre le matériel commençant à l'instant 16. En changeant simplement la clé sur le paquet avec l'horodatage à ou après 16, et en refusant cette nouvelle clé à ces participants, on ne réalise pas cela ; les trames 17, 18, et 21 ont été fournies dans des paquets précédents sous la clé précédente, et une erreur de dissimulation peut rendre l'audio intelligible au moins aussi loin que la trame 18 ou 19, et éventuellement plus loin.

Ce format de charge utile RTP et son décodeur de supports ne présentent aucune non uniformité significative de la complexité de calcul du côté receveur pour le traitement de paquet, et donc ont peu de chances de faire peser une menace de déni de service résultant de la réception de données pathologiques. Le format de charge utile RTP ne contient pas de contenu actif.

 	11.	Remerciements

Les auteurs tiennent à remercier Roni Even et Anisse Taleb pour leur aide sur ce document. Merci aussi aux personnes qui ont fourni des réactions : Colin Perkins, Mark Baker, et Stephen Botzko.

 	12.	Références
 	12.1	Références normatives

[G.719]	Recommandation UIT-T G.719, "Codage audio pleine bande peu complexe pour des applications conversationnelles de haute qualité ", avril 2008.<https://www.itu.int/rec/T-REC-G.719 >

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

[RFC3264]	J. Rosenberg et H. Schulzrinne, "Modèle d'offre/réponse avec le protocole de description de session (SDP)", juin 2002. (P.S.  ; MàJ par RFC8843, 9143)

[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. (MàJ par RFC7164, RFC7160, RFC8083, RFC8108, RFC8860)

[RFC3551]	H. Schulzrinne et S. Casner, "Profil RTP pour conférences audio et vidéo avec contrôle minimal", STD 65, juillet 2003. (MàJ par RFC8860)

[RFC4566]	M. Handley, V. Jacobson et C. Perkins, "SDP : Protocole de description de session", juillet 2006. (P.S.  ; remplacée par RFC8866)

[RFC5234]	D. Crocker, P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", janvier 2008. (STD0068)

[RFC5405]	L. Eggert, G. Fairhurst, "Lignes directrices pour l'utilisation d'UDP en envoi individuel pour les concepteurs d'applications", novembre 2008. (BCP0145 ; MàJ par RFC8085)

 	12.2	Références pour information

[RFC2198]	C. Perkins et autres, "Charge utile RTP pour données audio redondantes", septembre 1997. (P.S.)

[RFC2326]	H. Schulzrinne, A. Rao et R. Lanphier, "Protocole de flux directs en temps réel (RTSP)", avril 1998. (Remplacée par RFC7826)

[RFC2974]	M. Handley, C. Perkins, E. Whelan, "Protocole d'annonce de session (SAP)", octobre 2000. (Expérimentale)

[RFC3711]	M. Baugher et autres, "Protocole de transport sécurisé en temps réel (SRTP)", mars 2004. (P.S. ; MàJ par 9335)

[RFC3839]	R. Castagno, D. Singer, "Enregistrements de types MIME pour les fichiers multimédia du projet en partenariat de 3ème génération (3GPP)", juillet 2004.(P.S.)

[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.) (Remplace la RFC2401)

[RFC4337]	Y Lim, D. Singer, "Enregistrements de type MIME pour MPEG-4", mars 2006. (P.S.)

[RFC4855]	S. Casner, "Enregistrement du type de support des formats de charge utile RTP", février 2007. (P.S.)

[RFC5109]	A. Li, éd., "Format de charge utile RTP pour la correction générique d'erreur directe", décembre 2007. (Remplace RFC2733, RFC3009) (P.S.)

[RFC5246]	T. Dierks, E. Rescorla, "Version 1.2 du protocole de sécurité de la couche Transport (TLS)", DOI 10.17487/RFC5246, août 2008. (P.S. ; remplace RFC3268, 4346, 4366 ; MàJ RFC4492 ; rendue obsolète par la RFC8446)

 	Adresse des auteurs

Magnus Westerlund	Ingemar Johansson	
Ericsson AB	Ericsson AB	
Torshamnsgatan 21-23	Laboratoriegrand 11	
SE-164 83 Stockholm	SE-971 28 Lulea	
mél : magnus.westerlund@ericsson.com	mél : ingemar.s.johansson@ericsson.com