20. Champs d'en-tête (Header Fields)
20 Champs d'en-tête
La syntaxe générale des champs d'en-tête est traitée à la section 7.3. Cette section énumère l'ensemble complet des champs d'en-tête avec des annotations sur la syntaxe, la sémantique et l'utilisation. Tout au long de cette section, [HX.Y] est utilisé pour faire référence à la section X.Y de la spécification HTTP/1.1 actuelle, RFC 2616 [8]. Des exemples de chaque champ d'en-tête sont présentés.
Les informations relatives aux champs d'en-tête concernant les méthodes et le traitement par proxy sont résumées dans les tableaux 2 et 3.
La colonne « where » décrit les types de requêtes et de réponses dans lesquels le champ d'en-tête peut apparaître. Les valeurs de cette colonne sont les suivantes :
R : Le champ d'en-tête peut apparaître uniquement dans les requêtes.
r : Le champ d'en-tête peut apparaître uniquement dans les réponses.
2xx, 4xx, etc. : Un nombre ou une plage indique les codes de réponse dans lesquels le champ d'en-tête peut être utilisé.
c : Le champ d'en-tête est copié de la requête vers la réponse.
Si la colonne « where » est vide, cela indique que le champ d'en-tête peut être présent dans toutes les requêtes et réponses.
La colonne « proxy » décrit les opérations qu'un proxy peut effectuer sur le champ d'en-tête.
a : Un proxy peut ajouter ou concaténer le champ d'en-tête s'il est absent.
m : Un proxy peut modifier une valeur de champ d'en-tête existante.
d : Un proxy peut supprimer la valeur du champ d'en-tête.
r : Un proxy doit pouvoir lire le champ d'en-tête, donc ce champ d'en-tête ne peut pas être chiffré.
Les six colonnes suivantes se rapportent à la présence du champ d'en-tête dans les méthodes.
c : Conditionnel. L'exigence pour le champ d'en-tête dépend du contexte du message.
m : Le champ d'en-tête est obligatoire.
m* : Le champ d'en-tête est recommandé (SHOULD) d'être envoyé, mais le client/serveur doit être prêt à recevoir un message sans ce champ d'en-tête.
o : Le champ d'en-tête est optionnel.
t : Le champ d'en-tête est recommandé (SHOULD) d'être envoyé, mais le client/serveur doit être prêt à recevoir un message sans ce champ d'en-tête.
Lorsqu'un protocole basé sur flux (comme TCP) est utilisé comme transport, le champ d'en-tête doit être envoyé.
* : Le champ d'en-tête est obligatoire si le corps du message n'est pas vide. Voir sections 20.14, 20.15 et 7.4 pour plus de détails.
- : Le champ d'en-tête ne s'applique pas.
« Optionnel » signifie qu'un élément PEUT inclure le champ d'en-tête dans une requête ou une réponse, et qu'un UA PEUT ignorer le champ d'en-tête s'il est présent dans une requête ou une réponse (à l'exception du champ d'en-tête Require discuté à la section 20.32). Un champ d'en-tête « obligatoire » doit être présent dans une requête et doit être compris par le UAS recevant la requête. Un champ d'en-tête de réponse « obligatoire » doit être présent dans la réponse et le champ d'en-tête doit être compris par le UAC traitant la réponse. « Ne s'applique pas » signifie que le champ d'en-tête ne DOIT PAS être présent dans une requête. S'il est placé par erreur dans une requête, il doit être ignoré par le UAS recevant la requête. De même, un champ d'en-tête étiqueté « ne s'applique pas » pour une réponse signifie que le UAS ne doit pas placer le champ d'en-tête dans la réponse, et que le UAC doit ignorer le champ d'en-tête dans la réponse.
Un UA devrait ignorer les paramètres de champ d'en-tête d'extension qu'il ne comprend pas.
Des abréviations de certains noms de champs d'en-tête courants sont également définies pour une utilisation lorsque la taille globale du message est un problème.
Les champs d'en-tête Contact, From et To contiennent des URI. Si un URI contient une virgule, un point d'interrogation ou un point-virgule, l'URI doit être encadré par des crochets angulaires (« < » et « > »). Les paramètres d'URI sont inclus à l'intérieur de ces crochets. Si l'URI n'est pas encadré par des crochets angulaires, les paramètres séparés par des points-virgules sont des paramètres d'en-tête, et non des paramètres d'URI.
20.1 Accept
Le champ d'en-tête Accept suit la syntaxe définie dans [H14.1]. La sémantique est également identique, à l'exception que si le champ d'en-tête Accept est absent, le serveur devrait supposer la valeur par défaut application/sdp.
Un champ d'en-tête Accept vide signifie qu'aucun format n'est accepté.
Exemple :
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Accept R - o - o m* o
Accept 2xx - - - o m* o
Accept 415 - c - c c c
Accept-Encoding R - o - o o o
Accept-Encoding 2xx - - - o m* o
Accept-Encoding 415 - c - c c c
Accept-Language R - o - o o o
Accept-Language 2xx - - - o m* o
Accept-Language 415 - c - c c c
Alert-Info R ar - - - o - -
Alert-Info 180 ar - - - o - -
Allow R - o - o o o
Allow 2xx - o - m* m* o
Allow r - o - o o o
Allow 405 - m - m m m
Authentication-Info 2xx - o - o o o
Authorization R o o o o o o
Call-ID c r m m m m m m
Call-Info ar - - - o o o
Contact R o - - m o o
Contact 1xx - - - o - -
Contact 2xx - - - m o o
Contact 3xx d - o - o o o
Contact 485 - o - o o o
Content-Disposition o o - o o o
Content-Encoding o o - o o o
Content-Language o o - o o o
Content-Length ar t t t t t t
Content-Type * * - * * *
CSeq c r m m m m m m
Date a o o o o o o
Error-Info 300-699 a - o o o o o
Expires - - - o - o
From c r m m m m m m
In-Reply-To R - - - o - -
Max-Forwards R amr m m m m m m
Min-Expires 423 - - - - - m
MIME-Version o o - o o o
Organization ar - - - o o o
Tableau 2 : Résumé des champs d'en-tête, A–O
Header field where proxy ACK BYE CAN INV OPT REG
Priority R ar - - - o - - Proxy-Authenticate 407 ar - m - m m m Proxy-Authenticate 401 ar - o o o o o Proxy-Authorization R dr o o - o o o Proxy-Require R ar - o - o o o Record-Route R ar o o o o o - Record-Route 2xx,18x mr - o o o o - Reply-To - - - o - - Require ar - c - c c c Retry-After 404,413,480,486 - o o o o o 500,503 - o o o o o 600,603 - o o o o o Route R adr c c c c c c Server r - o o o o o Subject R - - - o - - Supported R - o o m* o o Supported 2xx - o o m* m* o Timestamp o o o o o o To c(1) r m m m m m m Unsupported 420 - m - m m m User-Agent o o o o o o Via R amr m m m m m m Via rc dr m m m m m m Warning r - o o o o o WWW-Authenticate 401 ar - m - m m m WWW-Authenticate 407 ar - o - o o o
Tableau 3 : Résumé des champs d'en-tête, P–Z ; (1) : copié avec ajout possible de balise
Accept: application/sdp;level=1, application/x-private, text/html
20.2 Accept-Encoding
Le champ d'en-tête Accept-Encoding est similaire à Accept, mais se limite aux content-codings [H3.5] acceptables dans la réponse. Voir [H14.3]. La sémantique dans SIP est identique à celle définie dans [H14.3].
Un champ d'en-tête Accept-Encoding vide est autorisé. Il est équivalent à Accept-Encoding : identity, c'est-à-dire que seul le codage identity, signifiant sans codage, est autorisé.
Si le champ d'en-tête Accept-Encoding est absent, le serveur devrait supposer la valeur par défaut identity.
Cela diffère quelque peu de la définition HTTP. La définition HTTP indique que si elle est absente, n'importe quel codage peut être utilisé, mais que le codage identity est préféré.
Exemple :
Accept-Encoding: gzip
20.3 Accept-Language
Le champ d'en-tête Accept-Language est utilisé dans une requête pour indiquer la langue préférée pour la phrase de raison transportée dans le corps du message de la réponse, la description de session ou la réponse d'état. Si le champ d'en-tête Accept-Language est absent, le serveur devrait supposer que toutes les langues sont acceptables par le client.
Le champ d'en-tête Accept-Language suit la syntaxe définie dans [H14.4]. Les règles de classement des langues basées sur le paramètre « q » s'appliquent également à SIP.
Exemple :
Accept-Language: da, en-gb;q=0.8, en;q=0.7
20.4 Alert-Info
Lorsqu'il est présent dans une requête INVITE, le champ d'en-tête Alert-Info spécifie une sonnerie alternative pour le UAS. Lorsqu'il est présent dans une réponse 180 (Ringing), le champ d'en-tête Alert-Info spécifie une sonnerie alternative pour le UAC. L'utilisation typique consiste pour un proxy à insérer ce champ d'en-tête afin de fournir une fonctionnalité de sonnerie distincte.
Le champ d'en-tête Alert-Info peut présenter un risque de sécurité. Ces risques et leur traitement sont discutés à la section 20.9 qui traite du champ d'en-tête Call-Info, car les risques sont identiques.
De plus, l'utilisateur devrait pouvoir désactiver cette fonctionnalité de manière sélective.
Cela aide à prévenir la confusion pouvant résulter de l'utilisation de ce champ d'en-tête par un élément non fiable.
Exemple :
Alert-Info: <http://www.example.com/sounds/moo.wav>
20.5 Allow
Le champ d'en-tête Allow énumère l'ensemble des méthodes prises en charge par le UA générant le message.
Toutes les méthodes comprises par le UA (y compris ACK et CANCEL) doivent être incluses dans la liste des méthodes du champ d'en-tête Allow, s'il est présent. L'absence du champ d'en-tête Allow ne doit pas être interprétée comme signifiant que le UA envoyant le message ne prend en charge aucune méthode. Plutôt, cela signifie qu'il ne fournit aucune information sur les méthodes prises en charge par le UA.
L'inclusion du champ d'en-tête Allow dans une réponse à une méthode autre qu'OPTIONS réduit le nombre de messages nécessaires.
Exemple :
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE
20.6 Authentication-Info
Le champ d'en-tête Authentication-Info fournit une authentification mutuelle via HTTP Digest. Un UAS peut inclure ce champ d'en-tête dans une réponse 2xx à une requête authentifiée avec succès par digest basé sur le champ d'en-tête Authorization.
La syntaxe et la sémantique suivent celles spécifiées dans la RFC 2617 [17].
Exemple :
Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c"
20.7 Authorization
Le champ d'en-tête Authorization contient les informations d'identification d'authentification du UA. Un résumé de l'utilisation du champ d'en-tête Authorization est à la section 22.2, et la syntaxe et la sémantique lorsqu'il est utilisé pour l'authentification HTTP sont décrites à la section 22.4.
Ce champ d'en-tête, avec Proxy-Authorization, enfreint les règles générales concernant les champs d'en-tête multiples. Ce n'est pas une liste séparée par des virgules, mais ce nom de champ d'en-tête peut apparaître plusieurs fois et ne doit pas être fusionné en une seule ligne d'en-tête en utilisant les règles habituelles décrites à la section 7.3.
Dans l'exemple suivant, il n'y a pas de guillemets autour des paramètres Digest.
Authorization: Digest username="Alice", realm="atlanta.com",
nonce="84a4cc6f3082121f32b42a2187831a9e",
response="7587245234b3434cc3412213e5f113a5432"
20.8 Call-ID
Le champ d'en-tête Call-ID identifie de manière unique un invitation particulière ou toutes les inscriptions d'un client particulier. Un seule conférence multimédia peut entraîner plusieurs appels ayant des Call-ID différents, par exemple si un utilisateur invite plusieurs fois une seule personne à la même conférence (longue). Le Call-ID est sensible à la casse et est simplement comparé octet par octet.
L'abréviation du champ d'en-tête Call-ID est i.
Exemple :
Call-ID: [email protected]
i:[email protected]
20.9 Call-Info
Le champ d'en-tête Call-Info fournit des informations supplémentaires sur l'appelant ou l'appelé, selon qu'il s'agit d'une requête ou d'une réponse. L'objet de l'URI est décrit par le paramètre « purpose ». Le paramètre « icon » spécifie une image appropriée comme représentation iconique de l'appelant ou de l'appelé. Le paramètre « info » décrit l'appelant ou l'appelé de manière générale, par exemple via une page web. Le paramètre « card » fournit une carte de visite, par exemple au format vCard [36] ou LDIF [37]. Des jetons supplémentaires peuvent être enregistrés en utilisant l'IANA et les procédures de la section 27.
L'utilisation du champ d'en-tête Call-Info peut présenter un risque de sécurité. Si l'utilisateur récupère un URI fourni par un appelant malveillant, il peut être exposé à des risques tels que contenu inapproprié ou offensant, contenu dangereux ou illégal. Par conséquent, un UA ne devrait afficher les informations du champ d'en-tête Call-Info que s'il peut authentifier la provenance de l'élément ayant émis le champ d'en-tête et lui faire confiance. Ce n'a pas besoin d'être le UA pair. Un proxy peut insérer ce champ d'en-tête dans une requête.
Exemple :
Call-Info: http://wwww.example.com/alice/photo.jpg ;purpose=icon, http://www.example.com/alice/ ;purpose=info
20.10 Contact
La valeur du champ d'en-tête Contact fournit un URI dont la signification dépend du type de requête ou de réponse dans lequel il est inclus.
Une valeur de champ d'en-tête Contact peut inclure un nom d'affichage, un URI avec paramètres d'URI et des paramètres d'en-tête.
Ce document définit les paramètres Contact « q » et « expires ». Ces paramètres ne sont utilisés que lorsque Contact est présent dans une requête ou réponse REGISTER, ou dans une réponse 3xx. Des paramètres supplémentaires peuvent être définis dans d'autres spécifications.
Si la valeur du champ d'en-tête contient un nom d'affichage, l'URI incluant tous les paramètres d'URI est encadré par « < » et « > ». En l'absence de « < » et « > », tous les paramètres après l'URI sont des paramètres d'en-tête, et non des paramètres d'URI. Le nom d'affichage peut être un jeton, ou une chaîne entre guillemets si un plus grand jeu de caractères est souhaité.
Si le « display-name » est vide, la forme « name-addr » doit être utilisée si l'« addr-spec » contient une virgule, un point-virgule ou un point d'interrogation. Il peut y avoir ou non un LWS entre le nom d'affichage et « < ».
Ces règles d'analyse du nom d'affichage, de l'URI, des paramètres d'URI et des paramètres d'en-tête s'appliquent également aux champs d'en-tête To et From.
Le champ d'en-tête Contact joue un rôle similaire au champ d'en-tête Location de HTTP. Cependant, le champ d'en-tête HTTP n'autorise qu'une seule adresse sans guillemets. Les URI peuvent contenir des virgules et des points-virgules comme caractères réservés, et ils pourraient être confondus respectivement avec le séparateur d'en-tête ou de paramètre.
L'abréviation du champ d'en-tête Contact est m (pour « moved »).
Exemple :
Contact: "Mr. Watson" <sip:[email protected]>
;q=0.7; expires=3600,
"Mr. Watson" <mailto:[email protected]> ;q=0.1
m: <sips:[email protected]>;expires=60
20.11 Content-Disposition
Le champ d'en-tête Content-Disposition décrit comment le corps du message, ou dans le cas d'un message multipartie le corps du message-partie, doit être interprété par le UAC ou le UAS. Cet en-tête SIP étend le Content-Type MIME (RFC 2183 [18]).
Plusieurs nouveaux « disposition-type » de l'en-tête Content-Disposition sont définis par SIP. La valeur « session » indique que la partie du corps décrit une session, soit pour l'appel soit pour le média initial (avant l'appel). La valeur « render » indique que la partie du corps doit être affichée à l'utilisateur ou autrement rendue. La valeur « render » est utilisée au lieu de « inline » pour éviter l'implication que le corps MIME est affiché dans le cadre du rendu du message entier (car le corps MIME d'un message SIP n'est souvent pas affiché à l'utilisateur). Pour la compatibilité ascendante, si le champ d'en-tête Content-Disposition est absent, un serveur devrait supposer que le corps de type de contenu application/sdp a une disposition « session », et les autres types de contenu une disposition « render ».
Le type de disposition « icon » indique que la partie du corps contient une image appropriée comme représentation iconique de l'appelant ou de l'appelé, qui peut être rendue par l'agent utilisateur comme information lors de la réception d'un message, ou rendue en continu pendant un dialogue. La valeur « alert » indique que la partie du corps contient des informations (comme un clip audio) qui doivent être rendues par l'agent utilisateur pour avertir l'utilisateur de la réception d'une requête (généralement une requête initiant un dialogue). Ce corps d'alerte peut être rendu comme sonnerie d'un appel téléphonique, par exemple après l'envoi d'une réponse provisoire 180 Ringing.
Tout corps MIME avec un « disposition-type » rendant du contenu à l'utilisateur ne doit être traité que si le message est correctement authentifié.
Le paramètre handling (handling-param) décrit la réaction du UAS lorsqu'il reçoit un corps de message dont il ne comprend pas le type de contenu ou le type de disposition. Le paramètre a les valeurs prédéfinies « optional » et « required ». Si le paramètre handling est absent, la valeur « required » devrait être supposée. Le paramètre handling est décrit dans la RFC 3204 [19].
Si ce champ d'en-tête est absent, le type MIME détermine la disposition de contenu par défaut. En son absence, « render » est supposé.
Exemple :
Content-Disposition: session
20.12 Content-Encoding
Le champ d'en-tête Content-Encoding est utilisé comme modificateur du « media-type ». S'il est présent, sa valeur indique quel content-coding supplémentaire a été appliqué au corps d'entité, et donc quel mécanisme de décodage doit être appliqué pour obtenir le media-type référencé par le champ d'en-tête Content-Type. Content-Encoding est principalement utilisé pour permettre de compresser le corps sans perdre l'identité du media-type sous-jacent.
Si plusieurs codages sont appliqués au corps d'entité, les content-codings doivent être énumérés dans l'ordre où ils ont été appliqués.
Toutes les valeurs content-coding sont insensibles à la casse. L'IANA sert de registre pour les jetons de valeur content-coding. Voir [H3.5] pour la définition de la syntaxe de content-coding.
Un client peut appliquer un content-coding au corps dans une requête. Un serveur peut appliquer un content-coding au corps dans une réponse. Un serveur ne doit utiliser que les codages énumérés dans le champ d'en-tête Accept-Encoding de la requête.
L'abréviation du champ d'en-tête Content-Encoding est e.
Exemple :
Content-Encoding: gzip
e: tar
20.13 Content-Language
Voir [H14.12]. Exemple :
Content-Language: fr
20.14 Content-Length
Le champ d'en-tête Content-Length indique la taille du corps du message envoyé au destinataire sous forme de nombre décimal d'octets. Les applications devraient utiliser ce champ pour indiquer la taille du corps du message transmis, indépendamment du media-type de l'entité. Lorsqu'un protocole basé sur flux (comme TCP) est utilisé comme transport, le champ d'en-tête doit être utilisé.
La taille du corps du message n'inclut pas le CRLF qui sépare les champs d'en-tête du corps. Toute valeur Content-Length supérieure ou égale à zéro est une valeur valide. Si le message n'a pas de corps, la valeur du champ d'en-tête Content-Length doit être fixée à 0.
Le fait de pouvoir omettre Content-Length simplifie la création de scripts de type cgi générant dynamiquement des réponses.
L'abréviation du champ d'en-tête est l.
Exemple :
Content-Length: 349
l: 173
20.15 Content-Type
Le champ d'en-tête Content-Type indique le media-type du corps du message envoyé au destinataire. L'élément « media-type » est défini dans [H3.7]. Si le corps n'est pas vide, le champ d'en-tête Content-Type doit être présent. Si le corps est vide et que le champ d'en-tête Content-Type est présent, il indique qu'un corps d'un type particulier a une longueur nulle (par exemple un fichier audio vide).
L'abréviation du champ d'en-tête est c.
Exemple :
Content-Type: application/sdp
c: text/html; charset=ISO-8859-4
20.16 CSeq
Le champ d'en-tête CSeq contient un numéro de séquence décimal unique et la méthode de requête dans une requête. Le numéro de séquence doit pouvoir être représenté comme un entier non signé de 32 bits. La partie méthode de CSeq est sensible à la casse. Le champ d'en-tête CSeq fournit un moyen d'ordonner les transactions dans un dialogue, d'identifier de manière unique une transaction, et de distinguer une nouvelle requête d'une retransmission de requête. Deux champs d'en-tête CSeq sont considérés égaux si le numéro de séquence et la méthode de requête sont identiques. Exemple :
CSeq: 4711 INVITE
20.17 Date
Le champ d'en-tête Date contient la date et l'heure. Contrairement à HTTP/1.1, SIP ne prend en charge que les dates au format RFC 1123 [20] le plus récent. Comme [H3.3], SIP limite le fuseau horaire de SIP-date à « GMT », alors que la RFC 1123 autorise n'importe quel fuseau horaire. Les dates RFC 1123 sont sensibles à la casse.
Le champ d'en-tête Date reflète l'heure à laquelle la requête ou la réponse a été envoyée à l'origine.
Le champ d'en-tête Date peut être utilisé par un système terminal simple sans horloge sauvegardée pour obtenir un concept d'heure actuelle. Cependant, avec le format GMT, le client doit connaître son décalage par rapport à GMT.
Exemple :
Date: Sat, 13 Nov 2010 23:29:00 GMT
20.18 Error-Info
Le champ d'en-tête Error-Info fournit un pointeur vers des informations supplémentaires sur une réponse d'état d'erreur.
Les fonctionnalités d'interface utilisateur des UAC SIP vont d'une fenêtre contextuelle et d'un son sur un client logiciel PC, à un son uniquement sur un téléphone « noir » ou un point de terminaison connecté via une passerelle. Au lieu de forcer le serveur générant l'erreur à envoyer un code d'état d'erreur avec une phrase de raison détaillée et à lire un enregistrement audio, le champ d'en-tête Error-Info permet d'envoyer les deux. Le UAC peut ensuite choisir l'indicateur d'erreur à rendre à l'appelant.
Un UAC peut traiter un URI SIP ou SIPS dans le champ d'en-tête Error-Info comme s'il s'agissait d'un Contact dans une redirection, et générer un nouvel INVITE, aboutissant à l'établissement d'une session d'annonce enregistrée. Un URI non SIP peut être rendu à l'utilisateur.
Exemple :
SIP/2.0 404 The number you have dialed is not in service
Error-Info: <sip:[email protected]>
20.19 Expires
Le champ d'en-tête Expires donne le temps relatif après lequel le message (ou le contenu) expire.
Le sens précis de ceci dépend de la méthode.
L'expiration dans un INVITE n'affecte pas la durée de la session réelle qui pourrait résulter de l'invitation. Cependant, le protocole de description de session peut fournir la possibilité d'exprimer une limite de temps sur la durée de session.
La valeur de ce champ est un nombre entier de secondes (décimal) compris entre 0 et (2**32)-1, mesuré à partir de la réception de la requête.
Exemple :
Expires: 5
20.20 From
Le champ d'en-tête From indique l'initiateur de la requête. Cela peut différer du initiateur du dialogue. Une requête envoyée par l'appelé à l'appelant utilise l'adresse de l'appelé dans le champ d'en-tête From.
Le « display-name » optionnel est destiné à être rendu par l'interface utilisateur humaine. Si les informations d'identification du client sont masquées, le système doit utiliser le nom d'affichage « Anonymous ». Si le « display-name » est vide, la forme « name-addr » doit être utilisée si l'« addr-spec » contient une virgule, un point d'interrogation ou un point-virgule. Les problèmes de syntaxe sont discutés à la section 7.3.1.
Deux champs d'en-tête From sont équivalents si leurs URI correspondent et si leurs paramètres correspondent. Un paramètre d'extension présent dans l'un des champs d'en-tête mais pas dans l'autre est ignoré aux fins de comparaison. Cela signifie que la présence ou l'absence du nom d'affichage et des crochets angulaires n'affecte pas la correspondance.
Voir la section 20.10 pour les règles d'analyse du nom d'affichage, de l'URI, des paramètres d'URI et des paramètres de champ d'en-tête.
L'abréviation du champ d'en-tête From est f.
Exemple :
From: "A. G. Bell" <sip:[email protected]> ;tag=a48s
From: sip:[email protected];tag=887s
f: Anonymous <sip:[email protected]>;tag=hyh8
20.21 In-Reply-To
Le champ d'en-tête In-Reply-To énumère les Call-ID auxquels cet appel fait référence ou répond. Ces Call-ID peuvent avoir été mis en cache par le client et inclus dans le champ d'en-tête de cet appel de retour.
Cela permet à un système de distribution d'appels automatisé de router un appel de retour vers l'appelant de l'appel initial. Cela permet également à l'appelé de filtrer les appels, en n'acceptant que les retours d'appels qu'il a émis. Ce champ n'est pas un substitut à l'authentification de requête.
Exemple :
In-Reply-To: [email protected], [email protected]
20.22 Max-Forwards
Le champ d'en-tête Max-Forwards est utilisé avec toute méthode SIP et doit limiter le nombre de proxies ou de passerelles via lesquels la requête peut être transmise au serveur en aval suivant. Il est également utile lorsqu'un client tente de suivre une chaîne de requêtes qui semble avoir échoué ou bouclé en cours de route.
La valeur Max-Forwards est un entier compris entre 0 et 255 indiquant le nombre de fois restant que ce message de requête peut être transmis. Ce compteur est décrémenté par chaque serveur transmettant la requête. La valeur initiale recommandée est 70.
Ce champ d'en-tête doit être inséré par un élément qui ne peut pas garantir la détection de boucle par ailleurs. Par exemple, un B2BUA doit insérer le champ d'en-tête Max-Forwards.
Exemple :
Max-Forwards: 6
20.23 Min-Expires
Le champ d'en-tête Min-Expires transmet l'intervalle de mise à jour minimum pris en charge pour les éléments d'état logiciel gérés par ce serveur. Cela inclut les champs d'en-tête Contact stockés par un registraire. Le champ d'en-tête contient un nombre entier décimal de secondes compris entre 0 et (2**32)-1. L'utilisation du champ d'en-tête dans une réponse 423 (Interval Too Brief) est décrite aux sections 10.2.8, 10.3 et 21.4.17.
Exemple :
Min-Expires: 60
20.24 MIME-Version
Voir [H19.4.1].
Exemple :
MIME-Version: 1.0
20.25 Organization
Le champ d'en-tête Organization transmet le nom de l'organisation à laquelle appartient l'élément SIP émettant la requête ou la réponse.
Ce champ peut être utilisé par le logiciel client pour filtrer les appels.
Exemple :
Organization: Boxes by Bob
20.26 Priority
Le champ d'en-tête Priority indique l'urgence de la requête telle que reconnue par le client. Le champ d'en-tête Priority décrit la priorité que la requête SIP devrait avoir pour la personne recevant ou son agent. Par exemple, il peut être intégré dans le routage et les décisions d'acceptation d'appel. Dans ces décisions, un message sans champ d'en-tête Priority doit être traité comme s'il spécifiait la priorité « normal ». Le champ d'en-tête Priority n'affecte pas l'utilisation des ressources de communication telles que la priorité de transfert de paquets dans un routeur ou l'accès au circuit dans une passerelle PSTN. Le champ d'en-tête peut prendre les valeurs « non-urgent », « normal », « urgent » et « emergency », bien que des valeurs supplémentaires puissent être définies ailleurs. La valeur « emergency » est recommandée uniquement lorsque la vie, l'intégrité physique ou les biens sont en danger immédiat. Sinon, aucune sémantique n'est définie pour ce champ d'en-tête.
Ce sont les valeurs de la RFC 2076 [38] avec l'ajout d'« emergency ».
Exemple :
Subject: A tornado is heading our way!
Priority: emergency
Ou
Subject: Weekend plans
Priority: non-urgent
20.27 Proxy-Authenticate
La valeur du champ d'en-tête Proxy-Authenticate contient un défi d'authentification.
L'utilisation de ce champ d'en-tête est définie dans [H14.33]. Voir la section 22.3 pour plus de détails sur son utilisation.
Exemple :
Proxy-Authenticate: Digest realm="atlanta.com",
domain="sip:ss1.carrier.com", qop="auth",
nonce="f84f1cec41e6cbe5aea9c8e88d359",
opaque="", stale=FALSE, algorithm=MD5
20.28 Proxy-Authorization
Le champ d'en-tête Proxy-Authorization permet à un client de s'identifier auprès d'un proxy qui demande l'authentification du client. La valeur du champ Proxy-Authorization consiste en des informations d'identification contenant les informations d'authentification de l'agent utilisateur pour le proxy et/ou le realm de la ressource demandée.
Voir la section 22.3 pour la définition de l'utilisation de ce champ d'en-tête.
Ce champ d'en-tête, avec Authorization, enfreint les règles générales concernant les noms de champs d'en-tête multiples. Ce n'est pas une liste séparée par des virgules, mais ce nom de champ d'en-tête peut apparaître plusieurs fois et ne doit pas être fusionné en une seule ligne d'en-tête en utilisant les règles habituelles décrites à la section 7.3.1.
Exemple :
Proxy-Authorization: Digest username="Alice", realm="atlanta.com", nonce="c60f3082ee1212b402a21831ae", response="245f23415f11432b3434341c022"
20.29 Proxy-Require
Le champ d'en-tête Proxy-Require est utilisé par un UAC pour spécifier les fonctionnalités qu'un proxy doit prendre en charge pour traiter cette requête. Le champ d'en-tête Require (section 20.32) est utilisé pour spécifier les fonctionnalités prises en charge à la fois par le UAC et le UAS.
Comme le champ d'en-tête Require, si le champ d'en-tête Proxy-Require contient une fonctionnalité non prise en charge, le proxy doit renvoyer une réponse 420 (Bad Extension) et lister les fonctionnalités non prises en charge dans le champ d'en-tête Unsupported. Ce champ d'en-tête ne doit pas être utilisé dans une requête susceptible d'être envoyée à l'extérieur d'une chaîne de proxies de confiance. Ce champ d'en-tête existe spécifiquement pour informer un proxy de la fonctionnalité dont il a besoin pour traiter la requête, afin que la fonctionnalité fonctionne correctement si le proxy la prend en charge, plutôt que pour forcer le proxy à implémenter la fonctionnalité.
Exemple :
Proxy-Require: foo
20.30 Record-Route
Le champ d'en-tête Record-Route est utilisé par un proxy pour se placer dans une requête et forcer le passage des requêtes ultérieures dans le dialogue via ce proxy.
Le champ d'en-tête Record-Route ne contribue pas à l'ID de dialogue (section 12). Cependant, les URI inclus dans le champ d'en-tête Record-Route sont utilisés pour établir l'ensemble de routes sur lequel les requêtes ultérieures dans le dialogue sont envoyées.
Un UA n'est pas autorisé à supprimer des éléments de l'un des URI du champ d'en-tête Record-Route, ou des URI apparaissant dans le champ d'en-tête Route. Le champ d'en-tête Record-Route peut être ajouté par un proxy traitant la requête, et peut pointer vers d'autres proxies basés sur les décisions de routage discutées à l'élément 5 de la section 16.6. Les URI ne contenant pas le paramètre pp (section 19.1.1) devraient inclure le paramètre lr pour la compatibilité de routage avec les éléments RFC 2543.
Voir la section 12 pour plus de détails sur la façon dont le champ d'en-tête Record-Route est utilisé pour router les requêtes dans un dialogue.
Exemple :
Record-Route: <sip:server10.biloxi.com;lr>,
<sip:bigbox3.site3.atlanta.com;lr>
20.31 Reply-To
Le champ d'en-tête Reply-To, lorsqu'il est inclus dans un message de requête, contient un URI SIP ou SIPS vers lequel envoyer une réponse à la méthode demandée (par exemple INVITE). Si cet URI est absent, la réponse est envoyée à l'adresse fournie par le champ d'en-tête From ou Contact. Dans certains cas, l'appel est initié à partir d'une adresse différente de l'adresse à laquelle répondre. Ce champ d'en-tête permet de spécifier l'adresse de réponse indépendamment de l'adresse de destination.
Ce champ peut être utilisé pour router une réponse entre plusieurs adresses du destinataire. Par exemple, le destinataire peut souhaiter que l'appel arrive sur un téléphone SIP de travail, mais que la réponse soit envoyée à un téléphone portable.
Exemple :
Reply-To: <sip:[email protected]>
20.32 Require
Le champ d'en-tête Require est utilisé par un UAC pour spécifier les fonctionnalités que le UAS (et les proxies) doivent prendre en charge pour traiter la requête. Si un proxy ou un UAS ne peut pas comprendre une fonctionnalité répertoriée dans le champ d'en-tête Require d'une requête reçue, cet élément doit renvoyer une réponse 420 (Bad Extension) (section 20.40) contenant les fonctionnalités non prises en charge dans le champ d'en-tête Unsupported.
Par contraste, les fonctionnalités non répertoriées dans le champ d'en-tête Require auraient pu être traitées de manière appropriée par le UAS si la fonctionnalité n'était pas essentielle à la sémantique de la requête.
Une fonctionnalité peut apparaître sous la forme d'un format de message SIP, ou d'un media-type dans la description de session, ou d'un paramètre, ou d'une autre fonctionnalité. Les balises d'option du champ d'en-tête Require font référence à plusieurs fonctionnalités balisées, comme décrit à la section 19.2. Certaines fonctionnalités sont limitées aux proxies (par exemple « re-route »). Elles sont spécifiées à l'aide du champ d'en-tête Proxy-Require (section 20.29).
Si le champ d'en-tête Require est inclus dans un message de requête, il doit être copié dans le message de réponse.
Les implémentations de cette spécification doivent faire très attention à générer correctement le champ d'en-tête Require.
Le champ d'en-tête Require entraîne de nombreuses situations où les implémentations souhaitent communiquer mais prennent en charge des extensions contradictoires. La négociation d'extension correctement implémentée est difficile. Placer une fonctionnalité prise en charge par le UA dans le champ d'en-tête Require fait que l'homologue qui ne la prend pas en charge rejette la requête. Par conséquent, le champ d'en-tête Require ne doit être utilisé que pour les fonctionnalités que le UA croit raisonnablement être prises en charge. Toutes les autres fonctionnalités doivent être spécifiées dans le champ d'en-tête Supported. Les balises d'option disponibles pour le champ d'en-tête Require ne sont définies que dans des RFC de suivi standard. Cela permet de s'assurer que seules quelques fonctionnalités standardisées (et en particulier celles affectant à la fois le UAS et le UAC) obtiennent une balise d'option. Le processus d'examen rigoureux des balises d'option empêche le champ d'en-tête Require d'être facile à utiliser et répandu.
Exemple :
Require: 100rel
20.33 Retry-After
Le champ d'en-tête Retry-After permet à un serveur d'indiquer la période après laquelle un client peut réessayer sa requête. Il peut contenir un nombre de secondes relatif à l'heure actuelle, ou éventuellement une valeur de date SIP. Lorsqu'il est présent dans une réponse rejetant la requête (par exemple 500, 503 ou 600), la valeur indique la période après laquelle le serveur acceptera ou pourra tenter l'appel. Lorsqu'il est présent dans une réponse 503 (Service Unavailable), ce champ d'en-tête indique l'heure à laquelle la surcharge survenue devrait se terminer.
Si la valeur retry-after est supérieure à 0, le client doit attendre cette période avant de réessayer la requête. Si cette valeur est 0, le client peut réessayer la requête immédiatement.
Le paramètre optionnel « comment » contient un texte lisible par l'homme. Le paramètre optionnel « duration » représente la période (en secondes) pendant laquelle un appel ne doit pas être tenté, même après que le serveur a déterminé qu'il peut tenter l'appel.
Exemple :
Retry-After: 18000;duration=3600
Retry-After: 120;duration=3600
20.34 Route
Le champ d'en-tête Route existe pour forcer un flux préféré que le UAC utilise pour router la session. Un proxy est également responsable de satisfaire l'ensemble de routes dans une requête reçue. Voir la section 8.1.1.1.
Exemple :
Route: <sip:bigbox3.site3.atlanta.com;lr>,
<sip:server10.biloxi.com;lr>
20.35 Server
Le champ d'en-tête Server contient des informations sur le serveur traitant la réponse et peut inclure des informations sur le logiciel d'agent utilisateur serveur. Comme le champ d'en-tête HTTP similaire, ce champ d'en-tête peut être omis pour des raisons de sécurité.
L'utilisation du champ d'en-tête Server suit les mêmes règles que celles définies dans [H14.38] pour HTTP/1.1.
Exemple :
Server: HomeServer v2
20.36 Subject
Le champ d'en-tête Subject fournit une courte description de la nature ou du sujet de l'appel.
L'utilisation de la ligne « Subject » par l'agent utilisateur a la même sémantique que celle définie dans la RFC 822 [39].
Exemple :
Subject: Need more boxes
20.37 Supported
Le champ d'en-tête Supported énumère l'ensemble des fonctionnalités prises en charge par le UAC ou le UAS. Dans de nombreux cas, les fonctionnalités sont répertoriées comme balises d'option (section 19.2).
Si le champ d'en-tête Supported est envoyé par un UAC, le UAS peut répondre au UAC avec les fonctionnalités prises en charge dans le champ d'en-tête Supported.
Si le champ d'en-tête Supported est envoyé par un UAS, le UAC peut l'ignorer.
Require et Supported peuvent tous deux être inclus dans une réponse 2xx.
Si le champ d'en-tête Supported est inclus dans un message de requête, il doit être copié dans le message de réponse.
Les implémentations de cette spécification doivent faire très attention à générer correctement le champ d'en-tête Supported.
Comme expliqué dans la discussion du champ d'en-tête Require, un UA ne doit placer sur le champ d'en-tête Require que des fonctionnalités identifiées par des balises d'option standardisées. Tenter d'utiliser le champ d'en-tête Require pour forcer des extensions non standardisées ou propres à une entreprise peut réduire l'interopérabilité. Par conséquent, toutes les options prises en charge doivent être répertoriées dans le champ d'en-tête Supported. Les balises d'option disponibles pour le champ d'en-tête Require ne sont définies que dans des RFC de suivi standard. Cela permet de s'assurer que seules quelques fonctionnalités standardisées (et en particulier celles affectant à la fois le UAS et le UAC) obtiennent une balise d'option. Le processus d'examen rigoureux des balises d'option empêche le champ d'en-tête Require d'être facile à utiliser et répandu.
Exemple :
Supported: 100rel
20.38 Timestamp
Le champ d'en-tête Timestamp reflète l'heure à laquelle la requête du UAC a été générée. Le client peut utiliser l'heure renvoyée au serveur pour calculer le temps d'attente d'une réponse.
Exemple :
Timestamp: 54
20.39 To
Le champ d'en-tête To spécifie la seconde partie (ou la ressource logiquement adressée) à laquelle la requête a été initialement adressée. Ce champ d'en-tête spécifie généralement l'utilisateur ou la ressource invité après que le UAS a accepté la requête.
Le champ d'en-tête To doit être inclus dans tous les messages SIP dans les requêtes et les réponses.
Lorsque le champ d'en-tête To est généré par un UAS, le UAS doit ajouter un paramètre « tag » au champ d'en-tête To pour servir de partie de l'ID de dialogue.
Un UAS peut ajouter une balise au champ d'en-tête To même s'il rejette la requête pour une raison quelconque.
Voir la section 19.3 pour plus de détails sur la génération de balises.
Deux champs d'en-tête To sont équivalents si leurs URI correspondent et si leurs paramètres correspondent. Un paramètre d'extension présent dans l'un des champs d'en-tête mais pas dans l'autre est ignoré aux fins de comparaison. Cela signifie que la présence ou l'absence du nom d'affichage et des crochets angulaires n'affecte pas la correspondance.
Voir la section 20.10 pour les règles d'analyse du nom d'affichage, de l'URI, des paramètres d'URI et des paramètres de champ d'en-tête.
L'abréviation du champ d'en-tête To est t.
Exemple :
To: "A. G. Bell" <sip:[email protected]>;tag=a6c85cf
20.40 Unsupported
Le champ d'en-tête Unsupported énumère les fonctionnalités non prises en charge par le serveur. Ce champ d'en-tête est généré lorsqu'un serveur rejette une requête contenant le champ d'en-tête Require (section 20.32).
Exemple :
Unsupported: foo
20.41 User-Agent
Le champ d'en-tête User-Agent contient des informations sur l'agent utilisateur initiant la requête. Comme le champ d'en-tête HTTP similaire, ce champ d'en-tête peut être omis pour des raisons de sécurité.
Exemple :
User-Agent: Softphone Release 1.0
20.42 Via
Le champ d'en-tête Via indique le protocole de transport utilisé pour envoyer la requête, et les adresses des agents (proxys, redirecteurs et agents utilisateurs) qui l'ont transportée dans l'ordre où la requête a atteint le réseau. Les champs d'en-tête Via dans les requêtes et les réponses suivent la route que la requête a empruntée et empêchent les boucles d'envoi de réponse.
Le champ d'en-tête Via répertorie le protocole utilisé par l'application pour envoyer la requête et ne doit pas être confondu avec le protocole de transport utilisé pour transférer des messages entre applications. Par exemple, un message SIP peut être transféré entre applications sur UDP, mais l'application SIP utilise SIP/2.0/TCP pour indiquer le protocole utilisé pour envoyer le message sur TCP.
L'adresse répertoriée dans le cadre du champ d'en-tête Via est l'adresse où la réponse est envoyée. Le lieu responsable (généralement l'élément en amont le plus proche) peut ajouter un paramètre « received » au champ d'en-tête Via reçu pour aider le proxy à déterminer d'où il doit recevoir la réponse.
Voir les sections 18.2.1 et 18.2.2 pour plus de détails sur les paramètres « received » et « rport » du champ d'en-tête Via, respectivement.
Un UA ou un proxy générant une réponse inclut une valeur de champ d'en-tête Via répertoriant le protocole utilisé pour générer le message. Cette valeur ne doit pas être confondue avec le protocole utilisé pour envoyer la réponse. Comme pour la requête, la valeur du champ d'en-tête Via peut traverser plusieurs éléments (par exemple, si la réponse est renvoyée via une chaîne de proxys).
Une valeur de champ d'en-tête Via contient le protocole utilisé pour envoyer la requête, un identifiant de branche et l'adresse de l'application d'envoi. Le paramètre de branche est utilisé pour identifier la transaction. L'élément en amont le plus proche (et éventuellement le proxy) peut inclure un paramètre « received » qu'il ajoute pour router la réponse. La valeur du paramètre de branche est choisie par l'élément, mais doit satisfaire aux exigences suivantes. Cela permet à l'application de distinguer la requête, le transport utilisé pour envoyer la requête, et l'adresse (partiellement insensible à la casse) de l'instance de transport utilisée pour envoyer la requête.
o La valeur du paramètre de branche doit contenir le nom d'hôte ou les informations d'identification de l'élément.
o La valeur du paramètre de branche peut être modifiée pour refléter la création ou la modification de parties de la requête d'un message qui sont modifiées sans modifier l'adresse, le port et le protocole de transport de l'élément.
Voir la section 17 pour plus de détails sur le paramètre « branch ».
L'abréviation de ce champ d'en-tête est V.
Exemple :
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776sgdkse
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK77ef4z