idnits 2.17.1 

draft-ietf-clue-protocol-01.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** The document seems to lack a Security Considerations section.

  ** The document seems to lack an IANA Considerations section.  (See Section
     2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
     when there are no actions for IANA.)

  ** There are 189 instances of too long lines in the document, the longest
     one being 18 characters in excess of 72.

  ** The abstract seems to contain references ([I-D.kyzivat-clue-signaling],
     [I-D.ietf-clue-framework], [I-D.ietf-clue-datachannel],
     [I-D.ietf-clue-telepresence-requirements]), which it shouldn't.  Please
     replace those with straight textual mentions of the documents in question.

  ** The document seems to lack a both a reference to RFC 2119 and the
     recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
     keywords. 

     RFC 2119 keyword, line 205: '...a CLUE dialogue, the involved CPs MUST...'
     RFC 2119 keyword, line 396: '...   SHOULD be provided for each major v...'
     RFC 2119 keyword, line 404: '...ed, at least one <version> tag MUST be...'
     RFC 2119 keyword, line 428: '...o errors, the CR MUST insert within th...'
     RFC 2119 keyword, line 431: '...ent of the <version> element MUST be a...'
     (5 more instances...)


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
     match the current year

  == Line 916 has weird spacing: '...receive    sen...'

  == Line 1028 has weird spacing: '...receive   rece...'

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).
     
     Found 'SHOULD not' in this paragraph:
     
     The optional boolean <ack> element, set to "true", if present,
     indicates that the CONF message also acknowledge the referred
     advertisement, by applying in that way a piggibacking mechanism for
     simultaneously acknowledging and replying to the ADV message.  The <ack>
     element SHOULD not be present at all if an ADV ACK message has been
     already sent back to the MP and if the CONFIGURE refers to a READV
     RESPONSE message.

  -- The document date (June 24, 2014) is 3593 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Unused Reference: 'RFC5261' is defined on line 2160, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC6503' is defined on line 2176, but no explicit
     reference was found in the text

  == Outdated reference: A later version (-17) exists of
     draft-ietf-clue-data-model-schema-05

  == Outdated reference: A later version (-25) exists of
     draft-ietf-clue-framework-15

  -- Obsolete informational reference (is this intentional?): RFC 5117
     (Obsoleted by RFC 7667)


     Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------


2	CLUE Working Group                                             R. Presta
3	Internet-Draft                                                 S. Romano
4	Intended status: Standards Track                    University of Napoli
5	Expires: December 26, 2014                                 June 24, 2014

7	                             CLUE protocol
8	                      draft-ietf-clue-protocol-01

10	Abstract

12	   The CLUE protocol is an application protocol conceived for the
13	   description and negotiation of a CLUE telepresence session.  The
14	   design of the CLUE protocol takes into account the requirements and
15	   the framework defined, respectively, in [I-D.ietf-clue-framework] and
16	   [I-D.ietf-clue-telepresence-requirements].  The companion document
17	   [I-D.kyzivat-clue-signaling] delves into CLUE signaling details, as
18	   well as on the SIP/SDP session establishment phase.  CLUE messages
19	   flow upon the CLUE data channel, based on reliable and ordered SCTP
20	   over DTLS transport, as described in [I-D.ietf-clue-datachannel].
21	   Message details, together with the behavior of CLUE Participants
22	   acting as Media Providers and/or Media Consumers, are herein
23	   discussed.

25	Status of This Memo

27	   This Internet-Draft is submitted in full conformance with the
28	   provisions of BCP 78 and BCP 79.

30	   Internet-Drafts are working documents of the Internet Engineering
31	   Task Force (IETF).  Note that other groups may also distribute
32	   working documents as Internet-Drafts.  The list of current Internet-
33	   Drafts is at http://datatracker.ietf.org/drafts/current/.

35	   Internet-Drafts are draft documents valid for a maximum of six months
36	   and may be updated, replaced, or obsoleted by other documents at any
37	   time.  It is inappropriate to use Internet-Drafts as reference
38	   material or to cite them other than as "work in progress."

40	   This Internet-Draft will expire on December 26, 2014.

42	Copyright Notice

44	   Copyright (c) 2014 IETF Trust and the persons identified as the
45	   document authors.  All rights reserved.

