Groupe de travail Réseau	C. Huitema, Microsoft	
Request for Comments : 3605	octobre 2003	
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle	

Attribut Protocole de contrôle en temps réel (RTCP) dans le protocole de description de session (SDP)

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 (2006).

Résumé
Le protocole de description de session (SDP, Session Description Protocol) est utilisé pour décrire les paramètres des flux de supports utilisés dans les sessions multimédia. Quand une session exige plusieurs accès, SDP suppose que ces accès ont des numéros consécutifs. Cependant, lorsque la session traverse un appareil de traduction d'adresse réseau qui utilise aussi la transposition d'accès, l'ordre des accès peut être détruit par la traduction. Pour traiter cela, on propose un attribut d'extension à SDP.
Table des matières
1. Introduction	1
2. Description de la solution	2
2.1 Attribut RTCP	2
3. Discussion de la solution	2
3.1 Comment découvre t-on les numéros d'accès  ?	3
3.2 A t-on besoin de prendre en charge plusieurs accès ?	3
3.3 Pourquoi ne pas étendre la définition de support ?	3
4. Considérations d'UNSAF	3
5. Considérations sur la sécurité	4
6. Considérations relatives à l'IANA	4
7. Propriété intellectuelle	4
8. Remerciements	4
9. Références	5
9.1 Références normatives	5
9.2 Références pour information	5
10. Adresse de l'auteur	5
11. Déclaration complète de droits de reproduction	5

 	1.	Introduction

Le protocole d'initialisation de session (SIP, Session Initiation Protocol) [RFC3261] est souvent utilisé pour établir des sessions multimédia sur l'Internet. Il est fréquent aujourd'hui qu'une des extrémités de la connexion ou les deux soient cachées derrière un appareil de traduction d'adresse réseau (NAT, Network Address Translator) [RFC2766]. Dans ce cas, le texte SDP doit documenter les adresses IP et les accès UDP comme ils apparaissent du côté "Internet public" du NAT.  Dans le présent mémoire, on suppose que l'hôte situé derrière un NAT a un moyen d'obtenir ces numéros. Une façon possible d'apprendre ces numéros est brièvement mentionnée à la Section 3, cependant, juste apprendre les numéros n'est pas suffisant.

Les messages SIP utilisent le codage défini dans SDP [RFC2327] pour décrire les adresses IP et les accès TCP ou UDP utilisés par les divers supports. L'audio et la vidéo sont normalement envoyés en utilisant RTP [RFC3550], qui exige deux accès UDP, un pour le support et un pour le protocole de contrôle (RTCP). SDP porte seulement un numéro d'accès par support, et déclare que les "autres accès utilisés par l'application (comme l'accès RTCP) devraient être déduits par un algorithme de l'accès de support de base." Les numéros d'accès RTCP étaient nécessairement déduits de l'accès du support de base dans les plus anciennes versions de RTP (comme la [RFC1889]) mais maintenant que cette restriction a été levée, il est besoin de spécifier explicitement les accès RTCP dans SDP. Noter cependant, que les mises en œuvre de RTP qui adhèrent à l'ancienne spécification [RFC1889] peuvent n'être pas capables d'utiliser les attributs SDP spécifiés dans le présent document.

Quand l'appareil de NAT effectue la transposition d'accès, il n'est pas garanti que les transpositions de deux accès séparés reflètent le séquençage et la parité des numéros d'accès d'origine ; en fait, quand le NAT gère un réservoir d'adresses IP, il est même possible que les accès RTP et RTCP soient transposés à des adresses différentes. Afin de réussir à établir des connexions en dépit du mauvais ordre des numéros d'accès et des possibles changements de parité causés par le NAT, on propose d'utiliser un attribut SDP spécifique pour documenter l'accès RTCP et facultativement l'adresse RTCP.

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.	Description de la solution

La partie principale de cette solution est la déclaration d'un attribut SDP pour documenter l'accès utilisé par RTCP.

 	2.1	Attribut RTCP
L'attribut RTCP sert à documenter l'accès RTCP utilisé pour le flux de supports, quand cet accès n'est pas le prochain plus haut numéro (impair) d'accès qui suit l'accès RTP décrit dans la ligne "media". L'attribut RTCP est un attribut de "valeur", et suit la syntaxe générale spécifié à la page 18 de la [RFC2327]: "a=<attribut>:<valeur>". Pour l'attribut RTCP :
*  le nom est la chaîne ascii "rtcp" (en minuscules),
*  la valeur est le numéro d'accès RTCP et une adresse facultative.

La description formelle de l'attribut est définie par la syntaxe ABNF [RFC2234] suivante :

