Aller au contenu principal

1. Introduction

1. Introduction

Le Session Description Protocol (protocole de description de session, SDP) [1] a été conçu à l'origine pour décrire des sessions multicast transportées sur le Mbone. Le Session Announcement Protocol (protocole d'annonce de session, SAP) [6] a été élaboré comme mécanisme multicast pour porter des messages SDP. Bien que la spécification SDP autorise le fonctionnement en unicast, elle est incomplète. Contrairement au multicast, où une vue globale de la session est utilisée par tous les participants, les sessions unicast impliquent deux participants, et une vue complète de la session exige des informations provenant des deux parties ainsi qu'un accord sur les paramètres entre elles.

À titre d'exemple, une session multicast nécessite de transmettre une seule adresse multicast pour un flux média donné. En revanche, pour une session unicast, deux adresses sont nécessaires, une pour chaque participant. Autre exemple : une session multicast exige une indication des codecs qui seront utilisés dans la session. Pour l'unicast, en revanche, l'ensemble des codecs doit être déterminé en trouvant le chevauchement entre les ensembles pris en charge par chaque participant.

Par conséquent, même si le SDP est suffisamment expressif pour décrire des sessions unicast, il manque la sémantique et les détails opérationnels sur la manière concrète de le faire. Le présent document y remédie en définissant un modèle simple d'offre et de réponse (offer/answer) fondé sur le SDP. Dans ce modèle, un participant à la session génère un message SDP qui constitue l'offre : l'ensemble des flux média et des codecs que l'offreur souhaite utiliser, ainsi que les adresses IP et les ports que l'offreur souhaite utiliser pour recevoir le média. L'offre est transmise à l'autre participant, appelé le répondant. Le répondant génère une réponse, qui est un message SDP répondant à l'offre fournie par l'offreur. La réponse comporte un flux média 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 IP et ports que le répondant souhaite utiliser pour recevoir le média.

Il est également possible qu'une session multicast fonctionne de façon similaire à une session unicast : ses paramètres sont négociés entre une paire d'utilisateurs comme dans le cas unicast, mais les deux côtés envoient des paquets vers la même adresse multicast plutôt que vers des adresses unicast. Le présent document traite aussi de l'application du modèle offer/answer aux flux multicast.

Nous définissons en outre des lignes directrices sur l'utilisation du modèle offer/answer pour mettre à jour une session après un échange initial d'offre et de réponse.

Les moyens par lesquels les offres et les réponses sont transportées sortent du champ du présent document. Le modèle offer/answer défini ici est le mécanisme de référence obligatoire utilisé par le Session Initiation Protocol (protocole d'initiation de session, SIP) [7].