SIP signaling protocol explained by professor

Introduction
SIP est un protocole de signalisation défini par l’IETF
(Internet Engineering Task Force) permettant
l’établissement, la libération et la modification de
sessions multimédias.
Il hérite de certaines fonctionnalités des protocoles http
(Hyper Text Transport Protocl) utilisé pour naviguer sur
le WEB, et SMTP (Simple Mail Transport Protocol)
utilisé pour transmettre des messages électroniques (E-
mails).

Introduction
SIP s’appuie sur un modèle transactionnel
client/serveur comme http.
L’adressage utilise le concept d’URL SIP
(Uniform Resource Locator) qui ressemble à une
adresse E-mail.

Introduction
Chaque participant dans un réseau SIP est donc
adressable par une URL SIP.
Par ailleurs, les requêtes SIP sont acquittées par
des réponses identifiées par un code numérique.
D’ailleurs, la plupart des codes de réponses SIP
ont été empruntés au protocole http.

Introduction
Par exemple, lorsque le destinataire n’est pas
localisé, un code de réponse « 404 Not Found »
est retourné.
Une requête SIP est constituée de headers
comme une commande SMTP.

Introduction
SIP a été étendu afin de supporter de nombreux
services tels que la présence, la messagerie
instantanée (similaire au service SMS dans les
réseaux mobiles), le transfert d’appel, la
conférence, les services complémentaires de
téléphonie, etc

Introduction
SIP a été retenu par le 3GPP pour l’architecture
IMS (IP Multimedia Subsystem) comme
protocole pour le contrôle de session et le
contrôle de service.
Il remplacera à terme les protocoles ISUP(utilisé
pour le contrôle d’appel dans le Réseau
Téléphonique Commuté)

Introduction
Le protocole SIP n’est qu’un protocole de
signalisation.
Une fois la session établie, les participants de la
session s’échangent directement leur trafic
audio/vidéo à travers le protocole RTP (Real-
Time Transport Protocol)

Introduction
Par ailleurs, SIP n’est pas un protocole de réservation
de ressource, il ne peut donc pas assurer la QoS.
Il s’agit d’un protocole de contrôle d’appel et non de
contrôle du média.
SIP n’est pas non plus un protocole de transfert de
fichier tel que HTTP, utilisé afin de transporter de
grands volumes de données.

Introduction
Il a été conçu pour transmettre des messages de
signalisation courts afin d’établir, maintenir et
libérer des sessions multimédia.
Des messages courts non relatifs à un appel
peuvent néanmoins être transportés par SIP à la
manière des SMS.

Entités SIP
SIP définit deux types d’entités : les clients et les
serveurs.
Un client est une application qui émet des
requêtes SIP alors qu’un serveur est une entité
qui répond à des requêtes SIP.
SIP est donc un protocole client/serveur.

Entités SIP
Clients et serveurs SIP

Entités SIP
Proxy server (serveur de proxy): joue les rôles de client et de serveur. Il
reçoit des requêtes de clients qu’il traite lui-même ou qu’il relaye à
d’autres serveurs après avoir éventuellement réalisé certaines
modifications sur ces requêtes
Un serveur proxy est une sorte de pont qui vous relie au reste
d'Internet. Normalement, lorsque vous naviguez sur Internet,
vous vous connectez directement au site Web qui vous
intéresse. Un proxy établit à votre place la communication

Entités SIP
Le serveur de redirection (Redirect server): est un serveur qui accepte
des requêtes SIP, traduit l’adresse SIP de destination en une ou plusieurs
adresses réseau et les retourne au client.

Entités SIP
Contrairement au Proxy server, le Redirect server ne relaye pas de
requêtes SIP.

Entités SIP
L’agent utilisateur (User agent) est une application qui joue les rôles client
et serveur.

Entités SIP
L’agent utilisateur client
(UAC, User agent client) est
une application qui émet des
requêtes SIP.

Entités SIP
L’agent utilisateur serveur (UAS, User
agent server) est une application qui
accepte des requêtes SIP et qui
contacte l’utilisateur.

Entités SIP
Une réponse de l’utilisateur est retournée par
l’agent utilisateur serveur. Tout équipement SIP
(e.g., PC ou Téléphone IP avec applicatif SIP)
implantera les fonctions agent utilisateur client et
agent utilisateur serveur.
SIP permet justement l’établissement de sessions
entre User agents.

Entités SIP
L’enregistreur (Registrar) est un serveur qui
accepte les requêtes SIP REGISTER. SIP
comme H.323 dispose de la fonction
d’enregistrement d’utilisateurs.

Entités SIP
L’utilisateur indique par un message
REGISTER émis au Registrar, l’adresse où
il est joignable.

Entités SIP
L’enregistreur est une fonction associée à un
Proxy server ou à un Redirect server. Un
utilisateur peut s’enregistrer sur différents
terminaux SIP

La passerelle SIP (SIP Gateway) interconnecte
un réseau SIP à un réseau utilisant un autre
protocole de signalisation (e.g., H.323, Q.931,
ISUP).
Un SIP Gateway est considéré comme un user
agent puisqu’il est apte à émettre et accepter
des requêtes SIP.
Entités SIP

Les requêtes SIP: INVITE
Le RFC 3261 définit six requêtes ou méthodes SIP.
La méthode INVITE est utilisée afin d’établir une
session entre User agents.
INVITE correspond au message ISUP IAM ou au
message Q.931 SETUP et contient les informations
sur l’appelant et l’appelé et sur le type de flux qui
seront échangés (voix, vidéo, etc.).

Les requêtes SIP: INVITE
Lorsque le User agent ayant émis la méthode SIP
INVITE reçoit une réponse finale à l’invitation, il
confirme la réception de cette réponse par une
méthode ACK.
Une réponse par exemple « busy » est considérée
comme finale alors qu’une réponse telle que
« ringing » signifiant que l’appelé est alerté, est
une réponse provisoire.

Les requêtes SIP: BYE
La méthode BYE permet la libération d’une
session préalablement établie.
Elle correspond au message RELEASE des
protocoles ISUP et Q.931.
Un message BYE peut être émis par l’appelant
ou l’appelé.

La méthode REGISTER est utilisée par un User agent afin d’indiquer
au Registrar son adresse IP ainsi que son adresse SIP (SIP URL).
Ainsi le Registrar connaît la localisation de l’utilisateur.
Comme dans le cas du Gatekeeper, le User agent peut connaître par
avance son Registrar (adresse IP du Registrar préconfigurée dans le
User agent) auquel cas il émet une méthode REGISTER uniquement
à ce Registrar.
Sinon, le User agent émet le message à tous les Registrars en utilisant
une adresse IP multicast
Les requêtes SIP: REGISTER

Les requêtes SIP: CANCEL
La méthode CANCEL est utilisée afin de mettre fin à des
requêtes en cours.
Si un User agent s’enregistre auprès de plusieurs
terminaux, un message INVITE envoyé à ce User agent
sera dupliqué et relayé à l’ensemble de ces terminaux.
Lorsque l’utilisateur accepte l’appel sur un des
terminaux, une méthode CANCEL est émise vers les
autres terminaux afin d’annuler les requêtes INVITE en
cours.

Les requêtes SIP: OPTIONS
La méthode OPTIONS est utilisée afin
d’interroger les capacités et l’état d’un User
agent ou d’un serveur.
La réponse contient ses capacités (e.g., type de
média étant supporté) ou le fait que le User agent
soit indisponible.

Scénarios d’appel SIP: Exemple
d’établissement d’appel avec SIP sans serveur
Deux User agents SIP sont connectés à un réseau
IP. On suppose qu’ils connaissent leurs adresses
IP respectives.
La signalisation SIP est directement échangée
entre les User agents sans impliquer de Proxy
server ou de Redirect server.

