Groupe de travail Réseau	G. Camarillo, Ericsson	
Request for Comments : 4032	P. Kyzivat, Cisco Systems	
RFC mise à jour : 3312	mars 2005	
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle	

Mise à jour du cadre de préconditions du 
protocole d'initialisation de session (SIP)

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de droits de reproduction
Copyright (C) The Internet Society (2005).

Résumé
Le présent document met à jour la RFC 3312, qui définit le cadre pour les préconditions dans SIP. On donne des lignes directrices pour les auteurs de nouveaux types de précondition et on décrit comment utiliser les préconditions SIP dans les situations qui impliquent la mobilité de session.
Table des matières
1. Introduction	1
2. Terminologie	2
3. Définition de nouveaux types de précondition	2
3.1 Étiquette de type de précondition	2
3.2 Type d'état	2
3.3 Force de précondition	2
3.4 Suspension et reprise d'établissement de session	2
4. Questions relatives à la mobilité de session	3
4.1 Mise à jour à la RFC 3312	4
4.2 État désiré	4
5. Considérations sur la sécurité	5
6. Considérations relatives à l'IANA	5
7. Remerciements	5
8. Références	5
8.1 Références normatives	5
8.2 Références pour information	5
Adresse des auteurs	6
Déclaration complète de droits de reproduction	6
 	1.	Introduction

La [RFC3312] définit le cadre pour les préconditions de SIP [RFC3261], qui est un cadre générique permettant aux agents d'utilisateur (UA, User Agent) de SIP de suspendre l'établissement d'une session jusqu'à ce qu'un ensemble de préconditions soient satisfaites. Bien que seules des préconditions de qualité de service (QS, Quality of Service) aient été définies jusqu'à présent, ce cadre prend en charge différents types de préconditions. (Les préconditions de QS sont définies aussi par la RFC  3312).

Le présent document met à jour la RFC 3312, fournit des lignes directrices pour les auteurs de nouveaux types de précondition et explique de quels sujets ils ont besoin de discuter quand ils les définissent. De plus, il met à jour certaines des procédures de la RFC 3312 pour utiliser les préconditions SIP dans les situations qui impliquent la mobilité de session comme décrit ci-dessous.

La RFC 3312 se concentre sur les sessions de supports qui ne bougent pas. C'est-à-dire, le support est envoyé entre les mêmes points d'extrémité pendant toute la durée de la session. Néanmoins, les sessions de supports établies par SIP ne sont pas toujours statiques.

SIP offre des mécanismes pour assurer la mobilité de session, à savoir les re-INVITE et les UPDATE [RFC3311]. Alors que les mises en œuvre existantes de la RFC 3312 peuvent probablement traiter la mobilité de session, il est nécessaire de pointer explicitement les questions impliquées et de faire une petite mise à jour sur certaines des procédures qui y sont définies. Avec les procédures mises à jour définies dans ce document, les messages qui portent des informations de préconditions deviennent plus explicites sur l'état actuel des préconditions.

Spécifiquement, on permet maintenant que les réponses dégradent les valeurs d'état actuel (c'était interdit par la RFC 3312).  On considère le déplacement d'un flux existant à une nouvelle localisation comme équivalent à l'établissement d'un nouveau flux. Donc, les réponses qui déplacent les flux à de nouvelles localisations règlent toutes les valeur d'état courantes dans leurs réponses à "Non" et commencent une nouvelle négociation de précondition.

 	2.	Terminologie

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans la [RFC2119] et indiquent les niveaux d’exigence pour les mises en œuvre conformes.

 	3.	Définition de nouveaux types de précondition

Les spécifications qui définissent de nouveaux types de précondition ont besoin de discuter les questions décrites dans cette section. Avoir de claires définitions des nouveaux types de précondition est essentiel pour assurer l'interopérabilité entre les différentes mises en œuvre.

 	3.1	Étiquette de type de précondition
