Groupe de travail Réseau

Intégration de la gestion de ressource
et du protocole d’initialisation de session (SIP)

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.

Le présent document définit un cadre générique pour les préconditions, qui sont extensibles par enregistrement auprès de l’IANA. Le présent document expose aussi comment la qualité de service réseau peut devenir une précondition pour l’établissement de sessions initiées par le protocole d’initialisation de session (SIP, Session Initiation Protocol). Ces préconditions exigent que le participant réserve les ressources réseau avant de continuer la session. On ne définit pas de nouveaux mécanismes de réservation de qualité de service ; ces préconditions exigent simplement qu’un participant utilise les mécanismes de réservation de ressource existants avant de commencer la session.

Table des Matières

1. Introduction 1

2. Terminologie 2

3. Généralités 2

4. Paramètres de SDP 3

5. Usage de préconditions avec offre/réponse 4

5.1 Génération d’une offre 4

5.2 Génération d’une réponse 6

6. Suspension et reprise d’établissement de session 6

7. Confirmation d’état 7

8. Refus d’une offre 7

8.1 Rejet d’un flux de données 8

9. Type de précondition inconnu 8

10. Préconditions multiples par flux de données 9

11. Étiquette d’option pour les préconditions 9

12. Indication des capacités 9

13. Exemples 9

13.1 Type d’état de bout en bout 9

13.2 Type d’état segmenté 12

13.3 Offre dans une réponse SIP 12

14 Considérations sur la sécurité 14

15 Considérations relatives à l’IANA 14

16 Notice concernant les droits de propriété intellectuelle 15

17 Références 15

18 Contributeurs 15

19 Remerciements 16

20 Adresse des auteurs 16

21 Déclaration complète de droits de reproduction 16

Certaines architectures exigent qu’au moment de l’établissement de la session, une fois que l’appelé a été alerté, les chances d’un échec de l’établissement d’une session soient minimales. Une source d’échec est l’incapacité à réserver les ressource du réseau pour une session. Afin de minimiser les "anneaux fantômes", il est nécessaire de réserver des ressources réseau pour la session avant que l’appelé soit alerté. Cependant, la réservation des ressources réseau exige fréquemment d’apprendre de l’appelé l’adresse IP, l’accès, et les paramètres de session. Ces informations sont obtenues à la suite de l’échange initial offre/réponse porté par SIP. Cet échange cause normalement une "sonnerie de téléphone", introduisant donc un problème de l’œuf et de la poule : les ressources ne peuvent pas être réservées sans effectuer un échange initial offre/réponse, et l’échange initial offre/réponse ne peut être fait sans effectuer la réservation de ressources.

La solution est d’introduire le concept d’une précondition. Une précondition est un ensemble de contraintes sur la session qui sont introduites dans l’offre. Le receveur de l’offre génère une réponse, mais n’alerte pas l’usager ni ne procède par ailleurs à l’établissement de session. Cela n’intervient que lorsque les préconditions sont satisfaites. Cela peut être su par un événement local (comme une confirmation d’une réservation de ressources) ou par l’envoi d’une nouvelle offre par l’appelant.

Le présent document traite des sessions qui utilisent SIP [RFC3261] comme protocole de signalisation et SDP [RFC2327] pour décrire les paramètres de la session.

On a choisi d’inclure les préconditions de qualité de service dans la description SDP plutôt que dans l’en-tête SIP parce que les préconditions sont spécifiques du flux.

Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans le BCP 14, [RFC2119].

Pour s’assurer que l’établissement de session ne se fait pas tant que certaines préconditions ne sont pas satisfaites, on distingue deux variables d’état différentes qui affectent un flux de données particulier : l’état actuel et l’état désiré. Le présent document définit l’état de qualité de service. L’état désiré consiste en un seuil pour l’état actuel. L’établissement de session s’arrête jusqu’à ce que l’état actuel atteigne ou dépasse ce seuil. Une fois que le seuil est atteint ou dépassé, l’établissement de session reprend.

Par exemple, les valeurs suivantes pour les états actuel et désiré ne permettraient pas la reprise de l’établissement de session :

état désiré = ressources réservées dans les deux directions (envoi-réception)

D’un autre côté, les valeurs de l’exemple ci-dessous feraient reprendre l’établissement de session :

état actuel = ressources réservées dans les deux directions (envoi-réception)

Ces deux variables d’état définissent une certaine partie d’état d’un flux de données de la même façon que l’attribut de direction ou que les codecs utilisés définissent d’autres pièces d’état. Par conséquent, on traite ces deux nouvelles variables de la même façon que sont traités les autres attributs de support SDP dans le modèle offre/réponse utilisé par SIP [RFC3264] : ils sont échangés entre deux agents d’utilisateur qui se servent d’une offre et d’une réponse afin d’avoir une vue commune de l’état de la session.

