4. Aperçu du fonctionnement (Overview of Operation)
4 Aperçu du fonctionnement (Overview of Operation)
Cette section présente le fonctionnement de base de SIP à l'aide d'un exemple simple. Cette section a un caractère didactique et ne contient aucune phrase normative.
Le premier exemple montre la fonctionnalité de base de SIP : la découverte des points de terminaison, la signalisation de l'intention de communiquer, la négociation des paramètres de session pour établir une session et le démantèlement (teardown) de la session établie.
La Figure 1 montre un échange de messages SIP typique entre deux utilisateurs, Alice et Bob. (Chaque message est étiqueté d'une lettre "F" et d'un nombre pour référence depuis le texte.) Dans cet exemple, Alice utilise une application SIP sur son PC (appelée softphone) pour appeler le téléphone SIP de Bob sur Internet. Deux serveurs proxy SIP qui agissent pour Alice et Bob sont également affichés. Cet arrangement typique est souvent appelé « trapèze SIP (SIP trapezoid) » d'après la forme géométrique en pointillés de la Figure 1.
Alice « appelle » Bob en utilisant son identité SIP, un type d'Uniform Resource Identifier (URI) appelé SIP URI. Un SIP URI est défini à la Section 19.1. Sa forme ressemble à une adresse e-mail et contient généralement un nom d'utilisateur et un nom d'hôte. Dans ce cas, c'est sip:[email protected], où biloxi.com est le domaine du fournisseur de service SIP de Bob. Le SIP URI d'Alice est sip:[email protected]. Alice a peut-être saisi l'URI de Bob ou cliqué sur un lien hypertexte ou un élément de carnet d'adresses. SIP fournit également un URI sécurisé appelé SIPS URI. Un exemple est sips:[email protected]. Un appel vers un SIPS URI garantit que tous les messages SIP du demandeur au domaine de l'appelé sont transportés en utilisant un transport sécurisé et chiffré (c'est-à-dire TLS). À partir de là, la requête est envoyée en toute sécurité à l'appelé, mais le mécanisme de sécurité dépend de la politique du domaine de l'appelé.
SIP est basé sur un modèle de transaction request/response similaire à HTTP. Chaque transaction consiste en une requête invoquant une méthode (ou fonction) particulière sur un serveur, et au moins une réponse. Dans cet exemple, la transaction commence lorsque le softphone d'Alice envoie une requête INVITE vers le SIP URI de Bob. INVITE est un exemple de méthode SIP qui spécifie l'action que le demandeur (Alice) veut que le serveur (Bob) effectue. La requête INVITE (message F1 de la Figure 1) contient plusieurs champs d'en-tête (header fields). Les champs d'en-tête fournissent des attributs nommés donnant des informations supplémentaires sur le message. L'INVITE contient : un identifiant unique d'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 de la Figure 1) ressemble à ceci :
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 1: SIP session setup example with SIP trapezoid
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob `<sip:[email protected]>`
From: Alice `<sip:[email protected]>`;tag=1928301774
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: `<sip:[email protected]>`
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)
La première ligne du message codé en texte contient le nom de la méthode (INVITE). Les lignes suivantes sont la liste des champs d'en-tête. Cet exemple contient le jeu minimal requis. Les champs d'en-tête sont brièvement expliqués ci-dessous.
Via contient l'adresse (pc33.atlanta.com) où Alice s'attend à recevoir la réponse à cette requête. Il contient également un paramètre branch qui identifie cette transaction.
To contient le nom d'affichage (Bob) et l'URI SIP ou SIPS (sip:[email protected]) vers laquelle la requête a été initialement dirigée. Le nom d'affichage est décrit dans la RFC 2822 [3].
From contient également le nom d'affichage (Alice) et l'URI SIP ou SIPS (sip:[email protected]) indiquant l'initiateur de la requête. Ce champ d'en-tête a également un paramètre tag contenant une chaîne aléatoire (1928301774) ajoutée par le softphone à l'URI, utilisée à des fins d'identification.
Call-ID contient un identifiant globalement unique de 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 softphone. La combinaison du To tag, du From tag et du Call-ID définit complètement la relation peer-to-peer SIP entre Alice et Bob, appelée dialog.
CSeq (Command Sequence) contient un entier et le nom de la méthode. Le numéro CSeq est incrémenté pour chaque nouvelle requête dans un dialog, c'est une séquence classique.
Contact contient un URI SIP ou SIPS représentant une route pour atteindre directement Alice, généralement composé d'un nom d'utilisateur sur un nom de domaine pleinement qualifié (FQDN). Le FQDN est recommandé, mais de nombreux systèmes terminaux n'ont pas de nom de domaine enregistré, donc les adresses IP sont aussi autorisées. Le champ d'en-tête Via indique aux autres éléments où envoyer la réponse, alors que le champ d'en-tête Contact indique aux autres éléments où envoyer les requêtes futures.
Max-Forwards limite le nombre de sauts que la requête peut traverser avant d'atteindre sa destination. Il est constitué d'un entier, décrémenté de un à chaque saut.
Content-Type contient la description du corps du message (non illustré ici).
Content-Length contient le nombre d'octets (bytes) du corps du message.
L'ensemble complet des champs d'en-tête SIP est défini à la Section 20.
Les détails du type de session, du codec ou du taux d'échantillonnage ne sont pas décrits en utilisant SIP. Au lieu de cela, le corps d'un message SIP contient une description de session encodée dans un autre format de protocole. Un tel format est le Session Description Protocol (SDP) (RFC 2327 [1]). Ce message SDP (non illustré dans l'exemple) est transporté par le message SIP de la même manière qu'un message e-mail transporte une pièce jointe ou qu'un message HTTP transporte une page web.
Comme le softphone ne connaît ni l'emplacement de Bob ni le serveur SIP dans le domaine biloxi.com, le softphone envoie l'INVITE au serveur SIP qui fournit un service dans le domaine atlanta.com d'Alice. L'adresse du serveur SIP atlanta.com a pu être configurée sur le softphone d'Alice ou découverte via DHCP, par exemple.
Le serveur SIP atlanta.com est un type de serveur SIP appelé proxy server. Un proxy server reçoit les requêtes SIP et les transmet pour le compte du demandeur. Dans cet exemple, le proxy server reçoit la requête INVITE et renvoie une réponse 100 (Trying) au softphone d'Alice. La réponse 100 (Trying) indique que l'INVITE a été reçu et que le proxy le route vers la destination pour le compte d'Alice. Les réponses SIP utilisent un code à trois chiffres suivi d'une phrase. Cette réponse contient le même To, From, Call-ID, CSeq et le paramètre branch dans Via que l'INVITE, afin que le softphone d'Alice puisse associer la réponse à l'INVITE envoyé. Le serveur proxy atlanta.com trouve le proxy server biloxi.com, probablement en effectuant un type particulier de recherche DNS (Domain Name Service) pour trouver le serveur SIP fournissant un service dans le domaine biloxi.com, décrit dans [4]. Il obtient l'adresse IP du proxy server biloxi.com et y transfère (ou proxy) la requête INVITE. Avant de transmettre la requête, le proxy server atlanta.com ajoute une valeur de champ d'en-tête Via supplémentaire contenant sa propre adresse (l'INVITE contenait déjà l'adresse d'Alice dans le premier Via). Le proxy server biloxi.com reçoit l'INVITE et renvoie une réponse 100 (Trying) au proxy server atlanta.com, indiquant qu'il a reçu l'INVITE et le traite. Le proxy server consulte une base de données appelée location service contenant l'adresse IP actuelle de Bob. (La configuration de cette base de données est vue à la section suivante.) Le proxy server biloxi.com ajoute une autre valeur de champ Via contenant sa propre adresse à l'INVITE et le proxy vers le téléphone SIP de Bob.
Le téléphone SIP de Bob reçoit l'INVITE, en informe Bob de l'appel entrant d'Alice et lui permet de décider s'il répond (c'est-à-dire si le téléphone de Bob sonne). Le téléphone SIP de Bob indique cela avec une réponse 180 (Ringing), qui est routée en arrière via les deux proxys. Chaque proxy utilise le champ Via pour déterminer où envoyer la réponse et supprime sa propre adresse du début. Ainsi, bien que la recherche initiale de l'INVITE ait nécessité DNS et des recherches dans le location service, la réponse 180 (Ringing) peut être renvoyée au demandeur sans recherche et sans état sur le proxy. Cela a également la propriété souhaitable que chaque proxy voyant l'INVITE voit également toutes les réponses à cet INVITE.
Lorsque le softphone d'Alice reçoit la réponse 180 (Ringing), il informe Alice, probablement en lisant une tonalité de sonnerie (ringback) ou en affichant un message à l'écran.
Dans cet exemple, Bob décide de répondre. Lorsqu'il décroche, son téléphone SIP envoie une réponse 200 (OK) indiquant que l'appel a été répondu. Le 200 (OK) contient un corps de message avec la description média SDP du type de session que Bob souhaite établir avec Alice. Ainsi, un échange SDP en deux étapes se produit : Alice en envoie un à Bob, et Bob en envoie un à Alice. Cet échange en deux étapes fournit une fonction de négociation de base fondée sur le modèle simple offer/answer de l'échange SDP. Si Bob ne souhaite pas répondre ou est occupé sur un autre appel, une réponse d'erreur est envoyée au lieu du 200 (OK), et la session média n'est pas établie. La liste complète des codes de réponse SIP est dans la Section 21. Le 200 (OK) (message F9 de la Figure 1) envoyé par Bob ressemble à ceci :
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:[email protected]>`;tag=a6c85cf
From: Alice `<sip:[email protected]>`;tag=1928301774
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: `<sip:[email protected]>`
Content-Type: application/sdp
Content-Length: 131
(Bob's SDP not shown)
La première ligne de la réponse contient le code de réponse (200) et la phrase raison (OK). Les lignes restantes contiennent les champs d'en-tête. Les champs Via, To, From, Call-ID et CSeq sont copiés de la requête INVITE. (Il y a trois valeurs de champ Via - une ajoutée par le téléphone SIP d'Alice, une par le proxy atlanta.com, et une par le proxy biloxi.com.) Le téléphone SIP de Bob a ajouté un paramètre tag au champ To. Ce tag est incorporé dans le dialog par les deux extrémités et est inclus dans toutes les requêtes et réponses futures de ce appel. Le champ Contact contient l'URI où le téléphone SIP de Bob peut être directement atteint. Content-Type et Content-Length font référence au corps du message contenant les informations média SDP de Bob (non illustré).
En plus des recherches DNS et location service illustrées dans cet exemple, un proxy server peut prendre des « décisions de routage » flexibles pour déterminer où envoyer une requête. Par exemple, si le téléphone SIP de Bob renvoie une réponse 486 (Busy Here), le proxy server biloxi.com peut proxer l'INVITE vers le serveur de messagerie vocale (voicemail) de Bob. Un proxy peut également envoyer l'INVITE à plusieurs endroits simultanément. Ce type de recherche parallèle est appelé forking.
Dans ce cas, le 200 (OK) est routé en arrière via les deux proxys et reçu par le softphone d'Alice, qui arrête la sonnerie pour indiquer que l'appel a été répondu. Enfin, le softphone d'Alice envoie un message de confirmation ACK au téléphone SIP de Bob pour accuser réception de la réponse finale (200 (OK)). Dans cet exemple, l'ACK contourne les deux proxys et est envoyé directement du softphone d'Alice au téléphone SIP de Bob, car les extrémités ont appris mutuellement leurs adresses via le champ Contact dans l'échange INVITE/200 (OK), ce qui n'était pas connu lors de l'envoi de l'INVITE initiale. Les recherches effectuées par les deux proxys ne sont plus nécessaires, donc les proxys quittent le flux d'appel. Cela complète la poignée de main à trois voies INVITE/200/ACK utilisée pour établir une session SIP. Les détails complets de l'établissement de session sont dans la Section 13.
La session média d'Alice et Bob commence et ils envoient des paquets média en utilisant le format convenu dans l'échange SDP. Généralement, les paquets média de bout en bout prennent un chemin différent de celui des messages de signalisation SIP.
Pendant la session, l'un d'Alice ou Bob peut décider de modifier les caractéristiques de la session média. Cela se fait en envoyant un re-INVITE contenant une nouvelle description média. Comme le re-INVITE fait référence à un dialog existant, l'autre partie sait qu'il s'agit de modifier une session existante plutôt que d'en établir une nouvelle. 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 telle que 488 (Not Acceptable Here), qui reçoit aussi un ACK ; mais l'échec du re-INVITE n'entraîne pas l'échec de l'appel existant - la session continue avec les caractéristiques précédemment négociées. Les détails complets de la modification de session sont dans la Section 14.
À la fin de l'appel, Bob raccroche en premier, générant un message BYE. Ce BYE contourne également les proxys et est routé directement au softphone d'Alice. Alice confirme la réception du BYE avec une réponse 200 (OK), terminant ainsi 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. Cette gestion spéciale de l'INVITE est expliquée plus tard, mais elle est liée au mécanisme de fiabilité de SIP, au temps que met un téléphone pour répondre et au forking. Par conséquent, le traitement des requêtes SIP est souvent classé comme INVITE ou non-INVITE (faisant référence à toutes les méthodes autres qu'INVITE). Les détails complets de la fin de session sont dans la Section 15.
La Section 24.2 décrit entièrement les messages de la Figure 1.
Dans certains cas, il est utile qu'un proxy sur le chemin de signalisation SIP puisse voir tous les messages entre les extrémités pendant la session. Par exemple, si le proxy server biloxi.com souhaite rester sur le chemin de signalisation SIP après l'INVITE initial, il ajoute un champ d'en-tête de routage obligatoire appelé Record-Route contenant un URI résolu en son nom d'hôte ou son adresse IP. Ces informations sont reçues par le téléphone SIP de Bob et (puisque le Record-Route est renvoyé dans le 200 (OK)) par le softphone d'Alice, et conservées pendant la durée du dialog. Le proxy server biloxi.com reçoit ensuite et proxye l'ACK, le BYE et le 200 (OK) au BYE. Chaque proxy décide indépendamment de recevoir les messages suivants, et ceux-ci passent par tous les proxys qui ont choisi de les recevoir. Cette fonctionnalité est souvent utilisée pour les proxys fournissant des fonctions d'appel en cours.
L'enregistrement (registration) est une autre opération courante de SIP. L'enregistrement est l'une des façons dont le serveur biloxi.com connaît l'emplacement actuel de Bob. Lors de l'initialisation et à intervalles réguliers, le téléphone SIP de Bob envoie un message REGISTER au registrar dans le domaine biloxi.com. Le message REGISTER associe le SIP ou SIPS URI de Bob (sip:[email protected]) à la machine sur laquelle il est actuellement connecté (communiquée en tant qu'URI SIP ou SIPS dans le champ Contact). Le registrar écrit cette association (également appelée binding) dans une base de données appelée location service, utilisable par le proxy dans le domaine biloxi.com. Souvent, le serveur registrar d'un domaine est colocalisé avec son proxy. Il est important de comprendre que la distinction entre les serveurs SIP est logique et non physique.
Bob n'est pas limité à un enregistrement depuis un seul appareil. Par exemple, son téléphone SIP domestique et son téléphone SIP de bureau peuvent tous deux envoyer des enregistrements. Ces informations sont stockées ensemble dans le location service, permettant au proxy d'effectuer divers types de recherches pour trouver Bob. De même, plusieurs utilisateurs peuvent être enregistrés simultanément sur un seul appareil.
Le location service est une abstraction. Il contient généralement des informations permettant à un proxy, en entrant un URI, de recevoir un ensemble de zéro ou plusieurs URI indiquant où envoyer la requête. L'enregistrement est une façon de créer ces informations, mais pas la seule. N'importe quelle fonction de mappage peut être configurée à la discrétion de l'administrateur.
Enfin, il est important de noter que dans SIP, l'enregistrement est utilisé pour le routage des requêtes SIP entrantes et n'a aucun rôle dans l'autorisation des requêtes sortantes. L'autorisation et l'authentification sont gérées dans SIP par un mécanisme de défi/réponse (challenge/response) par requête, ou en utilisant des schémas de couche inférieure décrits dans la Section 26.
Les détails complets des messages SIP pour cet exemple d'enregistrement sont dans la Section 24.1.
D'autres opérations SIP, telles que l'interrogation des capacités d'un serveur ou client SIP avec OPTIONS, ou l'annulation d'une requête en attente avec CANCEL, sont présentées dans les sections suivantes.