Groupe de travail Réseau	S. Casner, Packet Design	
Request for Comments : 4856		
RFC rendue obsolète : 3555	mars 2007	
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle	

Enregistrement de type MIME des formats de charge utile dans le profil RTP pour conférences audio et vidéo

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

Notice de copyright
Copyright (C) The Internet Society (2007).

Résumé
Le présent document spécifie les enregistrements de type de support pour les formats de charge utile RTP définis dans le profil RTP pour les conférences audio et vidéo. Certains d'entre eux peuvent aussi être utilisés pour des modes de transfert autres que RTP.
Table des matières
1. Introduction	1
1.1 Considérations relatives à l'IANA	1
1.2 Terminologie	2
2. Enregistrements pour "profil audio/vidéo"	2
2.1 Enregistrements de type audio	2
2.2 Enregistrements du type vidéo	10
3. Changements par rapport à la RFC 3555	10
4. Considérations sur la sécurité	11
5. Références	11
5.1 Références normatives	11
5.2 Références pour information	12
Adresse de l'auteur	12
Déclaration complète de droits de reproduction	12

 	1.	Introduction

Le présent document met à jour les enregistrements de type de support initialement spécifiés dans la RFC 3555 pour les formats de charge utile du protocole de transport en temps réel (RTP, Real-time Transport Protocol) défini dans le profil RTP pour conférences audio et vidéo [RFC3551], comme sous types sous les types de supports "audio" et "video". Le présent document n'inclut pas d'enregistrement de type de support pour les formats de charge utile RTP qui sont référencés dans la RFC 3551 mais définis dans d'autres RFC. Les enregistrements de type de support pour ces formats de charge utile sont destinés à être mis à jour en les incluant dans les révisions des RFC individuelles qui définissent les formats de charge utile.

Les enregistrements de type de support spécifiés ici se conforment au format de gabarit et procédures révisés de la [RFC4288] et de la [RFC4855]. Cette mise à jour n'apporte pas de changement technique aux enregistrements. Avec la RFC 4855, le présent document rend obsolète la RFC 3555.

 	1.1	Considérations relatives à l'IANA
En conséquence de l'applicabilité généralisée du registre des types de supports spécifié dans la RFC 4288, certains changements de nomenclature sont nécessaires dans la section Format de charge utile RTP du registre. Dans le titre du registre "Types MIME de format de charge utile RTP" et dans le texte introductif, "MIME" devrait être remplacé par "support". "MIME" devrait être supprimé des en-têtes de tableaux, laissant juste "type de support" et "sous type".

Le présent document met à jour les enregistrements de type de support mentionnés ci-dessous pour se conformer au format d'enregistrement spécifié dans les RFC 4288 et RFC 4855, de sorte que la référence pour ces types de supports devrait être changée de la RFC 3555 en le présent document. Certains enregistrements de type de support contenus dans la RFC 3555 sont omis du présent document ; les enregistrements existants pour ces types continuent d'être valides jusqu'à ce qu'ils soient mis à jour par d'autres RFC. Le présent document ne contient pas de nouveaux enregistrements.

audio/DVI4
audio/G722
audio/G723
audio/G726-16
audio/G726-24
audio/G726-32
audio/G726-40
audio/G728
audio/G729
audio/G729D
audio/G729E
audio/GSM
audio/GSM-EFR
audio/L8
audio/L16
audio/LPC
audio/PCMA
audio/PCMU
audio/VDVI
video/nv

Le type de support audio/L16 était initialement enregistré via la RFC 2586 pour les transports autres que RTP. Cet enregistrement est incorporé ici et augmenté d'informations supplémentaires pour le transport RTP.

 	1.2	Terminologie
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] et indiquent les niveaux d’exigence pour les mises en œuvre conformes à la présente spécification.

 	2.	Enregistrements pour "profil audio/vidéo"

Dans les paragraphes qui suivent, les formats de charge utile RTP définis dans le profil RTP pour les conférences audio et vidéo [RFC3551] sont enregistrés comme types de supports.

 	2.1	Enregistrements de type audio
Pour la plupart des formats de charge utile audio, le débit d'horloge de l'horodatage RTP est égal au taux d'échantillonnage. Certains formats de charge utile ne fonctionnent qu'à un taux d'échantillonnage fixe, alors que d'autres sont ajustables.

Ces formats audio incluent aussi les paramètres facultatifs "ptime" pour spécifier la durée recommandée en millisecondes représentée par le support dans un paquet, et "maxptime" pour spécifier la quantité maximum de support qui peut être encapsulée dans chaque paquet, exprimée comme un temps en millisecondes. Les paramètres "ptime" et "maxptime" sont définis dans le protocole de description de session (SDP, Session Description Protocol) [RFC4566].

 	2.1.1	Enregistrement du type de support audio/DVI4
