Architecture SIP

Dans cette section, on trouvera une description du Protocole SIP comme boîte-à-outils. On décrira le concept d’AOR mais aussi on donnera une idée des rôles (UA, proxies, B2BUA), des requêtes (méthodes), des réponses et des messages du protocole SIP. Enfin, on envisagera quelques scénarios classiques à étudier.

1. Protocole SIP

Session Initiation Protocol (SIP) est un protocole TCP/IP de couche application normalisé et standardisé par l’IETF (RFC 3261). Il a été conçu pour établir, modifier et terminer des sessions multimédia. Il prend en charge l’authentification et la localisation de multiples participants. S’il se charge de la négociation des médias, il laisse le soin à d’autres protocoles de transporter du texte, de la voix ou de la vidéo.

SIP fonctionne aussi bien avec IPv4 qu’avec IPv6. SIP est supporté par TCP ou UDP sur le port 5060 par défaut. La version sécurisée SIP-TLS utilise par défaut le port TCP 5061.

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. Plus justement, 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é.

2. La boîte-à-outils SIP

SIP est donc un protocole de l’IETF (il aura la préférence du marché) qui est une véritable boîte-à-outils (primitives SIP) pour établir des communications à travers l’Internet. Ses illustrations les plus immédiates sont celles de la téléphonie IP, de la voix sur IP et puis des systèmes de messageries tels que Skype, WhatsApp, etc. Mais on peut y trouver d’autres cas d’usage où des communications vocales ou vidéos peuvent intervenir dans le cadre de services de support, de fourniture de connectivité ou encore dans l’IoT ou la domotique.

Une expérience SIP pleinement vécue ne se passe pas d’autres protocoles TCP/IP, de logiciels et de leurs librairies qui le mettent en oeuvre. Aussi, SIP n’est plus nécessairement le seul protocole ou l’élément central des solutions commerciales qui nous sont offertes sur le marché.

Figure : Protocoles VoIP

A cet égard, la mise en oeuvre du protocole peut provoquer des difficultés d’interconnexion entre des périphériques non supportés entre eux ; les passerelles Cisco Systems ont la faveur du marché et des opérateurs pour éviter cet écueil. Egalement, on prendra garde de ne pas confondre le message SIP rendu par l’application et l’erreur de l’application qui génère le message d’erreur. Enfin, comme boîte-à-outils, SIP aura notre préférence dans ses implémentations en “open source”.

Comme protocole IETF, SIP est normalisé et standardisé IETF. Le document RFCs SIP reprend les principales RFCs relatives à SIP (il y en a plusieurs centaines) dont voici un exemple de nomenclature :

• 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

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.

En téléchargeant les livres du Guide SIP vous encouragez son auteur !

4. Rôles SIP

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

4.1. User Agents (UA)

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

• UAC : Un Agent Utilisateur Client est tout élément de réseau qui envoie une requête 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 : Un Agent Utilisateur Serveur est une entité logique qui génère une réponse à une requête SIP. La réponse accepte, rejette, ou redirige la requête. Ce rôle ne dure que pendant le temps de cette transaction. En d’autres termes, si un logiciel répond à une requête, il agit comme UAS pour la durée de cette transaction. Si il génère plus tard une requête, il assume le rôle d’un UAC pour le traitement de cette transaction.

4.2. Proxy - serveur mandataire

Serveur Proxy (serveur mandataire) : Entité intermédiaire qui agit à la fois comme un serveur et comme un client pour les besoins de l’élaboration de requêtes 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 requête 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 requête avant de le retransmettre.

Outbound Proxy : Proxy qui reçoit des requêtes 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.

4.3. Serveur de redirection

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

4.4. B2BUA - Back-to-Back User Agent

B2BUA, Back-to-Back User Agent : Un B2BUA est une entité logique entre des UA qui reçoit une requête et la traite comme UAS. Afin de déterminer comment il devrait répondre à la requête, il agit comme un UAC vers l’UAS final et génère lui-même des requêtes. A la différence d’un serveur mandataire (proxy), il maintient l’état du dialogue et doit participer à toutes les requêtes 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.

