Groupe de travail Réseau	H. Schulzrinne, Columbia University	
Request for Comments : 3326	D. Oran, Cisco	
Catégorie : En cours de normalisation	G. Camarillo, Ericsson	
Traduction Claude Brière de L’Isle	décembre 2002	

Champ d’en-tête Reason pour le protocole d’initialisation de session (SIP)

Statut de ce mémoire
Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de copyright
Copyright (C) The Internet Society (2002). Tous droits réservés

Résumé
Pour créer des services, il est souvent utile de savoir pourquoi une demande du protocole d’initialisation de session (SIP) a été produite. Le présent document définit un champ d’en-tête, Reason, qui fournit ces informations. Le champ d’en-tête Reason est aussi destiné à être utilisé pour encapsuler un code d’état final dans une réponse provisoire. Cette fonctionnalité est nécessaire pour résoudre le "problème du fourchement de réponse d’erreur hétérogène" (HERFP, Heterogeneous Error Response Forking Problem).

Table des matières
1. Introduction	1
1.1 Terminologie	2
2. Champ d’en-tête Reason	2
3. Exemples	3
3.1 Appel achevé ailleurs	3
3.2 Refus d’une offre qui vient dans une réponse	3
3.3 Contrôle d’appel par un tiers	3
3.4 Inter fonctionnement ISUP	3
4. Considérations relatives à l’IANA	4
5. Considérations pour la sécurité	4
6. Remerciements	4
8. Références normatives	4
7. Adresse des auteurs	5
8. Déclaration complète de droits de reproduction	5

1.	Introduction

La même demande SIP [RFC3261] peut être produite pour diverses raisons. Par exemple, une demande SIP CANCEL peut être produite si l’appel s’est terminé sur une autre branche ou a été abandonnée avant réponse. Bien que le protocole et le comportement du système soient les mêmes dans les deux cas, à savoir, l’arrêt des alertes, l’interface d’utilisateur peut fort bien être différente. Dans le second cas, l’appel peut être enregistré comme appel manqué, alors que ce ne serait pas approprié si l’appel a été pris ailleurs.

Les contrôleurs d’appel tiers génèrent parfois une demande SIP à réception d’une réponse SIP provenant d’un autre dialogue. Les passerelles génèrent des demandes SIP après avoir reçu des messages provenant d’un autre protocole que SIP. Dans les deux cas, le client peut être intéressé à savoir ce qui a déclanché la demande SIP.

Les réponses SIP offrent déjà un moyen pour informer l’usager des raisons pour lesquelles une demande a échoué. Le mécanisme simple du présent document accomplit quelque chose d’à peu près similaire pour les demandes.

Un INVITE peut parfois être rejeté non pas parce que l’initialisation de session a été déclinée, mais parce que un certain aspect de la demande n’était pas acceptable. Si le INVITE a été fourché et a résulté en un rejet, la réponse d’erreur peut ne jamais être transmise au client sauf si toutes les autres branches rejettent aussi la demande. Ce problème est connu sous le nom de "problème du fourchement de réponse d’erreur hétérogène" (HERFP, Heterogeneous Error Response Forking Problem). On prévoit qu’une solution à ce problème pourrait impliquer d’encapsuler la réponse d’erreur finale dans une réponse provisoire. Le champ d’en-tête Reason est un candidat pour une telle encapsulation.

Initialement, le champ d’en-tête Reason défini ici apparaît des plus utiles pour les demandes BYE et CANCEL, mais il peut apparaître dans toute demande au sein d’un dialogue, dans toute demande CANCEL et dans toute réponse dont le code d’état permet explicitement la présence de ce champ d’en-tête.

Noter que le champ d’en-tête Reason n’est habituellement pas nécessaire dans les réponses parce que le code d’état et la phrase de cause donnent déjà des informations suffisantes.

Les clients et serveurs sont libres d’ignorer ce champ d’en-tête. Il n’a pas d’impact sur le traitement du protocole.

