Groupe de travail Réseau |
J. Rosenberg, dynamicsoft |
Request for Comments : 3264 |
H. Schulzrinne, Columbia U. |
RFC rendue obsolète : 2543 |
|
Catégorie : En cours de normalisation |
juin 2002 |
Traduction Claude Brière de L’Isle |
janvier 2008 |
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 (2002). Tous droits réservés.
Résumé
Le présent document définit un mécanisme par lequel deux entités peuvent utiliser le protocole de description de session (SDP, Session Description Protocol) pour arriver à une vue commune d’une session multimédia entre eux. Dans le modèle, un participant offre à l’autre une description de la session désirée dans sa perspective, et l’autre participant répond par la session désirée de son point de vue. Ce modèle d’offre/réponse est des plus utiles dans les sessions en envoi individuel où les informations provenant des deux participants sont nécessaires pour une vision complète de la session. Le modèle d’offre/réponse est utilisé par des protocoles comme le protocole d’initiation de session (SIP, Session Initiation Protocol).
Table des matières
1 Introduction
2 Terminologie
3 Définitions
4 Fonctionnement du protocole
5 Génération de l’offre initiale
5.1 Flux en envoi individuel
5.2 Flux en diffusion groupée
6 Génération de la réponse
6.1 Flux en envoi individuel
6.2 Flux en diffusion groupée
7 Traitement de la réponse par l’offreur
8 Modification de la session
8.1 Ajout d’un flux de support
8.2 Retrait d’un flux de support
8.3 Modification d’un flux de support
8.3.1 Modification de l’adresse, du port ou du transport
8.3.2 Changement de l’ensemble des formats de supports .
8.3.3 Changemant des types de supports
8.3.4 Changement des attributs
8.4 Mise en garde d’un flux de support en envoi individuel
9 Indication des capacités
10 Exemple d’échange offre/réponse
10.1 Échange de base
10.2 Sélection d’un parmi N codecs
11 Considérations sur la sécurité
12 Considérations relatives à l’IANA
13 Remerciements
14 Références normatives
15 Références informatives
16 Adresse des auteurs
17 Déclaration complète de droits de reproduction
Le protocole de description de session (SDP, Session Description Protocol) [1] a été conçu à l’origine comme un moyen de décrire des sessions de diffusion groupée portées sur le Mbone. Le protocole d’annonce de session (SAP, Session Announcement Protocol) [6] était conçu comme un mécanisme de diffusion groupée pour porter des messages SDP. Bien que la spécification SDP permette un fonctionnement en envoi individuel, elle n’est pas complète. À la différence de la diffusion groupée, où il y a une vision globale de la session qui est utilisée par tous les participants, les sessions d’envoi individuel impliquent deux participants, et une vision complète de la session exige des informations de la part des deux participants, et un accord entre eux sur les paramètres.
Par exemple, une session en diffusion groupée exige de convoyer une seule adresse de diffusion groupée pour un flux de supports particulier. Cependant, pour une session en envoi individuel, deux adresses sont nécessaires - une pour chaque participant. Pour un autre exemple, une session en diffusion groupée exige une indication des codecs qui seront utilisés dans la session. Cependant, pour l’envoi individuel, l’ensemble des codecs a besoin d’être déterminé en trouvant un recouvrement avec l’ensemble accepté par chaque participant.
Il en résulte que quand bien même SDP aurait la capacité d’expression pour décrire des sessions en envoi individuel, il lui manque la sémantique et les détails opérationnels sur la façon dont cela se fait réellement. Dans le présent document, on remédie à cela en définissant un modèle simple d’offre/réponse fondé sur SDP. Dans ce modèle, un participant à la session génère un message SDP qui constitue l’offre – l’ensemble de flux de supports et de codecs que l’offreur souhaite utiliser, ainsi que les adresses et ports IP que l’offreur aimerait utiliser pour recevoir le support. L’offre est convoyée à l’autre participant, appelé celui qui répond. Celui qui répond génère une réponse, qui est un message SDP qui répond à l’offre fournie par l’offreur. La réponse a un flux de supports correspondant pour chaque flux de l’offre, indiquant si le flux est accepté ou non, ainsi que les codecs qui seront utilisés et les adresses et ports IP que celui qui répond veut utiliser pour la réception du support.
Il est aussi possible à une session en diffusion groupée de travailler de façon similaire à une session en envoi individuel ; ses paramètres sont négociés entre une paire d’utilisateurs comme dans le cas de l’envoi individuel, mais les deux côtés envoient des paquets à la même adresse de diffusion groupée, plutôt que des envois individuels. Le présent document expose aussi l’application du modèle d’offre/réponse à des flux en diffusion groupée.
On définit aussi des lignes directrices sur la façon dont le modèle d’offre/réponse est utilisé pour mettre à jour une session après un échange d’offre/réponse initial.
Les moyens par lesquels les offres et les réponses sont convoyées sortent du domaine d’application du présent document. Le modèle d’offre/réponse défini ici est le mécanisme de base obligatoire utilisé par le protocole d’initiation de session (SIP) [7].
Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans la RFC 2119 [2] et indiquent les niveaux d’exigence pour les mises en œuvre SIP conformes.
Les termes suivants sont utilisés tout au long du présent document.
Agent : Un agent est la mise en œuvre de protocole impliquée dans l’échange d’offre/réponse. Il y a deux agents impliqués dans un échange d’offre/réponse.
Réponse : Message SDP envoyé par celui qui répond, en réponse à une offre reçue d’un offreur.
Celui qui répond : Agent qui reçoit une description de session d’un autre agent, décrivant les aspects des supports de communication désirés, et qui répond à cela par sa propre description de session.
Flux de support : D’après RTSP [8], un flux de support est une seule instance de support, par exemple, un flux audio ou un flux vidéo aussi bien qu’un seul tableau blanc ou un groupe d’applications partagé. Dans SDP, un flux de support est décrit par une ligne "m=" et ses attributs associés.
Offre : Message SDP envoyé par un offreur.
Offreur: Agent qui génère une description de session afin de créer ou modifier une session.
L’échange d’offre/réponse suppose l’existence d’un protocole de couche supérieure (tel que SIP) qui soit capable d’échanger SDP pour les besoins de l’établissement de session entre agents.
Le fonctionnement du protocole commence quand un agent envoie une offre initiale à un autre agent. Une offre est initiale si elle est en-dehors de tout contexte qui pourrait avoir été déjà établi à travers le protocole de couche supérieure. Il est supposé que le protocole de couche supérieure fournit la maintenance d’une sorte de contexte qui permet aux divers échanges SDP d’être associés.
L’agent qui reçoit l’offre PEUT générer une réponse, ou il PEUT rejeter l’offre. Les moyens de rejet d’une offre dépendent du protocole de couche supérieure. L’échange d’offre/réponse est atomique ; si la réponse est rejetée, la session revient au stade antérieur à l’offre (qui peut être l’absence de session).
À tout moment, l’un ou l’autre agent PEUT générer une nouvelle offre qui met à jour la session. Cependant, il NE DOIT PAS générer une nouvelle offre si il a reçu une offre qui n’a pas encore été rejetée ou à laquelle il n’a pas encore été répondu. De plus, il NE DOIT PAS générer une nouvelle offre si il a généré une offre antérieure à laquelle il n’a pas encore reçu de réponse ou de rejet. Si un agent reçoit une offre après en avoir envoyé une, mais avant d’en avoir reçu une réponse, ceci est considéré comme une condition de "double prise".
Le terme de double prise était à l’origine utilisé dans les réseaux de communication à commutation de circuits pour décrire une condition où deux commutateurs essayent simultanément de prendre le même circuit disponible sur la même artère. Ici, il signifie que les deux agents ont tenté d’envoyer simultanément une offre mise à jour.
Le protocole de couche supérieure a besoin de fournir un moyen pour résoudre une telle condition. Le protocole de couche supérieure devra fournir un moyen pour ordonner les messages dans chaque direction. SIP satisfait à ces exigences [7].
L’offre (et la réponse) DOIT être un message SDP valide, comme défini dans la RFC 2327 [1], à une seule exception près. La RFC 2327 rend obligatoire la présence d’une ligne e ou p dans le message SDP. La présente spécification assouplit cette contrainte ; un message SDP formulé pour une application offre/réponse PEUT omettre les deux lignes e et p. La valeur numérique de l’identifiant de session et la version dans la ligne o DOIT être représentable par un entier signé de 64 bits. La valeur initiale de la version DOIT être inférieure à (2**62)-1, pour éviter le retour à zéro. Bien que la spécification SPD permette que plusieurs descriptions de session soient concaténées en un grand message SDP, un message SDP utilisé dans le modèle d’offre/réponse DOIT contenir exactement une description de session.
La ligne SDP "s=" porte le sujet de la session, qui est raisonnablement défini pour la diffusion groupée, mais mal défini pour l’envoi individuel. Pour les sessions en envoi individuel, il est RECOMMANDÉ qu’il consiste en un seul caractère espace (0x20) ou un trait d’union (-).
Malheureusement, SDP n’admet pas que la ligne "s=" soit vide.
La ligne SDP "t=" porte l’heure de la session. Généralement, les flux pour les sessions en envoi individuel sont créées et détruites par des moyens de signalisation externes, tels que SIP. Dans ce cas, la ligne "t=" DEVRAIT avoir une valeur de "0 0".
L’offre va contenir zéro, un ou plusieurs flux de support (chaque flux de support est décrit par une ligne "m=" et ses attributs associés). Zéro flux de support implique que l’offreur souhaite communiquer, mais que les flux pour la session seront ajoutés ultérieurement au moyen d’une offre modifiée. Les flux PEUVENT être pour un mélange d’envois individuels et de diffusion groupée ; cette dernière implique à l’évidence une adresse de diffusion groupée dans la ou les lignes "c=" pertinentes.
La construction de chaque flux offert dépend de ce que le flux est en envoi individuel ou en diffusion groupée.
Si l’offreur souhaite seulement envoyer des supports sur un flux à son homologue, il DOIT marquer le flux comme envoi seul (sendonly) avec l’attribut "a=sendonly". On se réfère à un flux qui est marqué avec une certaine direction si un attribut direction était présent comme attribut de flux de support ou attribut de session. Si l’offreur souhaite seulement recevoir des supports de son homologue, il DOIT marquer le flux comment réception seule (recvonly). Si l’offreur souhaite communiquer, mais souhaite n’envoyer ni recevoir à ce moment, il DOIT marquer le flux avec un attribut "a=inactive". L’attribut de direction inactive est spécifié dans la RFC 3108 [3]. Noter que dans le case du protocole de transport en temps réel (RTP, Real Time Transport Protocol) [4], RTCP est encore envoyé et reçu pour les flux envoi seul, réception seule, et inactive. C’est-à-dire, la direction du flux de support n’a pas d’impact sur l’utilisation de RTCP. Si l’offreur souhaite à la fois envoyer et recevoir des supports avec son homologue, il PEUT inclure un attribut "a=sendrecv" (envoi/réception), ou il PEUT l’omettre, car sendrecv est la valeur par défaut.
Pour les flux réception seule et envoi/réception, le numéro de port et l’adresse dans l’offre indiquent où l’offreur aimerait recevoir le flux de support. Pour les flux RTP envoi seul, l’adresse et le numéro de port indiquent indirectement où l’offreur veut recevoir les rapports RTCP. Sauf indication contraire explicite, les rapports sont envoyés au numéro de port supérieur de un au numéro indiqué. L’adresse et le port IP présents dans l’offre n’indiquent rien sur l’adresse IP de source et le port de source des paquets RTP et RTCP qui seront envoyés par l’offreur. Un numéro de port de zéro dans l’offre indique que le flux est offert mais NE DOIT PAS être utilisé. Cela n’a pas de sémantique utile dans une offre initiale, mais est permis pour des raisons d’exhaustivité, car la réponse peut contenir un port zéro indiquant un flux rejeté (Section 6). De plus, les flux existants peuvent être terminés en réglant le port à zéro (Section 8). En général, un numéro de port de zéro indique que le flux de support n’est pas voulu.
La liste des formats de support pour chaque flux de support porte deux informations, à savoir l’ensemble des formats (codecs et tous paramètres associés au codec, dans le cas de RTP) que l’offreur est capable d’envoyer et/ou recevoir (selon les attributs de direction), et, dans le cas de RTP, les numéros de type de charge utile RTP utilisés pour identifier ces formats. Si plusieurs formats figurent sur la liste, cela signifie que l’offreur est capable de faire usage de n’importe lequel de ces formats durant la session. En d’autres termes, celui qui répond PEUT changer les formats au milieu de la session, faisant usage de n’importe lequel des formats listés, sans envoyer une nouvelle offre. Pour un flux envoi seul, l’offre DEVRAIT indiquer les formats que l’offreur veut envoyer pour ce flux. Pour un flux réception seule, l’offre DEVRAIT indiquer les formats que l’offreur veut recevoir pour ce flux. Pour un flux envoi/réception, l’offre DEVRAIT indiquer les codecs avec lesquels l’offreur veut envoyer et recevoir.
Pour les flux RTP réception seule, les numéros de type de charge utile indiquent la valeur du champ type de charge utile dans les paquets RTP que l’offreur s’attend à recevoir pour ce codec. Pour les flux RTP envoi seul, les numéros de type de charge utile indiquent la valeur du champ type de charge utile dans les paquets RTP que l’offreur prévoit d’envoyer pour ce codec. Pour les flux RTP envoi/réception, les numéros de type de charge utile indiquent la valeur du champ type de charge utile que l’offreur s’attend à recevoir, et préfèrerait envoyer. Cependant, pour les flux envoi seul et envoi/réception, la réponse peut indiquer différents numéros de type de charge utile pour les mêmes codecs, auquel cas, l’offreur DOIT envoyer avec les numéros de type de charge utile tirés de la réponse.
Différents numéros de type de charge utile peuvent être nécessaires dans chaque direction à cause de problèmes d’interopérabilité avec la Recommandation UIT-T H.323.
Conformément à la RFC 2327, des paramètres fmtp PEUVENT être présents pour fournir des paramètres supplémentaires de format de support.
Dans le cas de flux RTP, toutes les descriptions de support DEVRAIENT contenir des transpositions "a=rtpmap" des types RTP de charge utile en codages. Si il n’y a pas de "a=rtpmap", on doit utiliser la transposition par défaut de type de charge utile, telle que définie par le profil d’utilisation en cours (par exemple, RFC 1890 [5]).
Cela permet une migration plus facile à partir des types statiques de charge utile.
Dans tous les cas, les formats dans la ligne "m=" DOIVENT être listés dans l’ordre de préférence, le premier format de la liste étant le préféré. Dans ce cas, préféré signifie que le receveur de l’offre DEVRAIT utiliser le format qu’il accepte ayant la plus forte préférence.
Si l’attribut ptime est présent pour un flux, il indique l’intervalle de mise en paquet souhaité que l’offreur aimerait recevoir. L’attribut ptime DOIT être supérieur à zéro.
Si l’attribut bandwidth est présent pour un flux, il indique la bande passante désirée que l’offreur aimerait recevoir. Une valeur de zéro est permise, mais déconseillée. Elle indique qu’aucun support ne devrait être envoyé. Dans le cas de RTP, elle désactiverait aussi tout RTCP.
Si plusieurs flux de supports de différents types sont présents, cela signifie que l’offreur souhaite utiliser ces flux simultanément. Un cas typique est un flux audio et un flux vidéo au titre d’une visioconférence.
Si plusieurs flux de supports de même type sont présents dans une offre, cela signifie que l’offreur souhaite envoyer (et/ou recevoir) plusieurs flux de ce type en même temps. Lors de l’envoi de plusieurs flux du même type, c’est une question de politique locale de savoir comment chaque source de support de ce type (par exemple, une caméra vidéo et du VCR dans le cas de la vidéo) est transposée dans chaque flux. Lorsqu’un utilisateur a une seule source pour un type de support particulier, une seule politique convient : la source est envoyée à chaque flux du même type. Chaque flux PEUT utiliser des codages différents. Lors de la réception de plusieurs flux du même type, c’est une question de politique locale de savoir comment chaque flux est transposé dans les divers collecteurs de support pour ce type particulier (par exemple, les haut-parleurs ou un magnétophone dans le cas de l’audio). Il y a cependant quelques contraintes sur les politiques. D’abord, lors de la réception de plusieurs flux de même type, chaque flux DOIT être transposé dans au moins un collecteur pour les besoins de la présentation à l’usager. En d’autres termes, l’intention de la réception de plusieurs flux de même type est qu’ils devraient tous être présentés en parallèle, plutôt que de n’en choisir qu’un. Une autre contrainte est que lorsque plusieurs flux sont reçus et envoyés au même collecteur, ils DOIVENT être combinés d’une façon spécifique du support. Par exemple, dans le cas de deux flux audio, le support reçu de chacun pourrait être transposé aux haut-parleurs. Dans ce cas, l’opération de combinaison pourrait être de les mixer. Dans le cas de plusieurs flux de messagerie instantanée, où le collecteur est l’écran, l’opération de combinaison pourrait être de les présenter tous à l’interface d’utilisateur. La troisième contrainte est que si plusieurs sources sont transposées sur le même flux, ces sources DOIVENT être combinées d’une façon spécifique du support avant d’être envoyées sur le flux. Bien que les politiques au-delà de ces contraintes soient souples, un agent ne voudra généralement pas d’une politique qui copie le support sur ses sources d’après son collecteur à moins qu’il s’agisse d’un serveur de conférence (c’est-à-dire, ne pas copier sur un autre flux les supports reçus sur un flux).
Un exemple d’utilisation typique de plusieurs flux de supports du même type est celui d’une application de carte téléphonique prépayée, où l’utilisateur peut appuyer et tenir la touche dièse ("#") à tout moment durant un appel pour décrocher et faire un nouvel appel sur la même carte. Cela exige un support de l’usager vers deux destinations – la passerelle distante, et l’application de traitement DTMF qui cherche le dièse. Cela pourrait être accomplis avec deux flux de supports, un envoi/réception vers la passerelle, et l’autre envoi seul (du point de vue de l’usager) vers l’application DTMF.
Une fois que l’offreur a envoyé l’offre, il DOIT être prêt à recevoir des supports pour tout flux réception seule décrit par cette offre. Il DOIT être prêt à envoyer et recevoir des supports pour tout flux sendrecv dans l’offre, et à envoyer des supports pour tout flux envoi seul dans l’offre (bien sûr, il ne peut pas réellement envoyer tant que l’homologue n’a pas fourni une réponse avec les informations nécessaires d’adresse et de port). Dans le cas de RTP, bien qu’il puisse recevoir des supports avant que n’arrive la réponse, il ne sera pas capable d’envoyer des rapports de receveur RTCP avant que la réponse n’arrive.
Si une description de session contient un flux de support en diffusion groupée qui est désigné comme en réception (en envoi) seul, cela signifie que les participants, y compris l’offreur et celui qui répond, peuvent seulement recevoir (envoyer) sur ce flux. Cela diffère de la vision de l’envoi individuel, où la direction se réfère au flux de supports entre l’offreur et celui qui répond.
Au delà de cette précision, la sémantique d’un flux offert en diffusion groupée est exactement comme décrit dans la RFC 2327 [1].
La réponse à une description de session offerte se fonde sur la description de session offerte. Si la réponse est différente de l’offre d’une façon quelconque (adresses IP, ports, etc.), la ligne origine DOIT être différente dans la réponse, car la réponse est générée par une entrée différente. Dans ce cas, le numéro de version dans la ligne "o=" de la réponse est sans relation avec le numéro de version de la ligne o de l’offre.
Pour chaque ligne "m=" de l’offre, il DOIT y avoir une ligne "m=" correspondante dans la réponse. La réponse DOIT contenir exactement le même nombre de lignes "m=" que l’offre. Cela permet à des flux d’être confrontés sur la base de leur ordre. Cela implique que si l’offre contenait zéro ligne "m=", la réponse DOIT contenir zéro ligne "m=".
La ligne "t=" dans la réponse DOIT être égale à celle de l’offre. L’heure de la session ne peut être négociée.
Un flux offert PEUT être rejeté dans la réponse, pour n’importe quelle raison. Si un flux est rejeté, l’offreur et celui qui répond NE DOIVENT PAS générer de supports (ou paquets RTCP) pour ce flux. Pour rejeter un flux offert, le numéro de port dans le flux correspondant de la réponse DOIT être mis à zéro. Tout format de support listé est ignoré. Au moins un DOIT être présent, comme spécifié par SDP.
La construction d’une réponse pour chaque flux offert diffère pour l’envoi individuel et pour la diffusion groupée.
Si un flux est offert avec une adresse en envoi individuel, la réponse pour ce flux DOIT contenir une adresse d’envoi individuel. Le type de support du flux dans la réponse DOIT correspondre à celui de l’offre.
Si un flux est offert comme envoi seul, le flux correspondant DOIT être marqué comme réception seule ou inactif dans la réponse. Si un flux de support est répertorié comme réception seule dans l’offre, la réponse DOIT être marquée en envoi seul ou inactif dans la réponse. Si un flux de support offert est marqué envoi/réception (ou si il n’y a pas d’attribut de direction au niveau support ou session, auquel cas le flux est envoi/réception par défaut), le flux correspondant dans la réponse PEUT être marqué envoi seul, réception seule, envoi/réception, ou inactif. Si un flux de support offert est marqué inactif, il DOIT être marqué inactif dans la réponse.
Pour les flux marqué en réception seule dans la réponse, la ligne "m=" DOIT contenir au moins un format de support que celui qui répond accepte de recevoir parmi ceux dont la liste figure dans l’offre. Le flux PEUT indiquer des formats de support supplémentaires, ne figurant pas sur la liste des flux correspondant dans l’offre, que celui qui répond est d’accord pour recevoir. Pour les flux marqués en envoi seul dans la réponse, la ligne "m=" DOIT contenir au moins un format de support que celui qui répond est d’accord d’envoyer parmi la liste de l’offre. Pour les flux marqués en envoi/réception dans la réponse, la ligne "m=" DOIT contenir au moins un codec sur lequel celui qui répond accepte à la fois d’envoyer et de recevoir, parmi ceux figurant sur la liste de l’offre. Le flux PEUT indiquer des formats de support supplémentaires, ne figurant pas sur la liste du flux correspondant dans l’offre, que celui qui répond accepte d’envoyer ou recevoir (bien sûr, il ne sera pas capable de les envoyer à ce moment, car ils ne figuraient pas sur la liste de l’offre). Pour les flux marqués inactifs dans la réponse, la liste des formats de support est construite sur la base de l’offre. Si l’offre était envoi seul, la liste est construite comme si la réponse était réception seule. De même, si l’offre était réception seule, la liste est construite comme si la réponse était envoi seul, et si l’offre était envoi/réception, la liste est construite comme si la réponse était envoi/réception. Si l’offre était inactif, la liste est construite comme si l’offre était en fait envoi/réception et la réponse était envoi/réception.
L’adresse et le port de connexion dans la réponse indiquent l’adresse où celui qui répond souhaite recevoir les supports (dans le cas de RTP, RTCP sera reçu sur le port qui est supérieur de un sauf si il y a une indication explicite de faire autrement). Cette adresse et ce port DOIVENT être présents même pour un flux en envoi seul ; dans le cas de RTP, le port supérieur de un est encore utilisé pour recevoir RTCP.
Dans le cas de RTP, si un codec particulier était référencé avec un numéro de charge utile spécifique dans l’offre, ce même numéro de type de charge utile DEVRAIT être utilisé pour ce codec dans la réponse. Même si le même numéro de type de charge utile est utilisé, la réponse DOIT contenir des attributs rtpmap pour définir les transpositions de type de charge utile en types de charge utile dynamiques, et DEVRAIT contenir des transpositions en types de charge utile statiques. Les formats de support dans la ligne "m=" DOIVENT être listés dans l’ordre de préférence, le premier format de la liste étant le préféré. Dans ce cas, préféré signifie que l’offreur DEVRAIT utiliser le format ayant la plus forte préférence d’après la réponse.
Bien que celui qui répond PUISSE faire la liste des formats dans leur ordre de préférence, il est RECOMMANDÉ que sauf raison spécifique, celui qui répond fasse la liste des formats dans le même ordre que celui de leur présentation dans l’offre. En d’autres termes, si un flux dans l’offre fait une liste des codecs audio 8, 22 et 48, dans cet ordre, et si celui qui répond ne prend en charge que les codecs 8 et 48, il est RECOMMANDÉ que, si celui qui répond n’a pas de raisons de le changer, l’ordre des codecs dans la réponse soit 8, 48, et non 48, 8. Cela aise à s’assurer que le même codec est utilisé dans les deux directions.
L’interprétation des paramètres fmtp dans une offre dépend des paramètres. Dans de nombreux cas, ces paramètres décrivent des configurations spécifiques du format de support, et devraient donc être traités comme la valeur de format de support le serait elle-même. Cela signifie que les mêmes paramètres fmtp avec les mêmes valeurs DOIVENT être présents dans la réponse si le format de support qu’ils décrivent est présent dans la réponse. Les autres paramètres fmtp sont plus comme des paramètres, pour lesquels il est parfaitement acceptable que chaque agent utilise des valeurs différentes. Dans ce case, la réponse PEUT contenir des paramètres fmtp, et ceux-ci PEUVENT avoir les mêmes valeurs que ceux de l’offre, ou ils PEUVENT être différents. Les extensions SDP qui définissent de nouveaux paramètres DEVRAIENT spécifier l’interprétation appropriée dans l’offre/réponse.
Celui qui répond PEUT inclure un attribut ptime différent de zéro pour tout flux de support ; cela indique l’intervalle de mise en paquet que celui qui répond aimerait recevoir. Il n’est pas exigé que l’intervalle de mise en paquet soit le même dans chaque direction pour un flux particulier.
Celui qui répond PEUT inclure un attribut bandwidth pour tout flux de support ; cela indique la bande passante que celui qui répond aimerait que l’offreur utilise lors de l’envoi des supports. La valeur de zéro est admise, interprétée comme décrit à la Section 5.
Si celui qui répond n’a pas de format de support en commun pour un flux offert particulier, celui qui répond DOIT rejeter ce flux de support en réglant le port à zéro.
Si il n’y a pas de format de support en commun pour tous les flux, toute la session offerte est rejetée.
Une fois que celui qui répond a envoyé la réponse, il DOIT être prêt à recevoir des supports pour tout flux en réception seule décrit par cette réponse. Il DOIT être prêt à envoyer et recevoir des supports pour tout flux en envoi/réception dans la réponse, et il PEUT envoyer des supports immédiatement. Celui qui répond DOIT être prêt à recevoir des supports pour des flux en réception seule ou en envoi/réception en utilisant tous les formats de support figurant sur la liste de ces flux dans la réponse, et il PEUT envoyer des supports immédiatement. Lors de l’envoi de supports, il DEVRAIT utiliser un intervalle de mise en paquet égal à la valeur de l’attribut ptime dans l’offre, s’il en était un présent. Il DEVRAIT envoyer des supports en utilisant une bande passante qui ne soit pas supérieure à la valeur de l’attribut bande passante de l’offre, s’if en était un présent. Celui qui répond DOIT envoyer en utilisant un format de support de l’offre qui est aussi indiqué dans la réponse, et DEVRAIT envoyer en utilisant le format de support préféré de l’offre qui figure aussi dans la réponse. Dans le cas de RTP, il DOIT utiliser les numéros de type de charge utile provenant de l’offre, même si ils diffèrent de ceux de la réponse.
À la différence de l’envoi individuel, où il y a une vision bilatérale du flux, il n’y a qu’une vision unique du flux pour la diffusion groupée. À ce titre, générer une réponse à une offre en diffusion groupée implique généralement de modifier un ensemble limité des aspects du flux.
Si un flux en diffusion groupée est accepté, les informations d’adresse et de port dans la réponse DOIVENT correspondre à celles de l’offre. De même, les informations de direction dans la réponse (envoi seul, réception seule, ou envoi/réception) DOIVENT être égales à celles de l’offre. Ceci parce que tous les participants d’une session en diffusion groupée ont besoin d’avoir des visions équivalentes des paramètres de la session, et des hypothèses sous-jacentes du biais de diffusion groupée de la RFC 2327.
L’ensemble des formats de support dans la réponse DOIT être égal à celui de l’offre ou en être un sous-ensemble. Retirer un format est un moyen pour celui qui répond d’indiquer que ce format n’est pas pris en charge.
Les attributs ptime et bandwidth dans la réponse DOIVENT être égaux à ceux de l’offre, s’ils sont présents. S’ils ne le sont pas, un ptime différent de zéro PEUT être ajouté à la réponse.
Lorsque l’offreur reçoit la réponse, il PEUT envoyer des supports sur le ou les flux acceptés (en supposant qu’ils figurent comme envoi/réception ou réception seule dans la réponse). Il DOIT envoyer en utilisant un format de support figurant dans la réponse, et il DEVRAIT utiliser le premier format de support figurant dans la réponse lorsqu’il n’envoie pas.
La raison de ce DEVRAIT, plutôt qu’un DOIT ( c’est aussi DEVRAIT, et non DOIT, pour celui qui répond), est qu’il sera souvent besoin de changer les codecs à l’impromptu. Par exemple, durant des périodes de silence, un agent peut vouloir passer sur un codec de bruit de confort. Ou bine, si l’usager appuie sur un numéro du clavier, l’agent peut vouloir l’envoyer en utilisant la RFC 2833 [9]. Le contrôle d’encombrement peut nécessiter le passage à un codec à plus faible débit sur la base des informations en retour.
L’offreur DEVRAIT envoyer des supports conformément à la valeur des attributs ptime et bandwidth de la réponse.
L’offreur PEUT immédiatement cesser d’écouter les formats de support qui figuraient dans l’offre initiale, mais non présents dans la réponse.
À tout moment durant la session, l’un ou l’autre participant PEUT produire une nouvelle offre pour modifier les caractéristiques de la session. Il est fondamental pour le fonctionnement du modèle d’offre/réponse que soit utilisée exactement la même procédure d’offre/réponse définie ci-dessus pour la modification des paramètres d’une session existante.
L’offre PEUT être identique au dernier SDP fourni à l’autre partie (qui peut avoir été fourni dans une offre ou une réponse), ou elle PEUT être différente. On se réfère au dernier SDP fourni comme au "SDP précédent". Si l’offre est la même, la réponse PEUT être la même que le SDP précédent provenant de celui qui répond, ou elle PEUT être différente. Si le SDP offert est différent du SDP précédent, certaines contraintes s’imposent à sa construction, qui sont exposées ci-dessous.
Presque tous les aspects de la session peuvent être modifiés. De nouveaux flux peuvent être ajoutés, des flux existants peuvent être supprimés, et des paramètres de flux existants peuvent changer. Lors de la production d’une offre qui modifie la session, la ligne "o=" du nouveau SDP DOIT être identique à celle du SDP précédent, excepté que la version dans le champ origine DOIT s’incrémenter de un par rapport au SDP précédent. Si la version dans la ligne origine n’est pas incrémentée, le SDP DOIT être identique au SDP avec ce numéro de version. Celui qui répond DOIT être prêt à recevoir une offre contenant un SDP avec une version qui n’a pas changé ; ceci est effectivement un no-op. Cependant, celui qui répond DOIT générer une réponse valide (qui PEUT être la même que le SDP précédent provenant de celui qui répond, ou PEUT être différent), conformément aux procédures définies à la Section 6.
Si un SDP est offert, qui est différent du SDP précédent, le nouveau SDP DOIT avoir un flux de support correspondant pour chaque flux de support du SDP précédent. En d’autres termes, si le SDP précédent avait N lignes "m=", le nouveau SDP DOIT avoir au moins N lignes "m=". Le i ème flux de support dans le SDP précédent, en comptant à partir du haut, correspond au i ème flux de support dans le nouveau SDP, en comptant à partir du haut. Cette correspondance est nécessaire afin que celui qui répond détermine quel flux dans la nouveau SDP correspond à un flux dans le SDP précédent. À cause de ces exigences, le nombre de lignes "m=" dans un flux ne décroît jamais, mais reste le même ou croît. Les flux de support supprimés d’un SDP précédent NE DOIVENT PAS être retirés dans un nouveau SDP ; cependant, les attributs pour ces flux n’ont pas besoin d’être présents.
De nouveaux flux de support sont créés par de nouvelles descriptions de support supplémentaires au delà de celles qui existent, ou en réutilisant le "créneau" utilisé par un ancien flux de support qui a été désactivé en réglant son port à zéro.
Réutiliser son créneau signifie que la nouvelle description de support remplace l’ancienne, mais conserve son positionnement par rapport aux autres descriptions de support dans le SDP. Les nouvelles descriptions de support DOIVENT apparaître au-dessous de toute section de support existante. Les règles de formatage de ces descriptions de support sont identiques à celles décrites à la Section 5.
Lorsque celui qui répond reçoit un SDP avec plus de descriptions de support que le SDP précédent provenant de l’offreur, ou qu’il reçoit un SDP avec un flux de support dans un créneau où le port était précédemment zéro, celui qui répond sait que de nouveaux flux de support sont en train d’être ajoutés. Ils peuvent être rejetés ou accepté en plaçant une description de support structurée de façon appropriée dans la réponse. La procédure de construction de la nouvelle description de support dans la réponse est décrite à la Section 6.
Les flux de support existants sont retirés en créant un nouveau SDP avec le numéro de port pour ce flux mis à zéro. La description de flux PEUT omettre tous les attributs précédemment présents, et PEUT faire figurer dans la liste un seul format de support.
Un flux offert avec un port de zéro DOIT être marqué avec port zéro dans la réponse. Comme l’offre, la réponse PEUT omettre tous les attributs précédemment présents, et PEUT faire figurer dans la liste un seul format de support parmi ceux de l’offre.
Le retrait d’un flux de support impliques que les supports ne sont plus envoyés pour ce flux, et tout support reçu est éliminé. Dans le cas de RTP, la transmission RTCP cesse aussi, comme le fait le traitement de tout paquet RTCP reçu. Toutes les ressources qui y sont associées peuvent être libérées. L’interface d’utilisateur peut indiquer que le flux s’est terminé, par exemple en fermant la fenêtre qui y est associée sur un micro-ordinateur.
Presque toutes les caractéristiques d’un flux de support peuvent être modifiées.
Le numéro de port d’un flux PEUT être changé. Pour ce faire, l’offreur crée une nouvelle description de support, avec le numéro de port dans la ligne m différent du flux correspondant dans le SDP précédent. Si seul le numéro de port est à changer, le reste de la description de flux de support DEVRAIT rester inchangé. L’offreur DOIT être prêt à recevoir des supports à la fois sur le vieux et le nouveau port aussitôt l’offre envoyée. L’offreur NE DEVRAIT PAS cesser d’écouter les supports sur le vieux port jusqu’à ce que la réponse soit reçue et que les supports arrivent sur le nouveau port. Le faire pourrait résulter en perte de supports pendant la transition.
Dans ce cas, reçu signifie que les supports sont passés à un collecteur de supports. Cela signifie que si il y a une mémoire tampon de lecture, l’agent continuerait à écouter sur le vieux port jusqu’à ce que les supports sur le nouveau port atteignent le bout de la mémoire tampon de lecture. À ce moment, il PEUT cesser d’écouter les supports sur le vieux port.
Le flux de support correspondant dans la réponse PEUT être le même que le flux dans le SDP précédent venant de celui qui répond, ou il PEUT être différent. Si le flux mis à jour est accepté par celui qui répond, celui qui répond DEVRAIT commencer immédiatement à envoyer du trafic pour ce flux sur le nouveau port. Si celui qui répond change le port par rapport au SDP précédent, il DOIT être prêt à recevoir des supports à la fois sur le vieux et le nouveau port aussitôt la réponse envoyée. Celui qui répond NE DOIT PAS cesser d’écouter les supports sur le vieux port jusqu’à ce que les supports arrivent sur le nouveau port. À ce moment, il PEUT cesser d’écouter les supports sur le vieux port. La même chose est vraie pour un offreur qui envoie une offre mise à jour sur un nouveau port ; il NE DOIT PAS cesser d’écouter les supports sur le vieux port jusqu’à ce que les supports arrivent sur le nouveau port.
Bien sûr, si le flux offert est rejeté, l’offreur peut cesser d’être prêt à recevoir en utilisant le nouveau port aussitôt que le rejet est reçu.
Pour changer l’adresse IP à laquelle des supports sont envoyés, on suit la même procédure que pour changer le numéro de port. La seule différence est que la ligne de connexion est mise à jour, et pas le numéro de port.
Le transport PEUT être changé pour un flux. Le processus pour ce faire est identique au changement de port, excepté que le transport est mis à jour, et pas le port.
La liste des formats de support utilisée dans la session PEUT être changée. Pour ce faire, l’offreur crée une nouvelle description de supports, avec la liste des formats de support dans la ligne "m=" différente du flux de support correspondant dans le SDP précédent. Cette liste PEUT inclure de nouveaux formats, et PEUT retirer des formats présents dans le SDP précédent. Cependant, dans le cas de RTP, la transposition d’un numéro de type de charge utile dynamique particulier en une codec particulier au sein de ce flux de support NE DOIT PAS changer pour la durée d’une session. Par exemple, si A génère une offre avec G.711 alloué au numéro de type de charge utile dynamique 46, le numéro de type de charge utile 46 DOIT se référer à G.711 à partir de ce moment dans toutes les offres ou réponses pour ce flux de support ai sein de la session. Cependant, il est acceptable pour des numéros de type de charge utile multiples d’être transposés dans le même codec, de sorte qu’une offre mise à jour puisse aussi utiliser le numéro de type de charge utile 72 pour G.711.
Les transpositions ont besoin de rester fixées pour la durée de la session à cause de la synchronisation lâche entre les échanges de signaux de SDP et le flux de support.
Le flux de support correspondant dans la réponse est formulé comme décrit à la Section 6, et peut aussi bien résulter en un changement des formats de support. De même, comme décrit à la Section 6, aussitôt qu’il envoie sa réponse, celui qui répond DOIT commencer à envoyer des supports en utilisant les formats qui dans l’offre étaient aussi présents dans la réponse, et DEVRAIT utiliser le format préféré qui dans l’offre était aussi sur la liste de la réponse (en supposant que le flux permette l’envoi), et NE DOIT PAS envoyer en utilisant des formats qui n’étaient pas dans l’offre, même si ils étaient présents dans un SDP précédent provenant de l’homologue. De même, quand l’offreur reçoit la réponse, il DOIT commencer l’envoi des supports en utilisant un des formats de la réponse, et DEVRAIT utiliser le préféré (en supposant que le flux permette l’envoi), et NE DOIT PAS envoyer en utilisant des formats qui n’étaient pas dans la réponse, même si ils étaient présents dans un SDP précédent de l’homologue.
Lorsqu’un agent cesse d’utiliser un format de support (en ne le faisant pas figurer sur la liste dans une offre ou une réponse, quand bien même il aurait été dans un SDP précédent) l’agent aura encore besoin d’être prêt à recevoir des support à ce format pendant un bref instant. Comment sait-il quand il peut être prêt à arrêter de recevoir dans ce format ? Si il a besoin de le savoir, il y a trois techniques qui peuvent être appliquées. D’abord, l’agent peut changer les ports en plus de changer les formats. Lorsque les supports arrivent sur le nouveau port, il sait que l’homologue a cessé d’envoyer au vieux format, et il peut cesser d’être prêt à y recevoir. Cette approche présente l’avantage d’être indépendante du format de support. Cependant, les changements de ports peuvent exiger des changements de réservation de ressources ou des changements des clés des protocole de sécurités. La seconde approche est d’utiliser un ensemble totalement nouveau de types de charge utile dynamiques pour tous les codecs quand l’un d’eux est éliminé. Lorsque des supports sont reçus avec un des nouveaux types de charge utile, l’agent sait que l’homologue a cessé d’envoyer au vieux format. Cette approche n'affecte pas les réservations ou les contextes de sécurité, mais elle est spécifique de RTP et coûteuse en espaces de très petits types de charge utile. Une troisième approche est d’utiliser un temporisateur. Lorsque le SDP provenant de l’homologue est reçu, le temporisateur est mis. Lorsqu’il arrive à expiration, l’agent peut cesser d’être prêt à recevoir dans le vieux format. Une valeur de une minute devrait normalement être plus que suffisante. Dans certains cas, un agent peut ne pas s’en soucier, et donc être continuellement prêt à recevoir dans les vieux formats. Il n’est rien besoin de faire dans ce cas.
Bien sûr, si le flux offert est rejeté, l’offre peut cesser d’être prête à recevoir en utilisant n’importe lequel des nouveaux formats aussitôt que le rejet est reçu.
Le type de support (audio, vidéo, etc.) pour un flux PEUT être changé. Il est RECOMMANDÉ que le type de support soit changé (par opposition à l’ajout d’un nouveau flux) lorsque les mêmes données logiques sont convoyées, mais dans un format de support différent. Ceci est particulièrement utile pour un changement entre de la télécopie en bande vocale et de la télécopie en un seul flux, qui sont tous deux des types de support distincts. Pour faire cela, l’offreur crée une nouvelle description de support, avec un nouveau type de support, à la place de la description qui doit être changée dans le SDP précédent.
Le flux de support correspondant dans la réponse est formulé comme décrit à la Section 6. En supposant que le flux est acceptable, celui qui répond DEVRAIT commencer à envoyer avec les nouveaux type et formats de support aussitôt qu’il reçoit l’offre. L’offreur DOIT être prêt à recevoir des supports aussi bien avec l’ancien que le nouveau type jusqu’à la réception de la réponse, et que des supports avec le nouveau type soient reçus et atteignent le plafond de la mémoire tampon de lecture.
Tous les autres attributs d’une description de support PEUVENT être mis à jour dans une offre ou une réponse. Généralement, un agent DOIT envoyer des supports (si la direction du flux le permet) en utilisant les nouveaux paramètres une fois que le SDP ayant le changement est reçu.
Si une des parties à un appel veut mettre l’autre partie "en garde", c’est à dire, demander qu’il arrête temporairement d’envoyer un ou plusieurs flux de support en envoi individuel, cette partie offre à l’autre un SDP mis à jour.
Si le flux à placer en garde était précédemment un flux de support en envoi/réception, il est placé en garde en le marquant comme en envoi seul. Si le flux à placer en garde était précédemment un flux de support en réception seule, il est placé en garde en le marquant comme inactif.
Cela signifie qu’un flux est placé "en garde" séparément dans chaque direction. Chaque flux est placé "en garde" indépendamment. le receveur d’une offre pour un flux en garde NE DEVRAIT PAS retourner automatiquement une réponse avec le flux correspondant en garde. Un SDP avec tous les flux "en garde" est appelé un SDP en garde.
Certains scénarios de contrôle d’appel par un tiers ne fonctionnent pas lorsque celui qui répond au SDP en garde par un SDP en garde.
Normalement, lorsque un usager "active" la mise en garde, l’agent va générer une offre avec tous les flux dans le SDP qui indiquent une direction d’envoi seul, et il va aussi se mettre localement en mode silencieux, de sorte qu’aucun support n’est envoyé à l’extrémité distante, et qu’aucun support n’est lu.
La RFC 2543 [10] spécifiait que placer un usager en garde était accompli en réglant l’adresse de connexion à 0.0.0.0. Cet usage n’est plus recommandé pour mettre un appel en garde, car cela ne permet par d’utiliser RTCP avec le flux en garde, ne fonctionne pas avec IPv6, et provoque la coupure des supports orientés connexion. Cependant, il peut être utile dans une offre initiale lorsque l’offreur sait qu’il veut utiliser un ensemble de flux de support et de formats particulier, mais ne connaît pas les adresses et ports au moment de l’offre. Bien sûr, lorsqu’il est utilisé, le numéro de port NE DOIT PAS être zéro, ce qui spécifierait que le flux a été désactivé. Un agent DOIT être capable de recevoir SDP avec une adresse de connexion de 0.0.0.0, auquel cas cela signifie que ni RTP ni RTCP ne devrait être envoyé à l’homologue.
Avant q’un agent envoie une offre, il est utile de savoir si les formats de support de cette offre seront acceptables pour celui qui répond. Certains protocoles, comme SIP, donnent le moyen d’interroger sur l’existence de telles capacités. SDP peut être utilisé dans les réponses à de telles interrogations pour indiquer les capacités. La présente section décrit comment un tel message SDP est formé. Comme SDP n’a pas de moyen d’indiquer que le message est destiné à une indication de capacité, ceci est déterminé d’après le contexte du protocole de couche supérieure. La capacité du SDP de base à indiquer des capacités est très limitée. Il ne peut pas exprimer les gammes ou valeurs de paramètres admises, et il ne peut être fait en parallèle avec une offre/réponse elle-même. Des extensions pourraient à l’avenir traiter ces limitations.
Un SDP construit pour indiquer des capacités de support est structuré comme suit. Il DOIT être un SDP valide, excepté qu’il PEUT omettre les lignes "e=" et "p=". La ligne "t=" DOIT être égale à "0 0". Pour chaque type de support pris en charge par l’agent, il DOIT y avoir une description de support correspondante de ce type. L’identifiant de session dans le champ origine DOIT être unique pour chaque SDP construit pour indiquer les capacités de support. Le port DOIT être mis à zéro, mais l’adresse de connexion est arbitraire. L’usage du port zéro assure qu’un SDP formaté pour des capacités ne cause pas l’établissement de flux de support si il est interprété comme une offre ou une réponse.
Le composant transport de la ligne "m=" indique le transport pour ce type de support. Pour chaque format de support de ce type accepté par l’agent, il DEVRAIT y avoir un format de support figurant dans la liste de la ligne "m=". Dans le case de RTP, si des types de charge utile dynamiques sont utilisés, un attribut rtpmap DOIT être présent pour lier le type à un format spécifique. Il n’y a pas de moyen d’indiquer les contraintes, comme le nombre de flux simultanés qui peuvent être acceptés pour un codec particulier, et ainsi de suite.
v=0
o=carol 28908764872 28908764872 IN IP4 100.3.6.6
s=-
t=0 0
c=IN IP4 192.0.2.4
m=audio 0 RTP/AVP 0 1 3
a=rtpmap:0 PCMU/8000
a=rtpmap:1 1016/8000
a=rtpmap:3 GSM/8000
m=video 0 RTP/AVP 31 34
a=rtpmap:31 H261/90000
a=rtpmap:34 H263/90000
Figure 1 : SDP d’indication des capacités
Le SDP de la Figure 1 indique que l’agent peut accepter trois codecs audio (PCMU, 1016, et GSM) et deux codecs vidéo (H.261 et H.263).
La présente section donne des exemples d’échanges d’offre/réponse.
Supposons que l’appelant, Alice, a inclus la description suivante dans son offre. Elle comporte un flux audio bidirectionnel et deux flux vidéo bidirectionnels, utilisant H.261 (type de charge utile 31) et MPEG (type de charge utile 32). Le SDP offert est :
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
Le demandé, Bob, ne veut pas recevoir ou envoyer le premier flux de vidéo, aussi retourne t-il le SDP ci-dessous en réponse :
v=0
o=bob 2890844730 2890844730 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 49920 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
Un peu plus tard, Bob décide de changer le port où il va recevoir le flux audio (de 49920 à 65422), et en même temps, il ajoute une flux audio supplémentaire en réception seule, en utilisant le format RTP de charge utile pour événements [9]. Bob offre le SDP suivant dans l’offre :
v=0
o=bob 2890844730 2890844731 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 65422 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
m=audio 51434 RTP/AVP 110
a=rtpmap:110 telephone-events/8000
a=receive only
Alice accepte le flux de support supplémentaire, et génère ainsi la réponse suivante :
v=0
o=alice 2890844526 2890844527 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
m=audio 53122 RTP/AVP 110
a=rtpmap:110 telephone-events/8000
a=send only
Une occurrence courante dans les téléphones incorporés est que le processeur de signal numérique (DSP, Digital Signal Processor) utilisé pour la compression peut accepter plusieurs codecs en même temps, mais une fois que ce codec est choisi, il ne peut être changé à brûle-pourpoint. Cet exemple montre comment une session peut être établie en utilisant un échange initial d’offre/réponse, suivi immédiatement par un second pour verrouiller l’ensemble de codecs.
L’offre initiale de Alice à Bob indique un seul flux audio avec les trois codecs audio qui sont disponibles dans le DSP. Le flux est marqué comme inactif, car les supports ne peuvent être reçus tant qu’un codec n’est pas verrouillé :
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 62986 RTP/AVP 0 4 18
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
=inactive
Bob peut accepter une commutation dynamique entre PCMU et G.723. Aussi envoie t-il la réponse suivante :
v=0
o=bob 2890844730 2890844731 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 54344 RTP/AVP 0 4
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=inactive
Alice peut alors choisir un de ces deux codecs. Aussi envoie t-elle une offre mise à jour avec un flux en envoi/réception :
v=0
o=alice 2890844526 2890844527 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 62986 RTP/AVP 4
a=rtpmap:4 G723/8000
a=envoi/réception
Bob accepte ce seul codec :
v=0
o=bob 2890844730 2890844732 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 54344 RTP/AVP 4
a=rtpmap:4 G723/8000
=send/receive
Si celui qui répond (Bob) était seulement capable d’accepter un des N codecs, Bob choisirait un des codecs de l’offre, et le placerait dans sa réponse. Dans ce cas, Alice ferait une re-INVITE pour activer ce flux avec ce h codec.
En solution de remplacement à l’utilisation de "a=inactive" dans le premier échange, Alice peut faire la liste de tous les codecs, et sitôt qu’elle reçoit des supports de Bob, générer une offre mise à jour, verrouillant le codec sur celui qu’elle vient de recevoir. Bien sûr, si Bob n’accepte qu’un codec parmi N, il n’y aura qu’un codec dans sa réponse, et dans ce cas, il n’est pas besoin d’une re-INVITE pour verrouiller sur un seul codec.
De nombreuses attaques sont possibles si un attaquant peut modifier les offres ou les réponses en transit. Généralement, cela inclut la diversion des flux de support (permettant l’espionnage), la désactivation des appels, et l’injection de flux de support non voulus. Si un écouteur passif peut construire de fausses offres, et les injecter dans un échange, des attaques similaires sont possibles. Même si un attaquant peut simplement observer les offres et les réponses, il peut injecter des flux de support dans une conversation existante.
L’offre/réponse s’appuie sur le transport au sein d’un protocole de signalisation d’application, comme SIP. Il s’appuie aussi sur ce protocole pour les capacités de sécurité. À cause des attaques décrites ci-dessus, ce protocole DOIT fournir le moyen d’une authentification de bout en bout et d’une protection d’intégrité des offres et des réponses. Il DEVRAIT offrir le chiffrement des corps de message pour empêcher l’espionnage. Cependant, les attaques en injection de supports peuvent être résolues autrement au moyen d’échanges de supports authentifiés, et donc l’exigence du chiffrement est un DEVRAIT et non un DOIT.
Les attaques en répétition sont aussi problématiques. Un attaquant peut répéter une ancienne offre, peut–être une qui avait mis des supports en garde, et donc désactiver les flux de supports dans une conversation. Donc, le protocole d’application DOIT fournir un moyen sûr de séquencer les offres et les réponses, et de détecter et rejeter les anciennes offres ou réponses.
SIP [7] satisfait à toutes ces exigences.
Il n’y a pas de considérations relatives à l’IANA dans la présente spécification.
Les auteurs tiennent à remercier Allison Mankin, Rohan Mahy, Joerg Ott, et Flemming Andreasen pour leurs commentaires détaillés.
[1] M. Handley et V. Jacobson, "SDP : Protocole de description de session", RFC 2327, avril 1998.
[2] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d’exigence", BCP 14, RFC 2119, mars 1997.
[3] R. Kumar et M. Mostafa, "Conventions pour l’utilisation du protocole de description de session (SDP) pour connexions à porteuse ATM", RFC 3108, mai 2001.
[4] H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson, "RTP : Protocole de transport pour applications en temps réel", RFC 1889, janvier 1996.
[5] H. Schulzrinne, "Profil RTP pour conférences audio et vidéo avec contrôle minimal", RFC 1890, janvier 1996.
[6] M. Handley, C. Perkins et E. Whelan, "Protocole d’annonce de session", RFC 2974, octobre 2000.
[7] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley et E. Schooler, "SIP: Protocole d’initiation de session", RFC 3261, juin 2002.
[8] H. Schulzrinne, A. Rao et R. Lanphier, "Protocole de visionnage en temps réel (RTSP)", RFC 2326, avril 1998.
[9] H. Schulzrinne et S. Petrack, "Charge utile RTP pour chiffres DTMF, tonalités et signaux téléphoniques", RFC 2833, mai 2000.
[10] M. Handley, H. Schulzrinne, E. Schooler et J. Rosenberg, "SIP : Protocole d’initiation de session", RFC 2543, mars 1999.
Jonathan Rosenberg |
Henning Schulzrinne |
dynamicsoft |
Columbia University |
72 Eagle Rock Avenue |
M/S 0401 |
First Floor |
1214 Amsterdam Ave. |
East Hanover, NJ 07936 |
New York, NY 10027-7003 |
mél : jdrosen@dynamicsoft.com |
Copyright (C) The Internet Society (2002). Tous droits réservés.
e 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 copyright ci-dessus et le présent et 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 copyright 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 copyright 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 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.