Équipe d'ingénierie de l'Internet (IETF)	F. de Bont, Philips Electronics	
Request for Comments: 5691	S. Doehla, Fraunhofer IIS	
RFCmise à jour : 3640	M. Schmidt, Dolby Laboratories	
Catégorie : Sur la voie de la normalisation	R. Sperschneider, Fraunhofer IIS	
ISSN: 2070-1721	octobre 2009	
Traduction Claude Brière de L'Isle		

Format de charge utile RTP pour les flux élémentaires avec audio MPEG multi-canal en son environnant

Résumé
Le présent mémoire décrit des extensions pour le format de charge utile RTP défini dans la RFC 3640 pour le transport d'audio MPEG multi canaux en son environnant. Des paramètres de type de support supplémentaires sont définis pour signaler une transmission rétro-compatible à l'intérieur d'un flux élémentaire audio MPEG-4. De plus, un schéma de transmission en couches qui n'utilise pas le cadre des systèmes MPEG-4 est présenté pour transporter un flux élémentaire MPEG en son environnant via RTP en parallèle avec un flux RTP contenant les données audio converties.

Statut de ce mémoire
Ceci est un document de l’Internet sur la voie de la normalisation.

Le présent document a été produit par l’équipe d’ingénierie de l’Internet (IETF). Il représente le consensus de la communauté de l’IETF. Il a subi une révision publique et sa publication a été approuvée par le groupe de pilotage de l’ingénierie de l’Internet (IESG). Tous les documents approuvés par l’IESG ne sont pas candidats à devenir une norme de l’Internet ; voir la Section 2 de la RFC5741.

Les informations sur le statut actuel du présent document, tout errata, et comment fournir des réactions sur lui peuvent être obtenues à http://www.rfc-editor.org/info/rfc5691 

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

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. Les composants de code extraits du présent document doivent inclure le texte de licence simplifié de BSD comme décrit au paragraphe 4.e des dispositions légales du Trust et sont fournis sans garantie comme décrit dans la licence de BSD simplifiée.
Table des matières
1. Introduction	2
2. Conventions	2
3. Définitions et abréviations	2
3.1 Définitions	2
3.2 Abréviations	2
4. Transport de MPEG en son environnant	3
4.1 Données audio spatiales incorporées dans des charges utiles AAC	3
4.2 Flux élémentaire MPEG en son environnant	4
5. Considérations relatives à l'IANA	5
5.1 Enregistrement du type de support	5
5.2 Enregistrement des définitions de mode par l'IANA	6
5.3 Usage de SDP	6
6. Considérations sur la sécurité	6
7. Références	7
7.1 Références normatives	7
7.2 Références pour information	7
Adresse des auteurs	7

 	1.	Introduction

Le codage audio spatial (SAC, Spatial Audio Coding) MPEG en son environnant (MPEG Surround) [23003-1] est une norme internationale qui a été finalisée par MPEG en janvier 2007. Il est capable de recréer N canaux sur la base de M < N canaux transmis et des données de contrôle supplémentaires. Dans les modes préférés de fonctionnement du système de codage audio spatial, les M canaux peuvent être un seul canal mono ou une paire de canaux stéréo. Les données de contrôle représentent une charge de données significativement inférieure à celle exigée pour transmettre tous les N canaux, rendant ce codage très efficace tout en assurant en même temps la compatibilité avec les appareils à M canaux.

La norme MPEG en son environnant incorpore un certain nombre d'outils qui permettent des caractéristiques de large application de la norme. Une caractéristique clé est la capacité d'adapter graduellement la qualité de l'image spatiale de frais généraux spatiaux très faibles jusqu'à la transparence. Une autre caractéristique clé est que l'entrée au décodeur peut être rendue compatible avec les technologies existantes de matrice de son environnant.

Par exemple, pour de l'audio multi-canaux 5.1, le codeur MPEG Surround crée un signal stéréo (ou mono) converti et des informations spatiales décrivant tout le matériel 5.1 dans un format paramétré très efficace. Les informations spatiales sont transmises à côté de la conversion.

