Project

General

Profile

Actions

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:

  1. REGISTER:
    - L'UAC demande un enregistrement auprès du registrar du domaine REALM.
  2. 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.
  3. Route :
    - L'UAC force le routage du paquet vers IP_proxy.
    - lr : l'UAC supporte le loose rooting .
  4. Max-Forward:
    - Le paquet ne doit pas passer par plus de 70 relais SIP.
  5. From :
    - URI: L'URI de l'utilisateur.
    - tag : La moitié de tag de dialogue choisie par l'UAC
  6. 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)
  7. Call-ID :
    - Identifie un dialogue (note: insuffisant pour le hairpinning => tags)
  8. 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.
  9. User-Agent:
    - Nom: Le nom de l'UAC
  10. Contact :
    - URI: Celle que l'UAC propose pour être contacté lors de requêtes ultérieures.
  11. Expires :
    - La durée de validité souhaitée de l'enregistrement en secondes.
  12. Allow :
    - L'ensemble des méthodes supportées par l'UAC.
  13. 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:

  1. 401
    - Le proxy souhaite authentifier l'utilisateur.
  2. 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
  3. 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
  4. "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
  5. Call-ID:
    - L'identifiant de dialogue identique à celui de la requête
  6. 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
  7. WWW-Authenticate :
    - Méthode: méthode d'authentification par hachage
    - realm: le domaine REALM
    - nonce: l'aléa
  8. Server:
    - Le nom du proxy
  9. 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                           |                  
         |----------------------------------------------------------------->|

Updated by thomas.boissier about 6 years ago · 31 revisions