Modificateurs de bande passante du protocole de description de session (SDP)
pour la bande passante du protocole de contrôle de RTP (RTCP)

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

Copyright (C) The Internet Society (2003). Tous droits réservés

Résumé

Le présent document définit une extension au protocole de description de session (SDP, Session Description Protocol) pour spécifier deux modificateurs supplémentaires pour l’attribut de bande passante. Ces modificateurs peuvent être utilisés pour spécifier la bande passante permise pour les paquets du protocole de contrôle RTP (RTCP, RTP Control Protocol) dans une session du protocole de transport en temps réel (RTP, Real-time Transport Protocol).

1. Introduction

Le protocole de transport en temps réel (RTP), [RFC3550], comporte un protocole de contrôle, RTCP, qui fournit les informations de synchronisation à partir des envoyeurs de données et des informations de rétroaction de la part des receveurs des données.

Normalement, la quantité de bande passante allouée à RTCP dans une session RTP est de 5 % de la bande passante de la session. Pour certaines applications, il peut être approprié de spécifier la bande passante RTCP indépendamment de la bande passante de session. Utiliser un paramètre distinct permet aux applications qui s’adaptent au débit de régler une bande passante RTCP cohérente avec une bande passante de données "normale" qui est plus faible que la bande passante maximum spécifiée par le paramètre de bande passante de session. Cela permet de garder la bande passante RTCP à moins de 5 % de la bande passante des données lorsque le débit doit être réduit.

D’un autre côté, il peut y avoir des applications qui envoient des données à de très faibles débits mais ont besoin de communiquer des informations extra RTCP, comme des paquets APP. Ces applications peuvent avoir besoin de spécifier une bande passante RTCP qui soit supérieure aux 5 % de la bande passante des données.

La spécification RTP permet à un profil de spécifier que la bande passante RTCP peut être divisée en deux paramètres de session séparés pour les participants qui sont des envoyeurs de données actifs et ceux qui ne le sont pas. Utiliser deux paramètres permet aux rapports de réception de RTCP d’être entièrement désactivés pour une certaine session en réglant à zéro la bande passante RTCP pour les non envoyeurs de données tout en gardant différente de zéro la bande passante RTCP pour les envoyeurs de données afin que les rapports de ces envoyeurs puissent toujours être envoyés pour la synchronisation entre les supports. Désactiver les rapports de réception RTCP n’est pas recommandé parce qu’ils sont nécessaires pour les fonctions mentionnées dans la spécification RTP, en particulier les retours sur la qualité de réception et le contrôle d’encombrement. Cependant, faire ainsi peut être approprié pour les systèmes qui fonctionnent sur des liaisons unidirectionnelles ou pour des sessions qui n’exigent pas de retours sur la qualité de réception ou la survie des receveurs et qui ont d’autres moyens pour éviter l’encombrement.

Le présent mémoire définit une extension au protocole de description de session (SDP) [RFC2327] pour spécifier la bande passante RTCP pour les envoyeurs et les non envoyeurs (receveurs).

2. Extensions SDP

Le protocole de description de session comporte un attribut facultatif de bande passante qui a la syntaxe suivante :

b=<modificateur>:<valeur de bande passante>

où <modificateur> est un seul mot alphanumérique qui donne la signification de la valeur de bande passante, et où l’unité par défaut pour <valeur de bande passante> est le kilobits par seconde. Cet attribut spécifie la bande passante proposée à utiliser par la session ou le support.

Une utilisation typique est avec le modificateur "AS" (pour maximum spécifique de l’application) qui peut être utilisé pour spécifier la bande passante totale pour un seul flux de support à partir d’un site (source).

Le présent mémoire définit deux modificateurs supplémentaires de bande passante :

b=RS:<valeur de bande passante>

b=RR:<valeur de bande passante>

où "RS" indique la bande passante RTCP allouée aux envoyeurs de données actifs (comme défini par la spécification de RTP) et "RR" indique la bande passante RTCP allouée aux autres participants à la session RTP (c’est-à-dire, les receveurs). Le comportement exact induit par la spécification de ces modificateurs de bande passante dépend de l’algorithme utilisé pour calculer l’intervalle de rapports RTCP. Des algorithmes différents peuvent être spécifiés par des profils RTP différents.