47	   This document is subject to BCP 78 and the IETF Trust's Legal
48	   Provisions Relating to IETF Documents
49	   (http://trustee.ietf.org/license-info) in effect on the date of
50	   publication of this document.  Please review these documents
51	   carefully, as they describe your rights and restrictions with respect
52	   to this document.  Code Components extracted from this document must
53	   include Simplified BSD License text as described in Section 4.e of
54	   the Trust Legal Provisions and are provided without warranty as
55	   described in the Simplified BSD License.

57	Table of Contents

59	   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
60	   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
61	   3.  Overview of the CLUE protocol  . . . . . . . . . . . . . . . .  4
62	   4.  Protocol messages  . . . . . . . . . . . . . . . . . . . . . .  6
63	     4.1.  OPTIONS  . . . . . . . . . . . . . . . . . . . . . . . . .  8
64	     4.2.  OPTIONS RESPONSE . . . . . . . . . . . . . . . . . . . . . 10
65	     4.3.  ADVERTISEMENT  . . . . . . . . . . . . . . . . . . . . . . 11
66	     4.4.  ADVERTISEMENT ACKNOWLEDGEMENT  . . . . . . . . . . . . . . 12
67	     4.5.  CONFIGURE  . . . . . . . . . . . . . . . . . . . . . . . . 13
68	     4.6.  CONFIGURE RESPONSE . . . . . . . . . . . . . . . . . . . . 14
69	     4.7.  READV  . . . . . . . . . . . . . . . . . . . . . . . . . . 14
70	     4.8.  READV RESPONSE . . . . . . . . . . . . . . . . . . . . . . 15
71	     4.9.  Response codes and reason strings  . . . . . . . . . . . . 16
72	   5.  Protocol state machines  . . . . . . . . . . . . . . . . . . . 18
73	   6.  CLUE Participant's state machine . . . . . . . . . . . . . . . 18
74	     6.1.  Media Consumer's state machine . . . . . . . . . . . . . . 21
75	     6.2.  Media Provider's state machine . . . . . . . . . . . . . . 23
76	   7.  Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . 25
77	   8.  Extensions and options . . . . . . . . . . . . . . . . . . . . 26
78	   9.  XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 28
79	   10. ADVERTISEMENT examples . . . . . . . . . . . . . . . . . . . . 33
80	     10.1. Simple ADV . . . . . . . . . . . . . . . . . . . . . . . . 34
81	     10.2. ADV with MCCs  . . . . . . . . . . . . . . . . . . . . . . 39
82	   11. Diff with draft-ietf-clue-protocol-00  . . . . . . . . . . . . 46
83	   12. Diff with draft-presta-clue-protocol-04  . . . . . . . . . . . 47
84	   13. Diff with draft-presta-clue-protocol-03  . . . . . . . . . . . 47
85	   14. Diff with draft-presta-clue-protocol-02  . . . . . . . . . . . 47
86	   15. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 47
87	   16. Informative References . . . . . . . . . . . . . . . . . . . . 48

89	1.  Introduction

91	   The CLUE protocol is an application protocol used by two CLUE
92	   Participants to enhance the experience of a multimedia telepresence
93	   session.  The main goals of the CLUE protocol are:

95	   1.  enabling a MP to fully announce its current telepresence
96	       capabilities to a MC in terms of available media captures, groups
97	       of encodings, simultaneity constraints and other information
98	       envisioned in [I-D.ietf-clue-framework];

100	   2.  enabling a MC to request the desired multimedia streams to the
101	       offering MP.

103	   CLUE-capable endpoints are connected by means of the CLUE data
104	   channel, an SCTP over DTLS channel which is opened and established as
105	   depicted respectively in [I-D.kyzivat-clue-signaling] and
106	   [I-D.kyzivat-clue-signaling].  CLUE protocol messages flowing upon
107	   such channel are detailed in the following, both syntactically and
108	   semantically.

110	   In Section 3 we provide a general overview of the CLUE protocol.
111	   CLUE protocol messages are detailed in Section 4 The CLUE Participant
112	   state machine is introduced in Section 5.  Versioning and extensions
113	   are discussed in Section 7 and Section 8, respectively.  The XML
114	   schema defining the CLUE messages is reported in Section 9.

116	2.  Terminology

118	   This document refers to the same terminology used in
119	   [I-D.ietf-clue-framework] and in
120	   [I-D.ietf-clue-telepresence-requirements].  We briefly recall herein
121	   some of the main terms exploited in the document.  We further
122	   introduce the definition of CLUE Participant.

124	   CLUE Participant  An entity able to use the CLUE protocol within a
125	      telepresence session.  It can be an endpoint or a MCU able to use
126	      the CLUE protocol.

128	   Endpoint  The logical point of final termination through receiving,
129	      decoding and rendering, and/or initiation through capturing,
130	      encoding, and sending of media streams.  An endpoint consists of
131	      one or more physical devices which source and sink media streams,
132	      and exactly one [RFC4353] Participant (which, in turn, includes
133	      exactly one SIP User Agent).  Endpoints can be anything from
134	      multiscreen/multicamera room controllers to handheld devices.

136	   MCU  Multipoint Control Unit (MCU) - a device that connects two or
137	      more endpoints together into one single multimedia conference
138	      [RFC5117].  An MCU may include a Mixer [RFC4353].

140	   Media  Any data that, after suitable encoding, can be conveyed over
141	      RTP, including audio, video or timed text.

143	   Media Capture  A "Media Capture", or simply "Capture", is a source of
144	      Media.

146	   Capture Encoding  A specific encoding of a Media Capture, to be sent
147	      via RTP [RFC3550].

149	   Media Stream  The term "Media Stream", or simply "Stream", is used as
150	      a synonymous of Capture Encoding.

152	   Media Provider  A CLUE Participant (i.e., an Endpoint or a MCU) able
153	      to send Media Streams.

155	   Media Consumer  A CLUE Participant (i.e., an Endpoint or a MCU) able
156	      to receive Media Streams.

158	3.  Overview of the CLUE protocol

160	   The CLUE protocol has been conceived to enable CLUE telepresence
161	   session.  It is designed in order to address SDP limitations in terms
162	   of the description of several information about the multimedia
163	   streams that are involved in a real-time multimedia conference.
164	   Indeed, by simply using SDP we are not able to convey the information
165	   about the features of the flowing multimedia streams that is needed
166	   to enable a "being there" rendering.  Such information is designed in
167	   the CLUE framework document and formally defined and described in the
168	   CLUE data model document.  The CLUE protocol represents the mechanism
169	   that enables the exchange of CLUE information between CLUE
170	   Participants.  It mainly provides the messages to enable a Media
171	   Provider to advertise its telepresence capabilities and to enable a
172	   Media Consumer to select the desired telepresence options.

174	   The CLUE protocol, as defined in the following, is a stateful,
175	   client-server, XML-based application protocol.  CLUE protocol
176	   messages flow on realiable and ordered SCTP over DTLS transport
177	   channel connecting two CLUE Participants.  Messages carries
178	   information taken from the XML-based CLUE data model
179	   ([I-D.ietf-clue-data-model-schema]).  Three main communication layers
180	   can be identified:

182	   1.  Establishment of the CLUE data channel: in this phase, the CLUE
183	       data channel setup takes place.  If it ends up successfully, the
184	       CPs are able to communicate and start the initiation phase.

186	   2.  Negotiation of the CLUE protocol version and options (initiation
187	       phase): the CPs connected via the CLUE data channel agree on the
188	       version and on the options to be used during the telepresence
189	       session.  Special CLUE messages are used for such a task.  At the
190	       end of that basic negotiation, each CP starts its activity as a
191	       CLUE MP and/or CLUE MC.

193	   3.  CLUE telepresence capabilities description and negotiation: in
194	       this phase, the MP-MC offer-answer dialogues take place on the
195	       data channel by means of the CLUE protocol messages.

197	   As soon as the channel is ready, the CLUE Participants must agree on
198	   the protocol version and extensions to be used within the
199	   telepresence session.  CLUE protocol version numbers are
200	   characterized by a major version number and a minor version number,
201	   both unsigned integer, separated by a dot.  While minor version
202	   numbers denote backword compatible changes in the context of a given
203	   major version, different major version numbers generally indicate a
204	   lack of interoperability between the protocol implementations.  In
205	   order to correctly establish a CLUE dialogue, the involved CPs MUST
206	   have in common a major version number (see Section 7 for further
207	   details).  The subset of the protocol options and extensions that are
208	   allowed within the CLUE session is also determined in the initiation
209	   phase, such subset being the one including only the options that are
210	   supported by both parties.  A mechanism for the negotiation of the
211	   CLUE protocol version and extensions is envisioned in the initiation
212	   phase.  According to such solution, the CP which is the CLUE Channel
213	   initiator (CI) issues a proper CLUE message (OPTIONS) to the CP which
214	   is the Channel Receiver (CR) specifying the supported version and
215	   extensions.  The CR then answers by selecting the subset of the CI
216	   extensions that it is able to support and determines the protocol
217	   version to be used.

219	   After that negotiation phase is completed, CLUE Participants describe
220	   and agree on the media flows to be exchanged.  Indeed, being CPs A
221	   and B both transmitting and receiving, it is possible to distinguish
222	   between two dialogues:

224	   1.  the one needed to describe and set up the media streams sent from
225	       A to B, i.e., the dialogue between A's Media Provider side and
226	       B's Media Consumer side

228	   2.  the one needed to describe and set up the media streams sent from
229	       B to A, i.e., the dialogue between B's Media Provider side and
230	       A's Media Consumer side

232	   CLUE messages for the media session description and negotiation is
233	   designed by considering the MP side as the server side of the
234	   protocol, since it produces and provides media streams, and the MC
235	   side as the client side of the protocol, since it requests and
236	   receives media streams.  The messages that are exchanged to set up
237	   the telepresence media session are described by focusing on a single
238	   MP-MC dialogue.

240	   The MP first advertises its available media captures and encoding
241	   capabilities to the MC, as well as its simultaneity constraints,
242	   according to the information model defined in
243	   [I-D.ietf-clue-framework].  The CLUE message conveing the MP's
244	   multimedia offer is the ADVERTISEMENT message.  Such message
245	   leverages the XML data model definitions provided in
246	   [I-D.ietf-clue-data-model-schema].

248	   The MC selects the desired streams of the MP by using the CONFIGURE
249	   message, which makes reference to the information carried in the
250	   previously received ADVERTISEMENT.

252	   Besides ADVERTISEMENT and CONFIGURE, other messages have been
253	   conceived in order to provide all the needed mechanisms and
254	   operations and will be detailed in the following sections.

256	4.  Protocol messages

258	   CLUE protocol messages are textual, XML-based messages that enable
259	   the configuration of the telepresence session.  The formal definition
260	   of such messages is provided in the XML Schema provided at the end of
261	   this document (Section 9).

263	   The XML definitions of the CLUE information provided in
264	   [I-D.ietf-clue-data-model-schema] are included within some CLUE
265	   protocol messages (namely the ADVERTISEMENT, the CONFIGURE, and the
266	   READV RESPONSE messages), in order to use the concept defined in
267	   [I-D.ietf-clue-framework].

269	   The CLUE protocol messages that have been defined up to now are the
270	   following:

272	   o  OPTIONS

274	   o  OPTIONS RESPONSE

276	   o  ADVERTISEMENT (ADV)

278	   o  ADVERTISEMENT ACKNOWLEDGE (ACK)
279	   o  CONFIGURE (CONF)

281	   o  CONFIGURE RESPONSE

283	   o  READV

285	   o  READV RESPONSE

287	   While the OPTIONS and OPTIONS RESPONSE messages are exchanged in the
288	   initiation phase between the CPs, the other messages are involved in
289	   MP-MC dialogues.

291	   Each CLUE message inherits a basic structure depicted in the
292	   following figure:

294	<!-- CLUE MESSAGE TYPE -->
295	<xs:complexType name="clueMessageType" abstract="true">
296	<xs:sequence>
297	<xs:element name="clueId" type="xs:string"/>
298	<xs:element name="sequenceNr" type="xs:unsignedInt"/>
299	</xs:sequence>
300	<xs:attribute name="protocol" type="xs:string" fixed="CLUE" use="required"/>
301	<xs:attribute name="v" type="xs:string" use="required"/>
302	</xs:complexType>

304	   The basic structure determines the mandatory information that is
305	   carried within each CLUE message.  Such an information is made by:

307	   o  clueId: an XML element containing the identifier of the CP within
308	      the telepresence system;

310	   o  sequenceNr: an XML element containing the local message sequence
311	      number;

313	   o  protocol: a mandatory attribute set to "CLUE" identifying the
314	      procotol the messages refer to;

316	   o  v: a mandatory attribute carrying the version of the protocol.
317	      The content of the "v" attribute is composed by the major version
318	      number followed by a dot and then by the minor version number of
319	      the CLUE protocol in use.  Allowed values are of this kind: "1.3",
320	      "2.45", and the like.

322	   Each CP should manage uo to three streams of sequence numbers: (i)
323	   one for the messages exchanged in the initiation phase, (ii) one for
324	   the messages exchanged as MP, and (iii) one for the messages
325	   exchanged as MC.

327	4.1.  OPTIONS

329	   The OPTIONS message is sent by the CP which is the CI to the CP which
330	   is the CR as soon as the CLUE data channel is ready.  Besides the
331	   information envisioned in the basic structure, it specifies:

333	   o  mediaProvider: a mandatory boolean field set to "true" if the CP
334	      is able to act as a MP

336	   o  mediaConsumer: a mandatory boolean field set to "true" if the CP
337	      is able to act as a MC

339	   o  supportedVersions: the list of the supported versions

341	   o  supportedOptions: the list of the supported options

343	   The XML Schema of such a message is reported below:

345	<!-- CLUE OPTIONS -->
346	<xs:complexType name="optionsMessageType">
347	<xs:complexContent>
348	<xs:extension base="clueMessageType">
349	<xs:sequence>
350	<xs:element name="mediaProvider" type="xs:boolean"/>
351	<xs:element name="mediaConsumer" type="xs:boolean"/>
352	<xs:element name="supportedVersions" type="versionsListType" minOccurs="0"/>
353	<xs:element name="supportedOptions" type="optionsListType" minOccurs="0"/>
354	<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
355	</xs:sequence>
356	<xs:anyAttribute namespace="##other" processContents="lax"/>
357	</xs:extension>
358	</xs:complexContent>
359	</xs:complexType>

361	<!-- VERSIONS LIST TYPE -->
362	<xs:complexType name="versionsListType">
363	<xs:sequence>
364	<xs:element name="version" type="xs:string" minOccurs="1"
365	 maxOccurs="unbounded"/>
366	<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
367	</xs:sequence>
368	<xs:anyAttribute namespace="##other" processContents="lax"/>
369	</xs:complexType>

371	<!-- OPTIONS LIST TYPE -->
372	<xs:complexType name="optionsListType">
373	<xs:sequence>
374	<xs:element name="option" type="optionType" minOccurs="1"
375	 maxOccurs="unbounded"/>
376	<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
377	</xs:sequence>
378	<xs:anyAttribute namespace="##other" processContents="lax"/>
379	</xs:complexType>

381	<!-- OPTION TYPE -->
382	<xs:complexType name="optionType">
383	<xs:sequence>
384	<xs:element name="name" type="xs:string" />
385	<xs:element name="schemaRef" type="xs:anyURI" minOccurs="0"/>
386	<xs:element name="version" type="xs:string" minOccurs="0"/>
387	<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
388	</xs:sequence>
389	<xs:anyAttribute namespace="##other" processContents="lax"/>
390	</xs:complexType>
391	   <supportedVersions> contains the list of the versions that are
392	   supported by the CI, each one represented in a child <version>
393	   element.  The content of each <version> element is a string made by
394	   the major version number followed by a dot and then by the minor
395	   version number (e.g., 1.3 or 2.43).  Only one <version> element
396	   SHOULD be provided for each major version supported, containing the
397	   maximum minor version number of such a version, since all minor
398	   versions are backward compatible.  If no <supportedVersions> is
399	   carried whithin the OPTIONS message, the CI supports only the version
400	   declared in the "v" attribute.  For example, if the "v" attribute has
401	   a value of "3.4" and there is not a <supportedVersions> tag in the
402	   OPTIONS message, it means the CI supports only major version 3 with
403	   all the minor versions comprised between 3.0 the 3.4 included.  If a
404	   <supportedVersion> is provided, at least one <version> tag MUST be
405	   included.

407	   The <supportedOptions> element specifies the list of the options
408	   supported by the CI.  If there is no <supportedOptions> in the
409	   OPTIONS message, the CI does not support anything more than what is
410	   envisioned in the versions it supports.  For each option, an <option>
411	   element is provided.  An option is characterized by a name, an XML
412	   schema of reference where the option is defined, and the version of
413	   the protocol which the option refers to. [to be discussed: difference
414	   between options and extensions]

416	4.2.  OPTIONS RESPONSE

418	   The OPTIONS RESPONSE is sent by a CR to a CI as a reply to the
419	   OPTIONS message.  As depicted in the figure below, the OPTIONS
420	   RESPONSE contains mandatorily a response code and a response string
421	   indicating the processing result of the OPTIONS message.  Following,
422	   the CR attaches two boolean tags, <mediaProvider> and
423	   <mediaConsumer>, expressing the supported roles in terms of
424	   respectively MP and MC, similarly to what the CI does in the OPTIONS
425	   message.  These two elements are optional in the OPTIONS RESPONSE
426	   since, in case of error response code, the CR might not want to add
427	   further information besides the response code and the reason string.
428	   In case of no errors, the CR MUST insert within the OPTIONS RESPONSE
429	   the <mediaProvider> and the <mediaConsumer> elements.  Finally, the
430	   highest commonly supported version number is expressed in the
431	   <version> field.  The content of the <version> element MUST be a
432	   string made by the major version number followed by a dot and then by
433	   the minor version number (e.g., 1.3 or 2.43).  The commonly supported
434	   options are copied in the the <commonOptions> field.

436	 <!-- CLUE OPTIONS RESPONSE (2 WAY) -->
437	 <xs:complexType name="optionsResponseMessageType">
438	 <xs:complexContent>
439	 <xs:extension base="clueMessageType">
440	 <xs:sequence>
441	 <xs:element name="responseCode" type="xs:short"/>
442	 <xs:element name="reasonString" type="xs:string"/>
443	 <xs:element name="mediaProvider" type="xs:boolean" minOccurs="0"/>
444	 <xs:element name="mediaConsumer" type="xs:boolean" minOccurs="0"/>
445	 <xs:element name="version" type="xs:string" minOccurs="0"/>
446	 <xs:element name="commonOptions" type="optionsListType" minOccurs="0"/>
447	 <xs:any namespace="##other"
448	 processContents="lax" minOccurs="0"/>
449	 </xs:sequence>
450	 <xs:anyAttribute namespace="##other" processContents="lax"/>
451	 </xs:extension>
452	 </xs:complexContent>
453	 </xs:complexType>

455	   After the reception of such message, the version to be used is
456	   determined by each part of the conversation.  Indeed, it is the one
457	   provided in the <version> tag of the OPTIONS RESPONSE message.  The
458	   following CLUE messages will use such a version number in the "v"
459	   attribute.  The allowed options in the CLUE dialogue will be those
460	   indicated in the <commonOptions> of the OPTIONS RESPONSE message.

462	4.3.  ADVERTISEMENT

464	   This message is used by the MP to advertise the available media
465	   captures and related information to the MC.  The MP sends to the MC
466	   an ADV as soon as it is ready after the successful completion of the
467	   initiation phase.  During the telepresence session, the ADV can be
468	   sent from the MP both periodically and on a per-event basis, i.e.,
469	   each time there are changes in the MP's CLUE telepresence
470	   capabilities.

472	   The ADV structure is defined in the picture below.  The ADV contains
473	   elements compliant with the CLUE data model that characterize the
474	   MP's telepresence offer.  Namely, such elements are: the list of the
475	   media captures (<mediaCaptures>), of the encoding groups
476	   (>encodingGroups>), of the capture scenes (>captureScenes>) and of
477	   the global capture entries (>globalCaptureEntries>), and the list of
478	   the represented participants (>participants>).  Each of them is fully
479	   described in the CLUE framework document and formally defined in the
480	   CLUE data model document.

482	<!-- CLUE ADVERTISEMENT MESSAGE TYPE -->
483	<xs:complexType name="advertisementMessageType">
484	<xs:complexContent>
485	<xs:extension base="clueMessageType">
486	<xs:sequence>
487	<!-- mandatory fields -->
488	<xs:element name="mediaCaptures" type="dm:mediaCapturesType"/>
489	<xs:element name="encodingGroups" type="dm:encodingGroupsType"/>
490	<xs:element name="captureScenes" type="dm:captureScenesType"/>
491	<xs:element name="simultaneousSets" type="dm:simultaneousSetsType"
492	 minOccurs="0"/>
493	<xs:element name="globalCaptureEntries" type="dm:globalCaptureEntriesType"
494	 minOccurs="0"/>
495	<xs:element name="participants" type="dm:participantsType" minOccurs="0"/>
496	<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
497	</xs:sequence>
498	<xs:anyAttribute namespace="##other" processContents="lax"/>
499	</xs:extension>
500	</xs:complexContent>
501	</xs:complexType>

503	   [to be discussed: a "delta" mechanism for advertising only the
504	   changes with respect to the previous notification should be adopted.
505	   Similar approaches have been proposed for partial notifications in
506	   centralized conferencing frameworks ([RFC6502]), leveraging the XML
507	   diff codification mechanism defined in [RFC5261]].

509	4.4.  ADVERTISEMENT ACKNOWLEDGEMENT

511	   The ACK message is sent by a MC to a MP to acknowledge an ADV
512	   message.  As it can be seen from the message schema provided in the
513	   following, the ACK contains a response code and a reason string for
514	   describing the processing result of the ADV.  The <advSequenceNr>
515	   carries the sequence number of the ADV the ACK refers to.

517	   <!-- ADV ACK MESSAGE TYPE -->
518	   <xs:complexType name="advAcknowledgementMessageType">
519	   <xs:complexContent>
520	   <xs:extension base="clueMessageType">
521	   <xs:sequence>
522	   <xs:element name="responseCode" type="xs:short"/>
523	   <xs:element name="reasonString" type="xs:string"/>
524	   <xs:element name="advSequenceNr" type="xs:unsignedInt"/>
525	   <xs:any namespace="##other" processContents="lax" minOccurs="0"/>
526	   </xs:sequence>
527	   <xs:anyAttribute namespace="##other" processContents="lax"/>
528	   </xs:extension>
529	   </xs:complexContent>
530	   </xs:complexType>

532	4.5.  CONFIGURE

534	   The CLUE CONFIGURE message is sent from a MC to a MP to list the
535	   advertised captures the MC wants to receive.  The MC can send a CONF
536	   after the reception of an ADV or each time it wants to request other
537	   captures that have been previously advertised by the MP.  The content
538	   of the CONF message is shown below.

540	    <!-- CLUE CONFIGURE MESSAGE TYPE -->
541	   <xs:complexType name="configureMessageType">
542	   <xs:complexContent>
543	   <xs:extension base="clueMessageType">
544	   <xs:sequence>
545	   <!-- mandatory fields -->
546	   <xs:element name="advSequenceNr" type="xs:unsignedInt"/>
547	   <xs:element name="ack" type="xs:boolean" minOccurs="0" fixed="true"/>
548	   <xs:element name="captureEncodings" type="dm:captureEncodingsType"
549	    minOccurs="0"/>
550	   <xs:any namespace="##other" processContents="lax" minOccurs="0"/>
551	   </xs:sequence>
552	   <xs:anyAttribute namespace="##other" processContents="lax"/>
553	   </xs:extension>
554	   </xs:complexContent>
555	   </xs:complexType>

557	   In the >advSequenceNr< element is contained the sequence number of
558	   the ADVERTISEMENT or of the READV RESPONSE message the CONFIGURE
559	   refers to.

561	   The optional boolean <ack> element, set to "true", if present,
562	   indicates that the CONF message also acknowledge the referred
563	   advertisement, by applying in that way a piggibacking mechanism for
564	   simultaneously acknowledging and replying to the ADV message.  The
565	   <ack> element SHOULD not be present at all if an ADV ACK message has
566	   been already sent back to the MP and if the CONFIGURE refers to a
567	   READV RESPONSE message.

569	   The most important content of the CONFIGURE message is the list of
570	   the capture encodings provided in the <captureEncodings> element.
571	   Such an element is defined in the CLUE data model document and
572	   contains a sequence of capture encodings, representing the streams to
573	   be instantiated.

575	4.6.  CONFIGURE RESPONSE

577	   <!-- CONFIGURE RESPONSE MESSAGE TYPE -->
578	   <xs:complexType name="configureResponseMessageType">
579	   <xs:complexContent>
580	   <xs:extension base="clueMessageType">
581	   <xs:sequence>
582	   <xs:element name="responseCode" type="xs:short"/>
583	   <xs:element name="reasonString" type="xs:string"/>
584	   <xs:element name="confSequenceNr" type="xs:integer"/>
585	   <xs:any namespace="##other" processContents="lax" minOccurs="0"/>
586	   </xs:sequence>
587	   <xs:anyAttribute namespace="##other" processContents="lax"/>
588	   </xs:extension>
589	   </xs:complexContent>
590	   </xs:complexType>

592	   The CONF RESPONSE message is sent from the MP to the MC to
593	   communicate the processing result of requests carried in the
594	   previously received CONF message.  It contains a response code with a
595	   reason string indicating either the success or the failure (along
596	   with failure details) of a CONF request processing.  Following, the
597	   <confSequenceNr> field contains the number of the CONF message the
598	   response refers to.

600	4.7.  READV

602	   The READV message is a request the MC issues to the MP to retrieve an
603	   updated version of the MP's telepresence offer.  The content of the
604	   READV message is specified in the following.

606	   <!-- CLUE READV MESSAGE TYPE -->
607	   <xs:complexType name="readvMessageType">
608	   <xs:complexContent>
609	   <xs:extension base="clueMessageType">
610	   <xs:sequence>
611	   <xs:element name="lastReceivedAdv" type="xs:short"/>
612	   <xs:any namespace="##other" processContents="lax" minOccurs="0"/>
613	   </xs:sequence>
614	   <xs:anyAttribute namespace="##other" processContents="lax"/>
615	   </xs:extension>
616	   </xs:complexContent>
617	   </xs:complexType>

619	   The <lastReceivedAdv> element specifies the sequence number of the
620	   last ADVERTISEMENT or READV RESPONSE correctly received by the MC.

622	4.8.  READV RESPONSE

624	   The READV RESPONSE is sent by the MP to the MC to reply to a READV
625	   message.  As shown in the schema below, it contains, besides a
626	   response code and a reason string, all the information carried within
627	   an ADVERTISEMENT message (media captures, encoding groups, and so
628	   on).  If there are no updates with respect to the last telepresence
629	   offer successfully delivered to the MC (i.e, that having the sequence
630	   number specified in the <lastReceiveAdv> field of the READV message),
631	   the READV RESPONSE SHOULD carry only the response code with the
632	   reason string.

634	<!-- CLUE READV RESPONSE MESSAGE TYPE -->
635	<xs:complexType name="readvResponseMessageType">
636	<xs:complexContent>
637	<xs:extension base="clueMessageType">
638	<xs:sequence>
639	<xs:element name="responseCode" type="xs:short"/>
640	<xs:element name="reasonString" type="xs:string"/>
641	<xs:element name="readvSequenceNr" type="xs:string" minOccurs="0"/>
642	<xs:element name="mediaCaptures" type="dm:mediaCapturesType" minOccurs="0"/>
643	<xs:element name="encodingGroups" type="dm:encodingGroupsType" minOccurs="0"/>
644	<xs:element name="captureScenes" type="dm:captureScenesType" minOccurs="0"/>
645	<xs:element name="simultaneousSets" type="dm:simultaneousSetsType" minOccurs="0"/>
646	<xs:element name="globalCaptureEntries" type="dm:globalCaptureEntriesType" minOccurs="0"/>
647	<xs:element name="participants" type="dm:participantsType" minOccurs="0"/>
648	<xs:any namespace="##other"
649	 processContents="lax" minOccurs="0"/>
650	</xs:sequence>
651	</xs:extension>
652	</xs:complexContent>
653	</xs:complexType>

655	4.9.  Response codes and reason strings

657	   Examples of response codes and strings are provided in the following
658	   table.  Response codes can be designed by adhering to the HTTP
659	   semantics, as shown below.

661	   +-----------------+----------------------+--------------------------+
662	   |                 |                      |                          |
663	   |  Response code  |  Response string     |       Description        |
664	   |                 |                      |                          |
665	   +-----------------+----------------------+--------------------------+
666	   |                 |                      |                          |
667	   |   410           |  Bad syntax          |  The XML syntax of the   |
668	   |                 |                      |  CONF message is not     |
669	   |                 |                      |  correct.                |
670	   +-----------------+----------------------+--------------------------+
671	   |                 |                      |                          |
672	   |   411           |  Invalid value       |  The CONF message        |
673	   |                 |                      |  contains an invalid     |
674	   |                 |                      |  parameter value.        |
675	   +-----------------+----------------------+--------------------------+
676	   |                 |                      |                          |
677	   |   412           |  Invalid identifier  |  The identifier used for |
678	   |                 |                      |  requesting a capture is |
679	   |                 |                      |  not valid or unknown.   |
680	   +-----------------+----------------------+--------------------------+
681	   |                 |                      |                          |
682	   |   413           |  Conflicting values  |  The CONF message        |
683	   |                 |                      |  contains values that    |
684	   |                 |                      |  cannot be used together.|
685	   +-----------------+----------------------+--------------------------+
686	   |                 |                      |                          |
687	   |   420           |  Invalid sequencing  |  The sequence number of  |
688	   |                 |                      |  the CONF message is out |
689	   |                 |                      |  of date or corresponds  |
690	   |                 |                      |  to an obsoleted ADV.    |
691	   +-----------------+----------------------+--------------------------+
692	   |                 |                      |                          |
693	   |   510           | Version not supported|  The CLUE protocol       |
694	   |                 |                      |  version of the CONF     |
695	   |                 |                      |  message is not supported|
696	   |                 |                      |  by the MP.              |
697	   +-----------------+----------------------+--------------------------+
698	   |                 |                      |                          |
699	   |   511           | Option not supported |  The option requested in |
700	   |                 |                      |  the CONF message is not |
701	   |                 |                      |  supported by the MP.    |
702	   +-----------------+----------------------+--------------------------+

704	   ...  TBC.

706	   +---------------+------------------------+
707	   |               |                        |
708	   | Response code | Description            |
709	   | family        |                        |
710	   +---------------+------------------------+
711	   |               |                        |
712	   |     1XX       | Temporary info         |
713	   |               |                        |
714	   +---------------+------------------------+
715	   |               |                        |
716	   |     2XX       | Success                |
717	   |               |                        |
718	   +---------------+------------------------+
719	   |               |                        |
720	   |     3XX       | Redirection            |
721	   |               |                        |
722	   +---------------+------------------------+
723	   |               |                        |
724	   |     4XX       | Client error           |
725	   |               |                        |
726	   +---------------+------------------------+
727	   |               |                        |
728	   |     5XX       | Server error           |
729	   |               |                        |
730	   +---------------+------------------------+

732	5.  Protocol state machines

734	   The CLUE protocol is an application protocol used between two CPs in
735	   order to properly configure a multimedia telepresence session.  CLUE
736	   protocol messages flow upon the CLUE Data Channel, a DTLS/SCTP
737	   channel established as depicted in [I-D.kyzivat-clue-signaling].
738	   Over such a channel there are typically two CLUE streams between the
739	   channel terminations flowing in opposite directions.  In other words,
740	   typically, both channel terminations act simultaneously as a MP and
741	   as a MC.  We herein discuss the state machines associated,
742	   respectively, with the CLUE Participant, with MC process and with the
743	   MP process.

745	6.  CLUE Participant's state machine

747	   The main state machines focus on describing the states of CLUE
748	   channel from a CLUE channel initiator/receiver.  In the IDLE state,
749	   when the CP has established a CLUE channel, the main state moves to
750	   the ESTABLISHED state.  When in the ESTABLISHED state, if the CP is
751	   the Channel Initiator (CI), it prepares sending an OPTIONS message
752	   for version negotiation; otherwise, if the is the Channel Receiver
753	   (CR), it listens to the channel for an OPTIONS message for version
754	   negotiation.  If an OPTIONS message is sent or is received, the CP
755	   moves to the NEGOTIATING state.  If the CP checks some error in the
756	   request message received, the main state goes back to the IDLE state.
757	   [TODO: check this] When in the NEGOTIATING state, the CR prepares an
758	   OPTIONS RESPONSE message while the CI listens to the channel for an
759	   OPTIONS RESPONSE.  If an OPTIONS RESPONSE message for version
760	   negotiation is sent or is received, the main state moves to the
761	   ACTIVE state.  If the CI checks some error in the OPTIONS RESPONSE
762	   message received or receives an OPTIONS RESPONSE indicating an error,
763	   it goes back to the IDLE state.  When the CP enters in the ACTIVE
764	   state, it creates two sub state machines which are the MC state
765	   machine and the MP state machine, accordingly to the supported roles.
766	   When in the ACTIVE state, if the CP receives a further OPTIONS
767	   message for version negotiation or a further OPTIONS RESPONSE
768	   messages for version negotiation, it MUST ignore the messages and
769	   keep in the ACTIVE state.  When in the ACTIVE state, the CP delegates
770	   the sending and the processing of the CLUE messages the appropriate
771	   MP/MC sub-state machines.  The TERMINATED state is reachable from
772	   each of the aforementioned states whenever the session is canceled or
773	   released.  The IDLE state is reachable from each of the
774	   aforementioned states whenever the underlying channel is closed due
775	   to connection error.  [TODO: CLUE messages to cancel/release the
776	   session] [TODO: check the diagram]
777	                      +-------------+<------------------------------+---------+
778	         +----------->+     IDLE    +<--------------------------+   + TIMEOUT +
779	         |            +------+------+<-----------+              |   +------+--+
780	         |                   |                   |              |          |
781	         |                   |                   |              |          |
782	     Connection            CLUE                  |              |          |
783	       error              channel                |              |          |
784	         |           has been established        |              |          |
785	         |                   |                   |              |          |
786	         |                   V               Receive error      |          |
787	         +------------+-------------+     (version mismatch,    |          |
788	   +------------------+ ESTABLISHED +      missing elements,...)  |       time out
789	   |                  +------+------+            |              |          |
790	   |                         |                   |          Connection     |
791	   |                         |                   |             error       |
792	   |                  Send/Receive OPTIONS       |              |          |
793	   |                         |                   |              |          |
794	   |                         V                   |              |          |
795	   |                  +-------------+------------+              |          |
796	   |     +------------+ NEGOTIATING +---------------------------+          |
797	   |     |            +------+------+---------------------------|----------+
798	   |     |                   |                                  |
799	   |     |                   |                                  |
800	   |     |             Receive/Send                        Connection
801	   |     |            OPTIONS RESPONSE                       error
802	Session  |                   |                                  |
803	  ends   |                   V                                  |
804	   |     |            +-------------+---------------------------+
805	   |     |            |   ACTIVE    +<-------------------+
806	   |     |            |  +-------+  |           Receive OPTIONS/
807	   |     |            |  |SUBIDLE|  |             OPTIONS RESPONSE
808	   |   Session        |  |MC     |  +--------------------+
809	   |    ends          |  +-------+  |
810	   |     |            |  +-------+  +<-------------------+
811	   |     |            |  |SUBIDLE|  |       Send/Receive other CLUE messages
812	   |     |            |  |MP     |  |                    |
813	   |     |            |  +-------+  |                    |
814	   |     |            +------+------+--------------------+
815	   |     |                   |
816	   |     |                   |
817	   |     |                Session
818	   |     |                  ends
819	   |     |                   |
820	   |     |                   V
821	   |     |            +-------------+
822	   |     +----------->+ TERMINATED  +
823	   +----------------->+-------------+

825	6.1.  Media Consumer's state machine

827	   An MC in the WAIT FOR ADV state is waiting for an ADV coming from the
828	   MP.  If the timeout expires ("timeout"), the MC switches to the
829	   TIMEOUT state.

831	   In the TIMEOUT state, if the number of trials is below the retry
832	   threshold, the MC sends a READV message to the MP ("send RE-ADV"),
833	   switching back to the WAIT FOR ADV.  Otherwise, the MC moves to the
834	   TERMINATED state.

836	   When the ADV has been received ("receive ADV"), the MC goes into the
837	   ADV RECEIVED state.  The ADV is then parsed.  If something goes wrong
838	   with the ADV (bad syntax, missing XML elements, etc.), the MC sends a
839	   NACK message (an ACK with an error response code) to the MP
840	   specifying the encountered problem via a proper reason phrase.  In
841	   this way, the MC switches back to the WAIT FOR ADV state, waiting for
842	   a new copy of the ADV.  If the ADV is successfully processed, the MC
843	   issues a successful ACK message to the MP and moves to the ADV ACKED
844	   state.  When the SDP information arrives, from the ADV RECEIVED or
845	   the ADV ACKED state the MC switches to the READY TO CONF state.  When
846	   the CONF request is ready, the MC sends it and moves to the TRYING
847	   state.  If the ADV has not been already sent, the MC can piggyback
848	   the ACK message within the CONF request.

850	   While in the TRYING state, the MC is waiting for a CONF RESPONSE
851	   message (to the issued CONF) from the MP.  If the timeout expires
852	   ("timeout"), the MC moves to the TIMEOUT state and sends a READV in
853	   order to solicit a new ADV from the MP.  If a CONF RESPONSE with an
854	   error code is received ("receive 4xx, 5xx not supported"), then the
855	   MC moves back to the ADV RECEIVED state and produces a new CONF
856	   message to be sent to the MP.  If a successful CONF RESPONSE arrives
857	   ("receive 200 OK"), the MC gets into the CONF COMPLETED state. state.

859	   When the MC is in the CONF COMPLETED state, it means that the
860	   telepresence session configuration has been set up according to the
861	   MC's preferences.  Both the MP and the MC have agreed on (and are
862	   aware of) the media streams to be exchanged within the call.  If the
863	   MC decides to change something in the call settings, it issues a new
864	   CONF ("send CONF") and moves back to the TRYING state.  If a new ADV
865	   arrives from the MP ("receive ADV"), it means that something has
866	   changed on the MP's side.  The MC then moves to the ADV RECEIVED
867	   state and prepares a new CONF taking into account the received
868	   updates.  When the underlying channel is closed, the MC moves into
869	   the TERMINATED state.

