Fiabilité des réponses provisoires dans le protocole d’initiation 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 discussion 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é
Le présent document spécifie une extension au protocole d’initiation de session (SIP, Session Initiation Protocol) pour fournir des messages fiables de réponse provisoire. Cette extension utilise l’étiquette d’option 100rel et définit la méthode d’accusé de réception de réponse provisoire (PRACK, Provisional Response ACKnowledgement).

Table des matières

1 Introduction
2 Terminologie
3 Comportement de l’UAS
4 Comportement de l’UAC
5 Modèle d’offre/réponse et PRACK
6 Définition de la méthode PRACK
7 Définitions de champ d’en-tête
7.1 RSeq
7.2 RAck
8 Considérations relatives à l’IANA
8.1 Enregistrement IANA de l’étiquette d’option 100rel
8.2 Enregistrement IANA des en-têtes RSeq et RAck
9 Considérations pour la sécurité
10 Collected BNF
11 Remerciements
12 Références normatives
13 Référence informative
14 Adresse des auteurs
15 Déclaration complète de droits de reproduction

1 Introduction

Le protocole d’initiation de session (SIP) (RFC 3261 [1]) est un protocole de demande-réponse pour initier et gérer des sessions de communication. SIP définit deux types de réponses, provisoires et finales. Les réponses finales apportent le résultat du traitement de la demande, et leur envoi est fiable. Les réponses provisoires fournissent des informations sur les progrès du traitement de la demande, mais leur envoi n’est pas fiable dans la RFC 3261.

Il a été observé par la suite que la fiabilité était importante dans plusieurs cas, y compris celui des scénarios d’interopérabilité avec le RTPC. Il était donc nécessaire de disposer d’une capacité facultative à prendre en charge la transmission fiable des réponses provisoires. Cette capacité est fournie dans la présente spécification.

Le mécanisme de fiabilité fonctionne en reflétant les mécanismes actuels de fiabilité pour les réponses finales 2xx à INVITE. Ces demandes sont transmises périodiquement par l’utilisateur de transaction (TU, Transaction User) jusqu’à une transaction distincte, ACK, soit reçue pour indiquer la réception de la réponse 2xx par l’UAC. La fiabilité pour les réponses 2xx à INVITE et les messages ACK est de bout en bout. Afin de réaliser la fiabilité pour les réponses provisoires, on fait presque la même chose. Les réponses provisoires fiables sont retransmises par le TU avec un retour exponentiel. Ces retransmissions cessent lorsqu’un message PRACK est reçu. La demande PRACK joue le même rôle que ACK, mais pour les réponses provisoires. Il y a cependant une différence importante. PRACK est un message SIP normal, comme BYE. En tant que tel, sa propre fiabilité est assurée bond par bond à travers chaque mandataire à états pleins. Tout comme BYE, mais à la différence de ACK, PRACK a sa propre réponse. Si ce n’était pas le cas, le message PRACK ne pourrait pas traverser les serveurs mandataires conformes à la RFC 2543 [4].

Chaque réponse provisoire reçoit un numéro de séquence, porté dans le champ RSeq dans la réponse. Les messages PRACK contiennent un champ d’en-tête RAck, qui indique le numéro de séquence de la réponse provisoire dont il est accusé réception. Les accusés de réception ne sont pas cumulatifs, et les spécifications recommandent une seule réponse provisoire en cours à la fois, pour les besoins du contrôle d’encombrement.

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

3 Comportement de l’UAS

Un UAS PEUT envoyer de façon fiable toute réponse provisoire non 100 à INVITE, pour autant que la demande INVITE initiale (la demande à laquelle la réponse provisoire est envoyée de façon fiable) contienne un champ d’en-tête Supported avec l’étiquette d’option 100rel. Bien que la présente spécification ne permette de réponses provisoires fiables que pour la méthode INVITE, les extensions qui définissent de nouvelles méthodes qui peuvent établir des dialogues peuvent faire usage de ce mécanisme.

L’UAS DOIT envoyer fiablement toute réponse provisoire non 100 si la demande initiale contenait un champ d’en-tête Require avec l’étiquette d’option 100rel. Si l’UAS ne vaut pas faire comme cela, il DOIT rejeter la demande initiale avec une réponse 420 (Mauvaise extension) et inclure un champ d’en-tête Unsupported (non pris en charge) contenant l’étiquette d’option 100rel.

