1. Introduction

Le protocole SIP (Session Initiation Protocol) est, comme son nom l'indique un protocole d'initialisation de session multimédias. C'est un protocole jeune mais qui a le "vent en poupe" car soutenu par bon nombre d'industriels qui travaillent à son élaboration et à son développement. C'est le protocole qui devrait être retenu pour l'établissement des communications type visioconférence sur UMTS (mobiles de troisième génération).

 2. Le monde de la visioconférence

Les premières recherches en matière de systèmes de visiophonie remontent aux années 1970. En France, Matra a développé le premier visiophone en 1973.

 

Dans ce domaine émergeant, le besoin de normalisation s'est avéré rapidement nécessaire.

 

L'utilisation du RNIS comme réseau de support de la visioconférence date de 1993 et a marqué le début d'un réel développement de son usage et du nombre de terminaux.

 

La recommandation H.320 de l'UIT (Union Internationale des Télécommunications) spécifie les caractéristiques techniques des systèmes et équipements de visioconférence basés sur le RNIS.

 

La norme H.320 a ensuite été déclinée pour les différents types de support réseaux afin de donner la série de normes H.32x. On peut notamment citer :

 

»    H.321, le portage pur et simple de H.320 sur les réseaux ATM,

 

»    H.322, une autre forme de portage simple de H.320 sur le réseau Ethernet à débit garanti,

 

»    H.323, le portage de H.320 sur des réseaux de type IP,

 

»    H.324, concernant le réseau téléphonique commuté (RTC)

 

»    H.324M, la visiophonie pour les téléphones mobiles.

 

Développée à l'origine pour les réseaux locaux sans garantie de service, H.323 décrit les spécifications techniques nécessaires au transport des flux audiovisuels. H.323 est donc particulièrement adaptée aux réseaux informatiques des entreprises.

 

