Groupe de travail Réseau	J. van der Meer, Philips Electronics	
Request for Comments : 3640	D. Mackie, Apple Computer	
Catégorie : En cours de normalisation	V. Swaminathan, Sun Microsystems Inc.	
	D. Singer, Apple Computer	
	P. Gentric, Philips Electronics	
Traduction Claude Brière de L'Isle	novembre 2003	

Format de charge utile RTP 
pour le transport de flux élémentaires MPEG-4

Statut de ce mémoire
Le présent document spécifie un protocole 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 courante des "Normes officielles de protocoles de l'Internet" (STD 1) pour 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) The Internet Society (2003). Tous droits réservés.

Résumé
Le comité Groupe d'experts d'images animées (MPEG, Motion Picture Experts Group) (ISO/CEI JTC1/SC29 WG11) est un groupe de travail de l'ISO qui a produit la norme MPEG-4. MPEG définit des outils pour compresser des contenus comme des informations audio-visuelles en flux élémentaires. La présente spécification définit un format de charge utile RTP simple mais générique pour le transport de tout flux élémentaire MPEG-4 non multiplexé.
Table des Matières
1. Introduction	2
2. Portage de flux élémentaires MPEG-4 sur RTP	3
2.1 Signalisation par les paramètres de format MIME	3
2.2 Unités d'accès MPEG	3
2.3 Enchaînement des unités d'accès	3
2.4 Fragmentation des unités d'accès	3
2.5 Entrelaçage	4
2.6 Informations d'horodatage	4
2.7 Indication d'état des flux système MPEG-4	4
2.8 Indication d'accès aléatoire	5
2.9 Portage d'informations auxiliaires	5
2.10 Paramètres de format MIME et configuration de champs conditionnels	5
2.11 Structure globale du format de charge utile	5
2.12 Modes de transport des flux MPEG-4	5
2.13 Alignement sur la RFC 3016	6
3. Format de charge utile	6
3.1 Usage des champs d'en-tête RTP et RTCP	6
3.2 Structure de charge utile RTP	7
3.2.3.1 Fragmentation	9
3.3 Usage de cette spécification	12
4. Considérations relatives à l'IANA	15
4.1 Enregistrement de type MIME	15
4.2 Enregistrement des définitions de mode par l'IANA	19
4.3 Enchaînement des paramètres	19
4.4 Usage de SDP	19
5. Considérations sur la sécurité	19
6. Remerciements	20
Appendice. Usage de ce format de charge utile : analyse d'entrelaçage, exemples d'analyse de délai avec entrelaçage	20
A.1 Introduction	20
A.2 Désentrelaçage et dissimulation d'erreur	20
A.3 Entrelaçage de groupe simple	20
A.4 Entrelaçage de groupe plus subtil	21
A.5 Entrelaçage continu	22
Références	23
Références normatives	23
Références pour information	23
Adresse des auteurs	24
Déclaration complète de droits de reproduction	24

1.	Introduction

Le comité MPEG est le groupe de travail 11 (WG11) dans le sous comité 29 du comité technique conjoint n° 1 de l'ISO/CEI qui a spécifié les normes MPEG-1, MPEG-2 et, plus récemment, MPEG-4 [MPEG-4]. La norme MPEG-4 spécifie la compression des données audio-visuelles en, par exemple, un flux élémentaire audio ou vidéo. Dans la norme MPEG-4, ces flux prennent la forme d'objets audio-visuels qui peuvent être arrangés en une scène audio-visuelle au moyen d'une description de scène. Chaque flux élémentaire MPEG-4 consiste en une séquence d'unités d'accès (AU, unité d'accès). Des exemples d'unité d'accès sont une trame audio et une image vidéo.

La présente spécification définit une structure générale et configurable de charge utile pour transporter les flux MPEG-4 élémentaires, en particulier les flux MPEG-4 audios (incluant la parole), les flux MPEG-4 vidéos et aussi les flux de systèmes MPEG-4, comme les flux de format binaire de scènes (BIFS, BInary Format for Scenes) d'informations de contenu d'objet (OCI, Object Content Information) de descripteur d'objet (OD, Object Descriptor) et de gestion et protection de propriété intellectuelle (IPMP, Intellectual Property Management and Protection). La charge utile RTP définie dans le présent document est de mise en œuvre simple et d'une efficacité raisonnable. Elle permet un entrelacement facultatif des unités d'accès (comme les trames audios) pour augmenter la résilience aux erreurs lors des pertes de paquet.

Certains types de flux élémentaires MPEG-4 incluent des informations "cruciales" dont la perte ne peut pas être tolérée. Cependant, RTP ne fournit pas de transmission fiable, de sorte que la réception de ces informations cruciales n'est pas assurée. Le paragraphe 3.2.3.4 spécifie comment l'état du flux est transporté afin que le receveur puisse détecter la perte d'informations cruciales et cesse de décoder jusqu'à ce que le prochain point d'accès aléatoire ait été reçu. Les applications qui transmettent des flux qui incluent des informations cruciales, comme les commandes OD, les commandes BIFS, ou du contenu de programmation comme MPEG-J (Java) et ECMAScript, devraient inclure des points d'accès aléatoires, à une périodicité convenable selon la probabilité de perte, afin de réduire la corruption de flux à un niveau acceptable. Un exemple est le mécanisme de carrousel défini par MPEG dans la norme ISO/CEI 14496-1 [MPEG-4].

De telles applications peuvent aussi employer des protocoles ou services supplémentaires pour réduire la probabilité de pertes. À la couche RTP, ces mesures incluent des formats de charge utile et des profils pour la retransmission ou la correction d'erreur directe (comme dans la [RFC2733]), qui doivent être employés en prenant en compte le contrôle d'encombrement. Une autre solution qui peut être appropriée pour certaines applications est de porter RTP sur TCP (comme au paragraphe 10.12 de la [RFC2326]). À la couche réseau, l'allocation de ressource ou le service préférentiel peuvent être disponibles pour réduire la probabilité de pertes. Pour une description générale des méthodes de réparation des supports de flux, voir la [RFC2354].

Bien que le format de charge utile RTP défini dans le présent document soit capable de transporter tout flux MPEG-4, d'autres formats, plus spécifiques, peuvent exister, comme celui de la [RFC3016] pour le transport de vidéo MPEG-4 (ISO/CEI 14496 [MPEG-4] partie 2).

La configuration de la charge utile est fournie pour s'accommoder du transport de tout flux MPEG-4 à tout débit binaire possible. Cependant, pour un flux élémentaire MPEG-4 spécifique, seulement très peu de configurations sont normalement nécessaires. Ainsi, pour permettre la conception de receveurs simplifiés, mais dédiés, la présente spécification exige que des modes spécifiques soient définis pour le transport des flux MPEG-4. Le présent document définit des modes pour les flux MPEG-4 CELP et AAC, ainsi que un mode générique qui peut être utilisé pour transporter tout flux MPEG-4. À l'avenir, de nouvelles RFC sont attendues pour spécifier des modes supplémentaires pour le transport de flux MPEG-4.

Le format de charge utile RTP défini dans le présent document spécifie le portage d'informations en rapport avec le système qui sont souvent équivalentes aux informations qui peuvent être contenues dans la couche Sync (SL, Sync Layer) MPEG-4 comme défini dans les systèmes [MPEG-4]. Le présent document ne prescrit pas comment transcoder ou transposer les informations de SL en des champs définis dans le format de charge utile RTP. Un tel traitement, s'il en est, est laissé à la discrétion de l'application. Cependant, pour anticiper le besoin à l'avenir du transport de toutes informations supplémentaires en rapport avec le système, un champ auxiliaire peut être configuré pour porter de telles données.

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

2.	Portage de flux élémentaires MPEG-4 sur RTP
2.1	Signalisation par les paramètres de format MIME
Avec ce format de charge utile, un seul flux élémentaire MPEG-4 peut être transporté. Les informations sur le type de flux MPEG-4 porté dans la charge utile sont convoyées par les paramètres de format MIME, comme dans le message SDP [RFC2327] ou par d'autres moyens (voir la Section 4). Ces paramètres de format MIME spécifient la configuration de la charge utile. Pour permettre des receveurs simplifiés et dédiés, un paramètre de format MIME est disponible pour signaler un mode spécifique d'utilisation de cette charge utile. Une définition de mode PEUT inclure le type de flux élémentaire MPEG-4, ainsi que la configuration appliquée, afin d'éviter que les receveurs aient besoin d'analyser tous les paramètres de format MIME. Le mode appliqué DOIT être signalé.

