La première ligne d’un message SIP (requête ou réponse) indique toujours le type de méthode (ex. INVITE) suivi de l’identifiant (URI) de l’utilisateur ou du service associé à la requête. La fin de cette ligne indique toujours la version du protocole SIP, à savoir SIP/2.0.


Les lignes suivantes sont constituées de champs d’entête (header fields) obligatoires ou non qui forment l’entête du message SIP.

Les champs d’entête suivants se retrouvent dans toutes les requêtes SIP :


Champ From:

Le champ From: doit être présent dans toutes les requêtes et réponses SIP. Il contient un nom optionel (Display Name) entre guillemets utile pour l’affichage ainsi que l’adresse de l’émetteur de la requête. L’étiquette tag= est obligatoire et correspond à une valeur unique permettant d’identifier l’émetteur sans équivoque. Si l’utilisateur ne souhaite pas être identifié, la valeur Anonymous est utilisée pour le Display Name et l’émetteur.

Exemple

From: "Paul Dupont";tag=40627210
From: "Anonymous";tag=a34ca8e5506847ceo0


Champ To:

Le champ To: doit être présent dans toutes les requêtes et réponses SIP. Il indique la destination et est recopié à l’identique dans les réponses.

Exemple

To: ;tag=40627210


Champ Call-ID:

Le Call-ID est un identifiant unique généré pour toute nouvelle requête. Il permet de mettre en correspondance les requêtes et les réponses. Des requêtes INVITE successives avec le même Call-ID mais avec un contenu différent correspondent à un re-INVITE permettant par exemple de changer dynamiquement les paramètres d’une session (ex. Mise en attente d’un appel avec diffusion d’une musique d’attente).
Le contenu du Call-Id se compose d’une première partie unique caractérisant l’équipement et d’une deuxième partie spécifique à un domaine ou à une adresse IP (supposée publique).

Exemple

Call-ID: a5fe43f1-56768832 @192.168.1.100
Call-ID: c77a5d99-71aa7cd4 @domaine.com


Champ CSeq:

Les requêtes SIP doivent toujours indiquer un numéro de séquence et un nom de méthode dans le champ CSeq:. Pour un même appel, le numéro de séquence doit être incrémenté à chaque nouvelle requête. Dans le cas d’une retransmission d’une requête précédente, le numéro de séquence est repris. La numérotation commence à une valeur aléatoire.

Exemple

CSeq: 1234 INVITE
CSeq: 101 ACK


Champ Via:

Le champ Via: sert à retracer la route suivie par une requête SIP au travers de serveurs SIP successifs. A chaque passage par un nouveau serveur, un nouveau champ est ajouté à la liste de champs Via: déjà présente dans le message. Une fois la requête arrivée a destination, la réponse suivra chaque serveur SIP exactement en sens inverse.

Exemple

Via: SIP/2.0/UDP 192.168.0.215:5060;branch=z9hG4bK-f7e3ca-c851cefb-6e453f69
Via: SIP/2.0/UDP 192.168.1.200:5066;branch=z9hG4bK-72fa7c4e


Champ Max-Forwards:

Le champ Max-Forwards doit être utilisée pour toute requête pour limiter le nombre de serveurs SIP qui peut être traversé jusqu’à destination. Chaque serveur recevant une requête devra décrémenter la valeur du champ Max-Forwards. Si un serveur reçoit une requête avec un champ Max-Forwards égal à 0, il renvoie une réponse 483 Too Many Hops.

Exemple

Max-Forwards: 70


Champ Content-Type:

Le champ Content-Type décrit le type d’information contenu dans le corps du message. Le type de contenu le plus courant est application/sdp pour la description de session par le protocole SDP.

Exemple

Content-Type: application/sdp
Content-Type: application/dialog-info+xml
Content-Type: application/simple-message-summary
Content-Type: text/html; charset=ISO-8859-4


Champ Content-Length:

Ce champ indique le nombre d’octets dans le corps du message. Si le message ne comprend aucun corps, la valeur 0 est utilisée.

Exemple

Content-Length: 160


Champ Accept:

Le champ Accept peut être utilisé pour spécifier les types de media acceptables pour la réponse. Si ce champ n’est pas précisé le serveur doit supposer que la valeur par défaut application/sdp est utilisée. Lorsque le champ est vide, aucun format n’est
acceptable.

Exemple

Accept: application/sdp
Accept: application/sdp,application/cpim-pidf+xml
Accept: application/sdp;level=1, application/x-private, text/html


Champ Accept-Encoding:

Le champ Accept-Encoding est similaire au champ Accept mais restreint les modes de codage acceptables pour la réponse. Si le champ est vide, il équivaut à Accept-Coding: Identity qui signifie qu’aucun encodage n’est admis. Si le champ n’est pas précisé, le
serveur doit supposer que la valeur par défaut Identity est utilisée.

Exemple

Accept-Encoding: Identity
Accept-Encoding: gzip


Champ Accept-Language:

Le champ Accept-Language est utilisé dans les requêtes pour indiquer la langue préférée pour les textes explicatifs (reason phrases), les descriptions de session ou les états transportés dans le corps de la réponse. Si aucun champ Accept-Language n’est présent, le serveur doit supposer que toutes les langues sont aceptables pour le client. Plusieurs langues peuvent être précisées et ordonnées selon la valeur du paramètre “q”.

Exemple

Accept-Language: da, en-gb;q=0.8, en;q=0.7


Champ Alert-Info:

Lorsqu’il est présent dans une requête INVITE, le champ Alert-Info spécifie une tonalité de sonnerie alternative pour le serveur. Lorsqu’il est présent dans une réponse 180 Ringing, le champ Alert-Info spécifie une tonalité de sonnerie alternative pour le client. Ce champ est notamment destiné à des sonneries personnalisées.

Exemple

Alert-Info: <http://www.example.com/sounds/moo.wav>


Champ Allow:

Le champ Allow fournit la liste des méthodes supportées par l’équipement ayant généré le message. Toutes les méthodes supportées par l’équipement (y compris ACK et CANCEL) doivent être indiquées dans le champ Allow lorsqu’il est présent. L’absence de ce champ ne doit pas être interprétée comme signifiant que l’équipement ayant envoyé le message ne supporte aucune méthode. Cela signifie simplement que l’équipement ne fournit aucune information sur la liste des méthodes supportées.

Exemple

Allow: INVITE, ACK, OPTIONS, CANCEL, BYE


Champ Authentication-Info:

Le champ Authentication-Info sert à l’authentification mutuelle par HTTP Digest (voir RFC 2617). Un serveur peut inclure ce champ dans une réponse 2xx à une requête authentifiée avec succès en utilisant digest sur la base du champ Authorization.

Exemple

Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c"


Champ Authorization:

Le champ Authorization contient les éléments nécessaires à l’authentification d’un équipement. Ce champ, ainsi que le champ Proxy-Authorization, rompt avec les règles générales sur les valeurs multiples dans les champs d’entête.

Exemple

Authorization: Digest username="Alice", realm="atlanta.com",
nonce="84a4cc6f3082121f32b42a2187831a9e",
response="7587245234b3434cc3412213e5f113a5432"
Authorization: Digest username="0123456789",realm="sip.w3tel.net",
nonce="0x522",uri="sip:sip.w3tel.net",
response="7be8634dceb153f4671b7fa18fd735a0",algorithm=MD5,
cnonce="4ee78daa",opaque="",qop=auth,nc=00000001

Champ Call-Info:

Le champ Call-Info fournit des informations complémentaires relatives à l’appelant ou l’appelé suivant qu’il est présent soit dans la requête ou la réponse. L’objet associé à l’identifiant est décrit dans le paramètre “purpose”. Le paramètre “icon” désigne une image correspondant à une representation icônisée de l’appelant ou de l’appelé. Le paramètre “info” décrit l’appelant ou l’appelé d’une manière générale, par exemple par une page Web. Le paramètre “card” fournit une carte de visite, par exemple dans les formats vCard ou LDIF.

L’usage du champ Call-Info peut induire un risque quand à la sécurité. Si un appelé accède à des données fournies par un appelant malveillant, il peut être exposé l’affichage de contenus inappropriés, offensants, dangereux, illégaux, etc. Il est par conséquent recommandé que l’équipement destinataire ne donne accès à ces informations que lorsque l’authenticité des éléments a été vérifiée.

