Vous êtes sur la page 1sur 13

SIP

Session Initiation Protocol

Introduction ..............................................................................................................3
SIP (Session Initiation Protocol) ...............................................................................3
2.1
But ....................................................................................................................3
2.2
SIP URI (Uniform Resource Identifier)...............................................................3
2.3
Elments rseaux du SIP..................................................................................3
2.3.1
User Agents (UA) .......................................................................................3
2.3.2
Serveur Proxy ............................................................................................4
2.3.3
Registrar ....................................................................................................4
2.3.4
Redirect Server ..........................................................................................4
2.4
Messages SIP...................................................................................................5
2.5
Transaction SIP ................................................................................................7
2.6
Dialogue SIP .....................................................................................................8
2.7
Scnarios SIP typiques .....................................................................................8
2.7.1
Inscription ..................................................................................................8
2.7.2
Invitation la session.................................................................................8
2.7.3
Fin de la session ........................................................................................9
2.7.4
Record routing ...........................................................................................9
2.7.5
Strict versus loose routing ........................................................................10
2.7.6
Souscription un vnement et notification .............................................10
2.7.7
Messages instantans .............................................................................11
3 Conclusion .............................................................................................................12
4 Rfrences.............................................................................................................13

1
2

1 Introduction
Ce document dcrit les grandes lignes de la Session Initiation Protocol SIP. Nous allons
voir dans les diffrentes sections le but du SIP, les diffrentes entits qui le composent,
le format de message quil utilise. Nous allons galement dfinir ce que cest une
transaction, dialogue SIP pour enfin voir un scnario typique du SIP.

2 SIP (Session Initiation Protocol)


2.1 But
SIP est un protocole de contrle de la couche application. Ce protocole (bas sur le
protocole http : hypertext transfert protocol) est utilis pour crer, modifier et terminer
des sessions. Une session est lensemble d'
metteur et rcepteurs qui communiquent
entre eux ainsi que l'
tat conserver pendant la communication. Une session peut
inclure des appels tlphoniques Internet, une distribution multimdia, une confrence
multimdia avec un participant ou plus.
But du SIP:
Rendre la communication possible. La communication elle-mme doit tre
accomplie par un autre moyen. Les 2 protocoles utiliss le plus souvent avec SIP
sont RTP (Real Time Transport) et SDP (Session Data Point), lequel est utilis
pour dcrire et encoder les capacits des participants de la session.
SIP est utilis pour transporter la description des paramtres de la session. Cette
description est encode dans un document qui utilise SDP.

2.2 SIP URI (Uniform Resource Identifier)


Un SIP URI est de la forme sip :username@domain.

2.3 Elments rseaux du SIP


2.3.1 User Agents (UA)
Les UAs sont des end points Internet qui utilisent SIP pour se trouver et pour ngocier
une session. Habituellement, les UAs rsident sur l'
ordinateur d'
un utilisateur comme
application, mais peuvent tre aussi un tlphone cellulaire, PSTN (Public Switched
Telephone Network), PDAs (Personal Digital Assistant)...
Chaque UA contient un UAC (User Agent Client) et un UAS (User Agent Server) :
UAC: partie d'
UA qui envoie la requte et reoit la rponse.
UAS: partie d'
UA qui envoie des rponses et reoit la requte.

2.3.2 Serveur Proxy


Le proxy excute lacheminement d'
une invitation une session - d'
aprs l'
emplacement
de lactuel invit -, lauthentification, la comptabilit... Il existe deux types de serveur
proxy :
Serveurs stateless : ils acheminent les messages indpendamment les uns des
autres, ils ne prennent pas soin des transactions.
Serveurs stateful : ils maintiennent ltat des requtes pour la dure de la
transaction. Ils absorbent la rediffusion, et ils peuvent excuter des mthodes
plus compliques pour trouver un utilisateur.

2.3.3 Registrar
Un registrar est une entit qui reoit les inscriptions des utilisateurs. Elle extrait
linformation au sujet de lemplacement (adresse IP, port, username) de ces utilisateurs
et lentrepose dans une base de donnes : la location database. L'
UA doit rafrachir
rgulirement son inscription.

Figure 1- Vue d'ensemble du registrar

2.3.4 Redirect Server