2.2	Unités d'accès MPEG
Pour le portage de données audio-visuelles compressées, MPEG définit des unités d'accès. Une unité d'accès (AU, unité d'accès) MPEG est la plus petite entité de données à laquelle des informations de temps sont attribuées. Dans le cas de l'audio, une unité d'accès peut représenter une trame audio et dans le cas de vidéo, une image. Les unités d'accès MPEG sont alignées sur l'octet, par définition. Si, par exemple, une trame audio n'est pas alignée sur l'octet, jusqu'à 7 bits de bourrage à zéro DOIVENT être insérés à la fin de la trame pour réaliser les unités d'accès alignées sur l'octet, comme exigé par la spécification MPEG-4. Les décodeurs MPEG-4 DOIVENT être capables de décoder des AU dans lesquelles un tel bourrage est appliqué.

En cohérence avec la spécification MPEG-4, le présent document exige que chaque unité d'accès vidéo MPEG-4 partie 2 inclue toutes les données codées d'une image, tous les en-têtes de flux vidéo qui peuvent précéder les données d'image codées, et tout bourrage de flux vidéo qui peut les suivre, jusque, mais sans l'inclure, au code de début qui indique le commencement d'un nouveau flux vidéo ou l'unité d'accès suivante.

2.3	Enchaînement des unités d'accès
Il est fréquemment possible de porter plusieurs unités d'accès dans un paquet RTP. C'est particulièrement utile pour l'audio, par exemple, quand AAC est utilisé pour le codage d'un signal stéréo à 64 kbit/s, les trames AAC contiennent en moyenne, approximativement 200 octets. Sur un LAN avec une MTU de 1500 octets, cela permet de porter une moyenne de 7 trames AAC complètes par paquet RTP.

Les unités d'accès peuvent avoir une taille fixe en octets, mais une taille variable est aussi possible. Pour faciliter l'analyse dans le cas de multiples AU enchaînées dans un paquet RTP, la taille de chaque AU est communiquée au receveur. Lors d'un enchaînement dans le cas d'une taille d'AU constante, cette taille est communiquée "hors bande" par un paramètre de format MIME. Lors d'un enchaînement dans le cas d'AU de taille variable, la charge utile RTP porte "dans la bande" un  champ Taille d'AU pour chaque AU contenue.

En combinaison avec la longueur de charge utile RTP, les informations de taille permettent à la charge utile RTP d'être repartagée par le receveur entre les AU individuelles.

Pour simplifier la mise en œuvre des receveurs RTP, il est exigé que lorsque des AU multiples sont portées dans un paquet RTP, chaque AU DOIT être complète, c'est-à-dire, le nombre d'AU dans un paquet RTP DOIT être entier.

De plus, une AU NE DOIT PAS être répétée dans d'autres paquets RTP ; donc, la répétition d'une AU n'est possible que lorsque on utilise un paquet RTP dupliqué.

2.4	Fragmentation des unités d'accès
MPEG permet de très grandes unités d'accès. Comme la plupart des réseaux IP ont des tailles de MTU significativement plus petites, ce format de charge utile permet la fragmentation d'une unité d'accès sur plusieurs paquets RTP. Donc, lorsque un paquet IP est perdu après une fragmentation de niveau IP, seul un fragment d'AU sera perdu au lieu de l'AU entière. Pour simplifier la mise en œuvre de receveurs RTP, un paquet RTP DEVRA soit porter une ou plusieurs unités d'accès complètes, soit un seul fragment d'une AU, c'est-à-dire que les paquets NE DOIVENT PAS contenir des fragments de plusieurs unités d'accès.

2.5	Entrelaçage
Lorsque un paquet RTP porte une séquence d'unités d'accès contiguës, la perte d'un tel paquet peut résulter en un "trou de décodage" pour l'usager. Une méthode pour atténuer ce problème est de permettre d'entrelacer les unités d'accès dans les paquets RTP. Pour un coût modeste en latence et en complexité de mise en œuvre, on peut réaliser une résilience significative à l'erreur à l'égard des pertes de paquet.

Pour prendre en charge l'entrelaçage facultatif des unités d'accès, le présent format de charge utile permet que des informations d'indice soient envoyées pour chaque unité d'accès envoyée. Après l'information des receveurs sur les ressources de mémoire tampon à allouer pour le désentrelaçage, l'envoyeur RTP a la liberté de choisir le schéma d'entrelaçage sans propager cette information a priori aux receveurs. Bien sûr, l'envoyeur pourrait ajuster de façon dynamique le schéma d'entrelaçage sur la base de la taille de l'unité d'accès, du taux d'erreurs, etc. Le receveur RTP n'a pas besoin de savoir le schéma d'entrelaçage utilisé, il a seulement besoin d'extraire les informations d'indice de l'unité d'accès et d'insérer l'unité d'accès dans la séquence appropriée dans la file d'attente de décodage ou de rendu. Un exemple d'entrelaçage est donné ci-dessous.

Par exemple, si on suppose qu'un paquet RTP contient trois AU, et que les AU sont numérotées 0, 1, 2, 3, 4, etc., et si une longueur de groupe d'entrelaçage de 9 est choisie, le paquet RTP(i) contient alors l'AU(n) suivante :

paquet RTP(0) : AU(0), AU(3), AU(6)
paquet RTP(1) : AU(1), AU(4), AU(7)
paquet RTP(2) : AU(2), AU(5), AU(8)
paquet RTP(3) : AU(9), AU(12), AU(15)
paquet RTP(4) : AU(10), AU(13), AU(16),   etc.

2.6	Informations d'horodatage
L'horodatage RTP DOIT porter l'instant d'échantillonnage de la première AU (fragment) dans le paquet RTP. Lorsque plusieurs AU sont portées au sein d'un paquet RTP, les horodatages des AU suivantes peuvent être calculés si la période de trame de chaque AU est connue. Pour l'audio et la vidéo, ceci est possible si le taux de trame est constant. Cependant, dans certains cas, il n'est pas possible de faire un tel calcul (par exemple, pour une vidéo à débit de trame variable, ou pour des flux BIFS MPEG-4 qui portent des informations de composition). Pour prendre en charge de tels cas, ce format de charge utile peut être configuré à porter un horodatage dans la charge utile RTP pour chaque unité d'accès contenue. Un horodatage PEUT être convoyé dans la charge utile RTP pour les seules AU non premières dans le paquet RTP, et NE DEVRA PAS être convoyé pour la première AU (fragment), car l'horodatage pour la première AU du paquet RTP est porté par l'horodatage RTP.

MPEG-4 définit deux types d'horodatages : l'horodatage de composition (CTS, Composition Time Stamp) et l'horodatage de décodage (DTS, Decoding Time Stamp). Le CTS représente l'instant d'échantillonnage d'une AU, et donc, le CTS est équivalent à l'horodatage RTP. Le DTS peut être utilisé dans les flux vidéo MPEG-4 qui utilisent le codage bidirectionnel, c'est-à-dire, lorsque les images sont prédites dans les deux directions vers l'avant et vers l'arrière en utilisant soit une image de référence passée, soit une image de référence future. Le DTS ne peut pas être porté dans l'en-tête RTP. Dans certains cas, le DTS peut être déduit de l'horodatage RTP en utilisant des informations de débit de trame ; cela exige une analyse en profondeur du flux vidéo, qui peut être considérée comme critiquable. Si la trame vidéo est variable, les informations requises peuvent n'être même pas présentes dans le flux vidéo. Pour ces deux raisons, la capacité a été définie comme portant facultativement le DTS dans la charge utile RTP pour chaque unité d'accès contenue.

Pour conserver l'efficacité du codage des horodatages, chaque horodatage contenu dans la charge utile RTP est codé comme une différence. Pour le CTS, le décalage aux horodatages RTP est fourni, et pour le DTS, le décalage au CTS.

2.7	Indication d'état des flux système MPEG-4
La norme ISO/CEI 14496-1 définit les états pour les flux systèmes MPEG-4. De façon à convoyer les informations d'état lors du transport de flux systèmes MPEG-4, ce format de charge utile permet le portage facultatif dans la charge utile RTP de l'état du flux pour chaque unité d'accès contenue. Les états de flux sont utilisés pour signaler les AU "cruciales" qui portent des informations dont la perte ne peut pas être tolérée et sont aussi utiles lors de la répétition des AU selon le mécanisme de carrousel défini dans la norme ISO/CEI 14496-1.

2.8	Indication d'accès aléatoire
L'accès aléatoire au contenu des flux élémentaires MPEG-4 est possible à certaines unités d'accès, mais pas à toutes. Pour signaler les unités d'accès où l'accès aléatoire est possible, un fanion de point d'accès aléatoire peut facultativement être porté dans la charge utile RTP pour chaque unité d'accès contenue. Le portage de points d'accès aléatoire est particulièrement utile pour les flux systèmes MPEG-4 en combinaison avec l'état du flux.

2.9	Portage d'informations auxiliaires
Ce format de charge utile définit un champ spécifique pour porter les données auxiliaires.

Le champ Données auxiliaires est précédé par un champ qui spécifie la longueur des données auxiliaires, afin de faciliter le pilotage des données sans les analyser. Le codage des données auxiliaires n'est pas défini dans le présent document ; à la place, on s'attend à ce que le format, la signification et la signalisation des informations auxiliaires soient spécifiées dans une ou plusieurs futures RFC. Les informations auxiliaires NE DOIVENT PAS être transmises tant que leur format, signification et signalisation n'ont pas été spécifiées et que leur utilisation n'a pas été signalée. Les receveurs qui ont connaissance des données auxiliaires PEUVENT les décoder, mais les receveurs qui n'en ont pas connaissance DOIVENT sauter le champ Données auxiliaires.

2.10	Paramètres de format MIME et configuration de champs conditionnels
Pour prendre en charge les caractéristiques décrites dans les paragraphes précédents, plusieurs champs sont définis pour portage dans la charge utile RTP. Cependant, leur utilisation dépend fortement du type de flux élémentaire MPEG-4 qui est porté. Parfois un champ spécifique est nécessaire avec une certaine longueur, tandis que dans d'autres cas, un tel champ n'est pas nécessaire. Pour être efficace dans tous les cas, les champs pour la prise en charge de ces caractéristiques sont configurables au moyen de paramètres de format MIME. En général, un paramètre de format MIME définit la présence et la longueur du champ associé. Une longueur de zéro indique l'absence du champ. En conséquence, l'analyse de la charge utile exige la connaissance des paramètres de format MIME. Les paramètres de format MIME sont convoyés jusqu'au receveur via des messages SDP [RFC2327], comme spécifié au paragraphe 4.4.1, ou par d'autres moyens.

2.11	Structure globale du format de charge utile
La charge utile RTP suivant l'en-tête RTP, contient trois sections de données alignées sur l'octet, dont les deux premières PEUVENT être vides, voir la Figure 1.

         +---------+-----------+-----------+---------------+
         | En-tête | Section   |  Section  |Section données|
         |  RTP    |en-tête AU | auxiliaire|d'unité d'accès|
         +---------+-----------+-----------+---------------+
                   <------Charge utile de paquet RTP------->

Figure 1 : Sections de données au sein d'un paquet RTP

La première section de données est la section En-tête d'AU, qui contient un ou plusieurs en-têtes d'AU ; cependant, chaque en-tête d'AU PEUT être vide, auquel cas la section d'en-tête d'AU entière est vide. La seconde section est la section auxiliaire, contenant les données auxiliaires ; cette section PEUT aussi être vide par configuration. La troisième section est la section Données d'unité d'accès, contenant soit un seul fragment d'une unité d'accès, soit une ou plusieurs unités d'accès complètes. La section Données d'unité d'accès NE DOIT PAS être vide.

2.12	Modes de transport des flux MPEG-4
Bien qu'il soit possible de construire des receveurs pleinement configurables capables de recevoir tout flux MPEG-4, la présente spécification permet aussi la conception de receveurs simplifiés, mais dédiés, qui sont, par exemple, capables de recevoir seulement un type de flux MPEG-4. Ceci se fait en exigeant que des modes spécifiques soient définis afin d'utiliser la présente spécification. Chaque mode peut définir des contraintes pour le transport d'un ou plusieurs types de flux MPEG-4, par exemple sur la configuration de charge utile .

Le mode appliqué DOIT être signalé. La signalisation du mode est particulièrement importante pour les receveurs qui ne sont capables de décoder qu'un ou plusieurs modes spécifiques. De tels receveurs ont besoin de déterminer si le mode appliqué est supporté, afin d'éviter des problèmes avec le traitement de charges utiles qui vont au delà des capacités du receveur.

Dans le présent document sont définis plusieurs modes pour le transport de flux MPEG-4 CELP et AAC, ainsi qu'un mode générique qui peut être utilisé pour tout flux MPEG-4. À l'avenir, de nouvelles RFC pourront spécifier d'autres modes d'utilisation de la présente spécification. Cependant, chaque mode DOIT être pleinement conforme à la présente spécification (voir au paragraphe 3.3.7).

2.13	Alignement sur la RFC 3016
Cette charge utile peut être configurée comme presque identique au format de charge utile défini dans la [RFC3016] pour les configurations de vidéo MPEG-4 recommandées dans la [RFC3016]. Donc, les receveurs qui se conforment à la [RFC3016] peuvent décoder de telles charges utiles RTP, pourvu que des paquets supplémentaires contenant une configuration de décodeur vidéo (VO, VOL, VOSH) soient insérés dans le flux, comme exigé par la [RFC3016]. À l'inverse, les receveurs qui se conforment aux spécifications du présent document DEVRAIENT être capables de décoder les charges utiles, les noms et paramètres définis pour la vidéo MPEG-4 dans la [RFC3016]. À cet égard, il est fortement RECOMMANDÉ que la mise en œuvre donne la capacité d'ignorer les paquets de configuration de décodeur vidéo "dans la bande" qui pourraient se trouver dans les flux qui se conforment à la charge utile vidéo de la [RFC3016].

Noter que la disponibilité "hors bande" de la configuration du décodeur vidéo est facultative dans la [RFC3016]. Pour réaliser le maximum d'interopérabilité avec le format de charge utile RTP défini dans le présent document, les applications qui utilisent la [RFC3016] pour transporter la vidéo MPEG-4 (partie 2) sont recommandées pour faire que la configuration de décodeur vidéo soit disponible comme paramètre MIME.

3.	Format de charge utile
3.1	Usage des champs d'en-tête RTP et RTCP
Type de charge utile (PT, Payload Type) : 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 est utilisé ce format de charge utile, ou signalé dynamiquement hors bande (par exemple, en utilisant SDP).

Bit marqueur (M, Marker) : le bit M est réglé à 1 pour indiquer que la charge utile du paquet RTP contient soit le fragment final d'une unité d'accès fragmentée, soit une ou plusieurs unités d'accès complètes.

Bit d'extension (X) : défini par le profil RTP utilisé.

Numéro de séquence : le numéro de séquence RTP DEVRAIT être généré par l'envoyeur de la façon usuelle avec un décalage aléatoire constant.

Horodatage : indique l'instant d'échantillonnage de la première AU contenue dans la charge utile RTP. Cet instant d'échantillonnage est équivalent au CTS dans le domaine horaire MPEG-4. Lorsque on utilise SDP, le débit d'horloge de l'horodatage RTP DOIT être exprimé en utilisant l'attribut "rtpmap". Si un flux audio MPEG-4 est transporté, le débit DEVRAIT être réglé à la même valeur que le taux d'échantillonnage du flux audio. Si un flux vidéo MPEG-4 est transporté, il est RECOMMANDÉ que le taux soit réglé à 90 kHz.

Dans tous les cas, l'envoyeur DEVRA s'assurer que les horodatages RTP ne sont identiques que si l'horodatage RTP se réfère à des fragments de la même unité d'accès.

Selon le paragraphe 5.1 de la [RFC3550], il est RECOMMANDÉ pour des raisons de sécurité que les horodatages RTP commencent à une valeur aléatoire. Ce n'est pas un problème pour la synchronisation de plusieurs flux RTP. Cependant, lorsque les flux de plusieurs sources sont à synchroniser (par exemple un flux provenant d'une mémorisation locale, un autre provenant d'un serveur de flux RTP) la synchronisation peut devenir impossible si le receveur ne connaît que les relations d'horodatage d'origine. Dans de tels cas, la relation d'horodatage requise pour obtenir la synchronisation peut être fournie par des moyens hors bande. Le format de telles informations, ainsi que les méthodes de portage de telles informations, sortent du domaine d'application de la présente spécification.

SSRC : réglé comme décrit dans la [RFC3550].

Les champs CC et CSRC sont utilisés comme décrit dans la [RFC3550].

RTCP DEVRAIT être utilisé comme défini dans la [RFC3550]. Noter que les horodatages dans les rapports d'envoi RTCP peuvent être utilisés pour synchroniser plusieurs flux élémentaires MPEG-4 et aussi pour synchroniser des flux MPEG-4 avec des flux non MPEG-4, dans le cas où la livraison de ces flux utilise RTP.

3.2	Structure de charge utile RTP
3.2.1	Section d'en-tête d'AU
Lorsque présente, la section d'en-tête d'AU consiste en le champ Longueur des en-têtes d'AU, suivi par un certain nombre d'en-têtes d'AU, comme indiqué à la Figure 2.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. -+-+-+-+-+-+-+-+-+-+-+
|Longueur en-têtes| en-tête | en-tête |      | en-tête | bits de |
|     d'AU        | d'AU (1)| d'AU (2)|      | d'AU (n)| bourrage|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. -+-+-+-+-+-+-+-+-+-+-+

Figure 2 : Section d'en-tête AU

Les en-têtes d'AU sont configurés en utilisant les paramètres de format MIME et PEUVENT être vides. Si l'en-tête d'AU est configuré vide, le champ Longueur d'en-tête d'AU NE DEVRA PAS être présent et par conséquent la section d'en-tête d'AU est vide. Si l'en-tête d'AU n'est pas configuré vide, la longueur d'en-tête d'AU est un champ de deux octets qui spécifie la longueur en bits des en-têtes d'AU suivant immédiatement, excluant les bits de bourrage.

Chaque en-tête d'AU est associé à une seule unité d'accès (fragment) contenue dans la section Données de l'unité d'accès dans le même paquet RTP.

Pour chaque unité d'accès (fragment) contenue, il a exactement un en-tête d'AU. Au sein de la section En-tête d'AU, les en-têtes d'AU sont enchaînées au bit près dans l'ordre dans lequel les unités d'accès sont contenues dans la section Données de l'unité d'accès. Donc, le nième en-tête d'AU se réfère à la nième AU (fragment). Si les en-têtes d'AU enchaînés consomment un nombre non entier d'octets, jusqu'à 7 bits à zéro de bourrage DOIVENT être insérés à la fin pour réaliser l'alignement sur l'octet de la section d'en-tête d'AU.

3.2.1.1	En-tête d'AU
Chaque en-tête d'AU peut contenir les champs Données dans la Figure 3. La longueur en bits des champs, à l'exception des champs fanion CTS, fanion DTS et fanion RAP, est définie par les paramètres de format MIME ; voir au paragraphe 4.1. Si un paramètre de format MIME a la valeur par défaut de zéro, alors le champ associé n'est pas présent. Le nombre de bits pour les champs qui sont présents et qui représentent la valeur d'un paramètre DOIT être choisi assez grand pour coder correctement la plus grande valeur de ce paramètre durant la session.

Si ils sont présents, les champs DOIVENT survenir dans l'ordre donné à la Figure 3. Dans le cas général, un receveur peut seulement découvrir la taille d'un en-tête d'AU en l'analysant car la présence des champs delta CTS et delta DTS est signalée par la valeur des fanions respectivement CTS et DTS.

      +---------------------------------------+
      |     Taille d'AU                       |
      +---------------------------------------+
      |     Indice d'AU / delta d'indice d'AU |
      +---------------------------------------+
      |     Fanion CTS                        |
      +---------------------------------------+
      |     Delta de CTS                      |
      +---------------------------------------+
      |     Fanion DTS                        |
      +---------------------------------------+
      |     Delta de DTS                      |
      +---------------------------------------+
      |     Fanion RAP                        |
      +---------------------------------------+
      |     État de flux                      |
      +---------------------------------------+

Figure 3 : Champs dans l'en-tête d'AU

Si il est utilisé, le champ indice d'AU ne survient que dans le premier en-tête d'AU au sein d'une section d'en-tête d'AU ; dans tout autre en-tête d'AU, c'est le champ Delta d'indice d'AU qui apparaît.

Taille d'AU : indique la taille en octets de l'unité d'accès associée dans la section Données de l'unité d'accès dans le même paquet RTP. Lorsque la taille d'AU est associée à un fragment d'AU, la taille d'AU indique la taille de l'AU entière et non la taille du fragment. Dans ce cas, la taille du fragment est connue à partir de la taille de la section Données de l'AU. Ceci peut être exploité pour déterminer si un paquet contient une AU entière ou un fragment, ce qui est particulièrement utile après la perte d'un paquet qui porte le dernier fragment d'une AU.

Indice d'AU : indique le numéro de série de l'unité d'accès (fragment) associée. Pour chaque AU ou fragment d'AU consécutif (dans l'ordre du décodage) le numéro de série est incrémenté de 1. Lorsque il est présent, le champ Indice d'AU survient dans le premier en-tête d'AU dans la section En-tête d'AU, mais NE DOIT PAS survenir dans un en-tête d'AU suivant (non premier) dans cette section. Pour coder le numéro de série dans un tel en-tête d'AU non premier, on utilise le champ Delta d'indice d'AU.

Delta d'indice d'AU : le champ Delta d'indice d'AU est un entier non signé qui spécifie le numéro de série de l'AU associée comme la différence par rapport au numéro de série de l'unité d'accès précédente. Donc, pour la nième (n > 1) AU, le numéro de série est trouvé à partir de : indice d'AU(n) = indice d'AU(n - 1) + delta d'indice d'AU(n) + 1

Si le champ indice d'AU est présent dans le premier en-tête d'AU dans la section En-tête d'AU, le champ Delta d'indice d'AU DOIT être présent dans tout en-tête d'AU suivant (non premier). Lorsque le delta d'indice d'AU est codé avec la valeur 0, cela indique que les unités d'accès sont consécutives dans l'ordre de décodage. Une valeur de delta d'indice d'AU supérieure à 0 signale que l'entrelaçage est appliqué.

Fanion CTS : indique si le champ Delta CTS est présent. Une valeur de 1 indique que le champ est présent, une valeur de 0 indique qu'il n'est pas présent.

Le champ Fanion CTS DOIT être présent dans chaque en-tête d'AU si la longueur du champ Delta CTS est signalée comme étant supérieure à zéro. Dans ce cas, le champ Fanion CTS DOIT avoir la valeur 0 dans le premier en-tête d'AU et PEUT avoir la valeur 1 dans tous les en-têtes d'AU non premiers. Le champ Delta CTS DEVRAIT être 0 pour tout fragment non premier d'une unité d'accès.

Delta CTS : code le CTS en spécifiant la valeur du CTS comme un décalage (delta) de complément à deux sur l'horodatage dans l'en-tête RTP de ce paquet RTP. Le CTS DOIT utiliser le même débit d'horloge que l'horodatage dans l'en-tête RTP.

Fanion DTS : indique si le champ Delta DTS est présent. Une valeur de 1 indique que Delta DTS est présent, une valeur de 0 qu'il n'est pas présent. Le champ Delta DTS DOIT être présent dans chaque en-tête d'AU si la longueur du champ Delta DTS est signalée comme supérieure à zéro. Le champ Fanion DTS DOIT avoir la même valeur pour tous les fragments d'une unité d'accès.

Delta DTS : spécifie la valeur du DTS comme décalage (delta) de complément à deux par rapport au CTS. Le DTS DOIT utiliser le  même débit d'horloge que l'horodatage dans l'en-tête RTP. Le champ Delta DTS DOIT avoir la même valeur pour tous les fragments d'une unité d'accès.

Fanion RAP : lorsque il est réglé à 1, il indique que l'unité d'accès associée fournit un point d'accès aléatoire au contenu du flux. Si une unité d'accès est fragmentée, le fanion RAP, si présent, DOIT être réglé à 0 pour chaque fragment non premier de l'AU.

État de flux : spécifie l'état du flux pour une AU dans un flux système MPEG-4 ; chaque état est identifié par la valeur d'un compteur modulaire. Dans la norme ISO/CEI 14496-1, le flux système MPEG-4 utilise le numéro de séquence d'AU pour signaler les états de flux. Lorsque l'état de flux change, la valeur de l'état de flux DOIT être incrémentée de un.

Note : aucune relation n'est requise entre les états de flux de flux différents.

3.2.2	Section auxiliaire
La section auxiliaire consiste en le champ Taille de données auxiliaires suivi par le champ Données auxiliaires. Les receveurs PEUVENT (mais ne sont pas obligés) analyser le champ Données auxiliaires ; pour faciliter le saut du champ Données auxiliaires par les receveurs, le champ Taille de données auxiliaires indique la longueur en bits des données auxiliaires. Si l'enchaînement des champs Taille de données auxiliaires et Données auxiliaires consomme un nombre non entier d'octets, jusqu'à 7 bits de bourrage à zéro DOIVENT être insérés immédiatement après les données afin de réaliser l'alignement sur l'octet. Voir la Figure 4.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .. -+-+-+-+-+-+-+-+-+
| Taille de données auxiliaires | Données auxiliaires   ..    |bits bourrage|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .. -+-+-+-+-+-+-+-+-+

Figure 4 : Champs de la section auxiliaire

La longueur en bits du champ Longueur de données auxiliaires est configurable par un paramètre de format MIME ; voir le paragraphe 4.1. La longueur par défaut de zéro indique que la section auxiliaire entière est absente.

Taille de données auxiliaires : spécifie la longueur en bits du champ Données auxiliaires qui suit immédiatement.

Données auxiliaires : le champ Données auxiliaires contient des données d'un format non défini par cette spécification.

3.2.3	Section Données de l'unité d'accès
La section Données de l'unité d'accès contient un nombre entier d'unités d'accès complètes ou un seul fragment d'une AU. La section Données de l'unité d'accès n'est jamais vide. Si des données de plus d'une unité d'accès sont présentes, les AU sont alors enchaînées dans une chaîne d'octets contigus. Voir la Figure 5. Les AU à l'intérieur de la section Données de l'unité d'accès DOIVENT être dans l'ordre du décodage, bien que non nécessairement contiguës dans le cas d'entrelaçage.

La taille et le nombre des unités d'accès DEVRAIENT être ajustés de façon que le paquet RTP résultant ne soit pas supérieur à la MTU de chemin. Pour traiter de plus grands paquets, ce format de charge utile s'appuie sur les couches inférieures pour la fragmentation, qui PEUT résulter en des performances réduites.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |AU(1)                                                          |
      +                                                               |
      |                                                               |
      |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               |AU(2)                                          |
      +-+-+-+-+-+-+-+-+                                               |
      |                                                               |
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               | AU(n)                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |AU(n) suite    |
      |-+-+-+-+-+-+-+-+

Figure 5 : section Données de l'unité d'accès ; chaque AU est alignée sur l'octet

Lorsque plusieurs unités d'accès sont portées, la taille de chaque AU DOIT être mise à la disposition du receveur. Si la taille d'AU est variable, la taille de chaque AU DOIT être indiquée dans le champ Taille d'AU de l'en-tête d'AU correspondant. Cependant, si la taille d'AU est constante pour un flux, ce mécanisme NE DEVRAIT PAS être utilisé ; la taille fixée DEVRAIT plutôt être signalée par le paramètre de format MIME "constantSize" ; voir le paragraphe 4.1.

L'absence dans l'en-tête d'AU à la fois de Taille d'AU et du paramètre de format MIME constantSize indique le portage d'une seule AU (fragment), c'est-à-dire, qu'une seule unité d'accès (fragment) est transportée dans chaque paquet RTP pour ce flux.

3.2.3.1	Fragmentation
Un paquet DEVRA porter soit une ou plusieurs unités d'accès complètes, soit un seul fragment d'une unité d'accès. Les fragments de la même unité d'accès ont le même horodatage mais des numéros de séquence RTP différents. Le bit marqueur dans l'en-tête RTP est à 1 sur le dernier fragment d'une unité d'accès, et à 0 sur tous les autres fragments.

3.2.3.2	Entrelaçage
Sauf interdit par le mode signalé, un envoyeur PEUT entrelacer les unités d'accès. Les receveurs qui sont capables de recevoir des modes qui supportent l'entrelaçage DOIVENT être capables de décoder les unités d'accès entrelacées.

Lorsque un envoyeur entrelace des unités d'accès, il doit fournir des informations suffisantes pour permettre à un receveur de reconstruire sans ambiguïté l'ordre d'origine, même dans le cas de paquets en désordre, de perte de paquets, ou de duplication. Les informations que les envoyeurs doivent fournir dépendent de si les unités d'accès ont ou non une durée constante. Les unités d'accès ont une durée constante si :

TS(i + 1) - TS(i) = constante

pour tout i, où i indique l'indice de l'AU dans l'ordre d'origine, et TS(i) note l'horodatage de l'AU(i).

Le paramètre MIME "constantDuration" DEVRAIT être utilisé pour signaler que les unités d'accès ont une durée constante  ; voir au paragraphe 4.1.

Si le paramètre "constantDuration" est présent, le receveur peut reconstruire le moment original de l'unité d'accès sur la seule base de l'horodatage RTP et du delta d'indice d'AU. Par conséquent, lors de la transmission d'unités d'accès de durée constante, l'indice d'AU, si présent, DOIT être réglé à la valeur 0. Les receveurs d'unités d'accès de durée constante DOIVENT utiliser l'horodatage RTP pour déterminer l'indice de la première AU dans le paquet RTP. Le delta d'indice d'AU et le paramètre signalé "constantDuration" sont utilisés pour reconstruire le moment de l'AU.

Si le paramètre "constantDuration" n'est pas là, les envoyeurs PEUVENT alors signaler les AU de durée constante en codant l'indice d'AU à zéro dans chaque paquet RTP. En l'absence du paramètre constantDuration, les receveurs DOIVENT conclure que les AU ont une durée constante si l'indice d'AU est à zéro dans deux paquets RTP consécutifs.

Lors de la transmission d'unités d'accès de durée variable, le paramètre "constantDuration" NE DOIT PAS être présent, et l'émetteur DOIT utiliser l'indice d'AU pour coder les informations d'indice requises pour réordonner, et le receveur DOIT utiliser cette valeur pour déterminer l'indice de chaque AU dans le paquet RTP. Le nombre de bits du champ Indice d'AU DOIT être choisi de façon que des informations d'indice valides soient fournies au schéma d'entrelaçage appliqué, sans causer de problèmes dus au retour à zéro du champ d'indice d'AU. De plus, le delta CTS DOIT être codé dans l'en-tête d'AU pour chaque AU non première dans le paquet RTP, afin que les receveurs puissent placer correctement les AU dans le temps.

Lorsque l'entrelaçage est appliqué, une mémoire tampon de désentrelaçage est nécessaire chez les receveurs pour mettre les unités d'accès dans leur ordre logique de décodage correct. Cela exige le calcul de l'horodatage pour chaque unité d'accès. Dans le cas de durée constante par unité d'accès, l'horodatage de la ième unité d'accès dans un paquet RTP avec l'horodatage RTP T est calculé comme suit :

Horodatage[0] = T
Horodatage[i, i > 0] = T +(Somme(pour k= de 1 à i de (delta d'indice d'AU[k] + 1))) * durée-d'unité-d'accès

Lorsque Delta d'indice d'AU est toujours 0, cela se réduit à T + i * (durée d'unité d'accès). C'est le cas de non entrelaçage, où les trames sont consécutives dans l'ordre de décodage. Noter que le champ Indice d'AU (présent pour la première unité d'accès) n'est bien sûr pas nécessaire dans ce calcul.

3.2.3.3	Contraintes de l'entrelaçage
La taille des paquets devrait être convenablement choisie pour être appropriée à la fois pour la MTU de chemin et la capacité de la mémoire tampon de désentrelaçage du receveur. La taille de paquet maximum pour une session DEVRAIT être choisie de façon à ne pas excéder la MTU de chemin. Pour permettre aux receveurs d'allouer des ressources suffisantes pour le désentrelaçage, les envoyeurs DOIVENT fournir des informations aux receveurs, comme spécifié dans cette section. Les AU entrent dans le décodeur dans l'ordre de décodage. La mémoire tampon de désentrelaçage est utilisée pour réordonner un flux d'AU entrelacées dans l'ordre de décodage. Lorsque l'entrelaçage est appliqué, le décodage des AU "précoces" doit être retardé jusqu'à ce que toutes les AU qui les précèdent dans l'ordre de décodage soient présentes. Donc, ces AU "précoces" sont mémorisées dans la mémoire tampon de désentrelaçage. À titre d'exemple dans la Figure 6, le schéma d'entrelaçage du paragraphe 2.5 est examiné.

                             +--+--+--+--+--+--+--+--+--+--+--+-
   AU entrelacées            | 0| 3| 6| 1| 4| 7| 2| 5| 8| 9|12|..
                             +--+--+--+--+--+--+--+--+--+--+--+-
   Mémorisation des AU précoces   3  3  3  3  3  3
                                     6  6  6  6  6  6
                                           4  4  4
                                              7  7  7
                                                            12 12

Figure 6 : Mémorisation des AU "précoces" dans la mémoire tampon de désentrelaçage par AU entrelacée.

AU(3) est à livrer au décodeur après AU(0), AU(1) et AU(2) ; de ces AU, AU(2) arrive en dernier du réseau et donc AU(3) doit être mémorisée jusqu'à ce que AU(2) soit présente dans le schéma. De même, AU(6) est à mémoriser jusqu'à ce que AU(5) soit présente, tandis que AU(4) et AU(7) sont à mémoriser jusqu'à ce que AU(2) et AU(5) soient respectivement présentes. Noter que le remplissage de la mémoire tampon de désentrelaçage varie dans le temps. Dans la Figure 6, la mémoire tampon de désentrelaçage contient au plus 4, mais souvent moins d'AU.

De façon à donner une indication grossière des ressources nécessaires chez le receveur pour le désentrelaçage, le déplacement maximum de temps d'une AU est défini. Pour toute AU(j) dans le schéma, chaque AU(i) avec i<j qui n'est pas déjà présente peut être déterminée. Le déplacement maximum de temps d'une AU est la différence maximale entre l'horodatage d'une AU dans le schéma et l'horodatage de la première AU qui n'est pas encore présente. En d'autres termes, quand on considère une séquence d'AU entrelacées, alors :

Déplacement maximum = max{TS(i) - TS(j)}

pour tout i et tout j>i, où i et j indiquent l'indice de l'AU dans le schéma d'entrelaçage, et TS note l'horodatage de l'AU.

Dans l'exemple de la Figure 7, le schéma d'entrelaçage du paragraphe 2.5 est pris en compte. Pour chaque AU du schéma, l'indice est donné de la première de toutes les AU antérieures non encore présentes. Donc pour chaque AU(n) dans le schéma d'entrelaçage le plus petit indice k (avec k < n) des AU non encore livrées est indiqué. Un "-" indique que toutes les AU précédentes sont présentes. Si la période d'AU est constante, le déplacement maximum est égal à 5 périodes d'AU, comme on le trouve pour AU(6) et AU(7).

                                 +--+--+--+--+--+--+--+--+--+--+--+-
   AU entrelacées                | 0| 3| 6| 1| 4| 7| 2| 5| 8| 9|12|..
                                 +--+--+--+--+--+--+--+--+--+--+--+-
Première AU non encore présente    -  1  1  -  2  2  -  -  -  - 10

Figure 7 : Pour chaque AU dans le schéma d'entrelaçage, la première de toutes les AU antérieures non encore présentes

En cas d'entrelaçage, les envoyeurs DOIVENT signaler le déplacement maximum en temps durant la session via le paramètre de format MIME "maxDisplacement" ; voir au paragraphe 4.1.

Une estimation de la taille de la mémoire tampon de désentrelaçage est trouvée en multipliant le déplacement maximum par le débit binaire maximum :

taille(mémoire tampon de désentrelaçage) = {(maxDéplacement) * Débit(max)} / (fréquence d'horloge RTP),

où Débit(max) est le débit binaire maximum du flux transporté.

Noter que les receveurs peuvent déduire Débit(max) des paramètres de format MIME streamType, profile-level-id, et config.

Cependant, ce calcul estime la taille de mémoire tampon de désentrelaçage et la taille requise peut différer de la valeur calculée. Si ce calcul sous estime la taille de la mémoire tampon de désentrelaçage, les envoyeurs, en cas d'entrelaçage, DOIVENT alors signaler une taille de mémoire tampon de désentrelaçage via le paramètre de format MIME "de-interleaveBufferSize" ; voir le paragraphe 4.1. Si le calcul surestime la taille de la mémoire tampon de désentrelaçage, les envoyeurs, en cas d'entrelaçage, PEUVENT alors signaler une taille de mémoire tampon de désentrelaçage via le paramètre de format MIME "de-interleaveBufferSize".

La taille signalée de la mémoire tampon de désentrelaçage DOIT être assez grande pour contenir toutes les AU "précoces" à tout moment durant la session. C'est à dire :

taille minimum de mémoire tampon de désentrelaçage = max [somme {si TS(i) > TS(j) alors Taille d'AU(i) autrement 0}]
       pour tout j et tout i<j, où i et j indiquent l'indice de AU dans le schéma d'entrelaçage,
          TS(i) note l'horodatage de AU(i), et Taille d'AU(i) note la taille de AU(i) en nombre d'octets.

Si le paramètre "de-interleaveBufferSize" est présent, la mémoire tampon de désentrelaçage appliquée chez un receveur DOIT avoir une taille au moins égale à la taille signalée de mémoire tampon de désentrelaçage, sinon une taille au moins égale à la taille calculée de la mémoire tampon de désentrelaçage.

Quel que soit le schéma d'entrelaçage utilisé, il doit être analysé pour calculer la valeur applicable de maxDisplacement, ainsi que la taille requise de la mémoire tampon de désentrelaçage. Les envoyeurs DEVRAIENT signaler les valeurs qui ne sont pas supérieures aux valeurs strictement requises ; si des valeurs supérieures sont signalées, le receveur va mettre en mémoire tampon de manière excessive.

Noter que pour les matériels à faible débit, l'entrelaçage appliqué peut rendre les paquets plus courts que la taille de MTU.

3.2.3.4	AU cruciales et non cruciales avec les données système MPEG-4
Certaines unités d'accès avec des données système MPEG-4, appelées AU "cruciales", portent des informations dont la perte ne peut être tolérée, dans la présentation ou dans le décodeur. À chaque AU cruciale dans un flux système MPEG-4, l'état du flux change. L'état du flux PEUT rester constant pour des AU non cruciales. Dans la norme ISO/CEI 14496-1, les flux système MPEG-4 utilisent le AU_SequenceNumber pour signaler les états de flux.

Exemple : soient trois AU, AU1 = "Insertion du nœud X", AU2 = "Régler la position du nœud X", AU3 = "Régler la position du nœud X". AU1 est cruciale, car si elle est perdue, AU2 ne peut pas être exécutée. Cependant, AU2 n'est pas cruciale, car AU3 peut être exécutée même si AU2 est perdue.

Lorsque une AU cruciale est (éventuellement) perdue, le flux est corrompu. Par exemple, quand une AU est perdue et quand l'état du flux a changé à la prochaine AU reçue, il est alors possible que l'AU perdue ait été cruciale. Une fois corrompu, le flux reste corrompu jusqu'au prochain point d'accès aléatoire. Noter que la perte d'AU non cruciale ne corrompt pas le flux. Lorsque un décodeur commence à recevoir un flux, le décodeur DOIT considérer le flux comme corrompu jusqu'à ce qu'une AU soit reçue qui fournisse un point d'accès aléatoire.

Une AU qui fournit un point d'accès aléatoire, signalé par le fanion RAP, peut être ou non cruciale. Les AU RAP non cruciales fournissent un point d'accès aléatoire "répété" à utiliser par les décodeurs qui se sont joints récemment au flux, ou qui ont besoin de redémarrer le décodage après une corruption de flux. Les AU RAP non cruciales DOIVENT inclure toutes les mises à jour depuis la dernière AU RAP cruciale.

À réception d'AU, les décodeurs doivent réagir comme suit :

a)	Si le fanion RAP est réglé à 1 et si l'état de flux change, l'AU est alors une AU RAP cruciale, et l'AU DOIT être décodée.

b)	Si le fanion RAP est réglé à 1 et si l'état de flux ne change pas, l'AU est alors une AU RAP non cruciale, et le receveur DEVRAIT la décoder si le flux est corrompu. Autrement, le décodeur DOIT ignorer l'AU.

c)	Si le fanion RAP est réglé à 0, l'AU DOIT alors être décodée, sauf si le flux est corrompu, auquel cas l'AU DOIT être ignorée.

3.3	Usage de cette spécification
3.3.1	Généralités
L'usage de la présente spécification requiert la définition d'un mode. Un mode définit comment utiliser cette spécification, comme approprié. Les envoyeurs DOIVENT signaler le mode appliqué via le paramètre de format MIME "mode", comme spécifié au paragraphe 4.1. La présente spécification définit un mode générique qui peut être utilisé pour tout flux MPEG-4, ainsi que des modes spécifiques pour le transport des flux MPEG-4 CELP et AAC, définis dans la norme ISO/CEI 14496-3 [MPEG-4].

Lorsque l'utilisation de ce format de charge utile est signalé en utilisant SDP [RFC2327], un attribut "rtpmap" fait partie de cette signalisation. Les mêmes exigences s'appliquent pour l'attribut rtpmap dans tout mode conforme à la présente spécification. La forme générale d'un attribut rtpmap est :

a=rtpmap:<type de charge utile> <nom du codage>/<débit d'horloge>[/<paramètres de codage>]

Pour les flux audios, <paramètres de codage> spécifie le nombre de canaux audios : 2 pour le matériel stéréo (voir la [RFC2327]) et 1 pour le mono. Pourvu qu'aucun paramètre supplémentaire ne soit nécessaire, ce paramètre peut être omis pour le matériel mono, donc sa valeur par défaut est 1.

3.3.2	Mode générique
Le mode générique peut être utilisé pour tout flux MPEG-4. Dans ce mode, aucune contrainte spécifique du mode n'est appliquée ; donc, dans le mode générique, toute la souplesse de la présente spécification peut être exploitée. Le mode générique est signalé par mode=generic.

Un exemple est donné ci-dessous du transport d'un flux BIFS-Anim. Dans cet exemple, le portage de plusieurs unités d'accès BIFS-Anim est permis dans un paquet RTP. L'en-tête d'AU contient le champ Taille d'AU, le fanion CTS et, si le fanion CTS est réglé à 1, le champ Delta CTS. Le nombre de bits des champs Taille d'AU et Delta de CTS est respectivement de 10 et 16. L'en-tête d'AU contient aussi le fanion RAP et l'état de flux de 4 bits. Il en résulte un en-tête d'AU d'une taille totale de deux ou quatre octets par AU BIFS-Anim. L'horodatage RTP utilise une horloge à 1 kHz. Noter que le nom du type de support est vide, parce que le flux BIFS-Anim fait partie d'une présentation audiovisuelle. Pour les conventions sur les noms de type de supports, voir le paragraphe 4.1.

En détail :
m=video 49230 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/1000
a=fmtp:96 streamtype=3; profile-level-id=1807; mode=generic;
   objectType=2; config=0842237F24001FB400094002C0; sizeLength=10;
CTSDeltaLength=16; randomAccessIndication=1;
streamStateIndication=4

Note : La ligne a=fmtp a été coupée en deux pour tenir dans la page, elle comporte une seule ligne dans le fichier SDP.

La valeur hexadécimale du paramètre "config" est le BIFSConfiguration() comme défini dans la norme ISO/CEI 14496-1. BIFSConfiguration() spécifie que le flux BIFS est un flux BIFS-Anim. Pour la description des paramètres MIME, voir au paragraphe 4.1.

3.3.3	CELP à débit binaire constant
Ce mode est signalé par mode=CELP-cbr. Dans ce mode, une ou plusieurs trames CELP complètes de taille fixe peuvent être transportées dans un paquet RTP ; l'entrelaçage NE DOIT PAS être utilisé avec ce mode. La charge utile RTP consiste en une ou plusieurs trames CELP enchaînées, de taille égale. Les trames CELP NE DOIVENT PAS être fragmentées quand on utilise ce mode. La section En-tête d'AU et la section Auxiliaire DOIVENT toutes deux être vides.

Le paramètre de format MIME constantSize DOIT être fourni pour spécifier la longueur de chaque trame CELP.

Par exemple :
m=audio 49230 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/16000/1
a=fmtp:96 streamtype=5; profile-level-id=14; mode=CELP-cbr; config=440E00; constantSize=27; constantDuration=240

La valeur hexadécimale du paramètre "config" est AudioSpecificConfig() comme défini dans la norme ISO/CEI 14496-3. AudioSpecificConfig() spécifie un flux CELP mono avec un taux d'échantillonnage de 16 kHz à un débit binaire fixe de 14,4 kbit/s et 6 sous trames par trame CELP. Pour la description des paramètres MIME, voir au paragraphe 4.1.

3.3.4	CELP à débit binaire variable
Ce mode est signalé par mode=CELP-vbr. Avec ce mode, une ou plusieurs trames CELP complètes de taille variable peuvent être transportées dans un paquet RTP avec un entrelaçage FACULTATIF. Dans ce mode, la plus grande valeur possible pour Taille d'AU est supérieure à la taille maximum de trame CELP. Parce que les trames CELP sont très petites, la fragmentation des trames CELP n'est pas prise en charge. Donc, les trames CELP NE DOIVENT PAS être fragmentées quand on utilise ce mode.

Dans ce mode, la charge utile RTP consiste en la section d'en-tête d'AU, suivie par une ou plusieurs trames CELP enchaînées. La section Auxiliaire DOIT être vide. Pour chaque trame CELP contenue dans la charge utile, il DOIT y avoir un octet d'en-tête d'AU dans la section En-tête d'AU pour fournir :
a)	la taille de chaque trame CELP dans la charge utile et
b)	des informations d'indice pour calculer la séquence (et donc le moment) de chaque trame CELP.