L’appelant Mary commence par émettre un
message SIP INVITE à destination de l’appelé
Mark.
Le message INVITE contient l’ensemble des
informations sur le type de session à établir. Il
peut s’agir d’une session, audio, vidéo, etc.

Chaque champ est appelé en-tête (Header) et a la
forme : « Header : valeur CRLF ». CRLF
correspond au caractère de terminaison de ligne.
CRLF: carriage return/line feed

Le message INVITE contient les champs suivants :
INVITE sip : mark.rich@teleom-dev.fr SIP/2.0
Via: SIP/2.0/UDP station1.cegetel.fr:5060
Max-Forwards: 20
From: Mary Taylorsip:mary.taylor@cegetel.fr
To: Mark Rich<sip:mark.rich@telecom-dev.fr>
Call-Id: 23456789@station1.cegetel.fr
CSeq: 1 INVITE
Contact: sip:mary.taylor@192.190.132.20
Content-Type: application/sdp
Content-Length:162
La première ligne du message, appelée
start line (ligne de début) liste la
méthode, ici INVITE, la requête URI
(Uniform Resource Indicator) et le
numéro de version du protocole SIP
utilisé (2.0). La requête URI est une
forme particulière d’URL SIP et
indique l’entité destinataire.

Max-Forwards: 20
CSeq: 1 INVITE
Content-Length:162
Chaque entité SIP qui émet ou relaye
un message SIP insère son adresse de
host ou adresse IP dans ce Header Via

Max-Forwards: 20
CSeq: 1 INVITE
Content-Length:162
S’il s’agit d’une adresse de host, cette
dernière peut être traduite en une
adresse IP par le DNS.

Max-Forwards: 20
CSeq: 1 INVITE
Content-Length:162
Le Header Via contient la version du
protocole SIP, puis UDP indiquant un
transport UDP, un espace, suivi du
nom de host ou de l’adresse IP, de deux
points et d’un numéro de port SIP. Ici,
il s’agit du port SIP par défaut, à savoir
5060.

Max-Forwards: 20
CSeq: 1 INVITE
Content-Length:162
Le Header Via assure que la réponse
suivra le même chemin que la requête.

Max-Forwards: 20
From: Mary Taylor<sip:mary.taylor@cegetel.fr>
CSeq: 1 INVITE
Content-Length:162
 indiquer le nombre maximum de
proxy servers pouvant router la
méthode jusqu’au destinataire.
 Entier décrémenté à chaque saut
 Le message est éliminé quand Max-
Forwards=0

Max-Forwards: 20
From: Mary Taylor <sip:mary.taylor@cegetel.fr>
CSeq: 1 INVITE
Content-Length:162
indiquer les adresses SIP de l’émetteur
et du récepteur de la requête.

Max-Forwards: 20
CSeq: 1 INVITE
Content-Length:162
Lorsqu’un label de nom est utilisé
(dans l’exemple, Mary Taylor et Mark
Rich), alors l’URL SIP est délimitée
par des crochets et permet de router le
message.

Max-Forwards: 20
CSeq: 1 INVITE
Content-Length:162
Le Header Call-ID (identifiant unique
pour chaque appel) a une forme
similaire à celle d’une adresse
électronique mais ne fait que
représenter un identificateur permettant
de désigner sans ambiguïté une session
SIP.

Max-Forwards: 20
CSeq: 1 INVITE
Content-Length:162
L’émetteur de la requête choisit une
chaîne de caractères unique qu’il
suffixe par le caractère « @ » et par
son nom de host afin de disposer d’un
identificateur globalement unique.

Max-Forwards: 20
CSeq: 1 INVITE
Content-Length:162
Il est constitué par un numéro suivi du
nom de la méthode SIP. Dans
l’exemple, il s’agit de la méthode
INVITE.

Max-Forwards: 20
CSeq: 1 INVITE
Content-Length:162
Le numéro est incrémenté pour chaque
nouvelle méthode SIP émise. Le
numéro de séquence initial choisi dans
l’exemple est 1 mais il est possible de
commencer par n’importe qu’elle
valeur.

Max-Forwards: 20
CSeq: 1 INVITE
Content-Length:162
Le Header Contact permet à l’appelant
d’indiquer l’adresse IP à laquelle il
peut recevoir des messages SIP de la
part de l’appelé directement, sans
implication du proxy server dans le
routage de ces messages.
Obligatoires: To, From, Via, Max-Forwards, Contact, Call-ID et C-Seq

Max-Forwards: 20
CSeq: 1 INVITE
Content-Length:162
Les Headers content type et content
length indiquent que le corps du
message est une structure décrite avec
SDP (Session Description Protocol) et
contient 162 octets.
Obligatoires: To, From, Via, Max-Forwards, Contact, Call-ID et C-Seq

Corps des messages SIP

Scénarios d’appel SIP: Exemple d’établissement
d’appel avec SIP sans serveur
Paramètres SDP Nom de paramètre
v=0 Version du protocole SDP (0)
o=Mary 123456 123456 IN IP4
station1@cegetel.fr
Origine de la session décrite à travers le
username (Mary), l’dentificateur de la session
(123456), la version de la session, le type de
réseau (IN=Internet), le type d’adresse
(IP4=IPv4), et l’adresse réseau de la machaine
où la session a été créée.
s=annonce importante Nom de la session. Il s’agit d’une chaîne de
caractère qui peut être affichée aux participants
de la session.
c= IN IP4 192.190.132.20 Données de connexion incluant le type de
réseau (IN=Internet), le type d’adresse
(IP4=IPv4).
t=0 0 Instant de la session. Il indique les instants de
début et de fin de session.
m=audio 45450 RTP/AVP 0 Type de média (audio), port de transport où la
voix ou la vidéo paquétisée doit être envoyée
(45450), le protocole de transport (RTP) et le
type de format (AVP 0=G.711 -law)
Champs SDP de la requête INVITE dans l’exemple

IPV4 et IPV6
• IPv4 et IPv6 sont deux versions du protocole Internet, utilisées pour identifier et
localiser les dispositifs sur un réseau. La principale différence réside dans le format
des adresses.
• IPv4 utilise des adresses de 32 bits, ce qui offre environ 4,3 milliards d'adresses
uniques. Cela a suffi pendant un certain temps, mais avec l'explosion d'Internet et
le nombre croissant d'appareils connectés, on a réalisé que ces adresses allaient
bientôt manquer.
• C'est là qu'intervient IPv6, avec ses adresses de 128 bits. Cela offre un nombre
astronomique d'adresses uniques (environ 3.4 x 10^38), ce qui devrait suffire pour
tous les appareils imaginables, même ceux que nous n'avons pas encore inventés.
• IPv6 est comme la bibliothèque infinie des adresses IP, tandis qu'IPv4 est un peu
plus comme une bibliothèque avec un nombre fini de livres.

La réponse au message SIP INVITE est le
message 180 RINGING. Cette réponse indique
que le terminal de l’appelé a reçu le message
INVITE et que l’alerte du demandé a été
déclenchée.
Cette alerte du demandé peut être matérialisée par
une sonnerie ou un texte s’affichant sur l’écran du
combiné.

Les réponses SIP sont des nombres dont le
premier chiffre indique la classe de réponse.
1XX signifie « réponse d’information » et donc
informe sur l’état d’avancement de l’appel.

La réponse 180 Ringing a la structure suivante :
SIP/2.0 180 Ringing
Cseq: 1 INVITE
Contact:sip:mark.rich@193.188.23.16
Content-Length: 0
La réponse 180 RINGING est
créée en copiant un certain
nombre des headers du message
INVITE en particulier From,
To, Call-ID, Via et en rajoutant
une ligne de début de réponse
contenant la version du
protocole SIP suivie du type de
réponse.

SIP/2.0 180 Ringing
Cseq: 1 INVITE
Content-Length: 0
Les headers From et To ne sont
pas inversés dans la réponse car
ils indiquent la direction de la
requête et non celle de la
réponse.

