loader image

Documentation

Comprendre la VOip

Syntaxe SIP

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.

Form

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"<sip:1234 @192.168.1.100>;tag=40627210 From: "Anonymous"<sip:Anonymous @192.168.1.101>;tag=a34ca8e5506847ceo0 				 			

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: <sip:1234 @192.168.1.100>;tag=40627210  				 			

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  				 			

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  				 			

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  				 			

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  				 			

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 				 			

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  				 			

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 				 			

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 				 			

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  				 			

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> 				 			

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  				 			

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"  				 			

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 				 			

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 				 			

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 				 			

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  				 			

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 				 			

Content-Language

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

Exemple
 				 					Content-Language: fr  				 			

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  				 			

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>  				 			

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  				 			

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  				 			

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  				 			

MIME-Version

Version utilisée pour l'encodage MIME.

Exemple
 				 					MIME-Version: 1.0  				 			

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: Teqtel  				 			

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 				 			

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 				 			

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" 				 			

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  				 			

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>  				 			

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@ teqtel.com>  				 			

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  				 			

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 Found, 413 Request Entity Too Large, 480 Temporarily Unavailable, 486 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)  				 			

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>  				 			

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

Server

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  				 			

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  				 			

Supported

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

Exemple
 				 					Supported: 100rel  				 			

Timestamp

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

Exemple
 				 					Timestamp: 54  				 			

Unsupported

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

Exemple
 				 					Unsupported: foo  				 			

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  				 			

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'" 				 			

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