2 SIP (Session Initiation Protocol)

Transcription

2 SIP (Session Initiation Protocol)
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
Eléments réseaux 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
Scénarios 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 événement et notification .............................................10
2.7.7
Messages instantanés .............................................................................11
3 Conclusion .............................................................................................................12
4 Références.............................................................................................................13
1
2
1 Introduction
Ce document décrit les grandes lignes de la Session Initiation Protocol SIP. Nous allons
voir dans les différentes sections le but du SIP, les différentes entités qui le composent,
le format de message qu’il utilise. Nous allons également définir ce que c’est une
transaction, dialogue SIP pour enfin voir un scénario typique du SIP.
2 SIP (Session Initiation Protocol)
2.1 But
SIP est un protocole de contrôle de la couche application. Ce protocole (basé sur le
protocole http : hypertext transfert protocol) est utilisé pour créer, modifier et terminer
des sessions. Une session est l’ensemble d'
émetteur et récepteurs qui communiquent
entre eux ainsi que l'
état à conserver pendant la communication. Une session peut
inclure des appels téléphoniques Internet, une distribution multimédia, une conférence
multimédia …avec un participant ou plus.
But du SIP:
• Rendre la communication possible. La communication elle-même doit être
accomplie par un autre moyen. Les 2 protocoles utilisés le plus souvent avec SIP
sont RTP (Real Time Transport) et SDP (Session Data Point), lequel est utilisé
pour décrire et encoder les capacités des participants de la session.
• SIP est utilisé pour transporter la description des paramètres de la session. Cette
description est encodée 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 Eléments réseaux du SIP
2.3.1 User Agents (UA)
Les UAs sont des end points Internet qui utilisent SIP pour se trouver et pour négocier
une session. Habituellement, les UAs résident sur l'
ordinateur d'
un utilisateur comme
application, mais peuvent être aussi un téléphone 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 requête et reçoit la réponse.
UAS: partie d'
UA qui envoie des réponses et reçoit la requête.
2.3.2 Serveur Proxy
Le proxy exécute l’acheminement d'
une invitation à une session - d'
après l'
emplacement
de l’actuel invité -, l’authentification, la comptabilité... Il existe deux types de serveur
proxy :
Serveurs stateless : ils acheminent les messages indépendamment les uns des
autres, ils ne prennent pas soin des transactions.
Serveurs stateful : ils maintiennent l’état des requêtes pour la durée de la
transaction. Ils absorbent la rediffusion, et ils peuvent exécuter des méthodes
plus compliquées pour trouver un utilisateur.
2.3.3 Registrar
Un registrar est une entité qui reçoit les inscriptions des utilisateurs. Elle extrait
l’information au sujet de l’emplacement (adresse IP, port, username) de ces utilisateurs
et l’entrepose dans une base de données : la location database. L'
UA doit rafraîchir
régulièrement son inscription.
Figure 1- Vue d'ensemble du registrar
2.3.4 Redirect Server
Un redirect server est une entité qui reçoit une requête et renvoie une réponse. Il reçoit
des requêtes et cherche le destinataire prévu dans la location database créée par un
registrar. Il crée alors une liste d'
emplacements courants des utilisateurs et l'
envoie à
l'
initiateur de la requête dans une réponse classe 3xx. L'
initiateur de la requête extrait la
liste des destinations et leur envoie directement une autre requête.
Figure 2 - Réacheminement
2.4 Messages SIP
La communication qui utilise SIP (souvent appelé signalling) comprend une série de
messages. Les messages sont soit une requête d'
un client à un serveur soit une
réponse d'
un serveur à un client. Les messages peuvent être transportés
indépendamment par le réseau.
Requêtes: utilisées pour commencer des actions ou informer un destinataire de
la requête.
Réponses: utilisées pour confirmer qu'
une requête a été reçue et traitée, ou pour
indiquer le statut du traitement.
Format d’un message générique :
start-line
*message-header
CRLF
[message-body]
En détail:
start-line = Request-line/Status-line
Requêtes
start-line = Request-line
Request-line =
Methods (sp) Request-URI (sp) SIP-Version
REGISTER
INVITE
ACK
CANCEL
BYE
OPTIONS
Réponses
: lie une adresse permanente à l’emplacement courant
:
:
:
:
:
commence une session
confirme l’établissement de la session
annule un ‘’pending’’ INVITE
termine la session
demande au serveur ses capacités
start-line = Status-line
Status-line = SIP-Version (sp) Status-Code (sp) Reason-Phrase
Status-code : code de 3 nombres entiers qui est le résultat d'
une tentative de
compréhension et de satisfaction d’une requête.
Il y 6 classes de réponses :
1xx :
Provisoire
la requête a été reçue, et est en train d’être traitée.
2xx:
Succès
3xx :
Réacheminement
100 Trying, 180 Ringing, 181 Call is being forwarded
l'
action a été reçue avec succès, comprise et acceptée.
200 Ok
des actions supplémentaires sont nécessaires afin de
compléter la requête.
300 Multiple choice, 301 Moved permanently,
302 Moved temporarily
4xx:
Erreur client
la requête 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é à l’accomplissement d’une requête
apparemment valide.
la requête ne peut être accomplie par aucun serveur
La Reason-Phrase est prévue pour donner une courte description textuelle du Statuscode.
2.5 Transaction SIP
Transaction: séquence de messages SIP (une requête et toutes les réponses à cette
requête) échangés entre les différents éléments du SIP.
Si une transaction avait été commencée par une requête INVITE, alors la même
transaction inclut aussi l’ACK, mais seulement dans le cas où la dernière réponse n'
était
pas une réponse de la classe 2xx. Si la dernière réponse était une réponse 2xx, alors
l'
ACK n'
est pas considéré 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 l’activité à un moment donné.
Client transaction : reçoit la requête d'
un TU (Transaction User) qui est un UA ou
un stateful proxy, et délivre la requête à un serveur de transactions.
Server transaction : reçoit la requête de la couche transport et la délivre au TU.
Filtre toute rediffusion de la requête, accepte la réponse du TU et la délivre à la
couche transport
Un stateless proxy n’a ni un client, ni un serveur de transaction. La transaction
existe entre l'
UA ou un stateful proxy d’un côté, et l'
UA ou un stateful proxy de l’autre
côté.
Figure 3 - transaction SIP
2.6 Dialogue SIP
Les dialogues sont identifiés en utilisant le call-ID, l’étiquette From et l’étiquette To.
Les messages dont ces 3 champs sont respectivement identiques appartiennent à un
même dialogue.
Figure 4 - Dialogue SIP
2.7 Scénarios SIP typiques
Cette section donne une brève vue d'
ensemble de scénarios 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 réussie.
2.7.2 Invitation à la session
Une requête INVITE est envoyée habituellement à un proxy. Un 200 Ok est produit une
fois que l’appelé prend le téléphone. La session est établie au moment où l’appelé reçoit
l’ACK de l’appelant.
Figure 5 - Flux du message INVITE
2.7.3 Fin de la session
La fin de la session est faite en envoyant une requête BYE dans le dialogue établi par
INVITE. Les messages BYE sont envoyés directement d’un UA à l'
autre à moins qu'
un
proxy soit sur le chemin (path) de la requête INVITE, indiquant qu'
il est souhaité rester
sur le chemin défini dans le record routing.
2.7.4 Record routing
Toutes les requêtes dans un dialogue sont envoyées, par défaut, directement d'
un UA à
l'
autre. Seules les requêtes hors du dialogue traversent le proxy.
Un tel proxy insérerait le champ en-tête Record-route dans les messages SIP. Les
messages envoyés dans un dialogue traverseront alors tous le proxy SIP qui a mis un
champ en-tête 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-tête
de la Route.
Loose routing : le request-URI contient toujours l’URI de l’UA de la destination.
S'
il n’y a aucun en-tête du champ Route dans un message, le message est
envoyé à l'
URI du Route le plus élevé.
2.7.6 Souscription à un événement et notification
La spécification du SIP a été étendue pour supporter un mécanisme général qui autorise
la souscription aux événements asynchrones. De tels événements peuvent inclure un
changement statistique du proxy SIP, une information sur la présence, un changement
au niveau de la session etc. Ce mécanisme est utilisé principalement pour transmettre
de l'
information sur la présence de l’utilisateur.
Figure 7 - Souscription aux événements et notification
2.7.7 Messages instantanés
Les messages instantanés sont envoyés en utilisant une requête MESSAGE. Ces
requêtes n'
établissent pas de dialogue et par conséquent ils traverseront toujours le
même ensemble de proxy. C'
est la forme la plus simple pour envoyer des messages
instantanés. Le texte du message est envoyé dans le corps de la requête SIP.
Figure 8 - Messages instantanés
3 Conclusion
SIP est un protocole de signalisation pour les applications de téléphonie et la
visioconférence sur Internet. Sa simplicité et son intégration au monde IP, fait qu'
il vient
bousculer le mastodonte H.323 déjà bien implanté. Il intervient aux différentes phases
de l'
appel.
SIP fournit les mécanismes protocolaires nécessaires pour que les machines et des
serveurs puissent fournir des services comme la redirection d’appel…Il permet de
joindre les utilisateurs par des adresses de type e-mail, et réutilise l’infrastructure du
courrier électronique. Des adresses SIP ( URLs ) peuvent également être incluses dans
des pages WEB.
Etant utilisé typiquement au-dessus d’UDP ou de TCP, SIP peut être utilisé au-dessus
d’IPX ou d’autres protocoles.
Bien sûr SIP n’est pas le seul standard de la téléphonie sur IP. L’approche qui s’impose
aujourd’hui est basée sur la norme H.323 de l’UIT(Union Internationale des
Télecommunications).
Conçue initialement pour les conférences multimédia sur les LANs sans garantie de
qualité de service, et donc couvrant un spectre plus large que la téléphonie, H.323 se
révèle bien adapté pour fédérer les différents systèmes existants de voix sur IP.
Depuis son approbation en 1996, le standard H.323 fournit un cadre pour les
communications audio, vidéo et de données sur les réseaux IP. Il concerne
le contrôle des appels, la gestion du multimédia, la gestion de la bande passante pour
les conférences point-à-point et multipoints. Dans ce cadre, H.323 traite essentiellement
de l’interfaçage entre le LAN et les réseaux commutés, tels que le réseau téléphoniques
ou le RNIS.
La norme H.323 spécifie toute une suite de protocoles qui doivent être supportés pour
garantir l.interopérabilité entre produits conformes au standard. Dans le domaine de la
téléphonie sur IP, ces protocoles couvrent notamment le codage et la transmission de la
voix ainsi que la signalisation et certains éléments d’adressage.
4 Références
[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, ‘’Téléphonie sur réseaux de données’’, 2002.
[5] H.T. Kung, ‘’Computer Networks (SIP)”, avril 2003
[6] J. Janak, ‘’SIP Introduction’’, 2003.