Le transport des trames CELP exige que le champ Taille d'AU soit codé sur 6 bits. Donc, dans ce mode, 6 bits sont alloués au champ Taille d'AU, et 2 bits au champ (delta) d'indice d'AU. Chaque champ Indice d'AU DOIT être codé avec la valeur  0. Dans la section En-tête d'AU, les en-têtes d'AU enchaînées sont précédés par les 16 bits du champ Longueur d'en-têtes d'AU, comme spécifié au paragraphe 3.2.1.

En plus des paramètres de format MIME exigés, les paramètres suivants DOIVENT être présents : sizeLength (longueur de taille), indexLength (longueur d'indice), et indexDeltaLength (longueur de différence d'indice). Les trames CELP ont toujours une durée fixés par unité d'accès ; lorsque il y a entrelaçage dans ce mode, cette durée spécifique DOIT être signalée par le paramètre de format MIME constantDuration. De plus, le paramètre maxDisplacement DOIT être présent lors de l'entrelaçage.

Par exemple :
m=audio 49230 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/16000/1
a=fmtp:96 streamtype=5; profile-level-id=14; mode=CELP-vbr; config=440F20; sizeLength=6; indexLength=2;
 indexDeltaLength=2; constantDuration=160; maxDisplacement=5

Note : La ligne a=fmtp a été coupée en deux pour tenir dans la page, elle comporte une seule ligne dans le fichier SDP.