SIP/2.0 180 Ringing
Cseq: 1 INVITE
Content-Length: 0
Le Header Contact indique
l’adresse IP où l’appelé peut
directement recevoir des
requêtes SIP sans que celles-ci
soient routées par le proxy
server.

Une réponse 200 OK est retournée à l’appelant
lorsque l’appelé décroche et donc accepte
l’appel.
Les réponses 2XX indiquent que la requête a été
acceptée. Le corps de la réponse 200 OK
contient les informations du média de Mark.

SIP/2.0 200 OK
Via : SIP/2.0/UDP station 1.cegetel.fr :5060
CSeq: 1 INVITE
Content-Type:application/sdp
Content-Length:162
v=0
o=Mark 123456 123456 IN IP4
machine1.telecom-dev.fr
s=annonce importante
c=IN IP 193.188.23.16
m=audio 52140 RTP/AVP 0

Mary doit confirmer la réception de la réponse
200 OK par une requête ACK.
Cette confirmation signifie que Mary peut
supporter le média proposé par Mark.
Toute réponse à une méthode INVITE est
acquittée par une méthode ACK.
Dès lors, les canaux RTP et le canal RTCP sont
ouverts et utilisés par Mary et Mark pour la
communication téléphonique.

ACK sip:mark.rich@telecom-dev.fr SIP/2.0
Max-Forwards: 20
Cseq: 2 ACK
Content-Length: 0

Mary envoie une requête BYE pour terminer la session.
BYE sip:mark.rich@telecom-dev.fr SIP/2.0
Max-Forwards: 20
Cseq: 3 BYE
Content-Length: 0

Mark renvoie la réponse de confirmation suivante:
SIP/2.0 200 OK
CSeq: 3 BYE
Content-Length : 0

d’appel avec SIP avec proxy server
Afin qu’un User agent (dans l’exemple
précédent, Mary) puisse directement envoyer un
message INVITE à un User agent server (dans
l’exemple précédent, Mark), il lui faut connaître
son adresse IP.
Cela n’est pas toujours le cas.

A chaque connexion, cette adresse peut donc
changer pour un terminal donné.
Dans ce cas, c’est le proxy server qui traduira
l’adresse URL du destinataire en une adresse IP.

Dans l’exemple suivant, Mary appelle Mark à travers un
Proxy server. Mary ne connaissant pas l’adresse IP de
Mark, recherche dans le DNS à partir du nom de
domaine de l’URL SIP de Mark (telecom-dev.fr)
l’adresse IP du proxy server qui contrôle ce domaine
(proxy.telecom-dev.fr).
Le message INVITE émis par Mary est donc envoyé à
l’adresse IP du Proxy server du domaine telecom-dev.fr.

INVITE sip :mark.rich@telecom-dev.fr SIP/2.0
Max-Forwards: 20
Cseq: 1 INVITE
Contact : sip :mary.taylor@192.190.131.20
Content-Type : application/sd
Content-Length :162
v=0
o=Mark 123456 123456 IN IP4
c=IN IP 192.190.132.20
t= 0 0

Le Proxy server du domaine telecom-dev.fr recherche
l’URL SIP (mark.rich@telecom-dev.fr) dans sa base de
données ou grâce à un service de localisation et localise
Mark.
Notons que Mark s’est forcément enregistré à la fonction
Registrar de son domaine. Il est donc déclaré dans la
base de données mise à jour par la fonction Registrar.

Le message INVITE est alors relayé par le Proxy
server à l’adresse IP de Mark. Un second header
Via est rajouté, contenant l’adresse du Proxy.
Cela permettra aux réponses retournées par Mark
de suivre le même chemin que celui emprunté
par le message INVITE.

INVITE sip :mark.rich@telecom-dev.fr SIP/2.0
Via: SIP/2.0/UDP proxy.telecom-dev.fr:5060
Max-Forwards: 20
Cseq: 1 INVITE
Contact : sip :mary.taylor@192.190.131.20
Content-Type : application/sd
Content-Length :162
v=0
o=Mark 123456 123456 IN IP4
c=IN IP 192.190.132.20
t= 0 0

La réponse 180 RINGING est retournée par le terminal de Mark au
terminal de Mary à travers le Proxy server.
La réponse reçue par le Proxy server est :
SIP/2.0 180 Ringing
Cseq: 1 INVITE
Contact : sip :mark.rich@193.188.23.16
Content-Length : 0

Le proxy server vérifie que le premier header
Via contient son adresse (proxy.telecom-dev.fr),
supprime ce header et renvoie la réponse à
l’adresse présente dans le header Via suivant
(station1.cegetel.fr) au port UDP 5060.

La réponse reçue par Mary est :
SIP/2.0 180 Ringing
Cseq: 1 INVITE
Content-Length : 0

L’utilisation de headers Via simplifie grandement le relayage
de réponses sans traitement particulier ni accès à des bases de
données.
L’envoi d’une requête a nécessité un accès au DNS par le User
agent client et un accès à une base de données par le Proxy
server.
Par ailleurs, cela permet de s’assurer que les réponses passent
par les mêmes Proxy servers que les requêtes correspondantes.

Lorsque Mark accepte l’appel, la réponse 200 OK est
émise au Proxy server :
SIP/2.0 200 OK
Cseq: 1 INVITE
Content-Type :application/sdp
Content-Length : 162
v=0
o=Mark 123456 123456 IN IP4
c=IN IP 193.188.23.16
t= 0 0

Le proxy server retire le premier header Via contenant son adresse et relaye le
message au terminal de Mary.
Mary retourne un message ACK à Mark relayé par le Proxy server après avoir
rajouté un champ Via comme dans le cas du message INVITE précédent :
ACK sip:mark@telecom-dev.fr SIP/2.0
Cseq: 2 ACK
Content-Length : 0

Le proxy server participe au routage de la
signalisation entre User agents alors que les User
agents établissent directement des canaux RTP
pour le transport de la voix ou de la vidéo
paquetisée sans implication du Proxy server dans
ce transport.

Les réponses SIP
Après avoir reçu et interprété une requête SIP, l’appelé
retourne une réponse SIP. Il existe six classes de
réponses :
• Classe 1xx : Information, la requête a été reçue, et est
en cours de traitement.
• Classe 2xx : Succès, la requête a été reçue, comprise et
acceptée.
• Classe 3xx : Redirection, l’appel requiert d’autres
traitements avant de pouvoir déterminer s’il peut être
réalisé.

Les réponses SIP
• Classe 4xx : Erreur requête client, la requête ne
peut pas être interprétée ou servie par le serveur.
La requête doit être modifiée avant d’être
renvoyée.
• Classe 5xx : Erreur serveur, le serveur échoue
dans le traitement d’une requête apparemment
valide.
• Classe 6xx : Echec global, la requête ne peut
être traitée par aucun serveur.

Les réponses SIP
Les requêtes et réponses SIP contiennent des
adresses émission et destination SIP.
Ces adresses SIP sont des URLs SIP (Uniform
Ressource Locator) et ont une forme similaire à
une adresse e-mail c’est-à-dire user@host.

Les réponses SIP
• La partie user est identifiée soit par un nom,
soit par un numéro de téléphone.
• La partie host est représentée soit par un nom
de domaine, soit par une adresse de réseau.

Les méthodes SIP
La version 2.0 du protocole SIP est constituée de
six méthodes (RFC 3261) : INVITE,
REGISTER, BYE, ACK, CANCEL et
OPTIONS. Huit méthodes supplémentaires ont
été rajoutées au protocole. Ces méthodes sont
SUBSCRIBE (RFC 3265), NOTIFY (RFC 3265)
REFER (RFC 3515), MESSAGE (RFC 3428),
INFO (RFC 2976), PRACK (RFC 3262) et
UPDATE (RFC 3311).