Un UAS NE DOIT PAS essayer d’envoyer fiablement une réponse 100 (En essai). Seules les réponses provisoires numérotées de 101 à 199 peuvent être envoyées de façon fiable. Si la demande ne comportait ni un champ d’en-tête Supported ni un champ d’en-tête Require indiquant cette caractéristique, l’UAS NE DOIT PAS envoyer fiablement la réponse provisoire.

Les réponses 100 (En essai) sont seulement de bond à bond. Pour cette raison, les mécanismes de fiabilité décrits ici, qui sont de bout en bout, ne peuvent pas être utilisés.

Un élément qui peut agir comme mandataire peut aussi envoyer des réponses provisoires fiables. Dans ce cas, il agit comme un UAS pour les besoins de cette transaction. Cependant, il NE DOIT PAS essayer de faire ainsi pour toute demande qui contient une étiquette dans le champ To. C’est-à-dire qu’un mandataire ne peut pas générer des réponses provisoires fiables à des demandes envoyées dans le contexte d’un dialogue. Bien sûr, à la différence d’un UAS, lorsque l’élément mandataire reçoit un PRACK qui ne correspond à aucune réponse provisoire fiable en cours, le PRACK DOIT être mandaté.

Un UAS peut vouloir envoyer une réponse provisoire fiable pour plusieurs raisons. L’une d’elles est que la transaction INVITE va prendre un certain temps pour générer une réponse finale. Comme exposé au paragraphe 13.3.1.1 de la RFC 3261, l’UAS aura besoin d’envoyer des réponses provisoires périodiques pour demander une "extension" de la transaction chez les mandataires. L’exigence est qu’un mandataire les reçoive toutes les trois minutes, mais l’UAS a besoin de les envoyer plus fréquemment (une fois par minute est recommandé) à cause de la possibilité d’une perte de paquet. Pour une solution plus efficace, l’UAS peut envoyer la réponse de façon fiable, auquel cas l’UAS DEVRAIT envoyer des réponses provisoires toutes les deux minutes et demi. L’utilisation des réponses provisoires fiables pour l’extension des transactions est RECOMMANDÉE.

Le reste de cet exposé suppose que la demande initiale contenait un champ d’en-tête Supported ou Require avec 100rel, et qu’il y a une réponse provisoire à envoyer de façon fiable.

La réponse provisoire à envoyer de façon fiable est construite par le noyau d’UAS conformément aux procédures du paragraphe 8.2.6 de la RFC 3261. De plus, elle DOIT contenir un champ d’en-tête Require avec l’étiquette d’option 100rel, et DOIT inclure un champ d’en-tête RSeq. La valeur du champ d’en-tête pour la première réponse provisoire fiable d’une transaction DOIT être entre 1 et 2**31 - 1. Il est RECOMMANDÉ qu’elle soit choisie de façon uniforme dans cette gamme. L’espace de numérisation RSeq est dans une seule transaction. Cela signifie que les réponses provisoires pour des demandes différentes PEUVENT utiliser les mêmes valeurs pour le numéro de RSeq.

La réponse provisoire fiable PEUT contenir un corps. L’utilisation des descriptions de session est décrite à la Section 5.

La réponse provisoire fiable est passée périodiquement à la couche de transaction avec un intervalle qui commence à T1 secondes et double à chaque retransmission (T1 est défini à la Section 17 de la RFC 3261). Une fois passée au serveur de transaction, elle est ajoutée à une liste interne de réponses provisoires fiables dont il n’a pas été accusé réception. La couche de transaction va transmettre chaque retransmission passée depuis le noyau de l’UAS.

Ceci diffère des retransmissions de réponses 2xx, dont les intervalles culminent à T2 secondes. Cela parce que les retransmissions des ACK sont déclanchées par la réception d’une 2xx, mais les retransmissions de PRACK ont lieu indépendamment de la réception d’une 1xx.

Les retransmissions de la réponse provisoire fiable cessent lorsqu’un PRACK correspondant est reçu par le noyau d’UA. PRACK est comme toute autre demande au sein d’un dialogue, et le noyau d’UAS le traite conformément aux procédures des paragraphes 8.2 et 12.2.2 de la RFC 3261. Un PRACK correspondant est défini comme celui qui correspond au sein du même dialogue que la réponse, et dont la méthode, le numéro CSeq-num, et le numéro response-num dans le champ d’en-tête RAck, correspondent respectivement, à la méthode provenant du CSeq, au numéro de séquence venant du CSeq, et au numéro de séquence venant du RSeq de la réponse provisoire fiable.

