Groupe de travail Réseau	M. Hatanaka, Sony Corporation	
Request for Comments : 5584	J. Matsumoto, Sony Corporation	
Catégorie : Sur la voie de la normalisation	mai 2009	
Traduction Claude Brière de L'Isle		

Format de charge utile RTP pour la famille de codage acoustique par transformée adaptative (ATRAC)

Résumé
Le présent document décrit un format de charge utile RTP pour un transport efficace et souple des données audio codées avec la famille de codecs de codage acoustique par transformée adaptative (ATRAC, Adaptive TRansform Audio Coding). De récentes améliorations à la famille de codecs ATRAC prennent en charge le codage audio de haute qualité sur plusieurs canaux. Le format de charge utile RTP présenté dans le présent document inclut aussi la prise en charge de la fragmentation des données, des mesures élémentaires de redondance, et une variante sur les flux adaptables.

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. 

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiées ou rendues disponibles au public avant le 10 novembre 2008. La ou les personnes qui ont le contrôle des droits de reproduction sur tout ou partie de ces matériaux peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de ces matériaux en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la part de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériaux, le présent document ne peut pas être modifié en dehors du processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors du processus de normalisation de l’IETF, excepté pour le formater en vue de sa publication comme RFC ou pour le traduire dans une autre langue que l’anglais.
Table des matières
1. Introduction	2
2. Conventions utilisées dans ce document	2
3. Détails spécifiques du codec	2
4. Mise en paquets et transport des flux de la famille ATRAC dans RTP	3
4.1 Trames ATRAC	3
4.2 Enchaînement des trames	3
4.3 Fragmentation de trame	3
4.4 Transmission de trames redondantes	3
4.5 Flux adaptables sans pertes (mode de transfert à grande vitesse)	3
5. Format de charge utile	4
5.1 Structure globale de format de charge utile	4
5.2 Usage des champs d'en-tête RTP	4
5.3 Structure de charge utile RTP	5
6. Exemples de mise en paquets	7
6.1 Exemple de paquet multi-trames	7
6.2 Exemple de trame ATRAC fragmentée	8
7. Paramètres de format de charge utile	9
7.2 Enregistrement de type de support ATRAC-X	10
7.3 Enregistrement de type de support ATRAC avancé sans pertes	11
7.4 Tableau de configuration de transposition de canal	11
7.5 Transposition des paramètres de type de support dans SDP	12
7.6 Considérations sur le modèle d'offre/réponse	13
7.7 Usage de SDP déclaratif	14
7.8 Exemples de descriptions de session SDP	14
7.9 Exemple d'échange d'offre/réponse	15
8. Considérations relatives à l'IANA	17
9. Considérations sur la sécurité	17
10. Considérations sur le décodage correct	17
10.1 Vérification des paquets	17
10.2 Vérification de la validité des paquets	18
11. Références	18
11.1 Références normatives	18
11.2 Références pour information	18
Adresse des auteurs	19

 	1.	Introduction

La famille ATRAC des codecs perceptifs audios est conçue pour répondre à de nombreux besoins de transferts audio de haute qualité à faible débit binaire. La technologie ATRAC peut être trouvée dans de nombreux produits et applications grand public et professionnels, incluant des lecteurs MD, des lecteurs de CD, des enregistreurs vocaux, et des téléphones mobiles.

Les récentes avancées de la technologie ATRAC permettent que plusieurs canaux d'audio soient codés dans des groupements personnalisables. Cela devrait permettre que de futures expansions de flux adaptés fournissent la plus grande souplesse dans la transmission de flux de tout codec membre de la famille ATRAC ; cependant, ce format de charge utile ne distingue pas entre les codecs au niveau du paquet.

Ce format de charge utile simplifié contient seulement les informations de base nécessaires pour désassembler un paquet d'audio ATRAC afin de le décoder. Il y a aussi la prise en charge de base de la fragmentation et de la redondance.

 	2.	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" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

 	3.	Détails spécifiques du codec

Les premières versions du codec ATRAC traitaient seulement deux canaux d'audio à la fréquence d'échantillonnage de 44,1  kHz, avec des débits binaires normaux entre 66 kbit/s et 132 kbit/s. La dernière version permet un maximum de 8  canaux d'audio, jusqu'à 96 kHz en fréquence d'échantillonnage, et une option de codage sans perte qui peut être transmise dans un format adaptable (aussi appelé mode de transfert à haut débit) ou standard (aussi dit mode standard). La gamme de débits binaires faisable a aussi été étendue, permettant de 8 kbit/s à 1400 kbit/s dans les modes de codage avec pertes.

Selon la version d'ATRAC utilisée, la taille de trame d'échantillons est de 512, 1024, ou 2048 échantillons. Bien que les formats de mode à pertes et de mode standard sans pertes soient codés comme des trames audio séquentielles seules, les données du mode de transfert sans pertes à haute vitesse comportent deux couches -- une couche de base à pertes et une couche d'amélioration.

Bien que l'écoulement de l'audio multi-canaux soit pris en charge selon la version d'ATRAC utilisée, tout l'audio codé pour une période donnée est contenu dans une seule trame. Donc, il n'y a pas d'entrelacement ni de partage des données audio par canal avec lequel elles sont concernées.

 	4.	Mise en paquets et transport des flux de la famille ATRAC dans RTP
 	4.1	Trames ATRAC
Pour le transport des données audio compressées, ATRAC utilise le concept de trames. Les trames ATRAC sont les plus petites unités de données pour lesquelles les informations de temps sont attribuées. Les trames sont alignées sur l'octet par définition.

 	4.2	Enchaînement des trames
Il est souvent possible de porter plusieurs trames dans un paquet RTP. Cela peut être utile en audio, où sur un LAN avec une MTU de 1500 octets, une moyenne de 7 trames ATRAC complètes de 64 kbit/s pourraient être portées dans un seul paquet RTP, car chaque trame ATRAC va faire approximativement 200 octets. Les trames ATRAC peuvent être de longueur fixe ou variable. Pour faciliter l'analyse dans le cas de plusieurs trames dans un paquet RTP, la taille de chaque trame est communiquée au receveur en portant "dans la bande" la taille de trame pour chaque trame contenue dans un paquet RTP. Cependant, pour simplifier la mise en œuvre des receveurs RTP, il est exigé que quand plusieurs trames sont portées dans un paquet RTP, chaque trame DOIT être complète, c'est-à-dire, le nombre de trames dans un paquet RTP DOIT être un entier.

 	4.3	Fragmentation de trame
Le codec ATRAC peut traiter des trames très grandes. Comme la plupart des réseaux IP ont des tailles de MTU significativement plus petites que les tailles de trame que ATRAC peut traiter, ce format de charge utile permet la fragmentation d'une trame ATRAC sur plusieurs paquets RTP. Cependant, pour simplifier la mise en œuvre des receveurs RTP, un paquet RTP DOIT porter soit une ou plusieurs trames ATRAC complètes, soit un seul fragment d'une trame ATRAC. En d'autres termes, les paquets RTP NE DOIVENT PAS contenir des fragments de plusieurs trames ATRAC et NE DOIVENT PAS contenir un mélange de trames complètes et de trames fragmentées.

 	4.4	Transmission de trames redondantes
