Aller au contenu principal

7. SIP Messages

7 SIP Messages

SIP est un protocole texte qui utilise le jeu de caractères UTF-8 (RFC 2279 [7]).

Un message SIP est soit une requête du client vers le serveur, soit une réponse du serveur vers le client.

Bien que les messages de requête (section 7.1) et de réponse (section 7.2) diffèrent dans les détails du jeu de caractères et de la syntaxe, ils utilisent le format de base de la RFC 2822 [3] (par exemple, SIP permet des champs d'en-tête qui ne sont pas des champs d'en-tête valides selon RFC 2822). Les deux types de messages se composent d'une ligne de départ, d'un ou plusieurs champs d'en-tête, d'une ligne vide indiquant la fin des champs d'en-tête, et d'un corps de message optionnel.

     generic-message  =  start-line
                         *message-header
                         CRLF
                         [ message-body ]
     start-line       =  Request-Line / Status-Line

La ligne de départ, chaque ligne de champ d'en-tête et la ligne vide doivent (MUST) se terminer par une séquence de retour chariot saut de ligne (CRLF). Notez qu'une ligne vide doit être présente même si aucun corps de message n'existe.

À l'exception des différences de jeu de caractères ci-dessus, une grande partie de la syntaxe des messages et des champs d'en-tête SIP est identique à celle de HTTP/1.1. Au lieu de répéter la syntaxe et la sémantique ici, nous utiliserons [HX.Y] pour faire référence à la section X.Y de la spécification HTTP/1.1 actuelle (RFC 2616 [8]).

SIP n'est cependant pas une extension de HTTP.

7.1 Requêtes

Une requête SIP se distingue par une ligne de départ de type Request-Line. La Request-Line contient un nom de méthode, un Request-URI, et la version du protocole séparés par un caractère espace (SP) unique.

