Network Working Group F

RFC3407 Déclaration de capacité de SDP Andreasen

Groupe de travail Réseau	F. Andreasen, Cisco Systems
Request for Comments : 3407
Catégorie : En cours de normalisation
Traduction Claude Brière de L’Isle	octobre 2002

Déclaration simple de capacité du protocole de description de session (SDP)

Statut de ce mémoire

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître 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

Résumé

Le présent document définit un ensemble d’attributs du protocole de description de session (SDP, Session Description Protocol) qui permettent à SDP de fournir un mécanisme de déclaration de capacités minimal et rétro compatible. De telles déclarations de capacités peuvent être utilisées comme entrées dans une négociation de session ultérieure, ce qui est fait par des moyens qui sortent du domaine d’application du présent document. Cela donne une solution simple et limitée au problème général de la négociation de capacités qui sera traité par la prochaine génération de SDP, aussi appelé SDPng.

1. Terminologie

Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMETE", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans le BCP 14, [RFC2119].

2. Introduction

Le protocole de description de session (SDP, Session Description Protocol) [RFC2327] décrit des sessions multimédia pour les besoins de l’annonce de session, de l’invitation à une session, et d’autres formes d’initiation de session multimédia. SDP n’était pas destiné à fournir une négociation de capacités. Cependant, comme ce besoin a pris une importance croissante, des travaux ont commencé sur un "SDP de nouvelle génération" (SDPng) [RFCxxxx], [RFC5939] qui prend en charge à la fois la description de session et la négociation de capacité. Il n’est pas prévu que SDPng soit rétro compatible avec SDP et les travaux sur SDPng sont actuellement dans les premières phases. Cependant, plusieurs autres protocoles, par exemple, SIP [RFC2543] et le protocole de commande de passerelle de support (MGCP, Media Gateway Control Protocol) [RFC2705], utilisent SDP et vont vraisemblablement continuer de le faire dans le proche avenir. Néanmoins, dans de nombreux cas, ces protocoles de signalisation ont un besoin urgent d’une forme limitée de négociation de capacité.

Par exemple, un point d’extrémité peut prendre en charge l’audio de la Recommandation UIT-T G.711 (sur RTP) ainsi que le relais de télécopie de la Recommandation UIT-T T.38 (sur UDP ou TCP). Sauf si le point d’extrémité veut prendre en charge les deux supports de flux en même temps, cela ne peut pas être actuellement exprimé dans SDP. Un autre exemple implique la prise en charge de plusieurs codecs. Un point d’extrémité indique cela en incluant tous les codecs dans la ligne "m=" de la description de session. Cependant, le point d’extrémité s’engage également par là à prendre en charge simultanément chacun de ces codecs. En pratique, les limitations de mémoire et de puissance de traitement du processeur de signal numérique (DSP, Digital Signal Processor) peuvent ne pas rendre cela faisable.

Comme noté dans la [RFCxxx], le problème avec SDP est que les descriptions de supports sont utilisées pour décrire les paramètres de session aussi bien que les capacités sans une claire distinction entre les deux.

Dans le présent document, on définit une caractéristique minimale et rétro compatible de déclaration de capacité dans SDP en définissant un ensemble de nouveeaux attributs SDP. Ensemble, ces attributs définissent un ensemble de capacités, qui consiste en un numéro de séquence d’ensemble de capacités suivi par une ou plusieurs descriptions de capacité. Chaque description de capacité dans l’ensemble contient des informations sur les formats de supports pris en charge, mais le point d’extrémité ne s’engage pas à utiliser l’un d’entre eux. Afin d’utiliser réellement une capacité déclarée, la négociation de session devra être faite par des moyens qui sortent du domaine d’application du présent document, par exemple, en utilisant le modèle d’offre/aréponse de la [RFC3264].

On devrait noter que le mécanisme n’est pas destiné à résoudre le problème général de la négociation de capacité visé par SDPng. Il est simplement destiné à être une solution simple et limitée aux problèmes les plus urgents qui se posent aux utilisateurs actuels de SDP.