Si une demande PRACK est reçue par le noyau d’UA et ne correspond à aucune réponse provisoire fiable dont il n’a pas été accusé réception, l’UAS DOIT répondre au PRACK par une réponse 481. Si le PRACK ne correspond pas à une réponse provisoire fiable dont il n’a pas été accusé réception, il DOIT y être répondu par une réponse 2xx. L’UAS peut être certain à ce point que la réponse provisoire a été reçue dans l’ordre. Il DEVRAIT cesser les retransmissions de la réponse provisoire fiable, et DOIT la retirer de la liste des réponses provisoires sans accusé de réception.

Si une réponse provisoire fiable est retransmise depuis 64*T1 secondes sans réception d’un PRACK correspondant, l’UAS DEVRAIT rejeter la demande originale avec une réponse 5xx.

Si le PRACK contenait une description de session, il est traité comme décrit à la Section 5 du présent document. Si, au lieu de cela, le PRACK contenait tout autre type de corps, le corps est traité de la même façon qu’un corps serait traité dans un ACK.

Après qu’il ait été accusé réception de la première réponse provisoire fiable pour une demande, l’UAS PEUT envoyer des réponses provisoires fiables supplémentaires. L’UAS NE DOIT PAS envoyer une seconde réponse provisoire fiable tant qu’il n’a pas été accusé réception de la première. Après la première, il est RECOMMANDÉ que l’UAS n’envoie pas une réponse provisoire fiable supplémentaire jusqu’à ce qu’il ait été accusé réception de la première. La première réponse provisoire fiable reçoit un traitement particulier parce qu’elle porte le numéro de séquence initial. Si des réponses provisoires fiables supplémentaires étaient envoyées avant l’accusé de réception de la première, l’UAS ne pourrait pas être certain qu’elles ont été reçues dans l’ordre.

La valeur de RSeq dans chaque réponse provisoire fiable suivante pour la même demande DOIT être exactement supérieur de un. Les numéros de RSeq NE DOIVENT PAS revenir à zéro. Parce que le numéro initial est choisi comme étant inférieur à 2**31 - 1, mais que le maximum est 2**32 - 1, il peut y avoir jusqu’à 2**31 réponses provisoires fiables par demande, ce qui est plus que suffisant.

L’UAS PEUT envoyer une réponse finale à la demande initiale avant d’avoir reçu des PRACK pour toutes les réponses provisoires fiables sans accusé de réception, sauf si la réponse finale est 2xx et si une des réponses provisoires fiables sans accusé de réception contenait une description de session. Dans ce cas, il NE DOIT PAS envoyer de réponse finale jusqu’à ce que des réponses provisoires aient reçu un accusé de réception. Si l’UAS n’envoie pas de réponse provisoire alors que des réponses fiables sont toujours sans accusé de réception, il NE DEVRAIT PAS continuer à retransmettre des réponses provisoires fiables sans accusé de réception, mais il DOIT être prêt à traiter les demandes PRACK pour ces réponses en instance. Un UAS NE DOIT PAS envoyer de nouvelles réponses provisoires fiables (par opposition aux retransmissions de celles qui ont eu un accusé de réception) après l’envoi d’une réponse finale à une demande.

4 Comportement de l’UAC

Lorsqu’un UAC crée une nouvelle demande, il peut insister pour une livraison fiable des réponses provisoires pour cette demande. Pour faire cela, il insère un champ d’en-tête Require avec l’étiquette d’option 100rel dans la demande. Un en-tête Require avec la valeur de 100rel NE DOIT PAS être présent dans une demande excepté INVITE, bien que des extensions à SIP puissent permettre son usage avec d’autres méthodes de demande.

Tableau 1 : Résumé des champs d’en-tête, A à O

Tableau 2 : Résumé des champs d’en-tête, P à Z

Si l’UAC ne souhaite pas insister pour l’usage des réponses provisoires fiables, mais indique simplement qu’il les accepte si l’UAS a besoin d’en envoyer une, un en-tête Supported DOIT être inclus dans la demande avec l’étiquette d’option 100rel. L’UAC DEVRAIT l’inclure dans toutes les demandes INVITE.

Si une réponse provisoire est reçue pour une demande initiale, et si cette réponse contient un champ d’en-tête Require qui contient l’étiquette d’option 100rel, la réponse est à envoyer de façon fiable. Si la réponse est 100 (En essai) (par opposition à de 101 à 199), cette étiquette d’option DOIT être ignorée, et les procédures ci-dessous NE DOIVENT PAS être utilisées.

