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....................................................................................................... IP 2 925 - 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. IP 2 925

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

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 IP 2 925 − 1
PROTOCOLE SIP _______________________________________________________________________________________________________________________
1. Principe
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-
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).
1.1 Composants SIP
SIP définit deux composants, qui tous deux peuvent mettre en
œuvre soit un service d’élaboration de requête, soit un service de
traitement de requête : le protocole est donc de type client-serveur.
Le premier composant est nommé agent d'usager (User Agent,
UA). L’UA constitue un système terminal, à disposition d’un utilisa-
teur et lui apportant deux fonctionnalités :
— une fonctionnalité « client » (User Agent Client, UAC), exploi-
tée pour initier un appel, donc une requête SIP ;
— une fonctionnalité « serveur » (User Agent Server, UAS), char-
gée de traiter les requêtes parvenant jusqu’à l’UA (appel de l’utilisa-
teur) et de fournir des réponses adaptées.
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
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 ;
— soit un service de redirection de requête SIP (il s’agit alors d’un
Redirect Server), où un autre serveur, plus adapté, est choisi, et une
réponse de redirection est renvoyée à l’émetteur de la requête, men-
tionnant ce serveur plus adapté.
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.
1.2 Adressage et nommage
Les « objets » gérés par SIP sont des utilisateurs, humains princi-
palement, et accessibles par le biais de leur ordinateur, assistant
personnel..., ou utilisateur-machine particulière telle que des ser-
veurs de contenus. Tous ces objets sont identifiés au moyen d’une
SIP-URL (Universal Resource Locator), chaîne de caractères analo-
gue à celles utilisées dans le World Wide Web. Une SIP-URL prend la
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
un numéro de téléphone. La portion domaine est dans l’idéal le nom
du domaine de rattachement de l’utilisateur (par exemple entre-
prise.com). Il est prévu qu’une SIP-URL soit aisément obtenue, soit
auprès de services d’annuaires, soit du fait d’un échange antérieur
(e-mail, Web, etc.), soit encore par dérivation de l’adresse e-mail de
la personne. Par ailleurs, il est tout-à-fait possible de définir des SIP-
URL qui englobent plusieurs usagers, un appel ayant alors pour but
de joindre une des personnes considérées.
Exemple : sip:ventes@entreprise.com.
L’idée de base derrière ce principe de nommage est pour un utili-
sateur de publier une adresse générale, qui sera ensuite traduite au
cas par cas pour aboutir à l’identifier en tant qu’usager d’un système
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
IP 2 925 − 2 © Techniques de l’Ingénieur, traité Réseaux
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.
1.3 Localisation
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
à celui actuellement utilisé pour les serveurs web (www.entre-
prise.com), en substituant www par sip. La découverte de ce serveur
peut être accomplie par le biais du DNS (Domain Name Service :
service de nommage de l’internet). À la réception de la requête
d’établissement, ce serveur doit localiser l’utilisateur, qui peut être
connecté sur une ou plusieurs machines du domaine, ou éventuelle-
ment être indisponible. Pour ce faire, le serveur fait appel au serveur
de localisation, qui a connaissance (par des moyens non précisé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ù
l’utilisateur est susceptible d’être présent. Il peut alors faire suivre la
requête à des machines, par exemple en séquence jusqu’à ce que
l’utilisateur soit effectivement joint, ou en parallèle, en réémettant la
requête vers toutes les machines où l’usager est susceptible d’être
joint (les cas d’erreur sont pris en compte).
2. Messages SIP
De par l’orientation client-serveur de SIP, les messages échangés
sont soit des requêtes, soit des réponses. Dans les deux cas, les
messages sont de nature textuelle (à l’instar des messages HTTP du
World Wide Web), ce qui permet essentiellement une mise en œuvre
facilitée et une bonne extensibilité du protocole.
2.1 Requêtes
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)
ou la fermeture d’une session :
— INVITE : requête d’établissement, invitant un usager (humain
ou non) à participer à une session de communication. L’émetteur de
cette requête y indique les types de média qu’il souhaite et peut
recevoir, en général au travers d’une description de session SDP
(Session Description Protocol cf. [IP 2 960]) ;
— ACK : requête d’acquittement, émise pour confirmer que le
client émetteur d’un INVITE précédent a reçu une réponse finale et
valable ; cette requête peut véhiculer une description de session qui
clôt la négociation ;
— BYE : requête de clôture d’un appel ;
— CANCEL : requête d’annulation, signifiant au serveur de
détruire le contexte d’un appel en cours d’établissement (cette
requête n’a pas d’effet sur un appel en cours) ;
— OPTIONS : cette requête permet à un client d’obtenir de l’infor-
mation sur les capacités d’un usager, sans pour autant provoquer
l’établissement d’une session ;
— REGISTER : requête à destination d’un serveur SIP et permet-
tant de lui faire parvenir de l’information de localisation (machine
sur laquelle se trouve l’utilisateur).
_______________________________________________________________________________________________________________________ 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 IP 2 925 − 3
PROTOCOLE SIP _______________________________________________________________________________________________________________________