Nom de type : audio
Nom de sous type : DVI4
Paramètres exigés : rate. Le débit d'horloge de l'horodatage RTP, qui est égal au taux d'échantillonnage. Le taux normal est 8000, mais d'autres taux peuvent être spécifiés.
Paramètres facultatifs : ptime, maxptime (voir la RFC 4566)
Considérations de codage : ce type de support est de données binaires tramées (voir le paragraphe 4.8 de la [RFC4288]).
Considérations de sécurité : ce type de supports ne porte pas de contenu actif. Il transfère des données compressées. Voir la Section 4 de la RFC 4856.
Considérations d'interopérabilité : aucune
Spécification publiée : RFC 3551
Applications qui utilisent ce type de support : flux audio et vidéo directs et outils de conférences.
Informations supplémentaires : aucune
Personne et adresse de messagerie à contacter pour plus d'informations : Stephen Casner <casner@acm.org>
Utilisation prévue : COMMUNE
Restrictions d'usage : ce type de support dépend du tramage RTP, et est donc défini seulement pour le transfert via RTP [RFC3550]. Le transfert au sein d'autres protocoles de tramage n'est pas défini pour l'instant.
Auteur : Stephen Casner
Contrôleur des changements : groupe de travail IETF Audio/Video sur délégation de l'IESG.

 	2.1.2	Enregistrement du type de support audio/G722
Nom de type : audio
Nom de sous type : G722
Paramètres exigés : aucun
Paramètres facultatifs : ptime, maxptime (voir la RFC 4566)
Considérations de codage : ce type de support est de données binaires tramées (voir le paragraphe 4.8 de la [RFC4288]).
Considérations de sécurité : ce type de supports ne porte pas de contenu actif. Il transfère des données compressées. Voir la Section 4 de la RFC 4856.
Considérations d'interopérabilité : aucune
Spécification publiée : RFC 3551
Applications qui utilisent ce type de support : flux audio et vidéo directs et outils de conférences.
Informations supplémentaires : aucune
Personne et adresse de messagerie à contacter pour plus d'informations : Stephen Casner <casner@acm.org>
Utilisation prévue : COMMUNE
Auteur/contrôleur des changements : Stephen Casner
Restrictions d'usage : ce type de support dépend du tramage RTP, et est donc défini seulement pour le transfert via RTP [RFC3550]. Le transfert au sein d'autres protocoles de tramage n'est pas défini pour l'instant.
Auteur : Stephen Casner
Contrôleur des changements : groupe de travail IETF Audio/Video sur délégation de l'IESG.

 	2.1.3	Enregistrement du type de support audio/G723
Nom de type : audio
Nom de sous type : G723
Paramètres exigés : aucun
Paramètres facultatifs :
ptime, maxptime (voir la RFC 4566)
bitrate : débit de données en kbit/s utilisé ou préféré pour le flux de bits audio, dont les valeurs permises sont 5,3 ou 6,3. Si il n'est pas spécifié, le débit binaire peut changer de trame à trame comme indiqué dans la bande.
annexa : indique que la détection d'activité vocale de l'Annexe A est utilisée ou préférée. Les valeurs permises sont "oui" et "non" (sans les guillemets) ; "oui" est implicite si ce paramètre est omis.
Considérations de codage : ce type de support est de données binaires tramées (voir le paragraphe 4.8 de la [RFC4288]).
Considérations de sécurité : ce type de supports ne porte pas de contenu actif. Il transfère des données compressées. Voir la Section 4 de la RFC 4856.
Considérations d'interopérabilité : aucune
Spécification publiée : RFC 3551
Applications qui utilisent ce type de support : flux audio et vidéo directs et outils de conférences.
Informations supplémentaires : aucune
Personne et adresse de messagerie à contacter pour plus d'informations : Stephen Casner <casner@acm.org>
Utilisation prévue : COMMUNE
Restrictions d'usage : ce type de support dépend du tramage RTP, et est donc défini seulement pour le transfert via RTP [RFC3550]. Le transfert au sein d'autres protocoles de tramage n'est pas défini pour l'instant.
Auteur : Stephen Casner
Contrôleur des changements : groupe de travail IETF Audio/Video sur délégation de l'IESG.

 	2.1.4	Enregistrement du type de support audio/G726-16
Nom de type : audio
Nom de sous type : G726-16
Paramètres exigés : aucun
Paramètres facultatifs : ptime, maxptime (voir la RFC 4566)
Considérations de codage : ce type de support est de données binaires tramées (voir le paragraphe 4.8 de la [RFC4288]).
Considérations de sécurité : ce type de supports ne porte pas de contenu actif. Il transfère des données compressées. Voir la Section 4 de la RFC 4856.
Considérations d'interopérabilité : aucune
Spécification publiée : RFC 3551
Applications qui utilisent ce type de support : flux audio et vidéo directs et outils de conférences.
Informations supplémentaires : aucune
Personne et adresse de messagerie à contacter pour plus d'informations : Stephen Casner <casner@acm.org>
Utilisation prévue : COMMUNE
Restrictions d'usage : ce type de support dépend du tramage RTP, et est donc défini seulement pour le transfert via RTP [RFC3550]. Le transfert au sein d'autres protocoles de tramage n'est pas défini pour l'instant.
Auteur : Stephen Casner
Contrôleur des changements : groupe de travail IETF Audio/Video sur délégation de l'IESG.

 	2.1.5	Enregistrement du type de support audio/G726-24
