Protocole SIP

 SIP (Session Initiation Protocol) a été officiellement lancé en 1999

(RFC 2543)
 SIP est fondé sur d’autres protocoles:
 Le concept de session fut introduit dans RFC 2327 SDP (Session
Description Protocol)
 Définit comme un ensemble de flux transportant divers type de média
entre émetteurs et récepteurs
 Exemples de session:
 Conversation téléphonique
 Vidéoconférence
 Prise de contrôle de PC à distance
 Deux usagers qui échangent des données
 Messagerie instantanée (chat)
 Le protocole SAP (Session Announcement Protocol, RFC 2974)
 Le protocole de transmission de données temps réel RTSP (Real Time
Streaming Protocol, RFC 2326) pour contrôler les serveurs d’infos en
temps réel

© Kais Mnif -59-

Primitives génériques du protocole SIP

 Localisation des usagers

 déterminer des paramètres techniques (adresse IP, etc.)
 Disponibilité des usagers
 accessibilité et l’intention d’accepter ou refuser une
communication
 Capacité des terminaux
 type de média et leurs paramètres utilisables pour la
communication
 Établissement de session
 faire sonner le dispositif distant et établir la session média
entre l’appelant et l’appelé
 Gestion de session
 Le transfert de flux en cours, relâchement de la
communication, la modification des paramètres de session et
l’invocation de service

© Kais Mnif -60-

 Appel de base en SIP

 Les adresse SIP, comme les adresses web, respectent un

schéma de nommage défini pour les URI (Uniform
Resource Identifier) dans la RFC 2396
 Comme par ex. dans http, il doit être suivi de : puis //
 SIP utilise deux schémas de nommage:
 sip pour les communications non sécurisées
 sips pour les communications sécurisées
 Après ‘sip:’ ou ‘sips:’, la syntaxe minimale est un nom de
domaine (@IP) ou un DNS
sip : john@192.190.132.31
 Un appel SIP concerne une personne spécifique, la syntaxe
d’URL SIP permet d’ajouter d’autres paramètres
sip : user : password@adresse IP:port

© Kais Mnif -61-

Transaction SIP
 Les dispositifs SIP communiquent en utilisant des ‘transactions’
 Une transaction est une requête demandant une action bien spécifique
(ex. la requête INVITE et la réponse 200 OK)
requête
client A B serveur
INVITE Réponse
provisoire
Transaction 1 180 RINGING

200 OK
Réponse
finale
Transaction 2 ACK
Dialogue
SIP
MEDIA SESSION
Flux RTP

BYE
Transaction 3
200 OK

© Kais Mnif -62-

 Messages SIP
 Il existe deux types de messages SIP
 Les requêtes SIP
 Les réponses SIP
 La syntaxe de message utilisée est celui HTTP/1.1 (RFC 2068)
 Les lignes sont terminées par les caractères CR LF (Retour Chariot, Nouvelle
Ligne)
 Les requêtes SIP sont envoyées d’un client SIP à un serveur SIP.
 SIP définit 13 requêtes, les plus utilisées sont :

Requête Définition
INVITE Demande d’établissement d’appel
ACK Confirmer la réception d’une réponse finale d’un serveur

BYE Relâcher l’appel en cours par l’appelé ou l’appelant

CANCEL Annuler une requête précédente tant que le serveur n’ a pas

envoyé une réponse finale
REGISTER Enregistrer la localisation de clients auprès de serveurs
particuliers (registrar)
SUSCRIBE Demande de notifications d’événements
MESSAGE Envoi de messages instantanés
INFO Envoi d’infos ne modifiant pas l’état de l’appel

© Kais Mnif -63-

Format des messages SIP

 SIP has an HTTP-like structure, which makes it easy to read and

comprehend
 SIP only supports two basic types of messages:
 Requests
 Responses.

Request Method <space> Request-

line URL <space> SIP-version Where Method is INVITE
<CRLF> Request-URL is sip:user@domain.com
Ex. INVITE SIP version is SIP/2.0
sip:user@domain.com
SIP/2.0
Response SIP-version <space>Status Where SIP version is SIP/2.0
line Code <space> Reason- Status code is 100
Phrase <CRLF> Reason –Phrase is Trying
Ex. SIP/2.0 100 Trying

© Kais Mnif -64-

 Les requêtes SIP

 Toutes les requêtes SIP suivent le format détaillé suivant :

Ligne de début
Requête