Les méthodes SIP
Une entité SIP peut souscrire à un événement
afin d’être notifiée de son occurrence.
La requête SUBSCRIBE permet la souscription
alors que la requête NOTIFY est utilisée afin de
notifier l’occurrence de l’événement souscrit.

Les méthodes SIP
La méthode REFER renvoie le récepteur vers
une ressource identifiée dans la méthode.
REFER permet d’émuler différents services ou
applications dont le transfert d’appel.

Les méthodes SIP
La méthode MESSAGE permet le transfert de
messages courts et ainsi permet d’émuler le
service SMS avec le protocole SIP.

Les méthodes SIP
La méthode INFO permet de transférer des
informations de signalisation durant l’appel.

Les méthodes SIP
La méthode PRACK permet d’acquitter la
réception de réponses provisoires.

Les méthodes SIP
La méthode UPDATE permet à un user agent de
mettre à jour les paramètres d’une session
multimédia. (e.g., flux média et leurs codecs),
avant qu’elle soit établie.

Les méthodes SIP: Méthode INVITE
La méthode INVITE permet l’établissement
d’une session entre User agents.
Cette méthode est similaire au message SETUP
du protocole de signalisation Q.931 ou IAM du
protocole ISUP. Une réponse finale à une
méthode INVITE (e.g., 200 OK) est acquittée
par une requête ACK.

Une invitation SIP réussie est constituée d’une
requête INVITE suivie par ACK ; La requête
INVITE demande à l’appelé de rejoindre une
conférence particulière ou un appel téléphonique.
Après que l’appelé ait décidé de participer à
l’appel (il répond par 200 OK), l’appelant confirme
la réponse à l’appelé en lui envoyant une méthode
ACK.

Dans une requête INVITE figurent les
différentes informations qui permettent à
l’appelé de se joindre à la session.
L’appelé répond en retournant des informations
sur le type de média qu’il veut utiliser.

Si une requête INVITE ne contient pas
l’information concernant le média décrite par le
biais du protocole SDP (Session Description
Protocol)
 alors la méthode ACK la contiendra.

La méthode INVITE contient un header Call-ID
unique utilisé pour la durée de l’appel.
Les messages SIP envoyés dans le contexte de cet
appel ont un header Call-ID ayant la même valeur.
Un header Cseq doit être initialisé à une valeur
entière qui n’est pas nécessairement 1.
Cseq est incrémenté pour toute nouvelle requête
pour le même Call-ID.

Les headers From et To renseignent l’adresse
SIP de l’appelant et de l’appelé respectivement.

Si l’émetteur d’une requête INVITE souhaite
modifier les caractéristiques de la session, il
renvoie alors une nouvelle requête INVITE qui
contient le même Call-ID que celui de la requête
INVITE précédente, mais un Cseq dont la valeur a
été incrémentée.
Cela permet au récepteur de différencier les deux
requêtes INVITE.

Les méthodes SIP: Méthode ACK
• La méthode ACK est utilisée afin d’acquitter les
réponses finales de requêtes INVITE.
• L’émetteur de la méthode INVITE, à la réception
de la réponse 200 OK, envoie la méthode ACK.
• Cette requête ACK peut contenir un corps de
message si le message INVITE n’a pas fourni de
description de média.

Les méthodes SIP: Méthode REGISTER
La méthode REGISTER est utilisée par un User
agent afin d’indiquer à la fonction Registrar
(physiquement implantée dans un Proxy server ou
Redirect server) son adresse IP courante et son URL
SIP pour laquelle il souhaite recevoir des appels.
Cette méthode est similaire au message
RegistrationRequest (RRQ) du protocole RAS H.323.

Si un usager SIP veut renvoyer ses appels de son
domaine courant à un autre domaine (e.g., du
domaine cegetel.fr au domaine
francetelecom.com), il lui suffit d’indiquer à la
fonction Registrar son adresse SIP du domaine
francetelecom.com.

L’enregistrement SIP n’est pas requis pour
permettre à un User agent d’utiliser un Proxy
server afin d’effectuer des appels sortants.
Par contre, un User agent doit s’enregistrer pour
recevoir des appels entrants de Proxy servers.

Exemple d’enregistrement avec SIP

Mary s’identifie sur la
machine station1.cegetel.fr.
Une méthode REGISTER a
alors été mise à la fonction
Registrar locale

Le champ Via de la méthode
contient le chemin suivi par
la requête jusque-là.

Il contient donc l’adresse de
la station de Mary. Le champ
Via indique par ailleurs que la
méthode REGISTER est
transportée par le protocole
UDP.

Le Header Max-Forwards
indique le nombre maximum
de proxy servers pouvant
router la méthode
REGISTER.

Le header From indique
l’adresse de l’entité ayant
initié l’enregistrement. Il
s’agit de Mary. Le header To
indique l’adresse de
l’utilisateur enregistré

L’adresse de la fonction
REGISTRAR n’est indiquée
que dans la première ligne de
la commande REGISTER.

Un User agent utilisera un
même Call-ID pour
l’ensemble de ses
enregistrements.

Le header Expires est
optionnel et exprime une
durée d’enregistrement

S’il est absent, alors l’URL
SIP sera supprimé de la table
d’enregistrement de la
fonction Registrar au bout
d’une heure après
l’enregistrement.

La fonction Registrar
retourne une réponse 200 OK
en cas de succès de
l’enregistrement.

Les headers Via, From, To,
Call-ID et Cseq ont la même
valeur que dans la requête
REGISTER ;

Le header Expires de la
réponse 200 OK peut
indiquer une valeur égale ou
inférieure à celle spécifiée
dans la requête REGISTER ;

Le champ Contact indique les
différentes adresses
auxquelles l’usager SIP est
joignable.

Exemple d’enregistrement sur plusieurs terminaux
Un utilisateur
peut s’enregistrer
sur plusieurs
terminaux

Dans ce cas, les
méthodes INVITE à
délivrer à cet
utilisateur sont
relayées vers tous
les terminaux
auxquels il s’est
enregistré.

Pour annuler un
enregistrement avant
l’expiration, il suffit
d’envoyer une
commande REGITER à
la fonction Registrar
avec un header Expires
dont la valeur est
positionnée à 0.

Pour annuler son
enregistrement de tous
les terminaux, il faut
positionner la valeur
Expires de la requête
REGISTER à la valeur
0 et indiquer dans le
champ Contact la
valeur « * ».

Les méthodes SIP: Méthode CANCEL
La méthode CANCEL est utilisée pour
suspendre une requête en cours mais n’a aucun
effet sur une requête déjà exécutée.
Si un utilisateur s’est enregistré sur différents
terminaux SIP, alors son adresse SIP sera
traduite en plusieurs adresses SIP.

Un Proxy server ayant à délivrer un appel à cet
utilisateur, enverra la requête INVITE reçue à
tous les terminaux auprès desquels l’utilisateur
s’est enregistré.

Utilisation de la requête CANCEL dans le cas où l’appelé s’est enregistré sur
plusieurs terminaux

plusieurs terminaux
Mark s’est enregistré
sur le Terminal 2 (T2)
et le Terminal 3 (T3).

plusieurs terminaux
Mary envoie une
méthode INVITE au
Proxy Server
proxy.telecom-dev.fr
pour établir un appel
téléphonique avec
Mark.

plusieurs terminaux
Ce Proxy server
duplique le message
INVITE et le délivre aux
terminaux T2 et T3
après avoir identifié leur
adresse IP.

plusieurs terminaux
le Proxy server retourne
au terminal de Mary
(T1) une réponse 100
Trying indiquant que la
commande de Mary est
en cours de traitement.

plusieurs terminaux
Cette réponse a la même
signification que le
message Call
Proceeding du protocole
Q.931.

plusieurs terminaux
T2 et T3 retournent au
Proxy server des
réponses 180 Ringing.