La Request-Line se termine par CRLF. Aucun CR ou LF n'est autorisé, sauf la séquence CRLF de fin de ligne. Aucun espace linéaire (LWS) n'est autorisé dans aucun élément.

     Request-Line  =  Method SP Request-URI SP SIP-Version CRLF

  Method : la présente spécification définit six méthodes. REGISTER pour enregistrer des informations de contact, INVITE, ACK et CANCEL pour établir une session, BYE pour terminer une session, et OPTIONS pour interroger les capacités d'un serveur. Les extensions SIP décrites dans les RFC du suivi standard peuvent définir des méthodes supplémentaires.

  Request-URI : le Request-URI est un URI SIP ou SIPS comme décrit à la section 19.1, ou un URI générique (RFC 2396 [5]). Il indique l'utilisateur ou le service auquel cette requête est destinée. Le Request-URI ne doit pas (MUST NOT) contenir d'espaces non échappés ni de caractères de contrôle, et ne doit pas (MUST NOT) être entouré de « < > ».

       Les éléments SIP PEUVENT (MAY) prendre en charge les Request-URI avec un schéma autre que « sip » ou « sips » (par exemple le schéma d'URI « tel » de la RFC 2806 [9]). Les éléments SIP PEUVENT (MAY) utiliser leurs propres moyens pour convertir un URI non-SIP et produire un URI SIP, SIPS ou d'un autre schéma.

  SIP-Version : les messages de requête et de réponse contiennent tous la version SIP utilisée, et suivent [H3.1] (en remplaçant HTTP par SIP et HTTP/1.1 par SIP/2.0) en ce qui concerne l'ordre des versions, les exigences de conformité et la mise à niveau des numéros de version. Pour être conforme, une application envoyant un message SIP DOIT (MUST) inclure une SIP-Version de « SIP/2.0 ». La chaîne SIP-Version n'est pas sensible à la casse, mais les implémentations DOIVENT (MUST) l'envoyer en majuscules.

       Contrairement à HTTP/1.1, SIP traite le numéro de version comme une chaîne littérale. En pratique, cela ne devrait faire aucune différence.

7.2 Réponses

Une réponse SIP se distingue d'une requête par une ligne de départ de type Status-Line. La Status-Line est composée de la version du protocole suivie du Status-Code numérique et de la phrase de raison associée, chaque élément séparé par un caractère SP unique.

Aucun CR ou LF n'est autorisé, sauf la séquence CRLF finale.

  Status-Line  =  SIP-Version SP Status-Code SP Reason-Phrase CRLF

Le Status-Code est un code de résultat entier à trois chiffres indiquant le résultat de la compréhension et de la tentative de satisfaction de la requête. La Reason-Phrase est destinée à donner une brève description textuelle du Status-Code. Le Status-Code est destiné aux machines automatiques, et la Reason-Phrase aux utilisateurs humains. Un client n'a pas besoin d'examiner ou d'afficher la Reason-Phrase.

Cette spécification propose des expressions spécifiques pour les phrases de raison, mais les implémentations PEUVENT (MAY) choisir un autre texte, tel que la langue indiquée par le champ d'en-tête Accept-Language de la requête.

Le premier chiffre du Status-Code définit la classe de la réponse. Les deux derniers chiffres n'ont aucun rôle de classification. Par conséquent, les réponses dont le code d'état est compris entre 100 et 199 sont appelées « réponses 1xx », celles entre 200 et 299 « réponses 2xx », et ainsi de suite. Dans SIP/2.0, six valeurs sont autorisées pour le premier chiffre.

  1xx : Provisional (provisoire) — la requête a été reçue et son traitement se poursuit.

  2xx : Success (succès) — l'action a été reçue, comprise et acceptée.

  3xx : Redirection — des traitements supplémentaires sont nécessaires pour satisfaire la requête.

  4xx : Client Error (erreur client) — la requête contient une syntaxe incorrecte ou ne peut pas être satisfaite par ce serveur.

  5xx : Server Error (erreur serveur) — le serveur a échoué à satisfaire une requête apparemment valide.

  6xx : Global Failure (échec global) — la requête ne peut pas être satisfaite par aucun serveur.

La section 21 définit ces classes et décrit les codes individuels.

7.3 Champs d'en-tête

Les champs d'en-tête SIP sont similaires aux champs d'en-tête HTTP, à la fois dans la syntaxe et la sémantique. En particulier, les champs d'en-tête SIP suivent les définitions de [H4.2] concernant la syntaxe de message-header et les règles de continuation de champ d'en-tête sur plusieurs lignes. Celles-ci sont cependant spécifiées dans HTTP par un espace et un retour à la ligne implicites. Cette spécification adhère à RFC 2234 [10] et utilise uniquement des espaces et retours explicites comme partie intégrante de la grammaire.

[H4.2] spécifie également que plusieurs champs d'en-tête avec le même nom de champ dont les valeurs sont des listes séparées par des virgules peuvent être combinés en un seul champ d'en-tête. Cela s'applique aussi à SIP, mais avec des règles spécifiques différentes en raison de la grammaire différente. Plus précisément, tout en-tête SIP dont la grammaire est de la forme :

  header  =  "header-name" HCOLON header-value *(COMMA header-value)

permet de combiner des champs d'en-tête du même nom dans une liste séparée par des virgules. Le champ d'en-tête Contact permet une liste séparée par des virgules, sauf si la valeur du champ d'en-tête est « * ».

7.3.1 Format de champ d'en-tête

Les champs d'en-tête suivent le format général de l'en-tête donné dans la RFC 2822 [3], section 2.2. Chaque champ d'en-tête se compose d'un nom de champ, suivi d'un deux-points (« : »), et d'une valeur de champ.

  field-name: field-value

La grammaire formelle de message-header spécifiée à la section 25 permet un espace arbitraire de chaque côté des deux-points. Cependant, les implémentations DOIVENT ÉVITER (SHOULD) un espace entre le nom de champ et les deux-points, et utiliser un seul espace (SP) entre les deux-points et la valeur de champ.

  Subject:            lunch
  Subject      :      lunch
  Subject            :lunch
  Subject: lunch

Ainsi, tous les éléments ci-dessus sont valides et équivalents, mais le dernier est le format recommandé.

Les champs d'en-tête peuvent être étendus sur plusieurs lignes en préfixant chaque ligne supplémentaire d'au moins un SP ou d'une tabulation horizontale (HT). Le saut de ligne et l'espace de tête de la ligne suivante sont traités comme un seul caractère SP. Ainsi, ce qui suit est équivalent.

  Subject: I know you're there, pick up the phone and talk to me!
  Subject: I know you're there,
           pick up the phone
           and talk to me!

L'ordre relatif des champs d'en-tête avec des noms de champ différents n'est pas significatif. Cependant, les champs d'en-tête requis pour le traitement par le proxy (Via, Route, Record-Route, Proxy-Require, Max-Forwards, Proxy-Authorization, etc.) sont recommandés (RECOMMENDED) en haut du message pour faciliter l'analyse rapide. L'ordre relatif des lignes de champ d'en-tête avec le même nom de champ est significatif. Plusieurs lignes de champ d'en-tête avec le même nom de champ PEUVENT (MAY) exister dans un message seulement si la valeur de champ complète de ce champ d'en-tête est définie comme une liste séparée par des virgules (c'est-à-dire conformément à la grammaire de la section 7.3). Elles DOIVENT (MUST) pouvoir être combinées en une seule paire « field-name: field-value » sans modifier la sémantique du message, en ajoutant chaque valeur de champ ultérieure à la première séparée par des virgules. L'exception à cette règle concerne les champs d'en-tête WWW-Authenticate, Authorization, Proxy-Authenticate et Proxy-Authorization. Plusieurs lignes de champ d'en-tête avec ces noms PEUVENT (MAY) exister dans un message, mais leur grammaire ne suit pas le format général de la section 7.3, elles ne DOIVENT PAS (MUST NOT) être combinées en une seule ligne de champ d'en-tête.

