SIP [SIP02] (Session Initiation Protocol), est un protocole de signalisation spécifié par l'IETF (Internet Engineering Task Force). Ce protocole est utilisé pour créer, modifier,
terminer des sessions entre un ou plusieurs participants. La spécification définit premièrement des principes et une architecture pour gérer l'établissement de sessions entre participants. Des fonctions avancées permettent la mobilité des sessions.
2.1.1 Principes et architecture
Une infrastructure est définie afin de localiser les participants et relayer les communications quelque soit la topologie du réseau. SIP définit un réseau homogène se superposant aux différentes technologies complexes sous-jacentes (overlay network). Les messages SIP transitent à travers des serveurs Proxy en charge de les relayer vers la destination finale. Les serveurs Proxy utilisent les serveurs d'enregistrement, appelés Registrar, afin de résoudre les adresses SIP des participants. SIP utilisent le format URI (Unique Resource Identifier) pour les adresses des personnes associées à des terminaux. Ces adressent suivent le même format que les adresses e-mail : user@domain. Les messages de signalisation sont peu nombreux (invite, ok, ack, bye, options) et sont échangés de manière asynchrone entre clients SIP, appelés User Agent (UA).
Le protocole SIP n'étant qu'un protocole de signalisation, il ne prend en charge ni la qualité de service (QoS), ni le transport des flux audio/vidéo échangés par les participants de la session; en général, ce transport est assuré par le protocole RTP (Real-time Transport Protocol, IETF RFC 3550). SIP s'intègre également à d'autres protocoles tels que :
• RTCP (Real-time Transport Control Protocol, IETF RFC 3550), qui fournit des informations dynamiques sur l'état du réseau.
• RTSP (Real-time Streaming Protocol, IETF RFC 2326), pour contrôler la diffusion de flux multimédias en temps réel.
• RSVP (Resource reSerVation Protocol, IETF RFC 2205), pour obtenir des garanties de qualité de service et effectuer des réservations de ressources.
Figure 23 Principes et architecture d'une session SIP
La partie droite de la Figure 23 décrit les interactions nécessaires à l'établissement d'une communication par SIP. Dès que l'appelé est localisé les UAs échangent des messages de signalisations pour négocier les paramètres de la session à établir. La localisation du destinataire et le routage des messages jusqu'à lui est géré de manière transparente par l'infrastructure SIP (Serveurs Proxy et Registrar). La négociation de la session s'effectue par échange de propriétés entre terminaux. Les paramètres possibles sont décrits dans le format SDP (Session Description Protocol, IETF RFC 2327). L'objectif de la négociation est d'établir une session dont les paramètres conviennent pour chaque partie. Ce contrat décrit les paramètres possibles pour chaque type de flux multimédia (e.g., video, audio), le protocole de transfert de flux (e.g., RTP, HTTP, H.320) et le format du flux (e.g., MPEG, H.261), les
adresses IP et les ports d'émission ou de réception. La partie gauche de la Figure 23 montre le format d'une description SDP.
2.1.2 Fonctions avancées pour la mobilité de session
Dans cette section sont exposés les atouts intéressants des spécifications protocolaires attachées au protocole SIP qui sont utiles à la composition contextuelle de services multimédia : les méthodes Re-INVITE et REFER, les mécanismes 3PCC et le contrôle de transcodeurs sont décrits. Ces méthodes sont utilisées dans une des expérimentations de cette thèse et dans les travaux concurrents (cf. section Chapitre II.4.6.2).
Le contrat d'établissement de session peut être renégocié à tout moment grâce à la méthode Re-INVITE. Cette méthode est une méthode INVITE intervenant dans une communication déjà établie. Elle répond aux cas d'utilisations demandant des changements de configuration : ajout ou suppression d'un flux video, mobilité de terminal (en liaison avec l'utilisation du mécanisme 3PCC décrit ci-dessous). Quelques exemples de renégociation de session par utilisation de Re-INVITE avec proposition de paramètres de session différents sont proposés dans le RFC IETF 4317 intitulé "Session Description Protocol (SDP) Offer/Answer Examples". Ce dernier montre que les configurations d'une session gérant de multiples flux est possible. Cette possibilité de session multi-flux est particulièrement pertinente dans les scénarios d'éclatement du terminal de communication en un système constitué de plusieurs équipements domestiques (cf. Chapitre II.4.1.2). Cela nécessite toutefois que les équipements de part et d'autre soient compatibles avec une description SDP à flux multiples. Habituellement, les équipements SIP gère une session constitué d'un flux audio et d'un flux vidéo. Plusieurs flux d'un même type ne sont généralement pas possibles.
Figure 24 Premier mode d'utilisation de la méthode REFER
La méthode REFER (IETF RFC 3515 appelé Call Transfer Protocol) constitue un premier moyen pour réaliser la mobilité de session SIP. La méthode peut être utilisée de deux manières différentes. La différence repose sur le choix du participant pour le rôle de "transféré", soit le participant qui reçoit la requête de transfert d'appel (méthode REFER). Dans le sénario, Alice possède une maison composée d'au moins les deux pièces suivantes : le séjour et la cuisine. Un téléphone SIP est posé dans la cuisine où se trouve Alice au début du scénario. Le séjour est équipé d'un système sophistiqué, constitué d'une télévision et d'un système "home cinema", qui se comporte comme un téléphone SIP sur le réseau. Quant à Greg, il dispose d'un téléphone SIP.
Alice et Bob sont deux participants en cours de communication (1). Alice utilise d'abord le téléphone SIP dans la cuisine. Dans le premier mode d'utilisation de la méthode
REFER (cf. Figure 24), lorsqu'Alice passe dans le séjour (2), une demande de transfert d'appel (méthode REFER) vers l'équipement SIP du séjour est envoyée à Bob par le téléphone de la cuisine (3). Bob envoie donc un message d'invitation à l'équipement du séjour (4), une session est initialisée entre les deux et enfin, le téléphone de la cuisine met fin à sa session avec Greg. Ici le téléphone de Bob joue le rôle de transféré.
Figure 25 Deuxième mode d'utilisation de la méthode REFER
Dans le deuxième cas (cf. Figure 25), lorsqu'Alice passe dans le séjour (2), une demande de transfert d'appel vers le téléphone de Bob est envoyée à l'équipement du séjour par le téléphone de la cuisine (3). Bob est donc invité à initier une session par l'équipement du séjour, et enfin, le téléphone de la cuisine met fin à sa session avec Greg.
Figure 26 Mobilité de session par utilisation du mécanisme 3PCC
La Figure 26 décrit le même scénario de mobilité par utilisation du mécanisme nommé 3PCC (Third-Party Call Control, IETF RFC 3725). Alice et Bob sont en cours de communication (1), ils ont été mis en relation par le contrôleur 3PCC, installé dans la maison de Alice qui est à présent dans la cuisine. Elle utilise donc le téléphone de la cuisine. Lorsqu'elle se déplace dans le séjour, le contrôleur transfère la communication sur l'équipement du séjour (2). Ce dernier procède comme suit : il envoie un message d'invitation (requête INVITE) à l'équipement du séjour (3). Ce message d'invitation ne contient aucune
description de session. A ce message d'invitation il reçoit une réponse OK qui contient la description de session de l'équipement du séjour (4). Le contrôleur envoie un nouveau message d'invitation à Bob avec la description de la nouvelle session envoyée par l'équipement du séjour (5). Ce nouveau message d'invitation correspond à la méthode re-INVITE. Le téléphone de Bob répond OK à la réinvitation avec de nouveau ses paramètres de session (6). Le contrôleur envoie un message d'acquittement (requête ACK) au téléphone de Alice avec les paramètres de session de Bob (7). Ensuite, il envoie un message d'acquittement au téléphone de Bob également (8). Si tout s'est bien passé, le contrôleur envoie enfin une requête BYE au téléphone de Alice situé dans la cuisine(8). La conversation est transférée sur l'équipement du séjour.
Une autre spécification de l'IETF – RFC 4117, Transcoding Services Invocation in the Session Initiation Protocol Using 3PCC – adresse la gestion des différences de capacités des terminaux multimédia. Elle complète le protocole de négociation des paramètres de session attaché au protocole SDP dans le cadre de la gestion de l'hétérogénéité des protocoles de transfert de flux et de format des flux. En effet, si la négociation échoue et montre que 2 terminaux ne possèdent pas de protocoles de transfert et de format des flux communs pour au moins un type de ligne multimédia (e.g., audio, video), il est naturel de mettre en œuvre les capacités de transcodage disponibles sur le réseau. Le RFC 4117 repose sur la définition du contrôle d'un transcodeur par le protocole SIP. La Figure 27 décrit le diagramme d'interaction entre deux participants A et B d'une communication et un transcodeur où l'un des participants est contrôle le transcodeur T. A envoie un message INVITE à B (1) qui, constatant que la description SDP de A n'est pas compatibles avec ses capacités, envoie une INVITE à T avec sa description SDP et celle de A (2). T répond à B avec un message OK lui décrivant sa réponse SDP pour la session entre T et B et la réponse SDP que B doit envoyer à A (3). La première réponse SDP permet la session multimédia entre Tet B, B envoie alors une réponse ACK à T (4). B envoie la 2ème réponse SDP dans un message OK à A (5) qui répond ACK à B (6). Les paramètres SDP donnés à A dirige les flux de A à l'adresse de T. Les flux établis finalement entre A et B passent par les traitements du transcodeur T.
Figure 27 Interaction avec un transcodeur contrôlable par le protocole SIP