Nom de type : audio
Nom de sous type : G726-24
Paramètres exigés : aucun
Paramètres facultatifs : ptime, maxptime (voir la RFC 4566)
Considérations de codage : ce type de support est de données binaires tramées (voir le paragraphe 4.8 de la [RFC4288]).
Considérations de sécurité : ce type de supports ne porte pas de contenu actif. Il transfère des données compressées. Voir la Section 4 de la RFC 4856.
Considérations d'interopérabilité : aucune
Spécification publiée : RFC 3551
Applications qui utilisent ce type de support : flux audio et vidéo directs et outils de conférences.
Informations supplémentaires : aucune
Personne et adresse de messagerie à contacter pour plus d'informations : Stephen Casner <casner@acm.org>
Utilisation prévue : COMMUN
Restrictions d'usage : ce type de support dépend du tramage RTP, et est donc défini seulement pour le transfert via RTP [RFC3550]. Le transfert au sein d'autres protocoles de tramage n'est pas défini pour l'instant.
Auteur : Stephen Casner
Contrôleur des changements : groupe de travail IETF Audio/Video sur délégation de l'IESG.

 	2.1.6	Enregistrement du type de support MIME audio/G726-32
Nom de type : audio
Nom de sous type : G726-32
Paramètres exigés : aucun
Paramètres facultatifs : ptime, maxptime (voir la RFC 4566)
Considérations de codage : ce type de support est de données binaires tramées (voir le paragraphe 4.8 de la [RFC4288]).
Considérations de sécurité : ce type de supports ne porte pas de contenu actif. Il transfère des données compressées. Voir la Section 4 de la RFC 4856.
Considérations d'interopérabilité : aucune
Spécification publiée : RFC 3551
Applications qui utilisent ce type de support : flux audio et vidéo directs et outils de conférences.
Informations supplémentaires : aucune
Personne et adresse de messagerie à contacter pour plus d'informations : Stephen Casner <casner@acm.org>
Utilisation prévue : COMMUNE
Restrictions d'usage : ce type de support dépend du tramage RTP, et est donc défini seulement pour le transfert via RTP [RFC3550]. Le transfert au sein d'autres protocoles de tramage n'est pas défini pour l'instant.
Auteur : Stephen Casner
Contrôleur des changements : groupe de travail IETF Audio/Video sur délégation de l'IESG.

 	2.1.7	Enregistrement du type de support audio/G726-40
Nom de type : audio
Nom de sous type : G726-40
Paramètres exigés : aucun
Paramètres facultatifs : ptime, maxptime (voir la RFC 4566)
Considérations de codage : ce type de support est de données binaires tramées (voir le paragraphe 4.8 de la [RFC4288]).
Considérations de sécurité : ce type de supports ne porte pas de contenu actif. Il transfère des données compressées. Voir la Section 4 de la RFC 4856.
Considérations d'interopérabilité : aucune
Spécification publiée : RFC 3551
Applications qui utilisent ce type de support : flux audio et vidéo directs et outils de conférences.
Informations supplémentaires : aucune
Personne et adresse de messagerie à contacter pour plus d'informations : Stephen Casner <casner@acm.org>
Utilisation prévue : COMMUNE
Restrictions d'usage : ce type de support dépend du tramage RTP, et est donc défini seulement pour le transfert via RTP [RFC3550]. Le transfert au sein d'autres protocoles de tramage n'est pas défini pour l'instant.
Auteur : Stephen Casner
Contrôleur des changements : groupe de travail IETF Audio/Video sur délégation de l'IESG.

 	2.1.8	Enregistrement du type de support audio/G728
Nom de type : audio
Nom de sous type : G728
Paramètres exigés : aucun
Paramètres facultatifs : ptime, maxptime (voir la RFC 4566)
Considérations de codage : ce type de support est de données binaires tramées (voir le paragraphe 4.8 de la [RFC4288]).
Considérations de sécurité : ce type de supports ne porte pas de contenu actif. Il transfère des données compressées. Voir la Section 4 de la RFC 4856.
Considérations d'interopérabilité : aucune
Spécification publiée : RFC 3551
Applications qui utilisent ce type de support : flux audio et vidéo directs et outils de conférences.
Informations supplémentaires : aucune
Personne et adresse de messagerie à contacter pour plus d'informations : Stephen Casner <casner@acm.org>
Utilisation prévue : COMMUNE
Restrictions d'usage : ce type de support dépend du tramage RTP, et est donc défini seulement pour le transfert via RTP [RFC3550]. Le transfert au sein d'autres protocoles de tramage n'est pas défini pour l'instant.
Auteur : Stephen Casner
Contrôleur des changements : groupe de travail IETF Audio/Video sur délégation de l'IESG.

 	2.1.9	Enregistrement du type de support audio/G729