INVITE sip:martin@entreprise.com SIP/2.0

Via: SIP/2.0/UDP proxy.client.net SIP/2.0 200 OK
From: Dupont <sip:dupont@client.net> Via: SIP/2.0/UDP proxy.entreprise.com
To: Martin <sip:martin@entreprise.com> Via: SIP/2.0/UDP proxy.client.net
Call-ID: 1234567890@citrouille.client.net From: Martin <sip:martin@entreprise.com>
CSeq: 1 INVITE To: Dupont <sip:dupont@client.net>
Subject: Prise de rendez-vous Call-ID: 1234567890@citrouille.client.net
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 client.net

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

Dupont, connecté sur sa machine citrouille dans le domaine
client.net (dupont@citrouille.client.net) souhaite établir un appel dupont@citrouille.client.net
vers un usager Martin qui travaille dans le domaine entreprise.com.
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 client.net 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 entreprise.com
2.4.2 Réponse 200 OK

La figure 2 donne la réponse fournie par l’usager Martin, de type
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-
vent à router la réponse, en sens inverse. La réponse est donc desti-
née en premier lieu au serveur proxy du domaine entreprise.com,
qui va supprimer la ligne correspondante et retransmettre le mes-
sage vers le serveur identifié par le champ Via: suivant, en l’occur-
rence le serveur proxy du domaine client.net.
3. Fonctionnement
d'un système SIP
3.1 Appel simple
Considérons en premier lieu le cas simple où l’usager Dupont,
connecté sur sa machine citrouille, souhaite appeler l’utilisateur
Figure 3 – Appel simple SIP
Martin sur sa machine glouton. La figure 3 présente l’échange de
messages SIP entre les divers composants qui entrent en jeu.
Le premier message est une requête INVITE (comportant vraisem-
blablement l’en-tête To : martin@entreprise.com). Le serveur proxy
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é-
sent et qu’il « décroche le combiné », le message 5 est alors une
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,
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@glouton.entreprise.com,
permettant à Dupont d’émettre une requête INVITE directement
vers cette machine.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
IP 2 925 − 4 © Techniques de l’Ingénieur, traité Réseaux
_______________________________________________________________________________________________________________________ PROTOCOLE SIP

Domaine client.net

Domaine client.net Domaine entreprise.com dupont@citrouille.client.net

citrouille proxy glouton localisation
1
INVITE
2
martin ? 1 4 5
10 7 INVITE
3
martin@citrouille
4
INVITE
Serveur Serveur
6 proxy proxy
200 OK 5
200 OK
7
ACK
8 11 2 3 6
ACK 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 entreprise.com Domaine filiale.com

Figure 5 – Appel SIP avec redirection

3.2 Appel avec redirection

Illustrons maintenant les capacités de redirection offertes par un

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

