Protocole SIP

1. Architecture SIP

1.1. RFC

https://www.packetizer.com/ipmc/sip/standards.html

...

1.2. Présentation

SIP prend en charge cinq facettes de l’établissement et de la terminaison de communications multimédia :

  • Localisation de l’utilisateur : détermination du système terminal à utiliser pour la communication ;
  • Disponibilité de l’utilisateur : détermination de la volonté de l’appelé à s’engager dans une communication ;
  • Capacités de l’utilisateur : détermination du support et des paramètres de support à utiliser ;
  • Etablissement de session : "sonnerie", établissement des paramètres de session à la fois chez l’appelant et l’appelé ;
  • Gestion de session : y compris le transfert et la terminaison des sessions, la modification des paramètres de session, et l’invocation des services.

SIP n’est pas un système de communications intégré verticalement. SIP est plutôt un composant qui peut être utilisé avec d’autres protocoles de l’IETF pour construire une architecture multimédia complète.

SIP ne fournit pas de services. Plutôt, SIP fournit des primitives qui peuvent être utilisées pour mettre en œuvre différents services. Par exemple, SIP peut localiser un utilisateur et livrer un objet opaque à l’endroit où il se trouve. Une seule primitive est normalement utilisée pour fournir plusieurs services différents.

La nature des services fournis rend la sécurité particulièrement importante. A cette fin, SIP fournit une série de services de sécurité, qui comporte la prévention du déni de service, l’authentification (à la fois d’usager à usager et de mandataire à usager), la protection de l’intégrité, et de services de chiffrement et de confidentialité.

SIP travaille aussi bien avec IPv4 qu’avec IPv6

1.3. AOR

Adresse d’enregistrement (AOR, Address-of-Record) : Une adresse d’enregistrement est un URI SIP ou SIPS qui pointe sur un domaine avec un service de localisation qui peut transposer l’URI en un autre URI où l’utilisateur pourrait être disponible. Normalement, le service de localisation est rempli au moyen des enregistrements. Un AOR est fréquemment vu comme l’"adresse publique" de l’utilisateur.

1.4. Rôles SIP

On trouvera différents rôles logiques en SIP.

User Agents (UA)

UA qui caractérisent les points d'extrémités de la communication ou un B2BUA.

  • UAC : Un client est tout élément de réseau qui envoie une demande SIP et reçoit des réponses SIP. Les clients peuvent ou non interagir directement avec un utilisateur humain. Les clients et proxys d’UA sont des clients.
  • UAS : C’est une entité logique qui génère une réponse à une demande SIP. La réponse accepte, rejette, ou redirige la demande. Ce rôle ne dure que pendant le temps de cette transaction. En d’autres termes, si un logiciel répond à une demande, elle agit comme UAS pour la durée de cette transaction. Si elle génère plus tard une demande, elle assume le rôle d’un UAC pour le traitement de cette transaction.

Proxy

Serveur Proxy : Entité intermédiaire qui agit à la fois comme un serveur et comme un client pour les besoins de l’élaboration de demandes au nom des autres clients.

Un serveur proxy joue principalement un rôle d’acheminement, ce qui signifie que sa tâche est de s’assurer qu’une demande est envoyée à une autre entité "plus proche" de l’utilisateur cible. En cela il est comparable au routeur IP qui transfère le trafic en fonction de l'adresse IP de destination.

Les proxys sont aussi utiles pour mettre en application la politique de routage des appels (par exemple, s’assurer qu’un utilisateur est autorisé à effectuer un appel).

Un proxy interprète, et, si nécessaire, réécrit des parties spécifiques d’un message de demande avant de le retransmettre.

Outbound Proxy : Proxy qui reçoit des demandes de la part d’un client, même si il peut ne pas être le serveur donné par la résolution de l’URI demandée. Normalement un UA est configuré manuellement avec un mandataire de sortie, ou il peut en acquérir la connaissance au moyen de protocoles d’autoconfiguration.

Les notions de Stateful Proxy et et de Stateless Proxy se distinguent par le maintien d'un état des transactions. Alors que le proxy Stateless ne maintient aucun état, le proxy stateful peut accomplir des tâches plus complexes telles que la duplication les transactions, l'absorption des transactions ou d'autres telles que le transfert d'appel.

Serveur de redirection

C’est un serveur d’agent d’utilisateur (UAS) qui génère des réponses 3xx aux demandes qu’il reçoit, amenant le client à contacter un ensemble d’URI de remplacement.

B2BUA

B2BUA, Back-to-Back User Agent : Un B2BUA est une entité logique qui reçoit une demande et la traite comme UAS. Afin de déterminer comment il devrait être répondu à la demande, il agit comme un UAC et génère des demandes. A la différence d’un serveur mandataire, il maintient l’état du dialogue et doit participer à toutes les demandes envoyées dans les dialogues qu’il a établi. Comme c’est un enchaînement d’UAC et d’UAS, aucune définition explicite n’est nécessaire pour son comportement.

REGISTRAR Server et Location Server

Un REGISTRAR Server un serveur qui gère les requêtes REGISTER envoyées par les Users Agents pour signaler leur emplacement courant. Ces requêtes contiennent donc une adresse IP, associée à une URI, qui seront stockées dans une base de données.

Un service de localisation est utilisé par un Redirect Server ou un serveur proxy pour obtenir des informations sur la ou les localisations possibles d’un appelé. Il contient une liste de liens de clés d’address-of-record pour zéro ou plusieurs adresses de contact. Les liens peuvent être créés et retirés de nombreuses façons.

Les URI SIPs sont très similaires dans leur forme à des adresses email : sip:utilisateur@domaine.com

Généralement, des mécanismes d'authentification permettent d'éviter que quiconque puisse s'enregistrer avec n'importe quelle URI.

SBC

Un SBC (Session border controllers) est placé comme élément intermédiaire pour rendre des services entre les UA et les serveurs SIP en matière de sécurité, de camouflage de topologie, de filtrage ou d'assistance dans du NAT Traversal, de chiffrement du trafic.

Gateways

Les Gateways (passerelles) sont des entités logiques qui sont capables d'établir des liaisons vers des destinations non-IP notamment les réseaux PSTN.

1.5. Requêtes SIP

Le client envoie des requêtes au serveur, qui lui renvoie une réponse. Les méthodes de base (RFC 3261) comprises dans ces requêtes sont :

  • INVITE : permet à un client de demander une nouvelle session,
  • ACK : confirme l'établissement de la session,
  • CANCEL : annule un INVITE en suspens,
  • BYE : termine une session en cours,
  • OPTIONS : permet de récupérer les capacités de gestion des usagers, sans ouvrir de session,
  • REGISTER : permet de s'enregistrer auprès d'un serveur d'enregistrement.

