Attribut Content du protocole de description de session (SDP)

Statut de ce mémo
Le présent document spécifie un protocole de normalisation Internet pour la communauté de l'Internet, qui appelle à la discussion et à des suggestions pour son amélioration. Prière de se reporter à l'édition en cours des "Normes de protocole officielles de l'Internet" (STD 1) sur l'état de la normalisation et le statut de ce protocole. La distribution du présent mémo n'est soumise à aucune restriction.

Notice de Copyright
Copyright (C) The IETF Trust (2007).

Résumé
Le présent document définit un nouvel attribut de niveau support du protocole de description de session (SDP), 'content'. L’attribut 'content' définit le contenu du flux du support à un niveau plus détaillé que la ligne de description du support. L’expéditeur d’une description de session SDP peut accrocher l’attribut 'content' à un ou plusieurs des flux de support. L’application receveuse peut alors traiter différemment chaque flux de support (par exemple l’afficher un grand ou un petit écran) sur la base de son contenu.

1 Introduction

Le protocole de description de session (SDP, Session Description Protocol) [1] est un protocole destiné à décrire des sessions multimédia pour les besoins des annonces de session, d’invitation à une session, et autres formes d’initiation de sessions multimédia. Un des cas d’utilisation les plus typiques de SDP est celui où il est utilisé avec le protocole d’initialisation de session (SIP, Session Initiation Protocol) [5].

Il y a des situations où une application reçoit plusieurs flux de support similaires, qui sont décrits dans une description de session SDP. Les flux de support peuvent être similaires dans le sens où leur contenu ne peut être distingué simplement par l’examen de leurs lignes de description de support (par exemple, deux flux vidéo). L’attribut 'content' est nécessaire de façon que l’application qui reçoit puisse traiter chaque flux de support de façon appropriée sur la base de son contenu.

La présente spécification définit l’attribut SDP 'content' de niveau support, qui donne plus d’informations sur le flux de support que la ligne 'm' d’une description de session SDP.

Le principal objet de la présente spécification est de permettre aux applications de prendre des actions automatisées sur la base des attributs 'content'. Cependant, la présente spécification ne définit pas ces actions. Par conséquent, deux mises en œuvre peuvent se comporter de façon complètement différente lorsqu’elles reçoivent le même attribut 'content'.

2 Terminologie

Dans le présent document, les mots clé "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans le BCP 14 [RFC2119], et indiquent des niveaux d’exigence pour les mises en œuvre conformes.

3 Techniques concernées

L’attribut 'label' [10] permet à l’expéditeur d’attacher un pointeur à un flux de support particulier. L’espace de nom de l’attribut 'label' lui-même n’est pas soumis à restrictions ; aussi, en principe, il pourrait également être utilisé pour transporter des informations sur le contenu d’un flux de support. Cependant, en pratique, cela n’est pas possible à cause du besoin de rétro compatibilité. Les mises en œuvre existantes de l’attribut 'label' utilisent déjà des valeurs tirées de cet espace de nom non limité d’une façon spécifique de l’application. Aussi, il n’est pas possible de réserver des portions de l’espace de nom de l’attribut 'label' sans d’éventuels conflits avec les étiquettes spécifiques d’applications déjà utilisées.

Il est possible d’allouer une sémantique à un flux de support avec un document externe qui utilise l’attribut 'label' comme un pointeur. L’inconvénient de cette approche est que cela exige un document externe. Donc, ce type de mécanisme n’est applicable qu’à des cas particuliers où sont utilisés de tels documents externes (par exemple, une conférence centralisée).

Une autre façon d’attacher une sémantique à un flux de support est d’utiliser l’attribut 'i' de SDP, défini en [1]. Cependant, les valeurs de l’attribut 'i' sont destinées aux utilisateurs humains et non aux automates.

4 Motifs du nouvel attribut Content

Actuellement, SDP ne fournit aucun moyen pour décrire le contenu d’un flux de support (par exemple, l’image du commentateur, des transparents, le langage des signes) sous une forme que l’application puisse comprendre. Bien sûr, l’utilisateur final peut voir le contenu du flux de support et lire son titre, mais l’application ne peut pas comprendre ce que contient le flux du support.