871	   The TERMINATED state is reachable from each of the aforementioned
872	   states whenever the underlying channel is closed.  The corresponding
873	   transitions have not been reported for the sake of simplicity.  This
874	   termination condition is a temporary solution.

876	                                                                      +-----+
877	                     +---------------+-------------timeout------>+----+--+  |
878	                     | WAIT FOR ADV  |<----+                     |TIMEOUT|  |
879	                     +---------------+<----+--------send---------+-------+  |
880	                                |          |     RE-ADV(refresh)      ^     |
881	                                |          |                          |     |
882	                                |          |                          |     |
883	                             receive     send                         |     |
884	                               ADV       NACK                         |     |
885	           +---receive-------+  |       (missing elements,            |     |
886	           |   error RESP    |  |        invalid area,...)            |     |
887	           |                 v  v          |                          |     |
888	           +----------------+---------+----+      +--------+          |     |
889	          +---------------->|  ADV    |---send--->|  ADV   |      timeout   |
890	          |                 | RECEIVED|   ACK     | ACKED  |          |     |
891	          |     +---------->|         |           |        |          |     |
892	          |    recv  +----->+-----+---+<--recv----+----+---+          |     |
893	          |   error  |            |       ADV          |              |     |
894	          |    CONF  |            |                    |              |     |
895	          |     |    |         SDP info            SDP info           |     |
896	          |     |    |         received             received          |     |
897	          |     |    |            |     +--------+     |              |     +
898	          +     |    +            +---->|READY TO|<----+              +     |
899	          |     |    |                  | CONF   |                    |     |
900	          |     +    |            +-----+--------+-----+              +     |
901	          |     |    |            |                    +              +     |
902	          |     |    +            |                    |              +     +
903	          +     +    |            +                    |              |     |
904	      receive   |    |           send              send|              |     |
905	        ADV     |    |         CONF+ACK            CONF|              |     |
906	          |     |    |            |                    |              |     |
907	          |     |  receive        v                    |              |     |
908	          |     |  ADV         +-----------+<----------+              |     |
909	          |     |    |         |           |+-------------------------+     |
910	          |     +----|--------+|  TRYING   |                                |
911	          +----------|---------|           |                                |
912	                 +---|---------+-----------+                                |
913	                 |   |          |          ^                                |
914	                 |   |          |          |                                |
915	                 |   |          |          |                                |
916	          receive|   |         receive    send                          retry
917	          error RESP,|          200 OK    CONF                        expires
918	          retry  |   |          |          |                                |
919	          expired|   |          |          |                                |
920	                 |   |          |          |                                |
921	                 |   |          v          |                                |
922	                 |   |       +---------+   |                                |
923	                 |   +-------| CONF    |   |                                |
924	                 |           |COMPLETED|---+                                |
925	                 |           +---------+                                    |
926	                 |              |                                           |
927	                 |              |                                           |
928	                 |              |                                           |
929	                 |              |                                           |
930	                 |            connection                                    |
931	                 |             closed                                       |
932	                 |              |                                           |
933	                 |              |                                           |
934	                 |              |                                           |
935	                 |              |                                           |
936	                 |              |                                           |
937	                 |              v                                           |
938	                 |            +----------+<---------------------------------+
939	                 +----------->+TERMINATED|
940	                              +----------+