La réponse provisoire DOIT établir un dialogue s’il n’en a déjà été créé un.

En supposant que la réponse est à transmettre de façon fiable, l’UAC DOIT créer une nouvelle demande avec la méthode PRACK. Cette demande est envoyée au sein du dialogue associé à la réponse provisoire (bien sûr, la réponse provisoire peut avoir créé le dialogue). Les demandes PRACK PEUVENT contenir un corps, qui sera interprété conformément à son type et sa disposition.

Noter que PRACK est comme toute autre demande non INVITE au sein d’un dialogue. En particulier, un UAC NE DEVRAIT PAS retransmettre la demande PRACK lorsqu’il reçoit un accusé de réception de retransmission de la réponse provisoire, bien que de faire ainsi ne crée pas une erreur de protocole.

Une fois qu’une réponse provisoire fiable est reçue, les retransmissions de cette réponse DOIVENT être supprimées. Une réponse est une retransmission lorsque son identifiant de dialogue, son CSeq, et son RSeq correspondent à celui de la réponse d’origine. L’UAC DOIT maintenir un numéro de séquence qui indique les réponses provisoires fiables les plus récemment reçues dans l’ordre pour la demande initiale. Ce numéro de séquence DOIT être maintenu jusqu’à réception de la réponse final pour la demande initiale. Sa valeur DOIT être initialisée pour le champ d’en-tête RSeq dans la première réponse provisoire fiable reçue pour la demande initiale.

Le traitement des réponses provisoires fiables suivantes pour la même demande initiale suit les mêmes règles que ci-dessus, avec la différence suivante : les réponses provisoires fiables sont garanties dans le bon ordre. Il en résulte que si l’UAC reçoit une autre réponse provisoire fiable à la même demande, et si la valeur RSeq n’est pas supérieure de un à la valeur du numéro de séquence, cette réponse NE DOIT PAS recevoir d’accusé de réception avec un PRACK, et NE DOIT PAS être autrement traitée par l’UAC. Une mise en œuvre PEUT éliminer la réponse, ou PEUT mettre la réponse en mémoire cache dans l’espoir de recevoir les réponses manquantes.

L’UAC PEUT accuser réception des réponses provisoires fiables reçues après la réponse finale ou PEUT les éliminer.

5 Modèle d’offre/réponse et PRACK

La RFC 3261 décrit les lignes directrices pour les ensembles de messages dans lesquels les offres et les réponses [3] peuvent apparaître. Sur la base de ces lignes directrices, la présente extension fournit des opportunités supplémentaires d’échanges offre/réponse.

Si l’INVITE contenait une offre, l’UAS PEUT générer une réponse dans une réponse provisoire fiable (en supposant qu’elles sont acceptées par l’UAC). Il en résulté l’établissement de la session avant l’achèvement de la réalisation de l’appel. De même, si une réponse provisoire fiable est le premier message fiable renvoyée à l’UAC, et si l’INVITE ne contenait pas d’offre, il DOIT en apparaître une dans cette réponse provisoire fiable.

Si l’UAC reçoit une réponse provisoire fiable avec une offre (ce qui arriverait si l’UAC envoie une INVITE sans offre, auquel cas la première réponse provisoire fiable contiendra l’offre), il DOIT générer une réponse dans le PRACK. Si l’UAC reçoit une réponse provisoire fiable avec une réponse, il PEUT générer une offre supplémentaire dans le PRACK. Si l’UAS reçoit un PRACK avec une offre, il DOIT placer la réponse dans la 2xx au PRACK.

Une fois qu’une réponse a été envoyée ou reçue, l’UA DEVRAIT établir la session sur la base des paramètres de l’offre et de la réponse, même si l’INVITE original lui-même n’a pas reçu de réponse.

Si l’UAS avait placé une description de session dans toute réponse provisoire fiable qui n’a pas reçu d’accusé de réception au moment de l’acceptation de l’INVITE, l’UAS DOIT retarder l’envoi de la 2xx jusqu’à ce qu’il ait été accusé réception de la réponse provisoire. Autrement, la fiabilité du 1xx ne peut pas être garantie, et la fiabilité est nécessaire pour le bon fonctionnement de l’échange offre/réponse.

Tous les agents d’utilisateur qui prennent en charge cette extension DOIVENT accepter tous les échanges offre/réponse possibles sur la base des règles du paragraphe 13.2 de la RFC 3261, fondées sur l’existence de INVITE et PRACK comme demandes, et sur 2xx et 1xx fiable comme réponses fiables de non échec.

