Dossier délivré pour

DOCUMENTATION
22/10/2008

Protocole SIP

par François TOUTAIN

Docteur ès sciences
Ingénieur de recherche
École Nationale Supérieure des Télécommunications de Bretagne

1. Principe....................................................................................................... TE 7 530 - 2
1.1 Composants SIP........................................................................................... — 2
1.2 Adressage et nommage .............................................................................. — 2
1.3 Localisation .................................................................................................. — 2
2. Messages SIP ............................................................................................ — 2
2.1 Requêtes....................................................................................................... — 2
2.2 Réponses ...................................................................................................... — 3
2.3 Champs d'en-têtes....................................................................................... — 3
2.4 Exemples ...................................................................................................... — 4
2.4.1 Requête INVITE ................................................................................... — 4
2.4.2 Réponse 200 OK ................................................................................. — 4
3. Fonctionnement d'un système SIP ..................................................... — 4
3.1 Appel simple ................................................................................................ — 4
3.2 Appel avec redirection ................................................................................ — 5
3.3 Robustesse aux erreurs............................................................................... — 5
4. Services avancés offerts par SIP......................................................... — 6
5. Sécurité dans le cadre SIP .................................................................... — 6
Pour en savoir plus ........................................................................................... Doc. TE 7 530

'émergence des services de téléphonie, et plus largement de communica-

L tion multimédia interpersonnelle sur les réseaux IP, a suscité le besoin de
définir un protocole dédié à la signalisation d'appels. Ce protocole, nommé SIP
(Session Initiation Protocol), est normalisé par l'Internet Engineering Task Force
(IETF) au travers de la Request for Comments RFC 2543.
S'intégrant au schéma général de communication multimédia proposé par
l'IETF, le protocole SIP se pose en concurrent des mécanismes de signalisation
mis en œuvre dans les systèmes H.323 (cf. article « Téléphonie Internet » de ce
traité).

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Réseaux et télécommunications TE 7 530 − 1

Dossier délivré pour

DOCUMENTATION
22/10/2008
 Dossier délivré pour
DOCUMENTATION
22/10/2008
PROTOCOLE SIP _______________________________________________________________________________________________________________________

1. Principe informatique, actuellement connecté sur ce système. Cela constitue