La valeur hexadécimale du paramètre "config" est AudioSpecificConfig() comme défini dans la norme ISO/CEI 14496-3. AudioSpecificConfig() spécifie un flux mono CELP avec un taux d'échantillonnage de 16 kHz, à un débit binaire qui varie entre 13,9 et 16,2 kbit/s et avec 4 sous trames par trame CELP. Pour la description des paramètres MIME, voir au paragraphe 4.1.

3.3.5	AAC à faible débit binaire
Ce mode est signalé par mode=AAC-lbr. Ce mode prend en charge le transport d'une ou plusieurs trames AAC complètes de taille variable. Dans ce mode, les trames AAC peuvent être entrelacées et donc les receveurs DOIVENT supporter le désentrelaçage. La taille maximum d'une trame AAC dans ce mode est de 63 octets. Les trames AAC NE DOIVENT PAS être fragmentées lorsque on utilise ce mode. Donc, lorsque on utilise ce mode, les codeurs DOIVENT s'assurer que la taille de chaque trame AAC est au plus de 63 octets.

La configuration de charge utile dans ce mode est la même que dans le mode CELP à débit binaire variable défini au paragraphe 3.3.4. La charge utile RTP consiste en la section En-tête d'AU, suivie par les trames AAC enchaînées. La section Auxiliaire DOIT être vide. Pour chaque trame AAC contenue dans la charge utile, l'octet d'en-tête d'AU DOIT fournir :
a)	la taille de chaque trame AAC dans la charge utile et
b)	les informations d'indice pour calculer la séquence (et donc le moment) de chaque trame AAC.