6 Définition de la méthode PRACK

La présente spécification définit une nouvelle méthode SIP, PRACK. La sémantique de cette méthode est décrite ci-dessus. Les tableaux 1 et 2 étendent les tableaux 2 et 3 de la RFC 3261 pour cette nouvelle méthode.

7 Définitions de champ d’en-tête

La présente spécification définit deux nouveaux champs d’en-tête, RAck et RSeq. Le tableau 3 étend les tableaux 2 et 3 tirés de la RFC 3261 pour ces en-têtes.

Tableau 3 : Champs d’en-tête RAck et RSeq

7.1 RSeq

L’en-tête RSeq est utilisé dans les réponses provisoires afin de les transmettre de façon fiable. Il contient une seule valeur numérique de 1 à 2**32 - 1. Pour des précisions sur son utilisation, voir à la Section 3.

Exemple :

RSeq: 988789

7.2 RAck

L’en-tête RAck est envoyé dans une demande PRACK pour prendre en charge la fiabilité des réponses provisoires. Il contient deux nombres et une étiquette de méthode. Le premier nombre est la valeur tirée de l’en-tête RSeq dans la réponse provisoire dont il est accusé réception. Le nombre suivant, et la méthode, sont copiés de CSeq dans la réponse dont il est accusé réception. Le nom de la méthode dans l’en-tête RAck est sensible à la casse.

Exemple :

RAck: 776656 1 INVITE

8 Considérations relatives à l’IANA

Le présent document enregistre une nouvelle étiquette d’option et deux nouveaux en-têtes, sur la base du processus d’enregistrement IANA de la RFC 3261.

8.1 Enregistrement IANA de l’étiquette d’option 100rel

La présente spécification enregistre une seule étiquette d’option, 100rel. Les informations nécessaires à cet enregistrement, comme spécifié dans la RFC 3261, sont :

Nom : 100rel

Description : Cette étiquette d’option est pour la fiabilité des réponses provisoires. Lorsqu’elle est présente dans un en-tête Supported, elle indique que l’UA peut envoyer ou recevoir des réponses provisoires fiables. Lorsqu’elle est présente dans un en-tête Require d’une demande, elle indique que l’UAS DOIT envoyer toutes les réponses provisoires de façon fiable. Présente dans un en-tête Require dans une réponse provisoire fiable, elle indique que l’envoi de la réponse est fiable.

8.2 Enregistrement IANA des en-têtes RSeq et RAck

Ci-après figure l’enregistrement pour l’en-tête RSeq :

Numéro de RFC : RFC3262
Nom d’en-tête : RSeq
Forme compacte : aucune

Ci-après figure l’enregistrement pour l’en-tête RAck :

Numéro de RFC : RFC3262
Nom d’en-tête : RAck
Forme compacte : aucune

9 Considérations pour la sécurité

La demande PRACK peut être injectée par des attaquants pour forcer la cessation des retransmissions de réponses provisoires fiables. Comme ces réponses peuvent convoyer des informations importantes, les messages PRACK devraient être authentifiés comme toute autre demande. Les procédures d’authentification sont spécifiées dans la RFC 3261.

10 BNF

Le BNF pour les en-têtes RAck et RSeq et la méthode PRACK sont définis ici.

PRACKm = %x50.52.41.43.4B ; PRACK in caps

Method = INVITEm / ACKm / OPTIONSm / BYEm / CANCELm / REGISTERm / PRACKm / extension-method

RAck = "RAck" HCOLON response-num LWS CSeq-num LWS Method

response-num = 1*DIGIT

CSeq-num = 1*DIGIT

RSeq = "RSeq" HCOLON response-num

11 Remerciements

Les auteurs tiennent à remercier Jo Hornsby, Jonathan Lennox, Rohan Mahy, Allison Mankin, Adam Roach et Tim Schroeder pour leurs commentaires sur le présent document.

12 Références normatives

[1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley et E. Schooler, "SIP: Protocole d’initiation de session", RFC 3261, juin 2002.

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

[3] J. Rosenberg et H. Schulzrinne, "Modèle d’offre/réponse avec SDP", RFC 3264, juin 2002.

13 Référence informative

[4] M. Handley, H. Schulzrinne, E. Schooler et J. Rosenberg, "SIP : Protocole d’initiation de session", RFC 2543, mars 1999.

14 Adresse des auteurs

15 Déclaration complète de droits de reproduction

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

e 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 copyright ci-dessus et le présent et 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 copyright 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 copyright 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 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.

Remerciement

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