Aperçu des opérations SIP

Source : RFC 3261, “4 Overview of Operation”, traduit par http://abcdrfc.free.fr/rfc-vf/rfc3261.html et retravaillé par les soins de l’auteur.

Le premier exemple montre les fonctions de base de SIP :

• localisation d’un point de terminaison,
• signal d’une volonté de communiquer,
• négociation des paramètres de session pour établir la session,
• et suppression de la session une fois établie.

1. Présentation du dialogue

La figure suivante montre un exemple typique d’échange de messages SIP entre deux utilisateurs, Alice et Bob. (Chaque message est étiqueté avec la lettre “F” et un numéro pour référence par le texte.) Dans cet exemple, Alice utilise une application SIP sur son ordinateur (auquel on se réfère comme téléphone logiciel) pour appeler Bob sur son téléphone SIP dans l’Internet. Deux serveurs mandataires SIP sont également montrés, qui agissent au nom d’Alice et de Bob pour faciliter l’établissement de la session. Cet arrangement typique est souvent désigné sous le nom “trapézoïde de SIP” comme le montre la forme géométrique de lignes pointillées dans la figure suivante.

                     atlanta.com  . . . biloxi.com
                 .      proxy              proxy     .
               .                                       .
       Alice's  . . . . . . . . . . . . . . . . . . . .  Bob's
      softphone                                        SIP Phone
         |                |                |                |
         |    INVITE F1   |                |                |
         |--------------->|    INVITE F2   |                |
         |  100 Trying F3 |--------------->|    INVITE F4   |
         |<---------------|  100 Trying F5 |--------------->|
         |                |<-------------- | 180 Ringing F6 |
         |                | 180 Ringing F7 |<---------------|
         | 180 Ringing F8 |<---------------|     200 OK F9  |
         |<---------------|    200 OK F10  |<---------------|
         |    200 OK F11  |<---------------|                |
         |<---------------|                |                |
         |                       ACK F12                    |
         |------------------------------------------------->|
         |                   Media Session                  |
         |<================================================>|
         |                       BYE F13                    |
         |<-------------------------------------------------|
         |                     200 OK F14                   |
         |------------------------------------------------->|
         |                                                  |

Figure : Exemple d’établissement de session SIP avec le trapézoïde SIP

Alice “appelle” Bob en utilisant son identité SIP, un type d’”identifiant de ressource universel” (URI, Uniform Resource Identifier) appelé un URI SIP. Ils ont une forme similaire à celle d’une adresse de messagerie électronique, contenant normalement un nom d’utilisateur et un nom d’hôte. Dans ce cas, c’est sip:bob@biloxi.com, où biloxi.com est le domaine du fournisseur de service SIP de Bob. Alice possède un URI SIP qui est sip:alice@atlanta.com. Alice pourrait avoir tapé l’URI de Bob ou elle aurait peut être “cliqué” sur un lien hypertexte ou sur une entrée dans un carnet d’adresses. SIP fournit aussi des URI sécurisés, appelés URI SIPS. Ce serait par exemple sips:bob@biloxi.com. Un appel fait à un URI SIPS garantit qu’un transport sécurisé, chiffré (à savoir TLS) est utilisé pour porter tous les messages SIP de l’appelant au domaine de l’appelé. La requête est donc envoyée en toute sécurité à l’appelé mais avec des mécanismes de sécurité qui dépendent de la politique du domaine de l’appelé.

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

2. Invitation initiale

SIP se fonde sur un modèle de transaction de requête/réponse du style HTTP. Chaque transaction consiste en une requête qui implique une méthode ou fonction particulière sur le serveur, et au moins une réponse. Dans cet exemple, une transaction débute avec l’envoi par le téléphone logiciel d’Alice d’une requête INVITE adressée à l’URI SIP de Bob. INVITE est un exemple de méthode SIP qui spécifie l’action que le demandeur (Alice) veut que fasse le serveur (Bob). La requête INVITE contient un certain nombre de champs d’en-tête. Les champs d’en-tête sont des attributs désignés qui fournissent des informations supplémentaires sur un message. Ceux qui sont présents dans un INVITE incluent un identifiant unique pour l’appel, l’adresse de destination, l’adresse d’Alice, et des informations sur le type de session qu’Alice souhaite établir avec Bob. L’INVITE (message F1 dans la figure) pourrait ressembler à :

INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
...

Le SDP d’Alice n’est pas affiché dans la sortie du message.

La première ligne du message en texte codé contient le nom de la méthode (INVITE). Les lignes qui suivent sont une liste de champs d’en-tête. Cet exemple contient l’ensemble minimum requis. Les champs d’en-tête sont brièvement décrits ci-dessous :

• Via contient l’adresse pc33.atlanta.com à laquelle Alice s’attend à recevoir des réponses à cette requête. Il contient aussi un paramètre de branche qui identifie cette transaction.
• To (à) contient un nom d’affichage (Bob) et un URI SIP ou SIPS (sip:bob@biloxi.com) sur lequel la requête a été dirigée à l’origine. Les noms d’affichage sont décrit dans la RFC 2822 rendu obsolète par le RFC 5322.
• From (de) contient aussi un nom d’affichage (Alice) et un URI SIP ou SIPS (sip:alice@atlanta.com) qui indique la personne à l’origine de la requête. Ce champ d’en-tête a aussi un paramètre d’étiquette contenant une chaîne aléatoire (1928301774) qui a été ajoutée à l’URI par le téléphone logiciel. Elle sert pour des besoins d’identification.
• Call-ID (identifiant d’appel) contient un identifiant unique au monde pour cet appel, généré par la combinaison d’une chaîne aléatoire et du nom d’hôte ou de l’adresse IP du téléphone logiciel. La combinaison du champ To, du champ From, et du Call-ID (identifiant d’appel) définit de façon complète une relation SIP d’homologue à homologue entre Alice et Bob. On appelle un dialogue.
• CSeq ou Command Sequence (séquence de commande) contient un entier et un nom de méthode. Le nombre CSeq est incrémenté pour chaque nouvelle requête d’un dialogue et c’est un numéro de séquence traditionnel.
• Contact contient un URI SIP ou SIPS qui représente une route directe pour contacter Alice, habituellement composé d’un nom d’utilisateur sur un nom de domaine pleinement qualifié (FQDN, fully qualified domain name). Alors qu’un FQDN est préféré, de nombreux systèmes d’extrémité n’ont pas de noms de domaine enregistrés, de sorte que les adresses IP sont permises. Alors que le champ d’en-tête Via indique les autres éléments sur le lieu où envoyer la réponse, le champ d’en-tête Contact indique d’autres éléments sur où envoyer des requêtes futures.
• Max-Forwards (retransmissions maximales) sert à limiter le nombre de sauts que peut faire une requête sur son chemin vers sa destination. Il consiste en un entier qui est désincrémenté d’un à chaque saut.
• Content-Type (type de contenu) contient une description du corps de message (non montré).
• Content-Length (longueur du contenu) contient un compte d’octets du corps de message.

Les détails de la session, comme le type de support, codec ou débit d’échantillonnage ne sont pas décrits à l’aide de SIP. Le corps d’une message SIP contient plutôt une description de la session, codée dans un autre format de protocole. Un de ces formats est le protocole de description de session (SDP, Session Description Protocol) (RFC 4566). Ce message SDP (non montré dans l’exemple) est porté par le message SIP d’une façon analogue à celle dont un document joint est porté par un message électronique, ou dont une page web est portée par un message HTTP. Il est habituellement placé dans un INVITE initial et dans la réponse 200 OK attendue.

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

3. Routage de la requête

Comme le téléphone logiciel ne connaît pas la localisation de Bob ou le serveur SIP dans le domaine biloxi.com, le téléphone logiciel envoie l’INVITE au serveur SIP qui dessert le domaine d’Alice, atlanta.com. L’adresse du serveur SIP atlanta.com pourrait avoir été configurée dans le téléphone logiciel d’Alice, ou elle aurait pu être découverte par DHCP par exemple.