942	6.2.  Media Provider's state machine

944	   In the PREPARING ADV state, the MP is preparing the ADV message
945	   reflecting the actual telepresence capabilities.  After the ADV has
946	   been sent, the MP moves to the WAIT FOR ACK state.  If the ACK
947	   arrives, the MP moves to the WAIT FOR CONF state.  If a NACK arrives,
948	   it goes back to the PREPARING ADV state.

950	   When in the WAIT FOR ACK state, if a CONF or a CONF+ACK arrives, the
951	   MP switch to the CONF RECEIVED state directly.

953	   When in the WAIT FOR CONF state, the MP is listening to the channel
954	   for a CONF coming from the MC.  If a RE-ADV is received, the MP goes
955	   back to the IDLE state and issues an ADV again.  If telepresence
956	   settings change in the meanwhile, it moves back to the PREPARING ADV
957	   state and prepares a new ADV to be sent to the MC.  If a CONF
958	   arrives, the MP switches to the CONF RECEIVED state.  If nothing
959	   happens and the timeout expires, than the MC falls into the TIMEOUT
960	   state.

962	   In the TIMEOUT state, if the number of trials does not exceed the
963	   retry threshold, the MC comes back to the PREPARING ADV state for
964	   sending a new ADV.  Otherwise, it goes to the TERMINATED state.

966	   The MP in the CONF RECEIVED state is processing the received CONF in
967	   order to produce a CONF RESPONSE message.  If the MP is fine with the
968	   MC's configuration, then it sends back a 200 OK successful CONF
969	   RESPONSE and moves to the IN CALL state.  If there are errors duting
970	   CONF processing, then the MC returns a CONF RESPONSE carrying an
971	   error response code.  Finally, if there are changes in the
972	   telepresence settings, it goes back to the PREPARING ADV state to
973	   issue an updated ADV.

975	   When in the CONF COMPLETED state, the MP has successfully configured
976	   the telepresence session according to the MC's specifications.  If a
977	   new CONF arrives, it switches to the CONF RECEIVED state to analyze
978	   the new request.  If a RE-ADV arrives, or some modifications are
979	   applied to the telepresence options, then it moves to the PREPARE-ADV
980	   state to issue the ADV.  When the channel is terminated, the MP falls
981	   into the TERMINATED state.

983	   The TERMINATED state is reachable from each of the aforementioned
984	   states whenever the underlying channel is closed.  The corresponding
985	   transitions have not been reported for the sake of simplicity.  This
986	   termination condition is a temporary solution.

988	                    +-----------+
989	                    |           |
990	                    | PREPARING |
991	 +----------------->|   ADV     |<--------------------------+
992	 |   +------------->|           |<-----------retry----------+---------+
993	 |   |       +----->|           |<--+         not           |         |
994	 |   |       |      +-----------+   |        expired        |         |
995	 |   |       |            |         |                       |         |
996	 |   |  change          send       receive                  |        ++------+
997	 |   |  telepresence     ADV        NACK                    |        |TIMEOUT|
998	 |   |  settings          |         |                       |        ++--+---+
999	 |   |       |            |         |                       |         ^  |
1000	 |   |       |            v         |                       |         |  |
1001	 |   |       |    +-------------+---+                       |         |  |
1002	 |   |       +----+  WAIT FOR   +------------timeout--------+---------+  |
1003	 |   |         +--+     ACK     |                           |            |
1004	 change        |  +-------+-----+                           |            |
1005	 telepresence  |          |                                 |            |
1006	 settings      |        recv                                |            +
1007	 +   +         |        ACK                                 +            |
1008	 |   |         |          |                                 |            |
1009	 |   |         |          v                                 |            |
1010	 |   |         |     +-----------+                          |            |
1011	 |   |      recv     | WAIT FOR  |                          |            |
1012	 |   |         |     |   CONF    |<-+                       |            |
1013	 |   |    CONF+ACK   +----+------+  |                       |            |
1014	 |   |         |          |         +                       |            |
1015	 +   |         |        receive     CONF error,             +            |
1016	 |   +         |         CONF       retry not expired,      |            +
1017	 |   |         |          |         send error RESP         |            |
1018	 |   |         |          |         |                       |            |
1019	 |   |         |          |         |                       |            |
1020	 |   |         |          v         |                       |            |
1021	 |   |         +--->+-----------+---+                       |            |
1022	 +---+-------------+|   CONF    |                           |            |
1023	     |       +----->| RECEIVED  |----CONF error,            |            |
1024	     |       |      +-----+-----+    retry expired          |            |
1025	     |       |            |          +                      |            |
1026	     |       |            |          |                      |            |
1027	     |       |            |          |                      |            |
1028	 receive   receive      send         |                      |            |
1029	 RE-ADV     CONF       200 OK        |                      |       retry|
1030	     |       |            |          |                      |      expired
1031	     |       |            |          |                      |            |
1032	     |       |            |          |                      |            |
1033	     |       |            v          |                      |            |
1034	     |       |       +----------+    |   change             |            |
1035	     |       +-------|  CONF    |----|---telepresence-------+            |
1036	     +---------------| COMPLETED|    |   settings                        |
1037	                     +----------+    |                                   |
1038	                          |          |                                   |
1039	                          |          |                                   |
1040	                          |          |                                   |
1041	                       connection    |                                   |
1042	                        closed       |                                   |
1043	                          |          |                                   |
1044	                          |          |                                   |
1045	                          v          |                                   +
1046	                 +----------------+<-+                                   |
1047	                 |   TERMINATED   |<-------------------------------------+
1048	                 |                |
1049	                 +----------------+

1051	7.  Versioning

1053	   CLUE protocol messages are XML messages compliant to the CLUE
1054	   protocol XML schema.  The version of the protocol corresponds to the
1055	   version of the schema.  Both client and server have to test the
1056	   compliance of the received messages with the XML schema of the CLUE
1057	   protocol.  If the compliance is not verified, the message cannot be
1058	   processed further.

1060	   Obviously, client and server can not communicate if they do not share
1061	   exactly the same XML schema.  Such a schema is the one included in
1062	   the yet to come RFC, and associated with the CLUE URN
1063	   "urn:ietf:params:xml:ns:clue-message".  If all CLUE-enabled devices
1064	   use that schema there will be no interoperability problems due to
1065	   schema issues.

1067	   The version of the XML schema contained in the standard document
1068	   deriving from this draft will be 1.0.  The version usage is similar
1069	   in philosophy to XMPP (RFC6120).  A version number has major and
1070	   minor components, each a non-negative integer.  Major version changes
1071	   denote non-interoperable changes.  Minor version changes denote
1072	   schema changes that are backward compatible by ignoring unknown XML
1073	   elements, or other backward compatible changes.

1075	   The minor versions of the XML schema MUST be backward compatible, not
1076	   only in terms of schema but also semantically and procedurally as
1077	   well.  This means that they should define further features and
1078	   functionality besides those defined in the previous versions, in an
1079	   incremental way, without impacting the basic rules defined in the
1080	   previous version of the schema.  In this way, if a MP is able to
1081	   speak, e.g., version 1.5 of the protocol while the MC only
1082	   understands version 1.4, the MP should have no problem in reverting
1083	   the dialogue to version 1.4 without exploiting 1.5 features and
1084	   functionality.