L’application qui reçoit plusieurs flux de support similaires (par exemple, de même type et format) a besoin, dans certains cas, de savoir ce que sont les contenus de ces flux. Cette sorte de situation survient, par exemple, dans des cas où les transparents de présentation, l’image du commentateur, et le langage des signes, sont transportés dans des flux de support séparés. Il serait souhaitable que l’application receveuse puisse les distinguer d’une façon qui lui permette de les traiter automatiquement de façon appropriée.

Figure 1 : Écran d’application

La Figure 1 montre un écran d’une application de communication typique. L’attribut 'content' rend possible que l’application décide où montrer chaque flux de support. Du point de vue d’un utilisateur final, il est souhaitable que l’usager n’ait pas besoin d’arranger chaque flux de support chaque fois que débute une nouvelle session de support.

L’attribut 'content' pourrait aussi être utilisé dans des situations plus complexes. Une application qui commande des équipements dans un auditorium est un exemple d’une telle situation. Un auditorium peut avoir de nombreux canaux de sortie différents pour la vidéo (par exemple, l’écran principal et deux écrans plus petits) et pour l’audio (par exemple, les hauts parleurs principaux et des casques auditifs pour les participants). Dans ce type d’environnement, il est nécessaire d’avoir beaucoup d’interactions avec l’utilisateur final qui fait fonctionner l’application en l’absence de signaux provenant d’une application de contrôle. L’attribut 'content' rendrait possible, par exemple, qu’un utilisateur final spécifie une seule fois, quelle sortie devrait utiliser chaque flux de support d’une session donnée. L’application pourrait appliquer automatiquement la même disposition des supports pour les sessions suivantes. Ainsi, l’attribut 'content' peut aider à réduire considérablement la quantité d’interactions nécessaires pour l’utilisateur final.

5 L’attribut Content

La présente spécification définit un nouvel attribut de valeur de niveau support, 'content'. Son format en SDP est décrit par l’ABNF (Augmented Backus-Naur Form) [2] suivant :

content-attribute = "a=content:" mediacnt-tag
mediacnt-tag = mediacnt *("," mediacnt)
mediacnt = "slides" / "speaker" / "sl" / "main" / "alt" / mediacnt-ext
mediacnt-ext = token

L’attribut 'content' contient un ou plusieurs jetons, qui PEUVENT être attachés à un flux de support par une application d’envoi. Une application PEUT attacher un attribut 'content' à tout flux de support qu’elle décrit.

Le présent document donne un ensemble de valeurs prédéfinies pour l’attribut 'content'. D’autres valeurs pourront être définies à l’avenir. Les valeurs prédéfinies sont :

slides : le flux de support comporte des transparents de présentation. Le type de support peut être, par exemple, un flux de vidéo ou un certain nombre de messages instantanés avec des images. Un cas d’utilisation typique est celui de séminaires et cours en ligne. Ceci est similaire au rôle 'présentation' dans la Recommandation UIT-T H.239 [12].

speaker : le flux de support contient l’image du commentateur. Le support peut être, par exemple, un flux vidéo ou une image fixe. Un cas d’utilisation typique est celui de séminaires et cours en ligne.

sl : le flux de support contient du langage par signes. Un cas d’utilisation typique de cela est un flux audio qui est traduit en langage des signes, et qui est envoyé sur un flux vidéo.

main : le flux de support est tiré de la source principale. Un cas typique de cette utilisation est un concert où la caméra vise l’artiste.

alt : le flux de support est tiré d’une source annexe. Un cas typique de cette utilisation est un événement où le son ambiant est séparé de la source sonore principale. Le flux audio annexe pourrait être, par exemple, le bruit d’une jungle. Un autre exemple est la vidéo d’une salle de conférence, alors que le flux principal porte la vidéo de l’orateur. Ceci est similaire au rôle 'live' (en direct) dans la Recommandation UIT-T H.239.

Toutes des valeurs peuvent être utilisées avec tout type de support. On a choisi de ne pas restreindre chaque valeur à un ensemble particulier de types de support afin de ne pas empêcher les applications d’utiliser des combinaisons innovantes d’une valeur donnée avec différents types de supports.

