Groupe de travail Réseau

S. Donovan, Cisco Systems

Request for Comments : 4028

J. Rosenberg, Cisco Systems

Catégorie : En cours de normalisation

avril 2005

Traduction Claude Bière de L'Isle




Temporisateurs de session
dans 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 (2005).


Résumé

Le présent document définit une extension au protocole d'initialisation de session (SIP, Session Initiation Protocol). Cette extension permet un rafraîchissement périodique des sessions SIP par une demande re-INVITE ou UPDATE. Le rafraîchissement permet aux agents d'utilisateur et aux mandataires de déterminer si la session SIP est encore active. L'extension définit deux nouveaux champs d'en-tête : Session-Expires, qui porte la durée de vie de la session, et Min-SE, qui porte la valeur minimum permise pour le temporisateur de session.


Table des Matières

1. Introduction

2. Terminologie

3. Vue d'ensemble du fonctionnement

4. Définition du champ d'en-tête Session-Expires

5. Définition du champ d'en-tête Min-SE

6. Définition du code de réponse 422

7. Comportement de l'UAC

7.1 Génération d'une demande de rafraîchissement de session initiale

7.2 Traitement d'une réponse 2xx

7.3 Traitement d'une réponse 422

7.4 Génération des demandes de rafraîchissement de session suivantes

8. Comportement de mandataire

8.1 Traitement des demandes

8.2 Traitement des réponses

8.3 Expiration de session

9. Comportement de l'UAS

10. Réalisation des rafraîchissements

11. Considérations sur la sécurité

11.1 Attaques de l'intérieur

11.2 Attaques de l'extérieur

12. Considérations relatives à l'IANA

12.1 Enregistrement par l'IANA des champs d'en-tête Min-SE et Session-Expires

12.2 Enregistrement par l'IANA du code de réponse 422

12.3 Enregistrement par l'IANA de l'étiquette d'option 'timer'

13. Exemple de flux d'appel

14. Remerciements

15. Références

15.1 Références normatives

15.2 Références pour information

Adresse des auteurs

Déclaration des droits de reproduction


1. Introduction


Le protocole d'initialisation de session (SIP) [RFC3261] ne définit pas de mécanisme de garde en vie pour les sessions qu'il établit. Bien que les agents d'utilisateur puissent être capables de déterminer si la session est arrivée à expiration en utilisant des mécanismes spécifiques de la session, les mandataires ne seront pas capables de le faire. Le résultat est que les mandataires à états d'appel pleins ne seront pas toujours capables de déterminer si une session est encore active. Par exemple, lorsque un agent d'utilisateur manque à envoyer un message BYE à la fin d'une session, ou lorsque le message BYE est perdu à cause de problèmes dans le réseau, un mandataire d'appel à états pleins ne saura pas quand la session s'est terminée. Dans cette situation, le mandataire d'appel à états pleins va conserver l'état pour l'appel et n'a aucune méthode pour déterminer quand les informations d'état d'appel ne s'appliquent plus.


Pour résoudre ce problème, cette extension définit un mécanisme de garde en vie pour les sessions SIP. Les agents d'utilisateur (UA, User Agent) envoient des demandes périodiques re-INVITE ou UPDATE [RFC3311] (qu'on appelle des demandes de rafraîchissement de session) pour garder la session en vie. L'intervalle entre les demandes de rafraîchissement de session est déterminé par un mécanisme de négociation défini ici. Si une demande de rafraîchissement de session n'est pas reçue avant l'expiration de l'intervalle, la session est considérée comme terminée. Les deux UA sont supposés envoyer un BYE, et les mandataires d'appel à états pleins peuvent supprimer tout l'état pour l'appel.


Ce mécanisme de rafraîchissement a des applications supplémentaires. Un agent d'utilisateur va souhaiter déterminer si la session est encore active pour les mêmes raisons qu'un serveur mandataire d'appel à états pleins. Cette détermination peut être faite chez un agent d'utilisateur sans utiliser de mécanisme de niveau SIP ; pour les sessions audio, des paquets RTCP périodiques servent d'indication de vitalité [RFC3550]. Cependant, il est souhaitable de séparer les indications de vitalité de session SIP des détails de la session elle-même.


Une autre application du temporisateur de session est dans la construction d'une passerelle de niveau application (ALG, Application Level Gateway) de traducteur d'adresse réseau (NAT, Network Address Translator) SIP [RFC2663]. L'ALG incorporée dans un NAT va avoir besoin de conserver l'état pendant la durée de l'appel. Cet état doit finalement être supprimé. S'appuyer sur un BYE pour déclancher la suppression d'état, en plus de ne pas être fiable, introduit un potentiel d'attaque de déni de service.


Le présent document présente une extension à SIP qui définit un mécanisme d'expiration de session. Des rafraîchissements périodiques, par des re-INVITE ou UPDATE, sont utilisés pour garder la session active. L'extension est suffisamment rétro compatible avec SIP pour qu'elle fonctionne si l'un ou l'autre des deux participants à un dialogue comprend l'extension. Deux nouveaux champs d'en-tête (Session-Expires et Min-SE) et un nouveau code de réponse (422) sont définis. Session-Expires porte la durée de la session, et Min-SE porte la valeur minimum admise pour l'expiration de la session. Le code de réponse 422 indique que la durée du temporisateur de session était trop courte.


2. 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 la [RFC2119] et indiquent les niveaux d'exigence pour les mises en œuvre SIP conformes.


De plus, on définit les termes suivants :


Intervalle de session : durée maximum qui peut s'écouler entre les demandes de rafraîchissement de session dans un dialogue avant que la session soit considérée comme expirée. L'intervalle de session est porté dans le champ d'en-tête Session-Expires, qui est défini ici. Le serveur d’agent d’utilisateur (UAS, User Agent Server) obtient cette valeur du champ d'en-tête Session-Expires dans une réponse 2xx à une demande de rafraîchissement de session qu'il envoie. Les mandataires et les clients d'agent d'utilisateur (UAC, User Agent client) déterminent cette valeur d'après le champ d'en-tête Session-Expires dans une réponse 2xx à une demande de rafraîchissement de session qu'ils reçoivent.


Temporisateur minimum : à cause de la charge du traitement des demandes de mi-dialogue, tous les éléments (mandataire, UAC, UAS) peuvent avoir une valeur configurée minimum pour l'intervalle de session qu'ils veulent accepter. Cette valeur est appelée le temporisateur minimum.


Expiration de session : c'est l'instant où un élément va considérer que la session a fini son temps, si aucune transaction de rafraîchissement de session réussie n'intervient auparavant.


Demande de rafraîchissement de session : demande INVITE ou UPDATE traitée conformément aux règles de la présente spécification. Si la demande génère une réponse 2xx, l'expiration de session est augmentée de l'heure actuelle plus l'intervalle de session obtenu de la réponse. Une demande de rafraîchissement de session ne doit pas être confondue avec une demande de rafraîchissement de cible, définie à la Section 6 de la [RFC3261], qui est une demande qui peut mettre à jour la cible distante d'un dialogue.


Demande de rafraîchissement de session initiale : c'est la première demande de rafraîchissement de session envoyée avec une valeur particulière d'identifiant d'appel (Call-ID).


Demande de rafraîchissement de session suivante : toute demande de rafraîchissement de session envoyée avec un identifiant d'appel particulier après la demande de rafraîchissement de session initiale.


Rafraîchissement : même chose qu'une demande de rafraîchissement de session.


3. Vue d'ensemble du fonctionnement


Cette section donne une brève vue d'ensemble du fonctionnement de cette extension. Elle est par nature informative et ne devrait pas être considérée comme normative.