plusieurs terminaux
Le Proxy server renvoie
alors une réponse 180
Ringing à T1 pour
l’informer que l’alerte
du demandé a été
déclenchée (équivalent
au message Alerting du
protocole Q.931).

plusieurs terminaux
Lorsque Mark accepte
l’appel sur un des
terminaux (dans
l’exemple, T3), alors T3
retourne la réponse 200
OK contenant la
description du média de
Mark

plusieurs terminaux
ce message est relayé à
T1

plusieurs terminaux
Le Proxy server émet
alors une commande
CANCEL pour annuler
la commande INVITE
en cours sur T2.

plusieurs terminaux
A la réception du
message CANCEL, T2
arrête le traitement de la
demande INVITE et
retourne une réponse
pour confirmation 200
OK.

plusieurs terminaux
Mary émet une requête
ACK pour confirmer à
Mark la réception de la
réponse 200 OK et
l’acceptation du média
proposé par Mark.

plusieurs terminaux
Ce message reçu par le
Proxy server est relayé à
Mark.

Les méthodes SIP: Méthode BYE
Un user agent souhaitant terminer un appel émet
une requête BYE. Toute partie (User agent)
participant à un appel peut envoyer une méthode
BYE, mais pas un Proxy server.
A la réception de cette requête, un User agent server
doit arrêter de transmettre des données (e.g.,
paquets RTP) à la partie lui ayant envoyé la requête
BYE, et retourne une réponse positive 200 OK.

Exemple:
Mary libère la session établie avec Mark. La requête BYE incrémente
toujours le header Cseq.
Les headers obligatoires de la commande BYE sont Call-ID, Content-
Length, Cseq, From, To et Via.
Le Header From spécifie l’adresse SIP de l’émetteur de la requête BYE
et non l’émetteur de la requête INVITE. Le Header To indique l’adresse
du récepteur de la requête BYE.
La valeur du header Call-Id est commune aux requêtes BYE et INVITE.

BYE sip :mark.rich@telecom-dev.fr SIP/2.0
Max-Forwards: 20
From: Mary Taylor<sip:mary.taylor@cgetel.fr>
To: Mark rich<sip:mark.rich@telecom-dev.fr>
Cseq: 3 BYE
Content-Length: 0

Mark renvoie la réponse de confirmation suivante:
SIP/2.0 200 OK
Cseq: 2 BYE
Content-Length: 0

Les méthodes SIP: OPTIONS
La méthode OPTIONS est utilisée par un User agent
afin d’interroger les capacités d’un User agent ou d’un
serveur et de connaître sa disponibilité.
Un Proxy server ne génère jamais de méthode
OPTIONS.
Un User agent ou serveur répond à une requête
OPTIONS par 200 OK qui peut contenir les headers
(optionnels) Allow, Accept, Accept-Encoding, Accept-
Language et Supported afin d’indiquer ses capacités.

• Allow : En SIP, l'en-tête Allow est utilisé pour
spécifier les méthodes SIP autorisées pour une
ressource. Par exemple, les méthodes SIP incluent
INVITE, ACK, OPTIONS, BYE, CANCEL, etc.
L'en-tête Allow dans une réponse SIP indique
quelles méthodes sont permises pour la ressource ou
l'entité contactée.
• Accept : Dans le contexte de SIP, l'en-tête Accept
est utilisé pour indiquer les types de médias que
l'entité SIP est capable de traiter. Il spécifie les types
de contenu (comme les codecs audio ou vidéo) que
l'entité peut accepter dans une session SIP.

• Accept-Encoding : spécifier des méthodes de
compression de données dans le protocole SIP.
• Accept-Language : En SIP, cet en-tête est utilisé pour
indiquer les langues que l'utilisateur SIP ou
l'équipement peut comprendre. Cela peut être pertinent
lors de l'établissement de sessions de communication
où différentes langues peuvent être utilisées.
• Supported : Dans SIP, l'en-tête Supported est utilisé
pour indiquer les fonctionnalités ou les extensions que
le client ou le serveur SIP supporte. Cela permet à
deux entités SIP de négocier les fonctionnalités
qu'elles peuvent utiliser pendant une session.

Mary demande à Mark ses capacités :
OPTIONS sip :mark.rich@telecom-dev.fr SIP/2.0
Max-Forwards: 20
Cseq: 1 OPTIONS
Content-Length: 0

La réponse 200 OK à la requête OPTIONS est retournée par Mark à Mary et inclut les
headers Allow et Accept-Language.
SIP/2.0 200 OK
Cseq: 1 OPTIONS
Allow: INVITE, OPTIONS, ACK, BYE, CANCEL
Accept-Language: fr, en
Supported:…
Accept-Encoding : …
Content-Length: 0

Les méthodes SIP: SUBSCRIBE ET NOTIFY
Une entité SIP peut souscrire à un événement
afin d’être notifiée de son occurrence.
La requête SUBSCRIBE permet la souscription
alors que la requête NOTIFY est utilisée afin de
notifier.

Une requête SUBSCRIBE doit contenir un header
« expires » qui indique la durée de la souscription.
Si le souscripteur souhaite que la requête
SUBSCRIBE soit effective au-delà de la durée
indiquée dans le header « expires », il lui
nécessaire de retransmettre périodiquement une
nouvelle requête SUBSCRIBE.

La réponse 200 OK à la demande SUBSCRIBE
qui acquitte la prise en compte de cette requête
doit aussi contenir un header « expires ».
Afin d’annuler sa souscription, il suffit d’émettre
un message SUBSCRIBE dont la valeur du
header « expires » est égale à 0.

Une requête SUBSCRIBE doit aussi inclure un
header « Event » indiquant l’événement auquel
l’émetteur de la requête souhaite souscrire.
La requête NOTIFY qui notifie l’occurrence de
l’événement contient le même header « Event ».

Lorsqu’une requête SUBSCRIBE est reçue et
acquittée par un 200 OK, le récepteur du
SUBSCRIBE doit immédiatement générer et
émettre une requête NOTIFY au souscripteur,
communiquant ainsi l’état de la ressource.
Une réponse « 202 Accepted » indique que la
méthode SUBSCRIBE a été reçue et comprise,
mais n’a pas encore été prise en compte.

Une requête NOTIFY doit contenir un header « Subscription-State »
dont la valeur est « active », « pending », ou « terminated ».
La valeur « active » indique que la souscription a été acceptée et
autorisée.
La valeur « pending » indique que la demande de souscription a été
reçue mais qu’il n’est pas encore possible de l’accepter ou de la
refuser.
La valeur « terminated » indique que la souscription n’est pas active ;
elle a donc été supprimée.

Service de rappel automatique sur occupation
Considérons le cas
où UA 1 souhaite
établir un appel
téléphonique avec
UA 2, occupé

UA1 émet une
méthode SIP
INVITE à UA2

UA2 étant occupé, il
retourne à UA1 une
réponse finale 486
Busy Here.

UA1 acquitte la
réponse finale de
UA2 par la
méthode ACK.

UA1 souhaitant être informé
par UA2 lorsqu’il sera de
nouveau disponible, souscrit à
l’occurrence de l’événement
« Available » en utilisant la
méthode SUBSCRIBE qui est
acquittée par une réponse 200
OK.

Une première requête NOTIFY
suit immédiatement indiquant
que la requête SUBSCRIBE a
été acceptée et que l’état de
UA2 est « BUSY ». La
méthode NOTIFY est acquittée
par 200 OK.

Lorsque UA2 raccroche, son
état devient « Available » , ce
qui le conduit à transmettre une
requête NOTIFY à UA1,
acquittée par une réponse 200
OK.

UA1 peut établir la session
audio avec UA2 à travers une
séquence INVITE/180
RINGING/200 OK/ACK.