Dans la section En-tête d'AU, les en-têtes d'AU enchaînées DOIVENT être précédés par les 16 bits du champ Longueur d'en-têtes d'AU, comme spécifié au paragraphe 3.2.1.

En plus des paramètres de format MIME requis, les paramètres suivants DOIVENT être présents : sizeLength, indexLength, et indexDeltaLength. Les trames AAC ont toujours une durée fixée par unité d'accès ; lorsque l'entrelaçage est utilisé dans ce mode, cette durée spécifique DOIT être signalée par le paramètre de format MIME constantDuration. De plus, le paramètre maxDisplacement DOIT être présent lorsque il y a entrelaçage.

Par exemple :
m=audio 49230 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/22050/1
a=fmtp:96 streamtype=5; profile-level-id=14; mode=AAC-lbr; config=1388;
   sizeLength=6; indexLength=2; indexDeltaLength=2; constantDuration=1024; maxDisplacement=5

Note : La ligne a=fmtp a été coupée en deux pour tenir dans la page, elle comporte une seule ligne dans le fichier SDP.

La valeur hexadécimale du paramètre "config" est le AudioSpecificConfig(), défini dans la norme ISO/CEI 14496-3. AudioSpecificConfig() spécifie un flux mono AAC avec un taux d'échantillonnage de 22,05 kHz. Pour la description des paramètres MIME, voir au paragraphe 4.1.

3.3.6	AAC à fort débit binaire
Ce mode est signalé par mode=AAC-hbr. Ce mode prend en charge le transport de trames AAC de tailles variables. Dans un paquet RTP, une ou plusieurs trames AAC complètes sont portées, ou un seul fragment d'une trame AAC. Dans ce mode, les trames AAC peuvent être entrelacées et donc les receveurs DOIVENT prendre en charge le désentrelaçage. La taille maximum d'une trame AAC dans ce mode est de 8191 octets.

Dans ce mode, la charge utile RTP consiste en la section d'en-tête d'AU, suivie par une trame AAC, plusieurs trames AAC enchaînées ou une trame AAC fragmentée. La section Auxiliaire DOIT être vide. Pour chaque trame AAC contenue dans la charge utile, il DOIT y avoir un en-tête d'AU dans la section d'en-tête d'AU pour fournir :
a)	la taille de chaque trame AAC dans la charge utile et
b)	les informations d'indice pour calculer la séquence (et donc le moment) de chaque trame AAC.