Cette extension a la propriété de fonctionner même lorsque un seul UA d'un dialogue la prend en charge. Les étapes du traitement diffèrent pour les quatre cas suivants : l'UAC la prend ou non en charge, et l'UAS la prend ou non en charge. Pour faire simple, cette section décrira les opérations de base dans le cas où les deux côtés prennent en charge l'extension.


Un UAC commence par envoyer un INVITE. Cela inclut un champ d'en-tête Supported avec l'étiquette d'option "timer", qui indique la prise en charge de cette extension.


Cette demande passe par les mandataires, dont chacun peut avoir intérêt à établir un temporisateur de session. Chaque mandataire peut insérer un champ d'en-tête Session-Expires et un champ d'en-tête Min-SE dans la demande (si aucun n'est déjà présent) ou altérer la valeur des champs d'en-tête Session-Expires et Min-SE existants comme décrit ci-dessus.


Le champ d'en-tête Min-SE établit la limite inférieure de l'intervalle de rafraîchissement de session ; c'est-à-dire, le taux le plus rapide qu'aucun mandataire servant cette demande aura la permission de demander. L'objet de ce champ d'en-tête est d'empêcher des mandataires hostiles de régler les intervalles de rafraîchissement à des valeurs très courtes afin que leurs voisins soient surchargés. Chaque mandataire traitant la demande peut remonter cette limite inférieure (augmenter la période entre les rafraîchissements) mais n'est pas autorisé à la diminuer.


Le champ d'en-tête Session-Expires établit la limite supérieure de l'intervalle de rafraîchissement de session ; c'est-à-dire, la période après le traitement d'une demande pendant laquelle tout mandataire à états de session pleins doit conserver cet état pour la session. Tout mandataire qui sert cette demande peut diminuer cette valeur, mais il ne lui est pas permis de la diminuer en dessous de la valeur spécifiée dans le champ d'en-tête Min-SE.


Si l'intervalle Session-Expires est trop faible pour un mandataire (c'est-à-dire, plus bas que la valeur de Min-SE que le mandataire souhaiterait affirmer) le mandataire rejette la demande avec une réponse 422. Cette réponse contient un champ d'en-tête Min-SE qui identifie l'intervalle de session minimum qu'il veut prendre en charge. L'UAC va réessayer, cette fois en incluant le champ d'en-tête Min-SE dans la demande. Le champ d'en-tête contient le plus grand champ d'en-tête Min-SE qu'il a observé dans toutes les réponses 422 reçues précédemment. De cette façon, le temporisateur minimum satisfait aux contraintes de tous les mandataires le long du chemin.


Après plusieurs itérations INVITE/422, la demande arrive finalement à l'UAS. L'UAS peut ajuster la valeur de l'intervalle de session comme si il était un mandataire ; lorsque c'est fait, il place l'intervalle de session final dans le champ d'en-tête Session-Expires dans une réponse 2xx. Le champ d'en-tête Session-Expires contient aussi un paramètre "rafraîchisseur", qui indique qui fait le rafraîchissement – l'UA qui est actuellement l'UAC, ou l'UA qui est actuellement l'UAS. Comme la réponse 2xx voyage en retour à travers toute la chaîne de mandataires, chaque mandataire peut observer l'intervalle de session final mais ne peut le changer.


D'après le champ d'en-tête Session-Expires dans la réponse, les deux UA savent qu'un temporisateur de session est actif, quand il va arriver à expiration, et qui est rafraîchi. À un certain moment avant l'expiration, le rafraîchisseur actuellement actif génère une demande de rafraîchissement de session, qui est une demande re-INVITE ou UPDATE [RFC3311]. Si le rafraîchisseur n'obtient pas de réponse à cette demande de rafraîchissement de session, il envoie un BYE pour terminer la session. De façon similaire, si l'autre côté ne reçoit pas de demande de rafraîchissement de session avant l'expiration de la session, il envoie un BYE.


Les demandes de rafraîchissement envoyées une fois la session établie sont traitées d'une façon identique à celle des demandes initiales, comme décrit ci-dessus. Cela signifie qu'une demande de rafraîchissement de session réussie va étendre la durée de la session, comme désiré.


L'extension introduit des complications supplémentaires au delà du flux de base pour prendre en charge les cas où un seul des UA la supporte. Une de ces complications est qu'un mandataire peut avoir besoin d'insérer le champ d'en-tête Session-Expires dans la réponse, au cas où l'UAS ne supporterait pas l'extension. La négociation du rôle de rafraîchisseur est aussi affectée par cette capacité ; elle prend en considération quels participants prennent en charge l'extension.


Noter que le temporisateur de session rafraîchit la session, non le dialogue utilisé pour établir la session. Bien sûr, les deux se tiennent. Si la session expire, un BYE est envoyé, ce qui termine la session et, généralement, le dialogue.


4. Définition du champ d'en-tête Session-Expires


Le champ d'en-tête Session-Expires porte l'intervalle de session pour une session SIP. Il n'est placé que dans les demandes INVITE ou UPDATE, ainsi que dans toute réponse 2xx à un INVITE ou UPDATE. Comme le champ d'en-tête SIP Expires, il contient une différence de temps.


Le minimum absolu pour le champ d'en-tête Session-Expires est 90 secondes. Cette valeur représente un peu plus de deux fois la durée que peut prendre une transaction SIP en cas de fin de temporisation. Cela permet un délai suffisant pour qu'un UA tente un rafraîchissement à la moitié de l'intervalle de session, et pour que cette transaction s'achève normalement avant l'expiration de la session. Cependant, 1800 secondes (30 minutes) est RECOMMANDÉ comme valeur pour le champ d'en-tête Session-Expires. En d'autres termes, les entités SIP DOIVENT être prêtes à traiter des valeurs de champ d'en-tête Session-Expires de toute durée supérieurs à 90 secondes, mais les entités qui insèrent le champ d'en-tête Session-Expires NE DEVRAIENT PAS choisir des valeurs de moins de 30 minutes.


De petits intervalles de session peuvent être destructifs pour le réseau. Ils causent un trafic de gestion excessif qui affecte aussi bien les agents d'utilisateur et que les serveurs mandataires. Ils augmentent la possibilité "d'éblouissement" qui peut se produire quand les deux agents d'utilisateur envoient en même temps un re-INVITE ou UPDATE. Comme le principal objet du temporisateur de session est de fournir un moyen pour mettre fin à l'état dans les éléments SIP, de très petites valeurs ne sont généralement pas nécessaires. 30 minutes a été choisi parce que 95 % des appels téléphoniques sont plus courts que cette durée. Cependant, le minimum de 30 minutes est mentionné comme DEVRAIT, et non DOIT, car la valeur exacte dépend de nombreux facteurs du réseau, incluant la bande passante et la latence du réseau, la puissance de calcul, la mémoire disponible, la topologie du réseau, et, bien sûr, le scénario d'application. Après tout, SIP peut établir toutes sortes de sessions, et pas seulement un appel téléphonique. Au moment de la publication du présent document, 30 minutes semble approprié. Des avancées de la technologie pourront dans cinq ans montrer que ce nombre est excessif.


La valeur par défaut du champ d'en-tête Session-Expires est indéfinie. Cela signifie que l'absence du champ d'en-tête Session-Expires implique qu'il n'y a pas d'expiration de la session, en utilisant le mécanisme défini dans cette spécification. Noter que d'autres mécanismes non définis ici, comme des temporisateurs configurés en local, peuvent s'appliquer.


La syntaxe du champ d'en-tête Session-Expires est la suivante :