La Figure 1 montre un échange de message typique entre deux agents d’utilisateur SIP qui utilisent des préconditions. A inclut les préconditions de qualité de service dans la SDP de l’INVITE initial. A ne veut pas que B soit alerté jusqu’à ce que les ressources réseau soient réservées dans les deux directions (envoi-réception) de bout en bout. B est d’accord pour réserver les ressources réseau pour cette session avant d’alerter l’appelé. B va traiter la réservation de ressources dans la direction B->A, mais il a besoin que A traite la direction A->B. Pour indiquer cela, B retourne une réponse 183 (Session en cours) à A demandant à A de démarrer la réservation de ressource et de confirmer à B aussitôt que la direction A->B est prête pour la session. A et B commencent tous deux la réservation de ressource. B termine la réservation de ressources dans la direction B->A, mais n’alerte pas encore l’usager, parce que des ressources réseau dans les deux directions sont nécessaires. Lorsque A a terminé la réservation des ressources dans la direction A->B, il envoie un UPDATE [RFC3311] à B. B retourne une réponse 200 (OK) à l’UPDATE, indiquant que toutes les préconditions pour la session sont satisfaites. À ce moment, B commence à alerter l’usager, et l’établissement de session se termine normalement.

état-actuel = "a=actuel:" type-de-précondition SP type-d’état SP étiquette-de-direction

état-désiré = "a=des:" type-de-précondition SP étiquette-de-force SP type-d’état SP étiquette-de-direction

état-confirmé = "a=conf:" type-de-précondition SP type-d’état SP étiquette-de-direction

étiquette-de-force = ("obligatoire" | "facultatif" | "aucune" = | "échec" | "inconnu")

étiquette-de-direction = ("aucune" | "envoi" | "réception" | "envoi-réception")

État actuel : L’attribut État actuel porte l’état actuel des ressources réseau pour un flux de données particulier.

État désiré : l’attribut État désiré porte les préconditions pour un flux de données particulier. Lorsque l’étiquette de direction de l’attribut État actuel, avec le type-de-précondition/type-d’état donné pour un flux particulier est égal (ou meilleur que) l’étiquette de direction de l’attribut État désiré avec les mêmes type-de précondition/type-d’état, pour ce flux, les préconditions sont alors considérées comme satisfaites pour ce flux.

État confirmé : l’attribut État confirmé porte les conditions de seuil pour un flux de données. Lorsque l’état des ressources du réseau atteint ces conditions, l’agent d’utilisateur homologue envoie une mise à jour de la description de session contenant un attribut d’état actuel mis à jour pour ce flux de données particulier.

Type de précondition : le présent document définit des préconditions de qualité de service. Des extensions pourront définir d’autres types de préconditions.

Étiquette de force : l’étiquette de force indique si l’appelé peut ou non être alerté, en cas d’incapacité du réseau à satisfaire les préconditions.

Type d’état : on définit deux types d’état : de bout en bout, et segmenté. L’état de bout en bout reflète l’état d’une réservation de ressources de bout en bout. L’état segmenté reflète l’état des réservations des réseaux d’accès des deux agents d’utilisateur. L’état de bout en bout correspond à l’étiquette "e2e", définie ci-dessus, et l’état segmenté correspond aux étiquettes "local" et "distant". L’état de bout en bout est utile lorsque les mécanismes de réservation de ressource de bout en bout sont disponibles. L’état segmenté est utile lorsque un UA ou les deux effectuent les réservations de ressources sur leurs réseaux d’accès respectifs.

Étiquette de direction : étiquette-de-direction indique la direction dans laquelle un attribut particulier (état actuel, désiré ou confirmé) est applicable.

Les valeurs des étiquettes "envoi", "réception", "local" et "distant" représentent le point de vue de l’entité qui génère la description SDP. Dans une offre, "envoi" est la direction offreur->répondant et "local" est le réseau d’accès de l’offreur. Dans une réponse, "envoi" est la direction répondant->offreur et "local" est le réseau d’accès du répondant.

L’exemple suivant montre ces nouveaux attributs SDP dans deux lignes de support d’une description de session :

La négociation de paramètre dans SIP est effectuée en utilisant le modèle d’offre/réponse décrit dans la [RFC3264]. L’idée du modèle est de fournir une vue partagée des paramètres de la session pour les deux agents d’utilisateur une fois que la réponse a été reçue par l’offreur. La présente section décrit les valeurs que nos nouveaux attributs SDP peuvent prendre dans une réponse, selon leur valeur dans l’offre.

Pour réaliser une vue partagée de l’état d’un flux de données, on définit un modèle qui consiste en trois tableaux : les deux agents d’utilisateur mettent en œuvre un tableau d’état local, et chaque échange offre/réponse est associé à un tableau d’état de transaction. L’offreur génère un tableau d’état de transaction, identique à son tableau d’état local, et l’envoie à celui qui répond dans l’offre. Celui qui répond utilise les informations de ce tableau d’état de transaction pour mettre à jour son tableau d’état local. Celui qui répond met aussi à jour les champs du tableau d’état de transaction qui étaient périmés et retourne ce tableau à l’offreur dans la réponse. L’offreur peut alors mettre à jour son tableau d’état local avec les informations reçues dans la réponse. Après cet échange offre/réponse, les tableaux d’état local des deux agents d’utilisateur sont synchronisés. Ils ont maintenant une vue commune de l’état du flux de données. Les sessions qui impliquent plusieurs flux de données mettent en œuvre ces tableaux par flux de données. Noter cependant que c’est un modèle de comportement d’agent d’utilisateur, pas un logiciel. Une mise en œuvre est libre de suivre toute approche convenable pour reproduire le comportement externe que définit ce modèle.