L’application peut prendre des décisions sur la façon de traiter un seul flux de support sur la base à la fois du type de support et de la valeur de l’attribut 'content'. Si l’application ne met pas en œuvre de logique particulière pour le traitement d’une combinaison d’un type de support donné et d’une valeur de 'content', elle applique le traitement par défaut de l’application pour le type de support.

Noter que la même valeur d’attribut 'content' peut survenir plus d’une fois dans une seule description de session.

6 L’attribut Content dans le modèle d’offre/réponse

La présente spécification ne définit pas de moyen pour découvrir si le point d’extrémité homologue comprend l’attribut 'content' parce que les valeurs de 'content' sont seulement informatives au niveau du modèle offre/réponse [8]. Le fait que le point d’extrémité homologue ne comprenne pas l’attribut 'content' n’empêche pas l’établissement de la session du support. La seule conséquence est que l’interaction de l’utilisateur final du côté réception peut être obligée de diriger de façon appropriée les flux de support individuels.

L’attribut 'content' décrit les données que l’application qui génère la description de session SDP entend envoyer sur un flux de support particulier. Les valeurs de 'content' pour les deux directions d’un flux de support n’ont pas besoin d’être les mêmes. Donc, une réponse SDP PEUT contenir des attributs 'content' même si aucun d’eux n’était présent dans l’offre. De même, la réponse PEUT ne contenir aucun attribut 'content' même si il en était présent dans l’offre. De plus, il n’est pas nécessaire que les valeurs des attributs 'content' correspondent à une offre et une réponse.

L’attribut 'content' peut aussi être utilisé dans des scénarios où SDP est utilisé en style déclaratif. Par exemple, les attributs 'content' peuvent être utilisés dans des descripteurs de session SDP qui sont distribués avec le protocole d’annonce de session (SAP, Session Announcement Protocol) [9].

7 Exemples

Il y a deux exemples dans cette section. Le premier exemple, ci-dessous, utilise une seule valeur d’attribut 'content' par flux de support :

v=0
o=Alice 292742730 29277831 IN IP4 131.163.72.4
s=Seconde conférence sur les technologies de l’information
c=IN IP4 131.164.74.2
t=0 0
m=video 52886 RTP/AVP 31
a=rtpmap:31 H261/9000
a=content:slides
m=video 53334 RTP/AVP 31
a=rtpmap:31 H261/9000
a=content:speaker
m=video 54132 RTP/AVP 31
a=rtpmap:31 H261/9000
a=content:sl

Le second exemple, ci-dessous, est un cas où il y a plus d’une valeur d’attribut 'content' par flux de support. La différence avec l’exemple précédent est que maintenant le système de conférence peut mixer automatiquement les flux de vidéo provenant du présentateur et les transparents :

v=0
o=Alice 292742730 29277831 IN IP4 131.163.72.4
s=Seconde conférence sur les technologies de l’information
c=IN IP4 131.164.74.2
t=0 0
m=video 52886 RTP/AVP 31
a=rtpmap:31 H261/9000
a=content:slides,speaker
m=video 54132 RTP/AVP 31
a=rtpmap:31 H261/9000
a=content:sl

8 Fonctionnement avec SMIL

Les valeurs de l’attribut 'content', définies à la Section 5, peuvent aussi être utilisées avec le langage synchronisé d’intégration multimédia (SMIL, Synchronized Multimedia Integration Language) [11]. SMIL contient un élément 'param', qui est utilisé pour décrire le contenu d’un flux de support. Cependant, cet élément 'param', comme l’attribut 'content', fournit une description spécifique d’application du contenu du support.

Les détails de l’utilisation des valeurs de l’attribut 'content' avec l’élément 'param' de SMIL sortent du domaine d’application de la présente spécification.

9 Considérations sur la sécurité

Un attaquant peut tenter d’ajouter, modifier, ou retirer les attributs 'content' d’une description de session. Selon la façon dont une mise en œuvre choisit de réagir à la présence ou l’absence d’un attribut 'content' donné, il peut en résulter un comportement indésirable de l’application ; il est donc fortement RECOMMANDÉ qu’une protection d’intégrité soit appliquée aux descriptions de session SDP.