Le serveur SIP atlanta.com est un type de serveur SIP connu sous le nom de serveur mandataire (proxy). Un serveur mandataire reçoit des requêtes SIP et les transmet au nom du demandeur. Dans cet exemple, le serveur mandataire reçoit la requête INVITE et renvoie une réponse 100 (Trying) au téléphone logiciel d’Alice. La réponse 100 (Trying) indique que l’INVITE a été reçu et que le mandataire travaille en son nom pour acheminer l’INVITE à la destination. Les réponses de SIP utilisent un code à trois chiffres suivi par une phrase descriptive. Cette réponse contient les mêmes paramètres To, From, Call-ID, CSeq et branch dans le Via que dans l’INVITE, ce qui permet au téléphone logiciel d’Alice de corréler cette réponse avec l’INVITE envoyé. Le serveur mandataire atlanta.com localise le serveur mandataire à biloxi.com, éventuellement en effectuant un type particulier de recherche de DNS (service de nom de domaine) pour trouver le serveur SIP qui dessert le domaine biloxi.com. En résultat, il obtient l’adresse IP du serveur mandataire biloxi.com et lui transmet ou mandate la requête INVITE. Avant de transmettre la requête, le serveur mandataire atlanta.com ajoute une valeur de champ d’en-tête Via supplémentaire qui contient sa propre adresse (l’INVITE contient déjà l’adresse d’Alice dans le premier Via). Le serveur mandataire biloxi.com reçoit l’INVITE et répond par une réponse 100 (Trying) au serveur mandataire atlanta.com pour indiquer qu’il a reçu l’INVITE et traite la requête. Le serveur mandataire consulte une base de données, appelée de façon générique un service de localisation, qui contient l’adresse IP courante de Bob. (Nous verrons dans la prochaine section comment on peut remplir cette base de données.) Le serveur mandataire biloxi.com ajoute une autre valeur de champ d’en-tête Via avec sa propre adresse pour l’INVITE et l’envoie par procuration au téléphone SIP de Bob.

4. Réception de la requête

Le téléphone SIP de Bob reçoit l’INVITE et alerte Bob de l’appel entrant provenant d’Alice, de sorte que Bob peut décider s’il va répondre à l’appel, c’est à dire, le téléphone de Bob sonne. Le téléphone SIP de Bob indique cela dans une réponse 180 (Sonnerie), qui est acheminée en retour aux deux mandataires dans les directions opposées. Chaque mandataire utilise le champ d’en-tête Via pour déterminer où il faut envoyer la réponse et retire sa propre adresse du haut. En résultat, bien que les examens DNS et de service de localisation soient nécessaires pour acheminer l’INVITE initiale, la réponse 180 (Sonnerie) peut être retournée à l’appelant sans boucles ou sans que des états soient maintenus dans les mandataires. Cela a aussi la propriété avantageuse que chaque mandataire qui voit l’INVITE va aussi voir toutes les réponses à l’INVITE.

Lorsque le téléphone logiciel d’Alice reçoit la réponse 180 ("Sonnerie"), il passe cette information à Alice, peut-être en utilisant une tonalité de retour d’appel audio ou en affichant un message sur l’écran d’Alice.

5. Routage de la réponse

Dans cet exemple, Bob décide de répondre à l’appel. Lorsqu’il décroche le combiné, son téléphone SIP envoie une réponse 200 (OK) pour indiquer que l’appel a reçu une réponse. Le message de réponse 200 (OK) contient un corps de message avec la description SDP du type de session que Bob veut établir avec Alice. En résultat, il y a un échange de messages SDP en deux phases : Alice en envoie un à Bob, et Bob en renvoie un à Alice. Cet échange en deux phases donne une capacité de négociation de base et il est fondé sur un modèle simple d’offre/réponse d’échange SDP. Si Bob ne souhaite pas répondre à l’appel ou qu’il est occupé sur une autre ligne, une réponse d’erreur aurait été envoyée à la place du 200 (OK), et il en aurait résulté qu’aucune session de support n’aurait été établie. La liste complète des codes de réponse SIP figure à la page Réponses SIP. Le message 200 (OK) (message F9 dans la Figure 1) pourrait ressembler à cela car Bob a envoyé :

SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bKnashds8;received=192.0.2.3
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds ;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:bob@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131
...

Le SDP de Bob n’est pas montré dans cette sortie.