Les nouveaux types de précondition DOIVENT avoir une étiquette de type de précondition associée (par exemple, "qos" est l'étiquette pour les préconditions de QS). Les auteurs de nouvelles préconditions DOIVENT enregistrer les nouveaux types de précondition et leurs étiquettes auprès de l'IANA en suivant les instructions de la Section 15 de la RFC 3312.

 	3.2	Type d'état
La RFC 3312 définit deux types d'état : de bout en bout et segmenté. Les spécifications qui définissent de nouveaux types de précondition DOIVENT indiquer quel état s'applique à la nouvelle précondition. Les nouvelles préconditions peuvent utiliser seulement un type d'état ou les deux. Par exemple, les préconditions de QS définies dans la RFC 3312 peuvent utiliser les deux.

 	3.3	Force de précondition
La RFC 3312 définit des préconditions facultatives et obligatoires. Les spécifications qui définissent de nouveaux types de précondition DOIVENT décrire si des préconditions facultatives sont ou non applicables, et si elles le sont, quel est le comportement attendu d'un UA à réception de préconditions facultatives.

 	3.4	Suspension et reprise d'établissement de session
La Section 6 de la RFC 3312 décrit le comportement des UA à partir du moment où l'établissement de session est suspendu, du fait d'un ensemble de préconditions, jusqu'à ce qu'il soit repris quand ces préconditions sont satisfaites. En général, l'utilisateur appelé n'est pas alerté avant que les préconditions soient satisfaites.

En plus de ne pas alerter l'utilisateur, chaque type de précondition DOIT définir toutes les actions supplémentaires que les UA devraient effectuer ou s'abstenir d'effectuer quand l'établissement de session est suspendu. Le comportement des flux de supports durant la suspension de session fait donc partie de la définition d'un type particulier de précondition. Certains types de précondition peuvent permettre que des flux de supports envoient et reçoivent des paquets durant une suspension de session ; d'autres ne le peuvent pas. Par conséquent, le paragraphe suivant de la RFC 3312 s'applique seulement aux préconditions de QS :

Lorsque l'établissement de session est suspendu, les agents d'utilisateur NE DEVRAIENT PAS envoyer de données sur un flux de supports. Dans le cas de RTP, ni les paquets RTP ni RTCP ne sont envoyés.

Pour préciser le paragraphe précédent, les messages de contrôle utilisés pour établir les connexions dans des protocoles de transport en mode connexion (par exemple, des SYN TCP) ne sont pas affectés par la règle précédente. Donc, les agents d'utilisateur suivent les règles standard (par exemple, l'attribut SDP "setup" [RFC4145]) pour décider quand établir la connexion, sans égard aux préconditions de QS.

Les nouveaux types de précondition DOIVENT aussi décrire le comportement des UA à réception d'un re-INVITE ou d'un UPDATE avec des préconditions pour une session sortante.

 	4.	Questions relatives à la mobilité de session

La Section 5 de la RFC 3312 décrit comment utiliser les préconditions SIP [RFC3261] avec le modèle d'offre/réponse [RFC3264]. La RFC 3312 donne un ensemble de règles qui permettent à un agent d'utilisateur de communiquer les changements de l'état actuel des préconditions à l'agent d'utilisateur distant.

L'idée est qu'un agent d'utilisateur donné sait l'état actuel d'une partie des préconditions (par exemple, la direction d'envoi de la précondition de QS) par des informations locales (par exemple, un RESVV est reçu qui indique que la réservation de ressource a réussi). Le client d'agent d'utilisateur (UAC, User Agent Client) informe le serveur d'agent d'utilisateur (UAS, User Agent Server) des changements de l'état actuel en envoyant une offre à l'UAS. L'UAS, à son tour, pourrait (si nécessaire) envoyer une offre à l'UAC l'informant de l'état de la partie des préconditions dont l'UAS a des informations locales.

Noter, cependant, que les UAS n'envoient généralement pas de mises à jour de l'état actuel à l'UAC parce que les UAS sonceux qui reprennent l'établissement de session quand toutes les préconditions sont satisfaites. Donc, plutôt que d'effectuer un échange d'offre/réponse pour informer l'UAC que toutes les préconditions sont satisfaites, ils envoient simplement une réponse 180 (Sonnerie) qui indique que l'établissement de session a repris.

