Protocole SIP

Présentation

Le protocole SIP (Session Initiation Protocol) est un standard décrit dans les RCF 2543 et 3261 au sein de l’IETF (Internet Engineering Task Force).
Comme son nom l’indique, le protocole SIP permet de créer des sessions interactives entre plusieurs entités (poste à poste, client/serveur).
La création et l’utilisation de ces sessions impliquent un ensemble de fonctionnalités auxquelles le protocole SIP répond :

o Localisation : SIP utilise les URI (Uniform Resource Indicator) afin de localiser les utilisateurs au sein d’un réseau. La syntaxe utilisée est courante car elle reprend celle des adresses e-mail (par exemple sip:mohadina@elv.telecom-lille1.fr). Au préalable, l’usager s’enregistre auprès d’un serveur SIP via une requête afin d’être joignable.

o Négociation : Avant que la session ne soit créée, les usagers doivent négocier les informations qui vont être échangées. Ils pourront choisir le type de médias (vidéo, voix, texte…) selon un ordre de priorité des CODECs dépendant des terminaux de chacun des usagers. Cette partie là est spécifique au protocole SDP (Session Description Protocol)

o Contrôle : une fois la session initiée, il faut pouvoir intervenir sur son déroulement et la terminer. Il est possible de faire face à un changement de terminal et par conséquent à une renégociation des médias en jeu. Cette négociation est considérée comme un mécanisme résultant du contrôle.

Il est à noter que le transport des informations telles que le son et la vidéo ne sont pas pris en charge par SIP mais il est spécifique au protocole RTP (Real Time Protocol).

Le protocole SIP se situe au niveau applicatif au dessus du protocole IP. En conséquence, il est indépendant de la couche transport. En effet, il fonctionne avec de nombreux protocoles fiables (TCP, STCP) ou non fiables (UDP), sécurisées (TLS sur TCP, IPSec). La majorité des implémentations du protocole SIP communiquent en utilisant le protocole UDP. Le protocole SIP est un protocole textuel par opposition à binaire et est conçu de telle sorte que les messages soient facilement lisibles tel que l’utilisation de http 1.1.
Le protocole SIP encapsule des données dont il ne connaît pas la signification. En effet, aussi bien dans la téléphonie sur Internet mais aussi dans la vidéoconférence, le protocole SIP est utilisé en corrélation avec le protocole SDP ; ce dernier permet de décrire les capacités des terminaux vis-à-vis des médias supportés en émission et en réception. SDP joue le rôle de support lors du processus préalable de négociation de la communication.

Les applications SIP

SIP reprend les mêmes règles utilisées dans la téléphonie RTC (Réseaux Téléphonique Commuté). En effet, l’objectif de SIP est de localiser une ressource ou un terminal SIP de la même manière qu’on utilise les numéros de téléphones dans le RTC. SIP fournit des URI préfixées de « sip : » (SIP fournit des URI préfixés : exemple « sip : ») pour indiquer qu’elles appartiennent au protocole SIP et pour se démarquer des URI utilisées sur des applications Internet les plus utilisées le web et le mail exple http : ou mail to :
A l’inverse des numéros de téléphone, les adresses SIP désignent une entité plutôt q’un terminal. Cette différence est fondamentale car les adresses représentent un individu quelque soit sa localisation physique et quelque soit le terminal à sa disposition. La première application de SIP est de permettre à deux personnes de se contacter, indépendamment de leur localisation et de leur terminal.

SIP permet de mettre en œuvre les services déjà proposés par la téléphonie classique :

o La mise en attente ou en garde d'un appel
o Le transfert d'appel
o L'obtention d'informations sur l'appelant

Mais également des services plus complexes, comme notamment :

o La téléconférence
o Les messages instantanés
o Le filtrage d'appel (en général suivant des préférences utilisateur)
o La facturation

De plus, SIP propose aussi des fonctionnalités liées aux problèmes informatiques

o Enregistrer des entités SIP (téléphones, PDAs, ordinateurs)
o Authentifier, habiliter et gérer des comptes utilisateur
o Obtenir l'IP de l'autre point de la communication
o Router les requêtes au serveur approprié
o Permettre la mobilité de réseau et de terminal
o Enregistrer, filtrer et publier de l'information de présence (disponible, occupé, etc.)
o Informer les utilisateurs de l'évolution d'une communication, de son succès ou de son échec.
o Transmettre des requêtes de qualité de service ‡ d'autres éléments du réseau

Architecture SIP

L’architecture de SIP comporte les entités principales suivantes:

o Les agents SIP (UAC) : Application du visiteur qui lance et envoie des demandes de SIP.
o Les serveurs SIP (UAS) : Reçoit et répond aux demandes de SIP au nom des clients : accepte, réoriente ou refuse des appels.
o Serveur Proxy : Entre en contact avec un ou plusieurs clients ou serveurs du prochain saut et passe les demandes d'appel plus loin. Contient UAC et UAS.
o Serveur redirect : Accepte des demandes de SIP, trace l'adresse dans des adresses zéro ou plus récentes et renvoie ces adresses au client.
o Serveur localisation : Fournit des informations au sujet des endroits possibles d'un visiteur pour le réorienter aux serveurs Proxy. Peut Co-être placé avec un serveur de SIP.
o Terminal SIP : Soutient la communication en temps réel et bidirectionnelle avec une autre entité de SIP.

Ces entités interagissent entres elles afin de localiser un usager au sein d’un réseau et permettre des services qui sont définis dans les extensions de SIP.

Les messages SIP