une réponse au problème de mobilité personnelle, où un usager dis-
pose de plusieurs sites (bureaux, domicile...) et de plusieurs machi-
nes dans chaque site.
Le protocole SIP [2] découle d’une approche dédiée à la signalisa-
tion téléphonique sur Internet au sein du groupe MMUSIC (Multime-
dia Multiparty Session Control) [1].
Il intègre les fonctionnalités de transformation d’adresse, de loca- 1.3 Localisation
lisation d’usager, d’établissement et de gestion des appels, incluant
la négociation de capacités (formats de flux supportés avec leur
paramétrage). Lorsqu’un usager souhaite établir un appel, la requête est soit
émise vers un serveur proxy local, qui se charge de la faire suivre,
soit directement envoyée à un serveur SIP disponible à la destina-
tion. Le nommage d’un tel serveur peut suivre un principe similaire
1.1 Composants SIP à celui actuellement utilisé pour les serveurs web ([Link]-
[Link]), en substituant www par sip. La découverte de ce serveur
peut être accomplie par le biais du DNS (Domain Name Service :
SIP définit deux composants, qui tous deux peuvent mettre en service de nommage de l’internet). À la réception de la requête
œuvre soit un service d’élaboration de requête, soit un service de d’établissement, ce serveur doit localiser l’utilisateur, qui peut être
traitement de requête : le protocole est donc de type client-serveur. connecté sur une ou plusieurs machines du domaine, ou éventuelle-
Le premier composant est nommé agent d'usager (User Agent, ment être indisponible. Pour ce faire, le serveur fait appel au serveur
UA). L’UA constitue un système terminal, à disposition d’un utilisa- de localisation, qui a connaissance (par des moyens non précisés)
teur et lui apportant deux fonctionnalités : des usagers du domaine et de leur localisation précise. En retour, le
serveur SIP reçoit une liste, éventuellement vide, de machines où
— une fonctionnalité « client » (User Agent Client, UAC), exploi- l’utilisateur est susceptible d’être présent. Il peut alors faire suivre la
tée pour initier un appel, donc une requête SIP ; requête à des machines, par exemple en séquence jusqu’à ce que
— une fonctionnalité « serveur » (User Agent Server, UAS), char- l’utilisateur soit effectivement joint, ou en parallèle, en réémettant la
gée de traiter les requêtes parvenant jusqu’à l’UA (appel de l’utilisa- requête vers toutes les machines où l’usager est susceptible d’être
teur) et de fournir des réponses adaptées. joint (les cas d’erreur sont pris en compte).
Le second composant est nommé serveur réseau (Network Ser-
ver). Il peut être déployé dans diverses portions du réseau et, typi-
quement, il est mis en œuvre au niveau d’une organisation
(entreprise, domicile, etc.) et procure :
— soit un service de routage des requêtes SIP (on parle alors d’un
2. Messages SIP
proxy server), où une requête entrante est réexpédiée à un autre
serveur (réseau ou UAS), choisi selon des critères précis ; De par l’orientation client-serveur de SIP, les messages échangés
— soit un service de redirection de requête SIP (il s’agit alors d’un sont soit des requêtes, soit des réponses. Dans les deux cas, les
Redirect Server), où un autre serveur, plus adapté, est choisi, et une messages sont de nature textuelle (à l’instar des messages HTTP du
réponse de redirection est renvoyée à l’émetteur de la requête, men- World Wide Web), ce qui permet essentiellement une mise en œuvre
tionnant ce serveur plus adapté. facilitée et une bonne extensibilité du protocole.
Une troisième entité entre un jeu dans un système SIP, mais reste
extérieure à la norme. Il s’agit d’un serveur de localisation, dont
l’usage est décrit § 1.3.
2.1 Requêtes

1.2 Adressage et nommage La version actuelle de SIP (version 2.0, [2]) prévoit six requêtes
distinctes, permettant l’établissement d’un appel, la négociation des
capacités (types de média qui serviront aux échanges audiovisuels)
Les « objets » gérés par SIP sont des utilisateurs, humains princi- ou la fermeture d’une session :
palement, et accessibles par le biais de leur ordinateur, assistant
— INVITE : requête d’établissement, invitant un usager (humain
personnel..., ou utilisateur-machine particulière telle que des ser-
ou non) à participer à une session de communication. L’émetteur de
veurs de contenus. Tous ces objets sont identifiés au moyen d’une
cette requête y indique les types de média qu’il souhaite et peut
SIP-URL (Universal Resource Locator), chaîne de caractères analo-
recevoir, en général au travers d’une description de session SDP
gue à celles utilisées dans le World Wide Web. Une SIP-URL prend la
(Session Description Protocol cf. [IP 2 960]) ;
forme sip:utilisateur@domaine, où utilisateur est le nom de l’usa-
ger (tel qu’utilisé pour s’identifier dans le système informatique) ou — ACK : requête d’acquittement, émise pour confirmer que le
un numéro de téléphone. La portion domaine est dans l’idéal le nom client émetteur d’un INVITE précédent a reçu une réponse finale et
du domaine de rattachement de l’utilisateur (par exemple entre- valable ; cette requête peut véhiculer une description de session qui
[Link]). Il est prévu qu’une SIP-URL soit aisément obtenue, soit clôt la négociation ;
auprès de services d’annuaires, soit du fait d’un échange antérieur — BYE : requête de clôture d’un appel ;
(e-mail, Web, etc.), soit encore par dérivation de l’adresse e-mail de — CANCEL : requête d’annulation, signifiant au serveur de
la personne. Par ailleurs, il est tout-à-fait possible de définir des SIP- détruire le contexte d’un appel en cours d’établissement (cette
URL qui englobent plusieurs usagers, un appel ayant alors pour but requête n’a pas d’effet sur un appel en cours) ;
de joindre une des personnes considérées. — OPTIONS : cette requête permet à un client d’obtenir de l’infor-
Exemple : sip:ventes@[Link]. mation sur les capacités d’un usager, sans pour autant provoquer
l’établissement d’une session ;
L’idée de base derrière ce principe de nommage est pour un utili- — REGISTER : requête à destination d’un serveur SIP et permet-
sateur de publier une adresse générale, qui sera ensuite traduite au tant de lui faire parvenir de l’information de localisation (machine
cas par cas pour aboutir à l’identifier en tant qu’usager d’un système sur laquelle se trouve l’utilisateur).

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
TE 7 530 − 2 © Techniques de l’Ingénieur, traité Réseaux et télécommunications