rtcp-attribute = "a=rtcp:" accès [type-de-réseau espace type-d'adresse espace adresse-de-connexion] CRLF

Dans cette description, les jetons "accès", "type-de-réseau", "type-d'adresse" et "adresse-de-connexion" sont définis comme spécifié dans l'Appendice A Grammaire SDP de la [RFC2327].

Des exemples de codages sont :

m=audio 49170 RTP/AVP 0
a=rtcp:53020

m=audio 49170 RTP/AVP 0
a=rtcp:53020 IN IP4 126.16.64.4

m=audio 49170 RTP/AVP 0
a=rtcp:53020 IN IP6 2001:2345:6789:ABCD:EF01:2345:6789:ABCD

L'attribut RTCP PEUT être utilisé comme attribut de niveau support ; il NE DOIT PAS être utilisé comme attribut de niveau session. Bien que les exemples ci-dessus se rapportent à une méthode qui va retourner seulement des adresses d'envoi individuel, les valeurs d'envoi individuel et de diffusion groupée sont toutes deux valides.

 	3.	Discussion de la solution

La mise en œuvre de la solution est directe. Les questions qui se sont le plus souvent posées concernant cette solution sont sur son utilité, c'est-à-dire, si un hôte peut réellement découvrir les numéros d'accès dans un NAT non modifié, si elle est suffisante, c'est-à-dire, si il est ou non besoin de documenter plus d'un accès auxiliaire par type de support, et si il ne vaudrait pas mieux changer la définition du support plutôt que d'ajouter un nouvel attribut.

 	3.1	Comment découvre t-on les numéros d'accès  ?
La solution proposée n'est utilisée que si l'hôte peut découvrir les "numéros d'accès traduits", c'est-à-dire, la valeur des accès comme ils apparaissent sur le "côté externe" du NAT. Une possibilité est de demander la coopération d'un tiers bien connecté qui va agir comme serveur conformément à STUN [RFC3489]. On obtient donc un processus en quatre étapes :
1 - l'hôte alloue deux numéros d'accès UDP pour une paire RTP/RTCP,
2 - l'hôte envoie un message UDP à partir de chaque accès au serveur,
3 – le serveur STUN lit l'adresse et l'accès de source du paquet, et les copie dans le texte d'une réponse,
4 - l'hôte analyse la réponse selon le protocole STUN et apprend l'adresse et l'accès externes correspondant à chacun des deux accès UDP.

Cet algorithme suppose que le NAT va utiliser la même traduction pour les paquets envoyés au tiers et à "l'homologue SDP" avec lequel l'hôte veut établir la connexion. Il n'est pas garanti que tous les boîtiers de NAT déployés dans l'Internet aient cette caractéristique. Les mises en œuvre se référeront à la spécification de STUN [RFC3489] pour une discussion approfondie des divers types de NAT.

 	3.2	A t-on besoin de prendre en charge plusieurs accès ?
La plupart des flux de supports sont transmis en utilisant une seule paire d'accès RTP et RTCP. Il est possible, cependant, de transmettre un seul support sur plusieurs flux RTP, par exemple en utilisant un codage hiérarchique. Dans ce cas, SDP va coder le numéro d'accès utilisé par RTP sur le premier flux, et le nombre de flux, comme dans :

m=video 49170/2 RTP/AVP 31

Dans cet exemple, le support est envoyé sur deux paires consécutives d'accès, correspondant respectivement à RTP pour le premier flux (numéro pair, 49170), RTCP pour le premier flux (numéro impair, 49171), RTP pour le second flux (numéro pair, 49172), et RTCP pour le second flux (numéro impair, 49173).

En théorie, il serait possible de modifier SDP et documenter les nombreux accès correspondants aux différentes couches de codage. Cependant, les codages en couches ne sont pas très utilisés en pratique, et quand ils sont utilisés c'est principalement en liaison avec la transmission en diffusion groupée. Les questions de traduction documentées dans le présent mémoire s'appliquent uniquement à la transmission en envoi individuel, et il n'y a donc pas de besoin à court terme pour la prise en charge de plusieurs descriptions d'accès. Il est plus pratique et plus robuste de se concentrer sur le cas simple dans lequel un support est envoyé sur exactement un flux RTP/RTCP.

 	3.3	Pourquoi ne pas étendre la définition de support ?
Les accès RTP sont documentés dans la ligne de description du support, et il semble plus pratique de documenter l'accès RTCP au même endroit, plutôt que de créer un attribut RTCP. On a examiné cette autre conception et elle a été rejetée pour deux raisons : ajouter un numéro d'accès supplémentaire et une adresse d'option dans la description du support serait étrange, et plus important, cela créerait des problèmes avec les applications existantes, qui devraient rejeter la description de support entière si elles ne comprennent pas l'extension. Au contraire, ajouter un attribut a un mode d'échec bien défini : les mises en œuvre qui ne comprennent pas l'attribut "a=rtcp" vont simplement l'ignorer ; elles vont échouer à envoyer des paquets RTCP à l'adresse spécifiée, mais elles vont au moins être capables de recevoir le support dans les paquets RTP.

 	4.	Considérations d'UNSAF

L'attribut RTCP dans SDP est utilisé pour permettre l'établissement de flux RTP/RTCP à travers un NAT. Ce mécanisme peut être utilisé en conjonction avec un mécanisme de découverte d'adresse comme STUN [RFC3489]. STUN est une réparation de court terme au problème de la traversée de NAT, qui exige donc la considération des problèmes généraux liés à "l'auto correction d'adressage unilatérale" (UNSAF, Unilateral Self Address Fixing) [RFC3424].

L'attribut RTCP s'adresse à un problème très spécifique, la documentation des numéros d'accès comme ils apparaissent après la traduction d'adresse par un NAT qui transpose les accès. L'attribut RTCP NE DEVRAIT PAS être utilisé pour d'autres applications.

On s'attend à ce que, avec du temps, une ou deux stratégies de sortie puissent être développées. L'IETF peut développer un protocole explicite de "contrôle de boîtier de médiation" qui va permettre aux applications d'obtenir une paire de numéros d'accès appropriée pour RTP et RTCP. Une autre possibilité est le déploiement de IPv6, qui va permettre d'utiliser un adressage "de bout en bout" et garantir que les deux hôtes seront capables d'utiliser les accès appropriés. Dans les deux cas, il ne sera pas besoin de documenter un accès RTCP "non standard" avec l'attribut RTCP.

 	5.	Considérations sur la sécurité

Cette extension à SDP ne semble pas introduire de risque significatif pour la sécurité des applications multimédia. On peut concevoir qu'un tiers malveillant utilise l'extension pour rediriger la fraction RTCP d'un échange RTP, mais cela exige d'intercepter et réécrire le paquet de signalisation qui porte le texte SDP ; si un intercepteur peut faire cela, beaucoup plus d'attaques sont disponibles, incluant un changement complet des adresses et numéros d'accès auxquels le support va être envoyé.

Afin d'éviter des attaques de cette sorte, quand SDP est utilisé dans un paquet de signalisation où il est de la forme application/sdp, l'intégrité de bout en bout en utilisant S/MIME [RFC3369] est la méthode technique à mette en œuvre et appliquer. Ceci est compatible avec SIP [RFC3261].

 	6.	Considérations relatives à l'IANA

Le présent document définit un nouveau paramètre SDP, le champ d'attribut "rtcp", qui selon la [RFC2327] a été enregistré par l'IANA. Ce champ d'attribut est conçu pour être seulement utilisé au niveau du support.

 	7.	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 pourraient ê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 le 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.

 	8.	Remerciements

L'idée originale d'utiliser l'attribut "rtcp" a été développée par Ann Demirtjis. Le document a été revu par les groupes de travail MMUSIC et AVT de l'IETF.

 	9.	Références
 	9.1	Références normatives

[RFC1889]	H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson, "RTP : protocole de transport pour applications en temps réel", janvier 1996. (Obsolète, voir RFC3550 STD64) 

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

[RFC2234]	D. Crocker et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", novembre 1997. (Obsolète, voir RFC5234)

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

[RFC3489]	J. Rosenberg et autres, "STUN - Simple traversée par le protocole de datagramme d'utilisateur (UDP) des traducteurs d'adresse réseau (NAT)", mars 2003. (Obsolète, voir RFC5389) (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)

 	9.2	Références pour information

[RFC2766]	G. Tsirtsis, P. Srisuresh, "Traduction d'adresse réseau – traduction de protocole (NAT-PT)", février 2000. (Obsolète, voir RFC4966) (MàJ par RFC3152) (Historique)

[RFC3261]	J. Rosenberg et autres, "SIP : Protocole d'initialisation de session", juin 2002. (Mise à jour par 3265, 3853, 4320, 4916, 5393, 6665, 8217, 8760)

[RFC3369]	R. Housley, "Syntaxe de message cryptographique (CMS)", août 2002. (Obsolète, voir RFC3852) (P.S.)

[RFC3424]	L. Daigle, éd., IAB, "Considérations de l'IAB sur l'auto correction d'adressage unilatérale (UNSAF) à travers la traduction d'adresse réseau", novembre 2002. (Information)

 	10.	Adresse de l'auteur

Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399

mél : huitema@microsoft.com 

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