4.5. 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.

4.6. SBC - Session Border Controller

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.

4.7. Gateways - Passerelles

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 ; serveur qui, en retour, 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 requête envoyée du client au serveur jusqu’à la réponse finale (non-1xx) envoyée du serveur au client. Si la requête 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 requête 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 requête INVITE.

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

• Provisional (1xx): La requête 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 requête.
• Client Error (4xx): La requête comporte une mauvaise syntaxe et ne peut être prise en charge par le serveur.
• Server Error (5xx): Le serveur a échoué remplir une requête apparement valide.
• Global Failure (6xx): La requête ne peut être prise en charge par aucun serveur.

En téléchargeant les livres du Guide SIP vous encouragez son auteur !

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 champ 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 champ 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 veut adresser une nouvelle requête SIP. C’est ce champ qui permettra aux intervenant de communiquer directment entre eux.
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 requêtes SIP sont : To, From, CSeq, Call-ID, Max-Forwards et Via.

7.1. Exemple d’une transaction BYE-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.

8.1. Processus d’enregistrement

Source de l’image

• F1 - demande d’enregistrement initial auprès du SIP User Agent avec ses informations d’adresse (AOR)
• F2 - réponse du SIP Registrar avec les informations sur le login nécessaire
• F3 - nouvelle demande d’enregistrement avec login
• F4 - confirmation de l’enregistrement réussi sur le SIP Registrar

8.2. Flux d’appel SIP entre UA et serveurs de redirection entre proxys et UAs

Source de l’image

8.3. Flux d’appel B2BUA

Source de l’image

En téléchargeant les livres du Guide SIP vous encouragez son auteur !

9. Terminologie SIP

9.1. Transaction SIP

Une transaction se compose d’une demande, de toutes les réponses non définitives (1xx) reçues et d’une réponse finale (2xx, 3xx, 4xx, 5xx ou 6xx), ainsi que des accusés de réception des réponses (ACK ou PRACK), sauf les ACK aux 2xx réponses.

Fondamentalement, une transaction SIP est un seul échange demande / réponse finale complet.

9.2. Dialogue SIP

Un dialogue n’est qu’une série de transactions entre deux pairs SIP.

Le but d’un dialogue est de configurer, éventuellement de modifier, puis de démonter une session. D’où le nom de Session Initiation Protocol.

Comme il peut y avoir de nombreux dialogues en cours entre deux pairs SIP à tout moment (par exemple, il peut y avoir de nombreux appels simultanés en cours entre deux serveurs SIP), les dialogues sont identifiés par les champs From, To et Call-ID dans l’en-tête. Ainsi, si le pair SIP A reçoit deux requêtes BYE en même temps, il peut examiner ces champs pour déterminer à quel dialogue ils appartiennent.

Fondamentalement, les dialogues sont identifiés par les champs From, To et Call-ID des messages SIP.

Parce qu’il peut y avoir plusieurs dialogues en cours à la fois entre deux pairs (par exemple, plusieurs appels en cours entre deux serveurs SIP), des balises (“tags”) servent simplement à identifier à quel dialogue une requête ou réponse particulière appartient.

9.3. Session Média

Une session n’est qu’un flux média (par exemple audio ou vidéo) circulant entre pairs, généralement constitué de paquets RTP (et éventuellement RTCP).

Par exemple, si le protocole SIP est utilisé pour passer un appel vocal, la session est la donnée vocale qui est envoyée entre les terminaux.

Les transactions et dialogues SIP sont nécessaires pour créer des sessions (des flux média entre deux pairs), une “session” étant l’objectif principal du protocole SIP.

9.4. Domaine SIP

Un domaine est un nom de domaine qui identifie les ressources SIP.

Un service DNS robuste est recommandé pour identifier les ressources SIP.

Un domaine est un nom de domaine qui identifie les ressources SIP notamment grâce à un service DNS robuste.