Coder la taille maximum d'une trame AAC exige 13 bits. Donc, dans cette configuration 13 bits sont alloués au champ Taille d'AU, et 3 bits au champ Indice (delta) d'AU. Donc, chaque en-tête d'AU a une taille de 2 octets. Chaque champ Indice d'AU DOIT être codé avec la valeur 0. Dans la section En-tête d'AU, les en-têtes d'AU enchaînées DOIVENT être précédés par le champ de 16 bits Longueur d'en-têtes d'AU, comme spécifié au paragraphe 3.2.1.

En plus des paramètres de format MIME requis, les paramètres suivants DOIVENT être présents : sizeLength, indexLength, et indexDeltaLength. Les trames AAC ont toujours une durée fixée par unité d'accès ; lorsque il y a entrelaçage dans ce mode, cette durée spécifique DOIT être signalée par le paramètre de format MIME constantDuration.  De plus, le paramètre maxDisplacement DOIT être présent lorsque il y a entrelaçage.

Par exemple :
m=audio 49230 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/48000/6
a=fmtp:96 streamtype=5; profile-level-id=16; mode=AAC-hbr; config=11B0; sizeLength=13; indexLength=3;
   indexDeltaLength=3; constantDuration=1024

Note : La ligne a=fmtp a été coupée en deux pour tenir dans la page, elle comporte une seule ligne dans le fichier SDP.

La valeur hexadécimale du paramètre "config" est AudioSpecificConfig(), comme défini dans la norme ISO/CEI 14496-3. AudioSpecificConfig() spécifie un flux AAC de canal 5.1 avec un taux d'échantillonnage de 48 kHz. Pour la description des paramètres MIME, voir au paragraphe 4.1.

3.3.7.	Modes supplémentaires
La présente spécification ne définit que les modes spécifiés aux paragraphes 3.3.2 à 3.3.6. Des modes supplémentaires seront définis dans de futures RFC. Chaque mode supplémentaire DOIT être entièrement conforme à la présente spécification.

Tout nouveau mode DOIT être défini de telle façon qu'une mise en œuvre qui comporte toutes les caractéristiques de la présente spécification puisse décoder le format de charge utile correspondant à ce nouveau mode. Pour cette raison, un mode NE DOIT PAS spécifier de nouvelles valeurs par défaut pour les paramètres MIME. En particulier, les paramètres MIME qui configurent la charge utile RTP DOIVENT être présents (sauf si ils ont la valeur par défaut) même si leur présence est redondante dans les cas où le mode alloue une valeur fixe à un paramètre. Un mode peut de plus définir que certains paramètres MIME sont exigés au lieu de facultatifs, que certains paramètres MIME ont des valeurs (ou gammes) fixes, et qu'il y a des règles qui restreignent leur utilisation.

4.	Considérations relatives à l'IANA

Cette section décrit les types et noms MIME associés à ce format de charge utile. Le paragraphe 4.1 enregistre les types MIME, conformément à la [RFC2048].

Ce format peut exiger des informations supplémentaires sur la transposition à mettre à la disposition du receveur. Cela se fait en utilisant les paramètres décrits au paragraphe qui suit.

4.1	Enregistrement de type MIME
Nom de type de support MIME : "video" ou "audio" ou "application"."video" DOIT être utilisé pour les flux visuels MPEG-4 (ISO/CEI 14496-2) ou les flux système MPEG-4 (ISO/CEI 14496-1) qui portent les informations nécessaires pour une présentation audio/visuelle. "audio" DOIT être utilisé pour les flux audio MPEG-4 (ISO/CEI 14496-3) ou les flux systèmes MPEG-4 qui portent les informations nécessaires pour une présentation seulement audio. "application" DOIT être utilisé pour les flux système MPEG-4 (ISO/CEI 14496-1) qui servent à des objets autres que la présentation audio/visuelle, par exemple, dans certains cas où des flux MPEG-J (Java) sont transmis.

Selon la configuration de charge utile requise, des paramètres de format MIME peuvent devoir être disponibles pour le receveur. Ceci est fait en utilisant les paramètres décrits au paragraphe suivant. Il y a des paramètres exigés et des paramètres facultatifs.

Les paramètres facultatifs sont de deux types : les paramètres généraux et les paramètres de configuration. Les paramètres de configuration sont utilisés pour configurer les champs dans la section En-tête d'AU et dans la section Auxiliaire. L'absence de tout paramètre de configuration est équivalente au réglage du champ associé à sa valeur par défaut, qui est toujours zéro. L'absence de tout paramètre de configuration résulte en une configuration "de" base" par défaut avec une section En-tête d'AU vide et une section Auxiliaire vide dans chaque paquet RTP.

Nom de sous-type MIME : mpeg4-generic

Paramètres requis : les paramètres de format MIME ne sont pas sensibles à la casse ; pour être cependant clair, les majuscules et les minuscules sont utilisées dans les noms des paramètres décrits dans la présente spécification.

StreamType : valeur d'entier qui indique le type de flux MPEG-4 qui est porté ; son codage correspond aux valeurs de streamType, comme défini au Tableau 9 (Valeurs de streamType) dans la norme ISO/CEI 14496-1.

profile-level-id : représentation décimale de l'indication de niveau de profil MPEG-4. Ce paramètre DOIT être utilisé dans l'échange de capacités ou la procédure d'établissement de session pour indiquer la combinaison de profil et niveau MPEG-4 dont est capable le codec de support MPEG-4 pertinent.

Pour les flux audio MPEG-4, ce paramètre est la valeur décimale du Tableau 5 (valeurs de audioProfileLevelIndication) dans la norme ISO/CEI 14496- 1, qui indique quels sous ensembles d'outils MPEG-4 sont requis pour décoder le flux audio.

Pour les flux visuels MPEG-4, ce paramètre est la valeur décimale du Tableau G-1 (tableau FLC pour l'indication de profil et niveau) de la norme ISO/CEI 14496-2 [MPEG-4], qui indique quels sous ensembles d'outils visuels MPEG-4 sont requis pour décoder le flux visuel.

Pour les flux BIFS, ce paramètre est la valeur décimale obtenue de (SPLI + 256*GPLI), où :
-	SPLI est la valeur décimale tirée du Tableau 4 de la norme ISO/CEI 14496-1 en appliquant sceneProfileLevelIndication  ;
-	GPLI est la valeur décimale tirée du Tableau 7 de la norme ISO/CEI 14496-1 en appliquant graphicsProfileLevelIndication.

Pour les flux MPEG-J, ce paramètre est la valeur décimale tirée du Tableau 13 (MPEGJProfileLevelIndication) dans la norme ISO/CEI 14496-1, indiquant le profil et le niveau du flux MPEG-J.

Pour les flux OD, ce paramètre est la valeur décimale tirée du Tableau 3 (ODProfileLevelIndication) de la norme ISO/CEI 14496-1, qui indique le profil et niveau du flux OD.

Pour les flux IPMP, ce paramètre a la valeur décimale 0, qui indique un profil et niveau non spécifiés, ou une valeur supérieure à zéro, indiquant un profil et niveau IPMP MPEG-4 comme sera défini dans une future spécification MPEG-4.

Pour les flux de référence d'horloge et les flux d'informations de contenu d'objet, ce paramètre a la valeur décimale de zéro, indiquant que les informations de profil et de niveau sont portées dans le cadre OD.

Configuration : représentation hexadécimale d'une chaîne d'octets qui exprime la configuration de la charge utile du support. Les données de configuration sont transposées en la chaîne d'octets hexadécimale sur la base du bit de moindre poids en premier. Le premier bit des données de configuration DEVRA être localisé au MSB du premier octet. Dans le dernier octet, si nécessaire pour réaliser l'alignement sur l'octet, jusqu'à 7 bits de valeur zéro de bourrage devront suivre les données de configuration.

Pour les flux audio MPEG-4, "config" sont les données de configuration de décodeur spécifiques du type d'objet audio AudioSpecificConfig(), comme défini dans la norme ISO/CEI 14496-3. Pour l'audio structuré, les AudioSpecificConfig() peuvent être portées pas d'autres moyens, non définis dans la présente spécification. Si les AudioSpecificConfig() sont portées par d'autres moyens pour l'audio structuré, "config" DOIT être une chaîne d'octets hexadécimaux entre guillemets vide, comme suit : config="".

Noter qu'un futur mode d'utilisation de ce format de charge utile RTP pour "Structured Audio" pourra définir de tels autres moyens.

Pour les flux visuels MPEG-4, "config" sont les informations de configuration visuelle MPEG-4 définies au paragraphe 6.2.1, "codes de démarrage" de la norme ISO/CEI 14496-2. Les informations de configuration indiquées par ce paramètre DEVRONT être les mêmes que les informations de configuration dans le flux visuel MPEG-4 correspondant, sauf pour first-half-vbv-occupancy et latter-half-vbv-occupancy, si ils existent, ce qui peut varier dans les informations de configuration répétées au sein d'un flux visuel MPEG-4 (voir le paragraphe 6.2.1 "Start codes" de ISO/CEI 14496-2).

Pour les flux BIFS, ce sont les informations BIFSConfig() comme défini dans la norme ISO/CEI 14496-1. La version 1 de BIFSConfig est définie au paragraphe 9.3.5.2, et la version 2 est définie au paragraphe 9.3.5.3. Le paramètre de format MIME objectType signale la version de BIFSConfig.

Pour les flux IPMP, c'est soit une chaîne d'octets hexadécimaux vide entre guillemets, qui indique l'absence de toute information de configuration de décodeur (config=""), soit le IPMPConfiguration() comme il sera défini dans une future spécification IPMP MPEG-4.

Pour les flux d'informations de contenu d'objet (OCI, Object Content Info), ce sont les informations OCIDecoderConfiguration() du flux OCI, comme défini au paragraphe 8.4.2.4 de la norme ISO/CEI 14496-1.

Pour les flux OD, les flux de référence d'horloge et les flux MPEG-J, c'est une chaîne d'octets hexadécimalux vide entre guillemets (config="") car aucune information n'est requise sur la configuration du décodeur.

Mode : mode dans lequel est utilisé la présente spécification. Les modes suivants peuvent être signalés :
mode=generic,
mode=CELP-cbr,
mode=CELP-vbr,
mode=AAC-lbr et
mode=AAC-hbr.

On suppose que d'autres modes seront définis dans de futures RFC. Voir aussi les paragraphes 3.3.7 et 4.2 de la RFC 3640.

Paramètres facultatifs généraux :

objectType : valeur décimale tirée du Tableau 8 de la norme ISO/CEI 14496-1, qui indique la valeur de objectTypeIndication du flux transporté. Pour les flux BIFS, ce paramètre DOIT être présent pour signaler la version de BIFSConfiguration(). Noter que objectTypeIndication peut signaler un flux non MPEG-4 et que le format de charge utile RTP défini dans le présent document peut ne pas convenir pour porter un flux qui n'est pas défini par MPEG-4. Le paramètre objectType NE DEVRAIT PAS être réglé à une valeur qui signale un flux qui ne peut pas être porté par ce format de charge utile.

constantSize : taille constante en octets de chaque unité d'accès pour ce flux. Les paramètres constantSize et sizeLength NE DOIVENT PAS être simultanément présents.

constantDuration : durée constante de chaque unité d'accès pour ce flux, mesurée avec les mêmes unités que l'horodatage RTP.

maxDisplacement : représentation décimale du déplacement maximum en temps d'une AU entrelacée, comme défini au paragraphe 3.2.3.3, exprimée en unités de l'horloge de l'horodatage RTP. Ce paramètre DOIT être présent lorsque l'entrelaçage est appliqué.

de-interleaveBufferSize : représentation décimale en nombre d'octets de la taille de la mémoire tampon de désentrelaçage, décrite au paragraphe 3.2.3.3. Lorsque il y a entrelaçage, ce paramètre DOIT être présent si le calcul de la taille de mémoire tampon de désentrelaçage donnée au paragraphe 3.2.3.3 et fondée sur maxDisplacement et rate(max) sous estime la taille de la mémoire tampon de désentrelaçage. Si ce calcul ne sous estime pas la taille de la mémoire tampon de désentrelaçage, le paramètre de-interleaveBufferSize NE DEVRAIT alors PAS être présent.

Paramètres facultatifs de configuration :

sizeLength : nombre de bits sur lequel le champ Taille d'AU est codé dans l'en-tête d'AU. Les paramètres sizeLength et constantSize NE DOIVENT PAS être simultanément présents.

indexLength : nombre de bits sur lequel l'indice d'AU est codé dans le premier en-tête d'AU. La valeur par défaut de zéro indique l'absence du champ Indice d'AU dans chaque premier en-tête d'AU.

indexDeltaLength : nobre de bits sur lequel est codé le champ Delta d'indice d'AU dans tout en-tête d'AU non premier. La valeur par défaut de zéro indique l'absence du champ Delta d'indice d'AU dans chaque en-tête d'AU non premier.

CTSDeltaLength : nombre de bits sur lequel est codé le champ Delta de CTS dans l'en-tête d'AU.

DTSDeltaLength : nombre de bits sur lequel est codé le champ Delta de DTS dans l'en-tête d'AU.

randomAccessIndication : valeur décimale de zéro ou un, indiquant si le fanion RAP est présent dans l'en-tête d'AU. La valeur décimale de un indique la présence du fanion RAP, la valeur par défaut de zéro indique son absence.

streamStateIndication : nombre de bits sur lequel est codé le champ Stream-state dans l'en-tête d'AU. Ce paramètre PEUT être présent lors du transport de flux système MPEG-4, et NE DEVRA PAS être présent pour les flux MPEG-4 audio et vidéo.

auxiliaryDataSizeLength : nombre de bits qui sont utilisés pour coder le champ Taille de données auxiliaires.

Les applications PEUVENT utiliser plus de paramètres, en plus de ceux définis ci-dessus. Chaque paramètre supplémentaire DOIT être enregistré auprès de l'IANA pour s'assurer qu'il n'y a pas de collision de noms. Chaque paramètre supplémentaire DOIT être accompagné d'une spécification sous la forme d'une RFC, d'une norme MPEG, ou autre référence permanente et directement disponible (la politique "Spécification exigée" définie dans la [RFC2434]). Les receveurs DOIVENT tolérer la présence de tels paramètres supplémentaires, mais ces paramètres NE DEVRONT PAS impacter le décodage des receveurs qui se conforment à la présente spécification.

Considérations de codage : ce sous type MIME n'est défini que pour le transport RTP. Les flux binaires systèmes DOIVENT être générés conformément aux spécifications de système MPEG-4 (ISO/CEI 14496-1). Les flux binaires vidéo DOIVENT être générés conformément aux spécifications visuelles MPEG-4 (ISO/CEI 14496-2). Les flux binaires audio DOIVENT être générés conformément aux spécifications audio MPEG-4 (ISO/CEI 14496-3). Les paquets RTP DOIVENT être mis en paquets conformément au format de charge utile RTP défini dans la RFC 3640.

Considérations sur la sécurité : comme défini à la Section 5 de la RFC 3640.

Considérations d'interopérabilité : MPEG-4 fournit un grand et riche ensemble d'outils pour le codage des objets visuels. Pour une mise en œuvre efficace de la norme, des sous ensembles de la trousse à outils de MPEG-4 ont été fournis pour être utilisés dans des applications spécifiques. Ces sous ensembles, appelés "profils", limitent la taille de la trousse à outils dont la mise en œuvre est exigée du décodeur. Afin de réduire la complexité de calcul, un ou plusieurs "niveaux" sont établis pour chaque profil. Une combinaison de profil et de niveau permet :
-	à un constructeur de codec de ne mettre en œuvre que le sous ensemble du standard dont il a besoin, tout en maintenant l'interfonctionnement avec les autres appareils MPEG-4 qui mettent en œuvre la même combinaison, et
-	de vérifier si les appareils MPEG-4 se conforment à la norme ("essai de conformité").

Un flux DEVRA se conformer au profil et niveau MPEG-4 spécifié par le paramètre "profile-level-id" (identifiant de niveau de profil). L'interopérabilité entre un envoyeur et un receveur est réalisée en spécifiant le paramètre "profile-level-id" dans le contenu MIME. Dans la procédure d'échange/annonce de capacités, ce paramètre peut être établi mutuellement à la même valeur.

Spécification publiée : les spécifications pour les flux MPEG-4 sont présentées dans les normes ISO/CEI 14496-1, 14496-2, et 14496-3. Le format de charge utile RTP est décrit dans la RFC 3640.

Applications qui utilisent ce type de support : flux multimédia et outils de conférence.

Informations supplémentaires : aucune

Numéros magiques : aucun

Extensions de fichier  : aucune. Un format de fichier avec l'extension .mp4 a été défini pour le contenu MPEG-4 mais n'est pas directement corrélé à ce type MIME pour lequel le seul objet est le transport RTP.

Code de type de fichier Macintosh : aucun

Adresse personnelle et de messagerie à contacter pour plus d'informations : les auteurs de la RFC 3640, le groupe de travail de l'IETF Transport audio/vidéo .

Utilisation prévue : COMMUNE

Auteur/contrôleur des changements: les auteurs de la RFC 3640, le groupe de travail de l'IETF Transport audio/vidéo.

4.2	Enregistrement des définitions de mode par l'IANA
Cette spécification peut être utilisée dans un certain nombre de modes. Le mode de fonctionnement est signalé en utilisant le paramètre MIME "mode", avec l'ensemble initial de valeurs spécifié au paragraphe 4.1. De nouveaux modes pourront être définis à tout moment, comme décrit au paragraphe 3.3.7. Ces modes DOIVENT être enregistrés auprès de l'IANA, pour s'assure qu'il n'y a pas de collision de noms.

Un nouvel enregistrement de mode DOIT être accompagné d'une spécification sous forme de RFC, de norme MPEG, ou autre référence permanente et directement disponible (la politique "Spécification requise" définie dans la [RFC2434]).

4.3	Enchaînement des paramètres
Plusieurs paramètres DEVRAIENT être exprimés comme une chaîne de type de support MIME, sous la forme d'une liste de paires de paramètre/valeur séparées par deux points (voir des exemples d'utilisation de paramètres aux paragraphes 3.3.2 à 3.3.6).

