Groupe de travail Réseau	J. Rosenberg, Cisco Systems	
Request for Comments : 4575	H. Schulzrinne, Columbia University	
Catégorie : Sur la voie de la normalisation	O. Levin, éd., Microsoft Corporation	
Traduction Claude Brière de L'Isle	août 2006	

Paquetage d'événement du protocole d'initialisation de session (SIP) pour l'état de conférence

Statut du présent 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 "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de Copyright
Copyright (C) The Internet Society (2006).

Résumé
Le présent document définit un paquetage d'événement de conférence pour les conférences étroitement couplées en utilisant le cadre d'événements du protocole d'initialisation de session (SIP, Session Initiation Protocol) avec un format de données utilisé dans les notifications pour ce paquetage. Le paquetage de conférence permet à l'utilisateur de s'abonner à un identifiant de ressource universel (URI, Uniform Resource Identifier) de conférence. Des notifications sont envoyées sur les changements des membres de cette conférence et facultativement sur les changements de l'état des composants supplémentaires de la conférence.
Table des matières
1. Introduction	2
2. Terminologie	2
3. Paquetage d'événement Conférence	2
3.1 Nom de paquetage d'événement	3
3.2 Filtrage	3
3.3 Durée d'abonnement	3
3.4. Corps de NOTIFY	3
3.5 Traitement des demandes SUBSCRIBE par le notificateur	3
3.6 Génération des demandes NOTIFY par le notificateur	3
3.7 Traitement des demandes NOTIFY par l'abonné	4
3.8 Traitement des demandes fourchées	4
3.9 Taux des notifications	4
3.10 Agents d'état	4
4. Document Conférence	4
4.1 Format	4
4.2 Espace de noms	4
4.3 Version	5
4.4 Mécanisme de notifications partielles	5
4.5 Clés des éléments	5
4.6 Construction d'une procédure d'état cohérent	6
5. Données de conférence	6
5.1 Vue d'ensemble	6
5.2 <conférence-info>	7
5.3 <conférence-description>	8
5.4 <host-info>	10
5.5 <conférence-état>	10
5.6 <utilisateurs> et son sous élément <utilisateur> 10
5.7 <point d'extrémité>	12
5.8. <media>	14
5.9 Annexes	15
6. Schéma XML	16
7. Exemples	22
7.1 Exemple de base	22
7.2 Exemple enrichi	24
8. Considérations sur la sécurité	27
8.1 Sécurité de la connexion	27
8.2 Considérations d'autorisation	27
9. Considérations relatives à l'IANA	27
9.1 Enregistrement du paquetage d'événement de conférence	27
9.2 Enregistrement de application/conférence-info+xml MIME	27
9.3 Enregistrement de sous espace de noms d'URN pour urn:ietf:params:xml:ns:conférence-info	28
9.4 Enregistrement de schéma XML	28
9.5 Établissement du sous registre URI Purposes	28
10. Remerciements	29
11. Références	29
11.1 Références normatives	29
11.2 Références pour information	30
Adresse des auteurs	30
Déclaration complète de droits de reproduction	31

 	1.	Introduction

Le cadre d'événements du protocole d'initialisation de session (SIP) [RFC3265] définit les mécanismes généraux pour s'abonner et recevoir des notifications des événements au sein des réseaux SIP. Il introduit la notion de paquetage, qui est une "instanciation" spécifique du cadre d'événements pour un ensemble bien défini d'événements. On définit ici un paquetage d'événement SIP pour des conférences étroitement couplées. Ce paquetage peut être utilisé par le service de notification de conférence comme mentionné dans le cadre de conférence SIP [RFC4353]. Comme il y est décrit, les abonnements à un URI de conférence sont acheminés au point de concentration qui traite la conférence. Il agit comme notificateur et fournit aux clients des mises à jour de l'état de la conférence.

Les informations fournies par ce paquetage comportent le ou les identifiant de la conférence, les participants à la conférence (facultativement avec leur statut et la description de leurs supports) les annexes (sidebars) de la conférence, les URI de service de la conférence, etc.

 	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'exigences pour les mises en œuvre conformes.

Le présent document utilise la terminologie de conférence définie dans le cadre pour les conférences de la [RFC4353]. De plus, le terme "assistance" (roster) est utilisé pour se référer collectivement aux participants à une conférence ou sous conférence.

 	3.	Paquetage d'événement Conférence

Le paquetage d'événement de conférence permet à un utilisateur de s'abonner aux information relatives à une conférence. Dans SIP, les conférences sont représentées par des URI. Ces URI identifient un agent d'utilisateur (UA, User Agent) SIP, appelé un point de convergence (focus), qui est chargé de s'assurer que tous les utilisateurs dans la conférence peuvent communiquer les uns avec les autres, comme décrit dans le cadre de conférences [RFC4353]. Le point de convergence a des informations suffisantes sur l’état de la conférence pour en informer les abonnés.

Il est possible qu'un participant à la conférence puisse en fait être un autre point de convergence. Afin de fournir une liste plus complète des participants, le point de convergence PEUT s'abonner au paquetage de conférence des autres points de convergence pour découvrir la liste des participants dans la cascade de conférences. Ces informations peuvent alors être incluses dans des notifications par l'utilisation de l'élément <cascaded-focus> comme spécifié par ce paquetage.

Le présent paragraphe donne les détails pour définir un paquetage de notification d'événement spécifique de SIP, comme spécifié par la [RFC3265].

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

 	3.2	Filtrage
Les filtres, qui peuvent être appliqués aux abonnements aux conférences, sont une caractéristique désirable et peuvent être considérés comme l'objet de futures activités de normalisation. Le présent document ne définit pas de filtres pour le paquetage de conférence à inclure dans le corps de SUBSCRIBE.

Un SUBSCRIBE pour un paquetage de conférence, si il est envoyé sans corps, implique la politique de filtrage d'abonnement par défaut. La politique par défaut est la suivante :
o	Les notifications sont générées chaque fois qu'il y a un changement dans l'état de la conférence.
o	les notifications ne contiennent normalement pas l'état complet ; elles indiquent seulement plutôt l'état qui a changé. L'exception est un NOTIFY envoyé en réponse à un SUBSCRIBE. Ces NOTIFY contiennent l'état complet des informations demandées par l'abonné.

 	3.3	Durée d'abonnement
Le temps d'expiration par défaut pour un abonnement à une conférence est une heure. Une fois la conférence finie, tous les abonnements à cette conférence particulière sont terminés, avec une cause de "noresource" (pas de ressources) comme défini dans la [RFC3265].

 	3.4.	Corps de NOTIFY
Conformément à 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 mentionné 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 dans le SUBSCRIBE.

Dans ce paquetage d'événement, le corps de la notification contient un document d'informations de conférence qui décrit l'état d'une conférence. Tous les abonnés et notificateurs DOIVENT prendre en charge le format de données "application/conférence-info+xml" décrit aux Sections 5 et 9. Par défaut, c'est-à-dire, si aucun en-tête Accept n'est spécifié dans une demande SUBSCRIBE, le NOTIFY va contenir un corps dans le format de données "application/conférence-info+xml". Si le champ d'en-tête Accept est présent, il DOIT inclure "application/conférence-info+xml" et PEUT inclure tous autres types.

 	3.5	Traitement des demandes SUBSCRIBE par le notificateur
Les informations de conférence contiennent des informations très sensibles. Donc, tous les abonnements DEVRAIENT être authentifiés et ensuite autorisés avant approbation. La politique d'autorisation est à la discrétion de l'administrateur, comme toujours.

Cependant, il est RECOMMANDÉ que tous les utilisateurs de la conférence soient autorisés à s'abonner au paquetage d'événement de conférence.

 	3.6	Génération des demandes NOTIFY par le notificateur