Dossier délivré pour

DOCUMENTATION
22/10/2008
Dossier délivré pour
DOCUMENTATION
22/10/2008
_______________________________________________________________________________________________________________________ PROTOCOLE SIP

Un client doit pouvoir au minimum générer des requêtes INVITE

et ACK, et inclure une mise en œuvre de SDP [3]. Tableau 1 – Champs d’en-têtes obligatoires
Un serveur doit au minimum être capable de traiter les messages En-tête Description
INVITE, ACK, OPTIONS et BYE. Un serveur proxy doit en plus com-
prendre les requêtes CANCEL. Accept: précise les types de media qui sont accepta-
bles dans la réponse
Accept-Encoding: similaire à Accept:, avec des restrictions
supplémentaires sur l’encodage des
2.2 Réponses medias
Accept-Language: précise la langue à utiliser dans les messa-
ges de statut, de réponses, ou de descrip-
Après réception et traitement d’une requête, les divers serveurs tions de sessions
SIP génèrent un message de réponse qui indique principalement
Allow: informe le destinataire des méthodes qui
l’état du serveur vis-à-vis de la requête considérée (succès ou échec peuvent être invoquées sur la ressource
du traitement). Ces réponses sont codées par une séquence de trois
chiffres, où le premier est un code de classe (analogue aux codes Authorization: information d’authentification pour l’usage
HTTP, Hyper Text Transfer Protocol) : d’une ressource par un UA
— code 1xx : réponse intermédiaire d’information (traitement en Call-ID: identifiant unique pour un échange d’éta-
cours...) blissement particulier
• 100 Trying, Contact: généralement, URL de l’usager
• 180 Ringing, Content-Encoding: renforce le champ Content-Type: par la des-
• 181 Call is being forwarded ; cription de l’encodage appliqué sur la res-
source
— code 2xx : succès ;
— code 3xx : redirection Content-Length: longueur du message en octets
• 301 Moved permanently, Content-Type: indique le type du corps du message
(par exemple une description SDP)
• 302 Moved temporarily,
• 305 Use Proxy ; CSeq: (Command Sequence) identifie une requête
à l’intérieur d’un Call-ID:
• ...
— code 4xx : erreur client Encryption: précise que le contenu est chiffré
• 400 Bad Request, Expires: date et heure d’expiration du message
• 401 Unauthorized, From: identifie l’initiateur de la requête
• 404 Not Found, Hide: permet de masquer le chemin décrit par les
• ... champs Via:
— code 5xx : erreur serveur Max-Forwards: limite au nombre de serveurs et de proxies
• 500 Server Internal Error, qui peuvent router le message
• 501 Not Implemented, Proxy-Authenticate: information pour l’authentification d’un
• 503 Service Unavailable, usager auprès d’un proxy
• ... Proxy-Authorization: information pour l’authentification d’un
— code 6xx : échec global du traitement usager auprès d’un proxy
• 600 Busy Everywhere, Proxy-Require: précise un mécanisme qui doit être fourni
par le proxy
• 603 Decline,
• 606 Not Acceptable, Require: précise un mécanisme qui doit être fourni
par un UAS
• ...
Response-Key: clé de chiffrement pour le message
Route: route que le message doit emprunter
2.3 Champs d'en-têtes Timestamp: estampille indiquant la date d’émission du
message
To: précise le destinataire de la requête
Les requêtes et les réponses SIP incluent des champs d'en-têtes, Unsupported: liste les mécanismes non supportés par le
qui sont au nombre de 37, regroupés dans quatre catégories serveur
distinctes :
User-Agent: information sur l’UA qui a généré le mes-
— champs d’en-têtes généraux, applicables aux requêtes comme sage
aux réponses ;
Via: dénote le chemin emprunté par la requête
— champs d’en-têtes d’entité, définissant le contenu des messa- jusqu’à l’instant présent
ges ou la nature des ressources mises en jeu par le message ;
WWW-Authenticate: inclus dans les réponses 401, dans le but
— champs d’en-têtes de requêtes, qui accroissent l’information d’authentifier l’émetteur de la requête
d’une requête en la caractérisant finement, et permettent au client
d’inclure des informations additionnelles à son sujet ;
— champs d’en-têtes de réponses, qui affinent le contenu du
message de réponse. Les champs d’en-têtes SIP sont extensibles, au sens où une implé-
Le tableau 1 décrit les champs d’en-têtes définis par la norme SIP mentation peut choisir de définir de nouveaux en-têtes pour un
qui doivent être obligatoirement reconnus par toute mise en œuvre usage particulier. De ce fait, il est requis qu’un serveur ignore pure-
de SIP. ment et simplement les champs d’en-têtes non reconnus.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Réseaux et télécommunications TE 7 530 − 3