1086	   It is expected that, before the CLUE protocol XML schema reaches a
1087	   steady state, prototypes developed by different organizations will
1088	   conduct interoperability testing.  In that case, in order to
1089	   interoperate, they have to be compliant to the current version of the
1090	   XML schema, i.e., the one copied in the most up-to-date version of
1091	   the draft defining the CLUE protocol.  The versions of the non-
1092	   standard XML schema will be numbered as 0.01, 0.02, and so on.
1093	   During the standard development phase, the versions of the XML schema
1094	   will probably not be backward compatible so it is left to prototype
1095	   implementers the responsibility of keeping their products up to date.

1097	8.  Extensions and options

1099	   Although the standard version of the CLUE protocol XML schema will be
1100	   designed to thoroughly cope with the requirements emerging from the
1101	   application domain, new needs might arise and extensions can be
1102	   designed.  Extensions specify information and behaviors that are not
1103	   described in a certain version of the protocol.  They can relate to:

1105	      the information carried in the existing messages (for example, we
1106	      may want to add more fields within an existing message);

1108	      the meaning of the messages.  This is the case if there is no
1109	      proper message for a certain task, so a brand new CLUE message
1110	      needs to be defined.

1112	   As to the first type of extensions, it is possible to distinguish
1113	   between protocol specific- and data model information.  Indeed, CLUE
1114	   messages are envelopes carrying both:

1116	      (i) XML elements defined within the CLUE protocol XML schema
1117	      itself (protocol-specific information)

1119	      (ii) other XML elements compliant to the CLUE data model schema
1120	      (data model information)

1122	   When new protocol-specific information is needed somewhere in the
1123	   protocol messages, it can be added in place of the <any> elements and
1124	   <anyAttribute> elements envisioned by the protocol schema.  The
1125	   policy currently defined in the protocol schema for handling <any>
1126	   and <anyAttribute> elements is:

1128	      elementFormDefault="qualified"

1130	      attributeFormDefault="unqualified"

1132	   In that case, the new information must be qualified by namespaces
1133	   other than "urn:ietf:params:xml:ns:clue-message" (the protocol URN)
1134	   and "urn:ietf:params:xml:ns:clue-info" (the data model URN).
1135	   Elements or attributes from unknown namespaces MUST be ignored.

1137	   The other matter concerns data model information.  Data model
1138	   information is defined by the XML schema associated with the URN
1139	   "urn:ietf:params:xml:ns:clue-info".  Also for the XML elements
1140	   defined in such a schema there are extensibility issues.  Those
1141	   issues are overcome by using <any> and <anyAttribute> placeholders.
1142	   Similarly to what said before, new information within data model
1143	   elements can be added in place of <any> and <anyAttribute> schema
1144	   elements, as long as they are properly namespace qualified.

1146	   On the other hand (second type of extensions), "extra" CLUE protocol
1147	   messages, i.e., messages not envisioned in the last standard version
1148	   of the schema, can be needed.  In that case, the messages and the
1149	   associated behavior should be defined in external documents that both
1150	   the communication parties must be aware of.

1152	   Both the types of extensions, i.e., the information and the protocol
1153	   extensions, can be characterized by:

1155	      a name;

1157	      an external XML Schema defining the XML information and/or the XML
1158	      messages representing the extension;

1160	      the standard version of the protocol the extension refers to.

1162	   For that reason, the extensions can be represented by means of the
1163	   <option> element as defined below, which is carried within the
1164	   OPTIONS and OPTIONS RESPONSE messages to represent the extensions
1165	   supported by the CI and by the CR.

1167	   <!-- OPTION TYPE -->
1168	   <xs:complexType name="optionType">
1169	   <xs:sequence>
1170	   <xs:element name="name" type="xs:string" />
1171	   <xs:element name="schemaRef" type="xs:anyURI" minOccurs="0"/>
1172	   <xs:element name="version" type="xs:string" minOccurs="0"/>
1173	   <xs:any namespace="##other" processContents="lax" minOccurs="0"/>
1174	   </xs:sequence>
1175	   <xs:anyAttribute namespace="##other" processContents="lax"/>
1176	   </xs:complexType>

1178	9.  XML Schema

1180	   In this section, the XML schema defining the CLUE messages is
1181	   provided.

1183	<?xml version="1.0" encoding="UTF-8" ?>
1184	<xs:schema
1185	version="0.02"
1186	targetNamespace="urn:ietf:params:xml:ns:clue-message"
1187	xmlns:tns="urn:ietf:params:xml:ns:clue-message"
1188	xmlns:xs="http://www.w3.org/2001/XMLSchema"
1189	xmlns:dm="urn:ietf:params:xml:ns:clue-info"
1190	xmlns="urn:ietf:params:xml:ns:clue-message"
1191	elementFormDefault="qualified"
1192	attributeFormDefault="unqualified">

1194	<!-- Import data model schema -->
1195	<xs:import namespace="urn:ietf:params:xml:ns:clue-info"
1196	schemaLocation="data-model-schema-05.xsd"/>

1198	<!-- ELEMENT DEFINITIONS -->
1199	<xs:element name="options" type="optionsMessageType"/>
1200	<xs:element name="optionsResponse" type="optionsResponseMessageType"/>
1201	<!--<xs:element name="optionsAck" type="optionsAcknowledgementMessageType"/>-->
1202	<xs:element name="advertisement" type="advertisementMessageType"/>
1203	<xs:element name="ack" type="advAcknowledgementMessageType"/>
1204	<xs:element name="configure" type="configureMessageType"/>
1205	<xs:element name="configureResponse" type="configureResponseMessageType"/>
1206	<xs:element name="readv" type="readvMessageType"/>
1207	<xs:element name="readvResponse" type="readvResponseMessageType"/>

1209	<!-- CLUE MESSAGE TYPE -->
1210	<xs:complexType name="clueMessageType" abstract="true">
1211	<xs:sequence>
1212	<xs:element name="clueId" type="xs:string"/>
1213	<xs:element name="sequenceNr" type="xs:unsignedInt"/>
1214	</xs:sequence>
1215	<xs:attribute name="protocol" type="xs:string" fixed="CLUE" use="required"/>
1216	<xs:attribute name="v" type="xs:string" use="required"/>
1217	</xs:complexType>

1219	<!-- CLUE OPTIONS -->
1220	<xs:complexType name="optionsMessageType">
1221	<xs:complexContent>
1222	<xs:extension base="clueMessageType">
1223	<xs:sequence>
1224	<xs:element name="mediaProvider" type="xs:boolean"/>
1225	<xs:element name="mediaConsumer" type="xs:boolean"/>
1226	<xs:element name="supportedVersions" type="versionsListType" minOccurs="0"/>
1227	<xs:element name="supportedOptions" type="optionsListType" minOccurs="0"/>
1228	<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
1229	</xs:sequence>
1230	<xs:anyAttribute namespace="##other" processContents="lax"/>
1231	</xs:extension>
1232	</xs:complexContent>
1233	</xs:complexType>

1235	<!-- VERSIONS LIST TYPE -->
1236	<xs:complexType name="versionsListType">
1237	<xs:sequence>
1238	<xs:element name="version" type="xs:string" minOccurs="1"
1239	 maxOccurs="unbounded"/>
1240	<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
1241	</xs:sequence>
1242	<xs:anyAttribute namespace="##other" processContents="lax"/>
1243	</xs:complexType>
1244	<!-- OPTIONS LIST TYPE -->
1245	<xs:complexType name="optionsListType">
1246	<xs:sequence>
1247	<xs:element name="option" type="optionType" minOccurs="1"
1248	 maxOccurs="unbounded"/>
1249	<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
1250	</xs:sequence>
1251	<xs:anyAttribute namespace="##other" processContents="lax"/>
1252	</xs:complexType>

1254	<!-- OPTION TYPE -->
1255	<xs:complexType name="optionType">
1256	<xs:sequence>
1257	<xs:element name="name" type="xs:string" />
1258	<xs:element name="schemaRef" type="xs:anyURI" minOccurs="0"/>
1259	<xs:element name="version" type="xs:string" minOccurs="0"/>
1260	<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
1261	</xs:sequence>
1262	<xs:anyAttribute namespace="##other" processContents="lax"/>
1263	</xs:complexType>

1265	<!-- CLUE OPTIONS RESPONSE (2 WAY) -->
1266	<xs:complexType name="optionsResponseMessageType">
1267	<xs:complexContent>
1268	<xs:extension base="clueMessageType">
1269	<xs:sequence>
1270	<xs:element name="responseCode" type="xs:short"/>
1271	<xs:element name="reasonString" type="xs:string"/>
1272	<xs:element name="mediaProvider" type="xs:boolean" minOccurs="0"/>
1273	<xs:element name="mediaConsumer" type="xs:boolean" minOccurs="0"/>
1274	<xs:element name="version" type="xs:string" minOccurs="0"/>
1275	<xs:element name="commonOptions" type="optionsListType" minOccurs="0"/>
1276	<xs:any namespace="##other"
1277	processContents="lax" minOccurs="0"/>
1278	</xs:sequence>
1279	<xs:anyAttribute namespace="##other" processContents="lax"/>
1280	</xs:extension>
1281	</xs:complexContent>
1282	</xs:complexType>

1284	<!-- CLUE OPTIONS RESPONSE (3 WAYS) -->
1285	<!-- <xs:complexType name="optionsResponseMessageType">
1286	<xs:complexContent>
1287	<xs:extension base="clueMessageType">
1288	<xs:sequence>
1289	<xs:element name="mediaProvider" type="xs:boolean"/>
1290	<xs:element name="mediaConsumer" type="xs:boolean"/>
1291	<xs:element name="supportedVersions" type="versionsListType"
1292	 minOccurs="0"/>
1293	<xs:element name="supportedOptions" type="optionsListType" minOccurs="0"/>
1294	<xs:any namespace="##other"
1295	processContents="lax" minOccurs="0"/>
1296	</xs:sequence>
1297	<xs:anyAttribute namespace="##other" processContents="lax"/>
1298	</xs:extension>
1299	</xs:complexContent>
1300	</xs:complexType>
1301	 -->

1303	<!-- CLUE OPTIONS ACK (3 WAYS)-->
1304	<!--
1305	<xs:complexType name="optionsAckMessageType">
1306	<xs:complexContent>
1307	<xs:extension base="clueMessageType">
1308	<xs:sequence>
1309	<xs:element name="responseCode" type="xs:short"/>
1310	<xs:element name="reasonString" type="xs:string"/>
1311	<xs:element name="version" type="xs:string" minOccurs="0"
1312	 maxOccurs="1"/>
1313	<xs:element name="commonOptions" type="supportedOptionsType" minOccurs="0"/>
1314	<xs:any namespace="##other"
1315	processContents="lax" minOccurs="0"/>
1316	</xs:sequence>
1317	<xs:anyAttribute namespace="##other" processContents="lax"/>
1318	</xs:extension>
1319	</xs:complexContent>
1320	</xs:complexType>
1321	 -->

1323	<!-- CLUE ADVERTISEMENT MESSAGE TYPE -->
1324	<xs:complexType name="advertisementMessageType">
1325	<xs:complexContent>
1326	<xs:extension base="clueMessageType">
1327	<xs:sequence>
1328	<!-- mandatory fields -->
1329	<xs:element name="mediaCaptures" type="dm:mediaCapturesType"/>
1330	<xs:element name="encodingGroups" type="dm:encodingGroupsType"/>
1331	<xs:element name="captureScenes" type="dm:captureScenesType"/>
1332	<xs:element name="simultaneousSets" type="dm:simultaneousSetsType"
1333	 minOccurs="0"/>
1334	<xs:element name="globalCaptureEntries" type="dm:globalCaptureEntriesType"
1335	 minOccurs="0"/>
1336	<xs:element name="participants" type="dm:participantsType" minOccurs="0"/>
1337	<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
1338	</xs:sequence>
1339	<xs:anyAttribute namespace="##other" processContents="lax"/>
1340	</xs:extension>
1341	</xs:complexContent>
1342	</xs:complexType>

1344	<!-- ADV ACK MESSAGE TYPE -->
1345	<xs:complexType name="advAcknowledgementMessageType">
1346	<xs:complexContent>
1347	<xs:extension base="clueMessageType">
1348	<xs:sequence>
1349	<xs:element name="responseCode" type="xs:short"/>
1350	<xs:element name="reasonString" type="xs:string"/>
1351	<xs:element name="advSequenceNr" type="xs:unsignedInt"/>
1352	<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
1353	</xs:sequence>
1354	<xs:anyAttribute namespace="##other" processContents="lax"/>
1355	</xs:extension>
1356	</xs:complexContent>
1357	</xs:complexType>

1359	<!-- CLUE CONFIGURE MESSAGE TYPE -->
1360	<xs:complexType name="configureMessageType">
1361	<xs:complexContent>
1362	<xs:extension base="clueMessageType">
1363	<xs:sequence>
1364	<!-- mandatory fields -->
1365	<xs:element name="advSequenceNr" type="xs:unsignedInt"/>
1366	<xs:element name="ack" type="xs:boolean" minOccurs="0" fixed="true"/>
1367	<xs:element name="captureEncodings" type="dm:captureEncodingsType"
1368	 minOccurs="0"/>
1369	<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
1370	</xs:sequence>
1371	<xs:anyAttribute namespace="##other" processContents="lax"/>
1372	</xs:extension>
1373	</xs:complexContent>
1374	</xs:complexType>