Les deux agents d’utilisateur DOIVENT conserver un état de précondition local, qu’on appelle un "tableau d’état local". Les tableaux 1 et 2 montrent le format de ces tableaux pour les deux types d’état de bout en bout et segmenté. Pour le type d’état de bout en bout, le tableau contient deux rangées ; une pour chaque direction (c’est-à-dire, envoi et réception). Une valeur de "oui" dans le champ "actuel" indique la réussite de la réservation de cette ressource dans la direction correspondante. "Non" indique que les ressources n’ont pas encore été réservées. Le champ "Force désirée" indique la force des préconditions dans la direction correspondante. Le tableau pour le type d’état segmenté contient quatre rangées : les deux directions dans le réseau d’accès local et dans le réseau d’accès de l’homologue. La signification des champs est la même que dans le cas de bout en bout.

Avant de générer une offre, l’offreur DOIT construire un tableau d’état de transaction avec l’état actuel et l’état désiré, pour chaque flux de données. Les différentes valeurs de l’étiquette de force pour l’attribut d’état désiré ont la sémantique suivante :

o Facultatif : les agents d’utilisateur DEVRAIENT essayer de faire une réservation de ressource, mais la session peut continuer sans que cette fourniture soit ou non possible.

o Obligatoire : les agents d’utilisateur DOIVENT faire une réservation de ressource. Autrement, l’établissement de session NE DOIT PAS continuer.

L’offreur décide alors si il va utiliser le type d’état de bout en bout ou le type d’état segmenté. Si le type d’état de la ligne support est de bout en bout, l’agent d’utilisateur génère des enregistrements avec l’état désiré et l’état actuel indépendamment pour chaque direction (envoi et réception) comme le montre le tableau 1 :

Si le type d’état de la ligne support va être segmenté, l’agent d’utilisateur génère des enregistrements avec l’état désiré et l’état actuel indépendamment pour chaque direction (envoi et réception) et chaque segment (local et distant) comme le montre le tableau 2 :

Au moment de l’envoi de l’offre, le tableau d’état local et le tableau d’état de transaction de l’offreur contiennent les mêmes valeurs.

Avec le tableau d’état de transaction, l’agent d’utilisateur DOIT générer les lignes d’état actuel et d’état désiré, suivant la syntaxe de la Section 4 et les règles décrites ci-dessous au paragraphe 5.1.1.

Pour le type d’état de bout en bout, l’agent d’utilisateur DOIT générer une ligne d’état actuel avec l’étiquette "e2e" pour le flux de données. Si les étiquettes de force pour les deux directions sont égales (par exemple, toutes deux "obligatoire") dans le tableau d’état de transaction, l’agent d’utilisateur DOIT ajouter une ligne d’état désiré avec l’étiquette "envoi-réception". Si les deux étiquettes sont différentes, l’agent d’utilisateur DOIT inclure deux lignes d’état désiré, une avec l’étiquette "envoi" et l’autre avec l’étiquette "réception".

La sémantique de deux lignes avec la même étiquette de force, une avec une étiquette "envoi" et l’autre avec une étiquette "réception", est la même que celle d’une ligne "envoi-réception". Cependant, afin de réaliser un codage plus compact, on a choisi de rendre ce dernier format obligatoire.

Pour le type d’état segmenté, l’agent d’utilisateur DOIT générer deux lignes d’état actuel : une avec l’étiquette "local" et l’autre avec l’étiquette "distant". L’agent d’utilisateur DOIT ajouter une ou deux lignes d’état désiré par segment (c’est-à-dire, local et distant). Si, pour un segment particulier (local ou distant) les étiquettes pour les deux directions dans le tableau d’état de transaction sont égales (par exemple, toutes deux "obligatoire") l’agent d’utilisateur DOIT ajouter une ligne d’état désiré avec l’étiquette "envoi-réception". Si les deux étiquettes sont différentes, l’agent d’utilisateur DOIT inclure deux lignes d’état désiré, une avec l’étiquette "envoi" et l’autre avec l’étiquette "réception".

Noter que les règles ci-dessus s’appliquent aussi à l’étiquette de force désirée "aucune". De cette façon, un agent d’utilisateur qui prend en charge la qualité de service mais n’a pas l’intention de l’utiliser, ajoute des lignes d’état désiré avec l’étiquette de force "aucune". Comme cette étiquette peut être mise à niveau dans la réponse, comme décrit au paragraphe 5.2, celui qui répond peut demander une réservation de qualité de service sans avoir besoin d’un autre échange offre/réponse. L’exemple ci-dessous montre le SDP correspondant aux tableaux 1 et 2.

Lorsque celui qui répond reçoit l’offre, il recrée le tableau d’état de transaction en utilisant les attributs SDP contenus dans l’offre. Celui qui répond met à jour ses deux tableaux d’état local et de transaction selon les règles suivantes :

