Groupe de travail Réseau	J. Rosenberg, Cisco Systems	
Request for Comments : 4235	H. Schulzrinne, Columbia University	
Catégorie : Sur la voie de la normalisation	R. Mahy, SIP Edge LLC	
Traduction Claude Brière de L'Isle	novembre 2005	

Paquetage d'événement de dialogue initié par INVITE pour SIP

Statut de ce mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la 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 un paquetage d'événement de dialogue pour l'architecture d'événements SIP, ainsi qu'un format de données utilisé dans les notifications pour ce paquetage. Le paquetage de dialogue permet aux utilisateurs de s'abonner à un autre utilisateur et de recevoir des notifications des changements d'état des usages de dialogue initiés par INVITE dans lesquels l'utilisateur abonné est impliqué.
Table des matières
1. Introduction	2
2. Terminologie	2
3. Paquetage d'événement de dialogue	2
3.1 Nom de paquetage d'événement	3
3.2 Paramètres de paquetage d'événement	3
3.3 Corps SUBSCRIBE	3
3.4 Durée d'abonnement	4
3.5 Corps NOTIFY	4
3.6 Traitement par le notifieur des demandes SUBSCRIBE	4
3.7 Génération par le notifieur des demandes NOTIFY	5
3.8 Traitement par l'abonné des demandes NOTIFY	7
3.9 Traitement des demandes fourchées	7
3.10 Taux de notifications	7
3.11 Agents d'état	7
4. Format d'informations de dialogue	7
4.1 Structure des Informations de dialogue	8
4.2 Exemple de corps de notification	10
4.3 Construction d'un état cohérent	10
4.4 Schéma	11
5. Définition des paramètres de nouvelle caractéristique du support	13
5.1 Paramètre "sip.byeless"	13
5.2 Paramètre "sip.rendering" 	13
6. Exemples	14
6.1 Exemple de base	14
6.2 Émulation d'un système de téléphonie à ligne partagée	15
6.3 Informations minimales de dialogue avec confidentialité	18
7. Considérations sur la sécurité	18
8. Considérations relatives à l'IANA	18
8.1 Enregistrement MIME pour le type application/dialog-info+xml	18
8.2 Enregistrement du sous espace d'URN  urn:ietf:params:xml:ns:dialog-info	19
8.3 Enregistrement de schéma	19
8.4 Enregistrement de paramètre de caractéristique de support	19
9. Remerciements	20
10. Références	20
10.1 Références normatives	20
10.2 Références pour information	21
Adresse des auteurs	21
Déclaration complète de droits de reproduction	21
 	1.	Introduction

Le cadre d'événements SIP [RFC3265] définit des mécanismes généraux pour l'abonnement à, et la notification, des événements au sein des réseaux SIP. Il introduit la notion de paquetage, qui est une "instanciation" spécifique du mécanisme d'événements pour un ensemble bien défini d'événements. Les paquetages ont été définis pour la présence d'utilisateur [RFC3856], les informations d'observateur [RFC3857], et les indicateurs de message en attente [RFC3842], entre autres. Le présent document définit un paquetage d’événement pour les usages de dialogue initiés par INVITE. Les dialogues se réfèrent aux relations SIP établies entre deux homologues SIP [RFC3261]. Les dialogues peuvent être créés par de nombreuses méthodes, bien que la RFC 3261 en définisse seulement une : la méthode INVITE. La [RFC3265] définit les méthodes SUBSCRIBE et NOTIFY, qui créent aussi de nouveaux usages de dialogue. Cependant, utiliser ce paquetage pour modéliser l'état pour des usages de dialogue non de session sort du domaine de la présente spécification.

Diverses applications sont possibles par la connaissance de l'état d'usage de dialogue INVITE. Parmi les exemples :

Rappel automatique : dans cette application de base du réseau téléphonique public commuté (RTPC) l'usager A appelle l'usager B mais il est occupé. L'usager A aimerait avoir un rappel quand l'usager B raccrochera. Quand B raccroche, le téléphone de l'usager A sonne. Quand A décroche, il entend la sonnerie, alors qu'il est en train d'être connecté à B. Pour mettre cela en œuvre avec SIP, un mécanisme est nécessaire pour que A reçoive une notification quand le dialogue chez B se termine.

Conférence à présence activée : dans cette application, l'usager A souhaite établir une conférence avec les usagers B et C. Plutôt que de le programmer, l'appel est créé automatiquement quand A, B et C sont tous disponibles. Pour ce faire, le serveur qui fournit l'application aimerait savoir si A, B, et C sont "en ligne", non inactifs, et non engagés dans un appel téléphonique. Déterminer si A, B, et C sont ou non en appel peut être fait de deux façons. Dans la première, le serveur agit comme un mandataire à états d'appel pleins pour les usagers A, B, et C, et donc connaît leur état d'appel. Cela ne va cependant pas être toujours possible, et cela introduit des complexités d'adaptabilité, de fiabilité, et de fonctionnement. Dans la seconde façon, le serveur s'abonne à l'état de dialogue de ces usagers et reçoit les notifications lorsque cet état change. Cela permet à l'application d'être fournie de façon répartie ; le serveur n'a pas besoin de résider dans le même domaine que les usagers.

Alertes de conférence de messagerie instantanée : dans cette application, un usager peut recevoir un message instantané sur son téléphone chaque fois que quelqu'un se joint à une conférence dans laquelle le téléphone est impliqué. Les alertes de messagerie instantanée sont générées par une application séparée du serveur de conférence.

En général, le paquetage de dialogue permet la construction d'applications réparties, où l'application exige des informations sur l'état de dialogue mais n'est pas co-résidente avec l'usager final sur lequel cet état réside.

Le présent document définit aussi deux nouveaux paramètres de caractéristique de capacité d'appelé [RFC3840] :
o "sip.byeless", qui indique qu'un agent d'utilisateur (UA) SIP n'est pas capable de terminer lui-même une session (par exemple, dans certains services d'annonces ou d'enregistrement, ou dans certains centres d'appel) dans lesquels l'UA n'est plus intéressé à participer ; 
o "sip.rendering", qui décrit de façon positive si l'agent d'utilisateur restitue les supports qu'il reçoit. Ces paramètres de caractéristique sont utiles dans beaucoup des mêmes applications qui ont motivé le paquetage de dialogue, comme les conférences, la présence, et l'exemple de ligne partagée décrit au paragraphe 6.2.

 	2.	Terminologie

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

 	3.	Paquetage d'événement de dialogue

Cette section donne les détails de la définition d'un paquetage d'événement SIP, comme spécifié dans la [RFC3265].

 	3.1	Nom de paquetage d'événement
Le nom de ce paquetage d'événement est "dialog". Ce nom de paquetage est porté dans les champs d'en-tête Event et Allow-Events, comme définis dans la [RFC3265].

 	3.2	Paramètres de paquetage d'événement
Ce paquetage définit quatre paramètres de paquetage d'événement : call-id, to-tag, from-tag, et include-session-description.  Si un abonnement à un dialogue spécifique est demandé, les trois premiers de ces paramètres DOIVENT être présents, pour identifier le dialogue objet de l'abonnement. Le paramètre to-tag est confronté à l'étiquette locale, le paramètre from-tag est confronté à l'étiquette distante, et le paramètre call-id est confronté à l'identifiant d'appel. Le paramètre include-session-description indique si l'abonné aimerait recevoir la description de session associée à ou aux usages de dialogue souscrits.

Il est aussi possible de s'abonner à l'ensemble de dialogues créé par suite d'un seul INVITE envoyé par un client d'agent d’utilisateur (UAC, user agent client). Dans ce cas, call-id et to-tag DOIVENT être présents. Le paramètre to-tag est confronté à l'étiquette locale et le call-id est confronté à l'identifiant d'appel.

L'ABNF pour ces paramètres est montré ci-dessous. Il se réfère à de nombreuses constructions de l'ABNF de la RFC3261, comme EGAL, DQUOTE, et jeton.

call-id  =  "call-id" EGAL ( jeton / DQUOTE callid DQUOTE )
                    ;; Note : tout DQUOTE à l'intérieur de callid DOIT être échappé !
from-tag  =  "from-tag" EGAL jeton
to-tag  =  "to-taag" EGAL jeton
with-sessd =  "include-session-description"