Nom de type : audio
Nom de sous type : G729
Paramètres exigés : aucun
Paramètres facultatifs :
ptime, maxptime (voir la RFC 4566)
annexb : indique que la détection d'activité vocale de l'Annexe B est utilisée ou préférée. Les valeurs permises sont "oui" et "non" (sans les guillemets) ; "oui" est implicite si ce paramètre est omis.
Considérations de codage : ce type de support est de données binaires tramées (voir le paragraphe 4.8 de la [RFC4288]).
Considérations de sécurité : ce type de supports ne porte pas de contenu actif. Il transfère des données compressées. Voir la Section 4 de la RFC 4856.
Considérations d'interopérabilité : aucune
Spécification publiée : RFC 3551
Applications qui utilisent ce type de support : flux audio et vidéo directs et outils de conférences.
Informations supplémentaires : aucune
Personne et adresse de messagerie à contacter pour plus d'informations : Stephen Casner <casner@acm.org>
Utilisation prévue : COMMUNE
Restrictions d'usage : ce type de support dépend du tramage RTP, et est donc défini seulement pour le transfert via RTP [RFC3550]. Le transfert au sein d'autres protocoles de tramage n'est pas défini pour l'instant.
Auteur : Stephen Casner
Contrôleur des changements : groupe de travail IETF Audio/Video sur délégation de l'IESG.

 	2.1.10	Enregistrement du type de support audio/G729D
Nom de type : audio
Nom de sous type : G729D
Paramètres exigés : aucun
Paramètres facultatifs :
ptime, maxptime (voir la RFC 4566)
annexb : indique que la détection d'activité vocale de l'Annexe B est utilisée ou préférée. Les valeurs permises sont "oui" et "non" (sans les guillemets) ; "oui" est implicite si ce paramètre est omis.
Considérations de codage : ce type de support est de données binaires tramées (voir le paragraphe 4.8 de la [RFC4288]).
Considérations de sécurité : ce type de supports ne porte pas de contenu actif. Il transfère des données compressées. Voir la Section 4 de la RFC 4856.
Considérations d'interopérabilité : aucune
Spécification publiée : RFC 3551
Applications qui utilisent ce type de support : flux audio et vidéo directs et outils de conférences.
Informations supplémentaires : aucune
Personne et adresse de messagerie à contacter pour plus d'informations : Stephen Casner <casner@acm.org>
Utilisation prévue : COMMUNE
Restrictions d'usage : ce type de support dépend du tramage RTP, et est donc défini seulement pour le transfert via RTP [RFC3550]. Le transfert au sein d'autres protocoles de tramage n'est pas défini pour l'instant.
Auteur : Stephen Casner
Contrôleur des changements : groupe de travail IETF Audio/Video sur délégation de l'IESG.

 	2.1.11	Enregistrement du type de support audio/G729E
Nom de type : audio
Nom de sous type : G729E
Paramètres exigés : aucun
Paramètres facultatifs :
ptime, maxptime (voir la RFC 4566)
annexb : indique que la détection d'activité vocale de l'Annexe B est utilisée ou préférée. Les valeurs permises sont "oui" et "non" (sans les guillemets) ; "oui" est implicite si ce paramètre est omis.
Considérations de codage : ce type de support est de données binaires tramées (voir le paragraphe 4.8 de la [RFC4288]).
Considérations de sécurité : ce type de supports ne porte pas de contenu actif. Il transfère des données compressées. Voir la Section 4 de la RFC 4856.
Considérations d'interopérabilité : aucune
Spécification publiée : RFC 3551
Applications qui utilisent ce type de support : flux audio et vidéo directs et outils de conférences.
Informations supplémentaires : aucune
Personne et adresse de messagerie à contacter pour plus d'informations : Stephen Casner <casner@acm.org>
Utilisation prévue : COMMUNE
Restrictions d'usage : ce type de support dépend du tramage RTP, et est donc défini seulement pour le transfert via RTP [RFC3550]. Le transfert au sein d'autres protocoles de tramage n'est pas défini pour l'instant.
Auteur : Stephen Casner
Contrôleur des changements : groupe de travail IETF Audio/Video sur délégation de l'IESG.

 	2.1.12	Enregistrement du type de support audio/GSM
Nom de type : audio
Nom de sous type : GSM
Paramètres exigés : aucun
Paramètres facultatifs : ptime, maxptime (voir la RFC 4566)
Considérations de codage : ce type de support est de données binaires tramées (voir le paragraphe 4.8 de la [RFC4288]).
Considérations de sécurité : ce type de supports ne porte pas de contenu actif. Il transfère des données compressées. Voir la Section 4 de la RFC 4856.
Considérations d'interopérabilité : aucune
Spécification publiée : RFC 3551
Applications qui utilisent ce type de support : flux audio et vidéo directs et outils de conférences.
Informations supplémentaires : aucune
Personne et adresse de messagerie à contacter pour plus d'informations : Stephen Casner <casner@acm.org>
Utilisation prévue : COMMUNE
Restrictions d'usage : ce type de support dépend du tramage RTP, et est donc défini seulement pour le transfert via RTP [RFC3550]. Le transfert au sein d'autres protocoles de tramage n'est pas défini pour l'instant.
Auteur : Stephen Casner
Contrôleur des changements : groupe de travail IETF Audio/Video sur délégation de l'IESG.

 	2.1.13	Enregistrement du type de support audio/GSM-EFR