Un redirect server est une entit qui reoit une requte et renvoie une rponse. Il reoit
des requtes et cherche le destinataire prvu dans la location database cre par un
registrar. Il cre alors une liste d'
emplacements courants des utilisateurs et l'
envoie
l'
initiateur de la requte dans une rponse classe 3xx. L'
initiateur de la requte extrait la
liste des destinations et leur envoie directement une autre requte.

Figure 2 - Racheminement

2.4 Messages SIP


La communication qui utilise SIP (souvent appel signalling) comprend une srie de
messages. Les messages sont soit une requte d'
un client un serveur soit une
rponse d'
un serveur un client. Les messages peuvent tre transports
indpendamment par le rseau.
Requtes: utilises pour commencer des actions ou informer un destinataire de
la requte.
Rponses: utilises pour confirmer qu'
une requte a t reue et traite, ou pour
indiquer le statut du traitement.
Format dun message gnrique :

start-line
*message-header
CRLF
[message-body]

En dtail:
start-line = Request-line/Status-line
Requtes

start-line = Request-line

Request-line =

Methods (sp) Request-URI (sp) SIP-Version


REGISTER
INVITE
ACK
CANCEL
BYE
OPTIONS

Rponses

: lie une adresse permanente lemplacement courant


:
:
:
:
:

commence une session


confirme ltablissement de la session
annule un pending INVITE
termine la session
demande au serveur ses capacits

start-line = Status-line

Status-line = SIP-Version (sp) Status-Code (sp) Reason-Phrase


Status-code : code de 3 nombres entiers qui est le rsultat d'
une tentative de
comprhension et de satisfaction dune requte.
Il y 6 classes de rponses :
1xx :

Provisoire

la requte a t reue, et est en train dtre traite.

2xx:

Succs

3xx :

Racheminement

100 Trying, 180 Ringing, 181 Call is being forwarded

l'
action a t reue avec succs, comprise et accepte.

200 Ok

des actions supplmentaires sont ncessaires afin de


complter la requte.

300 Multiple choice, 301 Moved permanently,


302 Moved temporarily

4xx:

Erreur client

la requte contient une mauvaise syntaxe ou ne peut pas tre


accomplie sur ce serveur.

400 Bad request, 401 Unauthorized, 482 Loop detect,


486 Busy here

5xx:

Erreur serveur

6xx :

chec global

le serveur a chou laccomplissement dune requte


apparemment valide.
la requte ne peut tre accomplie par aucun serveur

La Reason-Phrase est prvue pour donner une courte description textuelle du Statuscode.

2.5 Transaction SIP


Transaction: squence de messages SIP (une requte et toutes les rponses cette
requte) changs entre les diffrents lments du SIP.

Si une transaction avait t commence par une requte INVITE, alors la mme
transaction inclut aussi lACK, mais seulement dans le cas o la dernire rponse n'
tait
pas une rponse de la classe 2xx. Si la dernire rponse tait une rponse 2xx, alors
l'
ACK n'
est pas considr comme faisant partie de la transaction.
Une transaction a un aspect client client transaction - et un aspect serveur server
transaction -, qui changent en fonction de lactivit un moment donn.
Client transaction : reoit la requte d'
un TU (Transaction User) qui est un UA ou
un stateful proxy, et dlivre la requte un serveur de transactions.
Server transaction : reoit la requte de la couche transport et la dlivre au TU.
Filtre toute rediffusion de la requte, accepte la rponse du TU et la dlivre la
couche transport
Un stateless proxy na ni un client, ni un serveur de transaction. La transaction
existe entre l'
UA ou un stateful proxy dun ct, et l'
UA ou un stateful proxy de lautre
ct.

Figure 3 - transaction SIP

2.6 Dialogue SIP


Les dialogues sont identifis en utilisant le call-ID, ltiquette From et ltiquette To.
Les messages dont ces 3 champs sont respectivement identiques appartiennent un
mme dialogue.

Figure 4 - Dialogue SIP

2.7 Scnarios SIP typiques


Cette section donne une brve vue d'
ensemble de scnarios SIP typiques qui
habituellement composent la circulation SIP.

2.7.1 Inscription
Comprend un message REGISTER suivi par un 200 Ok envoy par le registrar si
l'
inscription est russie.

2.7.2 Invitation la session


Une requte INVITE est envoye habituellement un proxy. Un 200 Ok est produit une
fois que lappel prend le tlphone. La session est tablie au moment o lappel reoit
lACK de lappelant.

Figure 5 - Flux du message INVITE

2.7.3 Fin de la session


