idnits 2.17.1
draft-ietf-clue-protocol-17.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 :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (September 21, 2018) is 2037 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)
== Missing Reference: '1-9' is mentioned on line 1357, but not defined
== Missing Reference: '0-9' is mentioned on line 1363, but not defined
== Unused Reference: 'RFC7667' is defined on line 2987, but no explicit
reference was found in the text
== Outdated reference: A later version (-18) exists of
draft-ietf-clue-datachannel-15
** Downref: Normative reference to an Experimental draft:
draft-ietf-clue-datachannel (ref. 'I-D.ietf-clue-datachannel')
== Outdated reference: A later version (-15) exists of
draft-ietf-clue-signaling-13
** Downref: Normative reference to an Experimental draft:
draft-ietf-clue-signaling (ref. 'I-D.ietf-clue-signaling')
-- Obsolete informational reference (is this intentional?): RFC 5117
(Obsoleted by RFC 7667)
Summary: 2 errors (**), 0 flaws (~~), 6 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. P. Romano
4 Intended status: Standards Track University of Napoli
5 Expires: March 25, 2019 September 21, 2018
7 Protocol for Controlling Multiple Streams for Telepresence (CLUE)
8 draft-ietf-clue-protocol-17
10 Abstract
12 The CLUE protocol is an application protocol conceived for the
13 description and negotiation of a telepresence session. The design of
14 the CLUE protocol takes into account the requirements and the
15 framework defined within the IETF CLUE working group. A companion
16 document delves into CLUE signaling details, as well as on the SIP/
17 SDP session establishment phase. CLUE messages flow over the CLUE
18 data channel, based on reliable and ordered SCTP over DTLS transport.
19 Message details, together with the behavior of CLUE Participants
20 acting as Media Providers and/or Media Consumers, are herein
21 discussed.
23 Status of This Memo
25 This Internet-Draft is submitted in full conformance with the
26 provisions of BCP 78 and BCP 79.
28 Internet-Drafts are working documents of the Internet Engineering
29 Task Force (IETF). Note that other groups may also distribute
30 working documents as Internet-Drafts. The list of current Internet-
31 Drafts is at https://datatracker.ietf.org/drafts/current/.
33 Internet-Drafts are draft documents valid for a maximum of six months
34 and may be updated, replaced, or obsoleted by other documents at any
35 time. It is inappropriate to use Internet-Drafts as reference
36 material or to cite them other than as "work in progress."
38 This Internet-Draft will expire on March 25, 2019.
40 Copyright Notice
42 Copyright (c) 2018 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (https://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the Simplified BSD License.
55 Table of Contents
57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
59 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
60 4. Overview of the CLUE protocol . . . . . . . . . . . . . . . . 4
61 5. Protocol messages . . . . . . . . . . . . . . . . . . . . . . 7
62 5.1. options . . . . . . . . . . . . . . . . . . . . . . . . . 9
63 5.2. optionsResponse . . . . . . . . . . . . . . . . . . . . . 11
64 5.3. advertisement . . . . . . . . . . . . . . . . . . . . . . 12
65 5.4. ack . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
66 5.5. configure . . . . . . . . . . . . . . . . . . . . . . . . 14
67 5.6. configureResponse . . . . . . . . . . . . . . . . . . . . 15
68 5.7. Response codes and reason strings . . . . . . . . . . . . 16
69 6. Protocol state machines . . . . . . . . . . . . . . . . . . . 18
70 6.1. Media Provider's state machine . . . . . . . . . . . . . 21
71 6.2. Media Consumer's state machine . . . . . . . . . . . . . 22
72 7. Versioning . . . . . . . . . . . . . . . . . . . . . . . . . 25
73 8. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 25
74 8.1. Extension example . . . . . . . . . . . . . . . . . . . . 27
75 9. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 29
76 10. Call flow example . . . . . . . . . . . . . . . . . . . . . . 34
77 10.1. CLUE message nr. 1: 'option' . . . . . . . . . . . . . . 37
78 10.2. CLUE message nr. 2: 'optionResponse' . . . . . . . . . . 39
79 10.3. CLUE message nr. 3: 'advertisement' . . . . . . . . . . 39
80 10.4. CLUE message nr. 4: 'configure + ack' . . . . . . . . . 47
81 10.5. CLUE message nr. 5: 'confResponse' . . . . . . . . . . . 47
82 10.6. CLUE message nr. 6: 'advertisement' . . . . . . . . . . 48
83 10.7. CLUE message nr. 7: 'ack' . . . . . . . . . . . . . . . 58
84 10.8. CLUE message nr. 8: 'configure' . . . . . . . . . . . . 58
85 10.9. CLUE message nr. 9: 'confResponse' . . . . . . . . . . . 59
86 11. Security Considerations . . . . . . . . . . . . . . . . . . . 60
87 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
88 12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 61
89 12.2. XML Schema registration . . . . . . . . . . . . . . . . 62
90 12.3. MIME Media Type Registration for 'application/clue+xml' 62
91 12.4. CLUE Protocol Registry . . . . . . . . . . . . . . . . . 63
92 12.4.1. CLUE Message Types . . . . . . . . . . . . . . . . . 63
93 12.4.2. CLUE Response Codes . . . . . . . . . . . . . . . . 64
94 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 66
95 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 66
96 14.1. Normative References . . . . . . . . . . . . . . . . . . 66
97 14.2. Informative References . . . . . . . . . . . . . . . . . 67
98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67
100 1. Introduction
102 The CLUE protocol is an application protocol used by two CLUE
103 Participants to enhance the experience of a multimedia telepresence
104 session. The main goals of the CLUE protocol are:
106 1. enabling a Media Provider (MP) to properly announce its current
107 telepresence capabilities to a Media Consumer (MC) in terms of
108 available media captures, groups of encodings, simultaneity
109 constraints and other information defined in
110 [I-D.ietf-clue-framework];
112 2. enabling an MC to request the desired multimedia streams from the
113 offering MP.
115 CLUE-capable endpoints are connected by means of the CLUE data
116 channel, an SCTP over DTLS channel which is opened and established as
117 described in [I-D.ietf-clue-signaling] and
118 [I-D.ietf-clue-datachannel]. CLUE protocol messages flowing over
119 such a channel are detailed in this document, both syntactically and
120 semantically.
122 In Section 4 we provide a general overview of the CLUE protocol.
123 CLUE protocol messages are detailed in Section 5. The CLUE Protocol
124 state machines are introduced in Section 6. Versioning and
125 extensions are discussed in Section 7 and Section 8, respectively.
126 The XML schema defining the CLUE messages is reported in Section 9.
128 2. Terminology
130 This document refers to the same terminology used in
131 [I-D.ietf-clue-framework] and in [RFC7262]. We briefly recall herein
132 some of the main terms used in the document. The definition of "CLUE
133 Participant" herein proposed is not imported from any of the above
134 documents.
136 Capture Encoding: A specific encoding of a Media Capture, to be sent
137 via RTP [RFC3550].
139 CLUE Participant (CP): An entity able to use the CLUE protocol
140 within a telepresence session. It can be an endpoint or an MCU
141 able to use the CLUE protocol.
143 CLUE-capable device: A device that supports the CLUE data channel
144 [I-D.ietf-clue-datachannel], the CLUE protocol and the principles
145 of CLUE negotiation, and seeks CLUE-enabled calls.
147 Endpoint: A CLUE-capable device which is the logical point of final
148 termination through receiving, decoding and rendering, and/or
149 initiation through capturing, encoding, and sending of media
150 streams. An endpoint consists of one or more physical devices
151 which source and sink media streams, and exactly one [RFC4353]
152 Participant (which, in turn, includes exactly one SIP User Agent).
153 Endpoints can be anything from multiscreen/multicamera rooms to
154 handheld devices.
156 MCU: a CLUE-capable device that connects two or more endpoints
157 together into one single multimedia conference [RFC5117]. An MCU
158 includes an [RFC4353]-like Mixer, without the [RFC4353]
159 requirement to send media to each participant.
161 Media: Any data that, after suitable encoding, can be conveyed over
162 RTP, including audio, video or timed text.
164 Media Capture: a source of Media, such as from one or more Capture
165 Devices or constructed from other Media streams.
167 Media Consumer (MC): A CLUE Participant (i.e., an Endpoint or an
168 MCU) able to receive Capture Encodings.
170 Media Provider (MP): A CLUE Participant (i.e., an Endpoint or an
171 MCU) able to send Capture Encodings.
173 Stream: a Capture Encoding sent from a Media Provider to a Media
174 Consumer via RTP [RFC3550].
176 3. Conventions
178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
180 "OPTIONAL" in this document are to be interpreted as described in BCP
181 14 [RFC2119] [RFC8174] when, and only when, they appear in all
182 capitals, as shown here.
184 4. Overview of the CLUE protocol
186 The CLUE protocol is conceived to enable CLUE telepresence sessions.
187 It is designed in order to address SDP limitations in terms of the
188 description of some information about the multimedia streams that are
189 involved in a real-time multimedia conference. Indeed, by simply
190 using SDP it is not possible to convey information about the features
191 of the flowing multimedia streams that are needed to enable a "being
192 there" rendering experience. Such information is contained in the
193 CLUE framework document [I-D.ietf-clue-framework] and formally
194 defined and described in the CLUE data model document
195 [I-D.ietf-clue-data-model-schema]. The CLUE protocol represents the
196 mechanism for the exchange of telepresence information between CLUE
197 Participants. It mainly provides the messages to enable a Media
198 Provider to advertise its telepresence capabilities and to enable a
199 Media Consumer to select the desired telepresence options.
201 The CLUE protocol, as defined in the following, is a stateful,
202 client-server, XML-based application protocol. CLUE protocol
203 messages flow on a reliable and ordered SCTP over DTLS transport
204 channel connecting two CLUE Participants. Messages carry information
205 taken from the XML-based CLUE data model
206 ([I-D.ietf-clue-data-model-schema]). Three main communication phases
207 can be identified:
209 1. Establishment of the CLUE data channel: in this phase, the CLUE
210 data channel setup takes place. If it completes successfully,
211 the CPs are able to communicate and start the initiation phase.
213 2. Negotiation of the CLUE protocol version and extensions
214 (initiation phase): the CPs connected via the CLUE data channel
215 agree on the version and on the extensions to be used during the
216 telepresence session. Special CLUE messages are used for such a
217 task ('options' and 'optionsResponse'). The version and
218 extensions negotiation can be performed once during the CLUE
219 session and only at this stage. At the end of that basic
220 negotiation, each CP starts its activity as a CLUE MP and/or CLUE
221 MC.
223 3. CLUE telepresence capabilities description and negotiation: in
224 this phase, the MP-MC dialogues take place on the data channel by
225 means of the CLUE protocol messages.
227 As soon as the channel is ready, the CLUE Participants must agree on
228 the protocol version and extensions to be used within the
229 telepresence session. CLUE protocol version numbers are
230 characterized by a major version number (single digit) and a minor
231 version number (single digit), both unsigned integers, separated by a
232 dot. While minor version numbers denote backward compatible changes
233 in the context of a given major version, different major version
234 numbers generally indicate a lack of interoperability between the
235 protocol implementations. In order to correctly establish a CLUE
236 dialogue, the involved CPs MUST have in common a major version number
237 (see Section 7 for further details). The subset of the extensions
238 that are allowed within the CLUE session is also determined in the
239 initiation phase, such subset being the one including only the
240 extensions that are supported by both parties. A mechanism for the
241 negotiation of the CLUE protocol version and extensions is part of
242 the initiation phase. According to such a solution, the CP which is
243 the CLUE Channel Initiator (CI) issues a proper CLUE message
244 ('options') to the CP which is the Channel Receiver (CR) specifying
245 the supported version and extensions. The CR then answers by
246 selecting the subset of the CI extensions that it is able to support
247 and determines the protocol version to be used.
249 After the negotiation phase is completed, CLUE Participants describe
250 and agree on the media flows to be exchanged. In many cases CPs will
251 seek to both transmit and receive media. Hence in a call between two
252 CPs, A and B, there would be two separate dialogs, as follows:
254 1. the one needed to describe and set up the media streams sent from
255 A to B, i.e., the dialogue between A's Media Provider side and
256 B's Media Consumer side
258 2. the one needed to describe and set up the media streams sent from
259 B to A, i.e., the dialogue between B's Media Provider side and
260 A's Media Consumer side
262 CLUE messages for the media session description and negotiation are
263 designed by considering the MP side as the server side of the
264 protocol, since it produces and provides media streams, and the MC
265 side as the client side of the protocol, since it requests and
266 receives media streams. The messages that are exchanged to set up
267 the telepresence media session are described by focusing on a single
268 MP-MC dialogue.
270 The MP first advertises its available media captures and encoding
271 capabilities to the MC, as well as its simultaneity constraints,
272 according to the information model defined in
273 [I-D.ietf-clue-framework]. The CLUE message conveying the MP's
274 multimedia offer is the 'advertisement' message. Such message
275 leverages the XML data model definitions provided in
276 [I-D.ietf-clue-data-model-schema].
278 The MC selects the desired streams of the MP by using the 'configure'
279 message, which makes reference to the information carried in the
280 previously received 'advertisement'.
282 Besides 'advertisement' and 'configure', other messages have been
283 conceived in order to provide all the needed mechanisms and
284 operations. Such messages are detailed in the following sections.
286 5. Protocol messages
288 CLUE protocol messages are textual, XML-based messages that enable
289 the configuration of the telepresence session. The formal definition
290 of such messages is provided in the XML Schema provided at the end of
291 this document (Section 9). This section includes non-normative
292 excerpts of the schema to aid in describing it.
294 The XML definitions of the CLUE information provided in
295 [I-D.ietf-clue-data-model-schema] are included within some CLUE
296 protocol messages (namely the 'advertisement' and the 'configure'
297 messages), in order to use the concepts defined in
298 [I-D.ietf-clue-framework].
300 The CLUE protocol messages are the following:
302 o options
304 o optionsResponse
306 o advertisement
308 o ack
310 o configure
312 o configureResponse
314 While the 'options' and 'optionsResponse' messages are exchanged in
315 the initiation phase between the CPs, the other messages are involved
316 in MP-MC dialogues.
318 Each CLUE message inherits a basic structure depicted in the
319 following excerpt (Figure 1):
321
322
323
324
325
326
328
329
331
332
333
334
335
336
338 Figure 1: Structure of a CLUE message
340 The information contained in each CLUE message is:
342 o clueId: an optional XML element containing the identifier (in the
343 form of a generic string) of the CP within the telepresence
344 system;
346 o sequenceNr: an XML element containing the local message sequence
347 number. The sender must increment the sequence numbers by one for
348 each new message sent, the receiver must remember the most recent
349 sequence number received and send back a 402 error if it receives
350 a message with an unexpected sequence number (e.g., sequence
351 number gap, repeated sequence number, sequence number too small).
352 The initial sequence number can be chosen randomly by each party;
354 o protocol: a mandatory attribute set to "CLUE", identifying the
355 procotol the messages refer to;
357 o v: a mandatory attribute carrying the version of the protocol.
358 The content of the "v" attribute is composed by the major version
359 number followed by a dot and then by the minor version number of
360 the CLUE protocol in use. The major number cannot be "0" and, if
361 it is more than one digit, it cannot start with a "0". Allowed
362 values are of this kind are, e.g., "1.3", "2.0", "20.44" etc.
363 This document describes version 1.0.
365 Each CP is responsible for creating and updating up to three
366 independent streams of sequence numbers in messages it sends: (i) one
367 for the messages sent in the initiation phase, (ii) one for the
368 messages sent as MP (if it is acting as a MP), and (iii) one for the
369 messages sent as MC (if it is acting as a MC).
371 In particular, CLUE response messages ('optionsResponse', 'ack',
372 'configureResponse') derive from a base type, inheriting from the
373 clueMessageType, which is defined as follows (Figure 2):
375
376
377
378
379
380
381
382
383
384
386 Figure 2: Structure of CLUE response messages
388 The elements and get populated as
389 detailed in Section 5.7
391 5.1. options
393 The 'options' message is sent by the CLUE Participant which is the
394 Channel Initiator to the CLUE Participant which is the Channel
395 Receiver as soon as the CLUE data channel is ready. Besides the
396 information envisioned in the basic structure, it specifies:
398 o : a mandatory boolean field set to "true" if the CP
399 is able to act as a MP
401 o : a mandatory boolean field set to "true" if the CP
402 is able to act as a MC
404 o : the list of the supported versions
406 o : the list of the supported extensions
408 The XML Schema of such a message is reported below (Figure 3):
410
411
412
413
414
415
416
417
419
421
423
424
425
426
427
429
430
431
432
434
435
436
437
439
440
441
442
444
445
446
447
449
450
451
452
453
454
455
456
457
458
459 Figure 3: Structure of CLUE 'options' message
461 contains the list of the versions that are
462 supported by the CI, each one represented in a child
463 element. The content of each element is a string made by
464 the major version number followed by a dot and then by the minor
465 version number (e.g., 1.3 or 2.4). Exactly one element
466 MUST be provided for each major version supported, containing the
467 maximum minor version number of such a version, since all minor
468 versions are backward compatible. If no is
469 carried within the 'options' message, the CI supports only the
470 version declared in the "v" attribute and all the versions having the
471 same major version number and lower minor version number. For
472 example, if the "v" attribute has a value of "3.4" and there is no
473 tag in the 'options' message, it means the CI
474 supports only major version 3 with all the minor versions comprised
475 between 3.0 and 3.4, with version 3.4 included. If a
476 is provided, at least one tag MUST be
477 included. In this case, the "v" attribute SHOULD be set to the
478 largest minor version of the smallest major version advertised in the
479 list. Indeed, the intention behind the "v"
480 attribute is that some implementation that receives a version number
481 in the "v" field with a major number higher than it understands is
482 supposed to close the connection, since it runs a risk of
483 misinterpreting the contents of messages. The minor version is
484 obviously less useful in this context, since minor versions are
485 defined to be both backwards and forwards compatible, but it is more
486 useful to know the highest minor version supported than some random
487 minor version, as it indicates the full feature set that is
488 supported. The reason why it is less useful is that the value can in
489 any case be parsed out of the list.
491 The element specifies the list of extensions
492 supported by the CI. If there is no in the
493 'options' message, the CI does not support anything other than what
494 is envisioned in the versions it supports. For each extension, an
495 element is provided. An extension is characterized by a
496 name, an XML schema of reference where the extension is defined, and
497 the version of the protocol which the extension refers to.
499 5.2. optionsResponse
501 The 'optionsResponse' (Figure 4) is sent by a CR to a CI as a reply
502 to the 'options' message. The 'optionsResponse' contains a mandatory
503 response code and a reason string indicating the processing result of
504 the 'options' message. If the responseCode is between 200 and 299
505 inclusive, the response MUST also include ,
506 , and elements; it MAY
507 include them for any other response code. and
508 elements are associated with the supported roles (in
509 terms of, respectively MP and MC), similarly to what the CI does in
510 the 'options' message. The field indicates the highest
511 commonly supported version number. The content of the
512 element MUST be a string made of the major version number followed by
513 a dot and then by the minor version number (e.g., 1.3 or 2.4).
514 Finally, the commonly supported extensions are copied in the
515 field.
517
518
519
520
521
522
524
526
527
529
531
532
533
534
535
537 Figure 4: Structure of CLUE 'optionsResponse' message
539 Upon reception of the 'optionsResponse' the version to be used is the
540 one provided in the tag of the message. The following CLUE
541 messages MUST use such a version number in the "v" attribute. The
542 allowed extensions in the CLUE dialogue are those indicated in the
543 of the 'optionsResponse' message.
545 5.3. advertisement
547 The 'advertisement' message is used by the MP to advertise the
548 available media captures and related information to the MC. The MP
549 sends an 'advertisement' to the MC as soon as it is ready after the
550 successful completion of the initiation phase, i.e., as soon as the
551 version and the extensions of the CLUE protocol are agreed between
552 the CPs. During a single CLUE session, an MP may send new
553 'advertisement' messages to replace the previous advertisement, if,
554 for instance, its CLUE telepresence media capabilities change mid-
555 call. A new 'advertisement' completely replaces the previous
556 'advertisement'.
558 The 'advertisement' structure is defined in the schema excerpt below
559 (Figure 5). The 'advertisement' contains elements compliant with the
560 CLUE data model that characterize the MP's telepresence offer.
561 Namely, such elements are: the list of the media captures
562 (), of the encoding groups (), of the
563 capture scenes (), of the simultaneous sets
564 (), of the global views (), and of the
565 represented participants (). Each of them is fully described
566 in the CLUE framework document and formally defined in the CLUE data
567 model document.
569
570
571
572
573
574
575
576
577
578
579
581
583
584
586
587
588
589
590
592 Figure 5: Structure of CLUE 'advertisement' message
594 5.4. ack
596 The 'ack' message is sent by a MC to a MP to acknowledge an
597 'advertisement' message. As it can be seen from the message schema
598 provided in the following excerpt (Figure 6), the 'ack' contains a
599 response code and a reason string for describing the processing
600 result of the 'advertisement'. The carries the
601 sequence number of 'advertisement' message the 'ack' refers to.
603
604
605
606
607
608
609
611
612
613
614
615
617 Figure 6: Structure of CLUE 'ack' message
619 5.5. configure
621 The 'configure' message is sent from a MC to a MP to list the
622 advertised captures the MC wants to receive. The MC can send a
623 'configure' after the reception of an 'advertisement' or each time it
624 wants to request other captures that have been previously advertised
625 by the MP. The content of the 'configure' message is shown below
626 (Figure 7).
628
629
630
631
632
633
634
635
637
639
641
642
643
644
645
647 Figure 7: Structure of CLUE 'configure' message
649 The element contains the sequence number of the
650 'advertisement' message the 'configure' refers to.
652 The optional element, when present, contains a success response
653 code, as defined in Section 5.7. It indicates that the 'configure'
654 message also acknowledges with success the referred advertisement
655 ('configure' + 'ack' message), by applying in that way a piggybacking
656 mechanism for simultaneously acknowledging and replying to the
657 'advertisement' message. The element MUST NOT be present if an
658 'ack' message has been already sent back to the MP.
660 The most important content of the 'configure' message is the list of
661 the capture encodings provided in the element (see
662 [I-D.ietf-clue-data-model-schema] for the definition of
663 ). Such an element contains a sequence of capture
664 encodings, representing the streams to be instantiated.
666 5.6. configureResponse
668 The 'configureResponse' message is sent from the MP to the MC to
669 communicate the processing result of requests carried in the
670 previously received 'configure' message. It contains (Figure 8) a
671 response code with a reason string indicating either the success or
672 the failure (along with failure details) of a 'configure' request
673 processing. Following, the field contains the
674 sequence number of the 'configure' message the response refers to.
676 There is no partial execution of commands. As an example, if a MP is
677 able to understand all the selected capture encodings except one,
678 then the whole command fails and nothing is instantiated.
680
681
682
683
684
685
686
688
689
690
691
692
694 Figure 8: Structure of CLUE 'configureResponse' message
696 5.7. Response codes and reason strings
698 Response codes are defined as a sequence of three digits. A well-
699 defined meaning is associated with the first digit. Response codes
700 beginning with "2" are associated with successful responses.
701 Response codes that do not begin with either "2" or "1" indicate an
702 error response, i.e., that an error occurred while processing a CLUE
703 request. In particular, response codes beginning with "3" indicate
704 problems with the XML content of the message ("Bad syntax", "Invalid
705 value", etc.), while response codes beginning with "4" refer to
706 problems related to CLUE protocol semantics ("Invalid sequencing",
707 "Version not supported", etc.). 200, 300 and 400 codes are
708 considered catch-alls. Further response codes can be either defined
709 in future versions of the protocol (by adding them to the related
710 IANA registry), or defined by leveraging the extension mechanism. In
711 both cases, the new response codes MUST be registered with IANA.
712 Such new response codes MUST NOT overwrite the ones here defined and
713 they MUST respect the semantics of the first code digit.
715 This document does not define response codes starting with "1", and
716 such response codes are not allowed to appear in major version 1 of
717 the CLUE protocol. The range from 100 to 199 inclusive is reserved
718 for future major versions of the protocol to define response codes
719 for delayed or incomplete operations if necessary. Response codes
720 starting with "5" through "9" are reserved for future major versions
721 of the protocol to define new classes of response, and are not
722 allowed in major version 1 of the CLUE protocol. Response codes
723 starting with "0" are not allowed.
725 The response codes and strings defined for use with version 1 of the
726 CLUE protocol are listed in Figure 9. The "Description" text
727 contained in the table can be sent in the element of a
728 response message. Implementations can (and are encouraged to)
729 include more specific descriptions of the error condition, if
730 possible.
732 +-----------------+----------------------+--------------------------+
733 | | | |
734 | Response code | Reason string | Description |
735 | | | |
736 +-----------------+----------------------+--------------------------+
737 | | | |
738 | 200 | Success | The request has been |
739 | | | successfully processed. |
740 | | | |
741 +-----------------+----------------------+--------------------------+
742 | | | |
743 | 300 | Low-level request | A generic low-level |
744 | | error. | request error has |
745 | | | occurred. |
746 | | | |
747 +-----------------+----------------------+--------------------------+
748 | | | |
749 | 301 | Bad syntax | The XML syntax of the |
750 | | | message is not correct. |
751 +-----------------+----------------------+--------------------------+
752 | | | |
753 | 302 | Invalid value | The message |
754 | | | contains an invalid |
755 | | | parameter value. |
756 +-----------------+----------------------+--------------------------+
757 | | | |
758 | 303 | Conflicting values | The message |
759 | | | contains values that |
760 | | | cannot be used together.|
761 +-----------------+----------------------+--------------------------+
762 | | | |
763 | 400 | Semantic errors | Semantic errors in the |
764 | | | received CLUE protocol |
765 | | | message. |
766 | | | |
767 +-----------------+----------------------+--------------------------+
768 | | | |
769 | 401 | Version not supported| The protocol version |
770 | | | used in the message |
771 | | | is not supported. |
772 | | | |
773 +-----------------+----------------------+--------------------------+
774 | | | |
775 | 402 | Invalid sequencing | Sequence number gap; |
776 | | | repeated sequence number;|
777 | | | sequence number outdated.|
778 +-----------------+----------------------+--------------------------+
779 | | | |
780 | 403 | Invalid identifier | The clueId used in |
781 | | | the message is |
782 | | | not valid or unknown. |
783 +-----------------+----------------------+--------------------------+
784 | | | The sequence number of |
785 | 404 | advertisement | the advertisement the |
786 | | Expired | configure refers to is |
787 | | | out of date. |
788 +-----------------+----------------------+--------------------------+
789 | | | |
790 | 405 | Subset choice not | The subset choice is not |
791 | | allowed | allowed for the specified|
792 | | | Multiple Content Capture |
793 +-----------------+----------------------+--------------------------+
795 Figure 9: CLUE response codes
797 6. Protocol state machines
799 The CLUE protocol is an application protocol used between two CPs in
800 order to properly configure a multimedia telepresence session. CLUE
801 protocol messages flow over the CLUE Data Channel, a DTLS/SCTP
802 channel established as depicted in [I-D.ietf-clue-datachannel]. We
803 herein discuss the state machines associated, respectively, with the
804 CLUE Participant (Figure 10), with the MC process (Figure 11) and
805 with the MP process (Figure 12). Endpoints often wish to both send
806 and receive media, i.e., act as both MP and MC. As such there will
807 often be two sets of messages flowing in opposite directions; the
808 state machines of these two flows do not interact with each other.
809 Only the CLUE application logic is considered. The interaction of
810 CLUE protocol and SDP negotiations for the media streams exchanged is
811 treated in [I-D.ietf-clue-signaling].
813 The main state machines focus on the behavior of the CLUE Participant
814 (CP) acting as a CLUE Channel Initiator/Receiver (CI/CR).
816 The initial state is the IDLE one. When in the IDLE state, the CLUE
817 data channel is not established and no CLUE-controlled media are
818 exchanged between the two considered CLUE-capable devices (if there
819 is an ongoing exchange of media streams, such media streams are not
820 currently CLUE-controlled).
822 When the CLUE data channel set up starts ("start channel"), the CP
823 moves from the IDLE state to the CHANNEL SETUP state.
825 If the CLUE data channel is successfully set up ("channel
826 established"), the CP moves from the CHANNEL SETUP state to the
827 OPTIONS state. Otherwise if "channel error", it moves back to the
828 IDLE state. The same transition happens if the CLUE-enabled
829 telepresence session ends ("session ends"), i.e., when an SDP
830 negotiation for removing the CLUE data channel is performed.
832 When in the OPTIONS state, the CP addresses the initiation phase
833 where both parts agree on the version and on the extensions to be
834 used in the subsequent CLUE messages exchange phase. If the CP is
835 the Channel Initiator (CI), it sends an 'options' message and waits
836 for the 'optionsResponse' message. If the CP is the Channel Receiver
837 (CR), it waits for the 'options' message and, as soon as it arrives,
838 replies with the 'optionsResponse' message. If the negotiation is
839 successfully completed ("OPTIONS phase success"), the CP moves from
840 the OPTIONS state to the ACTIVE state. If the initiation phase fails
841 ("OPTIONS phase failure"), the CP moves from the OPTIONS state to the
842 IDLE state. The initiation phase might fail because of one of the
843 following reasons:
845 1. the CI receives an 'optionsResponse' with an error response code
847 2. the CI does not receive any 'optionsResponse' and a timeout error
848 is raised
850 3. the CR does not receive any 'options' and a timeout error is
851 raised
853 When in the ACTIVE state, the CP starts the envisioned sub-state
854 machines (i.e., the MP state machine and the MC state machine)
855 according to the roles it plays in the telepresence sessions. Such
856 roles have been previously declared in the 'options' and
857 'optionsResponse' messages involved in the initiation phase (see
858 OPTIONS sections Section 5.1 and Section 5.2 for the details). When
859 in the ACTIVE state, the CP delegates the sending and the processing
860 of the CLUE messages to the appropriate MP/MC sub-state machines. If
861 the CP receives a further 'options'/'optionsResponse' message, it
862 MUST ignore the message and stay in the ACTIVE state.
864 +----+
865 +---------------------->|IDLE|<----------------------------+
866 | +-+--+ |
867 | | |
868 | | start |
869 | | channel |
870 | v |
871 | channel error/ +--------+ |
872 | session ends | CHANNEL| |
873 +----------------------+ SETUP | |
874 | +--+-----+ |
875 | | |
876 | | channel |
877 | | established |
878 | channel error/ v OPTIONS phase |
879 | session ends +-------+ failure |
880 +-----------------------+OPTIONS+--------------------------+
881 | +-+-----+
882 | |
883 | | OPTIONS phase
884 | | success
885 | v
886 | channel error/ +---------+
887 | session ends | ACTIVE |
888 +----------------------+ |
889 | +----+ +------------------+
890 | | MP | | send/receive |
891 | +----+ | CLUE messages |
892 | |<-----------------+
893 | +----+ |
894 | | MC | |
895 | +----+ |
896 | |
897 +---------+
899 Figure 10: CLUE Participant state machine
901 6.1. Media Provider's state machine
903 As soon as the sub-state machine of the MP (Figure 11) is activated,
904 it is in the ADV state. In the ADV state, the MP prepares the
905 'advertisement' message reflecting its actual telepresence
906 capabilities.
908 After the 'advertisement' has been sent ("advertisement sent"), the
909 MP moves from the ADV state to the WAIT FOR ACK state. If an 'ack'
910 message with a successful response code arrives ("ack received"), the
911 MP moves to the WAIT FOR CONF state. If a NACK arrives (i.e., an
912 'ack' message with an error response code), the MP moves back to the
913 ADV state for preparing a new 'advertisement'. When in the WAIT FOR
914 ACK state, if a 'configure' message with the element set to
915 TRUE arrives ("configure+ack received"), the MP goes directly to the
916 CONF RESPONSE state. 'configure+ack' messages referring to out-of-
917 date (i.e., having a sequence number equal to or less than the
918 highest seen so far) advertisements MUST be ignored, i.e., they do
919 not trigger any state transition. If the telepresence settings of
920 the MP change while in the WAIT FOR ACK state ("changed telepresence
921 settings"), the MP switches from the WAIT FOR ACK state to the ADV
922 state to create a new 'advertisement'.
924 When in the WAIT FOR CONF state, the MP listens to the channel for a
925 'configure' request coming from the MC. When a 'configure' arrives
926 ("configure received"), the MP switches to the CONF RESPONSE state.
927 If the telepresence settings change in the meanwhile ("changed
928 telepresence settings"), the MP moves from the WAIT FOR CONF back to
929 the ADV state to create the new 'advertisement' to be sent to the MC.
931 The MP in the CONF RESPONSE state processes the received 'configure'
932 in order to produce a 'configureResponse' message. If the MP
933 successfully processes the MC's configuration, then it sends a 200
934 'configureResponse' ("success configureResponse sent") and moves to
935 the ESTABLISHED state. If there are errors in the 'configure'
936 processing, then the MP issues a 'configureResponse' carrying an
937 error response code and it goes back to the WAIT FOR CONF state to
938 wait for a new configuration request. Finally, if there are changes
939 in the MP's telepresence settings ("changed telepresence settings"),
940 the MP switches to the ADV state.
942 The MP in the ESTABLISHED state has successfully negotiated the media
943 streams with the MC by means of the CLUE messages. If there are
944 changes in the MP's telepresence settings ("changed telepresence
945 settings"), the MP moves back to the ADV state. In the ESTABLISHED
946 state, the CLUE-controlled media streams of the session are those
947 described in the last successfully processed 'configure' message.
949 Messages not shown for a state do not cause the state to change.
951 +-----+
952 +------------>| ADV |<-------------------+
953 | +-+---+ |
954 | advertisement| NACK received |
955 | sent| |
956 | v |
957 changed| +--------+ |
958 telepresence+-------------+WAIT FOR+-----------------+
959 settings| +----------+ ACK |
960 | |configure +-+------+
961 | | + ack |
962 | |received |ack received
963 | | v
964 | | +--------+
965 +-------------+WAIT FOR|
966 | | | CONF |
967 | | +-+------+<-----------------------------+
968 | | | |
969 | | |configure received |
970 | | v |
971 | +--------->+---------+ error configureResponse sent|
972 +-------------+CONF |-----------------------------+
973 | +--------->|RESPONSE +
974 | | +---------+
975 | | |
976 | | |success
977 | | |configureResponse
978 | | |sent
979 | | |
980 | | |
981 | |configure |
982 | |received v
983 | | +-----------+
984 | +----------+ESTABLISHED|
985 +-------------+-----------+
987 Figure 11: Media Provider's state machine
989 6.2. Media Consumer's state machine
991 As soon as the sub-state machine of the MC (Figure 12) is activated,
992 it is in the WAIT FOR ADV state. An MC in the WAIT FOR ADV state is
993 waiting for an 'advertisement' coming from the MP. If the
994 'advertisement' arrives ("ADV received"), the MC reaches the ADV
995 PROCESSING state. Otherwise, the MC stays in the WAIT FOR ADV state.
997 In the ADV PROCESSING state, the 'advertisement' is parsed by the MC.
998 If the 'advertisement' is successfully processed, there are two
999 possibilities. In the former case, the MC issues a successful 'ack'
1000 message to the MP ("ACK sent") and moves to the CONF state. This
1001 typically happens when the MC needs some more time to produce the
1002 'configure' message associated with the received 'advertisement'. In
1003 the latter case, the MC is able to immediately prepare and send back
1004 to the MP a 'configure' message. Such a message will have the
1005 field set to "200" ("configure+ack sent") and will allow the MC to
1006 move directly to the WAIT FOR CONF RESPONSE state.
1008 If the ADV processing is unsuccessful (bad syntax, missing XML
1009 elements, etc.), the MC sends a NACK message (i.e., an 'ack' with an
1010 error response code) to the MP and optionally further describes the
1011 problem via a proper reason phrase. In this way ("NACK sent"), the
1012 MC switches back to the WAIT FOR ADV state, waiting for a new
1013 'advertisement'.
1015 When in the CONF state, the MC prepares the 'configure' request to be
1016 issued to the MP on the basis of the previously ack-ed
1017 'advertisement'. When the 'configure' has been sent ("configure
1018 sent"), the MC moves to the WAIT FOR CONF RESPONSE state. If a new
1019 'advertisement' arrives in the meanwhile ("advertisement received"),
1020 the MC goes back to the ADV PROCESSING state.
1022 In the WAIT FOR CONF RESPONSE state, the MC waits for the MP's
1023 response to the issued 'configure' or 'configure+ack'. If a 200
1024 'configureResponse' message is received ("successful
1025 configureResponse received"), it means that the MP and the MC have
1026 successfully agreed on the media streams to be shared. Then, the MC
1027 can move to the ESTABLISHED state. On the other hand, if an error
1028 response is received ("error configureResponse received"), the MC
1029 moves back to the CONF state to prepare a new 'configure' request.
1030 If a new 'advertisement' is received in the WAIT FOR CONF RESPONSE
1031 state, the MC switches to the ADV PROCESSING state.
1033 When the MC is in the ESTABLISHED state, the telepresence session
1034 configuration has been set up at the CLUE application level according
1035 to the MC's preferences. Both the MP and the MC have agreed on (and
1036 are aware of) the CLUE-controlled media streams to be exchanged
1037 within the call. While in the ESTABLISHED state, it might happen
1038 that the MC decides to change something in the call settings. The MC
1039 then issues a new 'configure' ("configure sent") and goes to wait for
1040 the new 'configureResponse' in the WAIT FOR CONF RESPONSE state. On
1041 the other hand, in the ESTABLISHED state, if a new 'advertisement'
1042 arrives from the MP ("advertisement received"), it means that
1043 something has changed on the MP's side. The MC then moves to the ADV
1044 PROCESSING state.
1046 Messages not shown for a state do not cause the state to change.
1048 +----------+
1049 | WAIT FOR |
1050 | ADV |
1051 +----+-----+<--------+
1052 | |
1053 advertisement| NACK sent|
1054 received| |
1055 v |
1056 +-----------+--------+
1057 | ADV +
1058 | PROCESSING|<-----------------------+
1059 +-+-----+---+ |
1060 | | |
1061 configure+ack | | ack |
1062 sent | | sent |
1063 | v |
1064 | +-----+ |
1065 | |CONF | advertisement received |
1066 +----------------------->| +-------------------------+
1067 |error | +--+--+ |
1068 |configureResponse | | |
1069 |received | |configure |
1070 | | |sent |
1071 | | | |
1072 | v v advertisement |
1073 +------------------+---------------+ received |
1074 +--------->| WAIT FOR +---------------------+
1075 | | CONF RESPONSE+ |
1076 | +-------+-------+ |
1077 | | |
1078 | | |
1079 | |successful |
1080 | |configureResponse |
1081 | |received |
1082 |configure v |
1083 |sent +-----------+ advertisement received|
1084 +------------+ESTABLISHED+-----------------------+
1085 +-----------+
1087 Figure 12: Media Consumer's state machine
1089 7. Versioning
1091 CLUE protocol messages are XML messages compliant to the CLUE
1092 protocol XML schema [I-D.ietf-clue-data-model-schema]. The version
1093 of the protocol corresponds to the version of the schema. Both
1094 client and server have to test the compliance of the received
1095 messages with the XML schema of the CLUE protocol. If the compliance
1096 is not verified, the message cannot be processed further.
1098 Obviously, client and server cannot communicate if they do not share
1099 exactly the same XML schema. Such a schema is associated with the
1100 CLUE URN "urn:ietf:params:xml:ns:clue-protocol". If all CLUE-enabled
1101 devices use that schema there will be no interoperability problems
1102 due to schema issues.
1104 This document defines XML schema version 1.0. The version usage is
1105 similar in philosophy to XMPP ([RFC6120]). A version number has
1106 major and minor components, each a non-negative integer. Major
1107 version changes denote non-interoperable changes. Minor version
1108 changes denote schema changes that are backward compatible by
1109 ignoring unknown XML elements, or other backward compatible changes.
1111 The minor versions of the XML schema MUST be backward compatible, not
1112 only in terms of schema but also semantically and procedurally as
1113 well. This means that they should define further features and
1114 functionality besides those defined in the previous versions, in an
1115 incremental way, without impacting the basic rules defined in the
1116 previous version of the schema. In this way, if a MP is able to
1117 speak, e.g., version 1.5 of the protocol while the MC only
1118 understands version 1.4, the MP should have no problem in reverting
1119 the dialogue back to version 1.4 without exploiting 1.5 features and
1120 functionality. Version 1.4 is the one to be spoken and has to appear
1121 in the "v" attribute of the subsequent CLUE messages. In other
1122 words, in this example, the MP MUST use version 1.4 and downgrade to
1123 the lower version. This said, and coherently with the general IETF
1124 "protocol robustness principle" stating that "an implementation must
1125 be conservative in its sending behavior, and liberal in its receiving
1126 behavior" [RFC1122], CLUE Participants MUST ignore unknown elements
1127 or attributes that are not envisioned in the negotiated protocol
1128 version and related extensions.
1130 8. Extensions
1132 Although the standard version of the CLUE protocol XML schema is
1133 designed to thoroughly cope with the requirements emerging from the
1134 application domain, new needs might arise and extensions can be
1135 designed. Extensions specify information and behaviors that are not
1136 described in a certain version of the protocol and specified in the
1137 related RFC document. Such information and behaviors can be
1138 optionally used in a CLUE dialogue and MUST be negotiated in the CLUE
1139 initiation phase. They can relate to:
1141 1. new information, to be carried in the existing messages. For
1142 example, more fields may be added within an existing message;
1144 2. new messages. This is the case if there is no proper message for
1145 a certain task, so a brand new CLUE message needs to be defined.
1147 As to the first type of extensions, it is possible to distinguish
1148 between protocol-specific and data model information. Indeed, CLUE
1149 messages are envelopes carrying both:
1151 o (i) XML elements defined within the CLUE protocol XML schema
1152 itself (protocol-specific information)
1154 o (ii) other XML elements compliant to the CLUE data model schema
1155 (data model information)
1157 When new protocol-specific information is needed somewhere in the
1158 protocol messages, it can be added in place of the elements and
1159 elements envisioned by the protocol schema. The
1160 policy currently defined in the protocol schema for handling
1161 and elements is:
1163 o elementFormDefault="qualified"
1165 o attributeFormDefault="unqualified"
1167 The new information must be qualified by namespaces other than
1168 "urn:ietf:params:xml:ns:clue-protocol" (the protocol URN) and
1169 "urn:ietf:params:xml:ns:clue-info" (the data model URN). Elements or
1170 attributes from unknown namespaces MUST be ignored.
1172 The other matter concerns data model information. Data model
1173 information is defined by the XML schema associated with the URN
1174 "urn:ietf:params:xml:ns:clue-info". Also for the XML elements
1175 defined in such a schema there are extensibility issues. Those
1176 issues are overcome by using and placeholders.
1177 New information within data model elements can be added in place of
1178 and schema elements, as long as they are
1179 properly namespace qualified.
1181 On the other hand (second type of extensions), "extra" CLUE protocol
1182 messages, i.e., messages not envisioned in the latest standard
1183 version of the schema, can be needed. In that case, the messages and
1184 the associated behavior should be defined in external documents that
1185 both communication parties must be aware of.
1187 As reported in Figure 13, the values of the fields of the
1188 element (either new information or new messages) take the following
1189 values:
1191 o a name;
1193 o an external XML Schema defining the XML information and/or the XML
1194 messages representing the extension;
1196 o the major standard version of the protocol that the extension
1197 refers to.
1199
1200
1201
1202
1203
1204
1205
1206
1207
1209 Figure 13: The element
1211 The above described element is carried within the
1212 'options' and 'optionsResponse' messages to represent the extensions
1213 supported both by the CI and the CR.
1215 Extensions MUST be defined in a separate XML schema file and MUST be
1216 provided with a companion document describing their semantics and
1217 use.
1219 8.1. Extension example
1221 An example of extension might be a "new" capture attribute (i.e., a
1222 capture attribute which is not envisioned in the current standard
1223 defining the CLUE data model in [I-D.ietf-clue-data-model-schema])
1224 needed to further describe a video capture.
1226 The CLUE data model document ([I-D.ietf-clue-data-model-schema])
1227 envisions the possibility of adding this kind of "extra" information
1228 in the description of a video capture by keeping the compatibility
1229 with the CLUE data model schema. This is made possible thanks to the
1230 presence of the element in the XML definition of the video
1231 capture, allowing for the introduction of a new XML field in the XML
1232 description. For the sake of convenience, the XML definition of a
1233 video capture taken from [I-D.ietf-clue-data-model-schema] is
1234 reported in Figure 14 below.
1236
1237
1238
1239
1240
1241
1243
1244
1245
1246
1247
1249 Figure 14: XML definition of a CLUE video capture
1251 According to such a definition, a video capture might have, after the
1252 set of the generic media capture attributes, a set of new attributes
1253 defined elsewhere, i.e., in an XML schema defining an extension. The
1254 XML schema defining the extension might look like the following
1255 (Figure 15):
1257
1258
1265
1271
1272
1273
1274
1275
1276
1277
1278
1280
1282
1283
1285 Figure 15: XML schema defining an extension
1287 By using the extension above, a video capture can be further
1288 described in the advertisement using the element
1289 containing two extra information ( and
1290 ) besides using the attributes envisioned for a
1291 generic media capture. As stated in this document, both participants
1292 must be aware of the extension schema and related semantics to use
1293 such an extension and must negotiate it via the 'options' and
1294 'optionsResponse' mechanism.
1296 9. XML Schema
1298 NOTE TO THE RFC-Editor: Please replace "data-model-schema-18.xsd"
1299 with the right schema location for the CLUE data model schema
1300 document (which is still to be defined at the time of this writing)
1301 in this section prior to publication as an RFC.
1303 In this section, the XML schema defining the CLUE messages is
1304 provided (Figure 16).
1306
1307
1315
1316
1318
1319
1320
1321
1322
1323
1324
1326
1327
1328
1329
1330
1331
1332
1334
1335
1336
1337
1338
1339
1340
1341
1342
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1375
1377
1379
1380
1381
1382
1383
1384
1385
1386
1387
1389
1390
1391
1392
1393
1394
1395
1396
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1420
1422
1423
1425
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1441
1442
1443
1445
1448
1449
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1478
1480
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1495
1496
1497
1498
1499
1500
1502 Figure 16: Schema defining CLUE messages
1504 10. Call flow example
1506 In this section the CLUE protocol messages exchanged in the following
1507 call flow are detailed.
1509 +-----+ +-----+
1510 | | | |
1511 | CP1 | | CP2 |
1512 | | | |
1513 +--+--+ +--+--+
1514 | |
1515 | 1.options |
1516 +----------------->|
1517 | |
1518 | |
1519 |2.optionsResponse |
1520 |<-----------------+
1521 | |
1522 | |
1523 | 3.advertisement |
1524 +----------------->|
1525 | |
1526 | |
1527 |4.configure+ack |
1528 |<-----------------+
1529 | |
1530 | |
1531 |5.confResponse |
1532 +----------------->|
1533 | |
1534 | |
1535 |6.advertisement |
1536 +----------------->|
1537 | |
1538 | |
1539 | 7.ack |
1540 |<-----------------+
1541 | |
1542 | |
1543 | 8.configure |
1544 |<-----------------+
1545 | |
1546 | |
1547 | 9.confResponse |
1548 +----------------->|
1549 | |
1550 | |
1551 . .
1552 . .
1553 . .
1555 Two CLUE Participants, CP1 and CP2, have successfully set up the CLUE
1556 channel according to document [I-D.ietf-clue-datachannel]. CP1 is
1557 the Channel Initiator (CI) and CP2 is the Channel Receiver (CR).
1559 The initiation phase starts (negotiation of the CLUE protocol version
1560 and extensions). CP1, as the CI, sends to CP2 an 'options' message
1561 specifying the supported versions and extensions (Section 10.1). CP1
1562 supports: (i) version 1.4 with extensions E1, E2 and E3, (ii) version
1563 2.7 with extensions E4 and E5. Because of such capabilities, CP1
1564 sends an 'options' message with the 'v' attribute set to 1.4 and
1565 specifies explicitly all the supported versions and extensions in the
1566 corresponding fields of the 'options' message. In the 'options'
1567 message, CP1 specifies also that it intends to act both as a MP and
1568 as a MC.
1570 CP2 supports version 3.0, version 2.9 and version 1.9 of the CLUE
1571 protocol, each version without any extension. Version 2.7 is the
1572 best common choice. Given the received 'options' message, CP2
1573 answers with an 'optionsResponse' message in which it specifies only
1574 version 2.7 as the agreed version of the CLUE protocol to be used,
1575 leaving blank the extensions part of the message to say that no
1576 extension will be used in the CLUE session (Section 10.2). In the
1577 'optionsResponse' message, CP2 specifies also that it intends to act
1578 both as a MP and as a MC.
1580 After the initiation phase is completed, CP1 and CP2 start their
1581 activity as MP and as MC. For the sake of simplicity, the following
1582 call flow focuses only on the dialogue between MP CP1 and MC CP2.
1584 CP1 advertises a telepresence configuration like the one described in
1585 [I-D.ietf-clue-data-model-schema], Sec. Sample XML File, where there
1586 are (i) three main video streams captured by three cameras, the
1587 central one capable of capturing a zoomed-out view of the overall
1588 telepresence room, (ii) a multi-content capture of the loudest
1589 segment of the room, and (iii) one audio capture for the audio of the
1590 whole room (Section 10.3).
1592 CP2 receives CP1's 'advertisement' message and, after processing it,
1593 sends back to CP1 a 'configure + ack' message where it declares to be
1594 interested only in the multi-content capture and in the audio capture
1595 (Section 10.4).
1597 CP1 answers to CP2's 'configure + ack' message with a
1598 'configureResponse' message including a response code '200 - Success'
1599 to accept all CP2's requests (Section 10.5).
1601 To reflect the changes in its telepresence offer, CP1 issues a new
1602 'advertisement' message to CP2 (Section 10.6), this time adding also
1603 a composed capture made by a big picture representing the current
1604 speaker and two picture-in-picture boxes representing the previous
1605 speakers (see more details about the telepresence description in
1606 [I-D.ietf-clue-data-model-schema], Sec. MCC example).
1608 CP2 acknowledges the second 'advertisement' message with an 'ack'
1609 message (Section 10.7).
1611 In a second moment, CP2 changes the requested media streams from CP1
1612 by sending to CP1 a 'configure' message replacing the previously
1613 selected video streams with the new composed media streams advertised
1614 by CP1 (Section 10.8).
1616 Finally, CP1 accept the last requests of CP2 with a 'confResponse'
1617 message (Section 10.9)
1619 10.1. CLUE message nr. 1: 'option'
1620
1621
1628 CP1
1629 51
1630 true
1631 true
1632
1633 1.4
1634 2.7
1635
1636
1637
1638 E1
1639 URL_E1
1640 1.4
1641
1642
1643 E2
1644 URL_E2
1645 1.4
1646
1647
1648 E3
1649 URL_E3
1650 1.4
1651
1652
1653 E4
1654 URL_E4
1655 2.7
1656
1657
1658 E5
1659 URL_E5
1660 2.7
1661
1662
1663
1665 10.2. CLUE message nr. 2: 'optionResponse'
1667
1668
1675 CP2
1676 62
1677 200
1678 Success
1679 true
1680 true
1681 2.7
1682
1684 10.3. CLUE message nr. 3: 'advertisement'
1686
1687
1694 CP1
1695 11
1696
1697
1701 CS1
1702
1703
1704
1705 0.0
1706 0.0
1707 10.0
1708
1709
1710 0.0
1711 1.0
1712 10.0
1713
1714
1715
1716 true
1717 EG1
1718 main audio from the room
1719
1720 1
1721 it
1722 static
1723 room
1724
1725 alice
1726 bob
1727 ciccio
1728
1729
1730
1733 CS1
1734
1735
1736
1737 -2.0
1738 0.0
1739 10.0
1740
1741
1742
1743
1744 -3.0
1745 20.0
1746 9.0
1747
1748
1749 -1.0
1750 20.0
1751 9.0
1752
1753
1754 -3.0
1755 20.0
1756 11.0
1757
1758
1759 -1.0
1760 20.0
1761 11.0
1762
1763
1764
1765 true
1766 EG0
1767 left camera video capture
1768
1769 1
1770 it
1771 static
1772 individual
1773
1774 ciccio
1775
1776
1777
1780 CS1
1781
1782
1783
1784 0.0
1785 0.0
1786 10.0
1787
1788
1789
1790
1791 -1.0
1792 20.0
1793 9.0
1794
1795
1796 1.0
1797 20.0
1798 9.0
1799
1800
1801 -1.0
1802 20.0
1803 11.0
1804
1805
1806 1.0
1807 20.0
1808 11.0
1809
1810
1811
1812 true
1813 EG0
1814 central camera video capture
1815
1816 1
1817 it
1818 static
1819 individual
1820
1821 alice
1822
1823
1824
1827 CS1
1828
1829
1830
1831 2.0
1832 0.0
1833 10.0
1834
1835
1836
1837
1838 1.0
1839 20.0
1840 9.0
1841
1842
1843 3.0
1844 20.0
1845 9.0
1846
1847
1848 1.0
1849 20.0
1850 11.0
1851
1852
1853 3.0
1854 20.0
1855 11.0
1856
1857
1858
1859 true
1860 EG0
1861 right camera video capture
1862
1863 1
1864 it
1865 static
1866 individual
1867
1868 bob
1869
1870
1871
1874 CS1
1875
1876
1877
1878 -3.0
1879 20.0
1880 9.0
1881
1882
1883 3.0
1884 20.0
1885 9.0
1886
1887
1888 -3.0
1889 20.0
1890 11.0
1891
1892
1893 3.0
1894 20.0
1895 11.0
1896
1897
1898
1899
1900 SE1
1901
1902 SoundLevel:0
1903 EG0
1904 loudest room segment
1905 2
1906 it
1907 static
1908 individual
1909
1910
1913 CS1
1914
1915
1916
1917 0.0
1918 0.0
1919 10.0
1920
1921
1922
1923
1924 -3.0
1925 20.0
1926 7.0
1927
1928
1929 3.0
1930 20.0
1931 7.0
1932
1933
1934 -3.0
1935 20.0
1936 13.0
1937
1938
1939 3.0
1940 20.0
1941 13.0
1942
1943
1944
1945 true
1946 EG0
1947 zoomed out view of all people in the
1948 room
1949 2
1950 it
1951 static
1952 room
1953
1954 alice
1955 bob
1956 ciccio
1957
1958
1959
1960
1961
1962 600000
1963
1964 ENC1
1965 ENC2
1966 ENC3
1967
1968
1969
1970 300000
1971
1972 ENC4
1973 ENC5
1974
1975
1976
1977
1978
1979
1980
1981
1982 VC0
1983 VC1
1984 VC2
1985
1986
1987
1988
1989 VC3
1990
1991
1992
1993
1994 VC4
1995
1996
1997
1998
1999 AC0
2000
2001
2002
2003
2004
2005
2006
2007 VC3
2008 SE1
2009
2010
2011 VC0
2012 VC2
2013 VC4
2014
2015
2016
2017
2018
2019
2020 Bob
2021
2022
2023 minute taker
2024
2025
2026
2027
2028 Alice
2029
2030
2031 presenter
2032
2033
2034
2035
2036 Ciccio
2037
2038
2039 chairman
2040 timekeeper
2041
2042
2043
2044 10.4. CLUE message nr. 4: 'configure + ack'
2046
2047
2054 CP2
2055 22
2056 11
2057 200
2058
2059
2060 AC0
2061 ENC4
2062
2063
2064 VC3
2065 ENC1
2066
2067 SE1
2068
2069
2070
2071
2073 10.5. CLUE message nr. 5: 'confResponse'
2074
2075
2082 CP1
2083 12
2084 200
2085 Success
2086 22
2087
2089 10.6. CLUE message nr. 6: 'advertisement'
2091
2092
2099 CP1
2100 13
2101
2102
2105 CS1
2106
2107
2108
2109 0.0
2110 0.0
2111 10.0
2112
2113
2114 0.0
2115 1.0
2116 10.0
2117
2118
2119
2120 true
2121 EG1
2122 main audio from the room
2123
2124 1
2125 it
2126 static
2127 room
2128
2129 alice
2130 bob
2131 ciccio
2132
2133
2134
2137 CS1
2138
2139
2140
2141 0.5
2142 1.0
2143 0.5
2144
2145
2146 0.5
2147 0.0
2148 0.5
2149
2150
2151
2152 true
2153 EG0
2154 left camera video capture
2155
2156 1
2157 it
2158 static
2159 individual
2160
2161 ciccio
2162
2163
2164
2167 CS1
2168
2169
2170
2171 0.0
2172 0.0
2173 10.0
2174
2175
2176
2177
2178 -1.0
2179 20.0
2180 9.0
2181
2182
2183 1.0
2184 20.0
2185 9.0
2186
2187
2188 -1.0
2189 20.0
2190 11.0
2191
2192
2193 1.0
2194 20.0
2195 11.0
2196
2197
2198
2199 true
2200 EG0
2201 central camera video capture
2202
2203 1
2204 it
2205 static
2206 individual
2207
2208 alice
2209
2210
2211
2214 CS1
2215
2216
2217
2218 2.0
2219 0.0
2220 10.0
2221
2222
2223
2224
2225 1.0
2226 20.0
2227 9.0
2228
2229
2230 3.0
2231 20.0
2232 9.0
2233
2234
2235 1.0
2236 20.0
2237 11.0
2238
2239
2240 3.0
2241 20.0
2242 11.0
2243
2244
2245
2246 true
2247 EG0
2248 right camera video capture
2249
2250 1
2251 it
2252 static
2253 individual
2254
2255 bob
2256
2257
2258
2261 CS1
2262
2263
2264
2265 -3.0
2266 20.0
2267 9.0
2268
2269
2270 3.0
2271 20.0
2272 9.0
2273
2274
2275 -3.0
2276 20.0
2277 11.0
2278
2279
2280 3.0
2281 20.0
2282 11.0
2283
2284
2285
2286
2287 SE1
2288
2289 SoundLevel:0
2290 EG0
2291 loudest room segment
2292 2
2293 it
2294 static
2295 individual
2296
2297
2300 CS1
2301
2302
2303
2304 0.0
2305 0.0
2306 10.0
2307
2308
2309
2310
2311 -3.0
2313 20.0
2314 7.0
2315
2316
2317 3.0
2318 20.0
2319 7.0
2320
2321
2322 -3.0
2323 20.0
2324 13.0
2325
2326
2327 3.0
2328 20.0
2329 13.0
2330
2331
2332
2333 true
2334 EG0
2335
2336 zoomed out view of all people in the room
2337
2338 2
2339 it
2340 static
2341 room
2342
2343 alice
2344 bob
2345 ciccio
2346
2347
2348
2351 CS1
2352
2353
2354
2355 -3.0
2356 20.0
2357 9.0
2358
2359
2360 3.0
2361 20.0
2362 9.0
2363
2364
2365 -3.0
2366 20.0
2367 11.0
2368
2369
2370 3.0
2371 20.0
2372 11.0
2373
2374
2375
2376
2377 SE1
2378
2379 SoundLevel:1
2380 penultimate loudest room segment
2381
2382 it
2383 static
2384 individual
2385
2386
2389 CS1
2390
2391
2392
2393 -3.0
2394 20.0
2395 9.0
2396
2397
2398 3.0
2399 20.0
2400 9.0
2401
2402
2403 -3.0
2404 20.0
2405 11.0
2406
2407
2408 3.0
2410 20.0
2411 11.0
2412
2413
2414
2415
2416 SE1
2417
2418 SoundLevel:2
2419 last but two loudest room segment
2420
2421 it
2422 static
2423 individual
2424
2425
2428 CS1
2429
2430
2431
2432 -3.0
2433 20.0
2434 9.0
2435
2436
2437 3.0
2438 20.0
2439 9.0
2440
2441
2442 -3.0
2443 20.0
2444 11.0
2445
2446
2447 3.0
2448 20.0
2449 11.0
2450
2451
2452
2453
2454 VC3
2455 VC5
2456 VC6
2457
2458 3
2459 EG0
2460 big picture of the current speaker +
2461 pips about previous speakers
2462 3
2463 it
2464 static
2465 individual
2466
2467
2468
2469
2470 600000
2471
2472 ENC1
2473 ENC2
2474 ENC3
2475
2476
2477
2478 300000
2479
2480 ENC4
2481 ENC5
2482
2483
2484
2485
2486
2487
2488
2489 participants' individual
2490 videos
2491
2492 VC0
2493 VC1
2494 VC2
2495
2496
2497
2498 loudest segment of the
2499 room
2500
2501 VC3
2502
2503
2504
2505 loudest segment of the
2506 room + pips
2507
2508 VC7
2509
2510
2511
2512 room audio
2513
2514 AC0
2515
2516
2517
2518 room video
2519
2520 VC4
2521
2522
2523
2524
2525
2526
2527
2528 VC3
2529 VC7
2530 SE1
2531
2532
2533 VC0
2534 VC2
2535 VC4
2536
2537
2538
2539
2540
2541
2542 Bob
2543
2544
2545 minute taker
2546
2547
2548
2549
2550 Alice
2551
2552
2553 presenter
2555
2556
2557
2558
2559 Ciccio
2560
2561
2562 chairman
2563 timekeeper
2564
2565
2566
2568 10.7. CLUE message nr. 7: 'ack'
2570
2571
2578 CP2
2579 23
2580 200
2581 Success
2582 13
2583
2585 10.8. CLUE message nr. 8: 'configure'
2586
2587
2594 CP2
2595 24
2596 13
2597
2598
2599 AC0
2600 ENC4
2601
2602
2603 VC7
2604 ENC1
2605
2606 SE5
2607
2608
2609
2610
2612 10.9. CLUE message nr. 9: 'confResponse'
2614
2615
2622 CP1
2623 14
2624 200
2625 Success
2626 24
2627
2629 11. Security Considerations
2631 As a general consideration, we remark that the CLUE framework (and
2632 related protocol) has been conceived at the outset by embracing the
2633 security-by-design paradigm. This entails that a number of
2634 requirements have been identified and properly standardized as
2635 mandatory within the entire set of documents associated with the CLUE
2636 architecture. Requirements include: (i) the use of cryptography and
2637 authentication; (ii) protection of all sensitive fields; (iii) mutual
2638 authentication between CLUE endpoints; (iv) the presence of
2639 authorization mechanisms; (v) the presence of native defence
2640 mechanisms against malicious activities such as eavesdropping,
2641 selective modification, deletion, replay (and related combinations
2642 thereof). Hence, security of the single components of the CLUE
2643 solution cannot be evaluated independently of the integrated view of
2644 the final architecture.
2646 The CLUE protocol is an application-level protocol allowing a Media
2647 Producer and a Media Consumer to negotiate a variegated set of
2648 parameters associated with the establishment of a telepresence
2649 session. This unavoidably exposes a CLUE-enabled telepresence system
2650 to a number of potential threats, most of which are extensively
2651 discussed in the framework document [I-D.ietf-clue-framework]. The
2652 security considerations section of the mentioned document actually
2653 discusses issues associated with the setup and management of a
2654 telepresence session both in the basic case involving two CLUE
2655 endpoints acting, respectively, as MP and MC, and in the more
2656 advanced scenario envisaging the presence of an MCU.
2658 The framework document also mentions that the information carried
2659 within CLUE protocol messages might contain sensitive data, which
2660 SHOULD hence be accessed only by authenticated endpoints. Security
2661 issues associated with the CLUE data model schema are discussed in
2662 [I-D.ietf-clue-data-model-schema].
2664 There is extra information carried by the CLUE protocol which is not
2665 associated with the CLUE data model schema and which exposes
2666 information that might be of concern. This information is primarily
2667 exchanged during the negotiation phase via the 'options' and
2668 'optionsResponse' messages. In the CLUE Participant state machine
2669 OPTIONS state, both parties agree on the version and on the
2670 extensions to be used in the subsequent CLUE messages exchange phase.
2671 A malicious participant might either try to retrieve a detailed
2672 footprint of a specific CLUE protocol implementation during this
2673 initial setup phase, or force the communicating party to use a non-
2674 up-to-date version of the protocol which they know how to break.
2675 Indeed, exposing all of the supported versions and extensions could
2676 conceivably leak information about the specific implementation of the
2677 protocol. In theory an implementation could choose not to announce
2678 all of the versions it supports if it wants to avoid such leakage,
2679 though at the expenses of interoperability. With respect to the
2680 above considerations, it is noted that the OPTIONS state is only
2681 reached after the CLUE data channel has been successfully set up.
2682 This ensures that only authenticated parties can exchange 'options'
2683 and related 'optionsResponse' messages and hence drastically reduces
2684 the attack surface which is exposed to malicious parties.
2686 The CLUE framework clearly states the requirement to protect CLUE
2687 protocol messages against threats deriving from the presence of a
2688 malicious agent capable to gain access to the CLUE data channel.
2689 Such a requirement is met by the CLUE data channel solution described
2690 in [I-D.ietf-clue-datachannel], which ensures protection from both
2691 message recovery and message tampering. With respect to this last
2692 point, any implementation of the CLUE protocol compliant with the
2693 CLUE specification MUST rely on the exchange of messages which flow
2694 on top of a reliable and ordered SCTP over DTLS transport channel
2695 connecting two CLUE Participants.
2697 12. IANA Considerations
2699 This document registers a new XML namespace, a new XML schema and the
2700 MIME type for the schema. This document also registers the "CLUE"
2701 Application Service tag and the "CLUE" Application Protocol tag and
2702 defines registries for the CLUE messages and response codes.
2704 12.1. URN Sub-Namespace Registration
2706 This section registers a new XML namespace,
2707 ""urn:ietf:params:xml:ns:clue-protocol"".
2709 URI: urn:ietf:params:xml:ns:clue-protocol
2711 Registrant Contact: IESG (iesg@ietf.org).
2713 XML:
2715 BEGIN
2716
2717
2719
2720
2721 CLUE Messages
2722
2723
2724 Namespace for CLUE Messages
2725 urn:ietf:params:xml:ns:clue-protocol
2726 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2727 with the RFC number for this specification.]]
2728 See
2729 RFCXXXX.
2730
2731
2732 END
2734 12.2. XML Schema registration
2736 This section registers an XML schema per the guidelines in [RFC3688].
2738 URI: urn:ietf:params:xml:schema:clue-protocol
2740 Registrant Contact: IESG (iesg@ietf.org).
2742 Schema: The XML for this schema can be found as the entirety of
2743 Section 9 of this document.
2745 12.3. MIME Media Type Registration for 'application/clue+xml'
2747 This section registers the ""application/clue+xml"" MIME type.
2749 To: ietf-types@iana.org
2751 Subject: Registration of MIME media type application/clue+xml
2753 MIME media type name: application
2755 MIME subtype name: clue+xml
2757 Required parameters: (none)
2759 Optional parameters: charset
2760 Same as the charset parameter of "application/xml" as specified in
2761 [RFC7303], Section 3.2.
2763 Encoding considerations: Same as the encoding considerations of
2764 "application/xml" as specified in [RFC7303], Section 3.2.
2766 Security considerations: This content type is designed to carry
2767 protocol data related to telepresence session control. Some of the
2768 data could be considered private. This media type does not provide
2769 any protection and thus other mechanisms such as those described in
2770 Section Security are required to protect the data. This media type
2771 does not contain executable content.
2773 Interoperability considerations: None.
2775 Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please
2776 replace XXXX with the RFC number for this specification.]]
2778 Applications that use this media type: CLUE participants.
2780 Additional Information: Magic Number(s): (none),
2781 File extension(s): .xml,
2782 Macintosh File Type Code(s): TEXT.
2784 Person & email address to contact for further information: Simon
2785 Pietro Romano (spromano@unina.it).
2787 Intended usage: LIMITED USE
2789 Author/Change controller: The IETF
2791 Other information: This media type is a specialization of
2792 application/xml [RFC7303], and many of the considerations described
2793 there also apply to application/clue+xml.
2795 12.4. CLUE Protocol Registry
2797 The document requests that the IANA creates new registries for CLUE
2798 messages and response codes.
2800 12.4.1. CLUE Message Types
2802 The following summarizes the registry for CLUE messages:
2804 Related Registry: CLUE Message Types Registry
2806 Defining RFC: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace XXXX
2807 with the RFC number for this specification.]]
2808 Registration/Assignment Procedures: Following the policies outlined
2809 in [RFC8126], the IANA policy for assigning new values for the CLUE
2810 message types for the CLUE protocol is Specification Required.
2812 Registrant Contact: IESG (iesg@ietf.org).
2814 The initial Message table is populated using the CLUE messages
2815 described in Section 5 and defined in the XML schema in Section 9.
2817 +-------------------+-----------------------------------+-----------+
2818 | Message | Description | Reference |
2819 +-------------------+-----------------------------------+-----------+
2820 | options | Sent by the CI to the CR in the | RFCXXXX |
2821 | | initiation phase to specify the | |
2822 | | roles played by the CI, the | |
2823 | | supported versions and the | |
2824 | | supported extensions. | |
2825 | optionsResponse | Sent by the CI to the CR in reply | RFCXXXX |
2826 | | to an 'options' message to | |
2827 | | finally estabilsh the version and | |
2828 | | the extensions to be used in the | |
2829 | | following CLUE messages exchange. | |
2830 | advertisement | Sent by the MP to the MC to | RFCXXXX |
2831 | | specify the telepresence | |
2832 | | capabilities of the MP expressed | |
2833 | | according to the CLUE framework. | |
2834 | ack | Sent by the MC to the MP to | RFCXXXX |
2835 | | acknowledge the reception of an | |
2836 | | 'advertisement' message. | |
2837 | configure | Sent by the MC to the MP to | RFCXXXX |
2838 | | specify the desired media | |
2839 | | captures among those specified in | |
2840 | | the 'advertisement'. | |
2841 | configureResponse | Sent by the MP to the MC in reply | RFCXXXX |
2842 | | to a CONFIGURE message to | |
2843 | | communicate if the configuration | |
2844 | | request has been successfully | |
2845 | | processed or not. | |
2846 +-------------------+-----------------------------------+-----------+
2848 IANA-CLUE
2850 12.4.2. CLUE Response Codes
2852 The following summarizes the requested registry for CLUE response
2853 codes:
2855 Related Registry: CLUE Response Code Registry
2856 Defining RFC: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace XXXX
2857 with the RFC number for this specification.]]
2859 Registration/Assignment Procedures: Following the policies outlined
2860 in [RFC8126], the IANA policy for assigning new values for the
2861 Response codes for CLUE shall be Specification Required.
2863 Registrant Contact: IESG (iesg@ietf.org).
2865 The initial Response-code table is populated using the Response codes
2866 defined in Section 5.7 as follows:
2868 +--------+---------------+------------------------------+-----------+
2869 | Number | Default | Description | Reference |
2870 | | Response | | |
2871 | | String | | |
2872 +--------+---------------+------------------------------+-----------+
2873 | 200 | Success | The request has been | RFCXXXX |
2874 | | | successfully processed. | |
2875 | 300 | Low-level | A generic low-level request | RFCXXXX |
2876 | | request | error has occurred. | |
2877 | | error. | | |
2878 | 301 | Bad syntax | The XML syntax of the | RFCXXXX |
2879 | | | message is not correct. | |
2880 | 302 | Invalid value | The message contains an | RFCXXXX |
2881 | | | invalid parameter value. | |
2882 | 303 | Conficting | The message contains values | RFCXXXX |
2883 | | values | that cannot be used | |
2884 | | | together. | |
2885 | 400 | Semantic | Semantic errors in the | RFCXXXX |
2886 | | errors | received CLUE protocol | |
2887 | | | message. | |
2888 | 401 | Version not | The protocol version used in | RFCXXXX |
2889 | | supported | the message is not | |
2890 | | | supported. | |
2891 | 402 | Invalid | Sequence number gap; | RFCXXXX |
2892 | | sequencing | repeated sequence number; | |
2893 | | | sequence number outdated. | |
2894 | 403 | Invalid | The clueId used in the | RFCXXXX |
2895 | | identifier | message is not valid or | |
2896 | | | unknown. | |
2897 | 404 | advertisement | The sequence number of the | RFCXXXX |
2898 | | Expired | advertisement the configure | |
2899 | | | refers to is out of date. | |
2900 | 405 | Subset choice | The subset choice is not | RFCXXXX |
2901 | | not allowed | allowed for the specified | |
2902 | | | Multiple Content Capture. | |
2903 +--------+---------------+------------------------------+-----------+
2905 13. Acknowledgments
2907 The authors thank all the CLUErs for their precious feedbacks and
2908 support, in particular Paul Kyzivat, Christian Groves and Scarlett
2909 Liuyan.
2911 14. References
2913 14.1. Normative References
2915 [I-D.ietf-clue-data-model-schema]
2916 Presta, R. and S. Romano, "An XML Schema for the CLUE data
2917 model", draft-ietf-clue-data-model-schema-17 (work in
2918 progress), August 2016.
2920 [I-D.ietf-clue-datachannel]
2921 Holmberg, C., "CLUE Protocol data channel", draft-ietf-
2922 clue-datachannel-15 (work in progress), August 2018.
2924 [I-D.ietf-clue-framework]
2925 Duckworth, M., Pepperell, A., and S. Wenger, "Framework
2926 for Telepresence Multi-Streams", draft-ietf-clue-
2927 framework-25 (work in progress), January 2016.
2929 [I-D.ietf-clue-signaling]
2930 Hansen, R., Kyzivat, P., Xiao, L., and C. Groves, "Session
2931 Signaling for Controlling Multiple Streams for
2932 Telepresence (CLUE)", draft-ietf-clue-signaling-13 (work
2933 in progress), November 2017.
2935 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2936 Requirement Levels", BCP 14, RFC 2119,
2937 DOI 10.17487/RFC2119, March 1997,
2938 .
2940 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
2941 Jacobson, "RTP: A Transport Protocol for Real-Time
2942 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
2943 July 2003, .
2945 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
2946 DOI 10.17487/RFC3688, January 2004,
2947 .
2949 [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303,
2950 DOI 10.17487/RFC7303, July 2014,
2951 .
2953 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
2954 Writing an IANA Considerations Section in RFCs", BCP 26,
2955 RFC 8126, DOI 10.17487/RFC8126, June 2017,
2956 .
2958 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2959 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
2960 May 2017, .
2962 14.2. Informative References
2964 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
2965 Communication Layers", STD 3, RFC 1122,
2966 DOI 10.17487/RFC1122, October 1989,
2967 .
2969 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the
2970 Session Initiation Protocol (SIP)", RFC 4353,
2971 DOI 10.17487/RFC4353, February 2006,
2972 .
2974 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
2975 DOI 10.17487/RFC5117, January 2008,
2976 .
2978 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
2979 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
2980 March 2011, .
2982 [RFC7262] Romanow, A., Botzko, S., and M. Barnes, "Requirements for
2983 Telepresence Multistreams", RFC 7262,
2984 DOI 10.17487/RFC7262, June 2014,
2985 .
2987 [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
2988 DOI 10.17487/RFC7667, November 2015,
2989 .
2991 Authors' Addresses
2993 Roberta Presta
2994 University of Napoli
2995 Via Claudio 21
2996 Napoli 80125
2997 Italy
2999 EMail: roberta.presta@unina.it
3000 Simon Pietro Romano
3001 University of Napoli
3002 Via Claudio 21
3003 Napoli 80125
3004 Italy
3006 EMail: spromano@unina.it