Nom de type : audio
Nom de sous type : GSM-EFR
Paramètres exigés : aucun
Paramètres facultatifs : ptime, maxptime (voir la RFC 4566)
Considérations de codage : ce type de support est de données binaires tramées (voir le paragraphe 4.8 de la [RFC4288]).
Considérations de sécurité : ce type de supports ne porte pas de contenu actif. Il transfère des données compressées. Voir la Section 4 de la RFC 4856.
Considérations d'interopérabilité : aucune
Spécification publiée : RFC 3551
Applications qui utilisent ce type de support : flux audio et vidéo directs et outils de conférences.
Informations supplémentaires : aucune
Personne et adresse de messagerie à contacter pour plus d'informations : Stephen Casner <casner@acm.org>
Utilisation prévue : COMMUNE
Restrictions d'usage : ce type de support dépend du tramage RTP, et est donc défini seulement pour le transfert via RTP [RFC3550]. Le transfert au sein d'autres protocoles de tramage n'est pas défini pour l'instant.
Auteur : Stephen Casner
Contrôleur des changements : groupe de travail IETF Audio/Video sur délégation de l'IESG.

 	2.1.14	Enregistrement du type de support audio/L8
Nom de type : audio
Nom de sous type : L8
Paramètres exigés : rate, le débit d'horloge de l'horodatage RTP.
Paramètres facultatifs : 
channels : nombre de canaux audio entrelacés, soit 1 pour mono ou 2 pour stéréo, et 1 par défaut. L'entrelacement a lieu entre échantillons individuels d'un octet. L'ordre des canaux est spécifié dans la RFC 3551.
ptime, maxptime (voir la RFC 4566)
Considérations de codage : ce type de support est de données binaires tramées (voir le paragraphe 4.8 de la [RFC4288]).
Considérations de sécurité : ce type de supports ne porte pas de contenu actif. Il transfère des données compressées. Voir la Section 4 de la RFC 4856.
Considérations d'interopérabilité : aucune
Spécification publiée : RFC 3551
Applications qui utilisent ce type de support : flux audio et vidéo directs et outils de conférences.
Informations supplémentaires : aucune
Personne et adresse de messagerie à contacter pour plus d'informations : Stephen Casner <casner@acm.org>
Utilisation prévue : COMMUNE
Restrictions d'usage : ce type de support dépend du tramage RTP, et est donc défini seulement pour le transfert via RTP [RFC3550]. Le transfert au sein d'autres protocoles de tramage n'est pas défini pour l'instant.
Auteur : Stephen Casner
Contrôleur des changements : groupe de travail IETF Audio/Video sur délégation de l'IESG.

 	2.1.15	Enregistrement du type de support audio/L16
Le type de support audio/L16 a été initialement enregistré via la [RFC2586] pour des transports autres que RTP. Cet enregistrement est incorporé ici et augmenté d'informations supplémentaires pour le transport RTP