D'autres RFC sont venus compléter les capacités du protocole avec de nouvelles méthodes :

  • PRACK : Provisional acknowledgement (RFC 3262)
  • SUBSCRIBE : Subscribes for an Event of Notification from the Notifier (RFC 6665)
  • NOTIFY : Notify the subscriber of a new Event (RFC 6665)
  • PUBLISH : Publishes an event to the Server (RFC 3903)
  • INFO : Sends mid-session information that does not modify the session state (RFC 6086)
  • REFER : Asks recipient to issue SIP request (call transfer.) (RFC 3515)
  • MESSAGE : Transports instant messages using SIP (RFC 3428)
  • UPDATE : Modifies the state of a session without changing the state of the dialog (RFC 3311)

1.6. Réponses SIP

Selon les contextes une réponse est attendue, les réponses possibles sont similaires aux réponses HTTP. Dans le meilleur des cas on obtient un 200 OK.

Une transaction SIP survient entre un client et un serveur et comprend tous les messages depuis la première demande envoyée du client au serveur jusqu’à la réponse finale (non-1xx) envoyée du serveur au client. Si la demande est INVITE et la réponse finale est un non-2xx, la transaction comporte aussi un ACK à la réponse. Le ACK pour une réponse 2xx à une demande INVITE est une transaction distincte.

Un dialogue est une relation SIP d’homologue à homologue qui persiste pendant un certain temps entre deux agents d’utilisateur. Un dialogue est établi par les messages SIP, comme une réponse 2xx à une demande INVITE. Un dialogue est identifié par un identifiant d’appel, une étiquette locale, et une étiquette distante.

  • Provisional (1xx): Request received and being processed.
  • Success (2xx): The action was successfully received, understood, and accepted.
  • Redirection (3xx): Further action needs to be taken (typically by sender) to complete the request.
  • Client Error (4xx): The request contains bad syntax or cannot be fulfilled at the server.
  • Server Error (5xx): The server failed to fulfill an apparently valid request.
  • Global Failure (6xx): The request cannot be fulfilled at any server.

1.7. Messages SIP

A SIP message consists of the following:

  1. Une ligne de dépar (start-line) : Message URI SIP/2.0
  2. Un ou plusieurs champs d'en-tête (header fields)
  3. Une ligne vide indiquant la fin des champs d'en-tête.
  4. Un corps de message optionnel (message body)

Un message SIP est notamment composé de champs d'en-têtes définis dans le RFC 3261 pour la signalisation et le routage des informations entre des entités SIP. SIP utilise le même format que celui qui définit un en-tête HTTP (RFC 2616). Chaque en-tête consiste en un nom de champs suivant d'un deux-points (:) et d'une valeur.

Les champs d'en-tête (header fields) sont :

  1. From : Il indique l'identité de celui qui initié la requête SIP. Cette valeur est souvent valorisée par l'AOR de l'envoyeur. Il comprend un URI SIP ou SIPS voire un "display name" optionnel.

  2. To : Cet en-tête indique le destinataire souhaité pour la requête SIP. Il utilise habituellement l'AOR du destinataire.

  3. Call-ID : Il identifie un dialogue SIP de manière unique. Il est donc identique pour toutes les requêtes et les réponses SIP.

  4. Cseq : Cet en-tête est composé d'une valeur de nombre entier et un nom de méthode. Il identifie, ordonne et séquence les requêtes SIP au sein d'un dialogue. Il permet de différencier les nouveaux messages et les retransmissions.

  5. Via : Le champs Via indique le chemin pris par la requête et identifie où la réponse doit être envoyée. Il indique aussi le transport utilisé. Cet en-tête doit contenir un parmaètre "branch" qui est utilisé pour identifier la transaction créée par la requête. Ce paramètre est utilisé aussi bien par le client que par le serveur. Il doit toujours commencer par un "magic cookie" d'une valeur de "z9hG4bK".

  6. Contact : Cet en-tête identifie un URI SIP ou SIPS où l'UA veux une nouvelle requête SIP.

  7. Allow : Cet en-tête liste les méthodes supportée par l'UA qui génère le message.

  8. Supported : Cet en-tête liste toutes extensions supportées par l'UA autre que celles définies dans le RFC 3261. Les extensions SIP sont représentées comme des étiquettes (tags) option.

  9. Require : Identique au précédent "Supported" mais obligatoire pour aboutir la transaction.

  10. Content-Type : Cet en-tête indique le type de corps de message (body)

  11. Content-Lenght : Indique la longueur du corps du message en décimal. Il est obligatoire quand les messages SIP sont transportés sur TCP.

Exemple d'une transaction BYE-200

Requête BYE

BYE sip:201@10.33.6.101:5060 SIP/2.0
Via: SIP/2.0/UDP 10.33.6.100;branch=z9hG4bKac795178845
Max-Forwards: 70
From: <sip:101@10.33.6.100;user=phone>;tag=1c782609321
To: <sip:201@10.33.6.101>;tag=1c1450530943
Call-ID: 1450530377152201062221@10.33.6.101
CSeq: 1 BYE
Supported: em,timer,replaces,path,resource-priority
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE
User-Agent: IPP/v.6.20A.027.012
Reason: Q.850 ;cause=16 ;text="local"
Content-Length: 0

Réponse 200 OK

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.33.6.100;branch=z9hG4bKac795178845
From: <sip:101@10.33.6.100;user=phone>;tag=1c782609321
To: <sip:201@10.33.6.101>;tag=1c1450530943
Call-ID: 1450530377152201062221@10.33.6.101
CSeq: 1 BYE
Contact: <sip:201@10.33.6.101:5060>
Supported: em,timer,replaces,path,resource-priority
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE
Server: GW/v.6.20A.027.012
Content-Length: 0

1.8. Scénarios SIP

Selon le contexte d'exécution on trouvera probablement plusieurs intervenants dans une session SIP.

Processus d'enregistrement

  • F1 - initial registration request from SIP User Agent with it's address information (AOR)
  • F2 - answer from SIP Registrar with the information about necessary login
  • F3 - new registration request with login
  • F4 - confirm of successful registration on SIP Registrar

Flux d'appel SIP entre UA et serveurs de redirection entre proxys et UAs

Flux d'appel B2BUA

1.9. UA en ligne de commande

  • PJSUA
  • linphonec
  • linphonecsh

Installation PJSUA

wget http://www.pjsip.org/release/1.12/pjproject-1.12.tar.bz2
tar -xjf pjproject-1.12.tar.bz2
cd pjproject-1.12/
./configure
make dep && make && make install
cp pjsip-apps/bin/pjsua* /usr/local/bin/pjsua

Exemple d'usage de PJSUA