Session-Expires = ("Session-Expires" / "x") HCOLON delta-seconds *(SEMI se-params)

se-params = rafraîchisseur-param / generic-param

rafraîchisseur-param = "rafraîchisseur" EQUAL ("uas" / "uac")

Noter qu'une forme compacte, la lettre x, a été réservée pour Session-Expires. Le BNF pour delta-seconds et generic-param est défini à la Section 25 de la [RFC3261].


Le tableau 1 est une extension des tableaux 2 et 3 de la [RFC3261] pour les champs d'en-tête Session-Expires et Min-SE. La colonne 'PRA' est pour la méthode PRACK [RFC3262], 'UPD' pour UPDATE [RFC3311], 'SUB' pour SUBSCRIBE [RFC3265], et 'NOT' pour NOTIFY [RFC3265].


En-tête

mandat.

ACK

BYE

CAN

INV

OPT

REG

PRA

UPD

SUB

NOT

Session-Expires

R

amr

-

-

-

o

-

-

-

o

-

-

Session-Expires

2xx

ar

-

-

-

o

-

-

-

o

-

-

Min-SE

R

amr

-

-

-

o

-

-

-

o

-

-|

Min-SE

422


-

-

-

m

-

-

-

m

-

-


Tableau 1 : Champs d'en-tête Session-Expires et Min-SE


5. Définition du champ d'en-tête Min-SE


Le champ d'en-tête Min-SE indique la valeur minimum pour l'intervalle de session, en unités de delta-secondes. Lorsque utilisé dans une demande INVITE ou UPDATE, il indique la plus petite valeur de l'intervalle de session qui peut être utilisée pour cette session. Lorsque présent dans une demande ou réponse, sa valeur NE DOIT PAS être moins de 90 s.


Lorsque le champ d'en-tête n'est pas présent, sa valeur par défaut est de 90 secondes.


Le champ d'en-tête Min-SE NE DOIT PAS être utilisé dans les réponses sauf celles avec un code de réponse 422. Cela indique la valeur minimum de l'intervalle de session que le serveur veut accepter.


La syntaxe du champ d'en-tête Min-SE est la suivante :


Min-SE = "Min-SE" HCOLON delta-seconds *(SEMI generic-param)


6. Définition du code de réponse 422


Cette extension introduit le code de réponse 422 (Intervalle de session trop court). Il est généré par un UAS ou mandataire quand une demande contient un champ d'en-tête Session-Expires dont la durée est inférieure au temporisateur minimum pour le serveur. La réponse 422 DOIT contenir un champ d'en-tête Min-SE avec le temporisateur minimum pour ce serveur.


7. Comportement de l'UAC

7.1 Génération d'une demande de rafraîchissement de session initiale

Un UAC qui prend en charge l'extension de temporisateur de session définie ici DOIT inclure un champ d'en-tête Supported dans chaque demande (sauf ACK) mentionnant l'étiquette d'option 'timer' [RFC3261]. Il DOIT le faire même si l'UAC ne demande pas l'usage du temporisateur de session pour cette session.


L'UAC PEUT inclure un champ d'en-tête Require dans la demande avec la valeur 'timer' pour indiquer que l'UAS doit prendre en charge le temporisateur de session pour participer à la session. Cela ne signifie pas que l'UAC exige que l'UAS effectue les rafraîchissements, mais seulement qu'il demande que l'UAS prenne en charge l'extension. De plus, l'UAC PEUT inclure un champ d'en-tête Proxy-Require dans la demande avec la valeur 'timer' pour indiquer que les mandataires doivent prendre en charge le temporisateur de session afin de traiter correctement la demande. Cependant, l'usage de Require ou Proxy-Require par l'UAC N'EST PAS RECOMMANDÉ. Ils ne sont pas nécessaires, car l'extension fonctionne même quand seul l'UAC prend l'extension en charge. Le champ d'en-tête Supported qui contient 'timer' DOIT quand même être inclus, même si les champ d'en-tête Require ou Proxy-Require sont présents et contiennent 'timer'.


Un UAC PEUT inclure le champ d'en-tête Min-SE dans la demande initiale INVITE.


Un UAC PEUT inclure un champ d'en-tête Session-Expires dans une demande initiale de rafraîchissement de session si il veut qu'un temporisateur de session s'applique à la session. La valeur de ce champ d'en-tête indique l'intervalle de session désiré par l'UAC. Si un en-tête Min-SE est inclus dans la demande initiale de rafraîchissement de session, la valeur de Session-Expires DOIT être supérieure ou égale à la valeur dans Min-SE.


L'UAC PEUT inclure le paramètre de rafraîchisseur avec la valeur 'uac' si il veut effectuer les rafraîchissements. Cependant, il est RECOMMANDÉ que le paramètre soit omis afin qu'il puisse être choisi par le mécanisme de négociation décrit ci-dessous.


7.2 Traitement d'une réponse 2xx

Le temporisateur de session demande à un UA de créer et conserver l'état. Cet état inclut l'intervalle de session, l'expiration de session, et l'identité du rafraîchisseur. Cet état est associé au dialogue sur lequel la session a été négociée.


Lorsque arrive une réponse 2xx à une demande de rafraîchissement de session, elle peut contenir ou non un champ d'en-tête Require avec la valeur 'timer'. Si elle l'a, l'UAC DOIT chercher le champ d'en-tête Session-Expires pour traiter la réponse.