Nom de type : audio
Nom de sous type : L16
Paramètres exigés  :
rate : nombre d'échantillons par seconde – pour un transport non RTP, les valeurs permises pour le débit sont 8000, 11025, 16000, 22050, 24000, 32000, 44100, et 48000 échantillons par seconde. Pour le transport RTP, d'autres valeurs sont permises mais les valeurs susmentionnées sont RECOMMANDÉES. Pour RTP, le paramètre "rate" indique le débit d'horloge de l'horodatage RTP, qui est égal au taux d'échantillonnage.
Paramètres facultatifs  :
channels : combien de flux audio sont entrelacés – 1 par défaut ; 2 pour la stéréo, etc. L'entrelacement a lieu entre des échantillons individuels de deux octets. L'ordre des canaux est celui spécifié dans la RFC 3551 sauf si un paramètre "channel-order" est aussi présent.
emphasis : pré accentuation analogique appliquée au signal avant quantification. La seule valeur d'accentuation définie ici est emphasis=50-15 pour indiquer la pré accentuation de 50/15 microsecondes utilisée avec les disques compacts. Ce paramètre DOIT être omis si aucune pré accentuation analogique n'a été appliquée. Noter que c'est un paramètre de propriété de flux, non un paramètre de configuration de receveur. Donc, si les paramètres sont négociés, il se peut que l'envoyeur ne puisse pas se conformer à la demande d'un réglage particulier de receveur.
channel-order : spécifie l'ordre d'entrelacement d'échantillons pour les flux audio à canaux multiples (voir la Section 7 de la [RFC3190]). Les valeurs permises sont DV.LRLsRs, DV.LRCS, DV.LRCWo, DV.LRLsRsC, DV.LRLsRsCS, DV.LmixRmixTWoQ1Q2, DV.LRCWoLsRsLmixRmix, DV.LRCWoLs1Rs1Ls2Rs2, DV.LRCWoLsRsLcRc. Pour l'inter fonctionnement avec les systèmes vidéo DV, seul un sous ensemble de ces combinaisons de canaux est spécifié pour être utilisé avec le codage linéaire à 20 bits de la spécification vidéo DV [IEC.61834] ; ce sont DV.LRLsRs, DV.LRCS, DV.LmixRmixTWoQ1Q2. Ce paramètre DOIT être omis quand la convention d'ordre de canal AIFF-C (voir la RFC3551) est utilisée.
Pour RTP, ptime : durée RECOMMANDÉ de chaque paquet en millisecondes.
Pour RTP, maxptime : durée maximum de chaque paquet en millisecondes.
Considérations  de codage : les données audio sont binaires, et doivent être codées pour un transport non binaire ; le codage Base64 convient pour la messagerie électronique. Noter que les données audio ne se compressent pas facilement en utilisant la compression sans pertes. Ce type est aussi défini pour le transfert via RTP [RFC 3550].
Considérations  de sécurité : il est estimé que les données Audio/L16 ne présentent pas de risque pour la sécurité. Ce type de support ne porte pas de contenu actif. Le codage n'est pas compressé. Voir la Section 4 de la RFC 4856.
Considérations  d'interopérabilité : ce type est compatible avec le codage utilisé dans les types WAV (Microsoft Windows RIFF) et Apple AIFF union, et avec les programmes "sox" et "rateconv" du domaine public.
Spécification publiée : RFC 2586 pour transports non RTP, RFC 3551 pour RTP.
Applications qui utilisent ce type de support : les programmes "sox" et "rateconv" du domaine public acceptent ce type.
Informations supplémentaires :
Numéro magique : aucun
Extension de fichier: WAV L16
Code de type de fichier Macintosh : AIFF
Personne et adresse de messagerie à contacter pour plus d'informations : James Salsman <jps-L16@bovik.org>
Utilisation prévue : COMMUNE. Il est prévu que de nombreuses applications audio et de parole utiliseront ce type. Déjà les plateformes les plus populaires fournissent ce type avec le paramètre rate=11025, appelé "parole de qualité radio".
Restrictions d'usage : en plus des méthodes de transfert fondées sur le fichier, ce type est aussi défini pour le transfert via RTP (RFC 3550).
Auteurs : James Salsman pour les transports non RTP  ; Stephen Casner pour le transport RTP.
Contrôleur des changements : James Salsman pour les transports non RTP; pour le transport RTP, groupe de travail IETF Audio/Video sur délégation de l'IESG .

 	2.1.16	Enregistrement du type de support audio/LPC
Nom de type : audio
Nom de sous type : LPC
Paramètres exigés : aucune
Paramètres facultatifs : ptime, maxptime (voir la RFC 4566)
Considérations de codage : ce type de support est de données binaires tramées (voir le paragraphe 4.8 de la [RFC4288]).
Considérations de sécurité : ce type de supports ne porte pas de contenu actif. Il transfère des données compressées. Voir la Section 4 de la RFC 4856.
Considérations d'interopérabilité : aucune
Spécification publiée : RFC 3551
Applications qui utilisent ce type de support : flux audio et vidéo directs et outils de conférences.
Informations supplémentaires : aucune
Personne et adresse de messagerie à contacter pour plus d'informations : Stephen Casner <casner@acm.org>
Utilisation prévue : COMMUNE
Restrictions d'usage : ce type de support dépend du tramage RTP, et est donc défini seulement pour le transfert via RTP [RFC3550]. Le transfert au sein d'autres protocoles de tramage n'est pas défini pour l'instant.
Auteur : Stephen Casner
Contrôleur des changements : groupe de travail IETF Audio/Video sur délégation de l'IESG.

 	2.1.17	Enregistrement du type de support audio/PCMA
Nom de type : audio
Nom de sous type : PCMA
Paramètres exigés : rate. Le débit d'horloge de l'horodatage RTP, qui est égal au taux d'échantillonnage. Le taux normal est 8000, mais d'autres taux peuvent être spécifiés.
Paramètres facultatifs : 
channels : nombre de canaux audio entrelacés, soit 1 pour mono ou 2 pour stéréo, et 1 par défaut. L'entrelacement a lieu entre échantillons individuels d'un octet. L'ordre des canaux est spécifié dans la RFC 3551.
ptime, maxptime (voir la RFC 4566)
Considérations de codage : ce type de support est de données binaires tramées (voir le paragraphe 4.8 de la [RFC4288]).
Considérations de sécurité : ce type de supports ne porte pas de contenu actif. Il transfère des données compressées. Voir la Section 4 de la RFC 4856.
Considérations d'interopérabilité : aucune
Spécification publiée : RFC 3551
Applications qui utilisent ce type de support : flux audio et vidéo directs et outils de conférences.
Informations supplémentaires : aucune
Personne et adresse de messagerie à contacter pour plus d'informations : Stephen Casner <casner@acm.org>
Utilisation prévue : COMMUNE
Restrictions d'usage : ce type de support dépend du tramage RTP, et est donc défini seulement pour le transfert via RTP [RFC3550]. Le transfert au sein d'autres protocoles de tramage n'est pas défini pour l'instant.
Auteur : Stephen Casner
Contrôleur des changements : groupe de travail IETF Audio/Video sur délégation de l'IESG.

 	2.1.18	Enregistrement du type de support audio/PCMU