Exemple d'un UA qui s'enregistre sur sip:3302@172.16.98.223, qui répond automatiquement aux appels en bloucle.

# cat autoansw.conf
--null-audio
--realm asterisk
--registrar sip:172.16.98.223
--id sip:3302@172.16.98.223
--username 3302
--password test1234
--play-file /root/believe-its-free.wav
--auto-answer 200
--auto-play --auto-loop
--max-calls 10
# pjsua --config-file autoansw.conf 

Installation du dépôt Linphone

En Centos 7, ajouter ceci dans le fichier /etc/yum.repos.d/Belledonne.repo

[Belledonne]
name=Belledonne Communications
baseurl=https://www.linphone.org/snapshots/centos7
enabled=1
gpgcheck=0
priority=1
# yum update
# yum install linphone-devel

linphonecsh

Exemple linphonecsh

# linphonecsh init
# linphonecsh register --host 172.16.98.223 --username 3303 --password test1234
# linphonecsh dial "sip:3302@172.16.98.223"

linphonec

Exemple linephonec

# linphonec -c .linphonerc
Warning: video is disabled in linphonec, use -V or -C or -D to enable.
linphonec> register sip:3303@172.16.98.223 sip:172.16.98.223 test1234
linphonec> Registration on <sip:172.16.98.223> successful.
linphonec> call sip:3302@172.16.98.223
Establishing call id to <sip:3302@172.16.98.223>, assigned id 1
Contacting <sip:3302@172.16.98.223>
linphonec> Call 1 to <sip:3302@172.16.98.223> in progress.
linphonec> Remote ringing.
linphonec> Remote ringing...
linphonec> Call 1 to <sip:3302@172.16.98.223> ringing.
Remote ringing.
linphonec> Call 1 with <sip:3302@172.16.98.223> connected.
Call answered by <sip:3302@172.16.98.223>.
linphonec> Media streams established with <sip:3302@172.16.98.223> for call 1 (audio).
linphonec> terminate
Call ended
linphonec> Call 1 with <sip:3302@172.16.98.223> ended (No error).
linphonec> quit
Terminating...
Unregistration on <sip:172.16.98.223> done.
#

2. INVITE SIP UAC/UAS

On peut éprouver les capacités de SIP dans un contexte UAC vers UAS sans serveur proxy. Le plus simple est d'installer un softphone comme Linephone ou CSIPsimple ou encore PJSUA sur deux ordinateurs du réseau local.

Ici la destination est encodée directement dans le logiciel : sip:192.168.1.8. Aucun paramètre n'est configuré sur le logiciel.

Source : https://www.cloudshark.org/captures/f22c8443205b

2.1. Requête INVITE SDP

Le premier message est une requête INVITE décrite comme suit

Session Initiation Protocol (INVITE)
    Request-Line: INVITE sip:192.168.1.8 SIP/2.0
    Message Header
        Via: SIP/2.0/UDP 192.168.1.7:5060;branch=z9hG4bK.zQpMKMKmd;rport
        From: <sip:linphone@192.168.1.7>;tag=zDTUMmqVS
        To: sip:192.168.1.8
        CSeq: 20 INVITE
        Call-ID: dJpMERl3hb
        Max-Forwards: 70
        Supported: outbound
        Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE
        Content-Type: application/sdp
        Content-Length: 585
        Contact: <sip:linphone@192.168.1.7>;+sip.instance="<urn:uuid:aa9274b7-03d6-4a98-b5f3-474e7603a6d0>"
        User-Agent: Linphone/3.9.1 (belle-sip/1.4.2)
    Message Body

2.2. Réponse provisionnelle 100 Trying

  Status-Line: SIP/2.0 100 Trying
  Message Header
        Via: SIP/2.0/UDP 192.168.1.7:5060;rport=5060;received=192.168.1.7;branch=z9hG4bK.zQpMKMKmd
        Call-ID: dJpMERl3hb
        From: <sip:linphone@192.168.1.7>;tag=zDTUMmqVS
        To: <sip:192.168.1.8>
        CSeq: 20 INVITE
        Content-Length:  0

2.3. Réponse provisionnelle 180 Ringing

    Status-Line: SIP/2.0 180 Ringing
    Message Header
        Via: SIP/2.0/UDP 192.168.1.7:5060;rport=5060;received=192.168.1.7;branch=z9hG4bK.zQpMKMKmd
        Call-ID: dJpMERl3hb
        From: <sip:linphone@192.168.1.7>;tag=zDTUMmqVS
        To: <sip:192.168.1.8>;tag=2ALrvgnIqfZqo1h4Cs5PAG9HS3b4GQNz
        CSeq: 20 INVITE
        Contact: <sip:192.168.1.8:5060>
        Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
        Content-Length:  0

2.4. Réponse 200 OK SDP

    Status-Line: SIP/2.0 200 OK
    Message Header
        Via: SIP/2.0/UDP 192.168.1.7:5060;rport=5060;received=192.168.1.7;branch=z9hG4bK.zQpMKMKmd
        Call-ID: dJpMERl3hb
        From: <sip:linphone@192.168.1.7>;tag=zDTUMmqVS
        To: <sip:192.168.1.8>;tag=2ALrvgnIqfZqo1h4Cs5PAG9HS3b4GQNz
        CSeq: 20 INVITE
        Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
        Contact: <sip:192.168.1.8:5060>
        Supported: replaces, 100rel, timer, norefersub
        Content-Type: application/sdp
        Content-Length:   300
    Message Body
        Session Description Protocol

2.5. ACK

    Request-Line: ACK sip:192.168.1.8:5060 SIP/2.0
    Message Header
        Via: SIP/2.0/UDP 192.168.1.7:5060;rport;branch=z9hG4bK.fPDRQHIBm
        From: <sip:linphone@192.168.1.7>;tag=zDTUMmqVS
        To: <sip:192.168.1.8>;tag=2ALrvgnIqfZqo1h4Cs5PAG9HS3b4GQNz
        CSeq: 20 ACK
        Call-ID: dJpMERl3hb
        Max-Forwards: 70

2.6. Transfert des medias