En utilisant MPEG en son environnant, les services existants peuvent facilement être mis à niveau pour fournir le son environnant de façon rétro-compatible. Alors qu'un décodeur stéréo dans un appareil traditionnel existant ignore les données de MPEG en son environnant et exécute le signal stéréo sans aucune dégradation de qualité, un décodeur à capacité MPEG en son environnant va livrer de l'audio multi-canaux de haute qualité.

Le décodeur MPEG en son environnant peut opérer dans des modes qui rendent le signal multi-canaux en sortie multi-canaux ou stéréo, ou il peut opérer dans un mode de casque à deux canaux pour produire un signal de sortie en son environnant virtuel.

 	2.	Conventions

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

 	3.	Définitions et abréviations
 	3.1	Définitions
Le présent mémoire utilise les définitions spécifiées dans [14496-1], [14496-3], [23003-1], et la [RFC3640]. On reprend ici les termes fréquemment utilisés :

Unité d'accès : une unité d'accès MPEG est la plus petite entité de données à laquelle sont attribuées des informations temporelles. Dans le cas de l'audio, une unité d'accès est la plus petite portion individuellement accessible de données audio codées dans un flux élémentaire.

AudioSpecificConfig() : étend la classe DecoderSpecificInfo(), comme défini dans [14496-1], quand l'indication objectType se réfère à un flux conforme à [14496-3]. AudioSpecificConfig() est utilisé comme structure de configuration pour l'audio MPEG-4 comme spécifié dans [14496-3]. Il contient le champ audioObjectType, qui distingue les différents codecs audio définis dans [14496-3], les informations audio générales (par exemple, fréquence d'échantillonnage et nombre de canaux) et d'autres structures d'informations dépendantes du codec.

SpatialSpecificConfig() : structure de configuration pour le codage audio MPEG en son environnant, comme spécifié dans [23003-1]. Un AudioSpecificConfig() avec un audioObjectType de valeur 30 contient une structure SpatialSpecificConfig().

 	3.2	Abréviations
AOT (Audio Object Type) : type d'objet audio
AAC (Advanced Audio Coding) : codage audio évolué
ASC (AudioSpecificConfig() structure) : structure de configuration spécifique de l'audio
AU (Access Unit) : unité d'accès
HE AAC (High Efficiency AAC) : codage audio évolué de haute efficacité
PLI (Profile et Level Indication) : indication de profil et de niveau
SSC (SpatialSpecificConfig() structure) : structure de configuration spatiale spécifique

 	4.	Transport de MPEG en son environnant

D'un point de vue général, les données de MPEG en son environnant peuvent être subdivisées en données de configuration contenues dans la structure SpatialSpecificConfig() (SSC) et la trame spatiale SpatialFrame(), qui contient la charge utile MPEG Surround. Les données de configuration peuvent être signalées dans la bande ou hors bande. Dans le cas de signalisation dans la bande les SSC sont convoyées dans une SacDataFrame() conjointement avec une SpatialFrame(). Dans le cas de signalisation hors bande, les SSC sont transmises séparément au décodeur, par exemple, au moyen du protocole de description de session (SDP, Session Description Protocol) [RFC4566].

Les SpatialFrame() peuvent être transmises soit incorporées dans le flux converti (paragraphe 4.1) soit comme des flux individuels à côté des flux audio convertis (paragraphe 4.2).

Les définitions de mémoire tampon pour les décodeurs AAC limitent la taille d'une AU, comme spécifié dans [14496-3]. Pour les applications à débit élevé qui excèdent cette limite, toutes les données MPEG en son environnant DOIVENT être mises dans un flux séparé, comme défini au paragraphe 4.2.

 	4.1	Données audio spatiales incorporées dans des charges utiles AAC
[14496-3] définit extension_payload() comme un mécanisme pour transporter des données d'extension à l'intérieur de charges utiles AAC. Les données d'extension normales incluent des données de duplication de bande spectrale (SBR, Spectral Band Replication) et des données MPEG en son environnant, c'est-à-dire, une SacDataFrame() dans des extension_payload() de type EXT_SAC_DATA. Les extension_payload() résident dans le flux élémentaire d'AAC converties. Le flux élémentaire unique résultant est transporté comme spécifié dans la [RFC3640]. Comme il est exigé des décodeurs AAC qu'ils sautent les données d'extension inconnues, les données MPEG en son environnant peuvent être incorporées de façon rétro-compatible et être transportées avec le mécanisme déjà décrit dans la [RFC3640].

La SacDataFrame() inclut une SpatialFrame() et un en-tête facultatif qui contient un SSC. Tout SSC dans une SacDataFrame() DOIT être identique au SSC convoyé via SDP pour ce flux.

Aucun nouveau mode n'est introduit pour les SpatialFrame() incorporées dans les charges utiles AAC. Le mode AAC-lbr ou le mode AAC-hbr DEVRAIT être utilisé. Les paramètres de type de support supplémentaires, comme définis au paragraphe 5.1, DEVRAIENT être présents quand des SpatialFrame() sont incorporées dans des charges utiles AAC.

Par exemple :

m=audio 5000 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/48000/2
a=fmtp:96 streamType=5; profile-level-id=44; mode=AAC-hbr; config=131
  056E598; sizeLength=13; indexLength=3; indexDeltaLength=3; constant
  Duration=2048; MPS-profile-level-id=55; MPS-config=F1B4CF920442029B501185B6DA00;

Dans cet exemple, le flux spécifie le profil HE AAC au niveau 2 [Indication de profil et de niveau (PLI) 44] et la chaîne de configuration contient la représentation hexadécimale de l'ASC HE AAC [audioObjectType=2 (AAC LC) ; extensionAudioObjectType=5 (SBR) ; samplingFrequencyIndex=0x6 (24 kHz) ; extensionSamplingFrequencyIndex=0x3 (48  kHz) ; channelConfiguration=2 (canaux 2.0)] du flux élémentaire AAC converti qui utilise la signalisation rétro-compatible explicite.

De plus, le flux spécifie le profil de base de MPEG en son environnant au niveau 3 (PLI55) et la chaîne de configuration MPS contient la représentation hexadécimale de l'ASC MPEG en son environnant [audioObjectType=30 (MPEG Surround) ; samplingFrequencyIndex=0x3 (48 kHz) ; channelConfiguration=6 (canaux 5.1) ; sacPayloadEmbedding=1 ; SSC=(48  kHz ; 32 intervalles ; 525 tree; ResCoding=1; ResBands=[0,13,13,13])].

Noter que la ligne a=fmtp de l'exemple ci-dessus fait des sauts à la ligne pour tenir dans la page ; elle comporterait une seule ligne dans le fichier SDP.

 	4.2	Flux élémentaire MPEG en son environnant
Les SpatialFrame() de MPEG en son environnant peuvent être présentes dans un flux élémentaire individuel. Ce flux complète le flux contenant les données audio converties, qui peuvent être codées par un schéma de codage arbitraire. Les flux élémentaires de MPEG en son environnant sont mis en paquets comme spécifié dans la [RFC3640]. Le mode signalé et utilisé pour un flux élémentaire de MPEG en son environnant DOIT être MPS-hbr ou MPS-lbr. Le mode MPS-hbr DEVRA être utilisé quand la taille de trame peut excéder 63 octets, par exemple, quand un codage résiduel à haut débit est utilisé.

Les relations de dépendance entre le flux élémentaire de MPEG en son environnant et le flux converti sont signalées comme spécifié dans la [RFC5583].

Les horloges des supports du flux élémentaire de MPEG en son environnant et du flux converti DEVRONT opérer dans le même domaine d'horloge, c'est-à-dire, les horloges sont déduites d'une horloge commune et NE DOIVENT PAS dériver. Les rapports d'envoyeur TCP DOIVENT indiquer que les horodatages des  flux ne dérivent pas, c'est-à-dire, un seul rapport d'envoyeur pour chaque flux est suffisant pour établir une heure non ambiguë. Le taux d'échantillonnage du signal MPEG en son environnant et le signal converti décodé DOIVENT être identiques.

Si HE AAC est utilisé comme schéma de codage pour le flux converti, le taux d'horloge RTP du flux converti PEUT être le taux d'échantillonnage du cœur AAC, c'est-à-dire, le débit d'horloge du flux élémentaire MPEG en son environnant est un multiple entier du débit d'horloge du flux converti.

Noter que des flux RTP séparés ont des décalages d'horodatage RTP aléatoires différents, et donc RTCP DOIT être utilisé pour synchroniser les données audio converties codées et le flux élémentaire de MPEG en son environnant.

Par exemple:

a=group:DDP L1 L2
m=audio 5000 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/48000/2
a=fmtp:96 streamType=5; profile-level-id=44; mode=AAC-hbr; config=2B1
     18800; sizeLength=13; indexLength=3; indexDeltaLength=3; constantDuration=2048
a=mid:L1

m=audio 5002 RTP/AVP 97
a=rtpmap:97 mpeg4-generic/48000/6
a=fmtp:97 streamType=5; profile-level-id=55; mode=MPS-hbr; config=F1B
     0CF920460029B601189E79E70; sizeLength=13; indexLength=3;  indexDelt
     aLength=3; constantDuration=2048
a=mid:L2
a=depend:97 lay L1:96

Dans cet exemple, le premier flux spécifie le profil HE AAC au niveau 2 (PLI44) et la chaîne config contient la représentation hexadécimale de l'ASC HE AAC [audioObjectType=2 (AAC LC) ; extensionAudioObjectType=5 (SBR) ; samplingFrequencyIndex=0x6 (24 kHz) ; extensionSamplingFrequencyIndex=0x3 (48 kHz) ; channelConfiguration=2 (canaux 2.0)].

Le second flux spécifie le profil MPEG en son environnant de base au niveau 3 (PLI55) et la chaîne config contient la représentation hexadécimale de l'ASC [AOT=30(MPEG Surround) ; 48 kHz ; canaux 5.1 ; sacPayloadEmbedding=0 ; SSC=(48 kHz; 32 intervalles ; 525 tree ; ResCoding=1 ; ResBands=[7,7,7,7])].

Noter que les lignes a=fmtp de l'exemple ci-dessus font des sauts à la ligne pour tenir dans la page ; elles comporteraient une seule ligne dans le fichier SDP.

 	4.2.1	MPEG en son environnant à faible débit binaire
Ce mode est signalé par mode=MPS-lbr. Ce mode prend en charge le transport d'une ou plusieurs unités d'accès complètes, chacune consistant en une seule SpatialFrame() MPEG Surround. Les AU peuvent être de taille et d'entrelaçage variables. La taille maximum d'une SpatialFrame() est 63 octets. La fragmentation NE DOIT PAS être utilisée dans ce mode. Les receveurs DOIVENT prendre en charge le désentrelaçage.

La configuration de charge utile est la même que dans le mode AAC-lbr. Elle consiste en la section d'en-tête AU, suivie par les AU enchaînés. Noter que les unités d'accès sont alignées sur l'octet. La Section Auxiliaire DOIT être vide dans le mode MPS-lbr. L'en-tête AU d'un octet DOIT fournir :
1.	la taille de chaque trame AAC, codée sur 6 bits,
2.	2 bits d'informations d'indice pour calculer la séquence (et donc l'heure) de chaque SpatialFrame().

La section d'en-tête AU enchaînée DOIT être précédée par le champ de 16 bits Longueur d'en-tête AU.

En plus des paramètres exigés de format de support, les paramètres suivants DOIVENT être présents avec des valeurs fixes : sizeLength (valeur 6) indexLength (valeur 2) et indexDeltaLength (valeur 2). Le paramètre maxDisplacement DOIT être présent quand il y a entrelaçage. Les SpatialFrame() ont toujours une durée fixe par AU ; la durée fixe DOIT être signalée par le paramètre de format de support constantDuration.

La valeur du paramètre "config" est la représentation hexadécimale de l'ASC, comme défini dans [14496-3], avec un AOT de 30 et le fanion sacPayloadEmbedding réglé à 0. Le paramètre "profile-level-id" DEVRA contenir une PLI valide pour MPEG en son environnant, comme spécifié dans [14496-3].

 	4.2.2	MPEG en son environnant à haut débit binaire
Ce mode est signalé par mode=MPS-hbr. Ce mode prend en charge le transport d'un fragment d'une unité d'accès ou d'une ou plusieurs AU complètes. Chaque AU consiste en une seule SpatialFrame() de MPEG en son environnant. Les AU peuvent être de taille et entrelaçage variables. La taille maximum d'une SpatialFrame() est 8191 octets. Les receveurs DOIVENT prendre en charge le désentrelaçage.

La configuration de charge utile est la même que dans le mode AAC-hbr. Elle consiste en la section d'en-tête AU, suivie d'une SpatialFrame(), d'un fragment d'une SpatialFrame(), ou de plusieurs SpatialFrame() enchaînées. Noter que les unités d'accès sont alignées sur l'octet. La Section Auxiliaire DOIT être vide dans le mode MPS-hbr. L'en-tête AU de deux octets DOIT fournir :
1.	la taille de chaque trame AAC, codée sur 13 bits,
2.	3 bits d'informations d'indice pour calculer la séquence (et donc l'heure) de chaque SpatialFrame() c'est-à-dire, le champ AU-Index ou AU-Index-delta.

Chaque champ AU-Index DOIT être codé avec la valeur 0. La section En-tête AU enchaînée DOIT être précédée du champ de 16 bits Longueur d'en-têtes AU.

En plus des paramètres exigés de format de supports, les paramètres suivants DOIVENT être présents avec des valeurs fixes : sizeLength (valeur 13) indexLength (valeur 3) et indexDeltaLength (valeur 3). Le paramètre maxDisplacement DOIT être présent en cas d'entrelaçage. Les SpatialFrame() ont toujours une durée fixe par AU ; la durée fixe DOIT être signalée par le paramètre de format de support constantDuration.

La valeur du paramètre "config" est la représentation hexadécimale de l'ASC, comme défini dans [14496-3], avec un AOT de 30 et le fanion sacPayloadEmbedding réglé à 0.

Le paramètre "profile-level-id" DEVRA contenir une PLI valide pour MPEG en son environnant, comme spécifié dans [14496-3].

 	5.	Considérations relatives à l'IANA

Le présent mémoire définit des paramètres de format supplémentaires facultatifs au type de support "audio" et son sous type "mpeg4-generic". Ces paramètres DEVRONT seulement être utilisés en combinaison avec les modes AAC-lbr ou AAC-hbr (cf. paragraphe 3.3 de la [RFC3640]) de "mpeg4-generic".

 	5.1	Enregistrement du type de support
Le présent mémoire définit les paramètres facultatifs supplémentaires suivants qui DEVRONT être utilisés si des données MPEG en son environnant sont présentes dans la charge utile d'un flux élémentaire AAC.

MPS-profile-level-id : représentation décimale de l'indication de profil et niveau MPEG en son environnant comme défini dans [14496-3]. Ce paramètre DOIT être utilisé dans l'échange de capacités ou la procédure d'établissement de session pour indiquer le profil et niveau MPEG en son environnant dont le décodeur doit être capable afin de décoder le flux.

MPS-config : représentation hexadécimale d'une chaîne d'octets qui exprime la configuration spécifique de l'audio (ASC, AudioSpecificConfig) comme défini dans [14496-3], pour MPEG Surround. L'ASC est transposée en la chaîne d'octets hexadécimale avec le bit de poids fort en premier. Le AOT dans cette ASC DEVRA avoir la valeur 30. Le SSC dans l'ASC DOIT avoir le fanion sacPayloadEmbedding réglé à 1.

 	5.2	Enregistrement des définitions de mode par l'IANA
Ce paragraphe demande l'enregistrement des valeurs "MPS-hbr" et "MPS-lbr" pour le paramètre "mode" du sous type de support "mpeg4-generic" dans le type de support "audio". Le sous type de support "mpeg4-generic" est défini dans la [RFC3640], et la [RFC3640] définit un répertoire pour le paramètre "mode". Le présent mémoire enregistre les modes "MPS-hbr" et "MPS-lbr" pour prendre en charge les flux élémentaires MPEG en son environnant.

Nom de type de support : audio
Nom de sous type : mpeg4-generic
Paramètres exigés : le paramètre "mode" est exigé par la [RFC3640]. Le présent mémoire spécifie les modes supplémentaires "MPS-hbr" et "MPS-lbr", en accord avec la [RFC3640].
Paramètres facultatifs : pour les modes "AAC-hbr" et "AAC-lbr", le présent mémoire spécifie les paramètres facultatifs supplémentaires "MPS-profile-level-id" et "MPS-config". Voir au paragraphe 4.1 les détails d'usage. Les paramètres facultatifs pour les modes "MPS-hbr" et "MPS-lbr" peuvent être utilisés comme spécifié dans la [RFC3640]. Les paramètres facultatifs "MPS-profile-level-id" et "MPS-config" NE DEVRONT PAS être utilisés pour les modes "MPS-hbr" et "MPS-lbr".

 	5.3	Usage de SDP
On suppose que les paramètres de format de support sont portés via un message SDP, comme spécifié au paragraphe 4.4 de la [RFC3640].

 	6.	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 sujets aux considérations sur la sécurité discutées dans la spécification RTP [RFC3550], dans la spécification de format de charge utile RTP pour les flux élémentaires MPEG-4 [RFC3640] (qui est étendue par le présent mémoire) et dans tout profil RTP applicable. Les principales considérations sur la sécurité pour le paquet RTP portant le format de charge utile RTP défini dans ce mémoire sont la confidentialité, l'intégrité, et l'authenticité de la source. La confidentialité est réalisée pour le chiffrement de la charge utile RTP. L'intégrité des paquets RTP est réalisée par un mécanisme convenable de protection cryptographique de l'intégrité. Un tel système cryptographique peut aussi permettre l'authentification de la source de la charge utile. Un mécanisme de sécurité convenable pour ce format de charge utile RTP devrait fournir une confidentialité, protection de l'intégrité, et authentification de la source capables au moins de déterminer si un paquet RTP provient d'un membre de la session RTP.

Le codec audio AAC inclut un mécanisme d'extension pour transmettre des données supplémentaires dans un flux qui est sauté en douceur par les décodeurs qui ne prennent pas en charge ces données supplémentaires. Ce canal caché peut être utilisé pour transmettre des données non autorisées dans un flux autrement valide.

Noter que le mécanisme approprié pour fournir la sécurité à RTP et aux charges utiles qui respectent le présent mémoire peut varier. Il dépend de l'application, du transport, et du protocole de signalisation employé. Donc, un seul mécanisme n'est pas suffisant ; cependant, si il convient, l'usage du protocole de transport sûr en temps réel (SRTP, Secure Real-time Transport Protocol) [RFC3711] est recommandé. D'autres mécanismes qui peuvent être utilisés sont IPsec [RFC4301] la sécurité de la couche transport (TLS, Transport Layer Security) [RFC5246] (RTP sur TCP) ; d'autres solutions peuvent exister.

 	7.	Références
 	7.1	Références normatives

[14496-1]	Norme Internationale ISO/CEI 14496-1, "Technologie de l'information - Codage des objets audio-visuels – Partie 1 : systèmes", Organisation internationale de normalisation (ISO), 2004.

[14496-3]	Norme Internationale ISO/CEI 14496-3, "Technologie de l'information - Codage des objets audio-visuels – Partie 3 : audio", Organisation internationale de normalisation (ISO), 2009.

[23003-1]	Norme Internationale ISO/CEI 23003-1,"MPEG en son environnant (MPEG D)", Organisation internationale de normalisation (ISO), 2007.

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

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

[RFC3640]	J. van der Meer et autres, "Format de charge utile RTP pour le transport de flux élémentaires MPEG-4", novembre  2003. (P.S., MàJ par RFC5691)

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

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

 	7.2	Références pour information

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

[RFC4301]	S. Kent et K. Seo, "Architecture de sécurité pour le protocole Internet", DOI 10.17487/RFC4301, décembre 2005. (P.S.) (Remplace la RFC2401)

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

 	Adresse des auteurs

Frans de Bont	Stefan Doehla	
Philips Electronics	Fraunhofer IIS	
High Tech Campus 5	Am Wolfmantel 33	
5656 AE Eindhoven,	91058 Erlangen,	
NL	DE	
mél : frans.de.bont@philips.com	mél : stefan.doehla@iis.fraunhofer.de	

Malte Schmidt	Ralph Sperschneider	
Dolby Laboratories	Fraunhofer IIS	
Deutschherrnstr. 15-19	Am Wolfmantel 33	
90537 Nuernberg,	91058 Erlangen,	
DE	DE	
mél : malte.schmidt@dolby.com	mél : ralph.sperschneider@iis.fraunhofer.de