Architecture SIP

1. RFCs SIP

Le document RFCs SIP reprend les principales RFCs relatives à SIP (plusieurs centaines) :

  • Core SIP Documents
  • SDP-Related Documents
  • RTP-Related Documents
  • HTTP-Related Documents
  • MIME-Related Documents
  • SIP Standards Track Documents (Options, Extensions, etc.)
  • SIP Informational RFCs and BCP Documents
  • SIP-Related Documents
  • Directory Services Documents

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

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.

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, il agit comme UAS pour la durée de cette transaction. Si il génère plus tard une demande, il assume le rôle d’un UAC pour le traitement de cette transaction.

Proxy

Serveur Proxy (mandataire) : 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, de routage, 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 cela est 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 (Redirection) 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 aucune 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 controller) 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 ou encore 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.

5. Requêtes (Méthodes) 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)

6. Réponses (Status Codes) SIP

Les réponses SIP sont présentées dans la page 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.

{% hint style='danger' %}

Un dialogue est identifié par un identifiant d’appel, une étiquette locale, et une étiquette distante.

{% endhint %}

  • Provisional (1xx): La demande est reçue et est en cours de traitement.
  • Success (2xx): L'action a été reçue, comprise et acceptée avec succès.
  • Redirection (3xx): Une action supplémentaire doit être prise (par l'appelant) pour compléter la demande.
  • Client Error (4xx): La demande comporte une mauvaise syntaxe et ne peut être prise en charge par le serveur.
  • Server Error (5xx): Le serveur a échoué remplir une demande apparement valide.
  • Global Failure (6xx): La demande ne peut être prise en charge par aucun serveur.

7. Messages SIP

Un message SIP est composé des éléments suivants :

  1. Une ligne de départ (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) peuvent être, entre autres :

  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 d'un même dialogue.

  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 paramè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.

Les champs d’en-tête obligatoires dans toutes les demandes SIP sont : To, From, CSeq, Call-ID, Max-Forwards et Via.

Exemple d'une transaction BYE-200

Message Structure
Méthodes Nom de la méthode + URI du destinataire + Version SIP BYE sip:201@10.33.6.101:5060 SIP/2.0
Réponses Version SIP + Status Code + Raison SIP/2.0 200 OK

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

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

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.

Commentaires