INVITE sip:user@domain.com SIP/2.0 CRLF

Méthode
Via: SIP/2.0/UDP 192.168.1.15;
URI From: <sip:308@192.168.1.15>;
To: <sip:309@192.168.1.15> En-tête général
Version Contact: <sip:308@192.168.1.10> adresse locale de la source
Supported: replaces
Call-ID: 8c80d06175b1eb80@192.168.1.10
CSeq: 28826 INVITE En-tête de
requête
Subject : meeting
En-tête
Content-Type: application/sdp
Content-Length: 225 En-tête d’entité

<CR LF> Ligne vide

v=0
o=308 8000 8000 IN IP4 192.168.1.10
s=SIP Call
Corps (SDP) c=IN IP4 192.168.1.10
t=0 0
m=audio 5004 RTP/AVP 4 18 97
a=sendrecv Données
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20
a=ptime:60

© Kais Mnif -65-

Les réponses SIP

 Un serveur SIP répond à une requête SIP au moyen d’une ou plusieurs réponses
 Les réponses sont de la forme:
 1xx informationnel
 2xx succès
 3xx redirection
 4xx Erreur Client
 5xx Erreur du serveur
 6xx Problème global
Version Ligne d’état
SIP/2.0 100 Trying
état

Code
Raison SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.1.15;branch=z9hG4bKb992.ec6bce33.0
Via: SIP/2.0/UDP 192.168.1.10;branch=z9hG4bKf3c60221ce03445c
From: <sip:308@192.168.1.15>;tag=fce371520693b722 En-tête
To: <sip:309@192.168.1.15>
En-tête Call-ID: 8c80d06175b1eb80@192.168.1.10
CSeq: 28826 INVITE
User-Agent: Grandstream BT110 1.0.8.33
Content-Length: 0
Ligne vide

Données de réponses
Corps SDP vide, chiffré, txt
plain, txt html

© Kais Mnif -66-

 © Kais Mnif -67-

Status Code
404 Not found
405 Method not allowed
100 Trying 406 Not acceptable
180 RINGING 407 Proxy authentication required
181 Call is being forwarded 408 Request timeout
182 Queued 409 Conflict
410 Gone
200 OK 411 Length required
413 Request entity too large
300 Multiple choices 414 Request – URI too long
301 Moved permanently 415 Unsupported media type
302 Moved temporarily 420 Bad extension
305 Use proxy 480 Temporarily unavailable
380 Alternative service 481 Call leg/Transaction does not
exist
482 Loop detected
400 Bad request 483 Too many hops
401 Unauthorized 484 Address incomplete
402 Payment required 485 Ambiguous
403 Forbidden 486 Busy here

68
 Status Code

500 Server internal error

501 Not implemented
502 Bad gateway
503 Service unavailable
504 Gateway time out
505 Version not supported

600 Busy everywhere

603 Decline
604 Does not exist anywhere
606 Not acceptable

69

Les Éléments SIP

© Kais Mnif -70-

 Terminologie SIP
 UA : User Agent
 Il se décompose en une partie cliente User Agent Client (UAC), et
une partie serveur User Agent Server (UAS). Le principal objectif
de SIP est de permettre l'établissement de sessions entre User
Agents
 Registrar Server
 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
 Proxy Server
 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 ne peut pas initier une requête exceptée la requête CANCEL
utilisée pour libérer une session

© Kais Mnif -71-

Terminologie SIP
 Redirect Server
 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

 Location Server
 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

© Kais Mnif -72-

 Fonction d’un Proxy (serveur mandataire)
 Un proxy est un dispositif qui agit comme
 un serveur d’un coté (reçoit les requêtes)
 comme un client de l’autre (il retransmet des requêtes)
 Il doit être, presque, entièrement transparent vis-à-vis des
messages des UAC,
 Il se contente de relayer les messages et d’y apporter des
modifications mineurs
 Un proxy peut :
 relayer la requête sans aucun changement vers la destination
finale
 décider pour vérifier la validité, l’authenticité des utilisateurs,
 dupliquer les requêtes
 résoudre les adresses
 annuler les appels en cours d’établissement,
 etc.
© Kais Mnif -73-

Types de proxy
 Selon le niveau de contrôle que la fonction de proxy a sur les
messages SIP, on distingue deux types de SP

 Proxy stateful maintient toute la durée des sessions l’état des

connexions
 Il conserve en mémoire l’état de l’appel et les transactions

 Il gère localement une bonne partie de la couche transaction: les