1376	<!-- CONFIGURE RESPONSE MESSAGE TYPE -->
1377	<xs:complexType name="configureResponseMessageType">
1378	<xs:complexContent>
1379	<xs:extension base="clueMessageType">
1380	<xs:sequence>
1381	<xs:element name="responseCode" type="xs:short"/>
1382	<xs:element name="reasonString" type="xs:string"/>
1383	<xs:element name="confSequenceNr" type="xs:integer"/>
1384	<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
1385	</xs:sequence>
1386	<xs:anyAttribute namespace="##other" processContents="lax"/>
1387	</xs:extension>
1388	</xs:complexContent>
1389	</xs:complexType>

1391	<!-- CLUE READV MESSAGE TYPE -->
1392	<xs:complexType name="readvMessageType">
1393	<xs:complexContent>
1394	<xs:extension base="clueMessageType">
1395	<xs:sequence>
1396	<xs:element name="lastReceivedAdv" type="xs:short"/>
1397	<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
1398	</xs:sequence>
1399	<xs:anyAttribute namespace="##other" processContents="lax"/>
1400	</xs:extension>
1401	</xs:complexContent>
1402	</xs:complexType>

1404	<!-- CLUE READV RESPONSE MESSAGE TYPE -->
1405	<xs:complexType name="readvResponseMessageType">
1406	<xs:complexContent>
1407	<xs:extension base="clueMessageType">
1408	<xs:sequence>
1409	<xs:element name="responseCode" type="xs:short"/>
1410	<xs:element name="reasonString" type="xs:string"/>
1411	<xs:element name="readvSequenceNr" type="xs:string" minOccurs="0"/>
1412	<xs:element name="mediaCaptures" type="dm:mediaCapturesType" minOccurs="0"/>
1413	<xs:element name="encodingGroups" type="dm:encodingGroupsType" minOccurs="0"/>
1414	<xs:element name="captureScenes" type="dm:captureScenesType" minOccurs="0"/>
1415	<xs:element name="simultaneousSets" type="dm:simultaneousSetsType" minOccurs="0"/>
1416	<xs:element name="globalCaptureEntries" type="dm:globalCaptureEntriesType" minOccurs="0"/>
1417	<xs:element name="participants" type="dm:participantsType" minOccurs="0"/>
1418	<xs:any namespace="##other"
1419	 processContents="lax" minOccurs="0"/>
1420	</xs:sequence>
1421	</xs:extension>
1422	</xs:complexContent>
1423	</xs:complexType>

1425	</xs:schema>

1427	10.  ADVERTISEMENT examples

1429	   In the following we provide two examples of ADVERTISEMENT
1430	   representing the telepresence environment described in
1431	   [I-D.ietf-clue-data-model-schema], Section 22 "Sample XML file" and
1432	   Section 23 "MCC example" respectively.

1434	10.1.  Simple ADV

1436	   The associated Media Provider's telepresence capabilities are
1437	   described in [I-D.ietf-clue-data-model-schema], Section 22 "Sample
1438	   XML file".  The XML file can be downloaded here:
1439	   http://wpage.unina.it/spromano/CLUE/.

1441	<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
1442	<advertisement xmlns="urn:ietf:params:xml:ns:clue-message"
1443	               xmlns:ns2="urn:ietf:params:xml:ns:clue-info"
1444	               xmlns:ns3="urn:ietf:params:xml:ns:vcard-4.0"
1445	               protocol="CLUE" v="0.0">
1446	    <clueId>Napoli</clueId>
1447	    <sequenceNr>45</sequenceNr>
1448	    <mediaCaptures>
1449	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1450	         xsi:type="ns2:videoCaptureType" captureID="AC0">
1451	            <ns2:capturedMedia>audio</ns2:capturedMedia>
1452	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1453	            <ns2:encGroupIDREF>EG1</ns2:encGroupIDREF>
1454	            <ns2:spatialInformation>
1455	                <ns2:capturePoint>
1456	                    <ns2:x>0.5</ns2:x>
1457	                    <ns2:y>1.0</ns2:y>
1458	                    <ns2:z>0.5</ns2:z>
1459	                    <ns2:lineOfCapturePoint>
1460	                        <ns2:x>0.5</ns2:x>
1461	                        <ns2:y>0.0</ns2:y>
1462	                        <ns2:z>0.5</ns2:z>
1463	                    </ns2:lineOfCapturePoint>
1464	                </ns2:capturePoint>
1465	            </ns2:spatialInformation>
1466	            <ns2:individual>true</ns2:individual>
1467	            <ns2:description lang="en">main audio from the room</ns2:description>
1468	            <ns2:priority>1</ns2:priority>
1469	            <ns2:lang>it</ns2:lang>
1470	            <ns2:mobility>static</ns2:mobility>
1471	            <ns2:view>room</ns2:view>
1472	            <ns2:capturedPeople>
1473	                <ns2:personIDREF>alice</ns2:personIDREF>
1474	                <ns2:personIDREF>bob</ns2:personIDREF>
1475	                <ns2:personIDREF>ciccio</ns2:personIDREF>
1476	            </ns2:capturedPeople>
1477	            <ns2:maxCaptureEncodings>1</ns2:maxCaptureEncodings>
1478	        </ns2:mediaCapture>
1479	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1480	         xsi:type="ns2:videoCaptureType" captureID="VC0">
1481	            <ns2:capturedMedia>video</ns2:capturedMedia>
1482	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1483	            <ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
1484	            <ns2:spatialInformation>
1485	                <ns2:capturePoint>
1486	                    <ns2:x>0.5</ns2:x>
1487	                    <ns2:y>1.0</ns2:y>
1488	                    <ns2:z>0.5</ns2:z>
1489	                    <ns2:lineOfCapturePoint>
1490	                        <ns2:x>0.5</ns2:x>
1491	                        <ns2:y>0.0</ns2:y>
1492	                        <ns2:z>0.5</ns2:z>
1493	                    </ns2:lineOfCapturePoint>
1494	                </ns2:capturePoint>
1495	            </ns2:spatialInformation>
1496	            <ns2:individual>true</ns2:individual>
1497	            <ns2:description lang="en">left camera video capture
1498	            </ns2:description>
1499	            <ns2:priority>1</ns2:priority>
1500	            <ns2:lang>it</ns2:lang>
1501	            <ns2:mobility>static</ns2:mobility>
1502	            <ns2:view>individual</ns2:view>
1503	            <ns2:capturedPeople>
1504	                <ns2:personIDREF>ciccio</ns2:personIDREF>
1505	            </ns2:capturedPeople>
1506	            <ns2:maxCaptureEncodings>2</ns2:maxCaptureEncodings>
1507	        </ns2:mediaCapture>
1508	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1509	         xsi:type="ns2:videoCaptureType" captureID="VC1">
1510	            <ns2:capturedMedia>video</ns2:capturedMedia>
1511	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1512	            <ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
1513	            <ns2:spatialInformation>
1514	                <ns2:capturePoint>
1515	                    <ns2:x>0.5</ns2:x>
1516	                    <ns2:y>1.0</ns2:y>
1517	                    <ns2:z>0.5</ns2:z>
1518	                    <ns2:lineOfCapturePoint>
1519	                        <ns2:x>0.5</ns2:x>
1520	                        <ns2:y>0.0</ns2:y>
1521	                        <ns2:z>0.5</ns2:z>
1522	                    </ns2:lineOfCapturePoint>
1523	                </ns2:capturePoint>
1524	            </ns2:spatialInformation>
1525	            <ns2:individual>true</ns2:individual>
1526	            <ns2:description lang="en">central camera video capture
1527	            </ns2:description>
1528	            <ns2:priority>1</ns2:priority>
1529	            <ns2:lang>it</ns2:lang>
1530	            <ns2:mobility>static</ns2:mobility>
1531	            <ns2:view>individual</ns2:view>
1532	            <ns2:capturedPeople>
1533	                <ns2:personIDREF>alice</ns2:personIDREF>
1534	            </ns2:capturedPeople>
1535	            <ns2:maxCaptureEncodings>2</ns2:maxCaptureEncodings>
1536	        </ns2:mediaCapture>
1537	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1538	         xsi:type="ns2:videoCaptureType" captureID="VC2">
1539	            <ns2:capturedMedia>video</ns2:capturedMedia>
1540	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1541	            <ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
1542	            <ns2:spatialInformation>
1543	                <ns2:capturePoint>
1544	                    <ns2:x>0.5</ns2:x>
1545	                    <ns2:y>1.0</ns2:y>
1546	                    <ns2:z>0.5</ns2:z>
1547	                    <ns2:lineOfCapturePoint>
1548	                        <ns2:x>0.5</ns2:x>
1549	                        <ns2:y>0.0</ns2:y>
1550	                        <ns2:z>0.5</ns2:z>
1551	                    </ns2:lineOfCapturePoint>
1552	                </ns2:capturePoint>
1553	            </ns2:spatialInformation>
1554	            <ns2:individual>true</ns2:individual>
1555	            <ns2:description lang="en">right camera video capture
1556	            </ns2:description>
1557	            <ns2:priority>1</ns2:priority>
1558	            <ns2:lang>it</ns2:lang>
1559	            <ns2:mobility>static</ns2:mobility>
1560	            <ns2:view>individual</ns2:view>
1561	            <ns2:capturedPeople>
1562	                <ns2:personIDREF>bob</ns2:personIDREF>
1563	            </ns2:capturedPeople>
1564	            <ns2:maxCaptureEncodings>2</ns2:maxCaptureEncodings>
1565	        </ns2:mediaCapture>
1566	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1567	         xsi:type="ns2:videoCaptureType" captureID="VC3">
1568	            <ns2:capturedMedia>video</ns2:capturedMedia>
1569	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1570	            <ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
1571	            <ns2:nonSpatiallyDefinable>true</ns2:nonSpatiallyDefinable>
1572	            <ns2:composed>false</ns2:composed>
1573	            <ns2:switched>true</ns2:switched>
1574	            <ns2:policy>Soundlevel:0</ns2:policy>
1575	            <ns2:maxCaptures>1</ns2:maxCaptures>
1576	            <ns2:description lang="en">loudest room segment</ns2:description>
1577	            <ns2:priority>1</ns2:priority>
1578	            <ns2:lang>it</ns2:lang>
1579	            <ns2:mobility>static</ns2:mobility>
1580	            <ns2:view>individual</ns2:view>
1581	            <ns2:maxCaptureEncodings>1</ns2:maxCaptureEncodings>
1582	        </ns2:mediaCapture>
1583	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1584	         xsi:type="ns2:videoCaptureType" captureID="VC4">
1585	            <ns2:capturedMedia>video</ns2:capturedMedia>
1586	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1587	            <ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
1588	            <ns2:spatialInformation>
1589	                <ns2:capturePoint>
1590	                    <ns2:x>0.5</ns2:x>
1591	                    <ns2:y>1.0</ns2:y>
1592	                    <ns2:z>0.5</ns2:z>
1593	                    <ns2:lineOfCapturePoint>
1594	                        <ns2:x>0.5</ns2:x>
1595	                        <ns2:y>0.0</ns2:y>
1596	                        <ns2:z>0.5</ns2:z>
1597	                    </ns2:lineOfCapturePoint>
1598	                </ns2:capturePoint>
1599	            </ns2:spatialInformation>
1600	            <ns2:individual>true</ns2:individual>
1601	            <ns2:description lang="en">zoomed out view of all people in
1602	            the room
1603	            </ns2:description>
1604	            <ns2:priority>1</ns2:priority>
1605	            <ns2:lang>it</ns2:lang>
1606	            <ns2:mobility>static</ns2:mobility>
1607	            <ns2:view>room</ns2:view>
1608	            <ns2:capturedPeople>
1609	                <ns2:personIDREF>alice</ns2:personIDREF>
1610	                <ns2:personIDREF>bob</ns2:personIDREF>
1611	                <ns2:personIDREF>ciccio</ns2:personIDREF>
1612	            </ns2:capturedPeople>
1613	            <ns2:maxCaptureEncodings>1</ns2:maxCaptureEncodings>
1614	        </ns2:mediaCapture>
1615	    </mediaCaptures>
1616	    <encodingGroups>
1617	        <ns2:encodingGroup encodingGroupID="EG0">
1618	            <ns2:maxGroupBandwidth>600000</ns2:maxGroupBandwidth>
1619	            <ns2:encodingIDList>
1620	                <ns2:encID>ENC1</ns2:encID>
1621	                <ns2:encID>ENC2</ns2:encID>
1622	                <ns2:encID>ENC3</ns2:encID>
1623	            </ns2:encodingIDList>