La première ligne de la réponse contient le code de réponse (200) et la phrase de cause (OK). Les lignes restantes contiennent des champs d’en-tête. Les champs d’en-tête Via, To, From, Call-ID, et CSeq sont copiés de la requête INVITE. (Il y a trois valeurs de champ d’en-tête Via - une ajoutée par le téléphone SIP d’Alice, une ajoutée par le mandataire atlanta.com, et une ajoutée par le mandataire biloxi.com.) Le téléphone SIP de Bob a ajouté un paramètre d’étiquette au champ d’en-tête. Cette étiquette sera incorporée dans le dialogue par les deux points d’extrémité et sera incluse dans toutes les futures requêtes et réponses de cet appel. Le champ d’en-tête Contact contient un URI auquel Bob peut être atteint directement sur son téléphone SIP. Le Content-Type (type de contenu) et Content-Length (longueur du contenu) se réfèrent au corps de message (non montré) qui contient les informations de support SDP de Bob.

En plus de l’examen de DNS et de service de localisation montré dans cet exemple, les serveurs mandataires peuvent prendre des “décisions d’acheminement” souples pour décider d’envoyer une requête. Par exemple, si le téléphone SIP de Bob a retourné une réponse 486 (BUSY HERE), le serveur mandataire biloxi.com pourrait mandater l’INVITE au serveur de messagerie vocale de Bob. Un serveur mandataire peut aussi envoyer un INVITE à un certain nombre de localisations en même temps. Ce type de recherche parallèle est connu sous le nom de fourchage (forking).

Dans ce cas, le 200 (OK) est ré-acheminé à travers les deux mandataires et est reçu par le téléphone logiciel d’Alice, qui arrête alors la tonalité de retour d’appel et indique que l’appel a reçu une réponse.

6. Accusé de réception en livraison directe

Finalement, le téléphone logiciel d’Alice envoie un message d’accusé de réception, ACK, au téléphone SIP de Bob pour confirmer la réception de la réponse finale (200 (OK)). Dans cet exemple, le ACK est envoyé directement du téléphone logiciel d’Alice au téléphone SIP de Bob, outrepassant les deux mandataires. Ceci est possible parce que les points d’extrémité ont appris leurs adresses respectives d’après les champs d’en-tête Contact à travers l’échange INVITE/200 (OK), qui n’étaient pas connues lorsque l’INVITE initial a été envoyé. Les examens effectués par les deux mandataires ne sont plus nécessaires, de sorte que les mandataires abandonnent le flux d’appel. Cela termine la prise de contact à trois INVITE/200 OK/ACK utilisée pour établir les sessions SIP.

7. Établissement de la session

La session media d’Alice et Bob a maintenant commencé, et ils envoient des paquets vocaux/vidéo en utilisant le format sur lequel ils se sont mis d’accord dans l’échange de SDP. En général, ces paquets de bout en bout prennent un chemin différent de celui des messages de signalisation SIP.

8. Renégociation des paramètres de la session

Durant la session, Alice ou Bob peut décider de changer les caractéristiques de la session média. Cela est possible en envoyant un re-INVITE contenant une nouvelle description de support. Ce re-INVITE fait référence au dialogue existant de sorte que l’autre partie sait que c’est pour modifier une session existante et non pour établir un nouvelle session. L’autre partie envoie un 200 (OK) pour accepter le changement. Le demandeur répond au 200 (OK) par un ACK. Si l’autre partie n’accepte pas le changement, elle envoie une réponse d’erreur comme 488 (Not Acceptable Here), qui reçoit aussi un ACK. Cependant, l’échec du re-INVITE ne cause pas de défaillance de l’appel existant - la session continue en utilisant les caractéristiques précédemment négociées.

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

9. Fin de la session

A la fin de l’appel, Bob déconnecte (raccroche) d’abord et génère un message BYE. Ce BYE est acheminé directement au téléphone logiciel d’Alice, outrepassant à nouveau les mandataires. Alice confirme la réception du BYE par une réponse 200 (OK), qui termine la session et la transaction BYE. Aucun ACK n’est envoyé - un ACK n’est envoyé qu’en réponse à une réponse à une requête INVITE. Les raisons de ce traitement spécial pour INVITE seront exposées plus loin mais se rapportent à des mécanismes de fiabilité dans SIP, à la durée qu’il faut pour répondre à un téléphone qui sonne et au fourchage. Pour cette raison, le traitement de la requête dans SIP est souvent classé comme INVITE ou non-INVITE, se référant à toutes les autres à côté de INVITE.