5. Structure du protocole (Structure of the Protocol)
5 Structure du protocole (Structure of the Protocol)
SIP est structuré comme un protocole en couches (layered protocol). Cela signifie que son fonctionnement est décrit comme un ensemble de traitements assez indépendants, avec des couplages lâches entre les étapes. La description du protocole en couches est une commodité de présentation, permettant de décrire les fonctionnalités communes dans une seule section à travers les éléments. Cela ne prescrit en rien l'implémentation. Le fait qu'un élément « contienne » une couche signifie qu'il est conforme à l'ensemble des règles définies dans cette couche.
Tous les éléments spécifiés par le protocole ne contiennent pas toutes les couches. De plus, les éléments spécifiés par SIP sont des éléments logiques, et non physiques. Une réalisation physique peut choisir de combiner différents éléments logiques, peut-être même choisis par transaction.
La couche la plus basse de SIP est sa syntaxe et son encodage. Son encodage est spécifié en utilisant une grammaire étendue Backus-Naur Form (BNF). Le BNF complet est spécifié à la Section 25. Un aperçu de la structure des messages SIP est dans la Section 7.
La deuxième couche est la couche de transport (transport layer). Elle définit comment un client envoie une requête et reçoit une réponse, et comment un serveur reçoit une requête et envoie une réponse sur le réseau. Tous les éléments SIP contiennent la couche de transport. La couche de transport est décrite à la Section 18.
La troisième couche est la couche de transaction (transaction layer). Une transaction est le bloc de construction fondamental de SIP. Une transaction consiste en une requête envoyée du client transaction (utilisant la couche de transport) au server transaction, et de toutes les réponses à cette requête envoyées du server au client. La couche de transaction gère les retransmissions au niveau de l'application, la correspondance des réponses aux requêtes et les expirations au niveau de l'application. Toute tâche accomplie par un user agent client (UAC) est effectuée en utilisant une série de transactions. La discussion sur les transactions se trouve à la Section 17. Un user agent contient la couche de transaction, tout comme un proxy avec état (stateful proxy). Un proxy sans état (stateless proxy) ne contient pas la couche de transaction. La couche de transaction a un composant client (appelé client transaction) et un composant serveur (appelé server transaction), chacun exprimé comme une machine à états finie (finite state machine) construite pour gérer une requête particulière.
La couche au-dessus de la couche de transaction est appelée transaction user (TU). Chaque entité SIP, à l'exception du proxy sans état, est un transaction user. Lorsqu'un TU souhaite envoyer une requête, il crée une instance de client transaction et lui passe la requête, ainsi que l'adresse IP, le port et le transport de destination vers lesquels l'envoyer. Le TU qui a créé la client transaction peut aussi l'annuler. Lorsqu'un client annule une transaction, il demande au serveur de cesser tout traitement supplémentaire et de revenir à l'état d'avant le démarrage de la transaction, en générant une réponse d'erreur particulière pour cette transaction. Cela se fait par une requête CANCEL, qui constitue elle-même une transaction, mais fait référence à la transaction annulée (Section 9).
Les éléments SIP, à savoir les user agent client et server, les proxy stateless et stateful, et les registrar, contiennent un core qui les distingue. À l'exception du proxy sans état, le core est un transaction user. Les règles du core pour le UAC et le UAS dépendent de la méthode, mais il y a quelques règles communes à toutes les méthodes (Section 8). Pour le UAC, ces règles régissent la construction des requêtes. Pour le UAS, elles régissent le traitement des requêtes et la génération des réponses. L'enregistrement jouant un rôle important dans SIP, le UAS qui traite REGISTER reçoit un nom spécial, registrar. La Section 10 décrit le comportement du core UAC et UAS de la méthode REGISTER. La Section 11 décrit le comportement du core UAC et UAS de la méthode OPTIONS, utilisée pour déterminer les capacités d'un UA.
Certaines autres requêtes sont envoyées dans un dialog. Un dialog est une relation SIP peer-to-peer entre deux user agents qui persiste pendant un certain temps. Un dialog facilite l'ordonnancement des messages et le routage approprié des requêtes entre user agents. La méthode INVITE est la seule définie dans cette spécification pour établir un dialog. Lorsqu'un UAC envoie une requête dans le contexte d'un dialog, il suit les règles communes UAC discutées à la Section 8, ainsi que les règles pour les requêtes dans un dialog. La Section 12 discute les dialogs, présentant leurs procédures de construction et de maintenance, ainsi que la construction de requêtes dans un dialog.
La méthode SIP la plus importante est INVITE, utilisée pour établir une session entre les participants. Une session est un ensemble de participants et de flux médias entre eux, dans le but de communiquer. La Section 13 discute comment une session démarre et devient un ou plusieurs dialog SIP. La Section 14 discute comment les caractéristiques de cette session sont modifiées via l'utilisation de requêtes INVITE dans un dialog. Enfin, la Section 15 discute comment une session se termine.
Les procédures des Sections 8, 10, 11, 12, 13, 14 et 15 traitent uniquement du core UA (la Section 9 décrit l'annulation, applicable au core UA et proxy). La Section 16 discute l'élément proxy, qui facilite le routage des messages entre user agents.