1625	        </ns2:encodingGroup>
1626	        <ns2:encodingGroup encodingGroupID="EG1">
1627	            <ns2:maxGroupBandwidth>300000</ns2:maxGroupBandwidth>
1628	            <ns2:encodingIDList>
1629	                <ns2:encID>ENC4</ns2:encID>
1630	                <ns2:encID>ENC5</ns2:encID>
1631	            </ns2:encodingIDList>
1632	        </ns2:encodingGroup>
1633	    </encodingGroups>
1634	    <captureScenes>
1635	        <ns2:captureScene scale="unknown" sceneID="CS1">
1636	            <ns2:sceneEntries>
1637	                <ns2:sceneEntry mediaType="video" sceneEntryID="SE1">
1638	                    <ns2:mediaCaptureIDs>
1639	                        <ns2:captureIDREF>VC0</ns2:captureIDREF>
1640	                        <ns2:captureIDREF>VC1</ns2:captureIDREF>
1641	                        <ns2:captureIDREF>VC2</ns2:captureIDREF>
1642	                    </ns2:mediaCaptureIDs>
1643	                </ns2:sceneEntry>
1644	                <ns2:sceneEntry mediaType="video" sceneEntryID="SE2">
1645	                    <ns2:mediaCaptureIDs>
1646	                        <ns2:captureIDREF>VC3</ns2:captureIDREF>
1647	                    </ns2:mediaCaptureIDs>
1648	                </ns2:sceneEntry>
1649	                <ns2:sceneEntry mediaType="video" sceneEntryID="SE3">
1650	                    <ns2:mediaCaptureIDs>
1651	                        <ns2:captureIDREF>VC4</ns2:captureIDREF>
1652	                    </ns2:mediaCaptureIDs>
1653	                </ns2:sceneEntry>
1654	                <ns2:sceneEntry mediaType="audio" sceneEntryID="SE4">
1655	                    <ns2:mediaCaptureIDs>
1656	                        <ns2:captureIDREF>VC4</ns2:captureIDREF>
1657	                    </ns2:mediaCaptureIDs>
1658	                </ns2:sceneEntry>
1659	            </ns2:sceneEntries>
1660	        </ns2:captureScene>
1661	    </captureScenes>
1662	    <simultaneousSets>
1663	        <ns2:simultaneousSet setID="SS1">
1664	            <ns2:captureIDREF>VC3</ns2:captureIDREF>
1665	            <ns2:sceneEntryIDREF>SE1</ns2:sceneEntryIDREF>
1666	        </ns2:simultaneousSet>
1667	        <ns2:simultaneousSet setID="SS2">
1668	            <ns2:captureIDREF>VC0</ns2:captureIDREF>
1669	            <ns2:captureIDREF>VC2</ns2:captureIDREF>
1670	            <ns2:captureIDREF>VC4</ns2:captureIDREF>
1671	            <ns2:captureIDREF>VC3</ns2:captureIDREF>
1672	        </ns2:simultaneousSet>

1674	    </simultaneousSets>
1675	    <people>
1676	        <ns2:person personID="bob">
1677	            <ns2:personInfo>
1678	                <ns3:fn>
1679	                    <ns3:text>Bob</ns3:text>
1680	                </ns3:fn>
1681	            </ns2:personInfo>
1682	            <ns2:personType>minute taker</ns2:personType>
1683	        </ns2:person>
1684	        <ns2:person personID="alice">
1685	            <ns2:personInfo>
1686	                <ns3:fn>
1687	                    <ns3:text>Alice</ns3:text>
1688	                </ns3:fn>
1689	            </ns2:personInfo>
1690	            <ns2:personType>presenter</ns2:personType>
1691	        </ns2:person>
1692	        <ns2:person personID="ciccio">
1693	            <ns2:personInfo>
1694	                <ns3:fn>
1695	                    <ns3:text>Ciccio</ns3:text>
1696	                </ns3:fn>
1697	            </ns2:personInfo>
1698	            <ns2:personType>chairman</ns2:personType>
1699	            <ns2:personType>timekeeper</ns2:personType>
1700	        </ns2:person>
1701	    </people>
1702	</advertisement>

1704	10.2.  ADV with MCCs

1706	   The associated Media Provider's telepresence capabilities are
1707	   described in [I-D.ietf-clue-data-model-schema], Section 23 "MCC
1708	   example".  The XML file can be downloaded here:
1709	   http://wpage.unina.it/spromano/CLUE/.

1711	<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
1712	<advertisement xmlns="urn:ietf:params:xml:ns:clue-message"
1713	 xmlns:ns2="urn:ietf:params:xml:ns:clue-info"
1714	 xmlns:ns3="urn:ietf:params:xml:ns:vcard-4.0" protocol="CLUE" v="0.1">
1715	    <clueId>Napoli CLUE Endpoint</clueId>
1716	    <sequenceNr>34</sequenceNr>
1717	    <mediaCaptures>
1718	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1719	         xsi:type="ns2:videoCaptureType" captureID="AC0">
1720	            <ns2:capturedMedia>audio</ns2:capturedMedia>
1721	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1722	            <ns2:encGroupIDREF>EG1</ns2:encGroupIDREF>
1723	            <ns2:spatialInformation>
1724	                <ns2:capturePoint>
1725	                    <ns2:x>0.5</ns2:x>
1726	                    <ns2:y>1.0</ns2:y>
1727	                    <ns2:z>0.5</ns2:z>
1728	                    <ns2:lineOfCapturePoint>
1729	                        <ns2:x>0.5</ns2:x>
1730	                        <ns2:y>0.0</ns2:y>
1731	                        <ns2:z>0.5</ns2:z>
1732	                    </ns2:lineOfCapturePoint>
1733	                </ns2:capturePoint>
1734	            </ns2:spatialInformation>
1735	            <ns2:individual>true</ns2:individual>
1736	            <ns2:description lang="en">main audio from the room</ns2:description>
1737	            <ns2:priority>1</ns2:priority>
1738	            <ns2:lang>it</ns2:lang>
1739	            <ns2:mobility>static</ns2:mobility>
1740	            <ns2:view>room</ns2:view>
1741	            <ns2:capturedPeople>
1742	                <ns2:personIDREF>alice</ns2:personIDREF>
1743	                <ns2:personIDREF>bob</ns2:personIDREF>
1744	                <ns2:personIDREF>ciccio</ns2:personIDREF>
1745	            </ns2:capturedPeople>
1746	            <ns2:maxCaptureEncodings>1</ns2:maxCaptureEncodings>
1747	        </ns2:mediaCapture>
1748	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1749	         xsi:type="ns2:videoCaptureType" captureID="VC0">
1750	            <ns2:capturedMedia>video</ns2:capturedMedia>
1751	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1752	            <ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
1753	            <ns2:spatialInformation>
1754	                <ns2:capturePoint>
1755	                    <ns2:x>0.5</ns2:x>
1756	                    <ns2:y>1.0</ns2:y>
1757	                    <ns2:z>0.5</ns2:z>
1758	                    <ns2:lineOfCapturePoint>
1759	                        <ns2:x>0.5</ns2:x>
1760	                        <ns2:y>0.0</ns2:y>
1761	                        <ns2:z>0.5</ns2:z>
1762	                    </ns2:lineOfCapturePoint>
1763	                </ns2:capturePoint>
1764	            </ns2:spatialInformation>
1765	            <ns2:individual>true</ns2:individual>
1766	            <ns2:description lang="en">left camera video capture</ns2:description>
1767	            <ns2:priority>1</ns2:priority>
1768	            <ns2:lang>it</ns2:lang>
1769	            <ns2:mobility>static</ns2:mobility>
1770	            <ns2:view>individual</ns2:view>
1771	            <ns2:capturedPeople>
1772	                <ns2:personIDREF>ciccio</ns2:personIDREF>
1773	            </ns2:capturedPeople>
1774	            <ns2:maxCaptureEncodings>2</ns2:maxCaptureEncodings>
1775	        </ns2:mediaCapture>
1776	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1777	        xsi:type="ns2:videoCaptureType" captureID="VC1">
1778	            <ns2:capturedMedia>video</ns2:capturedMedia>
1779	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1780	            <ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
1781	            <ns2:spatialInformation>
1782	                <ns2:capturePoint>
1783	                    <ns2:x>0.5</ns2:x>
1784	                    <ns2:y>1.0</ns2:y>
1785	                    <ns2:z>0.5</ns2:z>
1786	                    <ns2:lineOfCapturePoint>
1787	                        <ns2:x>0.5</ns2:x>
1788	                        <ns2:y>0.0</ns2:y>
1789	                        <ns2:z>0.5</ns2:z>
1790	                    </ns2:lineOfCapturePoint>
1791	                </ns2:capturePoint>
1792	            </ns2:spatialInformation>
1793	            <ns2:individual>true</ns2:individual>
1794	            <ns2:description lang="en">central camera video capture
1795	            </ns2:description>
1796	            <ns2:priority>1</ns2:priority>
1797	            <ns2:lang>it</ns2:lang>
1798	            <ns2:mobility>static</ns2:mobility>
1799	            <ns2:view>individual</ns2:view>
1800	            <ns2:capturedPeople>
1801	                <ns2:personIDREF>alice</ns2:personIDREF>
1802	            </ns2:capturedPeople>
1803	            <ns2:maxCaptureEncodings>2</ns2:maxCaptureEncodings>
1804	        </ns2:mediaCapture>
1805	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1806	        xsi:type="ns2:videoCaptureType" captureID="VC2">
1807	            <ns2:capturedMedia>video</ns2:capturedMedia>
1808	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1809	            <ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
1810	            <ns2:spatialInformation>
1811	                <ns2:capturePoint>
1812	                    <ns2:x>0.5</ns2:x>
1813	                    <ns2:y>1.0</ns2:y>
1814	                    <ns2:z>0.5</ns2:z>
1815	                    <ns2:lineOfCapturePoint>
1816	                        <ns2:x>0.5</ns2:x>
1817	                        <ns2:y>0.0</ns2:y>
1818	                        <ns2:z>0.5</ns2:z>
1819	                    </ns2:lineOfCapturePoint>
1820	                </ns2:capturePoint>
1821	            </ns2:spatialInformation>
1822	            <ns2:individual>true</ns2:individual>
1823	            <ns2:description lang="en">right camera video capture
1824	            </ns2:description>
1825	            <ns2:priority>1</ns2:priority>
1826	            <ns2:lang>it</ns2:lang>
1827	            <ns2:mobility>static</ns2:mobility>
1828	            <ns2:view>individual</ns2:view>
1829	            <ns2:capturedPeople>
1830	                <ns2:personIDREF>bob</ns2:personIDREF>
1831	            </ns2:capturedPeople>
1832	            <ns2:maxCaptureEncodings>2</ns2:maxCaptureEncodings>
1833	        </ns2:mediaCapture>
1834	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1835	        xsi:type="ns2:videoCaptureType" captureID="VC3">
1836	            <ns2:capturedMedia>video</ns2:capturedMedia>
1837	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1838	            <ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
1839	            <ns2:nonSpatiallyDefinable>true</ns2:nonSpatiallyDefinable>
1840	            <ns2:content>
1841	                <ns2:sceneEntryIDREF>SE1</ns2:sceneEntryIDREF>
1842	            </ns2:content>
1843	            <ns2:composed>false</ns2:composed>
1844	            <ns2:switched>true</ns2:switched>
1845	            <ns2:policy>Soundlevel:0</ns2:policy>
1846	            <ns2:maxCaptures>1</ns2:maxCaptures>
1847	            <ns2:description lang="en">loudest room segment</ns2:description>
1848	            <ns2:priority>1</ns2:priority>
1849	            <ns2:lang>it</ns2:lang>
1850	            <ns2:mobility>static</ns2:mobility>
1851	            <ns2:view>individual</ns2:view>
1852	            <ns2:maxCaptureEncodings>1</ns2:maxCaptureEncodings>
1853	        </ns2:mediaCapture>
1854	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1855	        xsi:type="ns2:videoCaptureType" captureID="VC4">
1856	            <ns2:capturedMedia>video</ns2:capturedMedia>
1857	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1858	            <ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
1859	            <ns2:spatialInformation>
1860	                <ns2:capturePoint>
1861	                    <ns2:x>0.5</ns2:x>
1862	                    <ns2:y>1.0</ns2:y>
1863	                    <ns2:z>0.5</ns2:z>
1864	                    <ns2:lineOfCapturePoint>
1865	                        <ns2:x>0.5</ns2:x>
1866	                        <ns2:y>0.0</ns2:y>
1867	                        <ns2:z>0.5</ns2:z>
1868	                    </ns2:lineOfCapturePoint>
1869	                </ns2:capturePoint>
1870	            </ns2:spatialInformation>
1871	            <ns2:individual>true</ns2:individual>
1872	            <ns2:description lang="en">zoomed out view of all people in the room
1873	            </ns2:description>
1874	            <ns2:priority>1</ns2:priority>
1875	            <ns2:lang>it</ns2:lang>
1876	            <ns2:mobility>static</ns2:mobility>
1877	            <ns2:view>room</ns2:view>
1878	            <ns2:capturedPeople>
1879	                <ns2:personIDREF>alice</ns2:personIDREF>
1880	                <ns2:personIDREF>bob</ns2:personIDREF>
1881	                <ns2:personIDREF>ciccio</ns2:personIDREF>
1882	            </ns2:capturedPeople>
1883	            <ns2:maxCaptureEncodings>1</ns2:maxCaptureEncodings>
1884	        </ns2:mediaCapture>
1885	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1886	        xsi:type="ns2:videoCaptureType" captureID="VC5">
1887	            <ns2:capturedMedia>video</ns2:capturedMedia>
1888	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1889	            <ns2:nonSpatiallyDefinable>true</ns2:nonSpatiallyDefinable>
1890	            <ns2:content>
1891	                <ns2:sceneEntryIDREF>SE1</ns2:sceneEntryIDREF>
1892	            </ns2:content>
1893	            <ns2:composed>false</ns2:composed>
1894	            <ns2:switched>true</ns2:switched>
1895	            <ns2:policy>Soundlevel:1</ns2:policy>
1896	            <ns2:maxCaptures>1</ns2:maxCaptures>
1897	            <ns2:description lang="en">penultimate loudest room segment
1898	            </ns2:description>
1899	            <ns2:priority>1</ns2:priority>
1900	            <ns2:lang>it</ns2:lang>
1901	            <ns2:mobility>static</ns2:mobility>
1902	            <ns2:view>individual</ns2:view>
1903	            <ns2:maxCaptureEncodings>1</ns2:maxCaptureEncodings>
1904	        </ns2:mediaCapture>
1905	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1906	        xsi:type="ns2:videoCaptureType" captureID="VC6">
1907	            <ns2:capturedMedia>video</ns2:capturedMedia>
1908	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1909	            <ns2:nonSpatiallyDefinable>true</ns2:nonSpatiallyDefinable>
1910	            <ns2:content>
1911	                <ns2:sceneEntryIDREF>SE1</ns2:sceneEntryIDREF>
1912	            </ns2:content>
1913	            <ns2:composed>false</ns2:composed>
1914	            <ns2:switched>true</ns2:switched>
1915	            <ns2:policy>Soundlevel:2</ns2:policy>
1916	            <ns2:maxCaptures>1</ns2:maxCaptures>
1917	            <ns2:description lang="en">last but two loudest room segment
1918	            </ns2:description>
1919	            <ns2:priority>1</ns2:priority>
1920	            <ns2:lang>it</ns2:lang>
1921	            <ns2:mobility>static</ns2:mobility>
1922	            <ns2:view>individual</ns2:view>
1923	            <ns2:maxCaptureEncodings>1</ns2:maxCaptureEncodings>
1924	        </ns2:mediaCapture>
1925	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1926	        xsi:type="ns2:videoCaptureType" captureID="VC7">
1927	            <ns2:capturedMedia>video</ns2:capturedMedia>
1928	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1929	            <ns2:nonSpatiallyDefinable>true</ns2:nonSpatiallyDefinable>
1930	            <ns2:content>
1931	                <ns2:captureIDREF>VC3</ns2:captureIDREF>
1932	                <ns2:captureIDREF>VC5</ns2:captureIDREF>
1933	                <ns2:captureIDREF>VC6</ns2:captureIDREF>
1934	            </ns2:content>
1935	            <ns2:composed>true</ns2:composed>
1936	            <ns2:switched>true</ns2:switched>
1937	            <ns2:maxCaptures>1</ns2:maxCaptures>
1938	            <ns2:description lang="en">big picture of the current speaker +
1939	            pips about previous speakers</ns2:description>
1940	            <ns2:priority>1</ns2:priority>
1941	            <ns2:lang>it</ns2:lang>
1942	            <ns2:mobility>static</ns2:mobility>
1943	            <ns2:view>individual</ns2:view>
1944	            <ns2:maxCaptureEncodings>1</ns2:maxCaptureEncodings>
1945	        </ns2:mediaCapture>
1946	    </mediaCaptures>
1947	    <encodingGroups>
1948	        <ns2:encodingGroup encodingGroupID="EG0">
1949	            <ns2:maxGroupBandwidth>600000</ns2:maxGroupBandwidth>
1950	            <ns2:encodingIDList>
1951	                <ns2:encID>ENC1</ns2:encID>
1952	                <ns2:encID>ENC2</ns2:encID>
1953	                <ns2:encID>ENC3</ns2:encID>
1954	            </ns2:encodingIDList>
1955	        </ns2:encodingGroup>
1956	        <ns2:encodingGroup encodingGroupID="EG1">
1957	            <ns2:maxGroupBandwidth>300000</ns2:maxGroupBandwidth>
1958	            <ns2:encodingIDList>
1959	                <ns2:encID>ENC4</ns2:encID>
1960	                <ns2:encID>ENC5</ns2:encID>
1961	            </ns2:encodingIDList>
1962	        </ns2:encodingGroup>
1963	    </encodingGroups>
1964	    <captureScenes>
1965	        <ns2:captureScene scale="unknown" sceneID="CS1">
1966	            <ns2:sceneEntries>
1967	                <ns2:sceneEntry mediaType="video" sceneEntryID="SE1">
1968	                    <ns2:description lang="en">participants' individual videos
1969	                    </ns2:description>
1970	                    <ns2:mediaCaptureIDs>
1971	                        <ns2:captureIDREF>VC0</ns2:captureIDREF>
1972	                        <ns2:captureIDREF>VC1</ns2:captureIDREF>
1973	                        <ns2:captureIDREF>VC2</ns2:captureIDREF>
1974	                    </ns2:mediaCaptureIDs>
1975	                </ns2:sceneEntry>
1976	                <ns2:sceneEntry mediaType="video" sceneEntryID="SE2">
1977	                    <ns2:description lang="en">loudest segment of the room
1978	                    </ns2:description>
1979	                    <ns2:mediaCaptureIDs>
1980	                        <ns2:captureIDREF>VC3</ns2:captureIDREF>
1981	                    </ns2:mediaCaptureIDs>
1982	                </ns2:sceneEntry>
1983	                <ns2:sceneEntry mediaType="video" sceneEntryID="SE5">
1984	                    <ns2:description lang="en">loudest segment
1985	                    of the room + pips</ns2:description>
1986	                    <ns2:mediaCaptureIDs>
1987	                        <ns2:captureIDREF>VC7</ns2:captureIDREF>
1988	                    </ns2:mediaCaptureIDs>
1989	                </ns2:sceneEntry>
1990	                <ns2:sceneEntry mediaType="audio" sceneEntryID="SE4">
1991	                    <ns2:description lang="en">room audio</ns2:description>
1992	                    <ns2:mediaCaptureIDs>
1993	                        <ns2:captureIDREF>AC0</ns2:captureIDREF>
1994	                    </ns2:mediaCaptureIDs>
1995	                </ns2:sceneEntry>
1996	                <ns2:sceneEntry mediaType="video" sceneEntryID="SE3">
1997	                    <ns2:description lang="en">room video</ns2:description>
1998	                    <ns2:mediaCaptureIDs>
1999	                        <ns2:captureIDREF>VC4</ns2:captureIDREF>
2000	                    </ns2:mediaCaptureIDs>
2001	                </ns2:sceneEntry>
2002	            </ns2:sceneEntries>
2003	        </ns2:captureScene>
2004	    </captureScenes>
2005	    <simultaneousSets>
2006	        <ns2:simultaneousSet setID="SS1">
2007	            <ns2:captureIDREF>VC7</ns2:captureIDREF>
2008	            <ns2:sceneEntryIDREF>SE1</ns2:sceneEntryIDREF>
2009	        </ns2:simultaneousSet>
2010	        <ns2:simultaneousSet setID="SS2">
2011	            <ns2:captureIDREF>VC0</ns2:captureIDREF>
2012	            <ns2:captureIDREF>VC2</ns2:captureIDREF>
2013	            <ns2:captureIDREF>VC4</ns2:captureIDREF>
2014	            <ns2:captureIDREF>VC7</ns2:captureIDREF>
2015	        </ns2:simultaneousSet>
2016	    </simultaneousSets>
2017	    <people>
2018	        <ns2:person personID="bob">
2019	            <ns2:personInfo>
2020	                <ns3:fn>
2021	                    <ns3:text>Bob</ns3:text>
2022	                </ns3:fn>
2023	            </ns2:personInfo>
2024	            <ns2:personType>minute taker</ns2:personType>
2025	        </ns2:person>
2026	        <ns2:person personID="alice">
2027	            <ns2:personInfo>
2028	                <ns3:fn>
2029	                    <ns3:text>Alice</ns3:text>
2030	                </ns3:fn>
2031	            </ns2:personInfo>
2032	            <ns2:personType>presenter</ns2:personType>
2033	        </ns2:person>
2034	        <ns2:person personID="ciccio">
2035	            <ns2:personInfo>
2036	                <ns3:fn>
2037	                    <ns3:text>Ciccio</ns3:text>
2038	                </ns3:fn>
2039	            </ns2:personInfo>
2040	            <ns2:personType>chairman</ns2:personType>
2041	            <ns2:personType>timekeeper</ns2:personType>
2042	        </ns2:person>
2043	    </people>
2044	</advertisement>