Les notifications DEVRAIT être générées pour l'état de conférence quand un nouveau participant s'y joint (c'est-à-dire, y est "connecté") ou qu'un participant la quitte (c'est-à-dire, en est "déconnecté").

Sous réserve de la politique d'un point de convergence local, des changements supplémentaires de l'état des participants, des changements de leurs types de supports, et d'autres informations facultatives PEUVENT être rapportés par le point de convergence.

Les changements des listes d'annexes DEVRAIENT être rapportés par le point de convergence aux participants et PEUVENT être rapportés aux autres, sous réserve de la politique locale.

Les changements des identifiants de conférence et des URI de service DEVRAIENT être rapportés par le point de convergence aux abonnés au paquetage de conférence.

Les changements d'autres informations d'état de conférence PEUVENT être rapportés par le point de convergence aux abonnés au paquetage de conférence.

 	3.7	Traitement des demandes NOTIFY par l'abonné
Le cadre d'événements SIP attend des paquetages qu'ils spécifient comment un abonné traite les demandes NOTIFY d'une façon spécifique du paquetage, et en particulier, 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 conférence va seulement contenir des informations sur les utilisateurs dont l'état dans la conférence a changé. Pour construire une vue cohérente de l'état total de tous les utilisateurs, un abonné au paquetage de conférence va avoir besoin de combiner les NOTIFY reçus au fil du temps.

Les notifications au sein de ce paquetage peuvent porter 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. Les détails de ce mécanisme sont spécifiques du type de document particulier. Voir au paragraphe 4.6 des informations sur la construction d'informations cohérentes à partir d'un document application/conférence-info+xml.

 	3.8	Traitement des demandes fourchées
Par nature, les conférences prises en charge par ce paquetage sont centralisées. Donc, les demandes SUBSCRIBE pour une conférence ne devraient généralement pas fourcher. Si un fourchement se produit dans le réseau, les abonnés à ce paquetage NE DOIVENT PAS établir plus d'un seul dialogue SIP par suite d'une seule demande SUBSCRIBE. Dans le cas de points de convergence en cascade, des informations de conférence détaillées peuvent être restituées en établissant un dialogue SUBSCRIBE individuel avec chaque point de convergence participant.

 	3.9	Taux des notifications
Pour des raisons de contrôle d'encombrement, il est important que le taux de notifications ne devienne pas excessif. Par suite, il est RECOMMANDÉ que le serveur ne génère pas de notifications pour un seul abonné à un taux supérieur à une toutes les 5 secondes.

 	3.10	Agents d'état
L'état de conférence est idéalement maintenu dans l'élément dans lequel réside la conférence. Donc, un point de convergence de conférence est l'élément qui convient le mieux pour traiter les abonnements qui le concernent. Les points de convergence en cascade PEUVENT mettre en œuvre des agents d'état (comme défini dans la [RFC3265]) pour ce paquetage.

 	4.	Document Conférence
 	4.1	Format
Les informations de conférence sont un document XML qui DOIT être bien formé et valide. Il DOIT être fondé sur le langage de balisage extensible (XML, Extensible Markup Language) 1.0 et DOIT être codé en UTF-8 [RFC3629].

 	4.2	Espace de noms
La présente spécification utilise l'espace de noms XML pour identifier les documents d'informations de conférence et les fragments de documents. L'URI d'espace de noms pour les éléments définis par la présente spécification est un espace de noms de ressource universel (URN, Uniform Resource Namespace) [RFC2141], qui utilise l'identifiant d'espace de noms "ietf" défini par la [RFC2648] et étendu par la [RFC3688]. Cet URN est comme suit : urn:ietf:params:xml:ns:conference-info.

 	4.3	Version
Les informations de conférence sont décrites par une structure XML hiérarchique avec l'élément racine <conférence-info>.  L'élément racine est le seul élément du schéma qui porte un numéro de version significatif pour tous les éléments dans le document. Les informations de conférence complètes sont associées à ce numéro de version.

L'attribut "version" DOIT être inclus dans l'élément racine <conférence-info>.

 	4.4	Mécanisme de notifications partielles
La présente spécification définit un mécanisme de base de notifications partielles en utilisant un attribut "état" comme décrit ci-dessous. Ce mécanisme DOIT être pris en charge par tous les clients qui s'abonnent. Des mécanismes généraux supplémentaires de notifications partielles peuvent être définis et appliqués à ce paquetage à l'avenir.

Tous les sous éléments dans la structure XML hiérarchique <conférence-info> peuvent être classés en deux groupes : les notifications partielles sont permises ou non. Les éléments qui portent une quantité substantielle de données qui sont sujettes à de fréquents changements sont admis à la notification partielle et ont un attribut '"état" qui leur est attaché. Toutes les futures extensions à ce schéma DOIVENT définir quels éléments d'extension peuvent aussi utiliser ce mécanisme. Tous les autres éléments peuvent être mis à jour seulement comme éléments de données atomiques.

Voici la liste complète des éléments à qui il est permis d'utiliser le mécanisme de notifications partielles défini dans la présente spécification. (Noter que de futurs mécanismes de notifications partielles pourront être applicables aux éléments supplémentaires.)

o  Élément <conférence-info>
o  Élément <utilisateurs>
o  Élément <utilisateur>
o  Élément <point d'extrémité>
o  Élément <annexes-par-valeur>
o  Élément <annexes-par-référence>

La valeur d'attribut "état" indique si les informations rapportées sur l'élément sont "pleines" ou "partielles", ou si l'élément a été "supprimé" du document d'état de conférence. La valeur par défaut de tout attribut "état" est "pleines".

Un attribut "état" d'un élément fils dans le document DOIT être cohérent avec le "état" de son parent. Cela signifie que si le "état" du parent est "pleines", l'état de son fils DOIT être "pleines". Si le "état" du parent est "partiel", l'état de son fils PEUT être soit "partielles", "pleines", ou "supprimé". Un élément parent avec l'état "supprimé" NE DEVRAIT PAS contenir d'élément fils. Toute information fournie pour des éléments fils d'un parent "supprimé" DOIT être ignorée par l'abonné au paquetage.

 	4.5	Clés des éléments
Le schéma XML défini a une propriété d'identification unique parmi les sous éléments d'un parent commun, qui rend possible d'utiliser le mécanisme de notifications partielles défini dans ce document. Cette propriété est réalisée en définissant une clé pour chaque sous élément qui peut apparaître plusieurs fois sous le parent commun.

Dans le contexte de la présente spécification, la clé d'élément est l'ensemble des attributs ou sous éléments obligatoires d'un élément. La valeur de clé DOIT être unique pour l'élément parmi ses cousins de même type.

Dans le contexte de la présente spécification, deux clés de type xs:anyURI sont considérées être égales si les représentations UTF-8  des clés (incluant tous les paramètres d'URI qui peuvent être inclus avec l'URI) sont identiques. Par conséquent, l'utilisation d'URI relatifs et d'espaces blanches lexicales dans ces clés n'est PAS RECOMMANDÉ.

Ci-dessous est la liste des éléments (sous réserve de notifications partielles de leurs éléments parents) avec leurs clés comme défini par la présente spécification :

o  Élément <utilisateur> utilise comme clé "entité"
o  Élément <point d'extrémité> utilise comme clé "entité"
o  Élément <media> utilise comme clé "id"
o  Élément <entrée> (enfant de <annexes-par-valeur>) utilise comme clé "entité"
o  Élément <annexes-par-référence> utilise comme clé <uri>

 	4.6	Construction d'une procédure d'état cohérent
Le présent paragraphe décrit l'algorithme pour construire un état de conférence cohérent par un abonné au paquetage de conférence. En utilisant une abstraction de programmation de logiciel, l'abonné maintient un seul numéro de version locale pour tout le document de conférence et une instance d'élément local pour chaque élément du schéma. Aussi, pour chaque élément avec des clés(comme défini ci-dessus) l'abonné maintient un tableau virtuel avec une rangée pour chaque valeur de clé existante.

La première fois qu'est reçu un NOTIFY avec un document "plein" (comme indiqué par la valeur de l'attribut "état" dans l'élément <conférence-info>) l'abonné au paquetage de conférence DOIT régler le numéro de "version" local à la valeur de l'attribut "version" des <conférence-info> reçues et remplir les données locales avec les informations reçues.

Chaque fois qu'un nouveau NOTIFY est reçu, la valeur du numéro de version locale et la valeur de l'attribut "version" dans le nouveau document reçu sont comparées. Si la valeur dans le document est égale ou inférieure à celle de la version locale, le document est éliminé sans traitement.

Autrement, si le NOTIFY reçu contient un état "plein" ou "supprimé", l'abonné au paquetage de conférence DOIT régler le numéro de "version" local à la valeur de l'attribut "version" des <conférence-info> reçues et remplacer les informations locales par le document reçu. Recevoir un état "supprimé" pour l'élément <conférence-info> signifie que la conférence a cessé d'exister et l'abonné DEVRAIT terminer l'abonnement par l'envoi de SUBSCRIBE avec Expires = 0.

Autrement (c'est-à-dire, si le NOTIFY reçu contient l'état "partiel") si le numéro de "version" dans le document reçu est supérieur de plus de un au précédent numéro de version locale, l'abonné DOIT générer une demande de rafraîchissement d'abonnement pour déclencher une notification d'état plein. Si le numéro de "version" dans le document est supérieur de un au numéro de version locale, le numéro de version locale est mis à jour en conséquence et le document est utilisé pour mettre à jour le contenu local comme décrit ci-dessous.

Pour chaque sous élément de l'élément <conférence-info> dans le document reçu,
1.	Si l'élément contient l'état "plein", tout le contenu de l'élément local est purgé et rempli à partir du document.
2.	Autrement, si l'élément contient l'état "supprimé", tout l'élément DOIT être retiré du contenu local.
3.	Autrement, si l'élément contient l'état "partiel" :
3.1.	pour les éléments avec des clés, l'abonné compare les clés reçues dans la mise à jour, avec les clés dans les tableaux locaux  ;
3.1.1.	si une clé n'existe pas dans le tableau local, une rangée est ajoutée, et son contenu est réglé aux informations de l'élément provenant de la mise à jour  ;
3.1.2.	autrement, si une clé de même valeur existe, pour chaque sous élément de la rangée, l'algorithme est appliqué à partir de l'étape 3.2  ;
3.2.	pour chaque élément atomique reçu dans le schéma, l'élément est remplacé globalement par les nouvelles informations. Pour chaque élément non atomique reçu dans le schéma soit sans attribut "état", soit avec l'attribut état réglé à "plein", l'élément est remplacé globalement par les nouvelles informations. Aussi, pour chaque élément avec l'attribut état réglé à "supprimé", tout l'élément est retiré du contenu local.
3.3.	Pour chaque élément non atomique avec l'attribut état réglé à "partiel", l'algorithme est appliqué de façon récurrente en commençant à l'étape 3.1.

 	5.	Données de conférence
 	5.1	Vue d'ensemble
Le format du document <conférence-info> est conçu pour convoyer les informations sur la conférence et sur la participation à la conférence. Le diagramme non normatif suivant donne un exemple de la hiérarchie globale utilisée dans ce format. Les conférences contiennent des utilisateurs qui peuvent être représentés par plusieurs points d'extrémité, dont chacun peut avoir plusieurs flux de supports. Les conférences peuvent aussi inclure ou référencer des "conférences annexes". Quand des informations d'annexe sont incorporées dans un document d'informations de conférence dans un élément <annexes-par-valeur>, chaque élément <entrée> représente une annexe et peut inclure tous sous éléments permis dans l'élément <conférence-info> de niveau supérieur.

   conférence-info
     |
     |-- conférence-description
     |
     |-- informations d'hôte
     |
     |-- état-de-conférence
     |
     |-- utilisateurs
     |    |-- utilisateur
     |    |    |-- point d'extrémité
     |    |    |    |-- support
     |    |    |    |-- support
     |    |    |    |-- informations-d'appel
     |    |    |
     |    |    |-- point d'extrémité
     |    |         |-- support
     |    |-- utilisateur
     |         |-- point d'extrémité
     |              |-- support
     |
     |--  annexes-par-référence
     |    |-- entrée
     |    |-- entrée
     |
     |-- annexes-par-valeur
          |-- entrée
          |    |-- utilisateurs
          |         |-- utilisateur
          |         |-- utilisateur
          |-- entrée
               |-- utilisateurs
                    |-- utilisateur
                    |-- utilisateur
                    |-- utilisateur

Dans la plupart des cas, ce document ne rend pas obligatoire la façon dont les informations, présentées aux abonné dans le document de conférences, sont obtenues par le point de convergence. Dans de nombreux cas, les informations peuvent être apprises de façon dynamique à partir de la signalisation d'appel et peuvent aussi être remplies manuellement par un administrateur – sous réserve des politiques locales. Le présent document spécifie quels éléments XML signifient un ordre pour permettre aux abonnés de l'interpréter correctement. Certaines portions des informations sont destinées au traitement par un automate ; d'autres sont seulement pour la consommation humaine. Par exemple, les sous éléments <texte-d'affichage> des éléments <conf-uris>, <service-uris>, <support-disponible>, <informations-d'hôte>, <point d'extrémité>, et <support> sont destinés à l'affichage pour les seuls abonnés humains.

Bien qu'en plusieurs endroits le présent document déclare que des informations spécifiques "DEVRAIENT" être communiquées aux abonnés, on note que les abonnés à un paquetage de conférence particulier (par exemple, représentant un modérateur, un administrateur, ou un point de convergence en cascade) s'appuient sur la précision de ces informations pour leur bon fonctionnement. Donc, un serveur de conférence DOIT s'assurer que tous les changements critiques (déclarés comme "DEVRAIT") sont communiqués à ces abonnés spécifiques ; autrement, ces changements DOIVENT être communiqués à tous les abonnés aux informations de conférence.

Les paragraphes qui suivent décrivent le schéma XML plus en détail.

 	5.2	<conférence-info>
Un document d'informations de conférence commence par l'étiquette d'élément racine <conférence-info> du type conférence.

Les attributs suivants sont définis pour <conférence-info>:

entité : cet attribut contient l'URI de conférence qui identifie la conférence décrite dans le document. C'est l'URI SIP auquel une entité intéressée doit SOUSCRIRE afin d'obtenir le paquetage des informations de conférence. Noter que cet URI peut être listé comme un des URI à utiliser afin d'accéder à la conférence au moyen de SIP et en accord avec le paragraphe 5.3.1 ci-dessous.

état : cet attribut indique si le document contient toutes les informations de conférence ("plein") ou seulement les informations qui ont changé depuis le précédent document ("partiel") ou si la conférence a cessé d'exister ("supprimé"). Voir les détails à la Section 4.

version : cet attribut permet au receveur des documents d'informations de conférence d'ordonner correctement les notifications reçues, et il DOIT être utilisé avec l'élément racine <conférence-info>. Le numéro de version est un entier de 32 bits à accroissement monotone dont la portée est l'abonnement. Un serveur DOIT incrémenter le numéro de version pour chaque notification (plein, partiel, et supprimé) envoyé à un abonné et rapportant un changement de l'état du document de conférence. Pour chaque notification partielle, le numéro de version DOIT être augmenté de un. Noter qu'une notification partielle et une notification pleine suivante sur le même dialogue PEUVENT contenir le même numéro de version si aucun changement de l'état de conférence ne s'est produit entre elles.

L'élément <conférence-info> est composé des éléments fils <conférence-description>, <informations-d'hôte>, <état-de-conférence>, <utilisateurs>, <annexes-par-référence> et <annexes-par-valeur>. Un document de conférence "plein" DOIT au moins inclure les éléments fils <conférence-description> et <utilisateurs>.

Les paragraphes qui suivent décrivent des éléments en détails. Le schéma XML complet est fourni à la Section 6.

 	5.3	<conférence-description>
L'élément <conférence-description> décrit la conférence comme un tout.

Les éléments fils <texte-d'affichage>, <sujet>, <texte-libre>, et <mots-clés> sont utilisés pour décrire le contenu de la conférence :

<texte d'affichage> : Contient un texte descriptif convenable pour la consommation humaine, par exemple, une liste dans un répertoire.

<sujet> : Contient le sujet de la conférence.

<texte-libre> : Contient une description supplémentaire plus longue de la conférence.

<mots-clés>:  Contient une liste de jetons séparés par des espaces qui peuvent être utilisés par des moteurs de recherche pour mieux classer la conférence.

Des éléments fils supplémentaires <conf-uris> et <service-uris> sont utilisés pour décrire les URI relatifs à la conférence ; <compte-maximum-utilisateur> et <support-disponible> sont utilisés pour décrire les caractéristiques globales.

Ces informations sont normalement déduites des politiques de conférence du système  ; elles sont réglées avant l'activation de la conférence, et sont rarement changées durant la vie de la conférence.

Les paragraphes qui suivent décrivent les éléments restants plus en détails. D'autres sous éléments pourront étendre <conférence-description> à l'avenir.

 	5.3.1	<conf-uris>
Cet élément contient une séquence d'éléments fils de <entrée> - chacun contenant l'URI à utiliser afin d'accéder à la conférence par les différents moyens de signalisation. La valeur de l'URI DOIT être unique dans le contexte de la conférence et est incluse dans le sous élément <uri>.

Chaque <entrée> PEUT contenir des informations supplémentaires utiles au participant quand il accède à la conférence.

Un élément <entrée> PEUT contenir le sous élément <texte d'affichage> qui fournit une description textuelle destinée à la consommation humaine.

Chaque élément <entrée> DEVRAIT contenir un sous élément <objet> qui décrit ce qui se passe quand on accède à l'URI.  Les valeurs de <objet> actuellement définies pour être utilisées avec <conf-uris> sont les suivantes :
participation : Accéder à un URI avec cet <objet> va amener cette partie dans la conférence.
streaming  : Accéder à un URI avec cet <objet> va commencer à suivre la conférence, mais sans pemettre une participation active.

Des exemples de schémas d'URI convenables incluent les URI sip: et sips: [RFC3261], xmpp: [RF4854], h323: [RFC3508], et tel: [RFC3966]. L'URI rtsp [RFC2326] convient pour les flux de direct (streaming).

De futures extensions à ce schéma pourront définir de nouvelles valeurs et les enregistrer auprès de l'IANA sous le registre établi par la présente spécification.

 	5.3.2	<service-uris>
Cet élément décrit les services auxiliaires disponibles pour la conférence. Comme <conférence-uris>, cet élément contient un ensemble d'éléments <entrée> fils - contenant chacun l'URI à utiliser afin d'accéder aux différents services disponibles pour cette conférence. La valeur de l'URI DOIT être unique dans le contexte de la conférence et est inclus dans le sous élément <uri>.

Un élément <entrée> PEUT contenir le sous élément <texte d'affichage> qui fournit une description textuelle destinée à la consommation de l'utilisateur.

Chaque élément <entrée> DEVRAIT contenir un sous élément <objet>. Les valeurs de <objet> actuellement définies pour être utilisées avec le <service-uris> sont les suivantes :

web-page : Indique la page de la Toile qui contient les informations supplémentaires sur la conférence.

Enregistrement : Indique le lien auquel le contexte enregistré de la conférence peut être restitué.

Événement : Indique l'URI auquel peut être demandé un abonnement au paquetage d'événement de conférence. Cela va être normalement l'URI de conférence de la conférence principale.

De futures extensions à ce schéma pourront définir de nouvelles valeurs et les enregistrer auprès de l'IANA dans le registre établi pour la présente spécification.

 	5.3.3	<compte-maximum-utilisateur>
La valeur de cet élément fournit une indication au receveur du document de conférence sur le nombre d'utilisateurs qui peuvent être invités à la conférence. Normalement, cette valeur représente le nombre total d'utilisateurs auxquels il est permis de se joindre à la conférence par les différents moyens tels que publiés par le document de conférence dans <conf-uris>. Noter que cette valeur est réglée par un administrateur et peut refléter toute combinaison de politiques locales comme la consommation du réseau, la puissance de traitement de CPU, et les règles de licences.

 	5.3.4	<support-disponible>
Cet élément contient une séquence d'éléments <entrée> fils du type support de conférence, chacun étant indexé par l'attribut "étiquette".

L'attribut "étiquette" est l'identifiant de flux de supports alloué par le serveur de conférence : sa valeur va être unique dans le contexte de <conférence-info>. La valeur de cet attribut va normalement correspondre à l'attribut de support du protocole  de description de session (SDP, Session Description Protocol) "label" défini dans la [RFC4574].

Chaque <entrée> décrit un seul flux de support disponible aux participants à la conférence et contient les informations suivantes :

 <texte d'affichage> : cet élément contient le texte affiché pour le flux de supports.

<type>: cet élément contient le type de supports du flux de supports. La valeur de cet élément DOIT être une des valeurs enregistrées pour "supports" de SDP [RFC4566] et ses révisions ultérieures, par exemple, "audio", "video", "text", et "message".

<état>: cet élément indique l'état disponible du flux de supports pour les participants à la conférence. Par exemple, ce pourrait être l'état du flux de supports, qui serait offert par le point de convergence, dans un scénario "d'accès extérieur commuté". En utilisant les mécanismes normaux d'offre/réponse de SIP (définis dans la [RFC3264]) dans les deux scénarios d'accès intérieur commuté et d'accès extérieur commuté, un participant peut bien sûr établir seulement un sous ensemble du flux disponible (c'est-à-dire, demander ou accepter le flux dans une seule direction, si les deux directions sont disponibles). Les valeurs valides sont "sendrecv" (envoi-réception), "sendonly" (envoi seul), "recvonly" (réception seule), ou "inactive" comme défini dans SDP [RFC4566] et ses révisions ultérieures. (Noter que la valeur spécifie la direction du point de vue des participants.)

 	5.4	<info-d'hôte>
Cet élément contient les informations sur l'entité qui héberge la conférence. Ces informations sont réglées avant l'activation de la conférence, et sont rarement changées durant la vie de la conférence, sauf si toute la conférence est déplacée pour être hébergée par une autre entité. Les informations d'hôte se composent des éléments suivants.

 	5.4.1	<texte d'affichage>
Cet élément contient le texte d'affichage qui décrit l'entité qui héberge la conférence.

 	5.4.2	<web-page>
Cet élément contient l'URI HTTP: ou HTTPS: d'une page de la Toile qui décrit soit le service de conférence soit l'utilisateur qui héberge la conférence.

 	5.4.3	<uris>
Cet élément contient un ensemble d'éléments <entrée> fils, contenant chacun la valeur de l'URI et facultativement sa description.

 	5.5	<conférence-état>
En incluant cet élément dans le document de conférence, le serveur peut informer les abonnés des changements dans les informations de conférence globales. Les éléments <conférence-état> fils sont décrits ci-dessous.

 	5.5.1	<compte-d'utilisateur>
La valeur de cet élément dit au receveur du document de conférence le nombre total d'utilisateurs participant à la conférence à un certain moment. Normalement, cette valeur représente le nombre total des utilisateurs qui se sont joints à la conférence par les différents moyens publiés par le document de conférence dans <conf-uris>. Noter que ce nombre ne correspond pas nécessairement et PEUT excéder le nombre d'entrées dans le conteneur <utilisateurs>. Par exemple, dans un scénario de conférence, les notifications de grandes conférence peuvent ne pas inclure tous les participants dans l'élément <utilisateurs>, mais plutôt ne rapporter que le jury ou les intervenants.

 	5.5.2	<active>
Cet élément booléen indique si la conférence est actuellement active. Une conférence est active si l'appel à un des <conf-uris> par un client autorisé résulte en un établissement réussi d'une session de signalisation entre le client et le point de convergence et une jonction réussie à la conférence.

 	5.5.3	<locked>
Cet élément booléen indique si la conférence est actuellement verrouillée. Dans ce contexte, "locked" signifie qu'on ne peut plus rien ajouter au rôle de la conférence (bien que des participants puissent quitter la conférence ou en être retirés).

 	5.6	<utilisateurs> et ses sous éléments <utilisateur>
L'élément <utilisateurs> est un conteneur des éléments <utilisateur> fils, chacun décrivant un seul participant à la conférence.

Les attributs suivants sont définis pour l'élément <utilisateur> :

entité : cet attribut contient l'URI pour l'utilisateur de la conférence. C'est un identifiant logique, qui correspond à l'identité authentifiée de signalisation d'appel du participant. La valeur "entité" DOIT être unique parmi tous les participants à la conférence. Si, pour certains participants, le point de convergence décide de ne pas révéler cette information (par exemple, à cause des politiques locales ou de raisons de sécurité) la portion hôte de l'URI d'utilisateur DOIT utiliser le domaine de niveau supérieur (TLD, top level domain) ".invalid" en accord avec les définitions de la [RFC2606]. Le point de convergence DOIT aussi construire la portion utilisateur de l'URI de façon que l'URI soit unique parmi tous les participants du même domaine. Par exemple, la convention "AnonymeX" <sip:anonymeX@anonyme.invalid> DEVRAIT être utilisée pour un participant qui exige la confidentialité en accord avec les lignes directrices pour générer des URI anonymes dans la [RFC3323]. Noter que dans un cas différent, comme quand utilisé en conjonction avec les améliorations pour la gestion d'identité authentifiée dans SIP [RFC4474], la convention peut être utilisée : "AnonymeX" <sip:anonymeX@exemple.com>

état :  cet attribut indique si le document contient toutes les informations d'utilisateur ("plein") ou seulement les informations qui ont changé depuis le précédent document ("partiel") ou si l'utilisateur a été retiré de la conférence ("supprimé").

Les éléments fils suivants sont définis pour l'élément <utilisateur> :

 	5.6.1	<texte d'affichage>
Cet élément est utilisé pour afficher le nom d'usage de l'utilisateur dans la conférence.

 	5.6.2	<associated-aors>
Cet élément contient des URI supplémentaires (à "entité") associés à <utilisateur>. Normalement, cette information va être fournie manuellement par un administrateur pour montrer l'association logique entre des entités de signalisation par ailleurs indépendantes. Par exemple, si le "'entité" d'un <utilisateur> contient un URI d'utilisateur d'acheminement mondial (GRUU, Globally Routable User URI) [RF5627] ou tel: [RFC3966], il va être utile de remplir ce champ avec l'adresse d’enregistrement (AOR, Address of Record) de la personne qui utilise ces appareils, chacun représenté comme un <utilisateur> indépendant.

 	5.6.3	<roles>
Cet élément PEUT contenir un ensemble de chaînes lisibles par l'humain décrivant les rôles de l'utilisateur dans la conférence. Noter que cette information est applicable seulement pour la consommation humaine. La présente spécification ne définit pas l'ensemble des rôles possibles dans une conférence ou la sémantique associée à chacun. Il est prévu que de futures spécifications de conférence les définissent avec les extensions de schéma correspondantes, comme approprié.

 	5.6.4	<langages>
Cet élément contient une liste de jetons, séparés par des espaces, contenant chacun un langage compris par l'utilisateur. Cette information peut être apprise automatiquement via la signalisation d'appel ou être réglée manuellement par participant.

 	5.6.5	<point-de-convergence-en-cascade>
Cet élément contient un URI de conférence (différent de l'URI de conférence principal) pour les utilisateurs qui sont connectés à la conférence principale par suite d'un point de convergence en cascade. En accord avec le cadre de conférence SIP [RFC4353], ce paquetage permet seulement la représentation d'un point de convergence en cascade d'homologue à homologue (c'est-à-dire, "plat"). Le graphe de cascade réel ne peut pas être déduit des informations fournies dans le seul paquetage. Des applications évoluées peuvent construire le graphe en s'abonnant à la fois à ce paquetage et au paquetage Dialogue [RFC4235] de chaque point de convergence en cascade et des information corrélatives pertinentes.

 	5.6.6	<point d'extrémité>
En incluant un ou plusieurs éléments <point d'extrémité> sous un élément parent <utilisateur>, le serveur peut fournir le niveau de détails désiré (incluant les informations d'état, de flux de supports, et d'accès) sur les appareils de l'utilisateur et les sessions de signalisation qui prennent part à la conférence.

Dans un système de conférence où l'authentification est effectuée par point d'extrémité (plutôt que par utilisateur) le point de convergence peut ne pas connaître l'association logique de plusieurs points d'extrémité sous un utilisateur commun. Dans ce cas, chaque point d'extrémité va apparaître comme un <utilisateur> séparé avec son ou ses propres sous éléments <point d'extrémité> dans le document de conférence.

Dans un cas différent, le point de convergence peut choisir de cacher aux autres abonnés les informations sur les plusieurs points d'extrémité et sessions de signalisation d'un participant (par exemple, à cause des politiques de confidentialité). Pour ce faire, le point de convergence PEUT agréger les informations de plusieurs sessions de signalisation sous un seul élément <point d'extrémité>. Noter que dans ce cas, les informations détaillées de signalisation d'appel (représentées par le sous élément <call-info>) ne seront pas incluses.

 	5.7	<point d'extrémité>
Le présent paragraphe décrit l'élément <point d'extrémité> plus en détails.

Les attributs suivants sont définis pour l'élément <point d'extrémité> :

entité : le serveur DOIT générer la clé "entité" pour chaque élément <point d'extrémité> inclus sous le parent <utilisateur>, pour que sa valeur soit unique dans le contexte de l'utilisateur. Dans les termes de SIP, ce peut être l'URI de contact, le GRUU, etc.

état : cet attribut indique si l'élément contient toutes les informations du point d'extrémité ("plein") ou seulement les informations qui ont changé depuis le précédent document ("partiel") ou si le point d'extrémité a été retiré de la conférence ("supprimé").

Les éléments fils suivants sont définis pour l'élément <point d'extrémité> :

 	5.7.1	<texte d'affichage>
Cet élément contient le texte d'affichage pour le point d'extrémité.

 	5.7.2	<referred>
Cet élément contient des informations sur l'utilisateur dont l'action a pour résultat que ce point d'extrémité a été amené dans la conférence (par exemple, l'utilisateur SIP identifié par cet URI a envoyé un REFER au point de convergence). Il PEUT contenir les sous éléments suivants :

quand : cet élément de type XML dateTime contient la date et l'heure à laquelle le point d'extrémité a été inscrit à la conférence et DEVRAIT être exprimé en format de temps universel coordonné (UTC, Coordinated Universal Time).  Par exemple, <quand>2005-03-04T20:00:00Z</quand>

raison : cet élément contient la raison pour laquelle le point d'extrémité a été inscrit à la conférence. Inclure les informations dans le format défini par la [RFC3326] est RECOMMANDÉ. Par exemple, <raison>Reason: SIP;text="Ad-hoc Invitation"</raison>.

par : cet élément contient l'URI de l'entité qui a causé l'inscription du point d'extrémité à la conférence. Dans le cas de SIP, il va être rempli à partir de l'en-tête Referred-By défini dans la [RFC3892].

 	5.7.3	<état>
Cet élément contient l'état du point d'extrémité et peut prendre les valeurs suivantes :

connecté : le point d'extrémité est un participant à la conférence. Selon les politiques de supports, il peut envoyer et recevoir des supports de et aux autres participants.

déconnecté : le point d'extrémité n'est pas un participant à la conférence, et aucun dialogue actif n'existe entre le point d'extrémité et le point de convergence.

en-garde : un dialogue de signalisation actif existe entre un point d'extrémité et un point de convergence, mais le point d'extrémité est "en-garde" pour cette conférence, c'est-à-dire, il n'est pas "en écoute" de la conférence et son support n'est pas mixé dans la conférence. Par exemple, le point d'extrémité a demandé à se joindre à la conférence en utilisant SIP, mais sa participation est en instance en attente de l'approbation du modérateur. Entre temps, il écoute la tonalité d'attente ou quelque autre sorte de contenu en rapport.

rendu-muet-par-le-point de convergence : un dialogue actif de signalisation existe entre un point d'extrémité et un point de convergence et le point d'extrémité peut "écouter" la conférence, mais le support du point d'extrémité n'est pas mixé dans la conférence. Noter que parfois un sous ensemble de flux de supports de point d'extrémité peut être rendu muet par le point de convergence (comme une vidéo de mauvaise qualité) tandis que d'autres (comme la voix ou IM) peuvent être toujours actifs. Dans ce cas, il est RECOMMANDÉ que l'élément <état> de connexité "agrégé" de point d'extrémité reflète l'état des supports les plus actifs.

en-instance : le point d'extrémité n'est pas encore dans la session, mais il est prévu qu'il va bientôt s'y joindre.

alerte : une Alerte du réseau téléphonique public commuté (RTPC) ou une sonnerie SIP 180 a été retournée pour l'appel sortant ; le point d'extrémité est alerté.

appel-entrant : le point d'extrémité appelle la conférence, il n'est pas encore dans l'assistance (probablement en cours d'authentification).

appel-sortant : le point de convergence a appelé pour connecter le point d'extrémité à la conférence, mais le point d'extrémité n'est pas encore dans l'assistance (probablement en cours d'authentification).

en-déconnexion : le point de convergence est dans le processus de déconnexion du point d'extrémité (par exemple, dans SIP un message DISCONNECT ou BYE a été envoyé au point d'extrémité).

Noter que les états transitoires définis (par exemple, en-déconnexion, alerte, etc.) peuvent générer un certain trafic. Donc, les mises en œuvre PEUVENT choisir de générer des notifications sur ces états à seulement certains participants ou de ne pas les générer du tout, selon la politique locale.

 	5.7.4	<méthode-de-jonction>
Cet élément contient la méthode par laquelle le point d'extrémité s'est joint à la conférence et peut prendre les valeurs suivantes :

appel-entrant : le point d'extrémité a appelé la conférence (par exemple, dans un INVITE SIP envoyé au point de convergence) qui a résulté en l'établissement réussi du dialogue.

appel-sortant : le point de convergence a mis le point d'extrémité dans la conférence (par exemple, dans SIP, le point de convergence a envoyé un INVITE réussi au point d'extrémité).