La fin de la session est faite en envoyant une requte BYE dans le dialogue tabli par
INVITE. Les messages BYE sont envoys directement dun UA l'
autre moins qu'
un
proxy soit sur le chemin (path) de la requte INVITE, indiquant qu'
il est souhait rester
sur le chemin dfini dans le record routing.

2.7.4 Record routing


Toutes les requtes dans un dialogue sont envoyes, par dfaut, directement d'
un UA
l'
autre. Seules les requtes hors du dialogue traversent le proxy.
Un tel proxy insrerait le champ en-tte Record-route dans les messages SIP. Les
messages envoys dans un dialogue traverseront alors tous le proxy SIP qui a mis un
champ en-tte Record-route dans le message.

Figure 6 - Flux du Message BYE avec et sans Record routing

2.7.5 Strict versus loose routing


Strict routing : sauve le request-URI original comme le dernier champ de l'
en-tte
de la Route.
Loose routing : le request-URI contient toujours lURI de lUA de la destination.
S'
il ny a aucun en-tte du champ Route dans un message, le message est
envoy l'
URI du Route le plus lev.

2.7.6 Souscription un vnement et notification


La spcification du SIP a t tendue pour supporter un mcanisme gnral qui autorise
la souscription aux vnements asynchrones. De tels vnements peuvent inclure un
changement statistique du proxy SIP, une information sur la prsence, un changement
au niveau de la session etc. Ce mcanisme est utilis principalement pour transmettre
de l'
information sur la prsence de lutilisateur.

Figure 7 - Souscription aux vnements et notification

2.7.7 Messages instantans


Les messages instantans sont envoys en utilisant une requte MESSAGE. Ces
requtes n'
tablissent pas de dialogue et par consquent ils traverseront toujours le
mme ensemble de proxy. C'
est la forme la plus simple pour envoyer des messages
instantans. Le texte du message est envoy dans le corps de la requte SIP.

Figure 8 - Messages instantans

3 Conclusion
SIP est un protocole de signalisation pour les applications de tlphonie et la
visioconfrence sur Internet. Sa simplicit et son intgration au monde IP, fait qu'
il vient
bousculer le mastodonte H.323 dj bien implant. Il intervient aux diffrentes phases
de l'
appel.
SIP fournit les mcanismes protocolaires ncessaires pour que les machines et des
serveurs puissent fournir des services comme la redirection dappelIl permet de
joindre les utilisateurs par des adresses de type e-mail, et rutilise linfrastructure du
courrier lectronique. Des adresses SIP ( URLs ) peuvent galement tre incluses dans
des pages WEB.
Etant utilis typiquement au-dessus dUDP ou de TCP, SIP peut tre utilis au-dessus
dIPX ou dautres protocoles.
Bien sr SIP nest pas le seul standard de la tlphonie sur IP. Lapproche qui simpose
aujourdhui est base sur la norme H.323 de lUIT(Union Internationale des
Tlecommunications).
Conue initialement pour les confrences multimdia sur les LANs sans garantie de
qualit de service, et donc couvrant un spectre plus large que la tlphonie, H.323 se
rvle bien adapt pour fdrer les diffrents systmes existants de voix sur IP.
Depuis son approbation en 1996, le standard H.323 fournit un cadre pour les
communications audio, vido et de donnes sur les rseaux IP. Il concerne
le contrle des appels, la gestion du multimdia, la gestion de la bande passante pour
les confrences point--point et multipoints. Dans ce cadre, H.323 traite essentiellement
de linterfaage entre le LAN et les rseaux commuts, tels que le rseau tlphoniques
ou le RNIS.
La norme H.323 spcifie toute une suite de protocoles qui doivent tre supports pour
garantir l.interoprabilit entre produits conformes au standard. Dans le domaine de la
tlphonie sur IP, ces protocoles couvrent notamment le codage et la transmission de la
voix ainsi que la signalisation et certains lments dadressage.

4 Rfrences
[1] D.Sisalem, J.Kuthan, Understanding SIP.
[2] H.Schulzrinne, The Session Initiation Protocol (SIP), septembre 2000.
[3] J.Rosenberg, H.Schulzrinne, SIP : Session Initiation Protocol, RFC 3261, juin 2002.
[4] A. Gomez, Tlphonie sur rseaux de donnes, 2002.
[5] H.T. Kung, Computer Networks (SIP), avril 2003
[6] J. Janak, SIP Introduction, 2003.