Si il y avait un champ d'en-tête Require dans la réponse avec la valeur 'timer', le champ d'en-tête Session-Expires sera toujours présent. Les UAC DOIVENT être prêts à recevoir un champ d'en-tête Session-Expires dans une réponse, même si aucun n'était présent dans la demande. Le paramètre "rafraîchisseur" sera présent dans le champ d'en-tête Session-Expires, indiquant qui va effectuer les rafraîchissements. L'UAC DOIT régler l'identité du rafraîchisseur à la valeur de ce paramètre. Si le paramètre contient la valeur 'uac', l'UAC les effectuera. Il est possible que l'UAC ait demandé le temporisateur de session (et ait donc inclus un champ d'en-tête Session-Expires dans la demande) et qu'il n'y ait pas de champ d'en-tête Require ou Session-Expires dans la réponse 2xx. Cela va arriver lorsque l'UAS ne prend pas en charge l'extension temporisateur de session et que seul l'UAC a demandé un temporisateur de session (aucun mandataire ne l'a demandé). Dans ce cas, si l'UAC souhaite toujours utiliser le temporisateur de session (qui est pour son seul bénéfice) il doit les effectuer. Pour ce faire, l'UAC suit les procédures définies dans la présente spécification comme si le champ d'en-tête Session-Expires avait été dans la réponse 2xx, et que sa valeur était la même que dans la demande, mais avec un paramètre de rafraîchisseur de 'uac'.


Si la réponse 2xx ne contenait pas de champ d'en-tête Session-Expires, il n'y a pas d'expiration de session. Dans ce cas, aucun rafraîchissement n'est envoyé. Une 2xx sans Session-Expires peut venir aussi bien de la demande de rafraîchissement de session initiale que des suivantes. Cela signifie que le temporisateur de session peut être "débranché" en milieu de dialogue par la réception d'une réponse sans champ d'en-tête Session-Expires.


L'UAC se souvient de l'intervalle de session pour une session comme la valeur de delta-time dans le champ d'en-tête Session-Expires de la plus récente réponse 2xx à une demande de rafraîchissement de session sur un dialogue. Il est explicitement permis qu'il y ait des intervalles de session différents (ou aucun) sur des dialogues différents établis par suite d'une seule INVITE. L'UAC se souvient aussi de si lui ou son homologue est le rafraîchisseur pour la session.


Si l'UAC doit effectuer les rafraîchissements, il calcule l'expiration de session pour cette session. L'expiration de session est l'heure de réception de la dernière réponse 2xx à une demande de rafraîchissement de session sur ce dialogue plus l'intervalle de session pour cette session. Si l'UA cherche à continuer la session au delà de l'expiration de session, il DOIT générer un "refresh" avant l'expiration de la session. Il est RECOMMANDÉ que ce rafraîchissement soit envoyé une fois que la moitié de l'intervalle de session s'est écoulé. Des procédures supplémentaires pour ce rafraîchissement sont décrites à la Section 10.


De façon similaire, une demande re-INVITE ou UPDATE envoyée au sein d'un dialogue pour des besoins autres que le rafraîchissement de session aura aussi pour effet de rafraîchir la session, et son traitement va suivre les procédures définies dans la présente spécification.


7.3 Traitement d'une réponse 422

Si la réponse à une demande de rafraîchissement de session est un message de réponse 422 (Intervalle de session trop court) l'UAC PEUT alors ressayer la demande. La procédure pour le réessai est décrite au paragraphe 7.4. Cette nouvelle demande constitue une nouvelle transaction et DEVRAIT avoir les mêmes valeurs de Call-ID, To, et From que la demande précédente, mais le CSeq devrait contenir un nouveau numéro de séquence qui soit supérieur de un au précédent.


7.4 Génération des demandes de rafraîchissement de session suivantes

Les valeurs de Supported, Require, et Proxy-Require utilisées dans la demande initiale de rafraîchissement de session DOIVENT être utilisées.


L'UAC DOIT insérer le champ d'en-tête Min-SE dans une demande de rafraîchissement de session pour un certain dialogue si il a reçu une réponse 422 à une précédente demande de rafraîchissement de session sur le même dialogue, ou si il a reçu une demande de rafraîchissement de session sur ce dialogue qui contenait un champ d'en-tête Min-SE. De façon similaire, si aucun dialogue n'a été encore établi, un UAC DOIT insérer le champ d'en-tête Min-SE dans une demande INVITE si il a reçu une réponse 422 à une demande INVITE précédente avec le même Call-ID.


La valeur du champ d'en-tête Min-SE présent dans une demande de rafraîchissement de session DOIT être la plus grande valeur parmi toutes les valeurs de champ d'en-tête Min-SE retournées dans toutes les réponses 422 ou reçues dans les demandes de rafraîchissement de session, sur le même dialogue, si un dialogue a été établi. Si aucun dialogue n'a été établi, la valeur du champ d'en-tête Min-SE est réglée à la plus grande valeur parmi toutes les valeurs de champ d'en-tête Min-SE retournées dans toutes les réponses 422 pour une demande INVITE avec le même Call-ID. Par suite de cette règle; la valeur maximum de Min-SE est effectivement "supprimée" une fois le dialogue établi, et à partir de là, seules les valeurs provenant de mandataires connus pour être sur le chemin des mandataires vont finir par être utilisées.


L'UAC peut avoir ses propres opinions sur l'intervalle de session minimum. Dans ce cas, si la valeur ci-dessus est trop petite, l'UAC PEUT l'augmenter.


Dans une demande de rafraîchissement de session envoyée au sein d'un dialogue avec un temporisateur de session actif, le champ d'en-tête Session-Expires DEVRAIT être présent. Lorsque il est présent, il DEVRAIT être égal au maximum du champ d'en-tête Min-SE (on se rappelle que la valeur par défaut lorsque il n'est pas présent est 90 secondes) et l'intervalle de session actuel. L'inclusion du champ d'en-tête Session-Expires avec cette valeur évite certaines attaques de déni de service, comme exposé à la Section 11. À ce titre, UN UA DEVRAIT seulement ignorer le DEVRAIT dans les cas inhabituels et singuliers où il est désirable de changer l'intervalle de session à mi dialogue.


Si la demande de rafraîchissement de session n'est pas l'initiale, il est RECOMMANDÉ que le paramètre rafraîchisseur soit réglé à 'uac' si l'élément qui envoie la demande est actuellement en train d'effectuer des rafraîchissements, et à 'uas' si son homologue est en train d'effectuer les rafraîchissements. De cette façon, le rôle de rafraîchisseur ne change pas à chaque rafraîchissement. Cependant, si il souhaite explicitement changer les rôles, il PEUT utiliser une valeur de 'uas' si il sait que l'autre côté prend en charge le temporisateur de session. Il pourrait savoir cela en ayant reçu une demande de son homologue avec un champ d'en-tête Supported contenant la valeur 'timer'. Si il cherche à refaire le choix des rôles, il PEUT omettre le paramètre.


Un re-INVITE généré pour rafraîchir la session est un re-INVITE normal, et un UPDATE généré pour rafraîchir une session est un UPDATE normal. Si un UAC sait que son homologue prend en charge la méthode UPDATE, il est RECOMMANDÉ que UPDATE soit utilisé plutôt qu'un re-INVITE. Un UA peut faire cette détermination si il a vu un champ d'en-tête Allow provenant de son homologue avec la valeur 'UPDATE', ou par une demande OPTIONS de mi dialogue. Il est RECOMMANDÉ que la demande UPDATE ne contienne pas une offre [RFC3264], mais un re-INVITE DEVRAIT en contenir une, même si les détails de la session n'ont pas changé. Dans ce cas, l'offre DOIT indiquer qu'ils n'ont pas changé. Dans le cas de SDP, ceci se fait en incluant la même valeur pour le champ d'origine que celui des messages SDP précédents à son homologue. La même chose est vraie pour une réponse échangée par suite d'une demande de rafraîchissement de session ; si elle n'a pas changé, cela DOIT être indiqué.


8. Comportement de mandataire


Les temporisateurs de session sont intéressants principalement pour les serveurs mandataires d'appel à états pleins (c'est-à-dire, pour les serveurs qui conservent l'état des appels et dialogues établis à travers eux). Cependant, un serveur mandataire sans états (c'est-à-dire, un serveur qui connaît l'état de transaction mais ne conserve pas l'état d'appel ou de dialogue) PEUT aussi suivre les règles décrites ici. Les mandataires sans états NE DOIVENT PAS tenter de demander des temporisateurs de session. Les mandataires qui demandent des temporisateurs de session DEVRAIENT enregistrer le chemin car sinon ils ne vont pas recevoir les rafraîchissements.


Les règles de traitement par le mandataire exigent que celui-ci se souvienne des informations entre la demande et la réponse, excluant les mandataires sans états.


8.1 Traitement des demandes

Le traitement des demandes est identique pour toutes les demandes de rafraîchissement de session.


Pour demander un temporisateur de session pour une session, un mandataire s'assure qu'un champ d'en-tête Session-Expires est présent dans une demande de rafraîchissement de session pour cette session. Un mandataire PEUT insérer un champ d'en-tête Session-Expires dans la demande avant de la transmettre si aucun n'était présent dans la demande. Ce champ d'en-tête Session-Expires peut contenir toute heure d'expiration désirée par le mandataire, mais pas avec une durée inférieure à la valeur dans le champ d'en-tête Min-SE de la demande, si il est présent. Le mandataire NE DOIT PAS inclure un paramètre rafraîchisseur dans la valeur du champ d'en-tête.