Dossier délivré pour

DOCUMENTATION
22/10/2008
 Dossier délivré pour
DOCUMENTATION
22/10/2008
PROTOCOLE SIP _______________________________________________________________________________________________________________________

INVITE sip:martin@[Link] SIP/2.0

Via: SIP/2.0/UDP [Link] SIP/2.0 200 OK
From: Dupont <sip:dupont@[Link]> Via: SIP/2.0/UDP [Link]
To: Martin <sip:martin@[Link]> Via: SIP/2.0/UDP [Link]
Call-ID: 1234567890@[Link] From: Martin <sip:martin@[Link]>
CSeq: 1 INVITE To: Dupont <sip:dupont@[Link]>
Subject: Prise de rendez-vous Call-ID: 1234567890@[Link]
Content-Type: application/sdp CSeq: 1 INVITE
Content-Length: 142 Content-Type: application/sdp
Content-Length: 153
<description de session SDP >
<description de session SDP >
Figure 1 – Requête INVITE

Figure 2 – Spécification SDP en retour

2.4 Exemples

2.4.1 Requête INVITE

Domaine [Link]

Examinons une requête de type INVITE dans laquelle un usager

Dupont, connecté sur sa machine citrouille dans le domaine
[Link] (dupont@[Link]) souhaite établir un appel dupont@[Link]
vers un usager Martin qui travaille dans le domaine [Link].
La requête est donnée sous forme textuelle dans la figure 1. Les dif-
férentes champs d’en-têtes représentés ont la signification
suivante : 6
1 7
— Via: route empruntée par la requête ; celle-ci vient de quitter le 200 OK
INVITE ACK
serveur proxy du domaine [Link] au moment de sa saisie, par
conséquent seul celui-ci est mentionné. Au fur et à mesure de la pro-
gression de la requête, dans le réseau, des en-têtes Via: seront
ajoutées ; 4
— From: information sur l’appelant (ici une SIP-URL) ; INVITE
Serveur 200
— To: SIP-URL de l’appelé ; proxy 5
OK
— Call-ID: identifiant unique, établi par l’UAS de l’appelant ;
— CSeq: identifiant de la requête, ici INVITE ; 8
— Subject: (en-tête optionnel) champ de texte fourni par l’usager 3 ACK
appelant, afin de renseigner l’appelé sur la nature de l’appel ; martin@glouton
— Content-Type: type des données présentes dans la requête, ici 2 martin@glouton
une description de session (SDP) ; martin ?
— Content-Length: longueur de la requête.
Le corps de la requête est fourni, après un saut de ligne, sous la
forme d’une description de session SDP. Serveur
de localisation
Domaine [Link]
2.4.2 Réponse 200 OK