3.3 Robustesse aux erreurs
Examinons enfin un scénario plus complexe (chronogramme
donné figure 7), où l’utilisateur Martin dispose de deux machines,
vorace et gargantua, dans le domaine filiale.com. Son contact public
est martin@entreprise.com, mais, étant dans la filiale, il envoie une
requête REGISTER vers le serveur SIP du domaine entreprise.com,
pour établir une redirection vers la filiale (message 1). Par ailleurs, il
enregistre ses deux machines auprès du serveur du domaine
filiale.com (serveur de localisation), mais oublie qu’il a précédem-
gantua.
Lorsque l’usager Dupont cherche à joindre Martin, c’est le serveur
SIP du domaine entreprise.com qui est contacté (message 2).
Celui-ci découvre la redirection établie, et fait suivre la requête
(message 3) vers le serveur SIP de la filiale (dont l’adresse est obte-
nue par DNS). Ce serveur, grâce au service de localisation, découvre
deux machines où Martin peut être joint, et envoie donc la requête
simultanément aux deux (message 4). La machine gargantua, du
fait de l’ancienne redirection, fournit une réponse 302 (Moved tem-
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 IP 2 925 − 5
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é
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
Domaine client.net Domaine entreprise.com Domaine filiale.com (e-mail, message audio et/ou vidéo), un contact prioritaire en cas
citrouille proxy proxy vorace gargantua d’urgence, ou une redirection vers d’autres interlocuteurs à même
1
de renseigner l’appelant, en fonction du sujet qu’il souhaite aborder.
2 Register
INVITE Deux possibilités de mise en œuvre sont à l’étude dans le groupe
3
INVITE MMUSIC de l’IETF. La première préconise l’usage de scripts CGI
4
INVITE (Common Gateway Interface, technologie du Web) exécutés en
réponses à des requêtes SIP, la seconde propose un langage de
script, nommé CPL (Call Processing Language), de syntaxe analo-
6 gue au HTML (technologie du Web là encore), et qui permet à l’utili-
INVITE 5
302 Moved sateur de décrire simplement ce type d’application.
7 temporarily
Loop 8
detected 200 OK

10
9
200 OK
200 OK
11
ACK
Figure 7 – Chronogramme : robustesse aux erreurs
au serveur SIP de entreprise.com (message 6), lequel détecte la
boucle et répond par un message d’erreur (message 7). La machine
vorace par contre signale l’appel (sonnerie), auquel répond Martin,
ce qui provoque une réponse en direction du serveur SIP de la filiale
(message 8). Celui-ci, ayant reçu des réponses à toutes ses requê-
tes, fournit une réponse au serveur SIP du domaine entreprise.com
(message 9), réponse réexpédiée à Dupont (message 10). À ce
stade, la communication peut s’établir directement entre les machi-
nes citrouille et vorace (message 11), ce qui permet aux serveurs
de détruire les contextes associés à ces messages.
Ce troisième exemple illustre la capacité de l’architecture SIP à
« rechercher » un utilisateur, par le biais d’une requête qui parcourt
différents serveurs au hasard des redirections, ainsi que sa résis-
tance à des défauts de configuration (ici l’ancienne redirection sur la
machine gargantua), qui passe essentiellement par la détection de
boucles. Cette mesure est mise en œuvre au moyen de l’en-tête Via:
qui dénote, au fur et à mesure de la progression d’une requête, les
divers serveurs empruntés.
4. Services avancés offerts
par SIP
Les services avancés vus dans le contexte H.323 sont également
fournis par l’architecture SIP. Les fonctionnalités de transfert
d’appel, renvoi, mise en attente, signal d’appel, sont mises en
œuvre de façon différente, mais avec des résultats analogues.
Par ailleurs, la similitude existant entre la syntaxe SIP et celle de
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
piloté par les touches du téléphone, mais qui répond aux appels au
5. Sécurité dans le cadre SIP
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
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é.
Les différents messages SIP peuvent être chiffrés afin d’empêcher
tant leur lecture par un utilisateur malveillant, que la perception par
celui-ci du « schéma » de communication (qui appelle qui et selon
quelles modalités). De ce fait, trois types de chiffrement sont
prévus :
— chiffrement de bout en bout du corps de message et de cer-
tains en-têtes (seuls l’émetteur et le destinataire ont connaissance
du contenu) ;
— chiffrement de proche en proche (de serveur en serveur), de
niveau réseau ou transport, utilisant indifféremment IPSEC (IP Secu-
rity) ou TLS (Transport Layer Security), à l’instar de H.235 pour
empêcher une écoute qui permettrait de déterminer les identités
des personnes impliquées dans la communication ;
— chiffrement du champ Via:, par coopération entre les serveurs,
visant à masquer la route prise par la requête.
Certains champs d’en-têtes (To:, Via:) doivent être lisibles par les
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
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-
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-
frée doit elle aussi être chiffrée, alors l’UA émetteur de la requête
fournit au destinataire une clé de chiffrement pour la réponse.
En matière d’authentification, SIP reprend les mécanismes mis en
œuvre pour HTTP et les étend par l’usage de PGP, permettant ainsi
de signer numériquement les messages.
L’information relative aux développements de l’IETF est
essentiellement disponible sur Internet [4].

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
IP 2 925 − 6 © Techniques de l’Ingénieur, traité Réseaux