Si la demande a déjà un champ d'en-tête Session-Expires, le mandataire PEUT réduire sa valeur mais NE DOIT PAS la régler à une durée inférieure à la valeur dans le champ d'en-tête Min-SE de la demande, si il est présent. Si la valeur du champ d'en-tête Session-Expires est supérieure ou égale à la valeur dans le champ d'en-tête Min-SE (on se rappelle que c'est par défaut 90 secondes quand le champ d'en-tête Min-SE est absent) le mandataire NE DOIT PAS augmenter la valeur du champ d'en-tête Session-Expires. Si la valeur du champ d'en-tête Session-Expires est inférieure à la valeur du champ d'en-tête Min-SE (éventuellement parce que le mandataire a augmenté la valeur du champ d'en-tête Min-SE, comme décrit ci-dessous) le mandataire DOIT augmenter la valeur du champ d'en-tête Session-Expires pour la rendre égale à la valeur du champ d'en-tête Min-SE. Le mandataire NE DOIT PAS insérer ou modifier la valeur du paramètre "rafraîchisseur" dans le champ d'en-tête Session-Expires.


Si la demande contient un champ d'en-tête Supported avec une valeur 'timer', le mandataire PEUT rejeter la demande INVITE avec une réponse 422 (Intervalle de session trop court) si l'intervalle de session dans le champ d'en-tête Session-Expires est plus petit que l'intervalle minimum défini par la politique locale du mandataire. Lorsque il envoie la réponse 422, le mandataire DOIT inclure un champ d'en-tête Min-SE avec la valeur de son intervalle minimum. Ce minimum NE DOIT PAS être inférieur à 90 secondes.


Si la demande n'indique pas la prise en charge du temporisateur de session mais contient un intervalle de session trop petit, le mandataire ne peut pas utilement rejeter la demande, car il en résulterait un échec de l'appel. Le mandataire DEVRAIT plutôt insérer un champ d'en-tête Min-SE contenant son intervalle minimum. Si un champ d'en-tête Min-SE est déjà présent, le mandataire DEVRAIT augmenter (mais NE DOIT PAS diminuer) la valeur à son intervalle minimum. Le mandataire DOIT ensuite augmenter la valeur du champ d'en-tête Session-Expires jusqu'à égaler la valeur qui est dans le champ d'en-tête Min-SE, comme décrit plus haut. Un mandataire NE DOIT PAS insérer un champ d'en-tête Min-SE ou modifier la valeur d'un champ d'en-tête existant dans une demande mandatée si cette demande contient un champ d'en-tête Supported avec la valeur 'timer'. Ceci est nécessaire pour se protéger contre certaines attaques de déni de service, décrites à la Section 11.


En supposant que le mandataire a demandé un temporisateur de session (et donc a éventuellement inséré le champ d'en-tête Session-Expires ou l'a réduit) le mandataire DOIT se souvenir qu'il utilise un temporisateur de session, et aussi se rappeler la valeur du champ d'en-tête Session-Expires provenant de la demande mandatée. Ceci DOIT être mémorisé pour la durée de la transaction.


Le mandataire DOIT se rappeler, pour la durée de la transaction, si la demande contenait le champ d'en-tête Supported avec la valeur 'timer'. Si elle ne contenait pas de champ d'en-tête Supported avec la valeur 'timer', le mandataire PEUT insérer un champ d'en-tête Require avec la valeur 'timer' dans la demande. Cependant, ceci N'EST PAS RECOMMANDÉ. Ceci permet au mandataire d'insister pour qu'il y ait un temporisateur de session pour la session. Ce champ d'en-tête n'est pas nécessaire si un champ d'en-tête Supported était dans la demande ; dans ce cas, le mandataire va déjà être sûr que le temporisateur de session peut être utilisé pour la session.


8.2 Traitement des réponses

Lorsque la réponse finale à la demande arrive, elle est examinée par le mandataire.


Si la réponse ne contenait pas de champ d'en-tête Session-Expires mais si le mandataire se souvient qu'il a demandé un temporisateur de session dans la demande (en insérant, modifiant, ou en examinant et acceptant le champ d'en-tête Session-Expires dans la demande mandatée) cela signifié que l'UAS ne prend pas en charge le temporisateur de session. Si le mandataire se souvient que l'UAC ne prend pas non plus en charge le temporisateur de session, le mandataire transmet la réponse normalement vers l'amont. Il n'y a pas d'expiration de session pour cette session. Si, cependant, le mandataire se souvient que l'UAC prend en charge le temporisateur de session, un traitement supplémentaire est nécessaire.


Parce qu'il n'y a pas de champ d'en-tête Session-Expires ou Require dans la réponse, le mandataire sait qu'il est le premier mandataire à capacité de temporisateur de session à recevoir la réponse. Ce mandataire DOIT insérer un champ d'en-tête Session-Expires dans la réponse avec la valeur mémorisée de la demande transmise. Il DOIT régler la valeur du paramètre "rafraîchisseur" à 'uac'. Le mandataire DOIT ajouter l'étiquette d'option 'timer' à tout champ d'en-tête Require dans la réponse, et si aucune n'était présente, ajouter le champ d'en-tête Require avec cette valeur avant de la transmettre vers l'amont.


Si la réponse reçue contient un champ d'en-tête Session-Expires, aucune modification de la réponse n'est nécessaire.


Dans tous les cas, si la réponse 2xx transmise en amont par le mandataire contenait un champ d'en-tête Session-Expires, sa valeur représente l'intervalle de session pour la session associée à cette réponse. Le mandataire calcule l'expiration de session comme l'heure à laquelle la réponse 2xx est transmise en amont, plus l'intervalle de session. Cette expiration de session DOIT mettre à jour toute expiration de session existante pour cette session. Le paramètre rafraîchisseur dans le champ d'en-tête Session-Expires de la réponse 2xx transmise en amont sera présent, et il indique quel UA effectue les rafraîchissements. Il peut y avoir plusieurs réponses 2xx à une seule INVITE, chacune représentant un dialogue différent, résultant en plusieurs expirations de session, une pour chaque session associée à chaque dialogue.


Le mandataire NE DOIT PAS modifier la valeur du champ d'en-tête Session-Expires reçu dans la réponse (en supposant qu'une était présente) avant de la transmettre en amont.


8.3 Expiration de session

Lorsque l'heure courante est égale ou dépasse l'heure d'expiration de session pour une session, le mandataire PEUT supprimer l'état d'appel associé, et PEUT libérer toutes les ressources associées à l'appel. À la différence de l'UA, il NE DOIT PAS envoyer de BYE.


9. Comportement de l'UAS


L'UAS doit répondre à une demande de temporisateur de session de l'UAC ou d'un mandataire sur le chemin de la demande, ou il peut demander lui-même qu'un temporisateur de session soit utilisé.


Si une demande entrante contient un champ d'en-tête Supported avec une valeur 'timer' et un champ d'en-tête Session-Expires, l'UAS PEUT rejeter la demande INVITE avec une réponse 422 (Intervalle de session trop petit) si l'intervalle de session dans le champ d'en-tête Session-Expires est inférieur à l'intervalle minimum défini par la politique locale de l'UAS. Lorsque il envoie la réponse 422, l'UAS DOIT inclure un champ d'en-tête Min-SE avec la valeur de son intervalle minimum. Cet intervalle minimum NE DOIT PAS être inférieur à 90 secondes.


Si l'UAS souhaite accepter la demande, il copie la valeur du champ d'en-tête Session-Expires d'après la demande dans la réponse 2xx.