Si des call-id contiennent des guillemets incorporés, ces guillemets DOIVENT être échappés en utilisant le mécanisme de citation avec barres oblique inverse. Noter que le paramètre call-id peut devoir être exprimé comme une chaîne entre guillemets. C'est parce que l'ABNF pour la production callid et la production "word", qui est utilisée par callid (toutes deux d'après la [RFC3261]) permet certains caractères (comme "@", "[", et ":") qui ne sont pas permis dans un jeton.

 	3.3	Corps SUBSCRIBE
Une demande SUBSCRIBE pour un paquetage de dialogue PEUT contenir un corps. Ce corps définit un filtre à appliquer à l'abonnement. Des documents de filtre ne sont pas spécifiés dans le présent document, et au moment de sa rédaction, on s'attend à ce qu'ils soient le sujet d'une activité future de normalisation.

Une demande SUBSCRIBE pour un paquetage de dialogue PEUT être envoyée sans un corps. Cela implique la politique de filtrage d'abonnement par défaut. La politique par défaut est :

o	Si le champ d'en-tête Event contenant des identifiants de dialogue, une notification est générée chaque fois qu'il y a un changement de l'état de tout dialogue correspondant pour l'usager identifié dans l'URI de demande du SUBSCRIBE.

o	Si il n'y avait pas d'identifiant de dialogue dans le champ d'en-tête Event, une notification est générée chaque fois qu'il y a un changement dans l'état de tout dialogue pour l'usager identifié dans l'URI de demande du SUBSCRIBE avec les exceptions suivantes : si l'URI cible (Contact) d'un abonné est équivalent à l'URI cible distant d'un dialogue spécifique, alors l’élément dialogue pour ce dialogue est supprimé pour cet abonné. (L'abonné est déjà partie directement au dialogue, de sorte que ces notifications sont superflues.) Si aucun dialogue ne reste après la suppression des dialogues, la notification entière à cet abonné est supprimée et le numéro de version dans l'élément dialogue-info n'est pas incrémenté pour cet abonné. Le filtrage implicite pour un abonné n'affecte pas les notifications aux autres abonnés.

o	Les notifications ne contiennent normalement pas d'état plein ; elles indiquent plutôt seulement l'état du ou des dialogues dont l'état a changé. Les exceptions sont un NOTIFY envoyé en réponse à un SUBSCRIBE, et un NOTIFY qui ne contient pas d'élément dialogue. Ces NOTIFY contiennent la vue complète de l'état de dialogue.

o	Les notifications contiennent les identités des participants au dialogue, les URI cibles, et les identifiants de dialogue. Les descriptions de session ne sont pas incluses sauf si c'est explicitement demandé et explicitement autorisé.

 	3.4	Durée d'abonnement
L'état de dialogue changes très rapidement. Une fois établi, un appel téléphonique normal dure quelques minutes (c'est différent bien sûr, pour les autres types de session). Cependant, l'intervalle entre les nouveaux appels est normalement long.  Les clients DEVRAIENT spécifier une durée explicite.

Il y a deux cas d'utilisation distincts pour l'état de dialogue. Le premier est quand un abonné est intéressé par l'état d'un ou plusieurs dialogues spécifiques (et qu'il est autorisé à trouver juste l'état de ces dialogues). Dans ce cas, quand les dialogues se terminent, l'abonnement se termine aussi. Dans ce cas, la valeur de la durée de l'abonnement est peu pertinente ; elle DEVRAIT être plus longue que la durée normale de dialogue. On recommande une durée par défaut de deux heures, ce qui devrait probablement couvrir la plupart des dialogues.

Dans l'autre cas, un abonné est intéressé par l'état de tous les dialogues pour un usager spécifique. Dans ce cas, un intervalle plus court paraît raisonnable. La valeur par défaut est d'une heure pour ces abonnements.

 	3.5	Corps NOTIFY
Comme décrit dans la [RFC3265], le message NOTIFY va contenir des corps qui décrivent l'état de la ressource objet de l'abonnement. Ce corps est dans un format marqué dans le champ d'en-tête Accept du SUBSCRIBE, ou dans un format par défaut spécifique du paquetage si le champ d'en-tête Accept était omis du SUBSCRIBE.

Dans ce paquetage d'événement, le corps de la notification contient un document d'informations de dialogue. Le présent document décrit l'état d'un ou plusieurs dialogues associés à la ressource souscrite. Tous les abonnés et notifieurs DOIVENT prendre en charge le format de données "application/dialog-info+xml" décrit à la Section 4. La demande d'abonnement PEUT contenir un champ d'en-tête Accept. Si un tel champ d'en-tête n'est pas présent, il a la valeur par défaut de "application/dialog-info+xml". Si le champ d'en-tête est présent, il DOIT inclure "application/dialog-info+xml", et il PEUT inclure tous autres types capables de représenter l'état de dialogue.

Bien sûr, les notifications générées par le serveur DOIVENT être dans un des formats spécifiés dans le champ d'en-tête Accept de la demande SUBSCRIBE.

 	3.6	Traitement par le notifieur des demandes SUBSCRIBE
Les informations de dialogue pour un usager contiennent des informations sensibles. Donc, tous les abonnements DEVRAIENT être authentifiés et ensuite autorisés avant approbation. Toutes les mises en œuvre de ce paquetage DOIVENT prendre en charge au moins le mécanisme d'authentification par résumé. La politique d'autorisation est à la discrétion de l'administrateur, comme toujours. Cependant, on peut faire quelques recommandations.