Force désirée : on définit un ordre absolu pour les étiquettes de force : "aucune", "facultatif" et "obligatoire". "Obligatoire" est l’étiquette du plus fort grade et "aucune" l’étiquette du grade inférieur. Un répondant PEUT mettre à niveau la force désirée dans toute entrée du tableau d’état de transaction, mais il NE DOIT PAS la dégrader. Donc, il ne pose pas de problème de passer de "aucune" à "facultatif", de "aucune" à "obligatoire", ou de "facultatif" à "obligatoire", mais pas l’inverse.

État actuel : pour chaque rangée, les valeurs du champ "actuel" dans le tableau d’état de transaction et dans le tableau d’état local de celui qui répond doivent être comparées. Le tableau 3 montre les quatre combinaisons possibles. Si les deux champs ont la même valeur (les deux premières lignes du tableau 3) rien n’a besoin d’être mis à jour. Si le champ "actuel" du tableau d’état de transaction est "oui", et si le champ du tableau d’état local est "non" (troisième ligne du tableau 3) ce dernier DOIT être réglé à "oui". Si le champ "actuel" du tableau d’état de transaction est "non", et si le champ du tableau d’état local est "oui" (quatrième ligne du tableau 3) celui qui répond doit vérifier si il a des informations locales (par exemple, si une confirmation de réservation de ressource a été reçue) sur cet état actuel particulier. Si il en a, le champ "actuel" du tableau d’état de transaction est réglé à "oui". Si celui qui répond n’a pas d’informations locales sur l’état actuel, le champ "actuel" du tableau d’état local DOIT être réglé à "non".

Une fois que les deux tableaux ont été mis à jour, une réponse DOIT être générée suivant les règles décrites au paragraphe 5.1.1, en prenant en compte que les étiquettes "envoi", "réception", "local" et "distant" ont été inversées dans la réponse, comme le montre le tableau 4.

Au moment de l’envoi de la réponse, le tableau d’état de transaction et le tableau d’état local de celui qui répond contiennent les mêmes valeurs. Donc, cette réponse contient la vue partagée de l’état de la ligne de support dans l’attribut État actuel et la force négociée et les étiquettes de direction dans l’attribut État désiré.

Si le mécanisme de réservation de ressource requiert la participation des deux agents d’utilisateur, celui qui répond DEVRAIT commencer la réservation de ressource après avoir envoyé la réponse et l’offreur DEVRAIT commencer la réservation de ressource aussitôt que la réponse est reçue. Si la participation de l’agent d’utilisateur de l’homologue n’est pas nécessaire (par exemple, type d’état segmenté) l’offreur PEUT commencer la réservation de ressource avant d’envoyer l’offre et celui qui répond PEUT la commencer avant d’envoyer la réponse.

L’état de la réservation de ressource d’une ligne de support peut changer entre deux échanges consécutifs d’offre/réponse. Donc, les deux agents d’utilisateur DOIVENT conserver à jour leurs tableaux d’état local en utilisant les informations locales pendant toute la durée de la session.

Un serveur d’agent d’utilisateur qui reçoit une offre avec des préconditions NE DEVRAIT PAS alerter l’usager tant que toutes les préconditions obligatoires ne sont pas satisfaites ; l’établissement de session est suspendu jusqu’à ce moment (par exemple, une passerelle du RTPC réserve des ressources sans envoyer de signalisation au RTPC.)

Un serveur d’agent d’utilisateur peut recevoir une demande INVITE sans offre en son sein. Dans ce cas, suivant les procédures normales définies dans les [RFC3261] et [RFC3311], le serveur d’agent d’utilisateur va fournir une offre dans une réponse 1xx fiable. Le client d’agent d’utilisateur va envoyer la réponse dans une autre demande SIP (c’est-à-dire, le PRACK pour la 1xx). Si l’offre et la réponse contiennent des préconditions, le serveur d’agent d’utilisateur NE DEVRAIT PAS alerter l’usager tant que toutes les préconditions obligatoires de la réponse ne sont pas satisfaites.

Noter que dans ce cas, un serveur d’agent d’utilisateur qui fournit une offre initiale avec des préconditions, une réponse 180 (Sonnerie) avec des préconditions ne sera jamais envoyée, car le serveur d’agent d’utilisateur ne peut pas alerter l’usager tant que les préconditions ne sont pas satisfaites.

Un UAS qui n’est pas capable de satisfaire unilatéralement toutes les préconditions obligatoires DOIT inclure un attribut Confirmer-l’état dans le SDP (offre ou réponse) qu’il envoie (voir la Section 7). De plus, le SDP (offre ou réponse) qui contient cet attribut Confirmer-l’état DOIT être envoyé aussitôt que permis par les règles d’offre/réponse de SIP.

Tandis que l’établissement de session est suspendu, les agents d’utilisateur NE DEVRAIENT PAS envoyer de données sur un flux de support. Dans le cas de RTP [RFC1889], des paquets ni RTP ni RTCP ne sont envoyés.