Pour le profil A/V de RTP [RFC3551], qui spécifie que l’algorithme d’intervalle RTCP par défaut dans la spécification RTP [RFC3550] doit être utilisé, au moins RS/(RS+RR) de la bande passante RTCP est dédié aux envoyeurs de données actifs. Si la proportion d’envoyeurs du nombre total de participants est inférieur ou égal à RS/(RS+RR), chaque envoyeur obtient RS divisé par le nombre d’envoyeurs. Lorsque la proportion d’envoyeurs est supérieure à RS/(RS+RR), les envoyeurs obtiennent leur proportion de la somme de ces paramètres, ce qui signifie qu’un envoyeur et un non envoyeur obtiennent chacun la même allocation. Donc, il n’est pas possible de contraindre les envoyeurs de données d’utiliser moins de bande passante RTCP que ce qui est alloué aux non envoyeurs. On notera quelques cas particuliers :

o Si RR est zéro, alors la proportion de participants qui sont envoyeurs ne peut jamais être supérieure à RS/(RS+RR), et donc les non envoyeurs n’obtiennent jamais de bande passante RTCP indépendamment du nombre d’envoyeurs.

o Régler RS à zéro ne signifie pas que les envoyeurs de données ne sont pas autorisés à envoyer des paquets RTCP, cela signifie seulement qu’ils sont traités comme les non envoyeurs. La proportion d’envoyeurs (si il y en a) serait toujours supérieure à RS/(RS+RR) si RR est différent de zéro.

o Si RS et RR sont tous deux zéro, il serait déraisonnable de tenter de calculer la fraction RS/(RS+RR).

L’allocation de bande passante spécifiée par les modificateurs RS et RR s’applique à la bande passante totale consommée par tous les types de paquets RTCP, y compris SR, RR, SDES, BYE, APP et tous nouveaux types définis à l’avenir. La <valeur de bande passante> pour ces modificateurs est en unités de bits par seconde avec une valeur d’entier.

Note : La présente spécification était en conflit avec la spécification SDP initiale de la [RFC2327] qui prescrit que la <valeur de bande passante> pour tous les modificateurs de bande passante devrait être un nombre entier de kilobits par seconde. Cette discordance était forcée par le fait que le réglage de bande passante RTCP désiré peut être de moins de 1 kbit/s. Au 44^ème congrès de l’IETF à Minneapolis, deux solutions ont été considérées : permettre des valeurs fractionnaires, ou spécifier que l’unité pour ces modificateurs particuliers serait en bits par seconde. Ce second choix a été préféré afin que la syntaxe ne soit pas changée. La spécification de SDP sera modifiée [RFC4566] pour passer au statut de Projet de norme, et permettra ce changement de sémantique.

3. Valeurs par défaut

Si l’un ou l’autre, ou les deux, spécificateurs RS et RR de bande passante sont omis, les valeurs par défaut pour ces paramètres sont spécifiés dans le profil RTP utilisé pour la session en question. Pour le profil audio/vidéo, [RFC3551], les valeurs par défaut suivent les recommandations de la spécification RTP :

o La bande passante RTCP totale est de 5 % de la bande passante de la session. Si un des spécificateurs de bande passante RTCP est omis, sa valeur est de 5 % moins la valeur de l’autre, mais pas moins que zéro. Si tous deux sont omis, les bandes passantes de l’envoyeur et du receveur RTCP sont respectivement de 1,25 % et 3,75 % de la bande passante de la session.

o Au moins RS/(RS+RR) de la bande passante RTCP est dédié aux envoyeurs de données actifs. Lorsque la proportion d’envoyeurs est supérieure à RS/(RS+RR) des participants, les envoyeurs obtiennent leur proportion de la somme de ces paramètres.

Le présent mémoire n’impose pas de limite aux valeurs qui peuvent être spécifiées avec les modificateurs RR et RS, autre que le fait qu’ils ne doivent pas être négatifs. Cependant, la spécification RTP et le profil RTP approprié peuvent spécifier des limites.