3. Attributs de déclaration de simple capacité

La déclaration SDP de simple capacité (simcap) est définie par un ensemble d’attributs SDP. Ensemble, ces attributs forment un ensemble de capacités qui décrit les capacités de support complètes du point d’extrémité. Tout ensemble de capacités précédent produit par le point d’extrémité pour la session en question ne s’applique plus. L’ensemble de capacités consiste en un numéro de séquence et en une ou plusieurs descriptions de capacité. Chacune de ces descriptions de capacité décrit le type de support et les formats de support pris en charge et peut inclure un ou plusieurs paramètres de capacité pour mieux définir la capacité. Une description de session NE DOIT PAS contenir plus d’un ensemble de capacités, cependant, l’ensemble de capacités peut décrire des capacités à la fois au niveau session et au niveau support. Les descriptions de capacités fournies au niveau session s’appliquent à tous les flux du support du type de support indiqué, tandis que les descriptions de capacités fournies au niveau du support s’appliquent seulement à ce flux de support particulier. On se réfère à eux respectivement sous les noms de capacités de session et de capacités de flux de support. Une capacité de flux de support peut ou non être du même type de support que le flux de support auquel elle s’applique.

L’ensemble de capacités DOIT commencer par un seul numéro de séquence suivi par une ou plusieurs descriptions de capacité énumérant tous les formats de supports que le point d’extrémité est actuellement capable et désireux de prendre en charger. Plus précisément, si un format de support est inclus dans une ligne de support ("m="), alors par définition le format de support DOIT être inclus soit dans une capacité de session, soit dans une capacité de flux de support pour cette ligne de support. Le point d’extrémité PEUT inclure des formats de supports supplémentaires dans une capacité si il est capable de prendre en charge des formats de supports dans une session avec son homologue. Un point d’extrémité NE DOIT PAS inclure des capacités dont il sait qu’il ne peut pas les utiliser dans une certaine session. Un point d’extrémité qui reçoit un ensemble de capacités d’un autre point d’extrémité PEUT utiliser tout format de support qui est inclus dans cet ensemble de capacités dans une tentative ultérieure de négocier des flux de supports avec l’autre point d’extrémité, par exemple dans le modèle offre/réponse de la [RFC3264]. Si un nouvel ensemble de capacités est reçu de l’autre point d’extrémité, l’ancien ensemble de capacités NE DOIT PAS être utilisé. Les capacités de session peuvent être utilisées pour tout flux de support du type de supports indiqué, tandis que les capacités de flux de support ne peuvent être utilisées que pour leur ligne de support associée. Cependant, un point d’extrémité qui reçoit un ensemble de capacités avec un certain format de support NE DOIT PAS supposer que va réussir une tentative ultérieure de négocier un flux de support en utilisant juste ce format de support.

Les descriptions individuelles de capacités dans un ensemble de capacités peuvent être fournies de façon contiguë ou elles peuvent être dispersées dans la description de session. La première description de capacité DOIT cependant suivre immédiatement le numéro de séquence.

Le numéro de séquence est de la forme : a=sqn: <sqn-num>

où <sqn-num> est un entier entre 0 et 255 (tous deux inclus). Le numéro de séquence initial DOIT être 0 (zéro) et il DOIT être incrémenté de 1 modulo 256 avec chaque nouvel ensemble de capacités produit par le point d’extrémité. Les receveurs peuvent ne pas nécessairement voir tous les ensembles de capacités produits et donc NE DOIVENT PAS rejeter un ensemble de capacités à cause de trous dans les numéros de séquence. Le numéro de séquence DOIT être fourni comme attribut soit de niveau session soit de niveau support, Il NE DOIT cependant PAS y avoir plus d’une occurrence de l’attribut numéro de séquence dans la description de session (car il ne peut pas y avoir plus d’un ensemble de capacités).

Chaque description de capacité dans l’ensemble de capacités est de la forme :

a=cdsc: <cap-num> <support> <transport> <fmt list>