La réponse de l'UAS PEUT réduire sa valeur mais NE DOIT PAS la régler à une durée inférieure à la valeur qui est dans le champ d'en-tête Min-SE de la demande, s'il en est un présent ; autrement, l'UAS PEUT réduire sa valeur mais NE DOIT PAS la régler à une durée inférieure à 90 secondes. Si la demande n'indique pas la prise en charge du temporisateur de session mais contient un intervalle de session trop court, l'UAS ne peut pas utilement rejeter la demande, car il en résulterait un échec d'appel. L'UAS DEVRAIT plutôt insérer un champ d'en-tête Min-SE contenant son intervalle minimum. Si un champ d'en-tête Min-SE est déjà présent, l'UAS DEVRAIT augmenter (mais NE DOIT PAS diminuer) la valeur à son intervalle minimum. L'UAS DOIT ensuite augmenter la valeur du champ d'en-tête Session-Expires pour qu'elle soit égale à la valeur dans le champ d'en-tête Min-SE


Si la demande entrante contient un champ d'en-tête Supported avec une valeur 'timer' mais ne contient pas d'en-tête Session-Expires, cela signifie que l'UAC indique la prise en charge des temporisateurs mais n'en demande pas. L'UAS peut demander un temporisateur de session dans la réponse 2XX en incluant un champ d'en-tête Session-Expires. La valeur NE DOIT PAS être réglée à une durée inférieure à la valeur qui est dans le champ d'en-tête Min-SE de la demande, si il est présent.


L'UAS DOIT régler la valeur du paramètre rafraîchisseur dans le champ d'en-tête Session-Expires dans la réponse 2xx. Cette valeur spécifie qui va effectuer les rafraîchissements pour le dialogue. La valeur se fonde sur celle de ce paramètre dans la demande, et sur si l'UAC prend en charge l'extension de temporisateur de session. L'UAC prend l'extension en charge si l'étiquette d'option 'timer' est présente dans un champ d'en-tête Supported dans la demande. Le Tableau 2 définit comment est réglée la valeur dans la réponse. Une valeur de "aucun" dans la deuxième colonne signifie qu'il n'y a pas de paramètre rafraîchisseur dans la demande. Une valeur de "NA" dans la troisième colonne signifie que cette combinaison particulière ne devrait pas se produire, car elle est interdite par le protocole.


Prise en charge par l'UAC ?

Paramètre rafraîchisseur dans la demande

Paramètre rafraîchisseur dans la réponse

non

aucun

uas

non

uac

NA

non

uas

NA

oui

aucun

uas ou uac

oui

uac

uac

oui

uas

uas


Tableau 2 : Comportement de l'UAS


La quatrième ligne du Tableau 2 décrit un cas où l'UAC et l'UAS prennent tous deux en charge l'extension de temporisateur de session, et où l'UAC n'a pas choisi qui va effectuer les rafraîchissements. Cela permet à l'UAS de décider si lui ou l'UAC va effectuer les rafraîchissements. Cependant, comme le tableau l'indique, l'UAS ne peut pas outrepasser le choix de l'UAC du rafraîchisseur, si il en a fait un.


Si le paramètre rafraîchisseur dans le champ d'en-tête Session-Expires dans la réponse 2xx a une valeur de 'uac', l'UAS DOIT placer un champ d'en-tête Require dans la réponse avec la valeur 'timer'. C'est parce que l'UAC effectue les rafraîchissements et que la réponse doit être traitée pour que l'UAC le sache. Si le paramètre rafraîchisseur dans la réponse 2xx a une valeur de 'uas' et si le champ d'en-tête Supported dans la demande contenait la valeur 'timer', l'UAS DEVRAIT placer un champ d'en-tête Require dans la réponse avec la valeur 'timer'. Dans ce cas, l'UAC n'est pas rafraîchi, mais il est supposé envoyer un BYE si il ne reçoit pas de rafraîchissement. Comme l'appel va quand même réussir sans que l'UAC envoie de BYE, l'insertion du Require est ici DEVRAIT, et non DOIT.


Tout comme l'UAC, l'UAS mémorise l'état pour le temporisateur de session. Cet état inclut l'intervalle de session, l'heure d'expiration de session, et l'identité du rafraîchisseur. Cet état se limite au dialogue utilisé pour établir la session. L'intervalle de session est réglé à la valeur de la différence d'heure avec le champ d'en-tête Session-Expires dans la plus récente réponse 2xx à une demande de rafraîchissement de session sur ce dialogue. Il mémorise aussi si c'est lui ou son homologue qui est le rafraîchisseur sur le dialogue, sur la base de la valeur du paramètre rafraîchisseur d'après la plus récente réponse 2xx à une demande de rafraîchissement de session sur ce dialogue. Si la plus récente réponse 2xx n'a pas de champ d'en-tête Session-Expires, il n'y a pas d'expiration de session, et aucun rafraîchissement n'a à être effectué.


Si l'UAS doit rafraîchir la session, il calcule l'expiration de session. L'expiration de session est l'heure de transmission de la dernière réponse 2xx à une demande de rafraîchissement de session sur ce dialogue plus l'intervalle de session. Si l'UA souhaite continuer la session au delà de l'expiration de session, il DOIT générer un rafraîchissement avant l'expiration de la session. Il est RECOMMANDÉ que ce rafraîchissement soit envoyé dès que la moitié de l'intervalle de session s'est écoulée. Des procédures supplémentaires sont décrites à la Section 10 pour ce rafraîchissement.


10. Réalisation des rafraîchissements


Le côté qui génère un rafraîchissement le fait conformément aux procédures d'UAC définies à la Section 7. Noter que seule une réponse 2xx à une demande de rafraîchissement de session étend l'expiration de session. Cela signifie qu'un UA pourrait tenter un rafraîchissement et recevoir une réponse 422 avec un champ d'en-tête Min-SE qui contient une valeur plus grande que l'intervalle de session actuel. L'UA aura encore à envoyer une demande de rafraîchissement de session avant l'expiration de la session (qui n'a pas changé) même si cette demande contient une valeur de Session-Expires qui est bien plus grande que l'intervalle de session actuel.


Si la transaction de demande de rafraîchissement de session arrive à expiration ou génère une réponse 408 ou 481, l'UAC envoie alors une demande BYE conformément au paragraphe 12.2.1.2 de la [RFC3261]. Si la demande de rafraîchissement de session ne génère pas de réponse 2xx (et, par suite, si la session n'est pas rafraîchie) et si une réponse autre que 408 ou 481 est reçue, l'UAC DEVRAIT suivre les règles spécifiques de ce code de réponse et réessayer si possible. Par exemple, si la réponse est un 401, l'UAC va réessayer la demande avec de nouveaux accréditifs. Cependant, l'UAC NE DEVRAIT PAS continuellement réessayer la demande si le serveur indique la même réponse d'erreur.


De façon similaire, si le côté qui n'effectue pas les rafraîchissements ne reçoit pas une demande de rafraîchissement de session avant l'expiration de la session, il DEVRAIT envoyer un BYE pour terminer la session, légèrement avant l'expiration de session. Le minimum de 32 secondes et d'un tiers de l'intervalle de session est RECOMMANDÉ.


Les pare-feu et NAT ALG peuvent être impitoyables sur le sujet de l'admission du trafic SIP après l'heure d'expiration de la session. C'est pourquoi le BYE devrait être envoyé avant l'expiration.


11. Considérations sur la sécurité


Le temporisateur de session introduit la capacité qu'un mandataire ou élément d'UA force les UA conformes à envoyer des rafraîchissements à un taux du choix de l'élément. Cela introduit la possibilité d'attaques de déni de service avec des propriétés d'amplification significatives. Ces attaques peuvent être lancées de l'extérieur (par des éléments qui tentent de modifier les messages en transit) ou de l'intérieur (par des éléments qui sont légitimement sur le chemin de la demande mais sont destinés à causer des dommages). Heureusement, les deux cas sont traités de façon adéquate par la présente spécification.