Un serveur d’agent d’utilisateur sait que toutes les préconditions sont satisfaites pour une ligne de support lorsque son tableau d’état local a une valeur de "oui" dans toutes les lignes dont l’étiquette de force est "obligatoire". Lorsque les préconditions de toutes les lignes de support de la session sont satisfaites, l’établissement de session DEVRAIT reprendre.

Pour un INVITE initial, la suspension et la reprise de l’établissement de session sont très intuitives. L’appelant ne sera pas alerté tant que toutes les préconditions obligatoires ne sont pas satisfaites. Cependant, les offres qui contiennent des préconditions envoyées pendant une session en cours demandent des explications complémentaires. Les deux agents d’utilisateur DEVRAIENT continuer d’utiliser les paramètres de la vieille session jusqu’à ce que toutes les préconditions obligatoires soient satisfaites. À ce moment, les agents d’utilisateur peuvent commencer à utiliser les paramètres de la nouvelle session. La Section 13 contient un exemple de cette situation.

L’attribut Confirmation-d’état PEUT être utilisé dans les offres et dans les réponses. Cet attribut représente un seuil pour la réservation de ressource. Lorsque ce seuil est atteint ou dépassé, l’agent d’utilisateur DOIT envoyer une offre à l’agent d’utilisateur de l’homologue, reflétant le nouvel état actuel de la ligne support aussitôt que permis par les règles d’offre/réponse de SIP. Si ce seuil est franchi à nouveau (par exemple, le réseau cesse de fournir des ressources pour le flux de données) l’agent d’utilisateur DOIT aussi envoyer une nouvelle offre, aussitôt que permis par les règles d’offre/réponse de SIP.

Si un homologue a demandé confirmation sur un certain flux, un agent DOIT marquer ce flux avec un fanion dans son tableau d’état local. Lorsque toutes les rangées qui ont ce fanion ont une valeur "actuel" de "oui", l’agent d’utilisateur DOIT envoyer une nouvelle offre à l’homologue. Cette offre devra contenir l’état actuel de la réservation de ressource dans les attributs État-actuel. Plus tard, si une des rangées qui a ce fanion passe à "non", une nouvelle offre DOIT être aussi envoyée.

Les attributs de confirmation ne sont pas négociés. Celui qui répond utilise la valeur de l’attribut Confirmation-d’état dans l’offre, et l’offreur utilise la valeur de cet attribut dans la réponse.

Par exemple, si un agent d’utilisateur reçoit une description SDP avec les attributs suivants :

Il va envoyer une offre aussitôt qu’il aura réservé des ressources dans son réseau d’accès (étiquette "distant" dans le message reçu) pour les deux directions (envoi-réception).

Lorsque un UAS, agissant comme celui qui répond, ne peut ou ne veut pas satisfaire les préconditions de l’offre, il DEVRAIT rejeter l’offre en retournant une réponse 580 (Échec-de-précondition).

Utiliser le code d’état 580 (Échec-de-précondition) pour refuser une offre est utile lorsque l’offre vient dans une demande INVITE ou UPDATE. Cependant, SIP ne fournit pas de moyen de refuser les offres qui arrivent dans une réponse (1xx ou 2xx) à un INVITE. Si un UAC génère un INVITE initial sans une offre et reçoit une offre dans une réponse 1xx ou 2xx qui n’est pas acceptable, il DEVRAIT répondre à cette offre par une réponse correctement formée et envoyer immédiatement un CANCEL ou un BYE.

Si l’offre vient dans une réponse 1xx ou 2xx à un re-INVITE, A n’aurait aucun moyen de la rejeter sans en même temps terminer la session. La même recommandation qu’au paragraphe 15.2 de la [RFC3261] s’applique ici : "L’UAS DOIT s’assurer que la description de session se recoupe avec sa précédente description de session en formats de support, de transports, et autres paramètres qui exigent la prise en charge par l’homologue. Cela est destiné à éviter que l’homologue soit obligé de rejeter la description de session . Cependant, si c’est inacceptable pour A, celui-ci DEVRAIT générer une réponse avec une description de session valide, et envoyer ensuite un BYE pour terminer la session."

Les réponses 580 (Échec-de-précondition) et les demandes BYE et CANCEL, qui indiquent l’échec à satisfaire certaines préconditions, DEVRAIENT contenir une description SDP, indiquant quel état désiré a déclanché l’échec. Noter que cette description SDP n’est pas une offre ou une réponse, car elle ne conduit pas à l’établissement d’une session. Le format d’une telle description se fonde sur la dernière SDP (offre ou réponse) reçue de l’UA distant.

Pour chaque ligne "m=" dans la dernière description SDP reçue, il DOIT y avoir une ligne "m=" correspondante dans la description SDP qui indique l’échec. Cette description SDP DOIT contenir exactement le même nombre de lignes "m=" que la dernière description SDP reçue. Le numéro d’accès de chaque ligne "m=" DOIT être réglé à zéro, mais l’adresse de connexion est arbitraire.

La ligne d’état désiré qui correspond à la précondition qui a déclanché l’échec DOIT utiliser l’étiquette de force "échec", comme le montre l’exemple ci-dessous :