Comme RTP ne garantit pas la transmission fiable, la réception des données n'est pas assurée. La perte d'un paquet peut résulter en un "trou de décodage" chez le receveur. Une méthode pour remédier à ce problème est de permettre des copies décalées dans le temps de trames ATRAC à envoyer avec les données courantes. Pour un coût modeste en latence et en complexité de mise en œuvre, la résilience à l'erreur de perte de paquet peut être réalisée. Pour les détails, voir le paragraphe 5.3.2.1 et la [RFC2198].

 	4.5	Flux adaptables sans pertes (mode de transfert à grande vitesse)
Comme ATRAC supporte une variation sur le codage adaptable, ce format de charge utile donne un mécanisme pour transmettre les données essentielles (aussi appelées la couche de base) avec ses données d'amélioration de deux façons : multiplexées sur une session ou séparées sur deux sessions.

Dans l'une et l'autre méthode, seule la couche de base est essentielle pour produire les données audio. La couche d'amélioration porte les données audio restantes nécessaires pour décoder sans perte les données audio. Donc dans les situations de bande passante limitée, l'envoyeur peut choisir de ne pas transmettre les données d'amélioration tout en fournissant à un client assez de données pour générer de l'audio codé avec pertes à travers la couche de base.

 	4.5.1	Flux adaptables multiplexés
Dans l'écoulement multiplexé, la couche de base et la couche d'amélioration sont couplées dans chaque paquet, utilisant seulement une session comme illustré à la Figure 1.

Le paquet DOIT commencer avec la couche de base, et les deux types de couche DOIVENT s'entrelacer si les deux couches existent dans un paquet (seule la base ou l'amélioration est incluse dans un paquet au début d'un écoulement, ou durant la fragmentation).

   +-----------------+  +-----------------+  +-----------------+
   |Base|Amélioration|--|Base|Amélioration|--|Base|Amélioration| ...
   +-----------------+  +-----------------+  +-----------------+
           N                   N+1                 N+2        : Packet

Figure 1 : Structure multiplexée

 	4.5.2	Flux adaptables multi-sessions
Dans l'écoulement multi-sessions, la couche de base et la couche d'amélioration sont envoyées sur deux sessions séparées, permettant aux clients avec certaines limitations de bande passante de recevoir juste la couche de base pour le décodage comme illustré à la Figure 2.

Dans ce cas, il est EXIGÉ de déterminer quelles sessions sont appariées ensemble du côté receveur. Pour des sessions appariées de couche de base et d'amélioration, les liens CNAME dans la session du protocole de contrôle RTP (RTCP, RTP Control Protocol) DOIVENT être appliqués en utilisant le même CNAME pour assurer une transposition correcte en la source RTP.

Bien qu'il puisse y avoir des méthodes de remplacement pour la synchronisation des couches, l'horodatage DEVRAIT être utilisé pour synchroniser la couche de base avec son amélioration. Les deux sessions DOIVENT être synchronisées en utilisant les informations des paquets SR RTCP pour aligner les horodatages RTP.

Si les données de session de la couche d'amélioration ne peuvent pas arriver avant le moment de présentation, le décodeur DOIT décoder seulement les données de la couche de base de la session, ignorant les données de la couche d'amélioration.

         Session 1 :
         +------+  +------+  +------+  +------+
         | Base |--| Base |--| Base |--| Base | ...
         +------+  +------+  +------+  +------+
            N         N+1       N+2       N+3     : Paquet

         Session 2 :
         +-------------+  +-------------+  +-------------+
         |Amélioration |--|Amélioration |--|Amélioration | ...
         +-------------+  +-------------+  +-------------+
               N                N+1              N+2         : Paquet

Figure 2 : Écoulement multi-sessions

 	5.	Format de charge utile
 	5.1	Structure globale de format de charge utile
La structure de la charge utile ATRAC est illustrée à la Figure 3. La charge utile RTP qui suit l'en-tête RTP contient deux sections de données alignées sur l'octet.

            +-------+-------------+----------------------------------+
            |En-tête| Section d'en|     Section de trames ATRAC      |
            | RTP   | -tête ATRAC |(incluant les données redondantes)|
            +-------+-------------+----------------------------------+
            < ---------------- Charge utile de paquet RTP ---------- >

Figure 3 : Structure de charge utile RTP de la famille ATRAC

La première section de données est l'en-tête ATRAC, contenant juste un en-tête avec des informations pour le paquet entier. La seconde section est celle où les trames ATRAC codées sont mémorisées. Elle peut contenir un seul fragment d'une trame ATRAC ou une ou plusieurs trames ATRAC complètes. La section des trames ATRAC NE DOIT PAS être vide. Quand on utilise le mécanisme de redondance décrit au paragraphe 5.3.2.1, les données de la trame redondante peuvent être incluses dans cette section et l'horodatage DOIT être réglé au plus ancien horodatage de la trame redondante.

Pour bénéficier de la capacité de codage sans perte du mode de transfert à grande vitesse de ATRAC, la charge utile RTP peut être partagée entre deux sessions, l'une transmettant une couche de base essentielle et l'autre transmettant les données d'amélioration. Cependant, dans les deux cas, la structure ci-dessus s'applique.

 	5.2	Usage des champs d'en-tête RTP
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |       Numéro de séquence      |
+---+-+-+-------+-+-------------+---------------+---------------+
|                          Horodatage                           |
+---------------+---------------+---------------+---------------+
|           Identifiant de source de synchronisation(SSRC)      |
+---------------+---------------+---------------+---------------+
|           Identifiants de source contributive (CSRC)          |
|                             .....                             |
+---------------+---------------+---------------+---------------+

Figure 4 : Partie d'en-tête RTP standard

La structure de la partie d'en-tête RTP standard est illustrée dans la Figure 4.

Version (V) : 2 bits, réglé à 2.

Bourrage (P) : 1 bit. Si le bit de bourrage est établi, le paquet contient un ou plusieurs octets de bourrage supplémentaires à la fin, qui ne font pas partie de la charge utile. Le dernier octet du bourrage contient un compte du nombre d'octets de bourrage qui devraient être ignorés, incluant lui-même. Le bourrage peut être nécessaire pour certains algorithmes de chiffrement avec des tailles de bloc fixes ou pour porter plusieurs paquets RTP dans une unité de données de protocole de couche inférieure (voir la [RFC3550]).

Extension (X) : 1 bit. Défini par le profil RTP utilisé.

Compte de CSRC (CC) : 4 bits. Voir la [RFC3550].

Marqueur (M) : 1 bit. Réglé à 1 si le paquet est le premier paquet après une période de silence ; autrement, il DOIT être réglé à 0.