Le transfert de la voix est assuré par RTP codé en G.711 PCMU. Le format a été négocié par SDP dans la requête INVITE et la réponse 200 OK.

    Request-Line: INVITE sip:192.168.1.8 SIP/2.0
    Message Header
    Message Body
        Session Description Protocol
            Session Description Protocol Version (v): 0
            Owner/Creator, Session Id (o): linphone 1108 2378 IN IP4 192.168.1.7
            Session Name (s): Talk
            Connection Information (c): IN IP4 192.168.1.7
            Time Description, active time (t): 0 0
            Session Attribute (a): rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics
            Media Description, name and address (m): audio 7078 RTP/AVP 96 97 98 99 0 8 101 100 102
                Media Type: audio
                Media Port: 7078
                Media Protocol: RTP/AVP
                Media Format: DynamicRTP-Type-96
                Media Format: DynamicRTP-Type-97
                Media Format: DynamicRTP-Type-98
                Media Format: DynamicRTP-Type-99
                Media Format: ITU-T G.711 PCMU
                Media Format: ITU-T G.711 PCMA
                Media Format: DynamicRTP-Type-101
                Media Format: DynamicRTP-Type-100
                Media Format: DynamicRTP-Type-102
            Media Attribute (a): rtpmap:96 opus/48000/2
            Media Attribute (a): fmtp:96 useinbandfec=1
            Media Attribute (a): rtpmap:97 SILK/16000
            Media Attribute (a): rtpmap:98 speex/16000
            Media Attribute (a): fmtp:98 vbr=on
            Media Attribute (a): rtpmap:99 speex/8000
            Media Attribute (a): fmtp:99 vbr=on
            Media Attribute (a): rtpmap:101 telephone-event/48000
            Media Attribute (a): rtpmap:100 telephone-event/16000
            Media Attribute (a): rtpmap:102 telephone-event/8000
            Media Description, name and address (m): video 9078 RTP/AVP 96 97
            Media Attribute (a): rtpmap:96 VP8/90000
            Media Attribute (a): rtpmap:97 H264/90000
            Media Attribute (a): fmtp:97 profile-level-id=42801F
    Status-Line: SIP/2.0 200 OK
    Message Header
    Message Body
        Session Description Protocol
            Session Description Protocol Version (v): 0
            Owner/Creator, Session Id (o): - 3671180764 3671180766 IN IP4 192.168.1.8
            Session Name (s): pjmedia
            Connection Information (c): IN IP4 192.168.1.8
            Time Description, active time (t): 0 0
            Media Description, name and address (m): audio 4006 RTP/AVP 0 102
            Connection Information (c): IN IP4 192.168.1.8
            Media Attribute (a): rtcp:4007 IN IP4 192.168.1.8
            Media Attribute (a): sendrecv
            Media Attribute (a): rtpmap:0 PCMU/8000
            Media Attribute (a): rtpmap:102 telephone-event/8000
            Media Attribute (a): fmtp:102 0-16
            Media Description, name and address (m): video 0 RTP/AVP
            Connection Information (c): IN IP4 192.168.1.8

2.7. Requête BYE

    Request-Line: BYE sip:192.168.1.8:5060 SIP/2.0
    Message Header
        Via: SIP/2.0/UDP 192.168.1.7:5060;branch=z9hG4bK.UKDJAE8~q;rport
        From: <sip:linphone@192.168.1.7>;tag=zDTUMmqVS
        To: <sip:192.168.1.8>;tag=2ALrvgnIqfZqo1h4Cs5PAG9HS3b4GQNz
        CSeq: 21 BYE
        Call-ID: dJpMERl3hb
        Max-Forwards: 70
        User-Agent: Linphone/3.9.1 (belle-sip/1.4.2)

2.8. Réponse OK

    Status-Line: SIP/2.0 200 OK
    Message Header
        Via: SIP/2.0/UDP 192.168.1.7:5060;rport=5060;received=192.168.1.7;branch=z9hG4bK.UKDJAE8~q
        Call-ID: dJpMERl3hb
        From: <sip:linphone@192.168.1.7>;tag=zDTUMmqVS
        To: <sip:192.168.1.8>;tag=2ALrvgnIqfZqo1h4Cs5PAG9HS3b4GQNz
        CSeq: 21 BYE
        Content-Length:  0

3. REGISTER

3.1. REGISTER simple

Entre l'UAC 172.16.98.182 et l'UAS 172.16.98.102.

Source : https://www.cloudshark.org/captures/de9c2cf75368

REGISTER sip:domain.xyz SIP/2.0
Via: SIP/2.0/UDP 172.16.98.182:5060;rport;branch=z9hG4bK1013779528
From: <sip:telephone1@domain.xyz>;tag=1182049044
To: <sip:telephone1@domain.xyz>
Call-ID: 1077245679
CSeq: 1 REGISTER
Contact: <sip:telephone1@172.16.98.182;line=f0d50acfece3520>
Max-Forwards: 70
User-Agent: Linphone/3.6.1 (eXosip2/4.0.0)
Expires: 3600
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.16.98.182:5060;rport=5060;branch=z9hG4bK1013779528
Contact: <sip:telephone1@172.16.98.182;line=f0d50acfece3520>;expires=3600
To: <sip:telephone1@domain.xyz>;tag=2021e220
From: <sip:telephone1@domain.xyz>;tag=1182049044
Call-ID: 1077245679
CSeq: 1 REGISTER
User-Agent: repro 1.9.7
Content-Length: 0

Pour annuler un enregistrement, une nouvelle requête REGISTER avec un champ Expires: 0 dans :

REGISTER sip:domain.xyz SIP/2.0
Via: SIP/2.0/UDP 172.16.98.182:5060;rport;branch=z9hG4bK410623604
From: <sip:telephone1@domain.xyz>;tag=1182049044
To: <sip:telephone1@domain.xyz>
Call-ID: 1077245679
CSeq: 2 REGISTER
Contact: <sip:telephone1@172.16.98.182;line=f0d50acfece3520>
Max-Forwards: 70
User-Agent: Linphone/3.6.1 (eXosip2/4.0.0)
Expires: 0
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.16.98.182:5060;rport=5060;branch=z9hG4bK410623604
To: <sip:telephone1@domain.xyz>;tag=09697f6c
From: <sip:telephone1@domain.xyz>;tag=1182049044
Call-ID: 1077245679
CSeq: 2 REGISTER
User-Agent: repro 1.9.7
Content-Length: 0

3.2. REGISTER avec Authentification MD5

Le RFC 3261 recommande que les requêtes SIP soient authentifiées comme indiqué dans le RFC 2617 (HTTP Authentication: Basic and Digest Access Authentication).

Entre l'UAC 172.16.98.1 et 172.16.98.101.

image

Source : https://www.cloudshark.org/captures/423ab1d45e27

...

REGISTER sip:172.16.98.101;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 172.16.98.1:42952;branch=z9hG4bK-d8754z-531c0fb072273b86-1---d8754z-
Max-Forwards: 70
Contact: <sip:telephone1@172.16.98.1:42952;rinstance=564a2ed14798bc07;transport=UDP>
To: <sip:telephone1@172.16.98.101;transport=UDP>
From: <sip:telephone1@172.16.98.101;transport=UDP>;tag=0976af15
Call-ID: MzlhNDk0Nzg0MjE0MTEyNzRlM2VhNGYyYjgzYzc0MzA.
CSeq: 1 REGISTER
Expires: 3600
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
Supported: replaces, norefersub, extended-refer, timer, X-cisco-serviceuri
User-Agent: Z 3.3.21933 r21903
Allow-Events: presence, kpml
Content-Length: 0