4. Préséance

Une description SDP consiste en une description de niveau session (les détails qui s’appliquent à la session entière et à tous les flux de supports) et zéro, une ou plusieurs descriptions de niveau support (les détails qui ne s’appliquent qu’à un seul flux de support). Les spécificateurs de bande passante peuvent être présents soit au niveau session pour spécifier la bande passante totale partagée par tous les supports, soit dans les sections support pour spécifier la bande passante allouée à chaque support, ou les deux. Ceci est vrai aussi pour les deux modificateurs de bande passante RTCP définis ici.

Comme la bande passante allouée à RTCP est une fraction de la bande passante de session lorsque elle n’est pas spécifiée explicitement en utilisant les modificateurs définis ici, il y a une interaction entre la bande passante de session et les spécificateurs de bande passante RTCP au niveau de la session et du support de la description SDP. La préséance de ces spécificateurs est la suivante, (1) étant la plus forte préséance :

1) Spécificateur RR ou RS explicite au niveau support

2) Spécificateur RR ou RS explicite au niveau session

3) Valeur par défaut sur la base du spécificateur de bande passante de session au niveau support

4) Valeur par défaut sur la base du spécificateur de bande passante de session au niveau session.

En particulier, la relation de (2) et (3) signifie que si la bande passante RR est spécifiée comme zéro au niveau session, cela coupe la transmission RTCP pour les non envoyeurs de données dans tous les supports.

5. Exemple

Exemple de description SDP :

v=0

o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4

s=Séminaire SDP

i=Séminaire sur le protocole de description de session

c=IN IP4 224.2.17.12/127

t=2873397496 2873404696

m=audio 49170 RTP/AVP 0

b=AS:64

b=RS:800

b=RR:2400

m=video 51372 RTP/AVP 31

b=AS:256

b=RS:800

b=RR:2400

Dans cet exemple, les bandes passantes explicites RTCP pour le support audio sont égales aux valeurs par défaut et pourraient ainsi être omises. Cependant, pour le support vidéo, les bandes passantes RTCP ont été réglées selon une bande passante de données de 64 kbit/s bien que la bande passante de données maximum soit spécifiée comme 256 kbit/s. Ceci se fonde sur l’hypothèse que la bande passante des données vidéo va automatiquement s’adapter à une valeur inférieure sur la base des conditions du réseau.

6. Considérations relatives à l’IANA

La [RFC2327] exige que les nouveaux modificateurs de bande passante soient enregistrés auprès de l’IANA par référence à une RFC en cours de normalisation spécifiant précisément la sémantique du modificateur de bande passante, indiquant quand il devrait être utilisé, et pourquoi les spécificateurs de bande passante enregistrés existants ne suffisent pas.

Le présent document est destiné à satisfaire ces exigences.

Dans le tableau "bwtype" du registre des paramètres du protocole de description de session (SDP) les deux nouveaux modificateurs de bande passante suivants ont été enregistrés :

RS

RR

7. Considérations sur la sécurité

Le présent mémoire définit les mots clés modificateur de bande passante comme une extension à SDP, de sorte que les considérations pour la sécurité énumérées dans la spécification SDP s’appliquent aux descriptions de session qui contiennent ces modificateurs comme à tous les autres. La valeur de bande passante fournie avec un de ces modificateurs pourrait être déraisonnablement grande et causer l’envoi par l’application de paquets RTCP à un taux excessif, résultant en un déni de service. Ceci est similaire au risque qu’une bande passante déraisonnable soit spécifiée pour les données de support, bien que les codeurs aient généralement une gamme limitée de bande passante. Les applications devraient appliquer des vérifications de validité à tous les paramètres reçus dans une description SDP, en particulier si elle n’est pas authentifiée. Le présent mémoire ne peut pas spécifier de limites parce que elles dépendent du profil et de l’application RTP.

8. Références

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

[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)

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

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

9. Adresse de l’auteur

Stephen L. Casner

Packet Design

3400 Hillview Avenue, Building 3

Palo Alto, CA 94304

United States

téléphone : +1 650 739-1843

mél : casner@acm.org

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

Remerciement

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