La figure 2 donne la réponse fournie par l’usager Martin, de type Figure 3 – Appel simple SIP
200 OK.
Les champs d’en-têtes sont analogues, sauf en ce qui concerne les
en-têtes Via: ceux-ci reprennent le chemin suivi par la requête et ser- Martin sur sa machine glouton. La figure 3 présente l’échange de
vent à router la réponse, en sens inverse. La réponse est donc desti- messages SIP entre les divers composants qui entrent en jeu.
née en premier lieu au serveur proxy du domaine [Link],
qui va supprimer la ligne correspondante et retransmettre le mes- Le premier message est une requête INVITE (comportant vraisem-
sage vers le serveur identifié par le champ Via: suivant, en l’occur- blablement l’en-tête To : martin@[Link]). Le serveur proxy
rence le serveur proxy du domaine [Link]. de ce domaine traite la requête en interrogeant le serveur de locali-
sation (message 2), qui lui communique que l’usager est actuelle-
ment sur la machine glouton (message 3). Le serveur proxy fait
suivre la requête (message 4). En supposant que l’utilisateur est pré-
3. Fonctionnement sent et qu’il « décroche le combiné », le message 5 est alors une
d'un système SIP réponse de classe 2xx, dans l’exemple 200 OK. Cette réponse est
acheminée en sens inverse jusqu’à Dupont (message 6), puis une
requête finale ACK est véhiculée depuis celui-ci jusqu’à Martin
(messages 7 et 8). Dans le cas d’un serveur type Redirect, celui-ci,
3.1 Appel simple après interrogation du service de localisation, enverrait une réponse
de classe 3xx (ex : 302, Moved temporarily) comportant l’en-tête
Contact: suivi de la SIP-URL sip:martin@[Link],
Considérons en premier lieu le cas simple où l’usager Dupont, permettant à Dupont d’émettre une requête INVITE directement
connecté sur sa machine citrouille, souhaite appeler l’utilisateur vers cette machine.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
TE 7 530 − 4 © Techniques de l’Ingénieur, traité Réseaux et télécommunications

Dossier délivré pour

DOCUMENTATION
22/10/2008
Dossier délivré pour
DOCUMENTATION
22/10/2008
_______________________________________________________________________________________________________________________ PROTOCOLE SIP

Domaine [Link]

Domaine [Link] Domaine [Link]

citrouille proxy glouton localisation dupont@[Link]

1
INVITE
2
martin ?

3 1 4 5
martin@citrouille 10 7 INVITE
4
INVITE

6
200 OK 5 Serveur Serveur
200 OK
7 proxy proxy
ACK
8
ACK
11 2 3 6
ACK 9 8

Figure 4 – Chronogramme : appel simple

martin@gargantua
martin@glouton
La figure 4 présente tous ces échanges sous forme de chrono-
gramme.
Domaine [Link] Domaine [Link]

Figure 5 – Appel SIP avec redirection

3.2 Appel avec redirection