possesseur-du-point de convergence : le point d'extrémité est le point de convergence pour cette conférence. Cet état n'est utilisé que quand l'UA d'un participant agit comme point de convergence d'une conférence.

 	5.7.5	<joining-info>
Cet élément contient l'information sur la façon dont le point d'extrémité s'est joint et PEUT contenir les sous éléments suivants :

quand : cet élément du type XML dateTime contient la date et l'heure à laquelle le point d'extrémité a rejoint la conférence et DEVRAIT être exprimé en temps coordonné universel (UTC).

raison : cet élément contient la raison pour laquelle le point d'extrémité s'est joint à la conférence. Inclure les informations dans le format défini par la [RFC3326] est RECOMMANDÉ. Par exemple, <raison>Reason: SIP;text="Ad-hoc Invitation"</raison>

par : cet élément contient l'URI de l'entité qui est cause que le point d'extrémité a rejoint la conférence.

 	5.7.6	<méthode-de-déconnexion->
Cet élément contient la méthode par laquelle le point d'extrémité a quitté la conférence et peut prendre les valeurs suivantes  :

parti : dans SIP, le point d'extrémité a envoyé un BYE, quittant donc la conférence.

prêt-à-partir : dans SIP, le point d'extrémité a reçu un BYE envoyé par le point de convergence, l'éjectant de la conférence. Autrement, le point d'extrémité a essayé d'appeler la conférence mais a été rejeté par le point de convergence à cause de la politique locale.