4.4	Usage de SDP
4.4.1	Mot clé a=fmtp
On suppose qu'une façon normale de transporter les paramètres décrits ci-dessus associés au présent format de charge utile est via un message SDP [RFC2327] par exemple transporté au client en réponse à un RTSP DESCRIBE [RFC2326] ou via SAP [RFC2974]. Dans ce cas, le mot clé (a=fmtp) DOIT être utilisé comme décrit dans la [RFC2327], section 6, la syntaxe étant alors : a=fmtp:<format> <nom de paramètre>=<valeur>[; <nom de paramètre>=<valeur>]

5.	Considérations sur la sécurité

Les paquets RTP qui utilisent le format de charge utile défini dans la présente spécification sont soumis aux considérations sur la sécurité exposées dans la spécification RTP [RFC3550]. Cela implique que la confidentialité des flux de supports soit réalisée par le chiffrement. À cause de la compression de données utilisée avec ce format de charge utile qui est appliquée de bout en bout, le chiffrement peut être effectué sur les données compressées afin qu'il n'y ait pas de conflit entre les deux opérations. La complexité du traitement de paquet de cette charge utile type (c'est-à-dire, excluant le traitement des données des supports) ne présente pas de discordance significative du côté receveur susceptible de causer une menace de déni de service.

Cependant, il est possible d'injecter des flux MPEG (audios, vidéos, et systèmes) non conformes afin de submerger les mémoires tampons du receveur/décodeur, ce qui peut compromettre les fonctions du receveur ou même le mettre en panne. Ceci est particulièrement vrai pour les systèmes de bout en bout comme MPEG, où les modèles de mémoire tampon sont définis avec précision.

Les systèmes MPEG-4 prennent en charge des types de flux qui incluent des commandes qui sont exécutées sur le terminal, comme les commandes OD, les commandes BIFS, etc. et des contenus de programmation comme des scripts MPEG-J (code d'octet Java(TM)) et MPEG-4. Il est possible d'utiliser une ou plusieurs de celles-ci d'une manière non conforme à MPEG pour mettre en panne le receveur ou le rendre temporairement indisponible. Les envoyeurs qui transportent un contenu MPEG-4 DEVRAIENT s'assurer que de tels contenus sont conformes à MPEG, comme défini dans la partie conformité de la norme ISO/CEI 14496 [MPEG-4]. Les receveurs qui prennent en charge le contenu MPEG-4 devraient empêcher le mauvais fonctionnement du receveur en cas de contenu non conforme à MPEG.

Des mécanismes d'authentification peuvent être utilisés pour valider l'envoyeur et les données afin de prévenir les problèmes de sécurité dus à des flux malveillants non conformes à MPEG-4.

Dans la norme ISO/CEI 14496-1, un modèle de sécurité est défini pour les flux systèmes MPEG-4 qui portent des unités d'accès MPEG-J comportant des classes et objets Java(TM). MPEG-J définit un ensemble d'API Java et un modèle d'exécution sûr. Le contenu MPEG-J peut invoquer cet ensemble d'API et les méthodes Java(TM) à partir d'un ensemble de paquetages Java pris en charge chez le receveur au sein du modèle de sécurité défini. Selon ce modèle de sécurité, le code d'octet téléchargé n'a pas le droit de charger des bibliothèques, de définir des méthodes natives, de démarrer des programmes, de lire ou écrire des fichiers, ou de lire les propriétés du système. Les receveurs peuvent mettre en œuvre des filtres intelligents pour valider les exigences de mémoire tampon ou les commandes paramétriques (OD, BIFS, etc.) ou programmatiques (scripts MPEG-J, MPEG-4) dans les flux. Cependant, ceci peut augmenter significativement la complexité.

Les mises en œuvre de flux MPEG-4 sur RTP qui mettent aussi en œuvre des scripts MPEG-4 (sous ensemble de ECMAScript) DOIVENT s'assurer que l'action de tels scripts se limite seulement au domaine de la seule présentation dans laquelle ils résident (interdisant donc la communication de session à session, l'accès aux ressources et mémorisations locales, etc.). Bien que le chargement de ressources statiques situées dans le réseau (comme des supports) dans la présentation devrait être permis, l'accès réseau par des scripts DOIT être restreint à de tels téléchargements (supports).

6.	Remerciements

Le présent document est devenu la RFC 3640 après plusieurs révisions. Merci de leurs contributions aux membres du forum ISMA, au groupe de travail AVT de l'IETF et au groupe ad hoc "4-on-IP" au sein de MPEG. Les auteurs souhaitent remercier toutes les personnes qui s'y sont impliqué, en particulier Andrea Basso, Stephen Casner, M. Reha Civanlar, Carsten Herpel, John Lazaro, Zvi Lifshitz, Young-Zwon Lim, Alex MacAulay, Bill May, Colin Perkins, Dorairaj V et Stephan Wenger pour leur précieux commentaires et leur soutien.

Appendice.	Usage de ce format de charge utile : analyse d'entrelaçage, exemples d'analyse de délai avec entrelaçage
A.1	Introduction
Les questions d'entrelaçage sont discutées dans le présent appendice. Des notes générales sont fournies sur le désentrelaçage et la dissimulation d'erreur, et un certain nombre de schémas d'entrelaçage sont examinés, en particulier pour déterminer la taille de la mémoire tampon de désentrelaçage et le déplacement maximum des unités d'accès dans le temps. Dans ces exemples, le déplacement maximum est mentionné en termes de compte d'unité d'accès, pour faciliter la lecture. Dans les flux réels, il est signalé en unités de l'horloge d'horodatage RTP.

A.2	Désentrelaçage et dissimulation d'erreur
Le présent appendice ne décrit pas les détails du désentrelaçage et de la dissimulation d'erreur, car le processus de contrôle du décodage de l'AU et de dissimulation d'erreur a peu à voir avec l'entrelaçage. Si la prochaine AU à décoder est présente et si il y a une mémorisation disponible suffisante pour l'AU décodée, on la décode immédiatement. Sinon, on attend. Lorsque le délai de décodage est expiré (c'est-à-dire, le moment où le décodage doit commencer afin d'être achevé au moment où l'AU va être présentée) ou si le décodeur est un matériel qui présente un délai constant entre l'initiation du décodage d'une AU et la présentation de cette AU, le décodage doit alors commencer à l'expiration du délai.

Si la prochaine AU à décoder n'est pas présente lorsque le délai de décodage est arrivé à expiration, cette AU est alors perdue de sorte que le receveur doit prendre la mesure de dissimulation d'erreur qu'il estime appropriée. Le délai d'exécution peut devoir être ajusté à ce moment (en particulier si d'autres AU ont aussi manqué récemment leur délai d'expiration). Ou, si c'était un retard momentané, et que la conservation de la latence est importante, alors le receveur devrait minimiser le problème et continuer le traitement avec la prochaine AU.

A.3	Entrelaçage de groupe simple
A.3.1	Introduction
Un exemple d'entrelaçage régulier est lorsque des paquets sont formés en groupes. Si "l'écart" d'entrelaçage (la distance entre les AU entrelacées) est N, le paquet 0 pourrait contenir AU(0), AU(N), AU(2N), et ainsi de suite ; le paquet 1 pourrait contenir AU(1), AU(1+N), AU(1+2N), et ainsi de suite. Si il y a M unités d'accès dans un paquet, il y a alors M*N unités d'accès dans le groupe.

Voici un exemple avec N=M=3 ; noter que c'est le même exemple qu'au paragraphe 2.5 et qu'une durée fixe par unité d'accès est supposée :

Paquet	Horodatage	AU portés	Indice d'AU, delta d'indice d'AU	
P(0)	T[0]	0, 3, 6	0, 2, 2	
P(1)	T[1]	1, 4, 7	0, 2, 2	
P(2)	T[2]	2, 5, 8	0, 2, 2	
P(3)	T[9]	9, 12, 15	0, 2, 2	

Dans cet exemple, l'indice d'AU est présent dans le premier en-tête d'AU et est codé avec la valeur 0, comme requis pour les AU de durée fixe. La position de la première AU de chaque paquet au sein du groupe est définie par l'horodatage RTP, tandis que le champ Delta d'indice d'AU indique la position des AU suivantes par rapport à la première AU dans le paquet. Tous les champs Delta d'indice d'AU sont codés avec la valeur N-1, égale à 2 dans cet exemple. Donc l'horodatage RTP et le delta d'indice d'AU sont utilisés pour reconstruire l'ordre original. Voir aussi au paragraphe 3.2.3.2.

A.3.2	Détermination de la taille de mémoire tampon de désentrelaçage
Pour le schéma régulier comme dans cet exemple, la Figure 6 au paragraphe 3.2.3.3 montre que la mémoire tampon de désentrelaçage mémorise au plus 4 AU. Une valeur de de-interleaveBufferSize qui est au moins égale au nombre total d'octets de toutes les 4 AU "précoces" qui sont mémorisées au même moment peut être signalée.

A.3.3	Détermination du déplacement maximum
Pour le schéma régulier comme dans cet exemple, la Figure 7 au paragraphe 3.3 montre que le déplacement maximum en temps est égal à cinq périodes d'AU. Donc, la valeur minimum de maxDisplacement qui doit être signalée est 5 périodes d'AU. Dans le cas où chaque AU a la même taille, cette valeur de maxDisplacement surestime la taille de mémoire tampon de désentrelaçage d'une AU. Cependant, on note que dans le cas de tailles d'AU variables, la taille totale de toutes quatre AU "précoces" qui doivent être mémorisées au même moment peut excéder de maxDisplacement fois le débit binaire maximum, auquel cas la de-interleaveBufferSize doit être signalée.

A.4	Entrelaçage de groupe plus subtil
A.4.1	Introduction
On donne ci-dessous un autre exemple de formation de paquets avec entrelaçage de groupe. Dans cet exemple, les paquets sont formés de façon que la perte de deux paquets RTP suivants ne cause pas la perte de deux AU suivantes. Noter que dans cet exemple, les horodatages RTP des paquets 3 et 4 sont antérieurs, respectivement, aux horodatages RTP des paquets 1 et 2; on suppose une durée fixe par unité d'accès.

Paquet	Horodatage	AU portées	Indice d'AU, delta d'indice d'AU	
   0	T[0]	0,  5	0, 4	
   1	T[2]	2,  7	0, 4	
   2	T[4]	4,  9	0, 4	
   3	T[1]	1,  6	0, 4	
   4	T[3]	3,  8	0, 4	
   5	T[10]	10, 15	0, 4	
et ainsi de suite.

Dans cet exemple, l'indice d'AU est présent dans le premier en-tête d'AU et est codé avec la valeur 0, comme requis pour les AU de durée fixe. Pour reconstruire l'ordre d'origine, on utilise l'horodatage RTP et le delta d'indice d'AU (codé avec la valeur 4). Voir aussi le paragraphe 3.2.3.2.

A.4.2	Détermination de la taille de mémoire tampon de désentrelaçage
À partir de la Figure 8, on peut déterminer qu'au plus cinq AU "précoces" sont à mémoriser. Si les AU sont de taille constante, cette valeur est alors égale à cinq fois la taille d'AU. La taille minimum de la mémoire tampon de désentrelaçage égale le nombre total maximum d'octets des AU "précoces" qui sont à mémoriser en même temps. Cela donne la valeur minimum de la de-interleaveBufferSize qui peut être signalée.

                              +--+--+--+--+--+--+--+--+--+--+
   AU entrelacées             | 0| 5| 2| 7| 4| 9| 1| 6| 3| 8|
                              +--+--+--+--+--+--+--+--+--+--+
                                -  -  5  -  5  -  2  7  4  9
                                            7     4  9  5
   AU "précoces"                                  5     6
                                                  7     7
                                                  9     9

Figure 8 : Mémorisation des AU "précoces" dans la mémoire tampon de désentrelaçage par AU entrelacée

A.4.3	Détermination du déplacement maximum
À partir de la Figure 9, on peut voir que le déplacement de temps maximum est égal à huit périodes d'AU. Donc la valeur minimum de maxDisplacement à signaler est 8 périodes d'AU.

                                    +--+--+--+--+--+--+--+--+--+--+
   AU entrelacées                   | 0| 5| 2| 7| 4| 9| 1| 6| 3| 8|
                                    +--+--+--+--+--+--+--+--+--+--+
   AU précoce non encore présente     -  1  1  1  1  1  -  3  -  -

Figure 9 : Pour chaque AU dans le schéma d'entrelaçage, la plus antérieure de toutes les AU précoces n'est pas encore présente

Au cas où chaque AU a la même taille, la valeur trouvée de maxDisplacement surestime la taille de mémoire tampon de désentrelaçage de trois AU. Cependant, en cas de tailles d'AU variables, la taille totale de toutes cinq AU "précoces" mémorisées au même moment peut excéder de maxDisplacement fois le débit binaire maximum, auquel cas de-interleaveBufferSize doit être signalée.

A.5	Entrelaçage continu
A.5.1	Introduction
En entrelaçage continu, une fois que le schéma est "amorcé", le nombre d'AU dans un paquet excède "l'écart" (la distance entre elles). Cela diminue la mémoire tampon nécessaire, assouplit le flux des données, et donne des paquets légèrement plus grands -- et donc moins de frais généraux -- pour le même entrelaçage. Par exemple, voici un entrelaçage continu sur un écart de trois AU, mais avec quatre AU par paquet, pour une séquence de 20 AU. Cela montre à la fois comment le schéma "commence" et comment il finit. Là encore, l'exemple suppose une durée fixe par unité d'accès.

Paquet	Horodatage	AU portées	Indice d'AU, delta d'indice d'AU	
0	T[0]	0	0	
1	T[1]	1   4	0  2	
2	T[2]	2   5   8	0  2  2	
3	T[3]	3   6   9  12	0  2  2  2	
4	T[7]	7  10  13  16	0  2  2  2	
5	T[11	11  14  17  20	0  2  2  2	
6	T[15	15  18	0  2	
7	T[19	19	0	

Dans cet exemple, l'indice d'AU est présent dans le premier en-tête d'AU et codé avec la valeur 0, comme requis pour les AU de durée fixe. Pour reconstruire l'ordre d'origine, l'horodatage RTP et le delta d'indice d'AU (codé à la valeur 2) sont utilisés. Voir aussi au paragraphe 3.2.3.2. Noter que cet exemple a des horodatages RTP en ordre croissant.

A.5.2	Détermination de la taille de mémoire tampon de désentrelaçage
Pour cet exemple, la taille de mémoire tampon de désentrelaçage peut être déduite de la Figure 10. Le nombre maximum d'AU "précoces" est 3. Si les AU sont de taille constante, la taille de mémoire tampon de désentrelaçage est alors égale à 3  fois la taille de l'AU. Comparé à l'exemple en A.2, pour des AU de taille constante, la taille de mémoire tampon de désentrelaçage est réduite de 4 à 3 fois la taille d'AU, tout en conservant le même "écart".

                        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+-
   AU entrelacées       | 0| 1| 4| 2| 5| 8| 3| 6| 9|12| 7|10|13|16|
                        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+-
                          -  -  -  4  -  -  4  8  -  -  8 12  -  -
                                            5           9
   AU "précoces"                            8          12

Figure 10 : Mémorisation des AU "précoces" dans la mémoire tampon de désentrelaçage par AU entrelacée

A.5.3	Détermination du déplacement maximum
Pour cet exemple, le déplacement maximum a une valeur de 5 périodes d'AU. Voir la Figure 11. Comparé à l'exemple de A.2, le déplacement maximum ne diminue pas, bien qu'en fait moins de mémoire tampon de désentrelaçage soit requise.

                        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+-
   AU entrelacées       | 0| 1| 4| 2| 5| 8| 3| 6| 9|12| 7|10|13|16|
AU antérieures          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+-
 non encore présentes     -  -  2  -  3  3  -  -  7  7  -  - 11 11

Figure 11 : Pour chaque AU dans le schéma d'entrelaçage, la plus antérieure de toutes les AU antérieures n'est pas encore présente

Références
Références normatives
[MPEG-4]	Norme internationale ISO/CEI 14496 (MPEG-4) "Technologie de l'Information - Codage des objets audiovisuels", janvier 2000

[RFC2048]	N. Freed, J. Klensin et J. Postel, "Extensions multi-objets de la messagerie Internet (MIME) Partie 4 : Procédures d'enregistrement", BCP 13, novembre 1996. (Rendue obsolète par les RFC 4288-4289)

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

[RFC2327]	M. Handley et V. Jacobson, "SDP : Protocole de description de session", avril 1998. (Obsolète; voir RFC4566)

[RFC2434]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre, 1998. (Rendue obsolète par la RFC5226)

[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)
Références pour information
[RFC2250]	D. Hoffman et autres, "Format de charge utile RTP pour la vidéo MPEG1/MPEG2", janvier  1998.

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

[RFC2354]	C. Perkins et O. Hodson, "Options pour réparer un support de direct", juin 1998. (Information)

[RFC2733]	J. Rosenberg et H. Schulzrinne, "Format de charge utile RTP pour la correction d'erreur directe générique", décembre  1999. (Obsolète, voir  RFC  5109) (P.S.)

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

[RFC3016]	Y. Kikuchi et autres, "Format de charge utile RTP pour flux audio/vidéo MPEG-4", novembre 2000. (Obs., voir RFC6416) (P.S.)

Adresse des auteurs

Jan van der Meer	David Mackie	Viswanathan Swaminathan	
Philips Electronics	Apple Computer, Inc.	Sun Microsystems Inc.	
Prof Holstlaan 4	One Infinite Loop, MS:302-3KS	2600 Casey Avenue	
Building WAH-1	Cupertino  CA 95014	Mountain View, CA 94043	
5600 JZ Eindhoven	USA	USA	
Netherlands	mél : dmackie@apple.com 	mél : viswanathan.swaminathan@sun.com 	
mél : jan.vandermeer@philips.com 			

David Singer	Philippe Gentric	
Apple Computer, Inc.	Philips Electronics	
One Infinite Loop, MS:302-3MT	51 rue Carnot	
Cupertino  CA 95014	92156 Suresnes	
USA	France	
mél : singer@apple.com 	mél : philippe.gentric@philips.com 	

Déclaration complète de droits de reproduction

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

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.

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

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