Les méthodes SIP: MESSAGE
La messagerie instantanée (IM, Instant Messaging)
consiste en l’échange de message entre usagers en pseudo
temps réel.
Ces messages sont généralement courts.
La messagerie instantanée est utilisée en mode
conversationnel, i,e., l’échange de messages entre les
usagers est rapide afin de maintenir une conversation
interactive.

Les messages instantanés ne sont généralement
pas stockés (à la différence des SMS dans le
monde GSM).
ce stockage n’est pas « forcément » nécessaire.

il est possible d’introduire un serveur de
messagerie instantanée réalisant la fonction
similaire à un SMSC (Short Message Service
Center) dans un réseau mobile.

La méthode MESSAGE a été proposée comme extension au
protocole SIP afin de permettre le transfert de messages
instantanés.
Cette nouvelle méthode hérite de toutes les fonctions offertes
par le protocole SIP telles que le routage et la sécurité.
La méthode MESSAGE n’initie pas de session à la différence
de la méthodes INVITE; il s’agit d’un message isolé.

Une méthode MESSAGE peut traverser une route
de signalisation constituée d’un ensemble de
Proxy Server avant d’être délivrée à la destination.
Une réponse 200 OK est retournée par la
destination si elle accepte la méthode MESSAGE
mais cela ne signifie pas pour autant que la
destination a lu son contenu.

La taille maximale d’un message instantané ne doit pas
excéder 1300 octets.
Pour des contenus volumineux, l’URL où le contenu est
accessible pourrait être indiquée dans le corps de la
méthode MESSAGE.
Le contenu pourrait être téléchargé par le destinataire de
la méthode MESSAGE en utilisant le protocole HTTP.

Echange d’un message instantané entre deux UAs
connectés
exemple de transfert de
message instantané
lorsque les deux
participants sont
connectés.

L’émetteur transmet une méthode MESSAGE dont la structure
est la suivante :
MESSAGE sip:mark.rich@francetelecom.com SIP/2.0
Via: SIP/2.0/UDP 192.190.132.20:5060
Max-Forwards: 20
To: Mark rich<sip:mark.rich@francetelecom.com>
From: Mary Taylor<sip:mary.taylor@alcatel.com>
Call-Id: 12345678@192.190.132.20
Cseq: 1 MESSAGE
Contact: sip: mary.taylor@192.190.132.20
Content-Type: text/plain
Content-Length: 24
Mark, How are you today?

connectés
Cette requête est reçue
par le Proxy Server du
domaine alcatel.com
(domaine de l’émetteur)

connectés
Ce dernier cherche dans le
DNS à partir du nom de
domaine de l’URL SIP du
destinataire
(francetelecom.com) l’adresse
IP du Proxy server qui contrôle
ce domaine
(proxy.francetelecom.com).

connectés
La méthode MESSAGE est
relayée à ce proxy server qui
interroge la base de données de
localisation du domaine
francetelecom, obtient
l’adresse IP du User Agent
destinataire et lui délivre la
méthode MESSAGE.

connectés
Une réponse 200 OK est
retournée par la destination
pour indiquer qu’elle accepte
la méthode MESSAGE.

La structure de cette réponse 200 OK reçue par
l’émetteur est la suivante :
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.190.132.20:5060
To: Mark rich<sip:mark.rich@francetelecom.com>
From: Mary Taylor<sip:mary.taylor@alcatel.com>
Call-Id: 12345678@192.190.132.20
Cseq: 1 MESSAGE
Content-Length: 0

Les méthodes SIP: REFER
La méthode REFER renvoie le récepteur vers
une ressource identifiée dans la méthode.
REFER permet d’émuler différents services ou
applications dont le transfert d’appel.

Considérons UA1, l’entité à l’origine du transfert, UA2, l’entité
transférée et UA3, le destinataire du transfert.
Le transfert d’appel permet à UA1de transformer un appel en
cours entre UA1 et UA2 en un nouvel appel entre UA2 et un
UA3 choisi par UA1.
Si le transfert d’appel aboutit, UA2 et UA3 pourront
communiquer tandis que UA1 ne pourra plus dialoguer avec
UA2 ou UA3.

Exemple de transfert d’appel
UA2 établit une
communication
téléphonique avec UA1.

UA1 émet une méthode
REFER à UA2 afin que
ce dernier établisse une
nouvelle communication
avec UA3

UA1 libère l’appel avec
UA2

UA2 établit un nouvel
appel avec UA3

notifie UA1 dès lors que
l’appel est effectif entre
UA2 et UA3

Si le transfert n’aboutit pas,
UA2 peut établir une
nouvelle communication
avec UA1.

La méthode REFER identifie par le biais du header
« Refer-To » la ressource vers laquelle établir l’appel.
Ce header peut indiquer une adresse autre qu’une
URL SIP, e.g., adresse URL HTTP.
Dans ce dernier cas, l’UA2 télécharge une page WEB.
L’UA1 émet une méthode REFER Refer-To
http://www.yyy.com/page1.html afin de demander à
l’UA2 de télécharger la page 1

la méthode REFER identifie l’URL SIP de l’UA3 :
REFER Refer-To<sip : yyy.alcatel.com>.
Le header « Refer-To » peut contenir le type de méthode,
la méthode par défaut étant INVITE.
Une requête REFER peut être émise par UA1 à UA2 afin
de lui demander par exemple une libération d’appel (BYE)
plutôt qu’un établissement d’appel : REFER Refer-To
<sip : yyy.alcatel.com ; method=BYE>.

Les méthodes SIP: INFO
La méthode INFO permet de transférer des
informations de signalisation durant l’appel;
Parmi les exemples d’information figurent les
informations relatives à la taxation d’un appel;
La méthode INFO n’a pas pour but de changer l’état
en cours ou des paramètres de l’appel.

La route de signalisation empruntée par la
requête INFO est la même que celle utilisée par
les requêtes SIP utilisées pour l’établissement de
l’appel correspondant (e.g., INVITE, ACK).

Une des réponses suivantes est retournée par le destinataire
de la requête INFO :
• 200 OK si la requête INFO est applicable à un appel,
• 481 Call Leg/Transaction Does Not Exist, si la requête
INFO ne correspond à aucun appel en cours,
• 415 Unsupported Media Type Message si la requête
INFO contient un corps de message que le récepteur ne
sait pas interpréter.
• 4xx, 5xx et 6xx comme pour les autres méthodes SIP.

Les méthodes SIP: PRACK
Les réponses finales 2XX, 3XX, 4XX, 5XX et
6XX à une requête INVITE sont acquittées par la
requête ACK alors que les réponses provisoires de
type 1XX ne sont pas acquittées.
certaines réponses provisoires telles que 180
Ringing ou 183 SessionProgress sont critiques et
leur réception est essentielle pour la détermination
de l’état de l’appel.

La méthode PRACK a donc été définie afin
d’acquitter la réception de réponses provisoires
de type 1XX, sauf 100 Trying.
Seules les réponses provisoires comprises entre
101 et 199 peuvent être acquittées.

Si un UA reçoit une requête INVITE contenant le header « Require » dont la
valeur est 100rel, il doit émettre toute réponse provisoire (e.g., 180 Ringing ,
183 Session Progress) de manière fiable.
S’il ne le peut pas, il doit rejeter la demande en retournant une réponse « 420
Bad Extension » contenant un header « Unsupported » dont la valeur est
100rel.
L’émetteur de la méthode INVITE devra alors retransmettre cette méthode
sans header « Require ».
Remarque: 100rel: 100 (1xx doivent être acquittées par PRACK) / rel
(reliable (fiable))

Si un UA reçoit une requête INVITE contenant le
header « Supported » dont la valeur est 100rel, il
peut émettre s’il le souhaite toute réponse
provisoire de manière fiable.
Enfin, il ne doit pas émettre de réponse provisoire
de façon fiable si la méthode INVITE reçue ne
contient pas de header « Require » ou
« Supported ».