Exemple

Call-Info: <http://wwww. example.com/alice/photo.jpg> ;
purpose=icon,<http://www. example.com/alice/> ;purpose=info


Champ Contact:

Le champ Contact fournit un identifiant (URI) dont la valeur dépend du type de requête ou de réponse dans lequel il se trouve. Ce champ peut contenir un nom d’affichage (display name), un URI avec des paramètres d’URI ainsi que des paramètres d’en-tête.

Les paramètres “q” et “expires” peuvent être présents dans le champ Contact pour les requêtes et réponses REGISTER ou dans une réponse de classe 3xx.

Exemple

Contact: "Mr. Watson" <sip:watson@ worcester.bell-telephone.com>;q=0.7;
expires=3600,"Mr. Watson" <mailto:watson@ bell-telephone.com> ;q=0.1


Champ Content-Disposition:

Le champ Content-Disposition décrit comment le corps du message ou, pour les messages en plusieurs parties, comment le corps doit être interprété par le client ou le serveur. Ce champ étend le Content-Type de MIME (RFC 2183).

Plusieurs nouveaux types sont définis par le protocole SIP. La valeur “session” indique que le corps décrit une session soit pour le média de l’appel soit pour le média avant l’établissement de l’appel (early media). La valeur “render” indique que le corps devrait être affiché ou présenté à l’utilisateur par une opération de rendu.

Si le champ Content-Disposition n’est pas fourni, le serveur doit supposer que les corps ayant le champ Content-Type égal à “application/sdp” utilise un Content-Disposition égal à “session”. Pour les autres valeurs de Content-Type, la valeur par défaut à utiliser est “render”.

La valeur “icon” indique que le corps contient une image représentant l’appelant ou l’appelé. La valeur “alert” indique que le corps contient une information telle qu’un clip audio qui doit être joué afin que l’utilisateur soit alerté de la réception d’une requête (généralement un appel). Cette alerte peut se traduire par une tonalité de sonnerie pour un appel après l’envoi d’une réponse 180 Ringing.

Par mesure de sécurité, tout corps MIME contenant des informations devant être présentées à l’utilisateur devrait n’être traité qu’après authentification.

Exemple

Content-Disposition: session


Champ Content-Encoding:

Le champ Content-Encoding est utilisé pour modifier le type de media. Lorsqu’il est fourni, sa valeur indique qu’un codage additionnel du contenu a été appliqué au corps et, qu’en conséquence, les mécanismes de décodage appropriés doivent être appliqués. Le champ Content-Encoding est principalement utilisé pour la compression du corps du message. Si plusieurs encodages ont été appliqués, la liste des codages doit être donnée par ordre d’application.

Un client peut appliquer les encodages de son choix dans ses requêtes. Le serveur est libre d’appliquer ou non un encodage dans le corps des réponses selon les codages listés dans le champ Accept-Encoding de la requête.

Exemple

Content-Encoding: gzip
Content-Encoding: tar


Champ Content-Language:


Ce champ décrit la langue utilisé pour le corps du message.

Exemple

Content-Language: fr


Champ Date:

Le champ Date contient une date et une heure selon le format de la RFC 1123. Cependant, le protocole SIP restreint le fuseau horaire à “GMT” alors que la RFC 1123 prévoit tous les fuseaux horaires.

Exemple

Date: Sat, 13 Nov 2010 23:29:00 GMT


Champ Error-Info:

Le champ Error-Info fournit un pointeur vers une information additionnelle relative à l’erreur retournée dans la réponse.

Un client peut traiter l’identifiant (URI) contenu dans un champ Error-Info comme un contact et générer un nouvel INVITE qui fournira un enregistrement audio.

Exemple

SIP/2.0 404 The number you have dialed is not in service
Error-Info: <sip:not-in-service-recording@ atlanta.com>


Champ Expires:

Le champ Expires fournit un délai relatif au terme duquel le message ou le contenu expire. La signification de ce champ dépend de la méthode dans laquelle il est présent.

Le délai d’expiration dans un INVITE n’affecte pas la durée de la session actuelle résultant de l’invitation. En revanche, les protocoles de description de sessioin peuvent offrir la capacité de limiter expressément la durée de la session.