échec : dans SIP, le serveur a essayé d'amener le point d'extrémité dans la conférence, mais sa tentative de contacter le point d'extrémité spécifié a résulté en une réponse finale de classe non 200. Autrement, le point d'extrémité a essayé d'appeler la conférence sans succès pour des raisons techniques.

occupé : dans SIP, le  serveur a essayé d'amener le point d'extrémité dans la conférence, mais sa tentative de contacter le point d'extrémité spécifié a résulté en une réponse finale 486 "Occupé ici". Autrement, le point d'extrémité a essayé d'appeler la conférence mais le point de convergence a répondu par une réponse 486.

 	5.7.7	<informations-de-déconnexion>
Cet élément contient des informations sur le départ du point d'extrémité de la conférence et PEUT contenir les sous éléments suivants :

quand : cet élément du type XML dateTime contient la date et l'heure à laquelle le point d'extrémité a rejoint la conférence et DEVRAIT être exprimé en temps coordonné universel (UTC).

raison : cet élément contient la raison pour laquelle le point d'extrémité a quitté la conférence. Quand elle est connue et a une signification, inclure les informations telles que portées/rapportées par la signalisation d'appel dans le format défini par la [RFC3326] est RECOMMANDÉ. Par exemple, <raison>Reason: SIP;cause=415;text="Type de support non pris en charge"</raison>