Nom de type : audio
Nom de sous type : PCMU
Paramètres exigés : rate. Le débit d'horloge de l'horodatage RTP, qui est égal au taux d'échantillonnage. Le taux normal est 8000, mais d'autres taux peuvent être spécifiés.
Paramètres facultatifs : 
channels : nombre de canaux audio entrelacés, soit 1 pour mono ou 2 pour stéréo, et 1 par défaut. L'entrelacement a lieu entre échantillons individuels d'un octet. L'ordre des canaux est spécifié dans la RFC 3551.
ptime, maxptime (voir la RFC 4566)
Considérations de codage : ce type de support est de données binaires tramées (voir le paragraphe 4.8 de la [RFC4288]).
Considérations de sécurité : ce type de supports ne porte pas de contenu actif. Il transfère des données compressées. Voir la Section 4 de la RFC 4856.
Considérations d'interopérabilité : aucune
Spécification publiée : RFC 3551
Applications qui utilisent ce type de support : flux audio et vidéo directs et outils de conférences.
Informations supplémentaires : aucune
Personne et adresse de messagerie à contacter pour plus d'informations : Stephen Casner <casner@acm.org>
Utilisation prévue : COMMUNE
Restrictions d'usage : ce type de support dépend du tramage RTP, et est donc défini seulement pour le transfert via RTP [RFC3550]. Le transfert au sein d'autres protocoles de tramage n'est pas défini pour l'instant.
Auteur : Stephen Casner
Contrôleur des changements : groupe de travail IETF Audio/Video sur délégation de l'IESG.

 	2.1.19	Enregistrement du type de support audio/VDVI
Nom de type : audio
Nom de sous type : VDVI
Paramètres exigés : aucun
Paramètres facultatifs : ptime, maxptime (voir la RFC 4566)
Considérations de codage : ce type de support est de données binaires tramées (voir le paragraphe 4.8 de la [RFC4288]).
Considérations de sécurité : ce type de supports ne porte pas de contenu actif. Il transfère des données compressées. Voir la Section 4 de la RFC 4856.
Considérations d'interopérabilité : aucune
Spécification publiée : RFC 3551
Applications qui utilisent ce type de support : flux audio et vidéo directs et outils de conférences.
Informations supplémentaires : aucune
Personne et adresse de messagerie à contacter pour plus d'informations : Stephen Casner <casner@acm.org>
Utilisation prévue : COMMUNE
Restrictions d'usage : ce type de support dépend du tramage RTP, et est donc défini seulement pour le transfert via RTP [RFC3550]. Le transfert au sein d'autres protocoles de tramage n'est pas défini pour l'instant.
Auteur : Stephen Casner
Contrôleur des changements : groupe de travail IETF Audio/Video sur délégation de l'IESG.

 	2.2	Enregistrements du type Vidéo
Pour la plupart des formats de charge utile de vidéo enregistrés ici, le débit d'horloge de l'horodatage RTP est toujours 90000 Hz, de sorte que le paramètre "rate" n'est pas applicable. De même, le paramètre "channel" n'est pas utilisé avec la vidéo, et bien que "ptime" et "maxptime" pourraient être utilisés avec la vidéo, ils ne le sont normalement pas.

 	2.2.1	Enregistrement du type de support video/nv
Nom de type : video
Nom de sous type : nv
Paramètres exigés : aucun
Paramètres facultatifs : aucun
Considérations de codage : ce type de support est de données binaires tramées (voir le paragraphe 4.8 de la [RFC4288]).
Considérations de sécurité : ce type de supports ne porte pas de contenu actif. Il transfère des données compressées. Voir la Section 4 de la RFC 4856.
Considérations d'interopérabilité : aucune
Spécification publiée : RFC 3551
Applications qui utilisent ce type de support : flux audio et vidéo directs et outils de conférences.
Informations supplémentaires : aucune
Personne et adresse de messagerie à contacter pour plus d'informations : Stephen Casner <casner@acm.org>
Utilisation prévue : COMMUNE
Restrictions d'usage : ce type de support dépend du tramage RTP, et est donc défini seulement pour le transfert via RTP [RFC3550]. Le transfert au sein d'autres protocoles de tramage n'est pas défini pour l'instant.
Auteur : Stephen Casner
Contrôleur des changements : groupe de travail IETF Audio/Video sur délégation de l'IESG.

 	3.	Changements par rapport à la RFC 3555