Type de charge utile (PT) : 7 bits. L'allocation d'un type de charge utile RTP pour ce format de paquet sort du domaine d'application du présent document ; il est spécifié par le profil RTP sous lequel ce format de charge utile est utilisé, ou signalé dynamiquement hors bande (par exemple, en utilisant le protocole de description de session (SDP)).

Numéro de séquence : 16 bits. Numéro de séquence pour le paquet RTP. Il va de 0 à 65535 et se répète périodiquement.

Horodatage : 32 bits. Horodatage représentant l'heure d'échantillonnage du premier échantillon de la première trame ATRAC dans le paquet RTP en cours. Quand on utilise SDP, le débit d'horloge de l'horodatage RTP DOIT être exprimé en utilisant l'attribut "rtpmap". Pour ATRAC3 et ATRAC avancé sans perte, le débit d'horodatage RTP DOIT être 44100  Hz. Pour ATRAC-X, le débit d'horodatage RTP est 44100 Hz ou 48000 Hz, et il va être choisi par une signalisation hors bande.

Identifiant de SSRC : 32 bits. Voir la [RFC3550].

Identifiants de CSRC : de 0 à 15 éléments, de 32 bits chacun. Voir la [RFC3550].

 	5.3	Structure de charge utile RTP
 	5.3.1	Usage de la section d'en-tête ATRAC
La section d'en-tête ATRAC a une longueur fixe de un octet comme illustré à la Figure 5.

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|C|FrgNo|NFrames|
+-+-+-+-+-+-+-+-+

Figure 5 : En-tête RTP ATRAC

Fanion Continuation (C) : 1 bit. Le paquet qui correspond à la dernière partie des données de trame audio dans une fragmentation DOIT avoir ce bit réglé à 0 ; autrement, il est réglé à 1.

Numéro de fragment (FrgNo) : 3 bits. En cas de fragmentation des données, cette valeur est un pour le premier paquet, et augmente séquentiellement pour les paquets de données fragmentées restants. Cette valeur DOIT être zéro pour une trame non fragmentée. (Note : 3 bits sont suffisants pour éviter le retour à zéro du numéro de fragment étant donné le débit binaire maximum pris en charge actuellement dans la spécification ATRAC. Si cela change, le choix de 3 bits pour le numéro de fragment devrait être revu.)

Nombre de trames (NFrames) : 4 bits. Le nombre de trames audio dans ce paquet est la valeur du champ + 1. Cela permet un maximum de 16 trames audio ATRAC codées par paquet, avec 0 pour indiquer une trame audio. Chaque trame audio DOIT être complète dans le paquet si la fragmentation n'est pas appliquée. Dans le cas de fragmentation, il est permis que les données pour seulement une trame audio soient fragmentées, et cette valeur DOIT être 0.

 	5.3.2	Usage de la section Trames ATRAC
La section Trames ATRAC contient un nombre entier de trames ATRAC complètes ou un seul fragment d'une trame ATRAC, comme illustré à la Figure 6. Chaque trame ATRAC est précédée par un fanion d'un bit qui indique le type de couche et un champ Longueur de bloc indiquant la taille en octets de la trame ATRAC. Si plus d'une trame ATRAC est présente, alors les trames sont enchaînées dans une chaîne contiguë de bits fanions, Longueur de bloc, et trame ATRAC dans l'ordre de leur numéro de trame. Cette section NE DOIT PAS être vide.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|   Longueur de bloc          |         Trame ATRAC           |...
+-+-------------+---------------+---------------+---------------+

Figure 6 : Format de section de trame ATRAC

Fanion Type de couche (E) : 1 bit. Réglé à 1 si la trame ATRAC correspondante est d'une couche d'amélioration. 0 indique une trame codée de couche de base.

Longueur de bloc : 15 bits. Longueur en octets des données audio codées pour la trame suivante. C'est pour qu'en cas de fragmentation, si seulement un paquet suivant est reçu, le décodage puisse quand même se faire. 15 bits permettent une longueur de bloc maximum de 32 767 octets.

Trame ATRAC : données audio ATRAC codées.

 	5.3.2.1	Prise en charge de la redondance
Ce format de charge utile fournit un schéma rudimentaire pour compenser la perte occasionnelle de paquets. Comme l'horodatage de chaque paquet correspond à la première trame audio sans considération de si il est ou non redondant, et parce que on sait combien de trames d'audio chaque paquet encapsule, si deux paquets successifs sont transmis avec succès, on peut calculer le nombre de trames redondantes envoyées. Le résultat donne au client un idée de la façon dont le serveur répond aux rapports RTCP et l'avertit d'étendre sa taille de mémoire tampon si nécessaire. Pour un exemple d'utilisation des données redondantes, voir les Figures 7 et 8.

Dans cet exemple, le serveur a déterminé que pour les quelques paquets suivants, il devrait envoyer les deux dernières trames du précédent paquet du fait des récents rapports RTCP. Donc, entre les paquets N et N+1, il y a une redondance de deux trames (dont le client peut choisir de disposer). L'avantage apparaît quand les paquets N+2 et N+3 n'arrivent pas du tout, après quoi finalement le paquet N+4 arrive avec les données de trame audio suivantes nécessaires.

[Envoyeur]

|-Fr0-|-Fr1-|-Fr2-|                                      Paquet : N,     TS=0
         |-Fr1-|-Fr2-|-Fr3-|                             Paquet : N+1, TS=1024
                  |-Fr2-|-Fr3-|-Fr4-|                    Paquet : N+2, TS=2048
                           |-Fr3-|-Fr4-|-Fr5-|           Paquet : N+3, TS=3072
                                     |-Fr4-|-Fr5-|-Fr6-| Paquet : N+4, TS=4096

---------> Les paquets "N+2" et "N+3" ne sont pas arrivés  ------------->

[Receveur]

|-Fr0-|-Fr1-|-Fr2-|                            Paquet : N,     TS=0
         |-Fr1-|-Fr2-|-Fr3-|                   Paquet : N+1, TS=1024
                           |-Fr4-|-Fr5-|-Fr6-| Paquet : N+4, TS=4096

Le receveur peut décoder de FR4 à Fr6 en utilisant les données du paquet "N+4" même si la perte des paquets "N+2" et "N+3" s'est produite.