Illustrons maintenant les capacités de redirection offertes par un Domaine [Link] Domaine [Link] Domaine [Link]
système SIP, en considérant que l’usager Martin dispose, dans un
domaine [Link], d’une machine nommée gargantua. citrouille proxy glouton proxy gargantua
1
Son contact public est martin@[Link], par conséquent il INVITE
souhaite que les appels arrivant dans la filiale soient redirigés vers 2
le domaine [Link], où il est localisé le plus souvent. Cela INVITE
4
est mis en œuvre par exemple par la configuration locale de la 302 Moved
temporarily 3
machine gargantua (figure 5). 302 Moved
Supposons maintenant que l’usager Dupont ait trouvé dans un 5 temporarily
ACK
annuaire quelconque le contact martin@[Link], et qu’il initie un 7 6
appel vers ce contact (message 1). Le serveur proxy de la filiale INVITE ACK
8
détermine que la machine gargantua est une bonne candidate pour INVITE
trouver l’usager Martin et lui faire suivre la requête (message 2),
mais celle-ci répond par un message de type 302 Moved temporarily, 10
200 OK 9
qui est répercuté vers l’initiateur de l’appel (messages 3 et 4, qui
200 OK
sont acquittés par les messages 5 et 6). L’UA de Dupont reprend
alors à zéro, en soumettant une requête vers le proxy du domaine
[Link] (message 7). Celui-ci fait suivre la requête 11
ACK
(message 8), qui reçoit une réponse 200 OK retournée vers Dupont
(messages 9 et 10). Le message ACK peut enfin être émis directe-
ment vers la machine sur laquelle Martin a répondu à l’appel.
Figure 6 – Chronogramme : appel avec redirection
Le chronogramme de ce scénario est donné en figure 6.

ment établi une redirection vers [Link] sur la machine gar-

gantua.
3.3 Robustesse aux erreurs
Lorsque l’usager Dupont cherche à joindre Martin, c’est le serveur
SIP du domaine [Link] qui est contacté (message 2).
Examinons enfin un scénario plus complexe (chronogramme
donné figure 7), où l’utilisateur Martin dispose de deux machines, Celui-ci découvre la redirection établie, et fait suivre la requête
vorace et gargantua, dans le domaine [Link]. Son contact public (message 3) vers le serveur SIP de la filiale (dont l’adresse est obte-
est martin@[Link], mais, étant dans la filiale, il envoie une nue par DNS). Ce serveur, grâce au service de localisation, découvre
requête REGISTER vers le serveur SIP du domaine [Link], deux machines où Martin peut être joint, et envoie donc la requête
pour établir une redirection vers la filiale (message 1). Par ailleurs, il simultanément aux deux (message 4). La machine gargantua, du
enregistre ses deux machines auprès du serveur du domaine fait de l’ancienne redirection, fournit une réponse 302 (Moved tem-
[Link] (serveur de localisation), mais oublie qu’il a précédem- porarily) au serveur proxy (message 5). Celui-ci réexpédie la requête

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Réseaux et télécommunications TE 7 530 − 5

Dossier délivré pour

DOCUMENTATION
22/10/2008
 Dossier délivré pour
DOCUMENTATION
22/10/2008
PROTOCOLE SIP _______________________________________________________________________________________________________________________

moyen d’une page Web, que l’appelant peut parcourir de façon tra-
ditionnelle. L’on peut aussi imaginer un répondeur personnel basé
Domaine [Link] Domaine [Link] Domaine [Link]
sur le Web, et présentant en cas de non réponse de l’appelé une
page sur laquelle seront proposés l’enregistrement d’un message
citrouille proxy proxy vorace gargantua (e-mail, message audio et/ou vidéo), un contact prioritaire en cas
1 d’urgence, ou une redirection vers d’autres interlocuteurs à même
2 Register
INVITE de renseigner l’appelant, en fonction du sujet qu’il souhaite aborder.
3
INVITE Deux possibilités de mise en œuvre sont à l’étude dans le groupe
4
INVITE MMUSIC de l’IETF. La première préconise l’usage de scripts CGI
(Common Gateway Interface, technologie du Web) exécutés en
6 réponses à des requêtes SIP, la seconde propose un langage de
INVITE 5 script, nommé CPL (Call Processing Language), de syntaxe analo-
302 Moved
gue au HTML (technologie du Web là encore), et qui permet à l’utili-
7 temporarily
Loop
sateur de décrire simplement ce type d’application.
8
detected 200 OK
9
10 200 OK
200 OK
11
5. Sécurité dans le cadre SIP
ACK

La situation en terme de sécurité dans un système SIP est analo-