La valeur de ce champ est exprimée en secondes mesurées à compter de la réception de la requête.

Exemple

Expires: 3600


Champ In-Reply-To:

Le champ In-Reply-To énumère les Call-ID associés à cet appel ou ce retour. Ces Call-ID peuvent avoir été mis en cache par le client puis inclus dans l’entête dans un retour d’appel.
Cela permet aux systèmes de distribution automatique d’appels de router les retours d’appels à l’initiateur du premier appel. Cela permet également aux appelés de filtrer les appels, de sorte que seuls les appels retournés et qui ont été générés sont acceptés.

Exemple

In-Reply-To: 70710@ saturn.bell-tel.com, 17320@ saturn.bell-tel.com


Champ Min-Expires:


Le champ Min-Expires indique l’intervalle minimum de raffraichissement supporté par le serveur pour l’état des éléments qu’il gère. Cela comprend les champs Contact stockés dans un serveur d’enregistrement (registrar). La valeur de ce champ est exprimée en secondes. La réponse 423 Interval Too Brief est retournée lorsque le Min-Expire est trop bref.

Exemple

Min-Expires: 60


Champ MIME-Version:

Version utilisée pour l’encodage MIME.

Exemple

MIME-Version: 1.0



Champ Organization:


Le champ Organisation indique le nom de l’organisation à laquelle la requête ou la réponse appartiennent. Ce champ peut par exemple servir au filtrage d’appels par le client.

Exemple

Organization: W3Tel


Champ Priority:

Le champ Priority indique l’urgence de la requête selon la perception du client. Ce champ décrit la priorité de la requête pour l’utilisateur ou son agent. Il peut par exemple être utilisé pour prendre des décisions de routage ou d’acceptation d’appels.
Un message ne contenant pas de champ Priority est traité comme ayant une priorité normale. Les valeurs possibles pour ce champ sont “non-urgent”, “normal”, “urgent” et “emergency” mais d’autres valeurs peuvent être définies par ailleurs.

La valeur “emergency” ne doit en principe être utilisée que lorsque la vie, l’intégrité physique ou la destruction de bien sont en jeu.

Exemple

Subject: Tempete imminente
Priority: emergency


Champ Proxy-Authenticate:

Le champ Proxy-Authenticate est utilisé pour formuler une demande d’authentification.

Exemple

Proxy-Authenticate: Digest realm="w3tel.com",
domain="sip:w3tel.com", qop="auth",
nonce="f84f1cec41e6cbe5aea9c8e88d359",
opaque="", stale=FALSE, algorithm=MD5


Champ Proxy-Authorization:

Le champ Proxy-Authorization permet au client de s’identifier auprès d’un proxy qui lui demande une authentification. Ce champ

contient les éléments relatifs à l’identification de l’utilisateur sur le proxy et ou le domaine des ressources demandées.

Exemple

Proxy-Authorization: Digest username="Alice", realm="atlanta.com",
nonce="c60f3082ee1212b402a21831ae",
response="245f23415f11432b3434341c022"


Champ Proxy-Require:

Le champ Proxy-Require est utilisé pour indiquer des fonctions caractéristiques du proxy qui doivent être supportées par le proxy.

Exemple

Proxy-Require: foo


Champ Record-Route:

Le champ Record-Route est inséré par des proxy dans une requête afin de forcer les futures requêtes associées au dialogue à être routées au travers des proxy.

Exemple

Record-Route: <sip:server10.biloxi.com;lr>,<sip:bigbox3.site3.atlanta.com;lr>


Champ Reply-To:

Le champ Reply-To contient un identifiant (URI) de retour qui peut être différent de celui indiqué dans le champ From. Cet identifiant peut par exemple être utilisé pour un retour des appels manqués ou des sessions non établies. Si l’utilisateur souhaite rester anonyme, ce champ peut être omis ou rempli de sorte qu’il ne révèle aucune information privée.

Exemple

Reply-To: Bob <sip:bob@ w3tel.com>


Champ Require:

Le champ Require est utilisé par les clients pour informer les serveurs des options que les clients s’attendent à être supportées par les serveurs. Bien qu’optionnel, ce champ ne doit pas être ignoré lorsqu’il est présent.