où <cap-num> est un entier entre 1 et 255 (tous deux inclus) utilisé pour numéroter les capacités, et <support>, <transport>, et <fmt list> sont définis comme dans la ligne SDP "m=". La description de capacité se réfère à une capacité d’envoi et de réception par défaut. Quand on génère un ensemble de capacités, le numéro de capacité DOIT commencer par 1 dans la première description de capacité, et être incrémenté du nombre de formats de supports figurant dans le <fmt list> pour chaque description de capacité suivante. Les formats de supports dans le <fmt list> sont numérotés de gauche à droite. Les receveurs d’un ensemble de capacités NE DOIVENT PAS cependant rejeter des descriptions de capacité à cause de trous dans les numéros de capacités. Le numéro de capacité donne un moyen pratique dans le contexte de l’ensemble de capacité (tel que référencé par le numéro de séquence) qui peut être utilisé pour faire référence à une capacité particulière par des moyens qui sortent du domaine d’application de la présente spécification.

Une description de capacité peut inclure une ou plusieurs lignes de paramètres de capacité de la forme :

a=cpar: <cap-par>

a=cparmin: <cap-par>

a=cparmax: <cap-par>

où <cap-par> sont soit les informations de bande passante ("b=") soit un attribut ("a=") dans sa forme '<type>=<valeur>' complète (voir la [RFC2327]). Une ligne de paramètre de capacité fournit des paramètres supplémentaires pour la ligne d’attribut "cdsc" précédante. Les lignes de paramètre de capacité pour une description de capacité DEVRAIENT suivre immédiatement la ligne "cdsc" à laquelle ils se réfèrent. Néanmoins, la description de capacité inclut toutes les lignes de paramètre de capacité jusqu’à la prochaine ligne de description de capacité ("cdsc") ou de support ("m=") dans la description de session.

L’attribut "cpar" devrait normalement être utilisé lorsque les valeurs de paramètre de capacité doivent être spécifiées. Lorsque il est fourni, il signifie que le point d’extrémité déclare qu’il prend en charge les formats de support dans la ligne "cdsc" précédente conformément à la valeur <cap-par> spécifiée. Cela peut, par exemple, être utilisé pour spécifier des paramètres "fmtp". Si une négociation de session est tentée sans prendre en compte la valeur <cap-par>, elle peut échouer par manque de soutien de la part du point d’extrémité. Une description de capacité peut contenir zéro, une, ou plusieurs lignes d’attribut "cpar" qui décrivent soit le même paramètre, soit des paramètres différents. Décrire le même paramètre plus d’une fois peut servir à spécifier des solutions de remplacement.

Lorsque on doit spécifier une valeur numérique minimum, l’attribut "cparmin" devrait être utilisé. Il peut y avoir zéro, une, ou plusieurs lignes d’attribut "cparmin" dans une description de capacité ; cependant un certain paramètre NE DOIT PAS être décrit plus d’une fois par un paramètre "cparmin".

Lorsque on doit spécifier une valeur numérique maximale, l’attribut "cparmax" devrait être utilisé. Il peut y avoir zéro, une, ou plusieurs lignes d’attribut "cparmax" dans une description de capacité ; cependant, un certain paramètre NE DOIT PAS être décrit plus d’une fois par un attribut "cparmax".

Des gammes de valeurs numériques peuvent être exprimées en utilisant un attribut "cparmin" et"cparmax" pour un certain paramètre. Il découle de la règle précédente qu’une seule gamme peut être spécifiée pour un certain paramètre.

Les descriptions de capacités peuvent être fournies aussi bien au niveau session qu’au niveau support. Une description de capacité fournie au niveau session s’applique à tous les flux de support du type de support indiqué dans la description de session. Une description de capacité fournie au niveau support ne s’applique qu’à ce flux de support particulier (sans considération du type de support). Si une description de capacité avec le type de support X est fournie au niveau session, et si il n’y a pas de flux de support du type X dans la description de session, il n’est alors pas défini à quels flux de support s’applique la description de capacité (sauf si il n’y a qu’un seul flux de support). Il est donc RECOMMANDÉ que de telles capacités soient fournies plutôt au niveau support.