2046	11.  Diff with draft-ietf-clue-protocol-00

2048	   1.  The XML schema of the ADVERTISEMENT and of the READV have been
2049	       aligned with the current definitions in
2050	       [I-D.ietf-clue-data-model-schema] (example of updates:
2051	       <participants> --> <people>, <globalCaptureEntries> -->
2052	       <globalSceneEntries>)

2054	   2.  Text has been added to clarify that, in the OPTIONS RESPONSE,
2055	       when the response code is not an error response code, both
2056	       <mediaProvider> and <mediaConsumer> are mandatory.

2058	   3.  The content of the "v" attribute and of the <version> elements
2059	       carried in the OPTIONS and OPTIONS RESPONSE messages has been
2060	       described more precisely.

2062	   4.  Advertisement examples have been added.

2064	12.  Diff with draft-presta-clue-protocol-04

2066	   1.  The response code type error in the OPTIONS response (and in
2067	       other parts) has been corrected.

2069	13.  Diff with draft-presta-clue-protocol-03

2071	   1.  The XML Schema has been deeply revised and completed.

2073	   2.  The descriptions of the CLUE messages have been added.

2075	   3.  The distinction between major version numbers and minor version
2076	       numbers has been cut and pasted from
2077	       [I-D.kyzivat-clue-signaling].

2079	   4.  Besides the two way one, a three way mechanism for the options
2080	       negotiation has been proposed and provided to foster discussion.

2082	14.  Diff with draft-presta-clue-protocol-02

2084	   1.  "Terminology" section added.

2086	   2.  Introduced the concept of "CLUE Participant" - an Endpoint or a
2087	       MCU able to use the CLUE protocol within a telepresence session.
2088	       A CLUE Participant can act as a Media Provider and/or as a Media
2089	       Consumer.

2091	   3.  Introduced the ACK/NACK mechanism for the ADVERTISEMENT.

2093	   4.  MP and MC state machines have been updated.  The CP state machine
2094	       has been added.

2096	15.  Acknowledgments

2098	   The authors thank all the CLUErs for their precious feedbacks and
2099	   support, in particular Paul Kyzivat, Christian Groves and Scarlett
2100	   Liuyan.

2102	16.  Informative References

2104	   [I-D.ietf-clue-data-model-schema]          Presta, R. and S. Romano,
2105	                                              "An XML Schema for the
2106	                                              CLUE data model", draft-
2107	                                              ietf-clue-data-model-
2108	                                              schema-05 (work in
2109	                                              progress), June 2014.

2111	   [I-D.ietf-clue-datachannel]                Holmberg, C., "CLUE
2112	                                              Protocol Data Channel", dr
2113	                                              aft-ietf-clue-datachannel-
2114	                                              00 (work in progress),
2115	                                              March 2014.

2117	   [I-D.ietf-clue-framework]                  Duckworth, M., Pepperell,
2118	                                              A., and S. Wenger,
2119	                                              "Framework for
2120	                                              Telepresence Multi-
2121	                                              Streams", draft-ietf-clue-
2122	                                              framework-15 (work in
2123	                                              progress), May 2014.

2125	   [I-D.ietf-clue-telepresence-requirements]  Romanow, A., Botzko, S.,
2126	                                              and M. Barnes,
2127	                                              "Requirements for
2128	                                              Telepresence Multi-
2129	                                              Streams", draft-ietf-clue-
2130	                                              telepresence-requirements-
2131	                                              07 (work in progress),
2132	                                              December 2013.

2134	   [I-D.kyzivat-clue-signaling]               Kyzivat, P., Xiao, L.,
2135	                                              Groves, C., and R. Hansen,
2136	                                              "CLUE Signaling", draft-
2137	                                              kyzivat-clue-signaling-08
2138	                                              (work in progress),
2139	                                              April 2014.

2141	   [RFC3550]                                  Schulzrinne, H., Casner,
2142	                                              S., Frederick, R., and V.
2143	                                              Jacobson, "RTP: A
2144	                                              Transport Protocol for
2145	                                              Real-Time Applications",
2146	                                              STD 64, RFC 3550,
2147	                                              July 2003.

2149	   [RFC4353]                                  Rosenberg, J., "A
2150	                                              Framework for Conferencing
2151	                                              with the Session
2152	                                              Initiation Protocol
2153	                                              (SIP)", RFC 4353,
2154	                                              February 2006.

2156	   [RFC5117]                                  Westerlund, M. and S.
2157	                                              Wenger, "RTP Topologies",
2158	                                              RFC 5117, January 2008.

2160	   [RFC5261]                                  Urpalainen, J., "An
2161	                                              Extensible Markup Language
2162	                                              (XML) Patch Operations
2163	                                              Framework Utilizing XML
2164	                                              Path Language (XPath)
2165	                                              Selectors", RFC 5261,
2166	                                              September 2008.

2168	   [RFC6502]                                  Camarillo, G., Srinivasan,
2169	                                              S., Even, R., and J.
2170	                                              Urpalainen, "Conference
2171	                                              Event Package Data Format
2172	                                              Extension for Centralized
2173	                                              Conferencing (XCON)",
2174	                                              RFC 6502, March 2012.

2176	   [RFC6503]                                  Barnes, M., Boulton, C.,
2177	                                              Romano, S., and H.
2178	                                              Schulzrinne, "Centralized
2179	                                              Conferencing Manipulation
2180	                                              Protocol", RFC 6503,
2181	                                              March 2012.

2183	Authors' Addresses

2185	   Roberta Presta
2186	   University of Napoli
2187	   Via Claudio 21
2188	   Napoli  80125
2189	   Italy

2191	   EMail: roberta.presta@unina.it
2192	   Simon Pietro Romano
2193	   University of Napoli
2194	   Via Claudio 21
2195	   Napoli  80125
2196	   Italy

2198	   EMail: spromano@unina.it