Le serveur SIP répond avec 401 Unauthorized et indique un champ nécessaire à l'authentification WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="26235be0"

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 172.16.98.1:42952;branch=z9hG4bK-d8754z-531c0fb072273b86-1---d8754z-;received=172.16.98.1
From: <sip:telephone1@172.16.98.101;transport=UDP>;tag=0976af15
To: <sip:telephone1@172.16.98.101;transport=UDP>;tag=as108b6b97
Call-ID: MzlhNDk0Nzg0MjE0MTEyNzRlM2VhNGYyYjgzYzc0MzA.
CSeq: 1 REGISTER
Server: Asterisk PBX 11.7.0~dfsg-1ubuntu1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="26235be0"
Content-Length: 0

Une nouvelle requête (voir Cseq: 2) fournit les paramètres adéquat : Authorization: Digest username="telephone1",realm="asterisk",nonce="26235be0",uri="sip:172.16.98.101;transport=UDP",response="f76185db0be3a8ba2494f5fc4ea99eed",algorithm=MD5

REGISTER sip:172.16.98.101;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 172.16.98.1:42952;branch=z9hG4bK-d8754z-8de228c832cb6988-1---d8754z-
Max-Forwards: 70
Contact: <sip:telephone1@172.16.98.1:42952;rinstance=564a2ed14798bc07;transport=UDP>
To: <sip:telephone1@172.16.98.101;transport=UDP>
From: <sip:telephone1@172.16.98.101;transport=UDP>;tag=0976af15
Call-ID: MzlhNDk0Nzg0MjE0MTEyNzRlM2VhNGYyYjgzYzc0MzA.
CSeq: 2 REGISTER
Expires: 3600
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
Supported: replaces, norefersub, extended-refer, timer, X-cisco-serviceuri
User-Agent: Z 3.3.21933 r21903
Authorization: Digest username="telephone1",realm="asterisk",nonce="26235be0",uri="sip:172.16.98.101;transport=UDP",response="f76185db0be3a8ba2494f5fc4ea99eed",algorithm=MD5
Allow-Events: presence, kpml
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.16.98.1:42952;branch=z9hG4bK-d8754z-8de228c832cb6988-1---d8754z-;received=172.16.98.1
From: <sip:telephone1@172.16.98.101;transport=UDP>;tag=0976af15
To: <sip:telephone1@172.16.98.101;transport=UDP>;tag=as108b6b97
Call-ID: MzlhNDk0Nzg0MjE0MTEyNzRlM2VhNGYyYjgzYzc0MzA.
CSeq: 2 REGISTER
Server: Asterisk PBX 11.7.0~dfsg-1ubuntu1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Expires: 3600
Contact: <sip:telephone1@172.16.98.1:42952;rinstance=564a2ed14798bc07;transport=UDP>;expires=3600
Date: Wed, 11 May 2016 11:55:19 GMT
Content-Length: 0

3.3. REGISTER avec utilisateur erroné

Dans cette exemple, l'UA tente de s'authentifier sous un nom d'utilisateur (telephone0) inexistant sur le serveur SIP. Le message d'erreur est "403 Forbidden".

Source : https://www.cloudshark.org/captures/10222a758905

3.4. REGISTER avec mot de passe erroné

Dans cette exemple, l'UA tente de s'authentifier avec un mot de passe erroné. Le message d'erreur est aussi dans ce cas "403 Forbidden".

Source : https://www.cloudshark.org/captures/784f68cbb09a

3.5. Découverte de mots de passe

4. Proxy SIP UDP

Un appel (sip:telephone1@domain.xyz) entre 172.16.98.182 et 172.16.98.1 (sip:telephone2@domain.xyz)

  • UAC : 172.16.98.182
  • UAS : 172.16.98.1
  • Proxy : 172.16.98.102

Source : https://www.cloudshark.org/captures/5881e936996f

Champs Via, Max-Forwards, Contact.

4.1. INVITE (telephone1 → Proxy)

4.2. INVITE (Proxy → telephone2)

Champ Via ajouté

4.3. 100 Trying, 180 Ringing

Réponses routées à travers le saut noté dans le deuxième champ "Via". La réponse 180 Ringing du correspondant ajoute un tag au champ "To:".

4.4. 200 OK

La combinaison des champs To-tag From-Tag et Call-ID identifient le dialogue entre telephone1 et Telephone2

5. B2BUA

5.1. Conversation entre un Asterisk

Avec une topologie comprenant un B2BUA, le serveur établit un dialogue respectivement avec chaque intervenant impliqué dans une session multimedia. Il est donc le seul à parler en SIP avec les différents UA.

Dans cet exemple l'utilisateur telephone1 (172.16.98.1) tente de joindre le numéro de téléphone 2302. Cet appel routé jusqu'au périphérique telephone2 (172.16.98.145) par le B2BUA (172.16.98.101). Le B2BUA établit un dialogue avec les deux UA qui doivent s'échanger une session multimédia.

Source : https://www.cloudshark.org/captures/b89478f0b2d8

6. Flux SIP Trapéziodal

6.1. Etablissement de session à travers deux proxy

Source : https://tools.ietf.org/html/rfc3665#section-3.2