Figure 7 : Exemple de redondant 

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |       Numéro de séquence      |
+---+-+-+-------+-+-------------+---------------+---------------+
|        Horodatage (= début de l'échantillonnage de Fr1)       |
+---------------+---------------+---------------+---------------+
|         Identifiant de source de synchronisation (SSRC)       |
+---------------+---------------+---------------+---------------+
|           Identifiants de source contributive (CSRC)          |
|                             .....                             |
+---------------+---------------+---------------+---------------+
|0|  0  |   3   |0|       Longueur de bloc      |               |
+-+-----+-------+-+-------------+---------------+---------------+
|         Données (redondantes) de trame ATRAC (Fr1)  ...       |
+---------------+---------------+---------------+---------------+
|0|       Longueur de bloc      | Trame ATRAC (Fr2) (redondante)|
+-+-------------+---------------+---------------+---------------+
|    (suite)  |0|   Longueur de bloc       | Trame ATRAC (Fr3)  |
+-------------+-+---------------+----------+----+---------------+
|                       (suite)                                 |
+---------------+---------------+---------------+---------------+

Figure 8 : Exemple de structure de paquet avec données redondantes (cas du paquet "N+1")

 	5.3.2.2	Fragmentation de trame
Chaque paquet RTP DOIT contenir soit un nombre entier de trames ATRAC audio codées (avec un maximum de 16) soit un fragment de trame ATRAC. Dans le premier cas, autant de trames ATRAC complètes qui peuvent tenir dans une seule MTU de chemin DEVRAIENT être placées dans un paquet RTP. Cependant, si même une seule trame ATRAC ne tient pas dans un paquet RTP complet, la trame ATRAC DOIT être fragmentée.

Le début d'une trame fragmentée est placé dans son propre paquet RTP avec son bit Continuation (C) réglé à un, et son numéro de fragment (FragNo) réglé à un. Comme la trame doit être la seule dans le paquet, le champ Nombre de trames est zéro. Les paquets suivants vont contenir les données restantes de la trame fragmentée, avec le numéro de fragment augmenté en séquence et le bit Continuation (C) réglé en conséquence à un. Comme les paquets suivants ne contiennent aucune nouvelle trame, le champ Nombre de trames DOIT être ignoré. Le dernier paquet de données fragmentées DOIT avoir le bit Continuation (C) réglé à zéro.

Les paquets qui contiennent les trames fragmentées en rapport DOIVENT avoir des horodatages identiques. Donc, alors que les champs de bit de continuation et de numéro de fragment indiquent la fragmentation et un moyen de réordonner les paquets, l'horodatage peut être utilisé pour déterminer quels paquets vont ensemble.

 	6.	Exemples de mise en paquets
 	6.1	Exemple de paquet multi-trames
Plusieurs trames audio codées sont combinées dans un paquet. Noter comment, pour cet exemple, seulement les trames de couche de base sont envoyées de façon redondante, mais sont suivies par des trames entrelacées de couche de base et de couche d'amélioration, comme illustré à la Figure 9.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |       Numéro de séquence      |
+---+-+-+-------+-+-------------+---------------+---------------+
|                          Horodatage                           |
+---------------+---------------+---------------+---------------+
|         Identifiant de source de synchronisation (SSRC)       |
+---------------+---------------+---------------+---------------+
|           Identifiants de source contributive (CSRC)          |
|                             .....                             |
+---------------+---------------+---------------+---------------+
|0|  0  |   5   |0|     Longueur de bloc        |               |
+-+-----+-------+-+-------------+---------------+---------------+
|    Données (redondantes) de trame 1 de couche de base...      |
+---------------+---------------+---------------+---------------+
|0|       Longueur de bloc      |(redondant) trame 2 couche base|
+-+-------------+---------------+---------------+---------------+
|    (suite)  |0|   Longueur de bloc     | Trame 3 couche base  |
+-------------+-+---------------+---------------+---------------+
| (suite) |1|       Longueur de bloc     | amélioration trame 3 |
+---------+-+---+---------------+---------------+---------------+
| (suite) |0|       Longueur de bloc     | trame 4 couche base  |
+---------+-+---+---------------+---------------+---------------+
| (suite) |1|       Longueur de bloc     | amélioration trame 4 |
+---------+-+---+---------------+---------------+---------------+

Figure 9 : Exemple de paquet multi-trames

 	6.2	Exemple de trame ATRAC fragmentée
La trame de données audio codée est partagée sur trois paquets RTP comme illustré à la Figure 10. Les points suivants sont soulignés dans l'exemple ci-dessous :
o	transition de un à zéro du bit Continuation (C)
o	augmentation séquentielle du numéro de fragment

Paquet 1 :
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |     Numéro de séquence        |
+---+-+-+-------+-+-------------+---------------+---------------+
|                          Horodatage                           |
+---------------+---------------+---------------+---------------+
|         Identifiant de source de synchronisation (SSRC)       |
+---------------+---------------+---------------+---------------+
|           Identifiants de source contributive (CSRC)          |
|                             .....                             |
+---------------+---------------+---------------+---------------+
|1|  1  |   0   |1|    Longueur de bloc         |               |
+-+-----+-------+-+-------------+---------------+---------------+
|                     Données d'amélioration...                 |
+---------------+---------------+---------------+---------------+

Paquet 2 :
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |       Numéro de séquence      |
+---+-+-+-------+-+-------------+---------------+---------------+
|                          Horodatage                           |
+---------------+---------------+---------------+---------------+
|         Identifiant de source de synchronisation (SSRC)       |
+---------------+---------------+---------------+---------------+
|           Identifiants de source contributive (CSRC)          |
|                             .....                             |
+---------------+---------------+---------------+---------------+
|1|  2  |   0   |1|    Longueur de bloc         |               |
+-+-----+-------+-+-------------+---------------+---------------+
|              ...plus de données d'amélioration...             |
+---------------+---------------+---------------+---------------+

Paquet 3 :
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |       Numéro de séquence      |
+---+-+-+-------+-+-------------+---------------+---------------+
|                          Horodatage                           |
+---------------+---------------+---------------+---------------+
|         Identifiant de source de synchronisation (SSRC)       |
+---------------+---------------+---------------+---------------+
|           Identifiants de source contributive (CSRC)          |
|                             .....                             |
+---------------+---------------+---------------+---------------+
|0|  3  |   0   |1|    Longueur de bloc         |               |
+-+-----+-------+-+-------------+---------------+---------------+
|            ...dernières données d'amélioration                |
+---------------+---------------+---------------+---------------+

Figure 10 : Exemple de trame ATRAC fragmentée

 	7.	Paramètres de format de charge utile

Certains paramètres vont devoir être définis avant que du contenu codé de la famille ATRAC puisse être écoulé. D'autres paramètres facultatifs peuvent aussi être définis pour tirer parti de caractéristiques spécifiques relevant de certaines versions d'ATRAC. Des paramètres pour ATRAC3, ATRAC-X, et ATRAC avancé sans pertes sont définis ici au titre du processus d'enregistrement de sous type de support. Une transposition de ces paramètres dans le protocole de description de session (SDP, Session Description Protocol) [RFC4566] est aussi fournie pour les applications qui utilisent SDP. Ces enregistrements utilisent le gabarit défini dans la [RFC4288] et suivent la [RFC4855].

Le format et les paramètres des données sont spécifiés pour le transport en temps réel dans RTP.

 	7.1	Enregistrement de type de support ATRAC3
Le sous type de support pour le codec de transformation adaptative version 3 (ATRAC3, Adaptive TRansform Codec version 3) utilise le gabarit défini dans la [RFC4855].

Noter que tout paramètre inconnu DOIT être ignoré par le receveur.

Nom de type :  audio
Nom de sous type :  ATRAC3
Paramètres exigés :
rate : représente la fréquence d'échantillonnage en Hz des données audio originales. La seule valeur permise est 44100.
baseLayer : indique le débit binaire codé en kbit/s pour les données audio à écouler. Les valeurs permisses sont 66, 105, et 132.
Paramètres facultatifs :
ptime : voir la [RFC4566].
maxptime : voir la [RFC4566]. La longueur de trame de ATRAC3 est 1024/44100 = 23,22 (ms), et une valeur fractionnelle ne peut pas être applicable pour la définition de SDP. Donc la valeur du paramètre DOIT être un multiple de 24 (ms) pour une transmission sûre. Si ce paramètre n'est pas présent, l'envoyeur PEUT encapsuler un maximum de 6 trames codées dans un paquet RTP, pour écouler de l'ATRAC3.
maxRedundantFrames : nombre maximum de trames redondantes qui peuvent être envoyées durant une session dans tout paquet sous le mécanisme de tramage redondant détaillé dans ce document. Les valeurs permises sont des entiers dans la gamme de 0 à 15, inclus. Si ce paramètre n'est pas utilisé, une valeur par défaut de 15 DOIT être supposée.
Considérations de codage : ce type de support est tramé et contient des données binaires.
Considérations de sécurité : ce type de support ne porte pas de contenu actif. Voir la Section 9 du présent document.
Considérations d'interopérabilité : aucune.
Spécification publiée : spécification de la norme ATRAC3 [ATRAC3]
Applications qui utilisent ce type de support : flux audio et vidéo et outils de conférence.
Information supplémentaires : aucune
Numéro magique : aucun
Extensions de fichier : "at3", "aa3", et "omg"
Code de type de fichier Macintosh : aucun
Personne et adresse de messagerie à contacter pour plus d'informations : Mitsuyuki Hatanaka, Jun Matsumoto, actech@jp.sony.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.
Auteurs : Mitsuyuki Hatanaka, Jun Matsumoto, actech@jp.sony.com
Contrôleur des changements : groupe de travail AVT de l'IETF sur délégation de l'IESG

 	7.2	Enregistrement de type de support ATRAC-X
Le sous type de support pour le codec de transformation adaptative version X (ATRAC-X) utilise le gabarit défini dans la [RFC4855].

Noter que tout paramètre inconnu DOIT être ignoré par le receveur.

Nom de type : audio
Nom de sous type : ATRAC-X
Paramètres exigés :
rate : représente la fréquence d'échantillonnage en Hz des données audio originales. Les valeurs permises sont 44  100 et 48  000.
baseLayer : indique le débit binaire codé en kbit/s pour les données audio à écouler. Les valeurs permises sont 32, 48, 64, 96, 128, 160, 192, 256, 320, et 352.
channelID : indique le nombre et la disposition des canaux conformément au Tableau 1 du paragraphe 7.4. Noter que cette disposition est différente de celle proposée dans la [RFC3551]. Cependant, comme channelID = 0 définit une disposition de canaux ambiguë, la transposition de canal définie au paragraphe 4.1 de la [RFC3551] pourrait être utilisée. Les valeurs permises sont 0, 1, 2, 3, 4, 5, 6, 7.
Paramètres facultatifs :
ptime : voir la [RFC4566].
maxptime : voir la [RFC4566]. La longueur de trame de ATRAC-X est 2048/44100 = 46,44 (ms) ou 2048/48000 = 42,67 (ms), mais une valeur fractionnelle ne peut pas être applicable pour la définition de SDP. Donc la valeur du paramètre DOIT être un multiple de 47 (ms) ou 43 (ms) pour envisager une transmission sûre. Si ce paramètre n'est pas présent, l'envoyeur PEUT encapsuler un maximum de 16 trames codées dans un paquet RTP, en écoulant du ATRAC-X.
maxRedundantFrames : le nombre maximum de trames redondantes qui peuvent être envoyées durant une session dans tout paquet sous le mécanisme de tramage redondant détaillé dans ce document. Les valeurs permises sont des entiers dans la gamme de 0 à 15, inclus. Si ce paramètre n'est pas utilisé, une valeur par défaut de 15 DOIT être supposée.
delayMode : indique le désir d'utiliser des caractéristiques de faible délai, et dans ce cas le décodeur va traiter les données reçues en accord avec cette valeur. Les valeurs permises sont 2 et 4.
Considérations de codage : ce type de support est tramé et contient des données binaires.
Considérations de sécurité : ce type de support ne porte pas de contenu actif. Voir la Section 9 du présent document.
Considérations d'interopérabilité : aucune
Spécification publiée : spécification de la norme ATRAC-X [ATRAC-X]
Applications qui utilisent ce type de support : flux audio et vidéo et outils de conférence.
Information supplémentaires : aucune
Numéro magique : aucun
Extensions de fichier : "atx", "aa3", et "omg"
Code de type de fichier Macintosh : aucun
Personne et adresse de messagerie à contacter pour plus d'informations : Mitsuyuki Hatanaka, Jun Matsumoto, actech@jp.sony.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.
Auteurs : Mitsuyuki Hatanaka, Jun Matsumoto, actech@jp.sony.com
Contrôleur des changements : groupe de travail AVT de l'IETF sur délégation de l'IESG

 	7.3	Enregistrement de type de support ATRAC avancé sans pertes
Le sous type de supports de codec de transformation adaptative sans pertes (ATRAC Advanced Lossless) utilise le gabarit défini dans la [RFC4855].

Noter que tout paramètre inconnu DOIT être ignoré par le receveur.

Nom de type : audio
Nom de sous type : ATRAC-ADVANCED-LOSSLESS
Paramètres exigés :
rate : représente la fréquence d'échantillonnage en Hz des données audio originales. La seule valeur permise en mode de transfert à grande vitesse est 44 100. Toute valeur de 24 000, 32 000, 44 100, 48 000, 64 000, 88 200, 96 000, 176 400, et 192 000 peut être utilisée pour le mode standard.
baseLayer : Indique le débit binaire codé en kbit/s pour la couche de base dans les codages sans pertes en mode de transfert à grande vitesse. Pour le mode standard sans pertes, cette valeur DOIT être 0. Les valeurs permises pour ATRAC3 en couche de base sont 66, 105, et 132. Pour ATRAC-X en couche de base, ce sont 32, 48, 64, 96, 128, 160, 192, 256, 320, et 352.
blockLength : indique la longueur de bloc. Dans le mode de transfert à grande vitesse, les valeurs de 1024 et 2048 sont utilisées, respectivement, pour les flux sans pertes ATRAC avancés fondés sur ATRAC3 et ATRAC-X. Toute valeur de 512, 1024, et 2048 peut être utilisée pour le mode standard.
channelID :  indique le nombre et la disposition des canaux conformément au Tableau 1 du paragraphe 7.4. Noter que cette disposition est différente de celle proposée dans la [RFC3551]. Cependant, comme channelID = 0 définit une disposition ambiguë des canaux, la transposition de canal définie au paragraphe 4.1 de la [RFC3551] pourrait être utilisée dans ce cas. Les valeurs permises sont 0, 1, 2, 3, 4, 5, 6, 7.
ptime : voir la [RFC4566].
maxptime : voir la [RFC4566]. Dans l'écoulement de ATRAC avancé sans pertes, plusieurs trames ne peuvent pas être transmises dans un seul paquet RTP, car la taille de trame est grande. Donc ce DEVRAIT être considéré comme le temps d'une trame codée des deux côtés de l'envoyeur et du receveur. La longueur de trame de ATRAC avancé sans pertes est 512/44100 = 11,6 (ms), 1024/44100 = 23,22 (ms), ou 2048/44100 = 46,44 (ms), mais une valeur fractionnelle ne peut pas être applicable pour la définition de SDP. Donc la valeur du paramètre DOIT être 12 (ms), 24 (ms), ou 47  (ms) pour envisager une transmission sûre.
Considérations de codage : ce type de support est tramé et contient des données binaires.
Considérations de sécurité : ce type de support ne porte pas de contenu actif. Voir la Section 9 du présent document.
Considérations d'interopérabilité : aucune
Spécification publiée : spécification de la norme ATRAC avancé sans pertes [ATRAC-AL]
Applications qui utilisent ce type de support : flux audio et vidéo et outils de conférence.
Information supplémentaires : aucune
Numéro magique : aucun
Extensions de fichier : "aal", "aa3", et "omg"
Code de type de fichier Macintosh : aucun
Personne et adresse de messagerie à contacter pour plus d'informations : Mitsuyuki Hatanaka, Jun Matsumoto, actech@jp.sony.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.
Auteurs : Mitsuyuki Hatanaka, Jun Matsumoto, actech@jp.sony.com
Contrôleur des changements : groupe de travail AVT de l'IETF sur délégation de l'IESG

 	7.4	Tableau de configuration de transposition de canal
Le Tableau 1 explique la transposition entre l'identifiant de canal tel que passé durant les négociations SDP, et la transposition de locuteur que la valeur représente.

Identifiant de canal	Nombre de canaux	Transposition de locuteur par défaut
0	max 64	indéfinie
1	1	front : centre
2	2	front : gauche, droit
3	3	front : gauche, droit
		front : centre
4	4	front : gauche, droit
		front : centre
		arrière : autour
5	5+1	front : gauche, droit
		front : centre
		arrière : gauche, droit, LFE
6	6+1	front : gauche, droit
		front : centre
		arrière : gauche, droit
		arrière : centre , LFE
7	7+1	front : gauche, droit
		front : centre
		arrière : gauche, droit
		côté : gauche, droit, LFE

Tableau 1 : Configuration de canal

 	7.5	Transposition des paramètres de type de support dans 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) [RFC4566], qui est couramment utilisé pour décrire les sessions RTP. Quand SDP est utilisé pour spécifier des sessions qui emploient la famille ATRAC de codecs, les règles de transposition suivantes s'appliquent au codec ATRAC.

 	7.5.1	Pour le sous type de support ATRAC3