La RFC 3555 est rendue obsolète par la combinaison de la [RFC4855] et du présent document. La RFC 4855 conserve la spécification des procédures et exigences de la RFC 3555, tandis que les enregistrements de type de support de la RFC  3555 ont été placés dans le présent document. Les enregistrements de type de support pour les formats de charge utile RTP qui sont référencés dans la [RFC3551], mais définis dans d'autres RFC, ont été sortis du présent document parce que ces enregistrements sont destinés à être mis à jour en les incluant dans les révisions des RFC individuelles qui définissent les formats de charge utile.

Les enregistrements de type de support dans le présent document ont été mis à jour pour se conformer aux procédures révisées d'enregistrement de type de support des [RFC4288] et [RFC4855]. Alors que la RFC 3555 exigeait que les considérations de codage spécifient les transfert via RTP, ceci est maintenant spécifié sous les restrictions d'usage. Les considérations de codage avertissent maintenant que ces types sont des données binaires tramées. Le contrôleur des changements est maintenant identifié en accord avec les conventions actuelles. Le paramètre facultatif "channels" a été précisé pour les sous types audio L8, PCMA, et PCMU. Finalement, la référence [CEI.61834], qui manquait dans la RFC  3555, a été rajoutée.

 	4.	Considérations sur la sécurité

Le présent mémoire spécifie les enregistrements de type de support pour le transfert de plusieurs codages de données compressées audio et vidéo via RTP, de sorte que les mises en œuvre qui utilisent ces types de supports sont soumises aux considérations sur la sécurité discutées dans la spécification RTP [RFC3550].

Aucun de ces types de supports ne porte de "contenu actif" qui pourrait imposer des effets collatéraux malveillants au receveur. Le contenu consiste seulement en données audio ou vidéo compressées à décoder et présenter comme du son ou des images. Cependant, plusieurs codages audio et vidéo sont parfaits pour cacher des données en utilisant la stéganographie.

Une menace potentielle de déni de service existe pour les codages de données qui utilisent des techniques de compression qui ont une charge de calcul non uniforme côté receveur. L'attaquant peut injecter des datagrammes pathologiques dans le flux, qui soient complexes à décoder et causent la surcharge du receveur. Cependant, aucun des codages enregistrés ici n'a de facteur d'expansion supérieur à environ 20, et tous sont considérés comme relativement simples selon les standard modernes (certains sont mis en œuvre sur des appareils portables et la plupart ont été mis en œuvre sur des ordinateurs non spécialisés il y a dix ans).

Comme avec tout protocole fondé sur IP, dans certaines circonstances un receveur peut être surchargé simplement par la réception de trop de paquets, désirés ou indésirés. l'authentification de couche réseau PEUT être utilisée pour éliminer les paquets provenant de sources non désirées, mais le coût de traitement de l'authentidication elle-même peut être trop élevé.

RTP peut être envoyé via la diffusion groupée IP, qui ne fournit pas de moyen direct à un envoyeur pour connaître tous les receveurs des données envoyées et n'a donc aucune mesure de confidentialité. À tort ou à raison, les utilisateurs peuvent être plus sensibles aux problèmes de confidentialité avec les communications audio et vidéo qu'ils ne le sont avec des formes plus traditionnelles de communication en réseau. Donc, l'utilisation de mécanismes de sécurité avec RTP pour assurer la protection de la confidentialité et de l'intégrité des données est importante. Parce que la compression de données utilisée avec ces types de supports est appliquée de bout en bout, le chiffrement peut être effectué après la compression, de sorte qu'il n'y a pas de conflit entre les deux opérations.

 	5.	Références
 	5.1	Références normatives

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

[RFC3190]	K. Kobayashi et autres, "Format de charge utile RTP pour audio DAT à 12 bits et audio échantillonné à 20- et 24 bits linéaire", janvier 2002 . (P.S.)

[RFC3550]	H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson, "RTP : un protocole de transport pour les applications en temps réel", STD 64, juillet 2003. (MàJ par RFC7164, RFC7160, RFC8083, RFC8108, RFC8860)

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

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

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

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

 	5.2	Références pour information

[CEI.61834]	Norme CEI.61834, "Helical-scan digital video cassette recording system using 6,35 mm magnetic tape for consumer use (525-60, 625-50, 1125-60, and 1250-50 systems)", août 1998.

[RFC2586]	J. Salsman, H. Alvestrand, "Type de contenu MIME Audio/L16", mai 1999. (Information)

 	Adresse de l'auteur
Stephen L. Casner	
Packet Design	
3400 Hillview Avenue, Building 3	
Palo Alto, CA 94304	
USA	
téléphone : +1 650 739-1843	
mél : casner@acm.org 	

 	Déclaration complète de droits de reproduction
Copyright (C) The IETF Trust (2007).

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

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

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

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

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

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