Alice           Proxy 1          Proxy 2            Bob
     |                |                |                |
     |   INVITE F1    |                |                |
     |--------------->|                |                |
     |     407 F2     |                |                |
     |<---------------|                |                |
     |     ACK F3     |                |                |
     |--------------->|                |                |
     |   INVITE F4    |                |                |
     |--------------->|   INVITE F5    |                |
     |     100  F6    |--------------->|   INVITE F7    |
     |<---------------|     100  F8    |--------------->|
     |                |<---------------|                |
     |                |                |     180 F9     |
     |                |    180 F10     |<---------------|
     |     180 F11    |<---------------|                |
     |<---------------|                |     200 F12    |
     |                |    200 F13     |<---------------|
     |     200 F14    |<---------------|                |
     |<---------------|                |                |
     |     ACK F15    |                |                |
     |--------------->|    ACK F16     |                |
     |                |--------------->|     ACK F17    |
     |                |                |--------------->|
     |                Both Way RTP Media                |
     |<================================================>|
     |                |                |     BYE F18    |
     |                |    BYE F19     |<---------------|
     |     BYE F20    |<---------------|                |
     |<---------------|                |                |
     |     200 F21    |                |                |
     |--------------->|     200 F22    |                |
     |                |--------------->|     200 F23    |
     |                |                |--------------->|
     |                |                |                |

   ```

   In this scenario, Alice completes a call to Bob using two proxies
   Proxy 1 and Proxy 2.  The initial INVITE (F1) contains a pre-loaded
   Route header with the address of Proxy 1 (Proxy 1 is configured as a
   default outbound proxy for Alice).  The request does not contain the
   Authorization credentials Proxy 1 requires, so a 407 Proxy
   Authorization response is sent containing the challenge information.
   A new INVITE (F4) is then sent containing the correct credentials and
   the call proceeds.  The call terminates when Bob disconnects by
   initiating a BYE message.

   Proxy 1 inserts a Record-Route header into the INVITE message to
   ensure that it is present in all subsequent message exchanges.  Proxy
   2 also inserts itself into the Record-Route header.  The ACK (F15)
   and BYE (F18) both have a Route header.

### 6.2. Message Details

####   F1 INVITE Alice -> Proxy 1
INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b43 Max-Forwards: 70 Route: From: Alice sip:alice@atlanta.example.com;tag=9fxced76sl To: Bob sip:bob@biloxi.example.com Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: sip:alice@client.atlanta.example.com;transport=tcp Content-Type: application/sdp Content-Length: 151

v=0 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com s=- c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000

   /* Proxy 1 challenges Alice for authentication */


####   F2 407 Proxy Authorization Required Proxy 1 -> Alice
SIP/2.0 407 Proxy Authorization Required Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b43 ;received=192.0.2.101 From: Alice sip:alice@atlanta.example.com;tag=9fxced76sl To: Bob sip:bob@biloxi.example.com;tag=3flal12sf Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Proxy-Authenticate: Digest realm="atlanta.example.com", qop="auth", nonce="f84f1cec41e6cbe5aea9c8e88d359", opaque="", stale=FALSE, algorithm=MD5 Content-Length: 0
####   F3 ACK Alice -> Proxy 1
ACK sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b43 Max-Forwards: 70 From: Alice sip:alice@atlanta.example.com;tag=9fxced76sl To: Bob sip:bob@biloxi.example.com;tag=3flal12sf Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 ACK Content-Length: 0

``` /* Alice responds be re-sending the INVITE with authentication credentials in it. */

F4 INVITE Alice -> Proxy 1

   INVITE sip:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
   Max-Forwards: 70
   Route: <sip:ss1.atlanta.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 2 INVITE
   Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
   Proxy-Authorization: Digest username="alice",
    realm="atlanta.example.com",
    nonce="wf84f1ceczx41ae6cbe5aea9c8e88d359", opaque="",
    uri="sip:bob@biloxi.example.com",
    response="42ce3cef44b22f50c6a6071bc8"
   Content-Type: application/sdp
   Content-Length: 151

   v=0
   o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
   s=-
   c=IN IP4 192.0.2.101
   t=0 0
   m=audio 49172 RTP/AVP 0
   a=rtpmap:0 PCMU/8000

/* Proxy 1 accepts the credentials and forwards the INVITE to Proxy 2. Client for Alice prepares to receive data on port 49172 from the network. */

F5 INVITE Proxy 1 -> Proxy 2

   INVITE sip:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    ;received=192.0.2.101
   Max-Forwards: 69
   Record-Route: <sip:ss1.atlanta.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 2 INVITE
   Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
   Content-Type: application/sdp
   Content-Length: 151

   v=0
   o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
   s=-
   c=IN IP4 192.0.2.101
   t=0 0
   m=audio 49172 RTP/AVP 0
   a=rtpmap:0 PCMU/8000

F6 100 Trying Proxy 1 -> Alice

   SIP/2.0 100 Trying
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    ;received=192.0.2.101
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 2 INVITE
   Content-Length: 0

F7 INVITE Proxy 2 -> Bob

   INVITE sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1
   Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
    ;received=192.0.2.111
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    ;received=192.0.2.101
   Max-Forwards: 68
   Record-Route: <sip:ss2.biloxi.example.com;lr>,
    <sip:ss1.atlanta.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 2 INVITE
   Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
   Content-Type: application/sdp
   Content-Length: 151

   v=0
   o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
   s=-
   c=IN IP4 192.0.2.101
   t=0 0
   m=audio 49172 RTP/AVP 0
   a=rtpmap:0 PCMU/8000

F8 100 Trying Proxy 2 -> Proxy 1

   SIP/2.0 100 Trying
   Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
    ;received=192.0.2.111
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    ;received=192.0.2.101
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 2 INVITE
   Content-Length: 0

F9 180 Ringing Bob -> Proxy 2

   SIP/2.0 180 Ringing
   Via: SIP/2.0/TCP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1
    ;received=192.0.2.222
   Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
    ;received=192.0.2.111
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    ;received=192.0.2.101
   Record-Route: <sip:ss2.biloxi.example.com;lr>,
    <sip:ss1.atlanta.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=314159
   Call-ID: 3848276298220188511@atlanta.example.com
   Contact: <sip:bob@client.biloxi.example.com;transport=tcp>
   CSeq: 2 INVITE
   Content-Length: 0

F10 180 Ringing Proxy 2 -> Proxy 1

   SIP/2.0 180 Ringing
   Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
    ;received=192.0.2.111
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    ;received=192.0.2.101
   Record-Route: <sip:ss2.biloxi.example.com;lr>,
    <sip:ss1.atlanta.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=314159
   Call-ID: 3848276298220188511@atlanta.example.com
   Contact: <sip:bob@client.biloxi.example.com;transport=tcp>
   CSeq: 2 INVITE
   Content-Length: 0

F11 180 Ringing Proxy 1 -> Alice

   SIP/2.0 180 Ringing
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    ;received=192.0.2.101
   Record-Route: <sip:ss2.biloxi.example.com;lr>,
    <sip:ss1.atlanta.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=314159
   Call-ID: 3848276298220188511@atlanta.example.com
   Contact: <sip:bob@client.biloxi.example.com;transport=tcp>
   CSeq: 2 INVITE
   Content-Length: 0

F12 200 OK Bob -> Proxy 2

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1
    ;received=192.0.2.222
   Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
    ;received=192.0.2.111
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    ;received=192.0.2.101
   Record-Route: <sip:ss2.biloxi.example.com;lr>,
    <sip:ss1.atlanta.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=314159
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 2 INVITE
   Contact: <sip:bob@client.biloxi.example.com;transport=tcp>
   Content-Type: application/sdp
   Content-Length: 147

   v=0
   o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
   s=-
   c=IN IP4 192.0.2.201
   t=0 0
   m=audio 3456 RTP/AVP 0
   a=rtpmap:0 PCMU/8000

