Précédent Sommaire Suivant
Les différents champs d'en-tête qu'utilise SIP ne nécessitent pas d'ordre particulier sauf dans le cas de l'en-tête général Via où l'ordre des champs d'en-tête importe. En particulier, l'on distingue les champs d'en-têtes des message transmis saut par saut(c'est-à-dire qui sont interprétés et peuvent être modifiés ou ajoutés par tous les serveurs qu'ils traversent) des en-têtes des messages transmis de bout en bout(interprétés par les émetteurs et destinataires uniquement et non modifiables par les serveurs traversés). Les champs d'en-tête saut par saut doivent apparaître avant les champs d'en-tête de bout en bout. Les PS ne doivent pas réordonner les champs d'en-tête mais peuvent ajouter éventuellement des champs Via ou autres champs de type "saut par saut".
Chaque méthode (ACK, BYE, CANCEL, INVITE, OPTIONS, REGISTER) requière, ne supporte pas ou supporte de façon optionnelle certains champs d'en-tête. Parexemple, les champs d'en-tête CALL-ID, Cseq, FROM, TO et Via sont requis par toutes les méthodes(dans le cas de la méthode OPTIONS, il faut ajouter en plus le champ d'en-tête Allow ). Ces champs d'en-tête sont de type "de bout en bout".
Nous avons vu qu'il existait 4 types de champs d'en-tête:
En-tête général = Accept ou Accept-Encoding ou Accept-Language ou CALL-ID ou Contact ou Cseq ou Date ou Encryption ou Expires ou From ou Record-Route ou Timestamp ou To ou Via
En-tête d’entité = Content-Encoding ou Content-Lenght ou Content-Type
En-tête de requête = Authorization ou Contact ou Hide ou Max-Forwards ou Organization ou Priority ou Proxy-Authorization ou Proxy-Require ou Route ou Require ou Response-Key ou Subject ou User-Agent
En-tête de réponse = Allow ou Proxy-Authorization ou Retry-After ou Server ou Unsupported ou Warning ou WWW-Authenticate
Le champ d'en-tête général s'applique à la fois aux messages de requête et de réponse. Le champ d'en-tête d'entité définit le type d'informations contenues dans le Corps du message ou la ressource identifiée par la requête en l'absence du Corps du message. Le champ d'en-tête de requête autorise le client à ajouter des informations concernant sa requête et lui même à destination du serveur. Le champ d'en-tête de réponse autorise le serveur à ajouter des informations concernant sa réponse, qui ne peuvent pas être placées dans la ligne d'état, sur lui même et sur l'accès à la ressource identifiée par la requête URI. Décrivons les 36 noms d'en-têtes, par ordre alphabétique:
|
Accept Accept-Encoding Accept- Language Allow Authorization Call-ID Contact Content-Encoding Content-Length Content-Type Cseq Date |
Encryption Expires From Hide Max-Forwards Organization Priority Proxy-Authenticate Proxy-Authorization Proxy-Require Record-Route Require |
Response-Key Retry-After Route Server Subject Timestamp To Unsupported User-Agent Via Warning WWW-Authenticate |
Accept = Champ utilisé dans les messages INVITE, OPTIONS et REGISTER qui permet d'indiquer les types de média qui seront acceptés dans la réponse à ce message. Si aucun champ ACCEPT n'apparaît, le serveur utilisera un protocole d'application par défaut (par exemple SDP).
Accept-Encoding = ce champ conditionne la réponse car il détermine quels codages text-based y seront acceptés.
Accept-Language = Il permet au client d’indiquer au serveur quel langage à utiliser dans le corps du message de la réponse au client.
Allow : champ indique les méthodes valides supportées par les entités identifiées par la requête URI.
Authorization : Champ optionnel à inclure par l'utilisateur souhaitant s'authentifier vis à vis du serveur auquel il est relié. C’est le cas après réception d’une réponse de code 401.
Call-ID : identifie une invitation précise ou tous les enregistrements d’un client particulier. Notons qu’une simple conférence multimédia peut donner lieu à plusieurs appels avec différents Call-ID.
Contact : Champ pouvant apparaître dans les requêtes INVITE, ACK et REGISTER ou dans les réponses de codes 1xx, 2xx, 3xx et 485. Il fournit en général l’URL où l'utilisateur pourra être contacté lors de communications ultérieures.
Content-Encoding : Quand il est présent, sa valeur indique le code utilisé pour écrire et lire l'en-tête d'entité. Ainsi le serveur qui reçoit le message sait quel mécanisme de décodage appliquer pour lire le Content-Type décrit ci-dessus et peut connaître le type de média utilisé. Ce champ est très utile si l'on veut compresser les en-têtes sans perdre les informations précieuses qu'ils contiennent. A noter que les seuls codes qui peuvent être utilisés sont ceux qui ont été listé dans le Accept-Encoding du message précédent.
Content-Length : Il indique simplement la taille du Corps du message envoyé, en nombre décimal d'octets.
Exemple : Content-Length : 3495.
Si la longueur annoncée est plus grande que celle réelle, le client génère une réponse de code 400. Si elle est plus petite, et donc si le message contient des données supplémentaires, elles seront lues comme un nouveau message. Ce système permet ainsi de placer plusieurs messages dans un même paquet UDP. Par contre en l'absence de ce champ, le client comprend que le message correspond à la totalité du paquet UDP que le message correspond à toutes les données qui arrivent jusqu'à la fermeture de la connexion TCP.
Content-Type : Il indique les types de média utilisés dans le Corps du message envoyé.
Exemple : Content-Type : application/sdp
Content-Type : text/html;charset=iso-88596
Cseq : Chaque requête doit obligatoirement contenir un numéro de séquence Cseq (entier non signé de 32 bits). Le Cseq initial est choisi arbitrairement par celui qui envoie la requête INVITE mais doit toujours être inférieur à 2^31. Ensuite, toutes les requêtes qui se succèdent (mais qui diffèrent par leur méthode, leurs En-têtes ou bien leur Corps du message) augmentent strictement leur Cseq au fur et à mesure des échanges. Ainsi, si une requête est réémise, elle garde le même numéro de séquence mais si elle a été modifiée, elle l'augmente. Un serveur doit répondre à une requête avec le même Cseq et les requêtes ACK ou BYE, terminant cette transaction, doivent posséder le même Cseq. Grâce à ce champ, la réponse à une invitation ou à un acquittement ne peut pas être mal comprise même si elle arrive en retard. Cseq permet aussi au serveur de comprendre qu'il s'agit d'une nouvelle version d'une invitation (même Call-Id, Cseq supérieur) sans avoir à lire le Corps du message.
Date : donne la date d’émission de la requête ou de la réponse. Les retransmissions possèdent la même date que la requête ou réponse d’origine.
Encryption : Ce champ spécifie si le message est crypté et suivant quel cryptage. Les requêtes utilisent comme clés publiques celles correspondant à l’URL TO. Les réponses utilisent cette même clé publique. Seul le Corps du message et quelques champs d’en-tête sensibles sont cryptés.
Expires : donne la durée au dela de laquelle le message expire.
From : indique la personne à l'origine du message. Il peut contenir le paramètre tag.
Hide: Le client utilise ce champ lorsqu'il veut que le chemin compris dans l'En-Tête VIA soit caché aux prochains Proxy Servers que traverseront le message.
Max-Forwards : utilisé pour limiter le nombre de PS ou passerelles que la requête peut traverser jusqu’au prochain serveur dans le sens de l'UAC vers l'UAS (downstream).
Organization : précise le nom de l’organisation à laquelle l’entité dont émane la requête ou la réponse appartient.
Priority : indique le niveau d’urgence de la requête, tel qu’il est perçu par le client.
Exemples : priority = emergency
priority = non-urgent
Proxy-Authenticate : ce champ doit être rempli dans une réponse Proxy Authentification Required (code 407).
Proxy-Authorization : permet au client de s’identifier dans sa requête en destination d’un PS le lui ayant demandé.
Proxy-Require : indique quels champs d’en-tête le PS supporte.
Record-Route : Ce champ permet de mémoriser un chemin pour faciliter l'acheminement de la réponse. Chaque Proxy Serveur traversé ajoute son adresse dans ce champ en début de liste. Le serveur appelé copie cette liste, sans la changer, dans l'en-tête Route de sa réponse. La première entrée est ainsi l'adresse du server le plus proche de celui qui répond.
Exemple:
si le message a traversé les hôtes ieee.org et bell-telephone.com dans cet ordre le Record-Route sera de la forme :
Record-Route : <sip : a.g.bell@bell-telephone.com>, <sip : a.bell@ieee.org>
Require : utilisé par le client pour dire au serveur distant quelles options il devra supporter.
Exemple :
C -> S INVITE sip : watson@bell-telephone.com SIP/2.0
Require : org.ietf.sip.encrypt-response
La réponse devra être obligatoirement cryptée. Si le serveur ne comprend pas l'option, il répond par une réponse Bad Extension ( code 420):
S -> C SIP/2.0 420 Bad Extension
Unsupported : org.ietf.sip.encrypt-response
Response-Key : le client utilise cet en-tête dans sa requête pour déterminer la clé a utilisé pour crypter la réponse.
Retry-After : ce champ n'est utilisé que dans les réponses Service Unavailable(code 503), Not Found (code 404), Busy (code 600) ou bien Decline (code 603) pour indiquer à l'emetteur de la requête quand est-ce qu'un service "normal" pourra reprendre. Il contient une date ou un nombre en décimal de secondes.
Exemple : Retry-After : 120
Retry-After : Mon, 01 Jan 9999 00: 00:00 GMT
Route : Ce champ détermine le chemin que prendra la requête.
Server : Il contient les informations sur les softwares utilisés par les UAS.
Subject : Résumé ou nature de l'appel qui peut permettre de le filtrer sans avoir à lire la description de la session.
Timestamp : précise l'instant (date) où le client a envoyé la requête au serveur. Le serveur renvoie cette date en écho dans sa réponse mais il peut, s'il en a les moyens, ajouter une estimation du temps que le message a pris pour lui parvenir. Ainsi le client peut avoir une idée du temps de traversée du réseau et établir sa temporisation de réémission.
To : C'est l'adresse du destinataire. Ce champ est bien sûr obligatoire.
Exemple:
To : The operator <sip : operator@cs.columbia.edu>; tag=287447
Le tag rend une adresse beaucoup plus précise puisqu'il distingue les multiples applications de l'utilisateur correspondant à l'URL (audio, vidéo, mail…)
Unsupported : liste quelles configurations ne sont pas supportées par le serveur.
User-Agent : contient des informations sur le terminal de l'utilisateur (UAC/UAS) à l’origine de la requête.
Via : contient les adresses des serveurs (PS) que traverse la requête. Chaque nouvelle adresse rencontrée se place en tête de liste. Il existe donc une trace du chemin parcouru par la requête, ce qui permet d'éviter les boucles (looping) et d'être sûr que la requête ne repassera pas par la même adresse. Par exemple, si un proxy reçoit une requête et reconnaît sa propre adresse dans la champ Via, il renvoie une réponse Loop Detected (code 482). De même, il ne peut pas envoyer un message à un groupe en multicast si l'un d'entre eux est dans le VIA. Il est parfois possible qu'un serveur change l'adresse du From (adresse source), en faisant suivre le message, pour y mettre la sienne (c'est le cas des Network Address Translators, NAT). Dans ce cas, un paramètre supplémentaire indique ce changement d'adresse utile pour la réponse.
Exemple :
Via : sip/2.0/UDP erlang.bell-telephone.com : 5060
Via : SIP/2.0/UDP 10.0.0.1 : 5060 ; received=199.172.136.3
Ici, 199.172.136.3 est la nouvelle adresse remplaçant l’adresse d’origine 10.0.0.1.
Warning : Les avertissements sont contenus dans les réponses dans le langage le plus compréhensible pour l'utilisateur. Chaque serveur peut ajouter des warning à la réponse qu'il transmet (code 3xx ).
WWW-Authenticate : doit être inclus dans une réponse Unauthorized (code 401).