Les messages se composent de requêtes et de réponses qui sont échangés au format texte. Chaque message contient une adresse (URI), un ensemble d’en-tête, et un corps.

Exemple d’un message SIP initiant une communication : INVITE

Les messages SIP sont échangés entre deux entités sur un mode client/serveur. En effet, l’entité appelante émet une requête vers l’entité appelée. Celle-ci répondra par un autre message envoyé à l’appelant. Dans ce contexte, l’appelant est considéré comme un UAC et l’appelé comme un UAS et l’échange de message comme une transaction.

La figure 1 illustre l’établissement d’une communication entre deux individus disposant de terminaux SIP, et permet d’observer les transactions qui s’opèrent entre eux.

D’après le modèle client/serveur, les messages sont classés en deux catégories :

o Les requêtes : Elles constituent les messages définissant la qualité de la transaction (invitation, demande d’information, souscription etc.…).
Les échanges entre un terminal appelant et un terminal appelé se font par l’intermédiaire de requêtes :

_ INVITE : cette requête indique que l’application (ou utilisateur) correspondante à L’URL SIP spécifié est invité à participer à une session. Le corps du message décrit cette session (par ex : média supportés par l’appelant ). En cas de réponse favorable, l’invité doit spécifier les médias qu’il supporte.

_ ACK : permet de confirmer que le terminal appelant a bien reçu une réponse définitive à une requête INVITE.

_ OPTIONS : un proxy server en mesure de contacter un terminal appelé, doit répondre à une requête OPTIONS en précisant ses capacités à contacter le même terminal.

_ BYE : cette requête est utilisée par le terminal de l’appelé à fin de signaler qu’il souhaite mettre un terme à la session.

_ CANCEL : cette requête est envoyée par un terminal ou un proxy server à fin d’annuler une requête non validée par une réponse finale :
Si une machine ayant été invitée à participer à une session, et ayant accepté l’invitation ne reçoit pas de requête ACK, alors elle émet une requête CANCEL.

_ REGISTER : cette méthode est utilisée par un client pour enregistrer son adresse
auprès du serveur auquel il est relié.

o Les réponses : Elles constituent les informations renvoyées par le serveur au client ou par le client au serveur et concernent autant l’évolution de la transaction que les erreurs pouvant survenir (transport, serveur, client, etc.). On distingue les réponses provisionnelles, qui donnent une information optionnelle, et les réponses finales qui clôturent une transition.
Une transaction SIP est initiée par une requête, suivie d’une ou plusieurs réponses provisionnelles
Certaines transactions sont conclues par un acquittement permettant de s’assurer de la clôture de la transaction.

_ Réponses provisionnelles

- 1XX : provisoire/informationnelle, le traitement de la requête est en cours.

* Réponse 180 Ringing : le terminal demandé sonne.
* Réponse 183 Session Progress : l’appel est en cours
* Cas particulier du 100 Trying qui indique que la requête a été reçue par l’élément suivant.

_ Réponses finales

- 2XX : succès : la requête a été bien reçue, comprise et acceptée,

* Réponse 200 OK: le terminal a décroché.

- 3XX : redirection vers une autre entité. D’autres actions doivent être entreprises pour continuer le traitement.

- 4XX : erreur client. La requête est syntaxiquement erronée ou n’a pas pu être traitée avec succès, a été bien reçue, comprise et acceptée.

* Réponse 422: session timer too small

- 5XX : erreur serveur : le serveur n’a pas su traiter une requête.

* Réponse 500 : le nom de domaine du serveur est inconnu.

- 6XX : erreur générale : la requête ne peut être traitée par aucun serveur.

Paramètres

Les messages SIP respectent toujours la même structure générale, sans considérer les mots-clés spécifiques dans l'en-tête, et peuvent être globalement décrits sans prendre en compte s'ils sont produit par un user-agent ou un proxy.

Un message typique SIP contient les champs suivants (l'exemple est un message INVITE) :

Message Content Description

SIP content
INVITE sip:user2@contact.org SIP/2.0 Header with Request-URI
Via: SIP/2.0 / UDP gate.home.org:5060;branch=a9n3j8fu7
SIP version number – Transport Protocol Hostname : Port Number ; Transaction Id
Max-Forwards: 70 Max number of hops
To: User Two Destination
From: User One ;tag=91202 Originator – Random Tag Identifier
Call-ID: 123456789@gate.home.org Id of SIP session
CSeq: 1 INVITE Command Sequence
Subject: Hello World...
Contact:
Content-Type: application/sdp
Content-Length: 123 Total number of characters including CRLF

SDP content
v=0 Version Number
o=User1 1928374650 1928374650 IN IP4 gate.home.org Origin with Name
s=Phone Call Subject
c=IN IP4 192.168.0.1 Connexion Address
t=0 0 Time
m=audio 50121 RTP/AVP 0 Media Format - Port Number - Transport Protocol
a=rtpmap:0 PCMU/8000 Attributes – Media Encoding

Les champs VIA, MAX-FORWARDS, TO, FROM, CALL-ID, CSEQ sont le contenu minimum nécessaire pour n'importe quel message SIP. Le calcul de la longueur du contenu commence juste aprés cette ligne et est l'addition de tous les caractères au delà de ce point (CRLF y compris). En cas d'ACK ou de message BYE la longueur du contenu est zéro.

Les messages répondus emploieront le même format mais la destination modifiera l'information selon le contexte :

- Ajouter le contenu à la fin du champ VIA: ";received=192.168.0.1"
- créer son propre numero d'étiquette qui était absent sur le précédent champ
- mettre à jour le contenu particulièrement l'HEADER

haut de page