gue à celle rencontrée dans les architectures H.323. Les besoins sont
les mêmes, ils recouvrent les aspects d’authentification des usagers
Figure 7 – Chronogramme : robustesse aux erreurs
et des systèmes, de confidentialité des messages échangés, à la fois
pour la signalisation et pour les flux multimedia, ainsi que de leur
intégrité.
au serveur SIP de [Link] (message 6), lequel détecte la
boucle et répond par un message d’erreur (message 7). La machine Les différents messages SIP peuvent être chiffrés afin d’empêcher
vorace par contre signale l’appel (sonnerie), auquel répond Martin, tant leur lecture par un utilisateur malveillant, que la perception par
ce qui provoque une réponse en direction du serveur SIP de la filiale celui-ci du « schéma » de communication (qui appelle qui et selon
(message 8). Celui-ci, ayant reçu des réponses à toutes ses requê- quelles modalités). De ce fait, trois types de chiffrement sont
tes, fournit une réponse au serveur SIP du domaine [Link] prévus :
(message 9), réponse réexpédiée à Dupont (message 10). À ce — chiffrement de bout en bout du corps de message et de cer-
stade, la communication peut s’établir directement entre les machi- tains en-têtes (seuls l’émetteur et le destinataire ont connaissance
nes citrouille et vorace (message 11), ce qui permet aux serveurs du contenu) ;
de détruire les contextes associés à ces messages. — chiffrement de proche en proche (de serveur en serveur), de
Ce troisième exemple illustre la capacité de l’architecture SIP à niveau réseau ou transport, utilisant indifféremment IPSEC (IP Secu-
« rechercher » un utilisateur, par le biais d’une requête qui parcourt rity) ou TLS (Transport Layer Security), à l’instar de H.235 pour
différents serveurs au hasard des redirections, ainsi que sa résis- empêcher une écoute qui permettrait de déterminer les identités
tance à des défauts de configuration (ici l’ancienne redirection sur la des personnes impliquées dans la communication ;
machine gargantua), qui passe essentiellement par la détection de — chiffrement du champ Via:, par coopération entre les serveurs,
boucles. Cette mesure est mise en œuvre au moyen de l’en-tête Via: visant à masquer la route prise par la requête.
qui dénote, au fur et à mesure de la progression d’une requête, les Certains champs d’en-têtes (To:, Via:) doivent être lisibles par les
divers serveurs empruntés. serveurs proxy intermédiaires. Cela implique un chiffrement de ser-
veur en serveur qui évite une écoute de la ligne. Cependant, chacun
de ces serveurs devrait être protégé si l’on veut fournir un degré de
sécurité adéquat. Le chiffrement de bout en bout est réalisé par les
4. Services avancés offerts User Agents en PGP (Pretty Good Privacy), en scindant le message
en un en-tête non chiffré, contenant les champs qui doivent impéra-
par SIP tivement être lisibles par les équipements intermédiaires, et une
partie chiffrée. Un champ supplémentaire détaillant le mécanisme
de chiffrement exploité est inséré. Si la réponse à une requête chif-
Les services avancés vus dans le contexte H.323 sont également frée doit elle aussi être chiffrée, alors l’UA émetteur de la requête
fournis par l’architecture SIP. Les fonctionnalités de transfert fournit au destinataire une clé de chiffrement pour la réponse.
d’appel, renvoi, mise en attente, signal d’appel, sont mises en En matière d’authentification, SIP reprend les mécanismes mis en
œuvre de façon différente, mais avec des résultats analogues. œuvre pour HTTP et les étend par l’usage de PGP, permettant ainsi
Par ailleurs, la similitude existant entre la syntaxe SIP et celle de de signer numériquement les messages.
HTTP, en particulier l’usage d’URL, autorise une intégration aisée du
Web et de la téléphonie. Il est par exemple possible de construire un
« serveur répondeur interactif » qui n’est pas seulement vocal et L’information relative aux développements de l’IETF est
piloté par les touches du téléphone, mais qui répond aux appels au essentiellement disponible sur Internet [4].

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
TE 7 530 − 6 © Techniques de l’Ingénieur, traité Réseaux et télécommunications

Dossier délivré pour

DOCUMENTATION
22/10/2008