Exemple d’utilisation de PRACK pour l’acquittement des
réponses provisoires
UA souhaite émettre une
réponse provisoire de
manière fiable

La réponse provisoire (e.g.,
180 Ringing) doit contenir un
header « Require » dont la
valeur est 100rel et un header
« Rseq » qui correspond à un
numéro de séquence fiable,
dont la valeur est choisie
initialement de manière
aléatoire entre 1 et 223
-1.

Cette valeur doit être
incrémentée de 1 à chaque
envoi d’une nouvelle réponse
provisoire.

Si le temporisateur expire
avant qu’une requête
PRACK soit reçue, la
réponse 180 Ringing doit être
retransmise

La requête PRACK doit être
acquittée par une réponse
200 OK qui aura pour effet
d’annuler toute
retransmission de la requête
PRACK

l’émetteur de la requête
PRACK arme un
temporisateur T1 dès son
envoi. Si aucune réponse
n’est reçue avant l’expiration
de ce temporisateur, la
méthode PRACK doit être
retransmise.

Une méthode PRACK doit
contenir un header
« RACK » qui doit contenir
les valeurs des headers
« Cseq » et « Rseq » présents
dans la réponse provisoire
permettant de corréler la
requête PRACK et la réponse
provisoire qu’elle acquitte.

Les méthodes SIP: UPDATE
• La méthode UPDATE permet à un usager agent de
mettre à jour les paramètres d’une session multimédia
(e.g., flux média et leurs codecs) avant son
établissement.
• Lorsqu’un UA émet une méthode INVITE, elle doit
contenir un header « Allow » dont la valeur doit
contenir « UPDATE » pour indiquer sa capacité à
recevoir des méthodes UPDATE.

• Cela vaut aussi pour le récepteur lorsque ce
dernier retourne une réponse provisoire fiable.
• Cette information permettra d’indiquer à
l’émetteur que la destination a la capacité de
supporter une procédure UPDATE.

Scénario d’établissement d’appel utilisant la
méthode UPDATE
INVITE contenant une
description SDP1 pour
établir une session avec
UA2.
Cette description SDP indique des
préconditions de QoS pour la
session

méthode UPDATE
UA1 ne souhaite pas que
UA2 soit alerté tant que les
ressources n’ont pas été
réservées dans les deux
sens.

méthode UPDATE
UA2 accepte de réserver
des ressources pour cette
session avant d’alerter
l’appelé

méthode UPDATE
UA2 prend en charge la
réservation des ressources
dans le sens UA2UA1
Par ailleurs, il est nécessaire que
UA1 réserve des ressources dans
le sens UA1 UA2

méthode UPDATE
UA2 retourne une réponse
provisoire 183 Session
Progress à UA1 lui
demandant de commencer
la réservation des
ressources et de confirmer
à UA2 dès que la session
est prête dans le sens
UA1UA2.

méthode UPDATE
Cette réponse provisoire
contient aussi une
description SDP2

méthode UPDATE
A la réception du 183
Session Progress, UA1
émet une méthode PRACK
acquittée par 200 OK

méthode UPDATE
UA1 et UA2 commencent
la réservation de ressources

méthode UPDATE
Lorsque UA1 a finalisé sa
procédure de réservation, il
émet un message UPDATE
à UA2 contenant une
description SDP3 qui
indique cette réservation
dans le sens UA1UA2.

méthode UPDATE
UA2 retourne une
réponse 200 OK de
confirmation de la
méthode UPDATE,
indiquant que toutes les
préconditions de QoS
pour la session ont été
remplies et que la QoS a
bien été réservée dans les
deux sens.

méthode UPDATE
UA2 alerte l’appelé. Une
réponse provisoire 180
Ringing est émise par
l’UA2 à l’UA1

méthode UPDATE
Pour informer l’UA2 de sa
réception, un échange de
messages PRACK et 200
OK a lieu, l’appelé
décroche

méthode UPDATE
UA2 retourne une réponse
200 OK (réponse à la
méthode INVITE)

méthode UPDATE
ACK afin de finaliser
l’établissement d’appel.

méthode UPDATE
L’échange de média peut
donc avoir lieu entre les
deux participants à la
session.

Headers de messages SIP
• Les en-têtes généraux (general header) s’appliquent
à la fois aux messages de requêtes et de réponse.
• Ils contiennent l’information de base nécessaire au
traitement de la requête. Parmi ces headers, figurent
Accept, accept-Encoding, Accept-Language, CALL-
ID, Contact, Cseq, Date, Encryption, Expires, From,
Record-Route, Timestamp, To et Via.

• Les en-têtes de requête (request header) autorisent
le client à ajouter des informations concernant sa
requête et lui-même à destination du serveur.
• Les headers suivants appartiennent à ce type :
Authorization, Contact, Hide, Max-Forwards,
Organization, Priority, Proxy-Authorization,
Proxy-Require, Route, Require, Response-Key,
Subject et User-Agent

• Les en-têtes de réponse (response header)
autorisent le serveur à ajouter des informations
concernant sa réponse.
• Ces en-têtes sont Allow, Proxy-Authorization,
Retry-After, Server, Unsupported, Warning et
WWW-Authenticate.

• Les en-têtes d’entité (entity header) définissent
le type et le format des informations contenues
dans le corps du message.
• Ces en-têtes sont Content-Encoding, Content-
Length et Content-Type.

Headers de messages SIP: Présence des headers dans les
commandes SIP
 Le caractère « * »
indique que les headers
sont nécessaires
uniquement dans le cas
où le corps du message
n’est pas vide;
 Le caractère « O »
signifie optional;
 Le caractère « M »
mandatory (obligatoire);

commandes SIP

réponses SIP

Les serveurs SIP: Le proxy server
• Le Proxy server reçoit des requêtes SIP d’un
User agent et les relaye à la destination.
• Un Proxy server dispose d’un accès à une base
de données ou à un service de localisation afin
de déterminer le nœud suivant sur la route vers
la destination (Base de données mise à jour par
la fonction Registrar).

• Un Proxy server ne génère pas de méthodes
SIP à la différence d’un User agent.
• Par ailleurs, il ne traite pas de média et n’a pas
d’implication dans l’échange de données audio
ou vidéo entre participants de l’appel.

• Un Proxy server peut être de type stateless ou
stateful.
• Un stateless Proxy server traite chaque requête ou
réponse SIP à partir du contenu du message.
• Une fois le message relayé, aucune information
concernant ce message n’est stockée.
• Un stateless Proxy server ne maintient aucun
temporisateur et n’est donc pas en mesure de
retransmettre un message.

Dès que le proxy transmet le message, il oublie
tout, il ne fait que transférer le message et ne se
souvient de rien.
On limite la charge du proxy server

Cela semble évident, mais parce qu'un proxy
stateless (sans état) est sans état, il ne stocke
pas d'état, mais cela signifie également qu'il n'a
pas besoin de rechercher des informations
d'état ou de les réécrire;
 ce qui le rend beaucoup plus rapide et
généralement capable de gérer des charges
d'appels plus importantes qu’un équivalent
avec état.

• Un stateful Proxy server garde une trace des
requêtes et réponses relayées et utilise cette
information mémorisée afin de traiter les
messages à venir.
• Le stateful Proxy server arme un temporisateur
lors de l’envoi d’une requête et retransmet la
requête s’il n’a pas reçu de réponse avant
l’expiration de ce temporisateur.

Un proxy stateful (avec état) de dialogue
conserve les informations d'état pendant la durée
de cette session (dialogue).

Si nous voulons facturer en fonction de la durée
d'un appel/d'une session, nous aurions besoin de
stocker des informations d'état, comme l'ID
d'appel, l'heure de début et de fin de l'appel.
Nous ne pouvons le faire qu'avec un proxy stateful
(avec état), car un proxy stateless (sans état) ne
saurait pas à quelle heure l'appel a commencé.