Il est RECOMMANDÉ que, si la politique de l'usager B est que l'usager A soit autorisé à les appeler, les abonnements de dialogue provenant de l'usager A soient permis. Cependant, les informations fournies dans les notifications ne contiennent aucune information d'identification de dialogue, simplement une indication de si l'usager est au moins dans un appel. Précisément, on ne devrait pas être capable de trouver plus d'informations que si elles étaient envoyées dans un INVITE. (Ce concept de dialogue "virtuel" est discuté au paragraphe 3.7.2, et un exemple d'un tel corps de notification est montré ci-dessous).

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
             version="0" state="full" entity="sip:alice@exemple.com">
  <dialog id="as7d900as8">
    <state>confirmed</state>
  </dialog>
</dialog-info>

Un agent d'utilisateur qui s'enregistre avec l'adresse d'enregistrement X DEVRAIT autoriser les abonnements qui viennent de toute entité qui peut s'authentifier comme X. Des informations complètes sur l'état de dialogue DEVRAIENT être envoyées dans ce cas. Ce comportement d'autorisation permet qu'un groupe d'appareils représentant un seul utilisateur connaisse l'état de chacun des autres. C'est utile pour les applications comme une extension sur une ligne unique, aussi appelée ligne partagée.

Noter que de nombreuses mises en œuvre de "lignes partagées" ont une caractéristique qui permet que les détails des appels sur une adresse d'enregistrement partagée restent confidentielles. C'est une politique d'autorisation très raisonnable qui pourrait résulter en notifications qui contiennent seulement l'attribut d'identifiant de l'élément de dialogue et l'élément d'état quand la confidentialité de ligne partagée est demandée, et des notifications avec des informations plus complètes quand la confidentialité de ligne partagée n'est pas demandée.

 	3.7	Génération par le notifieur des demandes NOTIFY
Les notifications sont générées pour le paquetage de dialogue quand est envoyée une demande INVITE, quand un nouveau dialogue se manifeste à un UA, ou quand l'état ou les caractéristiques d'un dialogue existant changent. Donc, un modèle d'état de dialogue est nécessaire afin de déterminer précisément quand envoyer les notifications, et ce que devrait être leur contenu. La spécification SIP a raisonnablement bien défini le cycle de vie des dialogues. Cependant, il n'est pas explicitement modélisé. La présente spécification fournit un modèle explicite d'état de dialogue à travers un automate à états finis.

Il est RECOMMANDÉ que les demandes NOTIFY ne contiennent que des informations sur les dialogues dont l'état ou les informations de participation ont changé. Cependant, si un notifieur reçoit une demande SUBSCRIBE, le NOTIFY déclenché DEVRAIT contenir l'état de tous les dialogues que l'abonné est autorisé à voir.

 	3.7.1	Automate à états de dialogue
La modélisation de l'état de dialogue est compliquée par deux facteurs. Le premier est le fourchement, qui peut causer la génération par un seul INVITE de nombreux dialogues à un UAC. Le second est les vues différentes de l'état à l'UAC (client d'agent d'utilisateur) et à l'UAS (serveur d'agent d’utilisateur). On a choisi de traiter le premier problème en étendant l'automate à états finis (FSM, finite state machine) de dialogue pour inclure les états entre la transmission de l'INVITE et la création des dialogues réels par la réception des réponses 1xx et 2xx. Il en résulte que la présente spécification prend en charge la notion d'état de dialogue pour les dialogues avant qu'ils soient complètement instanciés.

On a aussi choisi d'utiliser un seul FSM pour l'UAC et l'UAS.

      +----------+            +----------+
      |          | 1xx-notag  |          |
      |    En    |----------->|          |
      |  essai   |            | En cours |-----+
      |          |---+  +-----|          |     |
      +----------+   |  |     +----------+     |
           |   |     |  |          |           |
           |   |     |  |          |           |
           +<--C-----C--+          |étiq. 1xx  |
           |   |     |             |           |
   annulé  |   |     |             V           |
   rejeté  |   |     |ét. 1xx +----------+     |
           |   |     +------->|          |     |2xx
           |   |              |          |     |
           +<--C--------------| Précoce  |-----C---+ étiquette 1xx
           |   |   remplacé   |          |     |   | sans nouvelle étiquette
           |   |              |          |<----C---+ (nouvelle instance
           |   |              +----------+     |      de FSM créée)
           |   |   2xx             |           |      
           |   +----------------+  |           |
           |                    |  |2xx        |
           V                    V  V           |
      +----------+            +----------+     |
      |          |            |          |     |
      | Terminé  |<-----------| Confirmé |<----+
      |          |  erreur    |          |
      |          |  fin tempo |          |
      +----------+  remplacé  +----------+
                    bye local   |      ^
                    bye distant |      |
                                +------+
                                 2xx sans nouvelle étiquette
                                (nouvelle instance de FSM créée)

Figure 3

La Figure 3 montre l'automate à état de dialogue. On comprend mieux le FSM en considérant séparément le cas de l'UAC et de l'UAS.

Le FSM est créé dans l'état En essai quand l'UAC envoie une demande INVITE. À réception d'une 1xx sans étiquette, le FSM passe à l'état En cours. Noter qu'il n'y a pas encore de dialogue réel, comme défini par la spécification SIP. Cependant, il y a un "demi dialogue", en ce sens que deux des trois composants de l'identifiant de dialogue (l'identifiant d'appel et l'étiquette locale) sont connus. Si est reçue une 1xx avec une étiquette, le FSM passe à l'état Précoce. L'identifiant de dialogue complet est maintenant défini. Si une 2xx avait été reçue, le FSM serait passé à l'état Confirmé.

Si, après le passage à l'état Précoce ou Confirmé, l'UAC reçoit une autre respectivement 1xx ou 2xx avec une étiquette différente, une autre instance du FSM est créée, initialisée dans l'état respectivement Précoce ou Confirmé. L'avantage de cette approche est qu'il va y avoir un seul FSM représentant l'état entier de l'invitation et du dialogue résultant quand on traite le cas courant sans fourchement.

Si l'UAC envoie un CANCEL et ensuite reçoit une réponse 487 à sa transaction INVITE, tous les FSM nés de cette INVITE transitent à l'état Terminé avec l'événement "annulé". Si l'UAC reçoit une nouvelle invitation (avec un en-tête Remplace [RFC3891]) qui remplace le dialogue actuel Précoce ou Confirmé, toutes les transactions INVITE nées de l'invitation remplacée transitent à l'état Terminé avec l'événement "Remplacé". Si la transaction INVITE se termine avec une réponse non 2xx pour une quelconque autre raison, tous les FSM nés de cet INVITE transitent à l'état Terminé avec l'événement "Rejeté".

Une fois dans l'état Confirmé, l'appel est actif. Il peut transiter à l'état Terminé si l'UAC envoie un BYE ou reçoit un BYE (correspondant aux événements "local-bye" et "remote-bye" comme approprié) si une demande de mi-dialogue génère une réponse 481 ou 408 (correspondant à l'événement "erreur") ou une demande de mi-dialogue ne génère pas de réponse (correspondant à l'événement "fin de temporisation").

Du point de vue de l'UAS, quand un INVITE est reçu, le FSM est créé dans l'état En essai. Si il envoie une 1xx sans une étiquette, le FSM transite à l'état En cours. Si une 1xx est envoyée avec une étiquette, le FSM transite à l'état Précoce, et si une réponse 2xx est envoyée, il transite à l'état Confirmé. Si l'UAS reçoit une demande CANCEL et génère ensuite une réponse 487 à l'INVITE (ce qui peut se produire dans les états En cours et Précoce) le FSM transite à l'état Terminé avec l'événement "annulé". Si l'UAS génère toute autre réponse finale non 2xx à la demande INVITE, le FSM transite à l'état Terminé avec l’événement "rejeté". Si l'UAS reçoit une nouvelle invitation (avec un champ d'en-tête Remplace [RFC3891]) qui remplace le dialogue confirmé en cours, l'invitation remplacée transite à l'état Terminé avec l'événement "remplacé". Une fois dans l'état Confirmé, les autres transitions à l'état Terminé se produisent pour les mêmes raisons que dans le cas de l'UAC.

Il ne devrait jamais y avoir de transition de l'état En essai à l'état Terminé avec l'événement "annulé", car la spécification SIP interdit la transmission à partir de CANCEL jusqu'à ce qu'une réponse provisoire soit reçue. Cependant, cette transition est définie dans le FSM pour unifier les transitions à partir des états En essai, En cours, et Précoce à l'état Terminé.

 	3.7.2	Application de l'automate à états
Le notifieur PEUT générer une demande NOTIFY sur toute transition d'événement du FSM. Il dépend de la politique que cela se fasse ou non. Cependant, on donne quelques lignes directrices générales.

Quand l'abonné est non authentifié, ou est authentifié mais représente un tiers sans politique d'autorisation spécifique, il est RECOMMANDÉ que les abonnements à un dialogue individuel ou un ensemble spécifique de dialogues soient interdits.  Seuls les abonnements à tous les dialogues (c'est-à-dire qu'il n'y a pas d'identifiant de dialogue dans le champ d'en-tête Event) sont permis. Dans ce cas, les états réels de dialogue à travers tous les dialogues ne seront pas rapportés. Un seul FSM de dialogue "virtuel" va être utilisé, et les transitions d'état du FSM seront rapportées.

Si il y a un dialogue à l'UA dont l'état est Confirmé, le FSM virtuel est dans l'état Confirmé. Si il n'y a pas de dialogue à l'UA dans l'état Confirmé mais si il y en a au moins un dans l'état Précoce, le FSM virtuel est dans l'état Précoce ou Confirmé. Si il n'y a pas de dialogue dans les états Confirmé ou Précoce mais si il y en a au moins un dans l'état En cours, le FSM virtuel est dans l'état En cours, Précoce ou Confirmé. Si il n'y a pas de dialogue dans les états Confirmé, Précoce, ou En cours, mais qu'il y en a au moins un dans l'état En essai, le FSM virtuel est dans l'état En essai, En cours, Précoce ou Confirmé. Le choix de l'état à utiliser dépend de si l'UA souhaite laisser les utilisateurs inconnus savoir que leur téléphone sonne, par opposition à être dans un appel actif.

Il est RECOMMANDÉ que, en l'absence de toute préférence, Confirmé soit utilisé dans tous les cas, comme montré dans l'exemple du paragraphe3.6. De plus, il est RECOMMANDÉ que les notifications des changements dans le FSM virtuel ne portent aucune information sauf l'état du FSM et ses transitions d'événement - aucun identifiant de dialogue (qui sont de toutes façons mal définis dans ce modèle). L'utilisation de ce FSM virtuel permet qu'un minimum d'informations soient transportées. Un abonné ne peut pas savoir combien d'appels sont en cours, ou avec qui, juste qu'il existe un appel. Ce sont les mêmes informations qu'il recevrait si il envoyait simplement un INVITE à l'utilisateur à la place ; une réponse 486 (Occupé ici) indiquerait qu'ils sont sur un appel.

Quand l'abonné est authentifié et s'est authentifié avec la même adresse d'enregistrement que l'UA utilise lui-même, si aucune politique explicite d'autorisation n'est définie, il est RECOMMANDÉ que toutes les transitions d'état sur les dialogues qui ont été souscrits pour être rapportés, ainsi que les identifiants complets de dialogue. Cela signifie soit tous les dialogues, si aucun identifiant de dialogue n'était présent dans le champ d'en-tête Event, soit l'ensemble spécifique de dialogues identifiés par les paramètres du champ d'en-tête Event.

Le notifieur DEVRAIT générer une demande NOTIFY sur chaque changement des caractéristiques associées au dialogue. Comme cela inclut les paramètres de URI de contact, Contact, et les descriptions de session, la réception des demandes re-INVITE et UPDATE [RFC3311] qui modifient ces informations PEUT déclencher des notifications.

 	3.8	Traitement par l'abonné des demandes NOTIFY
Le cadre d'événements SIP attend des paquetages qu'ils spécifient comment un abonné traite les demandes NOTIFY de façon spécifique du paquetage. En particulier, un paquetage devrait spécifier comment il utilise les demandes NOTIFY pour construire une vue cohérente de l'état de la ressource souscrite.

Normalement, le NOTIFY pour le paquetage de dialogue va contenir des informations sur seulement les dialogues dont l'état a changé. Pour construire une vue cohérente de l'état total de tous les dialogues, un abonné au paquetage de dialogue va avoir besoin de combiner les NOTIFY reçus au fil du temps.

Les notifications au sein de ce paquetage peuvent convoyer des informations partielles ; c'est-à-dire, elles peuvent indiquer des informations sur un sous ensemble de l'état associé à l'abonnement. Cela signifie qu'un algorithme explicite doit être défini afin de construire un état cohérent et consistant. Les détails de ce mécanisme sont spécifiques du type de document particulier. Voir au paragraphe 4.3 des informations sur la construction d'informations cohérentes à partir d'un document application/dialog-info+xml.

 	3.9	Traitement des demandes fourchées
Comme l'état de dialogue est réparti à travers l'UA pour un usager particulier, il est raisonnable et utile qu'une demande SUBSCRIBE pour un état de dialogue se divise et atteigne plusieurs UA.

Par suite, une demande SUBSCRIBE fourchée pour l'état de dialogue peut installer plusieurs abonnements. Les abonnés à ce paquetage DOIVENT être prêts à installer l'état d'abonnement pour chaque NOTIFY généré par suite d'un seul SUBSCRIBE.

 	3.10	Taux de notifications
Pour des raisons de contrôle d'encombrement, il est important que le taux de notifications ne soit pas excessif. Il est RECOMMANDÉ que le serveur ne génèrepas  de notifications pour un seul abonné plus qu'une fois par seconde.

 	3.11	Agents d'état
L'état de dialogue est idéalement conservé dans les agents d'utilisateur dans lesquels réside le dialogue. Donc, les éléments qui conservent le dialogue sont ceux qui sont le mieux adaptés pour traiter leurs abonnements. Cependant, dans certains cas, un agent de réseau peut aussi connaître l'état des dialogues tenus par un usager. De tels agents d'état PEUVENT être utilisés avec ce paquetage.

 	4.	Format d'informations de dialogue

Les informations de dialogue sont un document XML [XML] qui DOIT être bien formé et DEVRAIT être valide. Les documents d'informations de dialogue DOIVENT être fondés sur XML 1.0 et DOIVENT être codés en utilisant UTF-8. La présente spécification utilise les espaces de noms XML pour identifier les documents d'informations de dialogue et fragments de document. L'URI d'espace de noms pour les éléments définis par cette spécification est un URN [RFC2141] qui utilise l'identifiant d'espace de nom "ietf" défini par la [RFC2648] et étendu par la [RFC3688].

Cet URN est : urn:ietf:params:xml:ns:dialog-info

Un document d'informations de dialogue commence par l'étiquette d'élément racine "dialog-info".

 	4.1	Structure des Informations de dialogue
Un document d'informations de dialogue commence par un élément dialog-info. Cet élément a trois attributs obligatoires :

o	version : cet attribut permet au receveur de documents d'information de dialogue de les ordonner de façon appropriée. Les versions commencent à 0, et s'incrémentent de un pour chaque nouveau document envoyé à un abonné. La portée des versions est l'abonnement. Les versions DOIVENT être représentables en utilisant un entier de 32 bits non négatif.

o	état : cet attribut indique si le document contient les informations de dialogue complètes, ou si il contient seulement des informations sur les dialogues qui ont changé depuis le précédent document (partiel).

o	entité : cet attribut contient un URI qui identifie l'usager dont les informations de dialogue sont rapportées dans le reste du document. Cet usager est appelé "usager observé".

L'élément dialog-info a une série de zéro, un, ou plusieurs sous éléments de dialogue. Chacun d'eux représente un dialogue spécifique. Par exemple :

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" notify-state="full" 
           entity="sip:alice@exemple.com">
</dialog-info>

 	4.1.1	Élément "Dialog"
L'élément dialogue rapporte les informations sur un dialogue ou "demi-dialogue" spécifique. Il a un seul attribut obligatoire   id. L'attribut id fournit une seule chaîne qui peut être utilisée comme identifiant pour ce dialogue ou "demi-dialogue". C'est un identifiant différent de l'identifiant de dialogue défini dans la [RFC3261], mais qui s'y rapporte.
Pour un appelant, le id est créé quand une demande INVITE est envoyée. Quand une réponse 1xx avec une étiquette, ou une réponse 2xx est reçue, le dialogue est formellement créé. Le id reste inchangé. Cependant, si une réponse 1xx ou 2xx supplémentaire est reçue, résultant en la création d'un autre dialogue (et du FSM résultant) un nouvel id est alloué à ce dialogue.
Pour un appelé, l'id est créé quand est reçu un INVITE en dehors d'un dialogue existant. Quand une réponse 2xx ou 1xx avec une étiquette est envoyée, créant le dialogue, le id reste inchangé.

Le id DOIT être unique parmi les dialogues en cours à un UA.

Il y a un certain nombre d'attributs facultatifs qui fournissent des informations d'identification sur le dialogue :
o	call-id : cet attribut est une chaîne qui représente le composant call-id de l'identifiant de dialogue. (Noter que des guillemets simples et doubles à l'intérieur d'un call-id doivent être échappés en utilisant &quote; pour " 
et &apos; pour ' .)
o	local-tag : cet attribut est une chaîne qui représente le composant "étiquette locale" de l'identifiant de dialogue.
o	remote-tag : cet attribut est une chaîne qui représente le composant "étiquette distante" de l'identifiant de dialogue. L'attribut remote-tag ne sera pas présent si il y a seulement un "demi-dialogue", résultant de la génération d'un INVITE pour lequel aucune réponse finale ou provisoire avec étiquettes n'a été reçue.
o	direction : cet attribut est soit d'initiateur, soit de receveur, et indique si l'usager observé était l'initiateur du dialogue, ou le receveur de l'INVITE qui l'a créé.

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="partial" entity="sip:alice@exemple.com">
  <dialog id="as7d900as8" call-id="a84b4c76e66710" local-tag="1928301774" direction="initiator">
...
  </dialogue>
</dialog-info>

Les sous-éléments de l'élément dialogue fournissent des informations supplémentaires sur le dialogue. Certains de ces sous-éléments fournissent plus de détails sur le dialogue lui-même, tandis que les sous-éléments locaux et distants décrivent les caractéristiques des participants impliqués dans le dialogue. Le seul sous-élément obligatoire est l'élément "state".

 	4.1.2	Élément État
L'élément "state" indique l'état du dialogue. Sa valeur est un type d'énumération qui décrit un des états du FSM. Il a un attribut d'événement facultatif qui peut être utilisé pour indiquer l'événement qui a causé une transition à l'état Terminé, et un attribut de code facultatif qui indique le code de réponse associé à toute transition causée par une réponse à l'INVITE d'origine.

<state event="rejected" code="486">terminated</state>

 	4.1.3	Élément Durée
L'élément "duratio" contient la quantité de temps, en seconde, depuis la création du FSM.

<duration>145</duration>

 	4.1.4	Élément Replaces
L'élément "replaces" est utilisé pour corréler un nouveau dialogue avec celui qu'il remplace par suite d'une invitation avec un champ d'en-tête Replaces. Cet élément est présent dans le dialogue de remplacement seulement (le dialogue le plus récent) et contient les attributs avec le call-id, local-tag, et remote-tag du dialogue remplacé.

<replaces call-id="hg287s98s89" local-tag="6762h7" remote-tag="09278hsb"/>

 	4.1.5	Élément Referred-By
L'élément "referred-by" est utilisé pour corréler un nouveau dialogue avec une demande REFER [RFC3515] qui l'a déclenché. L'élément est présent dans un dialogue qui a été déclenché par une demande REFER qui contenait un champ d'en-tête Referred-By [RFC3892] et contient l'attribut de nom d'affichage (facultatif) et l'URI Referred-By comme sa valeur.

<referred-by display="Bob">sip:bob@exemple.com</referred-by>

 	4.1.6	Éléments Local et Distant
Les éléments "local" et "remote" sont des sous éléments de l'élément de dialogue qui contiennent des informations sur les participants, respectivement, local et distant. Ils ont tous ceux un certain nombre de sous-éléments facultatifs qui indiquent l'identité portée par le participant, l'URI cible, les étiquettes de caractéristiques de la cible, et la description de session du participant.

 	4.1.6.1	Élément Identité
L'élément "identity" indique un URI local ou distant selon le cas, comme défini dans la [RFC3261]. Il a un attribut facultatif, display, qui contient le nom d'affichage provenant de l'URL approprié.

Noter que plusieurs identités (par exemple un URI sip: et un URI  tel:) pourraient être incluses si elles correspondent toutes au participant. Pour éviter de répéter les informations d'identité dans chaque demande, l'abonné peut supposer que les URI d'identité sont les même que dans les notifications précédentes si aucun élément d'identité n'est présent dans l'élément local ou distant correspondant. Si des éléments d'identité sont présents dans la partie locale ou distante d'une notification, la nouvelle liste d'étiquettes d'identité remplace complètement l'ancienne liste dans la partie correspondante.

<identity display="Anonymous">sip:anonymous@anonymous.invalid</identity>

 	4.1.6.2	Élément Cible
L'élément "target" contient l'URI cible local ou distant construit par l'agent d'utilisateur pour ce dialogue, comme défini dans la [RFC3261] dans un attribut "uri".

Il peut contenir une liste de paramètres d'en-tête "Contact" dans des sous éléments de paramètres (comme ceux définis dans la [RFC3840]). L'élément paramètre contient deux attributs exigés, pname et pval. Les paramètres booléens sont représentés par les valeurs explicites de pval, "vrai" et "faux" (par exemple, quand un paramètre de caractéristique est explicitement nié). Les paramètres qui n'ont pas de valeur du tout sont représentés par la valeur explicite de pval "vrai". L'élément param lui-même n'a pas de contenu. Pour éviter de répéter les informations de Contact dans chaque demande, l'abonné peut supposer que l'URI cible et les paramètres sont les mêmes que dans les notifications précédentes si aucun élément cible n'est présent dans l’élément local ou distant correspondant. Si un élément cible est présent dans la partie locale ou distante d'une notification, la nouvelle étiquette cible et la liste des étiquettes de paramètres remplace complètement la vieille liste de cibles et paramètres dans la partie correspondante. Noter que tous les guillemets (incluant les crochets angulaires supplémentaires de citation utilisés pour citer des valeurs de chaîne dans la [RFC3840]) ou l'échappement avec barre oblique inverse, DOIVENT être retirés avant d'être placés dans un attribut pval. Tous les guillemets simples, doubles, et esperluettes DOIVENT être échappés correctement selon XML.

<target uri="sip:alice@pc33.exemple.com">
  <param pname="isfocus" pval="true"/>
  <param pname="class" pval="business"/>
  <param pname="description" pval="Alice's desk &amp; office"/>
  <param pname="sip.rendering" pval="no"/>
</target>

 	4.1.6.3	Élément Description de session
L'élément "session-description" contient la description de la session utilisée par l'utilisateur observé pour sa fin de dialogue.  Cet élément NE DEVRAIT généralement PAS être inclus dans les notifications, sauf si cela était explicitement demandé par l'abonné. Il a un seul attribut, "type", qui indique le type de support MIME de la description de session. Pour éviter de répéter les informations de description de session dans chaque demande, l'abonné peut supposer que la description de session est la même que dans les notifications précédentes si aucun élément de description de session n'est présent dans l’élément local ou distant correspondant.

 	4.2	Exemple de corps de notification
<?xml version="1.0" encoding="UTF-8"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="urn:ietf:params:xml:ns:dialog-info"
  version="1" state="full">
  <dialog id="123456">
     <state>confirmed</state>
     <duration>274</duration>
     <local>
       <identity display="Alice">sip:alice@exemple.com</identity>
       <target uri="sip:alice@pc33.exemple.com">
         <param pname="isfocus" pval="vrai"/>
         <param pname="class" pval="personal"/>
       </target>
     </local>
     <remote>
       <identity display="Bob">sip:bob@exemple.org</identity>
       <target uri="sip:bobster@phone21.exemple.org"/>
     </remote>
  </dialog>
</dialog-info>

 	4.3	Construction d'un état cohérent
L'abonné aux informations de dialogue conserve un tableau qui fait la liste des dialogues, avec une rangée pour chaque dialogue. Chaque rangée est indexée par un identifiant qui est présent dans l'attribut "id" de l'élément "dialog". Chaque rangée contient l'état de ce dialogue, comme porté dans le document.

Le tableau est aussi associé à un numéro de version. Le numéro de version DOIT être initialisé avec la valeur de l'attribut "version" provenant de l'élément "dialog-info" dans le premier document reçu. Chaque fois qu'un nouveau document est reçu, la valeur du numéro de version local est comparée à l'attribut "version" dans le nouveau document. Si la valeur dans le nouveau document est supérieure de un au numéro de version local, le numéro de version local est incrémenté de un et le document est traité. Si la valeur dans le document est supérieure de plus de un au numéro de version local, le numéro de version local est réglé à la valeur du nouveau document et le document est traité. Si le document ne contenait pas l'état complet, l'abonné DEVRAIT générer une demande de rafraîchissement (SUBSCRIBE) pour déclencher une notification d'état plein. Si la valeur dans le document est inférieure à la valeur de la version locale, le document est éliminé sans traitement.

Le traitement du document d'information de dialogue dépend de si il contient l'état plein ou partiel. Si il contient l'état plein, indiqué par la valeur de l’attribut "state" dans l'élément "dialog-info", le contenu du tableau est purgé et ensuite rempli à partir du document. Une nouvelle rangée du tableau est créée pour chaque élément "dialog". Si le document contient un état partiel, comme indiqué par la valeur de l'attribut "state" dans l'élément "dialog-info", le document est utilisé pour mettre à jour le tableau. Pour chaque élement "dialog" dans le document, l'abonné vérifie pour voir si une rangée existe pour ce dialogue. Cette vérification compare les identifiants dans l'attribut "id" de l'élement "dialog" avec les identifiants associés à la rangée. Si le dialogue n'existe pas dans le tableau, une rangée est ajoutée et son état est réglé selon les informations provenant de cet élément "dialog". Si le dialogue existe bien, son état est mis à jour pour être l'information provenant de cet élément "dialog". Si une rangée est mise à jour ou créée, de sorte que cet état est maintenant terminé, cette entrée PEUT être retirée du tableau à tout moment.

 	4.4	Schéma
Voici le schéma pour le type application/dialog-info+xml :

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
  targetNamespace="urn:ietf:params:xml:ns:dialog-info"  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:tns="urn:ietf:params:xml:ns:dialog-info"  elementFormDefault="qualified"  attributeFormDefault="unqualified">
  <!-- Cette importation introduit l'attribut de langage XML xml:lang-->
  <xs:import namespace="http://www.w3.org/XML/1998/namespace"
     schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>
  <xs:element name="dialog-info">
   <xs:complexType>
      <xs:sequence>
        <xs:element ref="tns:dialog" minOccurs="0" maxOccurs="unbounded"/>
       <xs:any namespace="##other" processContents="lax"  minOccurs="0"  maxOccurs="unbounded"/>
     </xs:sequence>
      <xs:attribute name="version" type="xs:nonNegativeInteger" use="required"/>
      <xs:attribute name="state" use="required">
        <xs:simpleType>
         <xs:restriction base="xs:string">
            <xs:enumeration value="full"/>
            <xs:enumeration value="partial"/>
          </xs:restriction>
        </xs:simpleType>
      </xs:attribute>
     <xs:attribute name="entity" type="xs:anyURI" use="required"/>
    </xs:complexType>
  </xs:element>
  <xs:element name="dialog">
    <xs:complexType>
      <xs:sequence>
        <xs:element ref="tns:state" minOccurs="1" maxOccurs="1"/>
        <xs:element name="duration" type="xs:nonNegativeInteger" minOccurs="0" maxOccurs="1"/>
        <xs:element name="replaces" minOccurs="0" maxOccurs="1">
          <xs:complexType>
            <xs:attribute name="call-id" type="xs:string" use="required"/>
            <xs:attribute name="local-tag" type="xs:string" use="required"/>
            <xs:attribute name="remote-tag" type="xs:string"  use="required"/>
          </xs:complexType>
        </xs:element>
        <xs:element name="referred-par" type="tns:nameaddr"  minOccurs="0" maxOccurs="1"/>
        <xs:element name="route-set" minOccurs="0" maxOccurs="1">
          <xs:complexType>
            <xs:sequence>
              <xs:element name="hop" type="xs:string"  minOccurs="1" maxOccurs="unbounded"/>
            </xs:sequence>
          </xs:complexType>
        </xs:element>
        <xs:element name="local" type="tns:participant"  minOccurs="0" maxOccurs="1"/>
        <xs:element name="remote" type="tns:participant"  minOccurs="0" maxOccurs="1"/>
        <xs:any namespace="##other" processContents="lax"  minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="id" type="xs:string" use="required"/>
      <xs:attribute name="call-id" type="xs:string" use="optional"/>
      <xs:attribute name="local-tag" type="xs:string" use="optional"/>
      <xs:attribute name="remote-tag" type="xs:string" use="optional"/>
      <xs:attribute name="direction" use="optional">
        <xs:simpleType>
          <xs:restriction base="xs:string">
            <xs:enumeration value="initiator"/>
            <xs:enumeration value="recipient"/>
          </xs:restriction>
        </xs:simpleType>
         </xs:attribute>
    </xs:complexType>
  </xs:element>
  <xs:complexType name="participant">
    <xs:sequence>
      <xs:element name="identity" type="tns:nameaddr"
        minOccurs="0" maxOccurs="1"/>
      <xs:element name="target" minOccurs="0" maxOccurs="1">
        <xs:complexType>
          <xs:sequence>
            <xs:element name="param" minOccurs="0" maxOccurs="unbounded">
              <xs:complexType>
                <xs:attribute name="pname" type="xs:string" use="required"/>
                <xs:attribute name="pval" type="xs:string" use="required"/>
              </xs:complexType>
            </xs:element>
          </xs:sequence>
          <xs:attribute name="uri" type="xs:string" use="required"/>
        </xs:complexType>
      </xs:element>
      <xs:element name="session-description" type="tns:sessd" minOccurs="0" maxOccurs="1"/>
      <xs:element name="cseq" type="xs:nonNegativeInteger" minOccurs="0" maxOccurs="1"/>
      <xs:any namespace="##other" processContents="lax"  minOccurs="0" maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>
  <xs:complexType name="nameaddr">
    <xs:simpleContent>
      <xs:extension base="xs:anyURI">
        <xs:attribute name="display-name" type="xs:string" use="optional"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
  <xs:complexType name="sessd">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="type" type="xs:string" use="required"/>
      </xs:extension>
   </xs:simpleContent>

  </xs:complexType>

   <xs:element name="state">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="xs:string">
          <xs:attribute name="event" use="optional">
            <xs:simpleType>
              <xs:restriction base="xs:string">
                <xs:enumeration value="cancelled"/>
                <xs:enumeration value="rejected"/>
                <xs:enumeration value="replaced"/>
                <xs:enumeration value="local-bye"/>
                <xs:enumeration value="remote-bye"/>
                <xs:enumeration value="error"/>
                <xs:enumeration value="timeout"/>
              </xs:restriction>
            </xs:simpleType>
          </xs:attribute>
          <xs:attribute name="code" use="optional">
            <xs:simpleType>
              <xs:restriction base="xs:positiveInteger">
                <xs:minInclusive value="100"/>
                <xs:maxInclusive value="699"/>
              </xs:restriction>
             </xs:simpleType>
          </xs:attribute>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>
</xs:schema>

 	5.	Définition des paramètres de nouvelle caractéristique du support

Cette section définit deux nouveaux paramètres de caractéristique de support qui sont utiles comme entrée à la présence d'utilisateur, dans les applications de conférence, et dans des applications comme l’exemple de ligne partagée décrit au paragraphe 6.2. Ces paramètres de caractéristiques sont particulièrement utiles en combinaison avec le paquetage de dialogue, car ils permettent à un tiers autorisé de prendre connaissance de ces caractéristiques.

 	5.1	Paramètre "sip.byeless"
Le paramètre de caractéristique de support "sip.byeless" est un nouveau paramètre booléen, défini dans le présent document, qui fournit une indication positive que l'agent d'utilisateur qui établit le paramètre est incapable de terminer les sessions de lui-même (par exemple, par l'envoi d'une demande BYE). Par exemple, des services continus d'annonces et certains services d'enregistrement sont incapables de déterminer quand il serait souhaitable de terminer une session, et donc ils n'ont pas du tout la capacité de terminer les sessions. Aussi, de nombreux centres d'appels humains sont configurés de telle sorte qu'ils ne terminent jamais les sessions. (C’est pour empêcher les agents des centres d'appel de déconnecter accidentellement l'appelé). (Noter que selon la [RFC3840], ce nom de paramètre doit être précédé par un caractère "+" quand il est utilisé dans un champ d'en-tête SIP Contact.)

Contact: <sip:recording-service@host.example.net> ; automaton;+sip.byeless

 	5.2	Paramètre "sip.rendering" 
Le paramètre de caractéristique de support "sip.rendering" est un nouveau paramètre de chaîne, défini dans le présent document, qui peut fournir une indication positive de si l'agent d'utilisateur qui établit le paramètre est actuellement en train d'exécuter un des supports qu'il reçoit dans le contexte d'une session spécifique. Il DOIT seulement être utilisé dans un champ d'en-tête Contact dans un dialogue créé en utilisant la demande INVITE.

Ce paramètre a trois valeurs légales : "oui", "non", et "inconnu". La valeur "oui" indique la connaissance positive que l'agent d'utilisateur est en train de rendre au moins un des flux de supports qu'il reçoit. La valeur "non" indique la connaissance positive que l'agent d'utilisateur ne rend aucun des supports qu'il reçoit. La valeur "inconnu" indique que l'agent d'utilisateur ne sait pas si le support associé à la session est en cours d'exécution (ce qui peut être le cas si l'agent d'utilisateur agit comme contrôleur d'appel de tiers (3pcc,Third Party Call Control) [RFC3725]).

Le paramètre "sip.rendering" est utile dans des applications comme l'apparence partagée, la surveillance d'état de conférence, ou comme entrée à la présence de l'utilisateur.

Contact: <sip:musak-onhold@host.example.net> ; automaton;+sip.rendering="no"

 	6.	Exemples
 	6.1	Exemple de base
Par exemple, si un UAC envoie un INVITE qui ressemble, en partie, à :

INVITE sip:bob@exemple.com SIP/2.0
Via: SIP/2.0/UDP pc33.exemple.com;branch=z9hG4bKnashds8
Max-Forwards: 70
To: Bob <sip:bob@exemple.com>
From: Alice <sip:alice@exemple.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.exemple.com>
Content-Type: application/sdp
Content-Length: 142

[le SDP n'est pas montré]

Le document XML dans une notification provenant d'Alice pourrait ressembler à :

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:alice@exemple.com">
   <dialog id="as7d900as8" call-id="a84b4c76e66710" local-tag="1928301774" direction="initiator">
    <state>trying</state>
  </dialog>
</dialog-info>

Si la réponse 180 suivante est reçue :

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP pc33.exemple.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@exemple.com>;tag=456887766
From: Alice <sip:alice@exemple.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:bob@host.exemple.com>

Le document XML dans une notification pourrait être :

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="1" state="full" entity="sip:alice@example.com">
  <dialogue id="as7d900as8" call-id="a84b4c76e66710" local-tag="1928301774" remote-tag="456887766"
         direction="initiator">
    <state>early</state>
  </dialog>
</dialog-info>

Si il reçoit un second 180 avec une étiquette différente :

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP pc33.exemple.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@exemple.com>;tag=hh76a
From: Alice <sip:alice@exemple.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:jack@host.exemple.com>

Il en résulte la création d'un second dialogue :

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="2" state="full" entity="sip:alice@exemple.com">
  <dialog id="as7d900as8" call-id="a84b4c76e66710" local-tag="1928301774" remote-tag="456887766"
                direction="initiator">
    <state>early</state>
  </dialog>
  <dialog id="as7d900as8" call-id="a84b4c76e66710" local-tag="1928301774" remote-tag="hh76a"
                direction="initiator">
    <state>early</state>
  </dialog>
</dialog-info>

Si une réponse 200 OK est reçue sur le second dialogue, le dialogue passe à l'état confirmé :

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="3" state="partial" entity="sip:alice@exemple.com">
  <dialog id="as7d900as8" call-id="a84b4c76e66710" local-tag="1928301774" remote-tag="hh76a" direction="initiator">
   <state>confirmed</state>
  </dialog>
</dialog-info>

32 secondes plus tard, l'autre dialogue précoce se termine parce que aucune réponse 2xx n'a été reçue pour lui. Cela implique qu'il a été annulé avec succès, et donc la notification suivante est envoyée :

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="4" state="partial" entity="sip:alice@exemple.com">
  <dialog id="as7d900as8" call-id="a84b4c76e66710" local-tag="1928301774" remote-tag="hh76a" direction="initiator">
    <state event="cancelled">terminated</state>
  </dialog>
</dialog-info>

 	6.2	Émulation d'un système de téléphonie à ligne partagée
L'exemple suivant montre comment un agent d'utilisateur de téléphone SIP peut fournir des informations d'état détaillées et aussi émuler un système de téléphone à ligne partagée (le téléphone "ment" en disant qu'il est dans un dialogue alors qu'il est simplement décroché).

Repos :
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:alice@exemple.com">
  </dialog-info>

Prise :
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="1" state="partial" entity="sip:alice@exemple.com">
  <dialog id="as7d900as8">
    <state>trying</state>
  </dialog>
</dialog-info>

Numérotation :
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="2" state="partial" entity="sip:alice@exemple.com">
  <dialog id="as7d900as8" call-id="a84b4c76e66710" local-tag="1928301774" direction="initiator">
    <state>trying</state>
    <local>
      <identity display="Alice Smith">
           sip:alice@exemple.com
            </identity>
      <target uri="sip:alice@pc33.exemple.com"/>
    </local>
    <remote>
      <identity>sip:bob@exemple.net</identity>
   </remote>
  </dialog>
</dialog-info>

Sonnerie :
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="3" state="partial" entity="sip:alice@exemple.com">
  <dialog id="as7d900as8" call-id="a84b4c76e66710" local-tag="1928301774"
                remote-tag="07346y131" direction="initiator">
   <state code="180">early</state>
    <remote>
      <target uri="sip:bobster@host2.exemple.net"/>
    </remote>
  </dialog>
</dialog-info>

Réponse (par messagerie vocale) :
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="4" state="partial" entity="sip:alice@exemple.com">
  <dialog id="as7d900as8" call-id="a84b4c76e66710" local-tag="1928301774"
                remote-tag="07346y131" direction="initiator">
    <state reason="cancelled">terminated</state>
  </dialog>
  <dialog id="zxcvbnm3" call-id="a84b4c76e66710" local-tag="1928301774"
                remote-tag="8736347" direction="initiator">
    <state code="200">confirmed</state>
    <remote>
      <target uri="sip:bob-est-not-here@vm.exemple.net">
        <param pname="actor" pval="msg-taker"/>
        <param pname="automaton" pval="true"/>
        <param pname="+sip.byeless" pval="true"/>
      </target>
    </remote>
  </dialog>
</dialog-info>

Alice préfèrerait parler à l'assistant de Bob (Cathy Jones) plutôt qu'à la messagerie vocale de Bob. Elle indique sa préférence en pressant une clé (peut-être "0" en Amérique du Nord ou "9" en Europe). Le système de messagerie vocale de Bob agit alors sur cette pression de clé en transférant [RF5589] l'appel d'Alice à l'AOR de Cathy.

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="5" state="partial" entity="sip:alice@exemple.com">
  <dialog id="zxcvbnm3" call-id="a84b4c76e66710" local-tag="1928301774"
           remote-tag="8736347" direction="initiator">
    <state reason="replaced">terminated</state>
  </dialog>
  <dialog id="sfhjsjk12" call-id="o34oii1" local-tag="8903j4" remote-tag="78cjkus" direction="receiver">
          <state reason="replaced">confirmed</state>
    <replaces call-id="a84b4c76e66710" local-tag="1928301774" remote-tag="8736347"/>
    <referred-by>
      sip:bob-is-not-here@vm.exemple.net
    </referred-by>
    <local>
      <target uri="sip:alice@pc33.exrmple.com"/>
        <param pname="+sip.rendering" pval="yes"/>
    </local>
    <remote>
      <identity display="Cathy Jones">
         sip:cjones@exemple.net
      </identity>
      <target uri="sip:line3@host3.exrmple.net">
        <param pname="actor" pval="attendant"/>
        <param pname="automaton" pval="false"/>
      </target>
    </remote>
  </dialog>
</dialog-info>

Alice et Cathy parlent, Cathy ajoute Alice à une conférence locale :
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="6" state="partial" entity="sip:alice@exemple.com">
  <dialogue id="sfhjsjk12" call-id="o34oii1" local-tag="8903j4" remote-tag="78cjkus" direction="receiver">
    <state>confirmed</state>
    <remote>
      <target uri="sip:confid-34579@host3.exemple.net">
        <param pname="isfocus" pval="true"/>
     </target>
    </remote>
  </dialog>
</dialog-info>

Alice met Cathy en garde :
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="7" state="partial" entity="sip:alice@exemple.com">
  <dialog id="sfhjsjk12" call-id="o34oii1" local-tag="8903j4" remote-tag="78cjkus" direction="receiver">
    <state>confirmed</state>
    <local>
      <target uri="sip:alice@pc33.exemple.com"/>
        <param pname="+sip.rendering" pval="no"/>
      </target>
    </local>
  </dialog>
</dialog-info>

Cathy raccroche :
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="8" state="partial" entity="sip:alice@exemple.com">
  <dialogue id="sfhjsjk12" call-id="o34oii1" local-tag="8903j4" remote-tag="78cjkus" direction="receiver">
    <state reason="remote-bye">terminated</state>
  </dialog>
  <dialog id="08hjh1345">
    <state>trying</state>
  </dialog>
</dialog-info>

Alice raccroche :
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="9" state="full" entity="sip:alice@exemple.com">
</dialog-info>

 	6.3	Informations minimales de dialogue avec confidentialité
L'exemple suivant montre le même agent d'utilisateur fournissant des informations minimales pour conserver la confidentialité de services comme le rappel automatique.

Raccroché :
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:alice@exemple.com">
</dialog-info>

Décroché : (choix de mise en œuvre/politique pour Alice pour passer à cet "état" quand elle est "en prise", "en essai", "en cours", ou "confirmé".)
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="1" state="full" entity="sip:alice@exemple.com">
  <dialogue id="1">
    <state>confirmed</state>
  </dialog>
</dialog-info>

Raccroché : ( choix de mise en œuvre/politique pour Alice pour passer à cet "état" quand elle est dans l'état "terminé, ou quand elle n'est plus "en prise")
<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="2" state="full" entity="sip:alice@exemple.com">
</dialog-info>

 	7.	Considérations sur la sécurité

Les abonnements à l'état de dialogue peuvent révéler des informations sensibles. Pour cette raison, le paragraphe 3.6 discute de l'authentification et l'autorisation des abonnements, et fournit des lignes directrices sur les politiques d'autorisation raisonnables. Toutes les mises en œuvre de ce paquetage DOIVENT prendre en charge le mécanisme d'authentification par résumé.

Comme les données dans les notifications sont aussi sensibles, les mécanismes de chiffrement de SIP de bout en bout en utilisant S/MIME PEUVENT être utilisées pour les protéger. Les agents d'utilisateur qui mettent en œuvre le paquetage de dialogue DEVRAIENT aussi mettre en œuvre SIP sur TLS [RFC2246] et le schéma sips:.

 	8.	Considérations relatives à l'IANA

Le présent document enregistre un nouveau type MIME, application/dialog-info+xml, un nouvel espace de noms XML, et deux nouveaux paramètres de caractéristique de support dans l'arborescence SIP.

 	8.1	Enregistrement MIME pour le type application/dialog-info+xml
Nom de type de support MIME : application
Nom de sous type MIME : dialog-info+xml
Paramètres obligatoires : aucun
Paramètres facultatifs : les mêmes que le paramètre de jeu de caractère application/xml comme spécifié dans la [RFC3023].
Considérations de codage : les mêmes que les considérations de codage de application/xml spécifiées dans la [RFC3023].
Considérations de sécurité : voir la Section 10 de la [RFC3023] et la Section 7 de la présente spécification.
Considérations d'interopérabilité : aucune.
Spécification publiée : le présent document.
Applications qui utilisent ce type de support : le type du présent document a été utilisé pour prendre en charge des applications SIP telles que le retour d'appel et l'auto-conférence.
Informations supplémentaires :
Numéro magique : aucun
Extension de fichier : .xml
Code de type de fichier Macintosh : "TEXT"
Adresse personnelle et de messagerie pour des informations : Jonathan Rosenberg, <jdrosen@jdrosen.net>
Utilisation prévue : Commune
Auteur/contrôleur des changements : IETF.

 	8.2	Enregistrement du sous espace d'URN  urn:ietf:params:xml:ns:dialog-info
Ce paragraphe enregistre un nouvel espace de noms XML, selon les lignes directrices de la [RFC3688].

URI: urn:ietf:params:xml:ns:dialog-info.
Contact d'enregistrelment : IESG, <iesg@ietf.org> 
XML :
DÉBUT
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
          "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"/>
  <title>Dialog Information Namespace</title>
</head>
<body>
  <h1>Namespace for Dialog Information</h1>
  <h2>urn:ietf:params:xml:ns:dialogue-info</h2>
  <p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc4235.txt">
       RFC4235</a>.</p>
</body>
</html>
FIN

 	8.3	Enregistrement de schéma
La présente spécification enregistre un schéma, selon les lignes directrices de la [RFC3688].
URI : urn:ietf:params:xml:schema:dialog-info
Contact d'enregistrement : IESG, <iesg@ietf.org>
XML : le XML se trouve être le seul contenu du paragraphe 4.4.

 	8.4	Enregistrement de paramètre de caractéristique de support
Ce paragraphe enregistre deux nouvelles étiquettes de caractéristiques de support, selon les procédures définies dans la [RFC2506]. Les étiquettes sont placées dans l'arborescence sip, qui est définie dans la [RFC3840].

 	8.4.1	Étiquette et nom d'étiquette de caractéristique de support sip.byeless
Identifiant ASN.1 : 19
Résumé de la caractéristique de support indiquée par cette étiquette : cette étiquette de caractéristique est un fanion booléen. Établi, il indique que l'appareil est incapable de terminer une session de façon autonome.
Valeurs appropriées pour l'utilisation de cette étiquette de caractéristique : booléen (vrai/faux).
L'étiquette de caractéristique est principalement destinée à être utilisée dans les applications, protocoles, services, ou mécanismes de négociation suivants : applications de communications pour décrire les capacités d'une application, comme un service d'annonces, un service d'enregistrement, une conférence, ou un centre d'appels.
Exemples d'utilisation typique : centres d'appels et services de supports.
Normes ou documents en rapport : RFC 4235
Considérations de sécurité : cette étiquette de caractéristique de support peut être utilisée d'une façon qui affecte le comportement de l'application ou peut révéler des informations privées. Par exemple, une application de conférence ou autre peut décider de terminer prématurément un appel si cette étiquette de caractéristique du support est établie. Donc, si un attaquant peut modifier la valeur de cette étiquette, il peut être capable d'affecter le comportement des applications. Il en résulte que les applications qui utilisent cette étiquette de caractéristique de support DEVRAIENT fournir un moyen de s'assurer de son intégrité. De même, on ne devrait se fier à cette étiquette de caractéristique que lorsque elle provient de l'utilisateur ou agent d'utilisateur décrit par l'étiquette. Par suite, les protocoles pour convoyer cette étiquette de caractéristique DEVRAIENT fournir un mécanisme qui puisse être utilisé pour garantir l'authenticité.

 	8.4.2	Étiquette de caractéristique de support sip.rendering
Nom de l'étiquette de caractéristique de support : sip.rendering
Identifiant ASN.1 : 20
Résumé de la caractéristique de support indiquée par cette étiquette : cette étiquette de caractéristique contient une des trois valeurs de chaîne indiquant si l'appareil est entrain d'exécuter un support provenant de la session en cours ("oui"), aucun des supports de la session en cours ("non"), ou si cet état n'est pas connu de l'appareil ("inconnu").
Valeurs appropriées à l'utilisation de cette étiquette de caractéristique : chaîne.
L'étiquette de caractéristique est principalement destinée à être utilisée dans les applications, protocoles, services, ou mécanismes de négociation suivants : applications de communication, pour décrire l'état d'un appareil (comme un téléphone ou tablette) durant une session multimédia.
Exemples d'utilisation typiques : applications de conférence, d'émulation de téléphone à ligne partagée, et de présence.
Normes ou documents en rapport : RFC 4235
Considérations de sécurité : cette étiquette de caractéristique de support peut être utilisée d'une façon qui affecte le comportement de l'application ou peut révéler des informations privées. Par exemple, une application de conférence ou autre peut décider de terminer prématurément un appel si cette étiquette de caractéristique du support est réglée à "non". Donc, si un attaquant peut modifier la valeur de cette étiquette, il peut être capable d'affecter le comportement des applications. Il en résulte que les applications qui utilisent cette étiquette de caractéristique de support DEVRAIENT fournir un moyen de s'assurer de son intégrité. De même, on ne devrait se fier à cette étiquette de caractéristique que lorsque elle provient de l'utilisateur ou agent d'utilisateur décrit par l'étiquette. Par suite, les protocoles pour convoyer cette étiquette de caractéristique DEVRAIENT fournir un mécanisme qui puisse être utilisé pour garantir l'authenticité.

 	9.	Remerciements

Les auteurs tiennet à remercier Sean Olson de ses commentaires.

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

[RFC2141]	R. Moats, "Syntaxe des URN", mai 1997. (Obsolète, voir RFC8141)

[RFC2246]	T. Dierks et C. Allen, "Protocole TLS version 1.0", janvier 1999. (P.S. ; MàJ par RFC7919)

[RFC2506]	K. Holtman, A. Mutz, T. Hardie, "Procédure d'enregistrement d'étiquette de caractéristique de support", mars 1999. (BCP0031)

[RFC2648]	R. Moats, "Espace de nom d'URN pour les documents de l'IETF", août 1999. (Information)

[RFC3023]	M. Murata, S. St.Laurent et D. Kohn, "Types de support XML", janvier 2001. (Obsolète, voir RFC7303)

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

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

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

[RFC3515]	R. Sparks, "Méthode Refer du protocole d'initialisation de session (SIP)", avril 2003. (MàJ par RFC8217)

[RFC3688]	M. Mealling, "Registre XML de l'IETF", BCP 81, janvier 2004.

[RFC3840]	J. Rosenberg, H. Schulzrinne et P. Kyzivat, "Indication des capacités d'agent d'utilisateur dans le protocole d'initialisation de session (SIP)", août 2004

[RFC3891]	R. Mahy, B. Biggs, R. Dean, "En-tête "Replaces" du protocole d'initialisation de session (SIP)", 
septembre 2004. (P.S.)

[RFC3892]	R. Sparks, "Mécanisme Referred-par du protocole d'initialisation de session (SIP)", septembre 2004. (MàJ par RFC8217

[XML]	Paoli, J., Sperberg-McQueen, C., Bray, T., et E. Maler, "Langage de balisage extensible (XML) 1.0 (Seconde édition)", W3C FirstEdition REC-xml-20001006, octobre 2000.

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

[RFC3842]	R. Mahy, "Paquetage d'événement Résumé de message et Indication de message en attente pour le protocole d'initialisation de session (SIP)", août 2004.

[RFC3856]	J. Rosenberg, "Paquetage d'événement Presence pour le protocole d'initialisation de session (SIP)", août 2004.

[RFC3857]	J. Rosenberg, "Paquetage-gabarit d'événement d'information d'observateur pour le protocole d'initialisation de session (SIP)", août 2004. (P.S.)

[RFC5589]	R. Sparks, A. Johnston, éd., D. Petrie, "Contrôle du transfert d'appel dans le protocole d'initialisation de session (SIP)", juin 2009. (BCP0149) 

 	Adresse des auteurs

Jonathan Rosenberg	Henning Schulzrinne	Rohan Mahy (editor)	
Cisco Systems	Columbia University	SIP Edge LLC	
600 Lanidex Plaza	M/S 0401	mél : rohan@ekabal.com 	
Parsippany, NJ  07054	1214 Amsterdam Ave.		
US	New York, NY  10027		

 	Déclaration complète de 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 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.

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.