Dans le modèle offre/réponse, lorsque celui qui répond souhaite rejeter un flux de données, il règle son accès à zéro. La présence de préconditions ne change pas ce comportement ; les flux sont quand même rejetés en réglant leur accès à zéro.

L’offreur et celui qui répond DOIVENT tous deux ignorer toutes les préconditions qui affectent un flux dont l’accès est réglé à zéro. Ils ne sont pas pris en considération pour décider si l’établissement de session peut ou non reprendre.

Le présent document définit l’étiquette "qos" pour les préconditions de qualité de service. Les nouveaux types de précondition qui seront définis à l’avenir auront de nouvelles étiquettes associées. Un UA qui reçoit un type de précondition inconnu, avec une étiquette de force "obligatoire" dans une offre, DOIT refuser l’offre sauf si les seules préconditions obligatoires inconnues ont l’étiquette "local". Dans ce cas, l’UA n’a pas besoin de s’occuper de satisfaire les préconditions. L’UA demandera confirmation des préconditions et, lorsque la confirmation arrivera, il reprendra l’établissement de session.

Un UA qui refuse une offre suit les règles décrites à la section 8, mais au lieu de l’étiquette "échec", il utilise l’étiquette "inconnu", comme le montre l’exemple suivant :

Un flux de données PEUT contenir plusieurs préconditions. Différentes préconditions PEUVENT avoir le même type de précondition et des types d’état différents (par exemple, des préconditions de qualité de service de bout en bout et segmenté) ou des types différents de préconditions (le présent document ne définit que le type de précondition "qos", mais des extensions pourront définir à l’avenir d’autres types de préconditions).

Toutes les préconditions pour un flux de données DOIVENT être satisfaites afin de reprendre l’établissement de session. L’exemple suivant montre une description qui utilise les deux types d’état de bout en bout et segmenté pour un flux de données :

On définit l’étiquette d’option "précondition" à utiliser dans les champs d’en-tête Require et Supported. Un offreur DOIT inclure cette étiquette dans le champ d’en-tête Require si l’offre contient une ou plusieurs étiquettes de force "obligatoire". Si toutes les étiquettes de force dans la description sont "facultatif" ou "aucune", l’offreur DOIT inclure cette étiquette dans un champ d’en-tête Supported ou dans un champ d’en-tête Require. Il est cependant RECOMMANDÉ que le champ d’en-tête Supported soit utilisé dans ce cas. L’absence de préconditions dans la réponse indiquerait que celui qui répond ne prend pas en charge cette extension.

La transposition des offres et des réponses en demandes et réponses SIP est effectuée en suivant les règles données dans la [RFC3311]. Donc, un agent d’utilisateur qui inclut des préconditions dans la SDP DOIT prendre en charge les méthodes PRACK et UPDATE. Par conséquent, il DOIT inclure l’étiquette "100rel" [RFC3262] dans le champ d’en-tête Supported et il DEVRAIT inclure un champ d’en-tête Allow avec l’étiquette "UPDATE" [RFC3311].

Le modèle offre/réponse de la [RFC3264] décrit le format d’une description de session pour indiquer les capacités. Ce format est utilisé dans les réponses aux demandes OPTIONS. Un UA qui prend en charge les préconditions DEVRAIT ajouter les lignes d’état désiré pour indiquer les types de préconditions pris en charge pour chaque flux de données. Ces lignes DOIVENT avoir l’étiquette de force "aucune", comme le montre l’exemple suivant :

Noter que lors de la publication du présent document, le type de précondition "foo" n’avait pas été enregistré. Il est utilisé ici dans la description de session ci-dessus pour donner un exemple avec plusieurs types de précondition.

Un UA qui prend en charge ce cadre DEVRAIT ajouter une étiquette "précondition" au champ d’en-tête Supported de ses réponses aux demandes OPTIONS.

Les exemples suivants couvrent les deux types d’état de bout en bout et segmenté.

Le flux d’appels de la Figure 2 montre un établissement de session de base qui utilise le type d’état de bout en bout. Les descriptions SDP de cet exemple sont données ci-dessous :

SDP1 : A inclut des préconditions de qualité de service de bout en bout dans l’offre initiale.

SDP2 : comme B utilise RSVP, il peut savoir quand sont disponibles des ressources dans sa direction "envoi", parce que il va recevoir des messages RESV du réseau. Cependant, il ne connaît pas l’état des réservations dans l’autre direction. B demande confirmation des réservations de ressource dans sa direction "réception" à l’agent d’utilisateur de l’homologue A dans sa réponse.

Après avoir envoyé la réponse, B commence à réserver les ressources du réseau pour le flux de données. Lorsque A reçoit cette réponse (2), il commence à effectuer aussi la réservation de ressources. Les deux UA utilisent RSVP, de sorte que A envoie des messages PATH vers B et B envoie des messages PATH vers A.

Après un certain temps, B reçoit des messages RESV qui confirment les réservations. Cependant, B attend que les ressources dans l’autre direction soient aussi réservées, car il n’a reçu aucune confirmation et les préconditions ne sont toujours pas satisfaites.

SDP3 : Lorsque A reçoit des messages RESV, il envoie une offre mise à jour (5) à B :