par : cet élément contient l'URI de l'entité qui a causé le départ du point d'extrémité de la conférence.

 	5.7.8	<support>
Cet élément contient des informations sur un seul flux de supports et est inclus pour chaque flux de supports établi entre le point de convergence et le <point d'extrémité>. La définition de flux de supports se trouve dans SDP [RFC4566].

Noter que si le sous élément <info-d'appel> du point d'extrémité n'est pas inclus dans le document par le serveur, il est possible que les flux de supports mentionnés sous le <point d'extrémité> commun aient été établis par des sessions de signalisation séparées.

 	5.7.9	<info-d'appel>
L'élément <info-d'appel> fournit des informations détaillées de signalisation d'appel pour un appel entre le participant et le point de convergence. Les politiques de confidentialité DOIVENT être consultées avant de révéler ces informations aux autres participants.

Le sous élément <sip> contient l'identifiant de dialogue SIP du dialogue du point d'extrémité avec le point de convergence.  L'élément inclut les sous éléments <texte d'affichage>, <id-d'appel>, <to-tag>, <from-tag>.

À l'avenir, l'élément <info-d'appel> pourrait être étendu pour inclure des informations de protocole de signalisation d'appel pour d'autres protocoles que SIP.

 	5.8.	<supports>
Le présent paragraphe décrit l'élément <supports> plus en détails.

Un seul attribut "id" est défini pour cet élément. C'est l'identifiant de flux de supports qui est généré par le serveur de telle façon que sa valeur soit unique dans le contexte du point d'extrémité. Cet attribut est la clé pour se référer à un flux de supports particulier dans le document de conférence.

Les éléments fils suivants sont définis pour <supports> :

 	5.8.1	<texte d'affichage>
Cet élément contient le texte d'affichage pour le flux de supports. La valeur de cet élément correspond à l'attribut SDP de description de support ("i") défini dans SDP [RFC4566].

 	5.8.2	<type>
Cet élément contient le type de supports pour le flux de supports. La valeur de cet élément DOIT être une des valeurs enregistrées pour "supports" de SDP [RFC4566] et ses révisions ultérieures.

 	5.8.3	<étiquette>
L'élément <étiquette> porte un identifiant univoque de ce flux parmi tous les flux de la conférence et est alloué par le point de convergence. La valeur de cet élément va normalement correspondre à l'attribut de support SDP "étiquette" défini dans la [RFC4574] et elle est échangée entre un participant et un point de convergence sur la connexion de signalisation établie entre eux.

Si les informations <support-disponible> (décrites au paragraphe 5.3.4) sont incluses dans le document de conférence, la valeur de cet élément DOIT être égale à la valeur de"étiquette" de <entrée> du flux de supports correspondant dans le conteneur <support-disponible>.

 	5.8.4	<src-id>
L'élément <src-id>, si applicable, porte les informations sur la source réelle du support. Par exemple, pour les flux de supports du protocole de transport en temps réel (RTP) / protocole de contrôle de RTP (RTCP) [RFC3550], la valeur DOIT contenir la valeur d'identifiant de source de synchronisation (SSRC) générée par le point d'extrémité pour le flux qu'il envoie.

Quand un mixeur RTP génère une liste d'identifiants de source contributive (CSRC) conformément à RTP/RTCP [RFC3550], il insère une liste des identifiants de SSRC des sources qui ont contribué à la génération d'un certain paquet dans l'en-tête RTP de ce paquet. Une citation de la [RFC3550] l'explique comme suit : "Un exemple d'application est la conférence audio où un mixeur indique tous les locuteurs dont les discours ont été combinés pour produire le paquet sortant, permettant au receveur d'indiquer le locuteur actuel, même si les paquets audio contiennent le même identifiant de SSRC (celui du mixeur)."

Si un mixeur RTP conforme à ce qui est dit ci-dessus est utilisé, les participants peuvent effectuer une transposition de SSRC à l'utilisateur et identifier "un orateur actuel".

 	5.8.5	<état>
L'élément <état> indique l'état dans les deux directions du flux de supports et a les valeurs "envoi-réception", "envoi-seul", "réception-seule", ou "inactive" comme défini dans SDP [RFC4566] et ses révisions ultérieures. Noter que la valeur spécifie la direction du point de vue du participant. Par exemple, le flux d'un participant rendu muet aura la valeur de "réception-seule".

 	5.9	Annexes
Si un participant à la conférence principale se joint à une annexe, un nouvel élément <utilisateur> représentant l'utilisateur est créé soit au titre d'une sous conférence séparée référencée à partir de l'élément <annexes-par-référence> soit sous un des éléments <annexes-par-valeur> décrits ci dessous.

Noter que <utilisateur> dans le rôle principal n'est pas supprimé, mais ses états de supports peuvent être mis à jour pour refléter l'effet causé par sa participation à l'annexe. L'affichage de ces informations peut varier parmi les abonnés aux mêmes informations de conférence, selon les politiques locales et le rôle de l'abonné dans l'annexe et dans la conférence principale.

 	5.9.1	<annexes-par-référence>
Cet élément contient un ensemble d'éléments <entrée> fils, contenant chacun un URI de conférence annexe. Le receveur de l'information peut alors s'abonner aux informations annexes indépendamment de l'abonnement au paquetage de conférence principale.

 	5.9.2	<annexes-par-valeur>
Cet élément contient un ensemble d'éléments <entrée> fils, contenant chacun des informations sur une seule annexe. En utilisant ce type d'élément de conférence, le serveur peut inclure une description complète ou partielle de chaque annexe (comme une sous conférence) dans le corps du document de conférence principale.

 	6.	Schéma XML

<?xml version="1.0" codage="UTF-8" ?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:conference-info"
xmlns:tns="urn:ietf:params:xml:ns:conference-info"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:conference-info"
elementFormDefault="qualifié"
attributeFormDefault="non qualifié">
<!--
  Ceci importe la définition xml:langage définition
-->
   <xs:import espace de noms="http://www.w3.org/XML/1998/espace de noms"
    schemaLocation="http://www.w3.org/2001/03/xml.xsd"/>