La protection d’intégrité d’une description de session portée dans SIP [5], peut être fournie en utilisant par exemple S/MIME [6] ou la sécurité de couche transport (TLS, Transport Layer Security) [7].

On suppose que les valeurs de l’attribut 'content' ne contiennent pas de données qui seraient vraiment dommageables si elles étaient exposées à un attaquant éventuel. Il vaut de noter que l’ensemble initial de valeurs ne contient aucune donnée qui exigerait la protection de la confidentialité. Cependant, S/MIME et TLS peuvent être utilisés pour protéger la confidentialité, en cas de besoin.

10 Considérations relatives à l’IANA

Le présent document définit un nouvel attribut 'content' pour SDP. Il définit aussi pour lui un ensemble de valeurs initiales. Des informations générales concernant l’attribut 'content' se présentent comme suit :

Nom du contact : Jani Hautakorpi <Jani.Hautakorpi@ericsson.com>.
Nom de l’attribut : 'content'.
Type d’attribut : Niveau support.
Soumis à l’ensemble de caractères : Non.
Objet de l’attribut : L’attribut 'content' donne des informations sur le contenu du flux de support à l’application qui le reçoit.
Valeurs d’attribut admises : "slides", "speaker", "sl", "main", "alt", et toute autre valeur enregistrée.

L’IANA a créé un sous-registre pour les valeurs de l’attribut 'content' au sein du registre des paramètres du protocole de description de session (SDP). Les valeurs initiales pour le sous-registre sont les suivantes :

Selon la terminologie de la RFC 2434 [4], la politique d’enregistrement des nouvelles valeurs du paramètre 'content' doit être 'Spécification exigée'.

Si de nouvelles valeurs de l’attribut 'content' sont spécifiées à l’avenir, elles devraient consister en une méta-description des contenus d’un flux de support. De nouvelles valeurs des attributs 'content' ne devraient pas décrire de choses du genre de ce qu’il convient de faire pour traiter un flux.

11 Remerciements

Les auteurs souhaitent remercier Arnoud van Wijk et Roni Even, qui ont fourni des idées précieuses pour ce document. Nous remercions aussi Tom Taylor pour sa relecture méticuleuse.

12 Références

12.1 Références normatives

[1] Handley, M., Jacobson, V., et C. Perkins, "SDP : Protocole de description de session", RFC 4566, juillet 2006.

[2] Crocker, D., Ed. et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", RFC 4234, octobre 2005.

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

[4] Narten, T. et H. Alvestrand, "Lignes directrices pour écrire la section Considérations relatives à l’IANA dans les RFC", BCP 26, RFC 2434, octobre 1998.

12.2 Références informatives

[5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., et E. Schooler, "SIP : Protocole d’initialisation de session", RFC 3261, juin 2002.

[6] Ramsdell, B., " E xtensions multi-usage de messagerie Internet sécurisée (S/MIME) Version 3.1 : Spécification de message", RFC 3851, juillet 2004.

[7] Dierks, T. et E. Rescorla, "Protocole de sécurité de la couche Transport (TLS) Version 1.1", RFC 4346, avril 2006.

[8] Rosenberg, J. et H. Schulzrinne, "Modèle d’offre/réponse avec le protocole de description de session (SDP)", RFC 3264, juin 2002.

[9] Handley, M., Perkins, C., et E. Whelan, "Protocole d’annonce de session", RFC 2974, octobre 2000.

[10] Levin, O. et G. Camarillo, "L’attribut Label du protocole de description de session (SDP)", RFC 4574, août 2006.

[11] Michel, T. et J. Ayars, "Langage synchronisé d’intégration multimédia (SMIL 2.0) - [Deuxième édition]", Recommandation REC-SMIL2-20050107 du World Wide Web Consortium, janvier 2005, <http://www.w3.org/TR/2005/REC-SMIL2-20050107>.

[12] Recommandation UIT-T H.329 "Infrastructure des services audiovisuels – Aspects système ; Gestion par rôle et canaux de support supplémentaires pour les terminaux de la série H.300", juillet 2003.

Adresse des auteurs

Déclaration de copyright

Copyright (C) The Internet 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 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.

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 Administrative Support Activity (IASA) de l'IETF.