SDP4 : B répond, et sa réponse (6) contient l’état actuel de la réservation de ressource (c’est-à-dire, envoi-réception) :

À ce moment, l’établissement de session reprend et B retourne une réponse 180 (Sonnerie) (7).

Supposons qu’au milieu de la session, A souhaite changer l’adresse IP à laquelle il reçoit les données. La Figure 3 montre ce scénario.

SDP1 : A inclut une offre dans un re-INVITE (1). A continue de recevoir les données sur la vieille adresse IP (192.0.2.1) mais est aussi prêt à recevoir les données à la nouvelle adresse (192.0.2.2) :

SDP2 : B inclut un attribut "conf" dans sa réponse. B continue d’envoyer les données à la vieille adresse IP distante (192.0.2.1)

SDP3 : Lorsque A reçoit les messages RESV, il envoie une offre mise à jour (5) à B :

SDP4 : B répond (6), et sa réponse indique que les préconditions sont satisfaites (état actuel "envoi-réception). C’est maintenant que B commence à envoyer les données à la nouvelle adresse IP distante (192.0.2.2).

Le flux d’appel de la Figure 4 montre un établissement de session de base qui utilise le type d’état segmenté. La description SDP de cet exemple est donnée ci-dessous.

SDP1 : A inclut des préconditions de QS locales et distantes dans l’offre initiale. Avant d’envoyer l’offre initiale, A réserve des ressources dans son réseau d’accès. Cela est indiqué dans l’état local actuel du SDP ci-dessous :

SDP2 : B réserve des ressources dans son réseau d’accès et, comme toutes les préconditions sont satisfaites, retourne une réponse dans un 180 (Sonnerie) (3).

Supposons qu’après réception de cette réponse, A décide qu’il veut n’utiliser que le MIC en loi µ (charge utile 0) par opposition aux MIC en loi µ et A (charge utile 8). Il va envoyer un UPDATE à B, éventuellement avant de recevoir le 200 (OK) pour le INVITE (5). La SDP ressemblerait à :

B génèrerait une réponse à cette offre et la placerait dans le 200 (OK) pour le UPDATE.

Noter que cette dernière offre/réponse pour réduire le nombre de codecs pris en charge peut arriver au serveur d’agent d’utilisateur après que la réponse 200 (OK) ait été générée. Cela voudrait dire que la session a été établie avant que A ait réduit le nombre de codecs pris en charge. Pour éviter cette situation, le client d’agent d’utilisateur pourrait attendre la première réponse de l’agent d’utilisateur avant de régler l’état actuel local à "envoi-réception".

Le flux d’appels de la Figure 5 montre un établissement de session basique où l’offre initiale apparaît dans une réponse 1xx fiable. Cet exemple utilise le type d’état de bout en bout. Les descriptions SDP de cet exemple sont montrées ci-dessous :

Le premier INVITE (1) ne contient pas de description de session. Donc, l’offre initiale est envoyée par B dans une réponse 183 (Session en cours) fiable.

SDP1 : B inclut des préconditions de qualité de service de bout en bout dans l’offre initiale. Comme B utilise RSVP, il peut savoir quand sont disponibles des ressources dans sa direction "envoi", parce qu’il va recevoir des messages RESV du réseau. Cependant, il ne sait pas l’état des réservations dans l’autre direction. B demande dans sa réponse confirmation des réservations de ressource dans sa direction "réception" à l’agent d’utilisateur de l’homologue A.

SDP2 : A inclut sa réponse dans le PRACK pour la réponse 183 (Session en cours).

Après l’envoi de la réponse, A commence à réserver les ressources réseau pour le flux de données. Lorsque B reçoit cette réponse (3), il commence à effectuer aussi la réservation de ressources. Les deux UA utilisent RSVP, de sorte que A envoie des messages PATH vers B et que B envoie des messages PATH vers A.

SDP3 : Lorsque A reçoit des messages RESV, il envoie une offre mise à jour (5) à B :

SDP4 : B répond en (6) et sa réponse contient l’état actuel de la réservation de ressource (c’est-à-dire, réception):

Le temps passant, B reçoit des messages RESV qui confirment la réservation. À ce moment, l’établissement de session reprend et B retourne une réponse 180 (Sonnerie) (7).

Une entité installée entre deux agents d’utilisateurs qui établissent une session pourrait ajouter des attributs d’état désiré qui rendent impossible l’établissement de la session. Elle pourrait aussi modifier le contenu des paramètres d’état actuel de telle sorte que la session soit établie sans satisfaire aux préconditions. La protection de l’intégrité peut être utilisée pour éviter ces attaques.

Une entité qui effectue des réservations de ressource à réception de demandes non authentifiées qui portent des préconditions peut être une cible facile d’une attaque de déni de service. Les demandes avec des préconditions DEVRAIENT être authentifiées.

Le présent document définit trois attributs SDP de niveau support : état-désiré, état-actuel, et état-confirmé. Leur format est défini à la Section 4.

Le présent document définit un cadre d’utilisation des préconditions avec SIP. Les types de précondition à utiliser avec ce cadre sont enregistrés par l’IANA lorsque ils sont publiés dans des RFC en cours de normalisation. La section Considérations relative à l’IANA de la RFC DOIT inclure les informations suivantes, qui apparaissent dans le registre de l’IANA avec le numéro de RFC de la publication :

o Nom du type-de-précondition : le nom PEUT être de n’importe quelle longueur, mais DEVRAIT ne pas dépasser dix caractères.

Le présent document définit aussi un nouveau code d’état SIP (580). Sa phrase de cause par défaut (Échec de précondition) est définie à la section 8.

Le présent document définit une étiquette d’option SIP (précondition) à la section 11.

Des droits de propriété intellectuelle revendiqués à l’égard de tout ou partie de la spécification contenue dans le présent document ont été notifiés à l’IETF. Pour plus d’informations, consulter la liste en ligne des revendications de droits.

[DOSA] C. Kalmanek, W. Marshall, P. Mishra, D. Nortz, and K. K. Ramakrishnan, "DOSA: an architecture for providing robust IP telephony service," dans Proceedings of the Conference on Computer Communications (IEEE Infocom), (Tel Aviv, Israel), mars 2000.

[RFC1890] H. Schulzrinne, "Profil RTP pour conférences audio et vidéo avec contrôle minimal", janvier 1996. (Obsolète, voir RFC3551) (P.S.)

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

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

Les personnes suivantes ont contribué et étaient co-auteurs des versions antérieures de la présente spécification : K. K. Ramakrishnan (TeraOptic Networks), Ed Miller (Terayon), Glenn Russell (CableLabs), Burcak Beser (Pacific Broadband Communications), Mike Mannette (3Com), Kurt Steinbrenner (3Com), Dave Oran (Cisco), Flemming Andreasen (Cisco), Michael Ramalho (Cisco), John Pickens (Com21), Poornima Lalwaney (Nokia), Jon Fellows (Copper Mountain Networks), Doc Evans (D. R. Evans Consulting), Keith Kelly (NetSpeak), Adam Roach (dynamicsoft), Dean Willis (dynamicsoft), Steve Donovan (dynamicsoft), Henning Schulzrinne (Columbia University).

Ce document multi-auteurs est le point culminant de plus de deux ans de travail de nombreux individus, dont la plupart sont énumérés oici dans la section de remerciements qui suit. Une mention particulière pour Flemming Andreasen, Burcak Beser, Dave Boardman, Bill Guckel, Chuck Kalmanek, Keith Kelly, Poornima Lalwaney, John Lawser, Bill Marshall, Mike Mannette, Dave Oran, K.K. Ramakrishnan, Michael Ramalho, Adam Roach, Jonathan Rosenberg, et Henning Schulzrinne qui ont été les fers de lance du travail sur les préconditions de qualité de service du "single INVITE" initial à partir de propositions précédentes , non compatible avec SIP, de "Invite en deux étapes". Ces propositions de "INVITE en deux étape" trouvent leur origine dans le travail sur la signalisation d’appel répartie de PacketCable, qui à son tour, avait des élements d’architecture de l’architecdture de système ouvert réparti (DOSA, Distributed Open Systems Architecture) [DOSA] de AT&T.

Le travail sur la signalisation d’appel répartie dans le projet PacketCable est le fait d’un grand nombre de personnes, représentant de nombreuses sociétés. Les auteurs tiennent à reconnaître et remercier de leur aide John Wheeler, Motorola; David Boardman, Daniel Paul, Arris Interactive, Bill Blum, Jay Strater, Jeff Ollis, Clive Holborow, General Instruments, Doug Newlin, Guido Schuster, Ikhlaq Sidhu, 3Com, Jiri Matousek, Bay Networks, Farzi Khazai, Nortel, John Chapman, Bill Guckel, Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung-Hai Hsiao, Partho Mishra, AT&T, Telcordia Technologies, et Lucent Cable Communications.

Miguel Angel Garcia-Martin, Rohan Mahy et Mark Watson ont fourni des commentaires et des suggestions utiles.

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

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

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

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

Groupe de travail Réseau	G. Camarillo, éd., Ericsson
Request for Comments : 3312	W. Marshall, éd., AT&T
Catégorie : En cours de normalisation	J. Rosenberg, dynamicsoft
Traduction Claude Brière de L’Isle	octobre 2002

Gonzalo Camarillo	Bill Marshall	Jonathan Rosenberg
Ericsson	AT&T	dynamicsoft
Advanced Signalling Research Lab.	Florham Park, NJ 07932	72 Eagle Rock Ave
FIN-02420 Jorvas	USA	East Hanover, NJ 07936
Finland	mél : wtm@research.att.com	USA
mél : Gonzalo.Camarillo@ericsson.com		mél : jdrosen@dynamicsoft.com

Direction	Actuel	Force désirée
envoi	non	obligatoire
réception	non	obligatoire

Tableau d’état de transaction	Tableau d’état local	Nouvelles valeurs transac./local
non	non	non/non
oui	oui	oui/oui
oui	non	oui/oui
non	oui	selon les informations locales

Offre	Réponse
envoi	réception
réception	envoi
local	distant
distant	local