Exemple

Require: 100rel


Champ Retry-After:

Le champ Retry-After peut être utilisé avec une réponse 500 Internal Server Error ou 503 Service Unavailable afin d’indiquer la durée pendant laquelle le service devrait être indisponible. Ce champ peut également être utilisé avec les réponses 404 Not Found413 Request Entity Too Large480 Temporarily Unavailable486 Busy Here ou 603 Decline afin d’indiquer quand l’appelé anticipe d’être à nouveau disponible. La valeur de ce champ indique une durée en seconde à compter de la réponse.

Un commentaire optionnel peut être utilisé pour indiquer des informations additionnelles sur l’heure de rappel. Un paramètre optionnel “duration” indique la durée pendant laquelle l’appelé sera joignable à partir du moment où il sera à nouveau disponible.

Si aucun paramètre “duration” n’est fourni, l’utilisateur est supposé disponible indéfiniment.

Exemple

Retry-After: 18000;duration=3600
Retry-After: 120 (Je suis en réunion)


Champ Route:

Le champ Route est utilisé pour forcer le routage d’une requête au travers d’une liste définie de proxy.

Exemple

Route: <sip:bigbox3.site3.atlanta.com;lr>,<sip:server10.biloxi.com;lr>


Champ Server:

Le champ Server contient des informations sur le logiciel utilisé par le serveur pour traiter la demande.

La révélation de la version spécifique du logiciel du serveur peut le rendre vulnérable aux attaques au travers de failles de sécurité connues.

Exemple

Server: SipServer V2


Champ Subject:

Le champ Subject fournit un résumé ou indique la nature de l’appel, autorisant ainsi le filtrage sans avoir à analyser la description de la session. La description de la session ne doit pas nécessairement utiliser le même sujet dans l’invitation.

Exemple

Subject: Need more boxes

Champ Supported:

Le champ Supported énumère toutes les extensions supportées par le client ou le serveur.

Exemple

Supported: 100rel


Champ Timestamp:

Le champ Timestamp indique le moment ou le client a envoyé la requête au serveur.

Exemple

Timestamp: 54


Champ Unsupported:

Le champ Unsupported fournit la liste des fonctions non supportées par le serveur.

Exemple

Unsupported: foo


Champ User-Agent:

Le champ User-Agent contient des informations relatives au client à l’origine de la requête.

La révélation de la version spécifique du logiciel de l’agent peut le rendre vulnérable aux attaques au travers de failles de sécurité connues.

Exemple

User-Agent: Softphone Beta1.5


Champ Warning:

Le champ Warning est utilisé pour véhiculer des informations additionnelles sur la réponse. Les valeurs du champ Warning sont envoyées dans les réponses et contiennent un code sur 3 chiffres, un nom d’hôte et un texte explicatif (warn-text).

Le texte explicatif est en langage naturel pour être compréhensible par une personne phyqique. La localisation de l’utilisateur, la valeur du champ Accept-Language dans la requête our le champ Content-Language dans une réponse permettent éventuellement de choisir la langue du texte.

Les codes actuellement définis sont décrits ci-dessous. Le premier chiffre “3” fait référence aux Warnings spécifiques au protocole SIP. Les valeurs 300 à 329 sont réservées aux problèmes de mot-clés dans les descriptions de session. Les valeurs 330 à 339 sont réservées aux Warning relatifs aux services réseau de base requis dans la description de session. Les valeurs 370 à 379 concernent les Warnings aux paramètres QoS requis dans la description de session. Enfin, les valeurs 390 à 399 correspondent à divers cas ne tombant dans aucune des catégories précédentes.

Exemple

Warning: 307 isi.edu "Session parameter 'foo' not understood"
Warning: 301 isi.edu "Incompatible network address type 'E.164'"


Champ WWW-Authenticate:

Un champ WWW-Authenticate contient une demande d’authentification.

Exemple

WWW-Authenticate: Digest realm="atlanta.com",
domain="sip:boxesbybob.com", qop="auth",
nonce="f84f1cec41e6cbe5aea9c8e88d359",
opaque="", stale=FALSE, algorithm=MD5