retransmissions sont réalisées par le proxy, les acquittements des
réponses finales (sauf 200 OK) et le traitement des requêtes
CANCEL

 Il peut choisir une route sortante pour un appel en analysant les

réponses pour passer à la passerelle suivante en cas d’échec, de

congestion, etc.

© Kais Mnif -74-

 Types de proxy

 Proxy stateless achmine les messages indépendamment les

uns des autres, sans sauvegarder l’état des connexions
 Il se contente de choisir la destination suivante du message SIP
utilisant l’info. de l’en-tête

 Il ne gère pas la retransmission, mais se contente de relayer les

messages tels qu’ils reçoit (ex. il n’effectue aucun traitement local s’il
reçoit une requeté CANCEL)

 Il n’acquitte aucune réponse, mais se contente de les retransmettre au

terminal qui a initier les requêtes

 Les proxy stateless sont plus rapides et plus légers que les proxy
statefull, mais ils ne disposent pas des mêmes capacités de
traitement sur les sessions

© Kais Mnif -75-

Scénarios de communication

 Initialisation d’une communication directe

 Enregistrement d’un terminal

 Initialisation d’une communication avec un serveur proxy

 Localisation par un serveur de redirection et initialisation

d’appel directe

 Modification dynamique d’une communication SIP

 Terminaison d’une communication

76
 Scénario 1: Initialisation d’une communication
directe
Invitation à une Terminal SIP appelant Terminal SIP appelé
communication. (UAC, User Agent Client) (UAS, User Agent Server)
Message contient les
paramètres désirés INVITE

L’UAS indique à 180 RINGING

l’UAC(par une réponse
provisoire 180) que 200 OK
l’UAS est en train d’être
averti de l’appel
Message
ACK d’acquittement.
En acceptant l’appel
(décrocher), l’UAS L’UAC informe
informe l’UAC par une l’UAS que
réponse définitive 200 l’appel peut
OK. Message contient débuter. Les
les paramètres que paramètres sont
l’UAS supporte pour la Flux média fixés pour la
session
session (audio, vidéo, texte,…)

Une communication peut s’effectuer directement entre deux correspondants, sans

faire intervenir d’autre entité
 l’appelant doit connaître la localisation (sous forme d’adresse IP) de
l’appelé

77

Scénario 2 : Enregistrement d’un terminal

:12345

enregistrement
dans la base

Expiration

48 min

Le serveur maintient dans sa base une entrée associant l’identifiant d’un utilisateur
avec sa position dans le réseau (@ IP et port utilisé par l’application)

Par défaut, le délai d’expiration est d’une heure. Périodiquement, le terminal doit
rafraichir son entrée avec la requête REGISTER. A défaut, l’entrée est effacée

78
 Scénario 3 : Initialisation d’une communication SIP avec un
serveur proxy
Terminal Serveur proxy Serveur proxy Terminal
de A de A de B de B

Localisation du
invite serveur proxy de B
Étape 1
Localisation
du terminal
100 Trying
invite de B

Attente
Étape 2 de la
100 Trying réponse
invite de B

180 Ringing
Étape 3
180 Ringing
180 Ringing
200 OK
Étape 4
200 OK
200 OK
ACK
Étape 5

Flux média
(audio, vidéo, texte,…)

79

Scénario 3 : Initialisation d’une communication SIP avec un

serveur proxy
 Etapes suivantes sont nécessaires:
 Étape 1
 A compose sur son terminal l’adresse SIP de B. Une requête INVITE est
envoyé de l’UAC de A vers son serveur proxy (SP)
 À la réception de ce message, le SP de A utilise la partie domaine de
l’adresse SIP de B pour déterminer le serveur en charge de la gestion de
B. Un serveur DNS peut être sollicité pour localiser le SP de B
 En parallèle, le SP informe A qu’il prend en charge la requête et en cours
de traitement par la réponse temporaire 100 TRYING
 Étape 2
 La requête INVITE est relayée jusqu’à B.
 Le SP de A transmet la requête INVITE au SP de B après l’avoir localisé
 Une modification du message au niveau du champ VIA, qui liste
l’ensemble des machines parcourus lors de l’acheminement du paquet
auquel il ajoute sa propre adresse réseau
 Le SP de B envoi au SP de A un message temporaire 100 TRYING
 Une fois la position de B est retrouvée, le SP de B lui transmet l’invitation