Alors que la RFC 3312 permet de mettre à jour les informations d'état courant en utilisant les méthodes décrites ci-dessus, elle ne permet pas de dégrader les valeurs d'état courant dans les réponses, comme le montre la troisième rangée du Tableau  3 de la RFC 3312. La Figure 1 montre comment effectuer une telle dégradation dans une réponse qui pourrait être parfois nécessaire.

                 A        Contrôleur 3pcc      B        C
                 |              |              |        |
                 |<-dialogue 1->|<-dialogue 2->|        |
                 |              |              |        |
                 | *************************** |        |
                 |*         SUPPORT           *|        |
                 | *************************** |        |
                 |              |              |        |
                 |              |              |        |
                 |<-dialogue 1->|<------dialogue 3----->|
                 |              |              |        |
                 | ************************************ |
                 |*             SUPPORT                *|
                 | ************************************ |
                 |              |              |        |
                 |              |              |        |

Figure 1 : Mobilité de session en utilisant 3pcc

Le contrôleur 3pcc (commande d'appel de tiers) [RFC3725] de la Figure 1 a établi une session entre A et B en utilisant le dialogue 1 vers A et le dialogue 2 vers B. À ce point, le contrôleur veut que A ait une session avec C au lieu de B. Pour transférer A à C (configuration montrée au bas de la Figure 1) le contrôleur envoie un re-INVITE vide (pas d'offre) à A.  Comme A ne sait pas que la session va être déplacée, son offre dans l'état 200 OK déclare que l'état actuel du flux de supports dans la direction d'envoi est "Oui". Après le contact avec C établissant le dialogue 3, le contrôleur renvoie une réponse à A. Cette réponse contient une nouvelle destination pour le support (C) et devrait avoir dégradé l'état en cours du flux de supports à "Non", car il n'y a pas de réservation de ressources entre A et C.

 	4.1	Mise à jour à la RFC 3312
Voici un ensemble de nouvelles règles qui mettent à jour la RFC 3312 pour traiter les problèmes ci-dessus.

La règle ci-dessous s'applique aux offreurs qui déplacent un flux de supports à une nouvelle adresse :

Quand un flux est déplacé à une nouvelle adresse de transport, l'offreur DOIT régler toutes les valeurs d'état en cours sur lesquelles il n'a pas d'informations locales à "Non".

Noter que pour les flux qui utilisent l'état segmenté (par opposition à l'état de bout en bout) le fait que l'adresse pour le flux de supports au segment local change peut ou non affecter l'état des préconditions au segment distant. Cependant, déplacer un flux existant à une nouvelle localisation, du point de vue des préconditions, est comme établir un nouveau flux. Donc, il est approprié de régler toutes les valeurs d'état courantes à "Non" et de commencer une nouvelle négociation de préconditions depuis le début.

La mise à jour du tableau et des règles ci-dessous s'applique à un répondeur qui déplace un flux de supports. L'offreur ignore le déplacement quand il génère l'offre.

Le Tableau 3 de la RFC 3312 doit être mis à jour pour permettre aux répondeurs de dégrader les valeurs d'état courant. Le tableau suivant montre le résultat.

Tableau d'état de transaction	Tableau d'état local	Nouvelles valeurs de transaction/locale
non	non	non/non
oui 	oui	oui/oui
oui	non	dépend des informations locales
non	oui	dépend des informations locales

Un répondeur DOIT dégrader les valeurs d'état courant reçues dans l'offre si il a des informations locales sur elles ou si le flux de supports est déplacé à une nouvelle adresse de transport.

Noter que pour les flux qui utilisent l'état segmenté, le changement d'adresse au receveur peut ou non affecter l'état des préconditions au segment de l'offreur. Cependant, comme déclaré ci-dessus, déplacer un flux existant à une nouvelle localisation, du point de vue des préconditions, est comme d'établir un nouveau flux. Donc, il est approprié de régler toutes les valeurs d'état en cours à "Non" et de commencer une nouvelle négociation de préconditions depuis le début.