F13 200 OK Proxy 2 -> Proxy 1

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
    ;received=192.0.2.111
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    ;received=192.0.2.101
   Record-Route: <sip:ss2.biloxi.example.com;lr>,
    <sip:ss1.atlanta.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=314159
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 2 INVITE
   Contact: <sip:bob@client.biloxi.example.com;transport=tcp>
   Content-Type: application/sdp
   Content-Length: 147

   v=0
   o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
   s=-
   c=IN IP4 192.0.2.201
   t=0 0
   m=audio 3456 RTP/AVP 0
   a=rtpmap:0 PCMU/8000

F14 200 OK Proxy 1 -> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
    ;received=192.0.2.101
   Record-Route: <sip:ss2.biloxi.example.com;lr>,
    <sip:ss1.atlanta.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=314159
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 2 INVITE
   Contact: <sip:bob@client.biloxi.example.com;transport=tcp>
   Content-Type: application/sdp
   Content-Length: 147

   v=0
   o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
   s=-
   c=IN IP4 192.0.2.201
   t=0 0
   m=audio 3456 RTP/AVP 0
   a=rtpmap:0 PCMU/8000

F15 ACK Alice -> Proxy 1

   ACK sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b76
   Max-Forwards: 70
   Route: <sip:ss1.atlanta.example.com;lr>,
    <sip:ss2.biloxi.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=314159
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 2 ACK
   Content-Length: 0

F16 ACK Proxy 1 -> Proxy 2

   ACK sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b76
    ;received=192.0.2.101
   Max-Forwards: 69
   Route: <sip:ss2.biloxi.example.com;lr>
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=314159
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 2 ACK
   Content-Length: 0

F17 ACK Proxy 2 -> Bob

   ACK sip:bob@client.biloxi.example.com SIP/2.0
   Via: SIP/2.0/TCP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1
   Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
    ;received=192.0.2.111
   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b76
    ;received=192.0.2.101
   Max-Forwards: 68
   From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   To: Bob <sip:bob@biloxi.example.com>;tag=314159
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 2 ACK
   Content-Length: 0

/* RTP streams are established between Alice and Bob */

/* Bob Hangs Up with Alice. */

/* Again, note that the CSeq is NOT 3. Alice and Bob maintain their own separate CSeq counts */

F18 BYE Bob -> Proxy 2

   BYE sip:alice@client.atlanta.example.com SIP/2.0
   Via: SIP/2.0/TCP client.biloxi.example.com:5060;branch=z9hG4bKnashds7
   Max-Forwards: 70
   Route: <sip:ss2.biloxi.example.com;lr>,
    <sip:ss1.atlanta.example.com;lr>
   From: Bob <sip:bob@biloxi.example.com>;tag=314159
   To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 1 BYE
   Content-Length: 0

F19 BYE Proxy 2 -> Proxy 1

   BYE sip:alice@client.atlanta.example.com SIP/2.0
   Via: SIP/2.0/TCP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1
   Via: SIP/2.0/TCP client.biloxi.example.com:5060;branch=z9hG4bKnashds7
    ;received=192.0.2.201
   Max-Forwards: 69
   Route: <sip:ss1.atlanta.example.com;lr>
   From: Bob <sip:bob@biloxi.example.com>;tag=314159
   To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 1 BYE
   Content-Length: 0

F20 BYE Proxy 1 -> Alice

   BYE sip:alice@client.atlanta.example.com SIP/2.0
   Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
   Via: SIP/2.0/TCP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1
    ;received=192.0.2.222
   Via: SIP/2.0/TCP client.biloxi.example.com:5060;branch=z9hG4bKnashds7
    ;received=192.0.2.201
   Max-Forwards: 68
   From: Bob <sip:bob@biloxi.example.com>;tag=314159
   To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 1 BYE
   Content-Length: 0

F21 200 OK Alice -> Proxy 1

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
    ;received=192.0.2.111
   Via: SIP/2.0/TCP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1
    ;received=192.0.2.222
   Via: SIP/2.0/TCP client.biloxi.example.com:5060;branch=z9hG4bKnashds7
    ;received=192.0.2.201
   From: Bob <sip:bob@biloxi.example.com>;tag=314159
   To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 1 BYE
   Content-Length: 0

F22 200 OK Proxy 1 -> Proxy 2

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1
    ;received=192.0.2.222
   Via: SIP/2.0/TCP client.biloxi.example.com:5060;branch=z9hG4bKnashds7
    ;received=192.0.2.101
   From: Bob <sip:bob@biloxi.example.com>;tag=314159
   To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 1 BYE
   Content-Length: 0

F23 200 OK Proxy 2 -> Bob

   SIP/2.0 200 OK
   Via: SIP/2.0/TCP client.biloxi.example.com:5060;branch=z9hG4bKnashds7
    ;received=192.0.2.201
   From: Bob <sip:bob@biloxi.example.com>;tag=314159
   To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
   Call-ID: 3848276298220188511@atlanta.example.com
   CSeq: 1 BYE
   Content-Length: 0

7. Extensions SIP

  • SIP Message Waiting Indication: Extension in RFC 3842
  • SIP method info: Extension in RFC 2976
  • SIP method message: Extension in RFC 3428
  • SIP method notify: Extension in RFC 2848 PINT
  • SIP method prack: Extension in RFC 3262
  • SIP method PUBLISH: Extension is RFC 3903
  • SIP method refer: Extension in RFC 3515
  • SIP method subscribe: Extension in RFC 2848 PINT
  • SIP method unsubscribe: Extension in RFC 2848 PINT
  • SIP method update: Extension in RFC 3311
  • SIP Specific Event Notification: Extension in RFC 3265

8. SIP sur TLS

...

9. Réponses SIP

9.1. Informational(1xx)

Informational responses are used to indicate call progress. Normally the responses are end to end (except 100 Trying). The main objective of informational responses is to stop retransmission of INVITE requests.

Informational responses include the following responses:

100 Trying

This special case response is only a hop-by-hop request.

It is never forwarded and may not contain a message body.

It is used to avoid the retransmission of INVITE requests.

180 Ringing

This response is used to indicate that an INVITE has been received by the user agent and alerting is taking place.

181 Call is Being Forwarded

This response is used to indicate that the call has been forwarded to another endpoint.

It is sent when the information may be of use to the caller.

It gives the status of the caller, as a forwarding operation may result in the call taking longer to be answered.

182 Call Queued

This response is used to indicate that the INVITE has been received and will be processed in a queue.

183 Session Progress

It indicates that information about the progress of a session may be present in a message body or media stream.

Unlike a 100 Trying response, a 183 is an end-to-end response and establishes a dialog.

A typical use of this response is to allow a UAC to hear a ringtone, busy tone, or recorded announcement in calls through a gateway into the PSTN.

9.2. Success(2xx)

This class of responses is meant for indicating that a request has been accepted. It includes the following responses:

200 OK

200 OK is used to accept a session invitation. It indicates a successful completion or receipt of a request.

202 Accepted

202 Accepted indicates that the UAS has received and understood the request, but that the request may not have been authorized or processed by the server.

It is commonly used in responses to SUBSCRIBE, REFER methods.

9.3. Redirection(3xx)

Generally these class responses are sent by redirect servers in response to INVITE. They are also known as redirect class responses. It includes the following responses:

300 Multiple Choices

It contains multiple Contact header fields to indicate that the location service has returned multiple possible locations for the SIP URI in the Request-URI.

301 Moved Permanently

This redirection response contains a Contact header field with the new permanent URI of the called party.

The address can be saved and used in future INVITE requests.

302 Moved Temporarily

This redirection response contains a URI that is currently valid but is not permanent.

That is, the location is valid for the duration of the time specified.

305 Use Proxy

This response contains a URI that points to a proxy server having authoritative information about the calling party.

This response could be sent by a UAS issuing a proxy for incoming call screening.

380 Alternative Service

This response returns a URI that indicates the type of service the called party would like.

For example, a call could be redirected to a voicemail server.

9.4. Client Error(4xx)

Client error responses indicate that the request cannot be fulfilled as some errors are identified from the UAC side. The response codes are generally sent by UAS. Upon receiving an error message, the client should resend the request by modifying it based on the response. Discussed below are some of the important client error responses.

400 Bad Request

It indicates that the request was not understood by the server.

Request might be missing required header fields such as To, From, Call-ID, or CSeq.

401 Unauthorized

It indicates that the request requires the user to perform authentication.

401 Unauthorized is normally sent by a registrar server for REGISTER request.

The response contains WWW-Authenticate header field which requests for correct credentials from the calling user agent.

401 Unauthorized

A subsequent REGISTER will trigger from the User Agent with correct credentials.

403 Forbidden

403 Forbidden is sent when the server has understood the request, found the request to be correctly formulated, but will not service the request.

This response is not used when authorization is required.

404 Not Found

404 Not Found indicates that the user identified by the SIP URI in the Request-URI cannot be located by the server or that the user is not currently signed on with the user agent.

405 Method Not Allowed

It indicates that the server or user agent has received and understood a request but is not willing to fulfil the request.

Example: A REGISTER request might be sent to a user agent.

An Allow field must be present to inform the UAC as to what methods are acceptable.

406 Not Acceptable

This response indicates that the request cannot be processed due to a requirement in the request message.

The Accept header field in the request did not contain any options supported by the UAS.

407 Proxy Authentication Required

This request sent by a proxy indicates that the UAC must first authenticate itself with the proxy before the request can be processed.

The response should contain information about the type of credentials required by the proxy in a Proxy-Authenticate header field.

The request can be resubmitted with the proper credentials in a Proxy-Authorization header field.

408 Request Timeout

This response is sent when an Expires header field is present in an INVITE request and the specified time period has passed.

It could be sent by a forking proxy or a user agent.

The request can be retried at any time by the UAC.

422 Session Timer Interval Too Small

The response is used to reject a request containing a Session-Expires header field.

The minimum allowed interval is indicated in the required Min-SE header field.

The calling party may retry the request without the Session-Expires header field or with a value less than or equal to the specified minimum.

423 Interval Too Brief

The response is returned by a registrar that is rejecting a registration request because the requested expiration time on one or more Contacts is too brief.

The response must contain a Min-Expires header field listing the minimum expiration interval that the registrar will accept.

480 Temporarily Unavailable

This response indicates that the request has reached the correct destination, but the called party is not available for some reason.

The response should contain a Retry-After header indicating when the request may be able to be fulfilled.

481 Dialog/Transaction Does Not Exist

This response indicates that a response referencing an existing call or transaction has been received for which the server has no records or state information.

483 Too Many Hops

This response indicates that the request has been forwarded the maximum number of times as set by the Max-Forwards header in the request.

This is indicated by the receipt of a Max-Forward: 0 header in a request.

486 Busy Here

This indicates the user agent is busy and cannot accept the call.

487 Request Terminated

This response can be sent by a UA that has received a CANCEL request for a pending INVITE request.

A 200 OK is sent to acknowledge the CANCEL, and a 487 is sent to cancel the INVITE transaction.

9.5. Server Failure (5xx)

This class response is used to indicate that the request cannot be processed because of an error with the server. The server failed to fulfil an apparently valid request. The response may contain a Retry-After header field. The request can be tried at other locations because there are no errors indicated in the request. Some of the important server failure responses are discussed below.

500 Server Internal Error

500 indicates that the server has experienced some kind of error that is preventing it from processing the request.

It is one kind of server failure that indicates the client to retry the request again at this server after several seconds.

501 Not Implemented

It indicates that the server is unable to process the request because it is not supported.

This response can be used to decline a request containing an unknown method.

502 Bad Gateway

This response is sent by a proxy that is acting as a gateway to another network.

It indicates some problem in the other network is preventing the request from being processed.

503 Service Unavailable

This response indicates that the requested service is temporarily unavailable at that time.

The request can be retried after a few seconds, or after the expiration of the Retry-After header field.

504 Gateway Timeout

This response comes when the request failed due to a timeout occurred in the other network to which the gateway connects.

It is a server error class response because the call is failing due to a failure of the server in accessing resources outside the SIP network.

505 Version Not Supported

The server denies a request when it comes with a different SIP version number. The denial is indicated in this message.

Currently SIP version 2.0 is the only version implemented.

513 Message Too Large

This response is used by a UAS to indicate that the request size was too large for it to process.

580 Preconditions Failure

This response is used to reject an SDP offer in which required preconditions cannot be met.

9.6. Global Error (6xx)

This response class indicates that the server knows that the request will fail wherever it is tried. As a result, the request should not be sent to other locations.

Only a server having definitive knowledge of the user identified by the Request-URI in every possible instance should send a global error class response. Otherwise, a client error class response should be sent.

A Retry-After header field can be used to indicate when the request might be successful. Some of the important responses are discussed below:

600 Busy Everywhere

This response indicates that the call to the specified Request-URI could be answered in other locations.

603 Decline

This response could indicate the called party is busy, or simply does not want to accept the call.

604 Does Not Exist Anywhere

This response is similar to the 404 Not Found response but indicates that the user in the Request-URI cannot be found anywhere.

This response should only be sent by a server having access to all the information about the user.

606 Not Acceptable

This response indicates that some aspect of the desired session is not acceptable to the UAS, and as a result, the session cannot be established.

The response may contain a Warning header field with a numerical code describing exactly what was not acceptable.

The request can be retried with different media session information.

10. Sécurité SIP

Commentaires