Le protocole SIP¶
Introduction¶
SIP en bref¶
Le protocole SIP (Session initiation protocol), défini par l'IETF, met en place des mécanismes pour la négociation de session multimedia (voix, visio, im, ...).
Parmi les fonctionnalités SIP:
- La localisation d'un UAC
- La demande d'établissement d'une session auprès un UAC
- La négociation des sessions média
- L'actualisation des sessions media existantes
- Achever une session media
Quelques réferences sur SIP¶
Point de départ pour la documentation RFC: RFC5411
SIP est défini par la RFC suivante: RFC3261
Plusieurs exemples de négociation sont disponibles: RFC3665, swizernet.com
La traversée du NAT par SIP en utilisant rport: rfc3581
Vocabulaire¶
dialogue:
Etude des transactions SIP actuelles¶
Le système de téléphonie SIP consiste en un proxy (Kamailio) et un serveur (Asterisk). Le proxy permet de scinder la gestion des transactions SIP en deux parties: le réseau d'une part, et les services d'autre part.
De cette façon, il permet une meilleure protection du serveur Asterisk qui ne communique qu'avec le proxy SIP. En effet, il est recommandé de ne pas laisser le serveur directement accessible par Internet afin de se prémunir d'attaques et de pouvoir fournir des services plus sereinement.
Les diagrammes et explications prennent donc en compte le proxy SIP.
L'enregistrement de l'UAC¶
L'enregistrement de l'UAC a plusieurs objectifs:
- Vérifier que l'URI signifiée dans la requête correspond à un utilisateur valide.
- Vérifier que l'utilisateur possède le mot de passe associé à l'URI renseignée.
- Lier l'URI de l'utilisateur à l'addresse permettant de joindre l'UAC (Address Of Record: AOR).
- Lister les actions SIP supportées par l'UAC et celles par l'UAS.
Voici le diagramme de séquence de l'enregistrement:
ENREGISTREMENT (simplifié)
A's . . . . . . . . . . . . SIP . . . . . . . . . . . . . . SIP
SIP phone proxy server
| | |
| REGISTER A@REALM IP_A F1 | |
|--------------------------------->| |
| 401 Auth F2 | |
|<---------------------------------| |
| REGISTER A@REALM IP_A F3 | |
|--------------------------------->| |
| | REGISTER A@REALM IP_proxy F4 |
| |--------------------------------->|
| | 200 OK for A@REALM IP_proxy F5 |
| |<---------------------------------|
| 200 OK for A@REALM IP_A F6 | |
|<---------------------------------| |
| | |
Details des paquets:¶
F1
REGISTER sip:REALM SIP/2.0
Via: SIP/2.0/UDP IP_A:5060;rport;branch=z9hG4bKPj3709e229-981d-411c-9865-489b06db5c51
Route: sip:IP_proxy;lr
Max-Forwards: 70
From: sip:202@REALM;tag=41bcaa31-a495-40e3-93cd-5c8a02e095a2
To: sip:202@REALM
Call-ID: 89ec7e03-7777-428b-9c99-71f32d6cdd45
CSeq: 21002 REGISTER
User-Agent: SFLphone
Contact: sip:202@IP_A:5060
Expires: 60
Allow: PRACK, SUBSCRIBE, NOTIFY, REFER, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, REGISTER, OPTIONS, MESSAGE
Content-Length: 0
Le premier paquet est une demande d'enregistrement par l'UAC. Celui-ci va être rejeté par le proxy car il ne contient pas la preuve que l'utilisateur connaît le mot de passe associé à l'URI 202@REALM (L'identifiant de l'utilisateur). Le rejet sera notifié par le paquet F2. La deuxième tentative d'enregistrement en F3 reprend tous les champs F1 plus le header WWW-Authenticate prouvant sa connaissance du mot de passe.
Voici la signification de ce paquet F1:
- REGISTER:
- L'UAC demande un enregistrement auprès du registrar du domaine REALM. - Via :
- Utilisation du protocole UDP.
- IP de l'UAC.
- rport : demande une réponse au port donné dans l' en-tête UDP et non pas le header Via (traversée du NAT).
- branch : UID de la requête parmi toutes les requêtes émises de l'UAC. - Route :
- L'UAC force le routage du paquet vers IP_proxy.
- lr : l'UAC supporte le loose rooting . - Max-Forward:
- Le paquet ne doit pas passer par plus de 70 relais SIP. - From :
- URI: L'URI de l'utilisateur.
- tag : La moitié de tag de dialogue choisie par l'UAC - To :
- URI: Idem que l'en-tete From pour une requête REGISTER.
(- Note: pas de "ToTag" car l'autre interlocuteur n'a pas encore transmis son tag) - Call-ID :
- Identifie un dialogue (note: insuffisant pour le hairpinning => tags) - CSeq :
- Numéro: identifie une transaction (requ?te-réponse) dans un dialogue, incrémenté pour chaque nouvelle transaction.
- Méthode: celle que l'on retrouve dans l'R-URI. - User-Agent:
- Nom: Le nom de l'UAC - Contact :
- URI: Celle que l'UAC propose pour être contacté lors de requêtes ultérieures. - Expires :
- La durée de validité souhaitée de l'enregistrement en secondes. - Allow :
- L'ensemble des méthodes supportées par l'UAC. - Content-Length :
- Taille du payload en octets
F2
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP IP_A:5060;rport=5060;branch=z9hG4bKPj3709e229-981d-411c-9865-489b06db5c51
From: sip:202@REALM;tag=41bcaa31-a495-40e3-93cd-5c8a02e095a2
To: sip:202@REALM;tag=ecc5e797927b99afb30713b7678fb8ee.e6c9
Call-ID: 89ec7e03-7777-428b-9c99-71f32d6cdd45
CSeq: 21002 REGISTER
WWW-Authenticate: Digest realm="REALM", nonce="U9PVz1PT1KMLCPDjscFFepG0TUAF67/E", qop="auth"
Server: kamailio (4.1.4 (x86_64/linux))
Content-Length: 0
Suite au premier essai d'enregistrement, le proxy demande une preuve d'authentification. Il s'agit d'une réponse à la requête F1.Pour cela, il fournit un nonce pour le domaine REALM dans le header WWW-Authenticate.
Voici la signification de ce paquet F2:
- 401
- Le proxy souhaite authentifier l'utilisateur. - Via :
- Le transport est UDP.
- La requête a été émise par IP_A.
- rport: Le requête a été émise du port 5060.
- branch: l'identifiant de requête pour l'UAC - From :
- URI: La requête est initiée par l'utilisateur avec l'URI en question
- tag: Le tag choisi par l'UAC lors de la requête comme ID de dialogue - "To" :
- URI: La même valeur que pour From. Cas particulier d'une requête REGISTER
- tag: Le tag choisi par le proxy comme ID de dialogue - Call-ID:
- L'identifiant de dialogue identique à celui de la requête - CSeq:
- Numéro: Le numéro de la requête (idem que dans F1)
- Méthode: La méthode de la requête: REGISTER ici - WWW-Authenticate :
- Méthode: méthode d'authentification par hachage
- realm: le domaine REALM
- nonce: l'aléa - Server:
- Le nom du proxy - Content-Length:
- Taille du payload
- F3
L'UAC génère une nouvelle requête similaire à F1, mais avec une en-tête Authorization comportant les champs donnés en F2 plus la réponse. Pas besoin de détailler plus de paquet. On note que cette nouvelle requête entame un nouveau dialogue (cf le tag et Call-ID), la précédente requête ayant échoué.
- F4
Lors de l'émission de ce paquet, le proxy doit être considéré comme un UAC. Le paquet REGISTER est tout à fait similaire à F1, mis à part que tous les renseignements de localisation de l'utilisateur sont remplacés par les données de localisation du proxy. Ainsi le serveur croit que l'utilisateur emploie le proxy comme UAC. On note que l'authentification est désactivée sur le serveur. En effet, l'authentification est à la charge du proxy exclusivement.
Voici le paquet F4:
REGISTER sip:IP_server:PORT_server SIP/2.0 Via: SIP/2.0/UDP IP_proxy;branch=z9hG4bKe4b6.73e32360000000000000000000000000.0 To: <sip:202@IP_server> From: <sip:202@IP_server>;tag=e377026bd267c209d4540e890df7a250-d84f CSeq: 10 REGISTER Call-ID: 2cbea95840a5f61d-10959@IP_proxy Max-Forwards: 70 Content-Length: 0 User-Agent: kamailio (4.1.4 (x86_64/linux)) Contact: <sip:202@IP_proxy:PORT_proxy> Expires: 60
- F5
Suite à la demande d'enregistrement de du proxy, le serveur accepte en répondant par le code 200 OK. Il définit son tag pour le dialogue entre le serveur et le proxy (To tag), publie les méthodes supportées, le support MIME et SDP.
Voici le paquet en question:
SIP/2.0 200 OK Via: SIP/2.0/UDP IP_server;branch=z9hG4bKe4b6.73e32360000000000000000000000000.0;received=IP_server From: <sip:202@IP_server>;tag=e377026bd267c209d4540e890df7a250-d84f To: <sip:202@IP_server>;tag=as7c35aeaf Call-ID: 2cbea95840a5f61d-10959@IP_proxy CSeq: 10 REGISTER Server: Asterisk PBX 11.10.2 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Expires: 60 Contact: <sip:202@IP_proxy:PORT_proxy>;expires=60 Date: Sun, 27 Jul 2014 17:20:49 GMT Content-Length: 0
Initialisation d'un appel¶
Dans cet exemple, les deux participants sont enregistrés dans le même domaine. Le même proxy SIP est utilisé pour faire transiter les paquets SIP.
INITIALISATION D'UN APPEL (sans l'interaction proxy-server)
Alice's . . . . . . . . . . . . . .SIP. . . . . . . . . . . . . . . Bob's
SIP phone proxy SIP phone
| | |
| INVITE F1 | |
|--------------------------------->| INVITE F2 |
| 100 Trying F3 |------------------------------>|
|<---------------------------------| 180 Ringing F4 |
| 180 Ringing F5 |<------------------------------|
|<---------------------------------| 200 OK F6 |
| 200 OK F7 |<------------------------------|
|<---------------------------------| |
| ACK F8 | |
|----------------------------------------------------------------->|
| Media Session |
| ( proxied ) |
|<================================>|<============================> |
| BYE F9 |
|<-----------------------------------------------------------------|
| 200 OK F10 |
|----------------------------------------------------------------->|
Mis à jour par thomas.boissier il y a plus de 10 ans · 31 révisions