<!--
ELEMENT CONFERENCE 
-->
   <xs:nom d'élément="conference-info" type="conference-type"/>
   <!--
  TYPE CONFERENCE 
   -->
   <xs:complexType name="conference-type">
    <xs:sequence>
     <xs:nom d'élément="conference-description"
      type="conference-description-type" minOccurs="0"/>
     <xs:nom d'élément="host-info"
      type="host-type" minOccurs="0"/>
     <xs:nom d'élément="conférence-état"
      type="conférence-état-type" minOccurs="0"/>
     <xs:nom d'élément="utilisateurs"
      type="utilisateurs-type" minOccurs="0"/>
     <xs:nom d'élément="annexes-par-référence"
      type="uris-type" minOccurs="0"/>
     <xs:nom d'élément="annexes-par-valeur"
      type="annexes-par-valeur-type" minOccurs="0"/>
     <xs:any espace de noms="##autre" processContents="lax"
      minOccurs="0" maxOccurs="non limité"/>
    </xs:sequence>
    <xs:nom d'attribut="entité"
     type="xs:anyURI" utilise="exigé"/>
    <xs:nom d'attribut="état"
     type="état-type" utilise="facultatif" defaut="plein"/>
    <xs:nom d'attribut="version"
     type="xs:unsignedInt" utilise="facultatif"/>
    <xs:anyAttribute espace de noms="##autre" processContents="lax"/>
   </xs:complexType>
   <!--
   TYPE ÉTAT 
   -->
   <xs:simpleType name="état-type">
    <xs:restriction base="xs:chaîne">
     <xs:enumeration valeur="plein"/>
     <xs:enumeration valeur="partiel"/>
     <xs:enumeration valeur="supprimé"/>
    </xs:restriction>
   </xs:simpleType>
   <!--
   TYPE DESCRIPTION DE CONFERENCE
   -->
   <xs:complexType name="conference-description-type">
    <xs:sequence>
     <xs:nom d'élément="texte d'affichage"
      type="xs:chaîne" minOccurs="0"/>
     <xs:nom d'élément="sujet"
      type="xs:chaîne" minOccurs="0"/>
     <xs:nom d'élément="texte-libre"
      type="xs:chaîne" minOccurs="0"/>
     <xs:nom d'élément="mots-clés"
      type="mots-clés-type" minOccurs="0"/>
     <xs:nom d'élément="conf-uris"
      type="uris-type" minOccurs="0"/>
     <xs:nom d'élément="service-uris"
      type="uris-type" minOccurs="0"/>
     <xs:nom d'élément="compte-maximum-utilisateur"
      type="xs:unsignedInt" minOccurs="0"/>
     <xs:nom d'élément="support-disponible"
      type="conference-support-type" minOccurs="0"/>
     <xs:any espace de noms="##autre" processContents="lax"
      minOccurs="0" maxOccurs="non limité"/>
    </xs:sequence>
    <xs:anyAttribute espace de noms="##autre" processContents="lax"/>
   </xs:complexType>
   <!--
   TYPE HOTE
   -->
   <xs:complexType name="host-type">
    <xs:sequence>
     <xs:nom d'élément="texte d'affichage" type="xs:chaîne"
      minOccurs="0"/>
     <xs:nom d'élément="web-page" type="xs:anyURI"
      minOccurs="0"/>
     <xs:nom d'élément="uris" type="uris-type"
      minOccurs="0"/>
     <xs:any espace de noms="##autre" processContents="lax"
      minOccurs="0" maxOccurs="non limité"/>
    </xs:sequence>
    <xs:anyAttribute espace de noms="##autre" processContents="lax"/>
   </xs:complexType>
   <!--
   TYPE ÉTAT DE CONFERENCE
   -->
   <xs:complexType name="conférence-état-type">
    <xs:sequence>
     <xs:nom d'élément="compte-d'utilisateur" type="xs:unsignedInt"
      minOccurs="0"/>
     <xs:nom d'élément="active" type="xs:booléen"
      minOccurs="0"/>
     <xs:nom d'élément="locked" type="xs:booléen"
      minOccurs="0"/>
     <xs:any espace de noms="##autre" processContents="lax"
      minOccurs="0" maxOccurs="non limité"/>
    </xs:sequence>
    <xs:anyAttribute espace de noms="##autre" processContents="lax"/>
   </xs:complexType>
   <!--
   TYPE DE SUPPORTS DE CONFERENCE
   -->
   <xs:complexType name="type-supports-conférence">
    <xs:sequence>
     <xs:nom d'élément="entrée" type="type-supports-conférence"
      maxOccurs="non limité"/>
    </xs:sequence>
    <xs:anyAttribute espace de noms="##autre" processContents="lax"/>
   </xs:complexType>
   <!--
   TYPE SUPPORT DE CONFERENCE
   -->
   <xs:complexType name="conférence-support-type">
    <xs:sequence>
     <xs:nom d'élément="texte d'affichage" type="xs:chaîne"
      minOccurs="0"/>
     <xs:nom d'élément="type" type="xs:chaîne"/>
     <xs:nom d'élément="état" type="support-état-type"
      minOccurs="0"/>
     <xs:any espace de noms="##autre" processContents="lax"
      minOccurs="0" maxOccurs="non limité"/>
    </xs:sequence>
    <xs:nom d'attribut="étiquette" type="xs:chaîne"
     utilise="exigé"/>
    <xs:anyAttribute espace de noms="##autre" processContents="lax"/>
   </xs:complexType>
   <!--
   TYPE URIs 
   -->
   <xs:complexType name="uris-type">
    <xs:sequence>
     <xs:nom d'élément="entrée" type="uri-type"
      maxOccurs="non limité"/>
    </xs:sequence>
    <xs:nom d'attribut="état" type="état-type"
     utilise="facultatif" defaut="plein"/>
    <xs:anyAttribute espace de noms="##autre" processContents="lax"/>
   </xs:complexType>
   <!--
   TYPE URI 
   -->
   <xs:complexType name="uri-type">
    <xs:sequence>
     <xs:nom d'élément="uri" type="xs:anyURI"/>
     <xs:nom d'élément="texte d'affichage" type="xs:chaîne"
      minOccurs="0"/>
     <xs:nom d'élément="objet" type="xs:chaîne"
      minOccurs="0"/>
     <xs:nom d'élément="modifié" type="execution-type"
      minOccurs="0"/>
     <xs:any espace de noms="##autre" processContents="lax"
      minOccurs="0" maxOccurs="non limité"/>
    </xs:sequence>
    <xs:anyAttribute espace de noms="##autre" processContents="lax"/>
   </xs:complexType>
    <!--
   TYPE MOTS-CLÉS
   -->
   <xs:simpleType name="mots-clés-type">
    <xs:list itemType="xs:chaîne"/>
   </xs:simpleType>
   <!--
   TYPE UTILISATEURS
   -->
   <xs:complexType name="utilisateurs-type">
    <xs:sequence>
     <xs:nom d'élément="utilisateur" type="utilisateur-type"
      minOccurs="0" maxOccurs="non limité"/>
     <xs:any espace de noms="##autre" processContents="lax"
      minOccurs="0" maxOccurs="non limité"/>
    </xs:sequence>
    <xs:nom d'attribut="état" type="état-type"
     utilise="facultatif" defaut="plein"/>
    <xs:anyAttribute espace de noms="##autre" processContents="lax"/>
   </xs:complexType>
   <!--
   TYPE UTILISATEUR
   -->
   <xs:complexType name="utilisateur-type">
    <xs:sequence>
     <xs:nom d'élément="texte d'affichage" type="xs:chaîne"
      minOccurs="0"/>
     <xs:nom d'élément="associated-aors" type="uris-type"
      minOccurs="0"/>
     <xs:nom d'élément="roles" type="utilisateur-roles-type"
      minOccurs="0"/>
     <xs:nom d'élément="langages" type="utilisateur-langages-type"
      minOccurs="0"/>
     <xs:nom d'élément="point-de-convergence-en-cascade" type="xs:anyURI"
      minOccurs="0"/>
     <xs:nom d'élément="point-d'extrémité" type="point d'extrémité-type"
      minOccurs="0" maxOccurs="non limité"/>
     <xs:any espace de noms="##autre" processContents="lax"
      minOccurs="0" maxOccurs="non limité"/>
    </xs:sequence>
    <xs:nom d'attribut="entité" type="xs:anyURI"/>
    <xs:nom d'attribut="état" type="état-type"
     utilise="facultatif" defaut="plein"/>
    <xs:anyAttribute espace de noms="##autre" processContents="lax"/>
   </xs:complexType>
   <!--
   TYPE ROLES D'UTILISATEUR
   -->
   <xs:complexType name="utilisateur-roles-type">
    <xs:sequence>
     <xs:nom d'élément="entrée" type="xs:chaîne"
      maxOccurs="non limité"/>
    </xs:sequence>
    <xs:anyAttribute espace de noms="##autre" processContents="lax"/>
   </xs:complexType>
   <!--
   TYPE LANGAGES D'UTILISATEUR
   -->
   <xs:simpleType name="utilisateur-langages-type">
    <xs:list itemType="xs:langage"/>
   </xs:simpleType>
   <!--
   TYPE POINT D'EXTRÉMITÉ
   -->
   <xs:complexType name="point d'extrémité-type">
    <xs:sequence>
     <xs:nom d'élément="texte-d'affichage" type="xs:chaîne"
      minOccurs="0"/>
     <xs:nom d'élément="referred" type="execution-type"
      minOccurs="0"/>
     <xs:nom d'élément="état" type="point-d'extrémité-état-type"
      minOccurs="0"/>
     <xs:nom d'élément="joining-method" type="joining-type"
      minOccurs="0"/>
     <xs:nom d'élément="joining-info"
      type="execution-type"
      minOccurs="0"/>
     <xs:nom d'élément="méthode-de-déconnexion"
      type="type-de-déconnexion"
      minOccurs="0"/>
     <xs:nom d'élément="info-de-déconnexion"
      type="execution-type"
      minOccurs="0"/>
     <xs:nom d'élément="support" type="type-support"
      minOccurs="0" maxOccurs="non limité"/>
     <xs:nom d'élément="infod'appel" type="type-appel"
      minOccurs="0"/>
     <xs:any espace de noms="##autre" processContents="lax"
      minOccurs="0" maxOccurs="non limité"/>
    </xs:sequence>
    <xs:nom d'attribut="entité" type="xs:chaîne"/>
    <xs:nom d'attribut="état" type="état-type"
     utilise="facultatif" defaut="plein"/>
    <xs:anyAttribute espace de noms="##autre" processContents="lax"/>
   </xs:complexType>
   <!--
   TYPE ÉTAT DE POINT D'EXTRÉMITÉ
   -->
   <xs:simpleType name="point-d'extrémité-état-type">
    <xs:restriction base="xs:chaîne">
     <xs:enumeration valeur="en-instance"/>
     <xs:enumeration valeur="appel-sortant"/>
     <xs:enumeration valeur="appel-entrant"/>
     <xs:enumeration valeur="alerte"/>
     <xs:enumeration valeur="en-garde"/>
     <xs:enumeration valeur="connecté"/>
     <xs:enumeration valeur="rendu-muet-via-point de convergence"/>
     <xs:enumeration valeur="en-cours-de-déconnexion"/>
     <xs:enumeration valeur="déconnecté"/>
    </xs:restriction>
   </xs:simpleType>
   <!--
   TYPE JONCTION
   -->
   <xs:simpleType name="joining-type">
    <xs:restriction base="xs:chaîne">
     <xs:enumeration valeur="dialed-in"/>
     <xs:enumeration valeur="dialed-out"/>
     <xs:enumeration valeur="possesseur-point de convergence"/>
    </xs:restriction>
   </xs:simpleType>
   <!--
   TYPE DECONNEXION 
   -->
   <xs:simpleType name="type-de-déconnexion">
    <xs:restriction base="xs:chaîne">
     <xs:enumeration valeur="parti"/>
     <xs:enumeration valeur="prêt-à-partir"/>
     <xs:enumeration valeur="échec"/>
     <xs:enumeration valeur="occupé"/>
    </xs:restriction>
   </xs:simpleType>
   <!--
   TYPE EXECUTION
   -->
   <xs:complexType name="execution-type">
    <xs:sequence>
     <xs:nom d'élément="quand" type="xs:dateTime"
      minOccurs="0"/>
     <xs:nom d'élément="raison" type="xs:chaîne"
      minOccurs="0"/>
     <xs:nom d'élément="par" type="xs:anyURI"
      minOccurs="0"/>
    </xs:sequence>
    <xs:anyAttribute espace de noms="##autre" processContents="lax"/>
   </xs:complexType>
   <!--
   TYPE D'APPEL
   -->
   <xs:complexType name="call-type">
    <xs:choice>
     <xs:nom d'élément="sip" type="sip-dialog-id-type"/>
     <xs:any espace de noms="##autre" processContents="lax"
      minOccurs="0" maxOccurs="non limité"/>
    </xs:choice>
    <xs:anyAttribute espace de noms="##autre" processContents="lax"/>
   </xs:complexType>
   <!--
   TYPE IDENTIFIANT DE DIALOGUE SIP
   -->
   <xs:complexType name="sip-dialog-id-type">
    <xs:sequence>
     <xs:nom d'élément="texte d'affichage" type="xs:chaîne"
      minOccurs="0"/>
     <xs:nom d'élément="call-id" type="xs:chaîne"/>
     <xs:nom d'élément="from-tag" type="xs:chaîne"/>
     <xs:nom d'élément="to-tag" type="xs:chaîne"/>
     <xs:any espace de noms="##autre" processContents="lax"
      minOccurs="0" maxOccurs="non limité"/>
    </xs:sequence>
    <xs:anyAttribute espace de noms="##autre" processContents="lax"/>
   </xs:complexType>
   <!--
   TYPE DE SUPPORT
   -->
   <xs:complexType name="support-type">
    <xs:sequence>
     <xs:nom d'élément="texte d'affichage" type="xs:chaîne"
      minOccurs="0"/>
     <xs:nom d'élément="type" type="xs:chaîne"
      minOccurs="0"/>
     <xs:nom d'élément="étiquette" type="xs:chaîne"
      minOccurs="0"/>
     <xs:nom d'élément="src-id" type="xs:chaîne"
      minOccurs="0"/>
     <xs:nom d'élément="état" type="media-état-type"
      minOccurs="0"/>
     <xs:any espace de noms="##autre" processContents="lax"
      minOccurs="0" maxOccurs="non limité"/>
    </xs:sequence>
    <xs:nom d'attribut="id" type="xs:chaîne"
     utilise="exigé"/>
    <xs:anyAttribute espace de noms="##autre" processContents="lax"/>
   </xs:complexType>
   <!--
   TYPE ÉTAT DU SUPPORT
   -->
   <xs:simpleType name="support-état-type">
    <xs:restriction base="xs:chaîne">
     <xs:enumeration valeur="réception-seule"/>
     <xs:enumeration valeur="envoi-seul"/>
     <xs:enumeration valeur="envoi-réception"/>
     <xs:enumeration valeur="inactive"/>
    </xs:restriction>
   </xs:simpleType>
   <!--
   TYPE ANNEXE PAR VALEUR
   -->
    <xs:complexType name="annexes-par-valeur-type">
     <xs:sequence>
      <xs:nom d'élément="entrée" type="conférence-type"
       minOccurs="0" maxOccurs="non limité"/>
     </xs:sequence>
     <xs:nom d'attribut="état" type="état-type"
      utilise="facultatif" defaut="plein"/>
     <xs:anyAttribute espace de noms="##autre" processContents="lax"/>
    </xs:complexType>
   </xs:schema>

 	7.	Exemples
 	7.1	Exemple de base