H.323 est une norme multimédia permettant de transporter de l'audio et de la vidéo entre deux personnes (lors d'une liaison point à point) ou plusieurs personnes (lors d'une liaison multipoints). Par contre, elle ne définit ni les interfaces réseaux, ni les protocoles sous-jacents.

 

La visioconférence sur réseaux IP utilise donc dans la quasi-totalité des cas la norme H.323 car c'est une norme éprouvée qui s'est de plus étoffée pour pouvoir répondre aux besoins et aux attentes des opérateurs Télécom et autres fournisseurs de service.

 

Actuellement la plupart des équipements de visioconférence répondent aux recommandation de H.323 ou de H.320 .

 

3. Présentation du protocole SIP (Session Initiation Protocol)

3.1 Généralités

A l'origine, SIP (Session Initiation Protocol) a été spécifié par le groupe de travail MMUSIC (Multiparty Multimedia SessIon Control) de l'IETF(Internet Engineering Task Force) dans la RFC 2543 en mars 1999. En septembre 1999 l'IETF a créé le groupe de travail SIP pour poursuivre ces travaux de spécification. SIP est un protocole conçu pour être un protocole de pure signalisation, suivant ainsi le credo de l'IETF «Un problème, un protocole».

 

Les principales fonctions d'un protocole de signalisation sont :

 

»      localiser un terminal

 

»      contacter un terminal pour déterminer sa volonté d'établir une session

 

»      échanger des informations sur les média pour permettre l'établissement d'une session

 

»      modifier des sessions media existantes

 

»      clore une session média existante

 

SIP peut être utilisé pour le contrôle de conférences multimédia, d'appels téléphoniques sur IP et bien d'autres types de communications. Les communications peuvent être en unicast (l'expéditeur envoie un flux par destinataire) ou en multicast (l'expéditeur envoie un flux vers les réseau et le réseau le duplique pour le faire parvenir à tous les destinataires). Les participants sont des utilisateurs finaux, des serveurs de media (audio, vidé…), des serveurs de pure signalisation SIP,ou bien des passerelles vers d'autres réseaux.

 

 

Le protocole est bâti sur une architecture Client/Serveur et utilise des messages textuels. Les messages sont transportés par les protocoles de transport réseaux TCP ou UDP. Le message possède un en-tête et un corps.

 

L'en-tête définit les paramètres nécessaires au routage du message et à l'établissement de la session. Le corps définit les caractéristiques de la session à l'aide d'un protocole de description de session. Le protocole recommandé (mais non obligatoire) est SDP (Session Description Protocol) également défini par MMUSIC dans la RFC 2237. On remarquera que les parties établissement de session et description de session sont séparées (mais coopèrent).

 

Un autre protocole est enfin utilisé pour propager le flux d'information sur le réseau. Le protocole conseillé mais non obligatoire est RTP/RTCP (Real-Time Protocol / Real-Time Control Protocol).

 

RSVP : réservation des ressources réseaux sur IP avec une excellent qualité de service (QoS).

 

RTP (Real-time Transfert Protocol) : transport des informations en temps réel avec une excellent QoS.

 

RTCP (Real-Time Control Protocol) : assure le contrôle de flux de données multimédia.

 

SDP (Session Description Protocol) : décrit les sessions multimédia.

 

Il faut savoir que le protocole SIP est pour l'instant moins utilisé que le protocole H.323 car il est beaucoup plus récent. Mais il se développe très rapidement et sa simplicité de mise en oeuvre lui confère un réel avantage. La plupart des grands constructeurs travaillent maintenant sur ce protocole. De plus, de nombreux « Internet-Drafts » IETF apportent des améliorations à ce protocole. Le fait de travailler sur ce protocole a  aussi été une des raisons de mon choix de projet car c'est un protocole prometteur qui s'insère parfaitement dans le mouvement émergeant de convergence des réseaux téléphonique vers les réseaux IP.

 

3.2 Les adresses SIP

Les adresses SIP se présentent sous la forme suivante:

 

 

Les Infos_utilisateur sont sous la forme:

    « nom utilisateur : mot de passe » ou « numéro de téléphone »

        sachant que le mot de passe est facultatif.

 

La partie domaine est sous la forme:

    « nom de domaine (univ-mlv.fr) ou adresse IP : port »

        ici aussi, le port est facultatif.

 

L'architecture SIP comprend deux types de composants : les « User Agent » (Agents utilisateurs) et les Serveurs.

  

3.3 Les User Agent

Le premier type de composant SIP est l'application de l'utilisateur final. Ce peut être, par exemple, un terminal de téléphonie ou de visioconférence sur IP, un serveur audio ou vidéo ou encore une passerelle vers un autre protocole. Ce type de composant est appelé User Agent (UA). Il se décompose en une partie cliente et une partie serveur. La partie cliente, appelée User Agent Client (UAC), envoie les requêtes SIP, et la partie serveur, appelée User Agent Server (UAS), les reçoit. Le principal objectif de SIP est de permettre l'établissement de sessions entre User Agents.

 

Exemple d'établissement d'une session SIP entre deux User Agents.

Cette figure représente les échanges qui ont lieu entre deux UA pour l'établissement d'une connexion. Ce cas est le plus simple car les deux UA connaissent l'adresse IP de leur interlocuteur c'est pourquoi ils peuvent se joindre directement.

 

Pour joindre un autre utilisateur, il est nécessaire de connaître son adresse SIP. Les utilisateurs, dans un environnement SIP sont identifiés par des URLs (Uniform Resource Locators). Les format d'un URL SIP est similaire à celui d'une adresse e-mail, généralement constituée d'un nom d'utilisateur et d'un domaine séparé par un « @ ». La forme d'un URL SIP est  donc : « SIP:loic.debourdeau@francetelecom.com ».

 

 

Dans l'exemple précédent, si nous consultons le serveur SIP qui administre le domaine où se trouve Bob (par exemple compagny.com) nous trouverons un utilisateur dont l'identifiant serait par exemple Bob.Johnson. L'URL de Bob pourrait être « sip:Bob@131.160.1.112 » ce qui indiquerait que l'équipement sur le réseau dont l'adresse IP est 131.160.1.112 possède un utilisateur identifié par le nom Bob.

 

3.4 Serveur Registrar

Afin de pouvoir joindre une personne à partir de son adresse SIP, une entité dans le réseau doit maintenir une correspondance (mapping) entre les adresses IP et les adresses SIP : c'est le rôle du serveur Registrar. Un utilisateur peut donc changer d'adresse, il lui suffit de s'inscrire auprès du Registrar en lui indiquant son adresse SIP et son adresse de machine sur le réseau.

 

 

 

 

Exemple d'enregistrement SIP.

 

Cette Figure montre l'enregistrement du terminal d'Amparo sur un serveur Registrar. A la réception du message REGISTER, le serveur Registrar a accès à l'adresse IP de la source, Amparo, dans l'en-tête IP du message. Il enregistre alors la correspondance entre cette adresse IP et l'adresse SIP donnée dans le champ « Contact : » , soit ici « sip:amparo@milano.it ».

 

3.5 Location Serveur

Lorsqu'une entité SIP souhaite joindre un correspondant à partir de son adresse SIP, elle est renseignée par le Location server qui accède à la base d'information renseignée et tenue à jour par le Serveur Registrar.

 

Donc lorsqu'un serveur proxy recevra un message INVITE destiné à Amparo, le Location Server lui indiquera l'adresse IP d'Amparo et le Proxy Server routera le message vers l'adresse IP appropriée.

 

On remarque dans les usages que le serveur Registrar est souvent associé au serveur Proxy et que le Location Server est, le plus souvent une entité logique.

3.6 Serveur Proxy

Un serveur proxy a la charge de router les messages SIP. Il a uniquement un rôle dans la signalisation et il ne gère pas de media. Il n'est en général à l'origine d'aucune requête exceptée la requête CANCEL utilisée pour libérer une session pendante.

 

 

 

Représentation schématique des flux SIP et des flux media lors de l'utilisation d'un serveur proxy.

 

 

Cette figure schématise, dans le cas de l'établissement d'une session grâce à un serveur proxy, la séparation de la partie signalisation et de la partie flux media. Le proxy peut se contenter de router les messages SIP vers l'opérateur sélectionné. Le « dialogue » SIP fournira aux deux terminaux (celui du client1 et celui du client2) les données nécessaires à l'établissement d'une session de media entre eux. Ces données sont entre autres leurs adresses IP respectives, les ports et les formats de codages utilisés. Les deux terminaux peuvent alors s'envoyer des flux média sans passer par le serveur proxy ce qui en allège la charge.

  

Exemple  d'appel SIP avec en serveur proxy en mode Stateless.

 

Cette figure présente un exemple d'établissement d'appel avec un serveur proxy SIP. Dans le cas présent, Amparo ne connaît pas l'adresse exacte de Lorenza, il ne connaît qu'une adresse SIP (appelée URL SIP) qui ressemble à une adresse e-mail : « sip :lorenza@ft.com ». Le proxy va recevoir l'appel (message INVITE), se charge de faire la correspondance avec l'adresse IP de la machine sur laquelle est connectée Lorenza et lui transmet le message ou le fait suivre vers un autre proxy plus apte à trouver Lorenza. Amparo n'a donc pas à connaître l'adresse IP exacte de Lorenza, seul l'adresse du proxy suffit. Ce système est très utile car il permet à un utilisateur de changer de machine ou de lieu sans avoir aucun problème de changement d'adresse.

 

Le serveur proxy en mode Statefull route les paquets et n'a aucune implication dans l'échange de flux média qui suit. Dans cet exemple on peut constater qu'une fois les premiers messages échangés, les UA s'envoient directement leurs messages sans passer par le proxy. C'est une fonctionnalité fournie par SIP qui permet aux UA de se donner leurs adresse sip finales (dans un champ nommé « Contact : »). Lors de la requête suivante les UA peuvent alors se joindre directement. Cependant le proxy peut forcer toutes les requêtes suivantes d'une session à passer par lui (en ajoutant son adresse dans le champ nommé « Record-Route : »).

 

Fonctionnement du Proxy SIP en monde Statefull

 

Un des intérêts de ce type de fonctionnement est de pouvoir garder une trace des temps de communication en vue de faire des statistiques sur les usages ou de mettre en place une facturation basée sur le temps de communication. Un autre intérêt de ce fonctionnement est qu'il offre la possibilité de contrôler le nombre de communication entre deux domaines et donc l'opportunité de pouvoir contrôler la bande passante sur certains liens (nécessaire pour pouvoir offrir une garantie de service).

 

 

 

Un type particulier de serveur proxy, appelé serveur forking proxy, peut dupliquer une requête et l'envoyer vers plusieurs destinataires. Ces serveurs peuvent par exemple être utilisés pour contacter plusieurs terminaux appartenant à la même personne.

 

 

3.7 Serveur Redirect

Les serveurs Redirect aident à localiser les User Agent SIP en fournissant une adresse alternative à laquelle l'utilisateur appelé peut être joint.

 

Lorsqu'une requête lui parvient, il retourne une réponse de redirection contenant la ou les prochaines adresses à contacter pour joindre le destinataire final.

 

Exemple de fonctionnement de serveurs SIP Redirect

 

Dans cet exemple, Laura désire appeler Bob. Sur son terminal, elle clique sur le bouton d'appel de Bob. Le terminal essaie d'abord de joindre Bob à son adresse publique (sip:Bob.johnson@compagny.com). Le domaine « compagny.com » a un serveur SIP Redirect qui sait que si Bob n'est pas enregistré dans le domaine compagny.com, il est peut-être joignable à l'université dont le domaine est umlv.com. Le serveur SIP Redirect indique donc au terminal de Laura qu'il doit essayer de contacter Bob à l'adresse SIP :Bob@umlv.com. Dans le domaine umlv.com est aussi présent un serveur SIP Redirect qui indique au terminal de Laura qu'il doit essayer de joindre Bob à l'adresse SIP :Bob@workstation1234.umlv.com. La communication peut alors s'établir comme on a vu précédemment.

La localisation de Bob Johnson est établie grâce aux informations contenues dans les Serveurs SIP. Tout ce système de recherche du destinataire est totalement transparent pour les utilisateurs, ce qui est très attrayant car la mobilité est de plus en plus présente dans le monde industriel.

 

4. Structure d'un message SIP

Voici deux exemple (les plus simples possible) d'en-tête de message SIP:

Première ligne : indication du type de message (INVITE) puis adresse SIP de l'expéditeur et version du protocole utilisé

La seconde et la troisième ligne indiquent les entités SIP traversées par le message avec le numéro de port d'écoute, ce champs est important pour que les réponses puisent emprunter le même chemin (au niveau SIP et pas nécessairement au niveau des liens physiques).

Les champs To et From indiquent respectivement l'adresse de l'expéditeur et celle du destinataire entre "<>" avant l'adresse il est possible (comme ici de mettre un nom d'alias pour la personne.

Le champs Call-ID permet d'identifier de manière unique la communication.

CSeq indique le type de message et son numéro de séquence.

Content-Type : le type d'application.

Content-Length : taille de l'en-tête.

 

Le second message est un message d'acquittement (200 OK). Dans ce message, les champs du message qu'il acquitte ont étés recopiés.

 

5. Méthodes et codes d'erreur

5.1 Principales Méthodes

Les principales Méthodes de SIP sont au nombre de 6 : ACK, INVITE, OPTION, BYE, REGISTER et CANCEL.

 

ACK : acquittement des messages

INVITE : invitation à une session multimédia

OPTION : permet d'indiquer un certains nombre de paramètres permettant notamment de pouvoir faire de gestion de présence sur le réseau (fonction très utilisée par le Messenger de Microsoft)

BYE : Met fin à une session en cours

REGISTER : enregistrement d'une entité auprès du serveur Registrar

CANCEL : met fin à une session pendante

 

5.2 Codes d'erreur

Les codes d'erreur (tels que le numéro 200 du message OK du paragraphe précédent) sont classés de la manière suivante:

Codes 1xx : Information

Code 200 : OK = succès

Codes 3xx : Redirection

Codes 4xx : Erreurs du client

Codes 5xx : Erreurs du serveur

Codes 6xx : Erreurs générales

6. Diagramme d'état de l'UAS et de l'UAC

 

 

7. Conclusion

 

SIP est un protocole décrit dans le RFC 2543 rendu obsolète depuis le mois de juillet 2002 par le RFC 3261. Ce protocole est encore jeune mais étant donné qu'un grand nombre de constructeurs tavaillent dessus, il se peut qu'il cohabite fortement avec les standards utilisé jusqu'alors (principalement H323). Un autre protocole denommé MGCP/MEGACO  à été développé par HSS (Hughes Software Systems) et standardisé par l'IETF (RFC 3015) et par l'ITU-T (H248), celui ci est déjà implanté dans le boîtier "freebox" distribué par Free en France. SIP reste néanmoins un protocole "à la mode" et seul l'avenir nous dira si il tient ses promesses.

 

8. Liens

 

Les RFC décrivant SIP:

http://www.ietf.org/rfc/rfc2543.txt

http://www.ietf.org/rfc/rfc3261.txt
 

Beaucoup d'informations:
http://www.cs.columbia.edu/sip/
 

Un bon document en français:
http://www.chez.com/jaaayyy/html/ProjetSIP/SommaireSIP.html
 

Site de l'ITU :
http://www.itu.int/home/index.html

 

 

Pour toute information vous pouvez me contacter : loic_debourdeau@yahoo.fr