Les implémentations DOIVENT (MUST) pouvoir traiter plusieurs lignes de champ d'en-tête avec le même nom en toute combinaison des formats à valeur unique par ligne ou à valeurs séparées par des virgules.

Les groupes suivants de lignes de champ d'en-tête sont tous valides et équivalents.

  Route: `&lt;sip:[email protected]>`
  Subject: Lunch
  Route: `&lt;sip:[email protected]>`
  Route: `&lt;sip:[email protected]>`

  Route: `&lt;sip:[email protected]>`, `&lt;sip:[email protected]>`
  Route: `&lt;sip:[email protected]>`
  Subject: Lunch

  Subject: Lunch
  Route: `&lt;sip:[email protected]>`, `&lt;sip:[email protected]>`,
         `&lt;sip:[email protected]>`

Chacun des blocs suivants est valide, mais ils ne sont pas équivalents entre eux.

  Route: `&lt;sip:[email protected]>`
  Route: `&lt;sip:[email protected]>`
  Route: `&lt;sip:[email protected]>`

  Route: `&lt;sip:[email protected]>`
  Route: `&lt;sip:[email protected]>`
  Route: `&lt;sip:[email protected]>`

  Route: `&lt;sip:[email protected]>`,`&lt;sip:[email protected]>`,
         `&lt;sip:[email protected]>`

Le format de la valeur d'un champ d'en-tête est défini par nom de champ d'en-tête. Il est toujours soit une séquence opaque d'octets TEXT-UTF8, soit une combinaison d'espaces, de jetons, de délimiteurs et de chaînes entre guillemets. Beaucoup de champs d'en-tête existants suivent la forme générale où la valeur de champ est suivie d'une suite de paires nom de paramètre et valeur de paramètre séparées par des points-virgules.

     field-name: field-value *(;parameter-name=parameter-value)

Notez qu'à moins qu'un certain nombre de paires de paramètres ne puissent être ajoutées à la valeur d'un champ d'en-tête, un nom de paramètre particulier ne DOIT PAS (MUST NOT) apparaître plusieurs fois.

Lors de la comparaison des champs d'en-tête, le nom de champ n'est jamais sensible à la casse. Sauf indication contraire dans la définition d'un champ d'en-tête particulier, les valeurs de champ, les noms de paramètres et les valeurs de paramètres ne sont pas sensibles à la casse. Les jetons ne sont jamais sensibles à la casse. Sauf indication contraire, les valeurs représentées comme chaînes entre guillemets sont sensibles à la casse. Par exemple,

  Contact: `&lt;sip:[email protected]>`;expires=3600

est équivalent à

  CONTACT: `&lt;sip:[email protected]>`;ExPiReS=3600