Voici un exemple de document complet d'informations de conférence :

<?xml version="1.0" codage="UTF-8"?>
<conférence-info
 xmlns="urn:ietf:params:xml:ns:conférence-info"
 entité="sips:conf233@exemple.com"
 état="plein" version="1">
<!--
INFORMATIONS DE CONFÉRENCE
-->
 <conférence-description>
  <sujet>Agenda : objectifs mensuels</sujet>
   <service-uris>
    <entrée>
     <uri>http://sharepoint/salesgroup/</uri>
     <objet>web-page</objet>
    </entrée>
   </service-uris>
  </conférence-description>
<!--
ÉTAT DE CONFÉRENCE
-->
 <conférence-état>
  <compte-d'utilisateur>33</compte-d'utilisateur>
 </conférence-état>
<!--
UTILISATEURS
-->
 <utilisateurs>
  <entité utilisatrice="sip:bob@exemple.com" état="plein">
   <texte d'affichage>Bob Hoskins</texte d'affichage>
<!--
POINTS D'EXTRÉMITÉ
-->
   <entité de point d'extrémité="sip:bob@pc33.exemple.com">
    <texte d'affichage>Tablette de Bob</texte d'affichage>
    <état>déconnecté</état>
    <méthode-de-déconnexion>parti</méthode-de-déconnexion>
    <informations-de-déconnexion>
     <quand>2005-03-04T20:00:00Z</quand>
     <raison>mauvaise qualité vocale</raison>
     <par>sip:mike@exemple.com</par>
    </informations-de-déconnexion>
<!--
SUPPORTS
-->
    <identifiant de support="1">
     <texte d'affichage>principalement audio</texte d'affichage>
     <type>audio</type>
     <étiquette>34567</étiquette>
     <src-id>432424</src-id>
     <état>envoi-reception</état>
    </support>
   </point d'extrémité>
  </utilisateur>
<!--
UTILISATEUR
-->
  <entité utilisatrice="sip:alice@exemple.com" état="plein">
   <texte d'affichage>Alice</texte d'affichage>
<!--
POINTS D'EXTRÉMITÉ
-->
   <entité de point d'extrémité="sip:4kfk4j392jsu@exemple.com;grid=433kj4j3u">
    <état>connecté</état>
    <joining-method>appel sortant</joining-method>
    <joining-info>
     <quand>2005-03-04T20:00:00Z</quand>
     <par>sip:mike@exemple.com</par>
    </joining-info>
<!--
SUPPORTS
-->
    <identifiant de support="1">
     <texte d'affichage>principalement audio</texte d'affichage>
     <type>audio</type>
     <étiquette>34567</étiquette>
     <src-id>534232</src-id>
     <état>envoi-réception</état>
    </support>
   </point d'extrémité>
  </utilisateur>
 </utilisateurs>
</conférence-info>

 	7.2	Exemple enrichi
Voici un exemple de document partiel d'informations de conférence. Dans cet exemple, il y a 32 participants à une conférence vocale. L'usager Bob a été éjecté de la conférence par Mike à cause de la mauvaise qualité vocale. Noter qu'il y a trois annexes dans la conférence ; deux sont référencées juste par leurs URI d'annexe, et les informations sur la troisième annexe sont incluses dans cette notification. Noter aussi qu'alors que cette conférence offre à la fois des capacités audio et vidéo, seul l'audio est actuellement utilisé.

<?xml version="1.0" codage="UTF-8"?>
<conférence-info
 xmlns="urn:ietf:params:xml:ns:conférence-info"
 entity="sips:conf233@exemple.com"
 état="partiel" version="5">
<!--
  CONFERENCE INFO
-->
 <conférence-description>
  <texte d'affichage>Réunion hebdomadiare des ventes</texte d'affichage>
  <sujet>Agenda : objectifs mensuels</sujet>
  <texte-libre>On commencera strictement à l'heure</texte-libre>
  <mots-clés>ventes réunion mensuelle</mots-clés>
  <conf-uris>
   <entrée>
    <uri>tel:+18005671234</uri>
    <texte d'affichage>TTI Bridge</texte d'affichage>
    <objet>participation</objet>
   </entrée>
   <entrée>
    <uri>h323:conf545@h323.exemple.com</uri>
    <objet>participation</objet>
   </entrée>
   <entrée>
    <uri>http://real.streaming.com/54634/live.ram</uri>
    <objet>streaming</objet>
   </entrée>
  </conf-uris>
  <service-uris>
   <entrée>
    <uri>http://sharepoint/salesgroup/</uri>
    <objet>web-page</objet>
   </entrée>
   <entrée>
    <uri>http://quicktime.com/54634/recording.mov</uri>
    <texte d'affichage>Quicktime</texte d'affichage>
    <objet>recording</objet>
   </entrée>
  </service-uris>
  <compte-maximum-utilisateur>100</compte-maximum-utilisateur>
  <support-disponible>
   <étiquette entrée="34567">
    <texte d'affichage>principalement audio</texte d'affichage>
    <type>audio</type>
    <état>envoi-réception</état>
   </entrée>
   <étiquette entrée="34569">
    <texte d'affichage> principalement vidéo</texte d'affichage>
    <type>video</type>
    <état>inactive</état>
   </entrée>
  </support-disponible>
 </conférence-description>
<!--
  INFO D'HOTE
-->
 <host-info>
  <texte d'affichage>Sales Host</texte d'affichage>
  <web-page>http://sharepoint/salesgroup/hosts/</web-page>
  <uris>
   <entrée>
    <uri>sip:sales@exemple.com</uri>
   </entrée>
  </uris>
 </host-info>
<!--
ÉTAT DE CONFÉRENCE
-->
 <conférence-état>
  <compte-utilisateurs>32</compte-utilisateurs>
  <active>vrai</active>
  <locked>faux</locked>
 </conférence-état>
<!--
UTILISATEURS
-->
 <utilisateurs>
  <entité utilisatrice="sip:bob@exemple.com">
   <texte d'affichage>Bob Hoskins</texte d'affichage>
   <associated-aors>    <entrée>
        <uri>mailto:boxample.com</uri>
        <texte d'affichage>ail</texte d'affichage>
       </entrée>    </associated-aors>
      <roles>
   <entrée>participant</entrée>
   </roles>
   <langages>fr</langages>
<!--
POINTS D'EXTRÉMITÉ
-->
   <entité de point d'extrémité="sip:bob@pc33.exemple.com">
    <texte d'affichage>Tablette de Bob</texte d'affichage>
    <referred>
     <quand>2005-03-04T20:00:00Z</quand>
     <raison>expert exigé</raison>
     <par>sip:mike@exemple.com</par>
    </referred>
    <état>se déconnecte</état>
    <joining-method>apel sortant</joining-method>
    <joining-info>
     <quand>2005-03-04T20:00:00Z</quand>
     <raison>invitation</raison>
     <by>sip:mike@exemple.com</by>
    </joining-info>
    <méthode-déconnexion>prêt-à-partir</méthode-déconnexion>
    <info-de-déconnexion>
     <quand>2005-03-04T20:00:00Z</quand>
     <raison>mauvaise qualité vocale</raison>
     <by>sip:mike@exemple.com</by>
    </info-de-déconnexion>
<!--
SUPPORTS
-->
    <identifiant de support="1">
     <texte d'affichage>principalement audio</texte d'affichage>
     <type>audio</type>
     <étiquette>34567</étiquette>
     <src-id>432424</src-id>
     <état>envoi-reception</état>
    </support>
<!--
  INFO D'APPEL
-->
    <info-d'appel>
     <sip>
      <texte d'affichage>plein info</texte d'affichage>
        <call-id>hsjh8980vhsb78</call-id>
        <from-tag>vav738dvbs</from-tag>
        <to-tag>8954jgjg8432</to-tag>
     </sip>
    </info-d'appel>
   </point d'extrémité>
  </utilisateur>
 </utilisateurs>
<!--
ANNEXES PAR REFERENCE
-->
 <annexes-par-référence état="partiel">
   <entrée>
   <uri>sips:conf233@exemple.com;grid=45</uri>
   <texte d'affichage>annexe avec Carol</texte d'affichage>
  </entrée>
  <entrée>
   <uri>sips:conf233@exemple.com;grid=21</uri>
   <texte d'affichage>privé avec Peter</texte d'affichage>
  </entrée>
 </annexes-par-référence>
<!--
ANNEXES PAR VALEUR
-->
 <annexes-par-valeur état="partiel">
  <entité d'entrée="sips:conf233@exemple.com;grid=77"
    état="partiel">
   <utilisateurs>
    <entité utilisatrice="sip:bob@exemple.com"/>
    <entité utilisatrice="sip:mark@exemple.com"/>
    <entité utilisatrice="sip:dan@exemple.com"/>
   </utilisateurs>
  </entrée>
 </annexes-par-valeur>
</conférence-info>

 	8.	Considérations sur la sécurité

Les abonnements aux informations d'état de conférence peuvent révéler des informations très sensibles. Pour cette raison, il est RECOMMANDÉ qu'un point de convergence utilise de forts moyens pour l'authentification et la protection des informations de conférence et qu'il applique des règles d'autorisation sans faille quand il utilise le mécanisme de notification de conférence défini dans ce document. Les paragraphe qui suivent discutent plus en détails de chacun de ces aspects.

 	8.1	Sécurité de la connexion
Il est RECOMMANDÉ qu'un point de convergence authentifie un abonné de paquetage de conférence en utilisant les mécanismes normaux d'authentification de SIP, comme le résumé défini à la Section 22 de la [RFC3261].