On montre ci-dessous un exemple de description de session qui utilise le mécanisme de déclaration de simple capacité :

v=0

o=- 25678 753849 IN IP4 128.96.41.1

c=IN IP4 128.96.41.1

t=0 0

m=audio 3456 RTP/AVP 18 96

a=rtpmap:96 telephone-event/8000

a=fmtp:96 0-15,32-35

a=sqn: 0

a=cdsc: 1 audio RTP/AVP 0 18 96

a=cpar: a=fmtp:96 0-16,32-35

a=cdsc: 4 image udptl t38

a=cdsc: 5 image tcp t38

L’envoyeur de cette description de session est actuellement prêt à envoyer et recevoir de l’audio G.729 ainsi que des événements de téléphonie 0-15 et 32-35. L’envoyeur est de plus capable de prendre en charge :

* le codage MIC U pour le flux de support audio,

* les événements de téléphonie 0-16 et 32-35,

* le relais de télécopie T.38 en utilisant udp ou tcp (voir [T.38]).

Noter que le premier numéro de capacité spécifié est 1, tandis que le suivant est 4 car les trois formats de support étaient inclus dans la première description de capacité. Noter aussi que le rtpmap pour le type de charge utile 96 n’était pas inclus dans la description de capacité, car il était déjà spécifié pour la ligne de support ("m="). À l’inverse, il n’aurait bien sûr pas été valide de fournir le rtpmap dans la description de capacité et d’omettre ensuite la ligne "a=rtpmap".

On montre ci-dessous un autre exemple du mécanisme de déclaration simple de capacité, cette fois avec plusieurs flux de supports :

v=0

o=- 25678 753849 IN IP4 128.96.41.1

c=IN IP4 128.96.41.1

t=0 0

m=audio 3456 RTP/AVP 18

a=sqn: 0

a=cdsc: 1 audio RTP/AVP 0 18

m=video 3458 RTP/AVP 31

a=cdsc: 3 video RTP/AVP 31 34

L’envoyeur de cette description de session est actuellement prêt à envoyer et recevoir de l’audio G.729 et de la vidéo H.261. L’envoyeur est de plus capable de prendre en charge :

* le codage MIC U pour le flux de support audio,

* H.263 pou le flux de support vidéo.

Noter que le premier numéro de capacité spécifié est 1, tandis que le suivant est 3, car les deux formats de supports ont été inclus dans la première description de capacité. Noter aussi que le numéro de séquence s’applique à l’ensemble de capacités entier, c’est-à-dire, aussi bien audio que vidéo, et donc n’est fourni qu’une seule fois. Finalement, noter que les formats de supports 18 et 31 sont énumérés dans les deux lignes de supports et d’ensemble de capacités comme exigé. La description de session ci-dessus pourrait également avoir été fournie comme ceci :

v=0

o=- 25678 753849 IN IP4 128.96.41.1

c=IN IP4 128.96.41.1

t=0 0

a=sqn: 0

a=cdsc: 1 audio RTP/AVP 0 18

a=cdsc: 3 video RTP/AVP 31 34

m=audio 3456 RTP/AVP 18

m=video 3458 RTP/AVP 31

c’est-à-dire, avec l’ensemble de capacités fourni au niveau session.

4. Considérations sur la sécurité

La négociation de capacité de paramètres sensibles à la sécurité est un processus délicat, et ne devrait pas être faite sans une évaluation soigneuse de sa conception, incluant la possible susceptibilité aux attaques en dégradation. L’utilisation de la re-négociation de capacité peut rendre la session susceptible de déni de service, si la conception ne prend pas en compte l’authentification.

5. Considérations relatives à l’IANA

Le présent document définit les nouveaux paramètres SDP suivants de type "att-field" (noms d’attribut) :

Nom d’attribut : sqn

Forme longue du nom : Sequence number.

Type d’attribut : niveau session et niveau support.

soumis à un jeu de caractères : non.

Objet : numérotage d’ensemble de capacités.