De plus, si nous voulions savoir si un utilisateur
était en appel ou non, un proxy Dialog Stateful sait
qu'il y a eu un 200 OK, mais pas encore Bye;
donc il sait si un utilisateur est en appel ou non,
c'est utile pour la présence.
Un proxy avec état de dialogue est le plus
gourmand en ressources, car il doit stocker l'état
pendant toute la durée de la session.

• Un stateful proxy server envoie généralement une réponse 100 Trying pour
informer l’appelant que sa requête INVITE est en cours de traitement.

• Un stateless proxy server n’émet jamais de réponse 100 Trying.

Les serveurs SIP: Le Redirect server
• Le Redirect server reçoit des requêtes mais ne traite
que le header contenant l’adresse SIP du
destinataire (To).
• A partir de celle-ci, il renvoie à l’émetteur de la
requête une liste des adresses correspondantes.
• Ce type de serveur n’initie pas lui-même de
requêtes, et ne peut pas être destinataire d’un appel.

Le Redirect server comme le Proxy server dispose
d’une base de données ou d’un service de localisation
pour déterminer l’adresse du destinataire qu’il retourne
dans un header Contact de la réponse.
Cette réponse du Redirect server est de type 3XX

Considérons l’exemple où Mary ne connaissant pas l’adresse IP de Mark
envoie le message INVITE à un Redirect server.
INVITE : sip : mark.rich@telecom-dev.fr SIP/2.0
Maw-Forwards: 20
Cseq: 1 INVITE
Content-Type: application/sd
Content-Length: 162
v = 0
o = Mary 123456 123456 IN
IP4 station1@cegetel.fr
s = appel téléphonique
c = IN IP4 192.190.132.20
t = 0 0
m = audio 45450 RTP/AVP 0

La réponse de redirection (301) à la requête INVITE est retournée
par le Redirect server à Mary.
SIP/2.0 301 Moved Permanently
Cseq: 1 INVITE
Contact: sip: mark.rich@193.188.23.16
Content-Length: 0

Mary confirme la reception de la réponse 301 (Réponse finale à une requête
INVITE) par l’envoi d’une requête ACK à destination du Redirect server.
ACK sip : mark.rich@telecom-dev.fr SIP/2.0
Maw-Forwards: 20
From: Mark Taylor<sip:mary.taylor@cegetel.fr>
Cseq: 2 ACK
Content-Length: 0

Un nouveau message INVITE est alors généré par Mary avec un nouveau
Call-ID, qu’elle envoie directement à Mark.
INVITE : sip : mark.rich@193.188.23.16 SIP/2.0
Maw-Forwards: 20
Cseq: 3 INVITE
Content-Length: 162
v = 0
o = Mary 123456 123456 IN IP4
station1@cegetel.fr
s = appel téléphonique
c = IN IP4 192.190.132.20
t= 0 0
m = audio 45450 RTP/AVP 0

Les réponses 180 Ringing et 200 OK sont retournées directement par Mark à
Mary ; Mary acquitte la réponse 200 OK par une requête ACK envoyée
directement à Mark.
Utilisation du Redirect server SIP

Interfonctionnement entre SIP/RTC
Pour l’interfonctionnement entre RTC et SIP, il est
nécessaire d’introduire un Gateway RTC/SIP qui
s’interface d’une part au RTC et d’autre part à réseau
SIP. Ce Gateway a deux fonctions :
– Traduction de la signalisation ISUP en
signalisation SIP et inversement.
– Conversion des signaux en paquets RTP et
inversement ; en effet ce Gateway établit des
canaux logiques RTP avec le terminal SIP et établit
des circuits de parole avec un Class switch.

Interfonctionnement RTC/SIP
un terminal relié au
RTC appelle un
terminal SIP. Le Class
5 Switch auquel est
rattaché l’appelant,
émet un message ISUP
IAM(Initial address
Message) au Gateway
RTC/SIP.

Ce message contient le
numéro du
destinataire,
l’identificateur de
circuit choisi par le
Class 5 Swicth pour
l’appel (CIC, Circuit
Identification Code)
ainsi que des
informations indiquant
la nature de l’appel
(parole, fax, données,
etc.).

Le Gateway RTC/SIP
traduit ce message en
une requête SIP INVITE
qui contient une adresse
de destination SIP dont
le champ user est un
numéro de téléphone.

Il passe le message au
SIP Proxy server qui
obtient l’adresse IP du
destinataire à partir de
l’adresse SIP par
interrogation d’une
base de données ou
d’un serveur de
localisation.

Le message INVITE est
relayé au terminal SIP.
Parallèlement, le Proxy
server notifie au
Gateway la réception
de la requête INVITE
par la réponse 100
Trying.

Le terminal SIP
retourne au Proxy
server une réponse 180
Ringing pour informer
l’appelant de l’alerte
de l’appelé, message
relayé par le Proxy
server au Gateway.

Le Gateway traduit
cette réponse en un
message ISUP ACM
(Address Complete
Message) renvoyé au
Class 5 Switch.

Lorsque l’appelé
décroche, une réponse
200 OK est retournée au
Proxy server qui la
relaye au Gateway.

Le Gateway acquitte la
réception de cette
réponse par une requête
ACK acheminée par le
Proxy server au
destinataire.
Parallèlement, le
Gateway génère un
message ISUP ANM
(Answer Message) émis
au Class 5 Switch.

Cet échange de
signalisation a permis
l’établissement de
canaux RTP entre le
terminal SIP et le
Gateway et la mise en
place d’un circuit de
parole entre le
Gateway et le Class 5
Switch.

Interfonctionnement entre SIP/H.323
Une entreprise peut disposer de PCs utilisant la
signalisation H.323 et de nouveaux téléphones
IP basés sur le protocole de signalisation SIP.
Pour permettre l’établissement de sessions entre
ces terminaux H.323 et SIP, il est nécessaire
d’introduire un Gateway H.323/SIP.

Interfonctionnement H.323/SIP

Ce Gateway traduit la signalisation H.323 en la
signalisation SIP et inversement.
Par contre les canaux RTP sont établis
directement entre les terminaux, soit établis entre
chaque terminal et le Gateway.

L’appelant (terminal
H.323) émet un message
RAS AdmissionRequest
(ARQ) au Gatekeeper
(GK) auprès duquel il s’est
enregistré pour lui
demander l’autorisation
d’établir une session.

Le GK répond
positivement par un
message AmissionConfirm
(ACF) indiquant au
terminal H.323 d’envoyer
directement au
destinataire (ici le GW) la
signalisation d’appel
Q.931.

Le terminal H.323 émet un
message Setup au GW en
utilisant la procédure Fast
Connect de la version 2 du
protocole H.323.

A la réception du message,
le GW émet un message
ARQ au GK pour lui
demander l’autorisation de
répondre à l’appel.

Le GK lui retourne une
réponse ACF.

Le GW traduit alors le
message SETUP en une
requête INVITE en recopiant
les caractéristiques média du
message Setup dans le
message INVITE.

Ce dernier est relayé par le
Proxy server au terminal
SIP destinataire.

Une réponse d’information
180 Ringing est retournée
par le terminal SIP au GW
qui la traduit en un
message Q.931 Alerting
renvoyé au terminal H.323.

Le terminal SIP acceptant
l’appel émet une réponse
finale 200 OK contenant le
média utilisé permettant
au GW de produire un
message Connect délivré
au terminal H.323.

Le GW retourne une
requête SIP ACK au
terminal SIP pour acquitter
la réception de la réponse
finale 200 OK.

Ces échanges de
signalisation ont permis
l’établissement de canaux
RTP directement entre les
terminaux H.323 et SIP.

SIP signaling protocol explained by professor

Contenu connexe

Similaire à SIP signaling protocol explained by professor

SIP signaling protocol explained by professor

Notes de l'éditeur