11.1 Attaques de l'intérieur

Cela introduit la possibilité que des mandataires ou UA félons introduisent des attaques de déni de service. Cependant, les mécanismes de la présente spécification empêchent cela d'arriver.


D'abord, considérons le cas d'un UAC félon qui souhaite forcer un UAS à générer des rafraîchissements à un taux rapide. Pour ce faire, il insère un champ d'en-tête Session-Expires dans un INVITE avec une faible durée et un paramètre rafraîchisseur égal à uas. Supposons qu'il place un champ d'en-tête Supported dans la demande. L'UAS ou tout mandataire qui fait objection à cette faible temporisation va rejeter la demande avec un 422, empêchant par là l'attaque. Si aucun champ d'en-tête Supported n'est présent, les mandataires vont insérer un champ d'en-tête Min-SE dans la demande avant de la transmettre. Par suite, l'UAS ne choisira pas un temporisateur de session inférieur au minimum permis par tous les éléments du chemin. Cela empêche aussi l'attaque.


Ensuite, considérons le cas d'un UAS félon qui souhaite forcer un UAC à générer des rafraîchissements à un taux rapide. Dans ce cas, l'UAC doit prendre en charge le temporisateur de session. Le INVITE initial arrive à l'UAS félon, qui retourne une 2xx avec un très petit intervalle de session. L'UAC utilise cette temporisation et envoie rapidement un rafraîchissement. Le paragraphe 7.4 exige que l'UAC copie l'intervalle de session en cours dans le champ d'en-tête Session-Expires dans la demande. Cela permet aux mandataires de voir la valeur actuelle. Les mandataires vont rejeter cette demande et fournir un Min-SE avec un minimum plus élevé, que l'UAC va alors utiliser. Noter que si les mandataires n'ont pas rejeté la demande, mais plutôt mandaté la demande avec un champ d'en-tête Min-SE, une attaque serait quand même possible. L'UAS pourrait éliminer ce champ d'en-tête dans une réponse 2xx et forcer l'UAC à continuer de générer des demandes à un taux rapide.


D'une façon similaire, un mandataire félon ne peut pas forcer l'UAC ou l'UAS à générer des rafraîchissements sauf si le mandataire reste sur le chemin de signalisation et voit chaque demande et réponse.


11.2 Attaques de l'extérieur

Un élément qui peut observer et modifier une demande ou réponse en transit peut forcer de rapides rafraîchissements de session. Pour empêcher cela, les demandes et réponses ont été protégées par l'intégrité de message. Comme les champ d'en-tête des temporisateurs de session ne sont pas de bout en bout et sont manipulés par les mandataires, les capacités SIP S/MIME ne conviennent pas pour cette tâche. L'intégrité doit plutôt être protégée en utilisant des mécanismes bond par bond. Par suite, il est RECOMMANDÉ qu'un élément envoie une demande avec un champ d'en-tête Session-Expires ou un champ d'en-tête Supported avec la valeur 'timer' en utilisant TLS. Comme une protection adéquate n'est obtenue que si la sécurité est appliquée sur chaque bond, il est RECOMMANDÉ que le schéma d'URI SIPS soit utilisé en conjonction avec cette extension. Cela signifie que les mandataires qui enregistrent le chemin et demandent le temporisateur de session DEVRAIENT enregistrer le chemin avec un URI SIPS. Un UA qui insère un en-tête Session-Expires dans une demande ou réponse DEVRAIT inclure un URI Contact qui soit un URI SIPS.


12. Considérations relatives à l'IANA


Cette extension définit deux nouveaux champs d'en-tête, un nouveau code de réponse, et une nouvelle étiquette d'option. SIP [RFC3261] définit les procédures de l'IANA pour les enregistrer.


12.1 Enregistrement par l'IANA des champs d'en-tête Min-SE et Session-Expires

L'enregistrement pour le champ d'en-tête Min-SE est le suivant :

Numéro de RFC : RFC 4028

Nom d'en-tête : Min-SE

Forme compacte : aucune


L'enregistrement pour le champ d'en-tête Session-Expires est le suivant :

Numéro de RFC : RFC 4028

Nom d'en-tête : Session-Expires

Forme compacte : x


12.2 Enregistrement par l'IANA du code de réponse 422

L'enregistrement pour le code de réponse 422 (Intervalle de session trop court) est le suivant :

Code de réponse : 422

Phrase de cause par défaut : Intervalle de session trop court

Numéro de RFC: RFC 4028


12.3 Enregistrement par l'IANA de l'étiquette d'option 'timer'

L'enregistrement pour l'étiquette d'option 'timer' est le suivant :

Nom : timer

Description : Cette étiquette d'option est pour la prise en charge de l'extension de temporisateur de session. L'inclusion dans un champ d'en-tête Supported dans une demande ou réponse indique que l'UA peut effectuer des rafraîchissements conformément à la présente spécification. L'inclusion dans un en-tête Require dans une demande signifie que l'UAS doit comprendre l'extension "temporisateur de session" pour traiter la demande. L'inclusion dans un champ d'en-tête Require dans une réponse indique que l'UAC doit chercher le champ d'en-tête Session-Expires dans la réponse et la traiter en conséquence.


13. Exemple de flux d'appel


Exemple de flux de temporisateur de session


Alice Mandataire P1 Mandataire P2 Bob

|(1) INVITE | | |

|SE: 50 | | |

|----------->| | |

|(2) 422 | | |

|MSE: 3600 | | |

|<-----------| | |

|(3) ACK | | |

|----------->| | |

|(4) INVITE | | |

|SE:3600 | | |

|MSE:3600 | | |

|----------->| | |

| |(5) INVITE | |

| |SE:3600 | |

| |MSE:3600 | |

| |----------->| |

| |(6) 422 | |

| |MSE:4000 | |

| |<-----------| |

| |(7) ACK | |

| |----------->| |

|(8) 422 | | |

|MSE:4000 | | |

|<-----------| | |

|(9) ACK | | |

|----------->| | |

|(10) INVITE | | |

|SE:4000 | | |

|MSE:4000 | | |

|----------->| | |

| |(11) INVITE | |

| |SE:4000 | |

| |MSE:4000 | |

| |----------->| |

| | |(12) INVITE |

| | |SE:4000 |

| | |MSE:4000 |

| | |----------->|

| | |(13) 200 OK |

| | |SE:4000 |

| | |<-----------|

| |(14) 200 OK | |

| |SE:4000 | |

| |<-----------| |

|(15) 200 OK | | |

|SE:4000 | | |

|<-----------| | |

|(16) ACK | | |

|----------->| | |

| |(17) ACK | |

| |------------------------>|

|(18) UPDATE | | |

|SE:4000 | | |

|----------->| | |

| |(19) UPDATE | |

| |SE:4000 | |

| |------------------------>|

| |(20) 200 OK | |

| |SE:4000 | |

| |<------------------------|

|(21) 200 OK | | |

|SE:4000 | | |

|<-----------| | |

| |(22) BYE | |

| |<------------------------|

|(23) BYE | | |

|<-----------| | |

| |(24) 408 | |

| |------------------------>|


Figure 1 : Exemple de flux de temporisateur de session


La Figure 1 donne un exemple de flux d'appels qui utilise le temporisateur de session. Dans cet exemple, l'UAC et l'UAS prennent tous deux en charge l'extension de temporisateur de session. La demande initiale INVITE est générée par l'UAC, Alice (message 1), et pourrait ressembler à :