o	Le type de supports ("audio") va dans la ligne SDP "m=" comme nom de support.

o	Le sous type de supports (nom de format de charge utile) va dans la ligne SDP "a=rtpmap" comme nom de codage. ATRAC3 prend seulement en charge les signaux mono ou stéréo, donc un nombre correspondant de canaux (0 ou 1) DOIT aussi être spécifié dans cet attribut.

o	Le paramètre "baseLayer" va dans SDP "a=fmtp". Ce paramètre DOIT être présent. "maxRedundantFrames" peut suivre, mais si aucune valeur n'est transmise, le receveur DEVRAIT supposer une valeur par défaut de "15".

o	Les paramètres "ptime" et "maxptime" vont dans les attributs SDP "a=ptime" et "a=maxptime", respectivement.

 	7.5.2	Pour le sous type de support ATRAC-X
o	Le type de supports ("audio") va dans la ligne SDP "m=" comme nom de support.

o	Le sous type de supports (nom de format de charge utile) va dans SDP "a=rtpmap" comme nom de codage. Ce DEVRAIT être suivi par "sampleRate" (comme débit d'horloge RTP) et ensuite le nombre réel de canaux sans considération du paramètre channelID.

o	Les paramètres "ptime" et "maxptime" vont dans les attributs SDP "a=ptime" et "a=maxptime", respectivement.

o	Tous les paramètres restants vont dans l'attribut SDP "a=fmtp" en les copiant directement de la chaîne de type de supports comme une liste séparée de points-virgules des paires de paramètre=valeur. Le paramètre "baseLayer" DOIT être la première entrée de cette ligne. Le paramètre "channelID" DOIT être l'entrée suivante. Le receveur DOIT supposer une valeur par défaut de "15" pour "maxRedundantFrames".

 	7.5.3	Pour le sous type de support ATRAC Advanced Lossless
o	Le type de supports ("audio") va dans la ligne SDP "m=" comme nom de support.

o	Le sous type de supports (nom de format de charge utile) va dans SDP "a=rtpmap" comme nom de codage. Ce DEVRAIT être suivi par "sampleRate" (comme débit d'horloge RTP) et ensuite le nombre réel de canaux sans considération du paramètre channelID.

o	Les paramètres "ptime" et "maxptime" vont dans les attributs SDP "a=ptime" et "a=maxptime", respectivement.

o	Tous les paramètres restants vont dans l'attribut SDP "a=fmtp" en les copiant directement de la chaîne de type de supports comme une liste séparée de points-virgules des paires de paramètre=valeur. 

Sur cette ligne, les paramètres "baseLayer" et "blockLength" DOIVENT être présents dans cet ordre.

La valeur de "blockLength" DOIT être 1024 ou 2048, pour utiliser, respectivement, ATRAC3 et ATRAC-X comme couche de base. Si "baseLayer=0" (ce qui signifie le mode standard) "blockLength" DOIT être 512, 1024, ou 2048. Le paramètre "channelID" DOIT être l'entrée suivante. Le receveur DOIT supposer une valeur par défaut de "15" pour "maxRedundantFrames".

 	7.6	Considérations sur le modèle d'offre/réponse
Certaines options de codage et décodage des données audios ATRAC vont exiger que l'envoyeur ou/et le receveur se conforment à certaines spécifications. Afin d'établir un cadre interopérable de transmission, une négociation d'offre/réponse dans SDP DOIT respecter les considérations suivantes. (Voir la [RFC3264].)

 	7.6.1	Pour les trois sous types de supports
o	Chaque combinaison des paramètres de configuration de format de transport de charge utile RTP (baseLayer et blockLength, sampleRate, channelID) est unique dans son schéma binaire et non compatible avec toute autre combinaison. Quand il crée une offre dans une application qui désire utiliser les caractéristiques les plus avancées (taux d'échantillonnage au-dessus de 44 100 kHz, plus de deux canaux) l'offreur DEVRAIT aussi offrir un type de charge utile contenant seulement le plus faible ensemble d'exigences nécessaires. Si plusieurs configurations sont intéressantes pour l'application, elles peuvent toutes être offertes.

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

 	7.6.2	Pour le sous type de support ATRAC3
o	En réponse à une offre, des sous ensembles dégradés de "baseLayer" sont possibles. Cependant, pour de meilleures performances, on suggère que la réponse contienne les plus hautes valeurs offertes possibles.

 	7.6.3	Pour le sous type de support ATRAC-X
o	En réponse à une offre, des sous ensembles dégradés de "sampleRate", "baseLayer", et "channelID" sont possibles. Pour de meilleures performances, une réponse NE DOIT PAS contenir de valeurs exigeant plus de capacités que ne contient l'offre, mais elle DEVRAIT fournir des valeurs aussi proches que possible de celles de l'offre.

o	Le "maxRedundantFrames" est un minimum suggéré. Cette valeur PEUT être augmentée dans une réponse (avec un maximum de 15) mais NE DOIT PAS être réduite.

o	Le paramètre facultatif "delayMode" est non négociable. Si le répondeur ne peut pas se conformer à la valeur offerte, la session DOIT être réputée inopérable.

 	7.6.4	Pour le sous type de support ATRAC Advanced Lossless
o	En réponse à une offre, des sous ensembles dégradés de "sampleRate", "baseLayer", et "channelID" sont possibles. Pour de meilleures performances, une réponse NE DOIT PAS contenir de valeurs exigeant plus de capacités que n'en contient l'offre, mais elle DEVRAIT fournir des valeurs aussi proches que possible de celles de l'offre.

o	Il n'y a pas d'exigence, autre que les deux parties doivent être d'accord, pour négocier "blockLength".

o	"maxRedundantFrames" est un minimum suggéré. Cette valeur PEUT être augmentée dans une réponse (avec un maximum de 15) mais NE DOIT PAS être réduite.

o	Pour la transmission de flux multi-sessions adaptables de contenu ATRAC avancé sans pertes, les attributs d'identification de flux de supports, les informations de groupe, et les dépendances de décodage entre flux de couche de base et flux de couche d'amélioration DOIVENT être signalées dans SDP par le modèle d'offre/réponse. Dans ce cas, l'attribut de "group", "mid", et "depend" suivi par le paramètre approprié DOIT être utilisé dans SDP [RFC3388], [RFC5583] afin d'indiquer la dépendance de codage en couches. L'attribut de "group" suivi par le paramètre "DDP" est utilisé pour indiquer la relation entre le flux de couche de base et le flux de couche d'amélioration avec la dépendance de décodage. Chaque flux est identifié par l'attribut "mid", et la dépendance du flux de couche d'amélioration est défini par l'attribut "depend", car la couche d'amélioration est seulement utile quand la couche de base est disponible. Des exemples de signalisation de dépendance de décodage de ATRAC avancé sans pertes sont décrits aux paragraphes 7.8 et 7.9.

 	7.7	Usage de SDP déclaratif
En usage déclaratif, comme SDP dans le protocole de flux en temps réel (RTSP) [RFC2326] ou dans le protocole d'annonce de session (SAP) [RFC2974], les paramètres DOIVENT être interprétés comme suit :

o	Les paramètres de configuration de format de charge utile (baseLayer, sampleRate, channelID) sont tous déclaratifs et un participant DOIT utiliser la ou les configurations 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 faible.

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

o	L'attribut de "mid", "group", et "depend" DOIT être utilisé pour indiquer la relation et la dépendance de la couche de base et de la couche d'amélioration dans l'écoulement multi-sessions adaptable de contenu ATRAC ADVANCED LOSSLESS, comme décrit dans les paragraphes 7.6, 7.8, et 7.9.

 	7.8	Exemples de descriptions de session SDP
Exemple d'usage de ATRAC-X avec stéréo à 44 100 Hz :

v=0
o=atrac 2465317890 2465317890 IN IP4 service.exemple.com
s=ATRAC-X Streaming
c=IN IP4 192.0.2.1/127
t=3409539540 3409543140
m=audio 49120 RTP/AVP 99
a=rtpmap:99 ATRAC-X/44100/2
a=fmtp:99 baseLayer=128; channelID=2; delayMode=2
a=maxptime:47

Exemple d'usage de ATRAC-X avec établissement 5.1 à 48 000 Hz :

v=0
o=atrac 2465317890 2465317890 IN IP4 service.exemple.com
s=ATRAC-X 5.1ch Streaming
c=IN IP4 192.0.2.1/127
t=3409539540 3409543140
m=audio 49120 RTP/AVP 99
a=rtpmap:99 ATRAC-X/48000/6
a=fmtp:99 baseLayer=320; channelID=5
a=maxptime:43

Exemple d'usage de ATRAC avancé sans pertes en mode de transfert multiplexé à grande vitesse :

v=0
o=atrac 2465317890 2465317890 IN IP4 service.exemple.com
s=AAL Multiplexed Streaming
c=IN IP4 192.0.2.1/127
t=3409539540 3409543140
m=audio 49200 RTP/AVP 96
a=rtpmap:96 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:96 baseLayer=128; blockLength=2048; channelID=2
a=maxptime:47

Exemple d'usage de ATRAC avancé sans pertes en mode de transfert multi-sessions à grande vitesse. Dans ce cas, le flux de couche de base et le flux de couche d'amélioration sont identifiés respectivement par L1 et L2, et L2 dépend de L1 dans le décodage.

v=0
o=atrac 2465317890 2465317890 IN IP4 service.exemple.com
s=AAL Multi Session Streaming
c=IN IP4 192.0.2.1/127
t=3409539540 3409543140
a=group:DDP L1 L2
m=audio 49200 RTP/AVP 96
a=rtpmap:96 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:96 baseLayer=128; blockLength=2048; channelID=2
a=maxptime:47
a=mid:L1
m=audio 49202 RTP/AVP 97
a=rtpmap:97 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:97 baseLayer=0; blockLength=2048; channelID=2
a=maxptime:47
a=mid:L2
a=depend:97 lay L1:96

Exemple d'usage de ATRAC avancé sans pertes en mode standard :

m=audio 49200 RTP/AVP 99
a=rtpmap:99 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:99 baseLayer=0; blockLength=1024; channelID=2
a=maxptime:24

 	7.9	Exemple d'échange d'offre/réponse
L'exemple d'offre/réponse suivant montre comment un désir de contenu de flux multi-canaux est refusé par le receveur, qui répond avec seulement la capacité de recevoir du contenu stéréo :

Offre :

m=audio 49170 RTP/AVP 98 99
a=rtpmap:98 ATRAC-X/44100/6
a=fmtp:98 baseLayer=320; channelID=5
a=rtpmap:99 ATRAC-X/44100/2
a=fmtp:99 baseLayer=160; channelID=2

Réponse :

m=audio 49170 RTP/AVP 99
a=rtpmap:99 ATRAC-X/44100/2
a=fmtp:99 baseLayer=160; channelID=2

L'exemple d'offre/réponse suivant montre que le receveur répond avec un choix de paramètres pris en charge :

Offre :

m=audio 49170 RTP/AVP 97 98 99
a=rtpmap:97 ATRAC-X/44100/2
a=fmtp:97 baseLayer=128; channelID=2
a=rtpmap:98 ATRAC-X/44100/6
a=fmtp:98 baseLayer=128; channelID=5
a=rtpmap:99 ATRAC-X/48000/6
a=fmtp:99 baseLayer=320; channelID=5

Réponse :

m=audio 49170 RTP/AVP 97 98
a=rtpmap:97 ATRAC-X/44100/2
a=fmtp:97 baseLayer=128; channelID=2
a=rtpmap:98 ATRAC-X/44100/6
a=fmtp:98 baseLayer=128; channelID=5

L'exemple d'offre/réponse suivant montre un échange pour essayer d'utiliser ATRAC avancé sans pertes. L'offre contient trois options : mode de transfert multi-sessions à grande vitesse, mode de transfert multiplexé à grande vitesse et mode standard.

Offre :

// En mode de transfert multi-sessions à grande vitesse, L1 et L2 correspondent à la couche de base et à la couche d'amélioration, respectivement, et L2 dépend de L1 au décodage.

a=group:DDP L1 L2
m=audio 49200 RTP/AVP 96
a=rtpmap:96 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:96 baseLayer=132; blockLength=1024; channelID=2
a=maxptime:24
a=mid:L1

m=audio 49202 RTP/AVP 97
a=rtpmap:97 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:97 baseLayer=0; blockLength=2048; channelID=2
a=maxptime:24
a=mid:L2
a=depend:97 lay L1:96

// Mode de transfert multiplexé à grande vitesse
m=audio 49200 RTP/AVP 98
a=rtpmap:98 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:98 baseLayer=256; blockLength=2048; channelID=2
a=maxptime:47

// Mode standard
m=audio 49200 RTP/AVP 99
a=rtpmap:99 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:99 baseLayer=0; blockLength=2048; channelID=2
a=maxptime:47

Réponse :

a=group:DDP L1 L2
m=audio 49200 RTP/AVP 94
a=rtpmap:94 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:94 baseLayer=132; blockLength=1024; channelID=2
a=maxptime:24
a=mid:L1

m=audio 49202 RTP/AVP 95
a=rtpmap:95 ATRAC-ADVANCED-LOSSLESS/44100/2
a=fmtp:95 baseLayer=0; blockLength=2048; channelID=2
a=maxptime:24
a=mid:L2
a=depend:95 lay L1:94

Noter que les noms de format de charge utile (codage) et des sous types de supports sont insensibles à la casse dans les deux endroits. De même, les noms de paramètres sont insensibles à la casse dans les types de supports et dans la transposition par défaut en l'attribut SDP a=fmtp.

 	8.	Considérations relatives à l'IANA

Trois nouveaux sous types de supports, audio/ATRAC3, audio/ATRAC-X, et audio/ATRAC-ADVANCED-LOSSLESS, ont été enregistrés (voir la Section 7).

 	9.	Considérations sur la sécurité

Le format de charge utile comme décrit dans le présent document est soumis aux considérations sur la sécurité définies dans la [RFC3550] et tout profil applicable, par exemple, la [RFC3551]. Aussi, la sécurité de l'enregistrement de type de supports DOIT être prise en compte comme décrit dans la Section 5 de la [RFC4855].

La charge utile pour la famille ATRAC consiste seulement en données audio compressées à décoder et à présenter comme du son, et les spécifications des normes ATRAC3, ATRAC-X, et ATRAC avancé sans pertes [ATRAC3], [ATRAC-X], [ATRAC-AL] définissent strictement la syntaxe de flux binaire et le modèle de mémoire tampon du côté décodeur pour chaque codec. Donc ils ne peuvent pas porter de "contenu actif" qui pourrait imposer des effets collatéraux malveillants au receveur, et ils ne causent aucun problème de consommation illégale de ressources du côté receveur, pour autant que les flux binaires se conforment à leurs spécifications standard.

Ce format de charge utile ne met pas en œuvre de mécanismes de sécurité par lui-même. La confidentialité, la protection de l'intégrité, et l'authentification doivent être fournies par un mécanisme extérieur à ce format de charge utile, par exemple, SRTP [RFC3711].

 	10.	Considérations sur le décodage correct
 	10.1	Vérification des paquets
La vérification des paquets audio codés reçus DOIT être effectuée afin de s'assurer d'un décodage correct des paquets. Comme mise en œuvre la plus primitive, la comparaison de la taille de paquet et de la longueur de charge utile peut être prise en compte. Si la longueur du paquet UDP est supérieure à la longueur de paquet RTP, le paquet peut être accepté, mais les octets supplémentaires DOIVENT être ignorés. Dans le cas de réception d'un paquet UDP plus court ou de paquets codés de façon impropre, les paquets DOIVENT être éliminés.

 	10.2	Vérification de la validité des paquets
La vérification de validité des paquets audio reçus DOIT aussi être effectuée. Elle peut être effectuée par le processus de décodage, car le format ATRAC est conçu de telle sorte que la validité des trames de données peut être déterminée par l'algorithme de décodage. La réponse du décodeur exigée sur une trame mal formée est d'éliminer les données mal formées et de dissimuler les erreurs dans la sortie audio jusqu'à ce qu'une trame valide soit détectée et décodée. Ceci est supposé empêcher les défaillances et autre comportement anormal du décodeur en réponse aux erreurs ou attaques.

 	11.	Références
 	11.1	Références normatives

[ATRAC3]	ATRAC3 Standard Specification ver.1.1, Sony Corporation, 2003.

[ATRAC-X]	ATRAC-X Standard Specification ver.1.2, Sony Corporation, 2004.

[ATRAC-AL]	ATRAC Advanced Lossless Standard Specification ver.1.1, Sony Corporation, 2007.

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

[RFC3388]	G. Camarillo, G. Eriksson, J. Holler et H. Schulzrinne, "Groupage des lignes de support dans le protocole de description de session (SDP)", décembre 2002. (Remplacée par RFC5888)

[RFC3550]	H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson, "RTP : un protocole de transport pour les applications en temps réel", STD 64, DOI 10.17487/RFC3550, 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)

[RFC4288]	N. Freed et J. Klensin, "Spécifications du type de support et procédures d'enregistrement", BCP 13, décembre 2005.

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

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

[RFC5583]	T. Schierl, S. Wenger ,"Dépendance du décodage de support de signalisation dans le protocole de description de session (SDP)", juillet 2009. (P. S.)

 	11.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)

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

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

 	Adresse des auteurs

Mitsuyuki Hatanaka	Jun Matsumoto	
Sony Corporation, Japan	Sony Corporation, Japan	
1-7-1 Konan	1-7-1 Konan	
Minato-ku	Minato-ku	
Tokyo  108-0075	Tokyo  108-0075	
Japan	Japan	
mél : actech@jp.sony.com	mél : actech@jp.sony.com