1.1	Terminologie

Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans le BCP 14, [RFC2119] et[ indiquent les niveaux d’exigence pour les mises en œuvre conformes à SIP.

2.	Champ d’en-tête Reason

Le champ d’en-tête Reason PEUT apparaître dans toute demande au sein d’un dialogue, dans toute demande CANCEL et dans toute réponse dont le code d’état permet explicitement la présence de ce champ d’en-tête. La syntaxe du champ d’en-tête suit la syntaxe standard de paramètre SIP.

Reason 	=  "Reason" HCOLON valeur-de-reason *(COMMA valeur-de-reason)
valeur-de-reason	=  protocole *(SEMI paramètre-de-reason)
protocole	=  "SIP" / "Q.850" / jeton
paramètre-de-reason	=  cause-de-protocole / texte-de-reason / extension-de-reason
cause-de-protocole	=  "cause" EQUAL cause
cause	=  1*CHIFFRE
texte-de-reason	=  "texte" EQUAL chaîne-entre-guillemets
extension-de-reason	=  paramètre-générique

Les valeurs suivantes ont été définies pour le champ protocole :

SIP : Le paramètre cause contient un code d’état SIP.
Q.850 : Le paramètre cause contient une valeur de cause UIT-T Q.850 en représentation décimale.

Exemples :
Reason: SIP ;cause=200 ;text="Appel terminé ailleurs"
Reason: Q.850 ;cause=16 ;text="Terminé"
Reason: SIP ;cause=600 ;text="Occupé partout"
Reason: SIP ;cause=580 ;text="Précondition d’échec"

Les mandataires qui génèrent une demande CANCEL à réception d’un CANCEL provenant du bond précédent qui contient un champ d’en-tête Reason DEVRAIENT le copier dans la nouvelle demande CANCEL.

En fonctionnement SIP normal, un code d’état SIP dans une réponse donne au client des informations sur la demande qui a déclanché la réponse, les paramètres de session, ou l’utilisateur. Par exemple, une réponse 405 (Méthode non admise) indique que la demande contenait une méthode non prise en charge. Un 488 (Non acceptable ici) indique que les paramètres de la session ne sont pas acceptables et un 486 (Occupé ici) donne des informations sur l’état de l’usager.

Tout code d‘état SIP PEUT apparaître dans le champ d’en-tête Reason d’une demande. Cependant, les codes d’état qui donnent des informations sur l’utilisateur et sur les paramètres de session sont normalement utiles pour mettre en œuvre des services tandis que les codes d’état destinés à rapporter des erreurs au sujet d’une demande sont normalement utiles pour des besoins de débogage.

Un message SIP PEUT contenir plus d’une valeur de Reason (c’est-à-dire, plusieurs lignes Reason) mais toutes DOIVENT avoir des valeurs de protocole différentes (par exemple, une SIP et l’autre Q.850). Une mise en œuvre est libre d’ignorer les valeurs de Reason qu’elle ne comprend pas.

3.	Exemples

Cette section contient un certain nombre d’exemples qui illustrent l’utilisation du champ d’en-tête Reason.

3.1	Appel achevé ailleurs
Un mandataire fourche une demande INVITE et une des branches retourne un 200 (OK). Le mandataire fourcheur inclut ce code d’état dans un champ d’en-tête Reason dans la demande CANCEL qu’il envoie au reste des branches.

3.2	Refus d’une offre qui vient dans une réponse
Un client envoie une INVITE vide et reçoit une offre inacceptable dans une réponse 200 (OK). Le client envoie un ACK avec une réponse correctement formatée et envoie immédiatement un BYE pour terminer la session. Le client inclut un code d’état 488 (Non acceptable ici) dans un champ d’en-tête Reason.

3.3	Contrôle d’appel par un tiers
Le contrôleur d’appel tiers de la Figure 1 essaye d’établir une session entre A et B. Cependant, l’usager B est occupé. Le contrôleur envoie un BYE avec le code d’état 486 (Occupé ici) dans un champ d’en-tête Reason.

      A                Contrôleur            B
      |   INV  no SDP     |                  |
      |<------------------|                  |
      |                   |                  |
      |    200 SDP A1     |                  |
      |-----------------> |                  |
      |                   |                  |
      |   ACK  SDP tenu   |                  |
      |<------------------|                  |
      |                   |                  |
      |                   |   INV no SDP     |
      |                   |----------------->|
      |                   |                  |
      |                   |  486 Occupé ici  |
      |                   |<-----------------|
      |                   |                  |
      |                   |       ACK        |
      |                   |----------------->|
      |     BYE (486)     |                  |
      |<------------------|                  |
      |                   |                  |
      |     200 OK        |                  |
      |-----------------> |                  |
      |                   |                  |

Figure 1 : Contrôle d’appel par un tiers

3.4	Inter fonctionnement ISUP
La passerelle RTPC de la Figure 2 génère une INVITE qui doit être annulée par CANCEL lorsque un message REL (libération) est reçu du côté ISUP. La demande CANCEL contient la valeur de cause Q.850 (16 Libération d’appel normale) du message REL.

      A               Passerelle             B
      |       IAM         |                  |
      |-----------------> |                  |
      |                   |     INVITE       |
      |                   |----------------->|
      |                   |                  |
      |                   |   100 Essai      |
      |                   |<-----------------|
      |     REL (16)      |                  |
      |-----------------> |                  |
      |                   | CANCEL (Q.850 16)|
      |                   |----------------->|
      |                   |      200 OK      |
      |                   |<-----------------|

Figure 2 : inter fonctionnement ISUP

4.	Considérations relatives à l’IANA

Le présent document définit un nouveau champ d’en-tête SIP, "Reason", selon la Section 27 de la [RFC3261].

Les valeurs de protocole (et leur cause de protocole associée) à utiliser avec ce champ d’en-tête sont enregistrées par l’IANA dans un nouveau sous-registre sous http://www.iana.org/assignments/sip-parameters, étiqueté "Reason Protocols".  Les protocoles Reason DOIVENT  se référer à un numéro de Recommandation UIT-T, à un nom de protocole de l’IETF, ou à l’identifiant de protocole reconnu par une autre organisation de normalisation. La cause de protocole décrit la source du champ 'cause' dans le champ d’en-tête Reason.

Les seules entrées dans le registré sont pour l’instant :

Valeur du Protocole	Cause du protocole	Référence	
SIP	Code d’état	RFC 3261	
Q.850	Valeur de cause en représentation décimale	UIT-T Q.850	

5.	Considérations pour la sécurité

Falsifier ou retirer le champ d’en-tête Reason d’une réponse dans un scénario HERFP peut rendre impossible à un client de mettre correctement à jour sa demande précédente, rendant don impossible d’établissement de la session. Donc, il est RECOMMANDÉ que ce champ d’en-tête soit protégé par un mécanisme d’intégrité convenable.

6.	Remerciements

Jonathan Rosenberg, Rohan Mahy et Vijay K. Gurbani ont fourni des commentaires et suggestions utiles.

8.	Références normatives

[RFC3261]	J. Rosenberg et autres, "SIP : Protocole d'initialisation de session", juin 2002. (Mise à jour par RFC3265, RFC3853, RFC4320, RFC4916, RFC5393, RFC6665)

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

7.	Adresse des auteurs

Henning Schulzrinne	David R. Oran	Gonzalo Camarillo	
Dept. of Computer Science	Cisco Systems, Inc.	Ericsson	
Columbia University	Acton, MA	Advanced Signalling Research Lab.	
1214 Amsterdam Avenue	USA	FIN-02420 Jorvas	
New York, NY 10027	mél :  oran@cisco.com 	Finland	
USA		mél : Gonzalo.Camarillo@ericsson.com 	
mél :  schulzrinne@cs.columbia.edu 			

8.	Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2003). Tous droits réservés.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.

Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.