Le mécanisme utilisé pou convoyer les informations de conférence DOIT assurer l'intégrité et DEVRAIT assurer la confidentialité des informations. Pour ce faire, un mécanisme de chiffrement SIP de bout en bout, comme S/MIME décrit au paragraphe 26.2.4 de la [RFC3261], DEVRAIT être utilisé.

Si un fort moyen de sécurité de bout en bout (comme ci-dessus) n'est pas disponible, il est RECOMMANDÉ qu'un point de convergence utilise les mécanismes de chiffrement et d'authentification mutuelle bond par bond de la sécurité de la couche Transport (TLS) décrits aux paragraphes 26.2.2 "Schémas d'URI SIPS" et 26.3.2.2 "Demandes inter domaines" de la [RFC3261].

 	8.2	Considérations d'autorisation
D'une façon générale, les applications de conférence sont très concernées par les décisions d'autorisation. Les mécanismes pour établir et appliquer de telles règles d'autorisation sont un concept central du cadre de conférence de SIP [RFC4353].  Parce que la plupart des informations sur une conférence peuvent être présentées en utilisant le paquetage de conférence, beaucoup des règles d'autorisation s'appliquent directement à la présente spécification. Par suite, un serveur de notifications DOIT être capable de générer des informations de conférence distinctes vues des différents abonnés, selon le rôle d'un abonné dans une conférence, ses droits d'accès personnels, etc. - tout cela sous réserve des politiques et règles d'autorisation locales.

Comme un point de convergence fournit des informations d'identité des participants en utilisant ce paquetage d'événement, la confidentialité du participant doit être prise en compte. Un point de convergence DOIT prendre en charge les demandes des participants en ce qui concerne la confidentialité. Celle-ci peut être indiquée par la politique de conférence - pour chaque participant ou des participants choisis. Elle peut aussi être indiquée dans la signalisation de session. Dans SIP, ce peut être fait en utilisant le champ d'en-tête Privacy décrit dans la [RFC3323]. Pour un participant qui demande la confidentialité, aucune information d'identité ne DEVRAIT être révélée par le point de convergence dans un URI inclus (par exemple, Address of Record, Contact, ou GRUU). Pour ces cas, la méthode de génération d'URI anonymes mentionnée au paragraphe 5.6 de ce document DOIT être suivie.

 	9.	Considérations relatives à l'IANA

Le présent document enregistre un paquetage d'événement SIP, un nouveau type MIME, "application/conférence-info+xml", un nouvel espace de noms XML, et un nouveau schéma XML, et crée un sous registre "URI purposes" sous le registre existant : http://www.iana.org/assignments/sip-parameters.

 	9.1	Enregistrement du paquetage d'événement de conférence
La présente spécification enregistre un paquetage d'événement, sur la base des procédures d'enregistrement définies dans la [RFC3265]. Les informations requises pour un tel enregistrement sont :
Nom de paquetage : conference
Paquetage ou gabarit de paquetage : c'est un paquetage.
Document publié : RFC 4575
Personne à contacter : groupe de travail SIPPING de l'IETF à <sipping@ietf.org>, comme désigné par l'IESG à <iesg@ietf.org>

 	9.2	Enregistrement de application/conference-info+xml MIME
Nom de type de supports MIME : application
Nom de sous type MIME : conference-info+xml
Paramètres obligatoires : aucun.
Paramètres facultatifs : les mêmes que pour le paramètre de jeu de caractères de application/xml comme spécifié dans la [RFC3023].
Considérations de codage : les mêmes que les considérations de codage de application/xml, comme spécifié dans la [RFC3023].
Considérations de sécurité  : voir la Section 10 de la [RFC3023] et la Section 8 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 supports : le présent type de document a été utilisé pour prendre en charge les applications de conférence SIP.
Informations supplémentaires :
Numéro magique : aucun.
Extension de fichier : .xml
Code de type de fichiers Macintosh :  "TEXT"
Adresse personnelle et de messagerie pour informations complémentaires : groupe de travail SIPPING de l'IETF à <sipping@ietf.org>, comme désigné par l'IESG à <iesg@ietf.org>
Usage prévu : COMMUN
Auteur/contrôleur des changements : groupe de travail SIPPING de l'IETF à <sipping@ietf.org>, comme désigné par l'IESG à <iesg@ietf.org>

 	9.3	Enregistrement de sous espace de noms d'URN pour urn:ietf:params:xml:ns:conférence-info
Le présent paragraphe enregistre un nouvel espace de noms XML, selon les lignes directrices de la [RFC3688].
URI : l'URI pour cet espace de noms est urn:ietf:params:xml:ns:conference-info
Contact de l'enregistrant : groupe de travail SIPPING de l'IETF à <sipping@ietf.org>, comme désigné par l'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">
<tête>
  <meta http-equiv="content-type"
     content="text/html;charset=iso-8859-1"/>
  <title>Conference Information Namespace</title>
</tête>
<corps>
  <h1>Espace de noms pour informations de conférence</h1>
  <h2>urn:ietf:params:xml:ns:conference-info</h2>
  <p>Voir <a href="http://www.rfc-editor.org/rfc/rfc4575.txt">
     RFC4575</a>.</p>
</corps>
</html>
FIN

 	9.4	Enregistrement de schéma XML
La présente spécification enregistre un schéma, selon les lignes directrices de la [RFC3688].

URI : prière de l'allouer
Contact de l'enregistrant : groupe de travail SIPPING de l'IETFà < sipping@ietf.org >, comme désigné par l'IESG à <iesg@ietf.org>
XML : le XML est le seul contenu de la Section 6.

 	9.5	Établissement du sous registre URI Purposes
L'IANA a créé un nouveau sous registre, "URI purposes" (objet de l'URI), sous le registre déjà existant à :
 http://www.iana.org/assignments/sip-parameters 

L'objet d'un URI est un élément XML, codé dans le paquetage d'événement de conférence de la RFC 4575. La valeur de l'élément <objet> indique l'usage prévu de l'URI dans le contexte du paquetage d'événement de conférence et est défini aux paragraphes 5.3.1 et 5.3.2 de cette spécification.

Ce sous registre est défini comme un tableau qui contient les trois colonnes suivantes :
Valeur : le jeton à enregistrer
Description : un texte descriptif qui définit l'usage prévu de l'URI
Document : une référence au document qui définit l'enregistrement

L'IANA a créé le tableau avec le contenu initial défini ci-dessous :

Valeur	Description	Document	
participation	L'URI peut être utilisé pour se joindre à la conférence	[RFC 4575]	
flux direct	L'URI peut être utilisé pour accéder aux données de la conférence	[RFC 4575]	
événement	L'URI peut être utilisé pour s'abonner au paquetage d'événement de conférence	[RFC 4575]	
enregistrement	L'URI peut être utilisé pour accéder aux données enregistrées de la conférence	[RFC 4575]	
page-web	L'URI peut être utilisé pour accéder à la page de la Toile qui contient des informations supplémentaires de la conférence	[RFC 4575]	

De nouvelles valeurs de "URI purposes" sont enregistrées par l'IANA et sont de "spécification exigée" selon la définition de la [RFC2434].

La Section Considérations relatives à l'IANA de la spécification DOIT inclure les informations suivantes :
Valeur : valeur de l'élément <objet> à enregistrer
Description : brève description de l'usage prévu de l'URI

 	10.	Remerciements

Les auteurs tiennent à remercier Dan Petrie, Sean Olson, Alan Johnston, Rohan Mahy, Cullen Jennings, Brian Rosen, Roni Even, et Miguel Garcia de leurs commentaires et apports.

 	11.	Références
 	11.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)

[RFC2434]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre 1998. (Rendue obsolète par la RFC5226)

[RFC2606]	D. Eastlake 3rd et A. Panitz, "Noms réservés de niveau supérieur du DNS", BCP 32, juin 1999.

[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 supports XML", janvier 2001. (Obsolète, voir RFC7303)

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

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

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

[RFC3323]	J. Peterson, "Mécanisme de confidentialité pour le protocole d'initialisation de session (SIP)", novembre 2002.

[RFC3326]	H. Schulzrinne, D. Oran, G. Camarillo, "Champ d'en-tête Reason pour le protocole d'initialisation de session (SIP)", décembre 2002. (P.S.)

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

[RFC3629]	F. Yergeau, "UTF-8, un format de transformation de la norme ISO 10646", STD 63, novembre 2003.

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

[RFC4353]	J. Rosenberg, "Cadre pour les conférences avec le protocole d'initialisation de session (SIP)", février 2006. (Information)

[RFC4566]	M. Handley, V. Jacobson et C. Perkins, "SDP : Protocole de description de session", juillet 2006. (P.S.  ; Remplacée par RFC8866)

[RFC4574]	O. Levin, G. Camarillo, "Attribut Label du protocole de description de session (SDP)", août 2006. (P.S.)

 	11.2	Références pour information

[RFC2326]	H. Schulzrinne, A. Rao et R. Lanphier, "Protocole de flux directs en temps réel (RTSP)", avril 1998. (Remplacée par RFC7826)

[RFC3508]	O. Levin, "Enregistrement du schéma des adresses universelles (URL) de la Recommandation UIT-T H.323", avril  2003.

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

[RFC3966]	H. Schulzrinne, "L'URI tel pour les numéros de téléphone", décembre 2004. (MàJ par RFC5341) (P.S.)

[RFC4235]	J. Rosenberg et autres, "Paquetage d'événement de dialogue initié par INVITE pour le protocole d'initialisation de session (SIP)", novembre 2005. (P.S.)

[RFC4474]	J. Peterson et C. Jennings, "Améliorations de la gestion d'identité authentifiée dans le protocole d'initialisation de session (SIP)", août 2006. (P.S. ; MàJ par RFC8224)

[RFC4854]	P. Saint-Andre, "Espace de noms d'URN pour les extensions au protocole extensible de messagerie et de présence (XMPP)", avril 2007. (Information)

[RFC5627]	J. Rosenberg, "Obtention et utilisation des URI d'agent d'utilisateur mondialement acheminable (GRUU) dans le protocole d'initialisation de session (SIP)", octobre 2009. (P. S.)

 	Adresse des auteurs
Henning Schulzrinne	Jonathan Rosenberg	Orit Levin (éditeur)	
Columbia University	Cisco Systems	Microsoft Corporation	
Department of Computer Science	600 Lanidex Plaza	One Microsoft Way	
450 Computer Science Building	Parsippany, NJ  07054	Redmond, WA  98052	
New York, NY  10027	US	US	
US	téléphone : +1 973 952-5000	mél : oritl@microsoft.com 	
mél : hgs+simple@cs.columbia.edu 	mél : jdrosen@cisco.com 		
URI : http://www.cs.columbia.edu 	URI : http://www.jdrosen.net 		

 	Déclaration complète de droits de reproduction

Copyright (C) The IETF Trust (2006).

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

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

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

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

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

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