Le nouveau tableau ci-dessous s'applique à un offreur qui reçoit une réponse qui met à jour ou dégrade ses tableaux d'état local. Les offreurs devraient mettre à niveau leurs tableaux d'état local quand ils reçoivent une réponse comme montré dans le tableau suivant.

Tableau d'état de transaction	Tableau d'état local	Nouvelles valeurs d'état local
non	non	non
oui	oui	oui
oui	non	oui
non	oui	non

 	4.2	État désiré
L'état désiré qu'un UA veut pour un flux de supports après que le flux est déplacé à une nouvelle adresse de transport peut être différent de l'état désiré négocié à l'origine pour le flux. Un UA, par exemple, peut exiger une QS obligatoire sur une liaison à faible bande passante mais être satisfait avec la QS facultative quand le flux est déplacé à une liaison à forte bande passante.

Si le nouvel état désiré est supérieur au précédent (par exemple, de facultatif à obligatoire) l'UA, suivant les procédures de la RFC 3312, peut mettre à niveau son état désiré dans une offre ou dans une réponse. Si le nouvel état désiré est inférieur au précédent (c'est-à-dire, de obligatoire à facultatif) l'UA, suivant aussi les procédures de la RFC 3312, peut dégrader son état désiré seulement dans une offre (c'est-à-dire, pas dans une réponse.)

 	5.	Considérations sur la sécurité

Un attaquant qui ajouterait des préconditions à une description de session ou modifierait des préconditions existantes pourrait empêcher l'établissement des sessions. Un attaquant qui retirerait des préconditions d'une description de session pourrait forcer les sessions à être établies sans satisfaire des préconditions obligatoires.

Donc, il est fortement RECOMMANDÉ que la protection de l'intégrité soit appliquée aux descriptions de session SDP. S/MIME est le choix naturel pour fournir une telle protection d'intégrité de bout en bout, comme décrit dans la [RFC3261].

 	6.	Considérations relatives à l'IANA

Les exigences d'enregistrement de l'IANA pour le cadre de préconditions sont définies dans la RFC 3312. Toute nouvelle précondition est soumise aux considérations relatives à l'IANA qui s'y trouvent.

 	7.	Remerciements

Dave Oran et Allison Mankin ont fourni d'utiles commentaires sur ce document.

 	8.	Références
 	8.1	Références normatives

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

[RFC3261]	J. Rosenberg et autres, "SIP : Protocole d'initialisation de session", juin 2002, DOI 10.17487/RFC3261. (Mise à jour par 3265, 3853, 4320, 4916, 5393, 6665, 8217, 8760)

[RFC3312]	G. Camarillo, éd., "Intégration de la gestion de ressource et du protocole d'initialisation de session (SIP)", octobre 2002. (MàJ par RFC4032, RFC5027) (P.S.)

 	8.2	Références pour information

[RFC3264]	J. Rosenberg et H. Schulzrinne, "Modèle d'offre/réponse avec le protocole de description de session (SDP)", juin 2002. (P.S.  ; MàJ par RFC8843, 9143)

[RFC3311]	J. Rosenberg, "Méthode UPDATE du protocole d'initialisation de session (SIP) ", octobre 2002.

[RFC3725]	J. Rosenberg et autres, "Bonnes pratiques actuelles pour la commande d'appel de tiers (3pcc) dans le protocole d'initialisation de session (SIP)", avril 2004. (BCP0085)

[RFC4145]	D. Yon, G. Camarillo, "Transport de support fondé sur TCP dans le protocole de description de session (SDP)", septembre   2005. (MàJ par RFC4572) (P.S.)

 	Adresse des auteurs
Gonzalo Camarillo	Paul Kyzivat	
Ericsson	Cisco Systems	
Hirsalantie 11	1414 Massachusetts Avenue, BXB500 C2-2	
Jorvas  02420	Boxborough, MA  01719	
Finland	USA	
mél : Gonzalo.Camarillo@ericsson.com 	mél : pkyzivat@cisco.com	

 	Déclaration complète de droits de reproduction
Copyright (C) The IETF Trust (2005).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournis 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 encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

Remerciement 
Le financement de la fonction d’édition des RFC est fourni par l'activité de soutien administratif (IASA) de l'IETF.