INVITE sips:bob@biloxi.example.com SIP/2.0

Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8

Supported: timer

Session-Expires: 50

Max-Forwards: 70

To: Bob <sips:bob@biloxi.example.com>

From: Alice <sips:alice@atlanta.example.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314159 INVITE

Contact: <sips:alice@pc33.atlanta.example.com>

Content-Type: application/sdp

Content-Length: 142


(Le SDP d'Alice n'est pas montré)


Cette demande indique qu'Alice prend en charge le temporisateur de session, et demande des rafraîchissements de session toutes les 50 secondes. Cela arrive au premier mandataire, P1. Cet intervalle de session est en dessous du minimum permis d'une valeur de 3600. Donc P1 rejette la demande avec un 422 (message 2) :


SIP/2.0 422 Intervalle de session trop court

Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8;received=192.0.2.1

Min-SE: 3600

To: Bob <sips:bob@biloxi.example.com>;tag=9a8kz

From: Alice <sips:alice@atlanta.example.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314159 INVITE


Cette réponse contient un champ d'en-tête Min-SE d'une valeur de 3600. Alice réessaye alors la demande. Cette fois, la demande contient un en-tête Min-SE, car Alice a reçu un 422 pour d'autres demandes INVITE avec le même Call-ID. La nouvelle demande (message 4) pourrait ressembler à :


INVITE sips:bob@biloxi.example.com SIP/2.0

Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds9

Supported: timer

Session-Expires: 3600

Min-SE: 3600

Max-Forwards: 70

To: Bob <sips:bob@biloxi.example.com>

From: Alice <sips:alice@atlanta.example.com>;tag=2568701785


Call-ID: a84b4c76e66710

CSeq: 314160 INVITE

Contact: <sips:alice@pc33.atlanta.example.com>

Content-Type: application/sdp

Content-Length: 142


(Le SDP d'Alice n'est pas montré)


Le mandataire P1 enregistre les chemins. Comme l'intervalle de session lui est maintenant acceptable, il transmet la demande à P2 (message 5). Cependant, l'intervalle de session est inférieur à la quantité minimum configurée de 4000. Il rejette donc la demande avec un code de réponse 422 (message 6) et inclut un champ d'en-tête Min-SE avec la valeur de 4000. Là encore, Alice réessaye le INVITE. Cette fois, le champ d'en-tête Min-SE dans son INVITE est le maximum de tous les Min-SE qu'elle a reçu (3600 et 4000).


Le message 10 pourrait ressembler à:


INVITE sips:bob@biloxi.example.com SIP/2.0

Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10

Supported: timer

Session-Expires: 4000

Min-SE: 4000

Max-Forwards: 70

To: Bob <sips:bob@biloxi.example.com>

From: Alice <sips:alice@atlanta.example.com>;tag=5647301796


Call-ID: a84b4c76e66710

CSeq: 314161 INVITE

Contact: <sips:alice@pc33.atlanta.example.com>

Content-Type: application/sdp

Content-Length: 142


(Le SDP d'Alice n'est pas montré)


P1 enregistre encore une fois les chemins, mais P2 ne le fait pas (cela ne devrait normalement pas se produire ; vraisemblablement, si il a demandé la temporisateur de session, il devrait enregistrer le chemin de la demande suivante). L'UAS reçoit la demande. Il copie l'en-tête Session-Expires de la demande dans la réponse et ajoute un paramètre rafraîchisseur de la valeur 'uac'. Ce 200 OK est retransmis à Alice. La réponse qu'elle reçoit (message 15) pourrait ressembler à :


SIP/2.0 200 OK

Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds10;received=192.0.2.1Require: timer

Supported: timer

Record-Route: sips:p1.atlanta.example.com;lr

Session-Expires: 4000;rafraîchisseur=uac

To: Bob <sips:bob@biloxi.example.com>;tag=9as888nd

From: Alice <sips:alice@atlanta.example.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314161 INVITE

Contact: <sips:bob@192.0.2.4>

Content-Type: application/sdp

Content-Length: 142


(Le SDP de Bob n'est pas montré)


Alice génère un ACK (message 16) qui est acheminé par P1 et ensuite à Bob. Comme Alice est le rafraîchisseur, environ 2000 secondes plus tard Alice envoie une demande UPDATE pour rafraîchir la session. Comme cette demande fait partie d'un dialogue établi et qu'Alice n'a pas reçu de réponse 422 ou de demande sur ce dialogue, il n'y a pas de champ d'en-tête Min-SE dans sa demande (message 18):


UPDATE sips:bob@192.0.2.4 SIP/2.0

Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds12

Route: sips:p1.atlanta.example.com;lr

Supported: timer

Session-Expires: 4000;rafraîchisseur=uac

Max-Forwards: 70

To: Bob <sips:bob@biloxi.example.com>;tag=9as888nd

From: Alice <sips:alice@atlanta.example.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314162 UPDATE

Contact: <sips:alice@pc33.atlanta.example.com>


Ceci est transmis par P1 à Bob. Bob génère un 200 OK, copie le champ d'en-tête Session-Expires dans la réponse. Elle est transmise par P1 et arrive à Alice. La réponse qu'elle reçoit (message 21) peut ressembler à :


SIP/2.0 200 OK

Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds12;received=192.0.2.1

Require: timer

Session-Expires: 4000;rafraîchisseur=uac

To: Bob <sips:bob@biloxi.example.com>;tag=9as888nd

From: Alice <sips:alice@atlanta.example.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314162 UPDATE

Contact: <sips:bob@192.0.2.4>


Peu après, l'UA d'Alice tombe en panne. Par suite, elle n'envoie pas de demande de rafraîchissement de session. 3968 secondes plus tard Bob arrive en fin de temporisation et envoie une demande BYE (message 22). Il est envoyé à P1. P1 tente de le livrer mais échoue (parce que l'UA d'Alice est en panne). P1 retourne alors un 408 (Fin de temporisation de demande) à Bob.


14. Remerciements


Les auteurs tiennent à remercier Brett Tate de ses contributions à ce travail. Brian Rosen a participé à l'édition du document.


15. Références

15.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.


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


[RFC3264] J. Rosenberg et H. Schulzrinne, "Modèle d'offre/réponse avec le protocole de description de session (SDP)", juin 2002.


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


15.2 Références pour information


[RFC2663] P. Srisuresh, M. Holdrege, "Terminologie et considérations sur les traducteurs d'adresse réseau IP (NAT)", août 1999. (Information)


[RFC3262] J. Rosenberg et H. Schulzrinne, "Fiabilité des réponses provisoires dans le protocole d'initialisation de session (SIP)", juin 2002. (P.S.)


[RFC3265] A.B. Roach, "Notification d'événement spécifique du protocole d'initialisation de session (SIP)", juin 2002. (MàJ par RFC6446) (Remplacée par la RFC6665)


[RFC3550] H. Schulzrinne, S. Casner, R. Frederick et V. Jacobson, "RTP : un protocole de transport pour les applications en temps réel", STD 64, juillet 2003. (MàJ par RFC7164, RFC7160)


Adresse des auteurs


Steve Donovan

Jonathan Rosenberg

Cisco Systems, Inc.

Cisco Systems, Inc.

2200 E. President George Bush Turnpike

Richardson, Texas 75082

USA

USA

mél : srd@cisco.com

mél : jdrosen@cisco.com


Déclaration des droits de reproduction


Copyright (C) The Internet Society (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 qui y sont 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 ci 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 pourraient ê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 actuellement fourni par la Internet Society.