de A. Ce message est conforme à l’original, seul le champ VIA a été
enrichi de l’adresse du SP de B
80
 Scénario 3 : Initialisation d’une communication SIP avec un
 Étape 3: serveur proxy
 Le terminal de B sonne
 Il indique à son SP (message 180 Ringing) que l’appel est entrain d’être notifié à B
et que la communication est en attente
 Ce message informatif est relayé jusqu’à l’émetteur A qui reçoit une sonnerie.
L’utilisation du champ VIA permet de remonter de proche en proche jusqu’à A
 Étape 4
 B répond au téléphone. À l’instant ou B décroche, l’UAS retourne à l’UAC un
message 200 Ok pour l’informer que l’appel est accepté,
 Ce message est relayé par les différent proxy
 Communication n’a pas encore débuté
 Étape 5
 A confirme les paramètres d’appel (en tenant compte des capacités prises en
charge par le récepteur
 A envoi un message ACK qui spécifie les paramètres définitifs à utiliser pour cette
session
 Le message ACK peut passer directement de A vers B sans transiter par les SPs
 Dans cet appel, on retrouve les 3 phases fondamentales
 Invitation de l’appelant: INVITE
 Acceptation de l’appelé: réponse 200 OK
 Confirmation par l’appelant: ACK

81

Scénario 4 : Localisation par un serveur de redirection et

initialisation d’appel
Terminal
de B
Terminal Serveur de redirection Serveur proxy
de A de A de B
Localisation du
invite serveur proxy de B
Étape 1 301 Moved Temp.
Localisation
ACK du terminal
invite de B

Étape 2 Attente
de la
100 Trying réponse
de B
invite

Étape 3 180 Ringing

180 Ringing

200 OK
Étape 4
200 OK

ACK
Étape 5

Flux média
(audio, vidéo, texte,…)

82
 Scénario 4 : Localisation par un serveur de redirection
et initialisation d’appel

 Étape 1
 Le terminal A sollicite le serveur de redirection (SR) pour
déterminer la localisation de B
 La réponse est directement envoyée à A
 A initie l’appel, lui-même, en contactant le SP de B
 Étapes 2, 3, 4 et 5 sont identiques au scénario 3
 L’initialisation d’appel par le SP de B, si ce dernier n’intervient
pas dans les échanges intermédiaires

83

Scénario 5 : modification dynamique d’une

communication SIP

 Un utilisateur en communication souhaite modifier les paramètres de

la session tout en restant actif
 S’il veut effectuer un téléchargement en //, il peut alors changer le codec
 Il veut ajouter de la vidéo
 SIP, par sa souplesse, capable de répondre a ce genre de demande
 Il suffit d’envoyer de nouveau la requête INVITE afin de renégocier les
paramètres
 INVITE, ici, n’a pas pour objectif d’inviter à une nouvelle session mais
d’utiliser de nouveaux paramètres

Terminal SIP Terminal SIP Terminal SIP

Terminal SIP
appelant appelant appelé
appelé
INVITE INVITE

200 OK 488Not Acceptable here

ACK
Requête re-invite accéptée Requête re-invite rejetée

84
 Scénario 6 : Terminaison d’une communication SIP

 Cette opération comporte deux étapes très simples

 Une requête BYE envoyé par l’interlocuteur qui désire
clôturer la session
 Le correspondant répond à cette requête en validant avec la
réponse 200 OK
La communication est alors rompue

Terminal SIP Terminal SIP

Flux média
(audio, vidéo, texte,…)

BYE

200 OK

85

Autres scénarios

 Messages instantanés
 Ils sont envoyés en utilisant la requête MESSAGE
 Aucun dialogue n’établie et par conséquent ils traverseront toujours
le même ensemble de proxy
 Le texte du message est envoyé dans le corps de la requête SIP

Message
Message
200 OK
200 OK

Message
Message

200 OK
200 OK

86
 Session Description Protocol (SDP)

 Définit dans RFC 2327

 a été conçu par l IETF dans le cadre de MMSIC, le
groupe de travail de SIP
 Décrit l’ensemble des paramètres constituant une
session incluant
 les spécifications des médias utilisés
 Les protocoles de transport
 Les ports
 Les codeurs
 Les ressources nécessaires
 Les dates d’activités de la session

© Kais Mnif -87-

Champs SDP
Champ Correspondance Type d’info. Description Présence
SDP du champs
v Protocole version Description de version du protocole Requise
session
o Owner/creator Description de Nom du créateur de la Requise
and Session ID session session et identification de
la session
s Session name Description de Nom de la session Requise
session
i Media title Description de Info. Sur la session Optionnelle
session et de média
u URI Description de URI de description de la Optionnelle
session session
e Email address Description de Email du créateur de Optionnelle
session session
p Phone Numb. Description de Num. de télé. du créateur Optionnelle
session de session
c Connection info. Description de Adresse réseau avec Requise
session et de média laquelle s’effectue la
connexion
b Bandwidth info. Description de Débit nécessaire optionnelle
session et de média

© Kais Mnif -88-

 Les champs SDP

Champ Correspondance Type d’info. Description Présence du

SDP champs
t time Description temporelle Date d’activité de la requise
session
r Repeat time Description de Rpétition de la session. optionnelle
temporelle Cette valeur commence à
partir de la valeur de
début de session indiquée
dans le champ t
z Time zone Description de session Info. horaire optionnelle
adjustments
k Encryption key Description de session Clé de cryptage utilisée Optionnelle
et de média
a Session attribute Description de session Attributs de média Optionnelle
et de média
m Media name and Description de média Type de média utilisé et requise
transport adresse de transport
address

© Kais Mnif -89-

SDP Requête/réponse : Media Setup

Source : SIP tutorial 2009 J. Ott G. Camarillo Ericsson

© Kais Mnif -90-

 Session Announcement Protocol (SAP)

 SAP delivers SDP packets using multicasting where

participants are not known in advance.

 A multicast session is announced by sending multicast

packets to a well-known multicast group carrying an SDP
description of the session to occur:
 Creates, modifies, and terminates sessions

 Uses SDP to describe the session being multicast

 Announces a conference session by periodically (every few

minutes)

 multicasting an announcement packet to a well-known

multicast address and port

© Kais Mnif -91-

Différence entre Call-Id et Cseq

 Cseq (Command Sequence), ordre de commande,

 est constitué de l’association d’un numéro et de la requête
correspondante

 Il permet de différencier chaque message de requête

 Pour une session, on peut avoir plusieurs Cseq

 Deux Cseq ne sont égaux que s’ils ont simultanément le même

numéro et la même requête
 Ex. CSeq:1 pour le premier message INVITE. Ce numéro est repris
identiquement pour les messages qui relaient la requête et pour les
messages qui fournissent une réponse. À la prochaine requête, Cseq est
incrémenté (Cseq:2), etc.

© Kais Mnif -92-

 Différence entre Call-Id et Cseq

 Call-Id ou identifiant de l’appel

 est un numéro identifiant une session particulière
 Le call Id est généré lors de l’initialisation de l’appel par le terminal client,
il sera reporté par dans tous les messages SIP liés à la session, qque soit
leur émetteur
 Tous les messages liés à une même session portent obligatoirement un
même identifiant d’appel, on peut décrire une session par son Call Id
associé
 Tous les utilisateurs d’une même session exploitent donc le même Call-Id,
y compris lors d’une conférence
 Les serveurs intervenant dans la signalisation des messages SIP, ces
derniers distinguent les sessions auxquelles un message fait référence par
leur identifiant d’appel
 Une communication peut etre repartie entre plusieurs sessions
 Une conférence peut mettre en place une session audio et une session vidéo
distinctes
 Chacune des sessions dispose un call Id différent

© Kais Mnif -93-

Exemple
Terminal
User A User B Server Proxy User
de C C
Session 1
Session 2

© Kais Mnif -94-

 Dans cet exemple :
 B initie une communication avec C en passant par le SP
 Le Call-Id est arbitrairement fixé à 23553@isecs.tn et le Cseq
débute à 1
 Le Cseq ne s’incrémente qu’avec la nouvelle requête

 Le Call-Id ne changera que plus tard lorsque B lancera une autre

session vers A (liaison directe)

© Kais Mnif -95-

Avantages et limites SIP

 Simple
 Syntaxe html
 Efficace
 Capacité de réaliser des services avancées
 Conférence

 Problème en présence du NAT dans un réseau

 Adresse locale de la source incluse dans le contenu du
message SIP
 Le contenu n est pas modifiable par le NAT

© Kais Mnif -96-

Comparaison H.323 and SIP

© Kais Mnif -97-

Comparaison H.323 and SIP

© Kais Mnif -98-

Comparaison H.323 and SIP

rt: Roundtrip (aller-retour)

© Kais Mnif -99-