et

  Content-Disposition: session;handling=optional

est équivalent à

  content-disposition: Session;HANDLING=OPTIONAL

Les deux en-têtes suivants ne sont pas équivalents.

  Warning: 370 devnull "Choose a bigger pipe"
  Warning: 370 devnull "CHOOSE A BIGGER PIPE"

7.3.2 Classification des champs d'en-tête

Certains champs d'en-tête n'ont de sens que dans une requête ou une réponse. Ceux-ci sont respectivement appelés champs d'en-tête de requête et de réponse. Si un champ d'en-tête apparaît dans un message qui ne correspond pas à sa catégorie (par exemple, un champ d'en-tête de requête dans une réponse), il DOIT (MUST) être ignoré. La section 20 définit la classification de chaque champ d'en-tête.

7.3.3 Forme compacte

SIP fournit un mécanisme pour exprimer les noms de champs d'en-tête communs sous forme abrégée. Cela peut être utile lorsque le message est trop volumineux pour être transporté sur le transport disponible (par exemple, avec UDP, lorsqu'il dépasse l'unité de transmission maximale (MTU)). Ces abréviations sont définies à la section 20. La forme abrégée PEUT (MAY) être remplacée à tout moment par la forme longue du nom de champ d'en-tête sans modifier la sémantique du message. Le nom de champ d'en-tête PEUT (MAY) apparaître à la fois en forme longue et courte dans le même message. Les implémentations DOIVENT (MUST) accepter à la fois la forme longue et la forme courte de chaque nom d'en-tête.

7.4 Corps

Sauf indication contraire, les requêtes PEUVENT (MAY) inclure un corps de message, y compris les nouvelles requêtes définies par les extensions de cette spécification. L'interprétation du corps dépend de la méthode de requête.

Pour les messages de réponse, la méthode de requête et le code d'état de réponse déterminent le type et l'interprétation du corps du message. Toutes les réponses PEUVENT (MAY) inclure un corps.

7.4.1 Type de corps de message

Le type de média Internet du corps de message DOIT (MUST) être donné par le champ d'en-tête Content-Type. Si le corps a subi un codage tel qu'une compression, cela DOIT (MUST) être indiqué par le champ d'en-tête Content-Encoding. Sinon, Content-Encoding DOIT (MUST) être omis. Le jeu de caractères du corps de message, le cas échéant, est indiqué comme partie de la valeur du champ d'en-tête Content-Type.

Les types MIME « multipart » définis dans la RFC 2046 [11] PEUVENT (MAY) être utilisés dans le corps du message. Une implémentation envoyant une requête contenant un corps de message multipart DOIT (MUST), si l'implémentation distante a demandé cela via un champ d'en-tête Accept n'incluant pas multipart, envoyer la description de session comme corps de message non-multipart.

Les messages SIP PEUVENT (MAY) inclure un corps binaire ou une partie de corps. Si l'expéditeur ne fournit pas de paramètre charset explicite, les sous-types de média de type « text » sont définis pour avoir « UTF-8 » comme valeur charset par défaut.

7.4.2 Longueur de corps de message

Longueur du corps (en octets) est fournie par le champ d'en-tête Content-Length. La section 20.14 détaille le contenu requis de ce champ d'en-tête.

Notez que le codage de transfert « chunked » de HTTP/1.1 NE DOIT PAS (MUST NOT) être utilisé avec SIP. (Note : le codage chunked modifie le corps du message pour le transférer comme une série de morceaux, chacun avec son propre indicateur de taille.)

7.5 Encadrement des messages SIP

Contrairement à HTTP, les implémentations SIP peuvent utiliser UDP ou un autre protocole de datagramme non fiable. Chaque datagramme transporte une seule requête ou réponse. Consultez la section 18 pour les contraintes liées à l'utilisation d'un transport non fiable.

Les implémentations traitant les messages SIP sur un transport orienté flux DOIVENT (MUST) ignorer tout CRLF apparaissant avant la ligne de départ [H4.1].

  Pour trouver la fin de chaque message SIP dans le flux, la valeur du champ d'en-tête Content-Length est utilisée. Elle est toujours présente lorsqu'un message SIP est envoyé sur un transport orienté flux.