idnits 2.17.1
draft-ietf-clue-protocol-15.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 (April 11, 2018) is 2204 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 1348, but not defined
== Missing Reference: '0-9' is mentioned on line 1354, but not defined
== Unused Reference: 'RFC7667' is defined on line 2709, but no explicit
reference was found in the text
== Outdated reference: A later version (-18) exists of
draft-ietf-clue-datachannel-14
** 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 normative reference: RFC 5226 (Obsoleted by RFC 8126)
-- Obsolete informational reference (is this intentional?): RFC 5117
(Obsoleted by RFC 7667)
Summary: 3 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: October 13, 2018 April 11, 2018
7 Protocol for Controlling Multiple Streams for Telepresence (CLUE)
8 draft-ietf-clue-protocol-15
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 October 13, 2018.
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 . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . . . . . 24
73 8. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 25
74 8.1. Extension example . . . . . . . . . . . . . . . . . . . . 27
75 9. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 29
76 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 34
77 10.1. Simple 'advertisement' . . . . . . . . . . . . . . . . . 34
78 10.2. 'advertisement' with Multiple Content Captures . . . . . 42
79 11. Security Considerations . . . . . . . . . . . . . . . . . . . 52
80 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
81 12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 53
82 12.2. XML Schema registration . . . . . . . . . . . . . . . . 54
83 12.3. MIME Media Type Registration for 'application/clue+xml' 54
84 12.4. CLUE Protocol Registry . . . . . . . . . . . . . . . . . 55
85 12.4.1. CLUE Message Types . . . . . . . . . . . . . . . . . 55
86 12.4.2. CLUE Response Codes . . . . . . . . . . . . . . . . 56
87 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58
88 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 58
89 14.1. Normative References . . . . . . . . . . . . . . . . . . 58
90 14.2. Informative References . . . . . . . . . . . . . . . . . 59
91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59
93 1. Introduction
95 The CLUE protocol is an application protocol used by two CLUE
96 Participants to enhance the experience of a multimedia telepresence
97 session. The main goals of the CLUE protocol are:
99 1. enabling a Media Provider (MP) to properly announce its current
100 telepresence capabilities to a Media Consumer (MC) in terms of
101 available media captures, groups of encodings, simultaneity
102 constraints and other information defined in
103 [I-D.ietf-clue-framework];
105 2. enabling an MC to request the desired multimedia streams from the
106 offering MP.
108 CLUE-capable endpoints are connected by means of the CLUE data
109 channel, an SCTP over DTLS channel which is opened and established as
110 described in [I-D.ietf-clue-signaling] and
111 [I-D.ietf-clue-datachannel]. CLUE protocol messages flowing over
112 such a channel are detailed in this document, both syntactically and
113 semantically.
115 In Section 4 we provide a general overview of the CLUE protocol.
116 CLUE protocol messages are detailed in Section 5. The CLUE Protocol
117 state machines are introduced in Section 6. Versioning and
118 extensions are discussed in Section 7 and Section 8, respectively.
119 The XML schema defining the CLUE messages is reported in Section 9.
121 2. Terminology
123 This document refers to the same terminology used in
124 [I-D.ietf-clue-framework] and in [RFC7262]. We briefly recall herein
125 some of the main terms used in the document. The definition of "CLUE
126 Participant" herein proposed is not imported from any of the above
127 documents.
129 Capture Encoding: A specific encoding of a Media Capture, to be sent
130 via RTP [RFC3550].
132 CLUE Participant (CP): An entity able to use the CLUE protocol
133 within a telepresence session. It can be an endpoint or an MCU
134 able to use the CLUE protocol.
136 CLUE-capable device: A device that supports the CLUE data channel
137 [I-D.ietf-clue-datachannel], the CLUE protocol and the principles
138 of CLUE negotiation, and seeks CLUE-enabled calls.
140 Endpoint: A CLUE-capable device which is the logical point of final
141 termination through receiving, decoding and rendering, and/or
142 initiation through capturing, encoding, and sending of media
143 streams. An endpoint consists of one or more physical devices
144 which source and sink media streams, and exactly one [RFC4353]
145 Participant (which, in turn, includes exactly one SIP User Agent).
146 Endpoints can be anything from multiscreen/multicamera rooms to
147 handheld devices.
149 MCU: a CLUE-capable device that connects two or more endpoints
150 together into one single multimedia conference [RFC5117]. An MCU
151 includes an [RFC4353]-like Mixer, without the [RFC4353]
152 requirement to send media to each participant.
154 Media: Any data that, after suitable encoding, can be conveyed over
155 RTP, including audio, video or timed text.
157 Media Capture: a source of Media, such as from one or more Capture
158 Devices or constructed from other Media streams.
160 Media Consumer (MC): A CLUE Participant (i.e., an Endpoint or an
161 MCU) able to receive Capture Encodings.
163 Media Provider (MP): A CLUE Participant (i.e., an Endpoint or an
164 MCU) able to send Capture Encodings.
166 Stream: a Capture Encoding sent from a Media Provider to a Media
167 Consumer via RTP [RFC3550].
169 3. Conventions
171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
173 "OPTIONAL" in this document are to be interpreted as described in BCP
174 14 [RFC2119] [RFC8174] when, and only when, they appear in all
175 capitals, as shown here.
177 4. Overview of the CLUE protocol
179 The CLUE protocol is conceived to enable CLUE telepresence sessions.
180 It is designed in order to address SDP limitations in terms of the
181 description of some information about the multimedia streams that are
182 involved in a real-time multimedia conference. Indeed, by simply
183 using SDP it is not possible to convey information about the features
184 of the flowing multimedia streams that are needed to enable a "being
185 there" rendering experience. Such information is contained in the
186 CLUE framework document [I-D.ietf-clue-framework] and formally
187 defined and described in the CLUE data model document
189 [I-D.ietf-clue-data-model-schema]. The CLUE protocol represents the
190 mechanism for the exchange of telepresence information between CLUE
191 Participants. It mainly provides the messages to enable a Media
192 Provider to advertise its telepresence capabilities and to enable a
193 Media Consumer to select the desired telepresence options.
195 The CLUE protocol, as defined in the following, is a stateful,
196 client-server, XML-based application protocol. CLUE protocol
197 messages flow on a reliable and ordered SCTP over DTLS transport
198 channel connecting two CLUE Participants. Messages carry information
199 taken from the XML-based CLUE data model
200 ([I-D.ietf-clue-data-model-schema]). Three main communication phases
201 can be identified:
203 1. Establishment of the CLUE data channel: in this phase, the CLUE
204 data channel setup takes place. If it completes successfully,
205 the CPs are able to communicate and start the initiation phase.
207 2. Negotiation of the CLUE protocol version and extensions
208 (initiation phase): the CPs connected via the CLUE data channel
209 agree on the version and on the extensions to be used during the
210 telepresence session. Special CLUE messages are used for such a
211 task ('options' and 'optionsResponse'). The version and
212 extensions negotiation can be performed once during the CLUE
213 session and only at this stage. At the end of that basic
214 negotiation, each CP starts its activity as a CLUE MP and/or CLUE
215 MC.
217 3. CLUE telepresence capabilities description and negotiation: in
218 this phase, the MP-MC dialogues take place on the data channel by
219 means of the CLUE protocol messages.
221 As soon as the channel is ready, the CLUE Participants must agree on
222 the protocol version and extensions to be used within the
223 telepresence session. CLUE protocol version numbers are
224 characterized by a major version number (single digit) and a minor
225 version number (single digit), both unsigned integers, separated by a
226 dot. While minor version numbers denote backward compatible changes
227 in the context of a given major version, different major version
228 numbers generally indicate a lack of interoperability between the
229 protocol implementations. In order to correctly establish a CLUE
230 dialogue, the involved CPs MUST have in common a major version number
231 (see Section 7 for further details). The subset of the extensions
232 that are allowed within the CLUE session is also determined in the
233 initiation phase, such subset being the one including only the
234 extensions that are supported by both parties. A mechanism for the
235 negotiation of the CLUE protocol version and extensions is part of
236 the initial phase. According to such a solution, the CP which is the
237 CLUE Channel initiator (CI) issues a proper CLUE message ('options')
238 to the CP which is the Channel Receiver (CR) specifying the supported
239 version and extensions. The CR then answers by selecting the subset
240 of the CI extensions that it is able to support and determines the
241 protocol version to be used.
243 After the negotiation phase is completed, CLUE Participants describe
244 and agree on the media flows to be exchanged. In many cases CPs will
245 seek to both transmit and receive media. Hence in a call between two
246 CPs, A and B, there would be two separate dialogs, as follows:
248 1. the one needed to describe and set up the media streams sent from
249 A to B, i.e., the dialogue between A's Media Provider side and
250 B's Media Consumer side
252 2. the one needed to describe and set up the media streams sent from
253 B to A, i.e., the dialogue between B's Media Provider side and
254 A's Media Consumer side
256 CLUE messages for the media session description and negotiation are
257 designed by considering the MP side as the server side of the
258 protocol, since it produces and provides media streams, and the MC
259 side as the client side of the protocol, since it requests and
260 receives media streams. The messages that are exchanged to set up
261 the telepresence media session are described by focusing on a single
262 MP-MC dialogue.
264 The MP first advertises its available media captures and encoding
265 capabilities to the MC, as well as its simultaneity constraints,
266 according to the information model defined in
267 [I-D.ietf-clue-framework]. The CLUE message conveying the MP's
268 multimedia offer is the 'advertisement' message. Such message
269 leverages the XML data model definitions provided in
270 [I-D.ietf-clue-data-model-schema].
272 The MC selects the desired streams of the MP by using the 'configure'
273 message, which makes reference to the information carried in the
274 previously received 'advertisement'.
276 Besides 'advertisement' and 'configure', other messages have been
277 conceived in order to provide all the needed mechanisms and
278 operations. Such messages are detailed in the following sections.
280 5. Protocol messages
282 CLUE protocol messages are textual, XML-based messages that enable
283 the configuration of the telepresence session. The formal definition
284 of such messages is provided in the XML Schema provided at the end of
285 this document (Section 9). This section includes non-normative
286 excerpts of the schema to aid in describing it.
288 The XML definitions of the CLUE information provided in
289 [I-D.ietf-clue-data-model-schema] are included within some CLUE
290 protocol messages (namely the 'advertisement' and the 'configure'
291 messages), in order to use the concepts defined in
292 [I-D.ietf-clue-framework].
294 The CLUE protocol messages are the following:
296 o options
298 o optionsResponse
300 o advertisement
302 o ack
304 o configure
306 o configureResponse
308 While the 'options' and 'optionsResponse' messages are exchanged in
309 the initiation phase between the CPs, the other messages are involved
310 in MP-MC dialogues.
312 Each CLUE message inherits a basic structure depicted in the
313 following excerpt (Figure 1):
315
316
317
318
319
320
322
323
325
326
327
328
329
330
332 Figure 1: Structure of a CLUE message
334 The information contained in each CLUE message is:
336 o clueId: an optional XML element containing the identifier (in the
337 form of a generic string) of the CP within the telepresence
338 system;
340 o sequenceNr: an XML element containing the local message sequence
341 number. The sender must increment the sequence numbers by one for
342 each new message sent, the receiver must remember the most recent
343 sequence number received and send back a 402 error if it receives
344 a message with an unexpected sequence number (e.g., sequence
345 number gap, repeated sequence number, sequence number too small).
346 The initial sequence number can be chosen randomly by each party;
348 o protocol: a mandatory attribute set to "CLUE", identifying the
349 procotol the messages refer to;
351 o v: a mandatory attribute carrying the version of the protocol.
352 The content of the "v" attribute is composed by the major version
353 number followed by a dot and then by the minor version number of
354 the CLUE protocol in use. The major number cannot be "0" and, if
355 it is more than one digit, it cannot start with a "0". Allowed
356 values are of this kind are, e.g., "1.3", "2.0", "20.44" etc.
357 This document describes version 1.0.
359 Each CP is responsible for creating and updating up to three
360 independent streams of sequence numbers in messages it sends: (i) one
361 for the messages sent in the initiation phase, (ii) one for the
362 messages sent as MP (if it is acting as a MP), and (iii) one for the
363 messages sent as MC (if it is acting as a MC).
365 5.1. options
367 The 'options' message is sent by the CLUE Participant which is the
368 Channel Initiator to the CLUE Participant which is the Channel
369 Receiver as soon as the CLUE data channel is ready. Besides the
370 information envisioned in the basic structure, it specifies:
372 o : a mandatory boolean field set to "true" if the CP
373 is able to act as a MP
375 o : a mandatory boolean field set to "true" if the CP
376 is able to act as a MC
378 o : the list of the supported versions
380 o : the list of the supported extensions
382 The XML Schema of such a message is reported below (Figure 2):
384
385
386
387
388
389
390
391
393
395
397
398
399
400
401
403
404
405
406
408
410
411
412
414
415
416
417
419
420
421
422
424
425
426
427
428
429
430
431
432
433
435 Figure 2: Structure of CLUE 'options' message
437 contains the list of the versions that are
438 supported by the CI, each one represented in a child
439 element. The content of each element is a string made by
440 the major version number followed by a dot and then by the minor
441 version number (e.g., 1.3 or 2.4). Exactly one element
442 MUST be provided for each major version supported, containing the
443 maximum minor version number of such a version, since all minor
444 versions are backward compatible. If no is
445 carried within the 'options' message, the CI supports only the
446 version declared in the "v" attribute and all the versions having the
447 same major version number and lower minor version number. For
448 example, if the "v" attribute has a value of "3.4" and there is no
449 tag in the 'options' message, it means the CI
450 supports only major version 3 with all the minor versions comprised
451 between 3.0 and 3.4, with version 3.4 included. If a
452 is provided, at least one tag MUST be
453 included. In this case, the "v" attribute SHOULD be set to he
454 largest minor version of the smallest major version advertised in the
455 list. Indeed, the intention behind the "v"
456 attribute is that some implementation that receives a version number
457 in the "v" field with a major number higher than it understands is
458 supposed to close the connection, since it runs a risk of
459 misinterpreting the contents of messages. The minor version is
460 obviously less useful in this context, since minor versions are
461 defined to be both backwards and forwards compatible, but it is more
462 useful to know the highest minor version supported than some random
463 minor version, as it indicates the full feature set that is
464 supported. The reason why it is less useful is that the value can in
465 any case be parsed out of the list.
467 The element specifies the list of extensions
468 supported by the CI. If there is no in the
469 'options' message, the CI does not support anything other than what
470 is envisioned in the versions it supports. For each extension, an
471 element is provided. An extension is characterized by a
472 name, an XML schema of reference where the extension is defined, and
473 the version of the protocol which the extension refers to.
475 5.2. optionsResponse
477 CLUE response messages ('optionsResponse', 'ack',
478 'configureResponse') derive from a base type, which is defined as
479 follows (Figure 3):
481
482
483
484
485
486
487
488
489
490
492 Figure 3: Structure of CLUE response messages
494 The elements and get populated as
495 detailed in Section 5.7
497 The 'optionsResponse' (Figure 4) is sent by a CR to a CI as a reply
498 to the 'options' message. The 'optionsResponse' contains a mandatory
499 response code and a reason string indicating the processing result of
500 the 'options' message. If the responseCode is between 200 and 299
501 inclusive, the response MUST also include ,
502 , and elements; it MAY
503 include them for any other response code. and
504 elements are associated with the supported roles (in
505 terms of, respectively MP and MC), similarly to what the CI does in
506 the 'options' message. The field indicates the highest
507 commonly supported version number. The content of the
508 element MUST be a string made of the major version number followed by
509 a dot and then by the minor version number (e.g., 1.3 or 2.4).
510 Finally, the commonly supported extensions are copied in the
511 field.
513
514
515
516
517
518
520
522
523
525
527
528
529
530
531
533 Figure 4: Structure of CLUE 'optionsResponse' message
535 Upon reception of the 'optionsResponse' the version to be used is
536 provided in the tag of the message. The following CLUE
537 messages MUST use such a version number in the "v" attribute. The
538 allowed extensions in the CLUE dialogue are those indicated in the
539 of the 'optionsResponse' message.
541 5.3. advertisement
543 The 'advertisement' message is used by the MP to advertise the
544 available media captures and related information to the MC. The MP
545 sends an 'advertisement' to the MC as soon as it is ready after the
546 successful completion of the initiation phase, i.e., as soon as the
547 version and the extensions of the CLUE protocol are agreed between
548 the CPs. During a single CLUE session, an MP may send new
549 'advertisement' messages to replace the previous advertisement, if,
550 for instance, its CLUE telepresence media capabilities change mid-
551 call. A new 'advertisement' completely replaces the previous
552 'advertisement'.
554 The 'advertisement' structure is defined in the schema excerpt below
555 (Figure 5). The 'advertisement' contains elements compliant with the
556 CLUE data model that characterize the MP's telepresence offer.
557 Namely, such elements are: the list of the media captures
558 (), of the encoding groups (), of the
559 capture scenes (), of the simultaneous sets
560 (), of the global views (), and of the
561 represented participants (). Each of them is fully described
562 in the CLUE framework document and formally defined in the CLUE data
563 model document.
565
566
567
568
569
570
571
572
573
574
575
577
579
580
582
583
584
585
586
588 Figure 5: Structure of CLUE 'advertisement' message
590 5.4. ack
592 The 'ack' message is sent by a MC to a MP to acknowledge an
593 'advertisement' message. As it can be seen from the message schema
594 provided in the following excerpt (Figure 6), the 'ack' contains a
595 response code and a reason string for describing the processing
596 result of the 'advertisement'. The carries the
597 sequence number of 'advertisement' message the 'ack' refers to.
599
600
601
602
603
604
605
607
608
609
610
611
613 Figure 6: Structure of CLUE 'ack' message
615 5.5. configure
617 The 'configure' message is sent from a MC to a MP to list the
618 advertised captures the MC wants to receive. The MC can send a
619 'configure' after the reception of an 'advertisement' or each time it
620 wants to request other captures that have been previously advertised
621 by the MP. The content of the 'configure' message is shown below
622 (Figure 7).
624
625
626
627
628
629
630
631
633
635
637
638
639
640
641
643 Figure 7: Structure of CLUE 'configure' message
645 The element contains the sequence number of the
646 'advertisement' message the 'configure' refers to.
648 The optional element, when present, contains a success response
649 code, as defined in Section 5.7. It indicates that the 'configure'
650 message also acknowledges with success the referred advertisement
651 ('configure' + 'ack' message), by applying in that way a piggybacking
652 mechanism for simultaneously acknowledging and replying to the
653 'advertisement' message. The element MUST NOT be present if an
654 'ack' message has been already sent back to the MP.
656 The most important content of the 'configure' message is the list of
657 the capture encodings provided in the element (see
658 [I-D.ietf-clue-data-model-schema] for the definition of
659 ). Such an element contains a sequence of capture
660 encodings, representing the streams to be instantiated.
662 5.6. configureResponse
664 The 'configureResponse' message is sent from the MP to the MC to
665 communicate the processing result of requests carried in the
666 previously received 'configure' message. It contains (Figure 8) a
667 response code with a reason string indicating either the success or
668 the failure (along with failure details) of a 'configure' request
669 processing. Following, the field contains the
670 sequence number of the 'configure' message the response refers to.
672 There is no partial execution of commands. As an example, if a MP is
673 able to understand all the selected capture encodings except one,
674 then the whole command fails and nothing is instantiated.
676
677
678
679
680
681
682
684
685
686
687
688
690 Figure 8: Structure of CLUE 'configureResponse' message
692 5.7. Response codes and reason strings
694 Response codes are defined as a sequence of three digits. A well-
695 defined meaning is associated with the first digit. Response codes
696 beginning with "2" are associated with successful responses.
697 Response codes that do not begin with either "2" or "1" indicate an
698 error response, i.e., that an error occurred while processing a CLUE
699 request. In particular, response codes beginning with "3" indicate
700 problems with the XML content of the message ("Bad syntax", "Invalid
701 value", etc.), while response codes beginning with "4" refer to
702 problems related to CLUE protocol semantics ("Invalid sequencing",
703 "Version not supported", etc.). 200, 300 and 400 codes are
704 considered catch-alls. Further response codes can be either defined
705 in future versions of the protocol (by adding them to the related
706 IANA registry), or defined by leveraging the extension mechanism. In
707 both cases, the new response codes MUST be registered with IANA.
708 Such new response codes MUST NOT overwrite the ones here defined and
709 they MUST respect the semantics of the first code digit.
711 This document does not define response codes starting with "1", and
712 such response codes are not allowed to appear in major version 1 of
713 the CLUE protocol. The range from 100 to 199 inclusive is reserved
714 for future major versions of the protocol to define response codes
715 for delayed or incomplete operations if necessary. Response codes
716 starting with "5" through "9" are reserved for future major versions
717 of the protocol to define new classes of response, and are not
718 allowed in major version 1 of the CLUE protocol. Response codes
719 starting with "0" are not allowed.
721 The response codes and strings defined for use with version 1 of the
722 CLUE protocol are listed in Figure 9. The "Description" text
723 contained in the table can be sent in the element of a
724 response message. Implementations can (and are encouraged to)
725 include more specific descriptions of the error condition, if
726 possible.
728 +-----------------+----------------------+--------------------------+
729 | | | |
730 | Response code | Reason string | Description |
731 | | | |
732 +-----------------+----------------------+--------------------------+
733 | | | |
734 | 200 | Success | The request has been |
735 | | | successfully processed. |
736 | | | |
737 +-----------------+----------------------+--------------------------+
738 | | | |
739 | 300 | Low-level request | A generic low-level |
740 | | error. | request error has |
741 | | | occurred. |
742 | | | |
743 +-----------------+----------------------+--------------------------+
744 | | | |
745 | 301 | Bad syntax | The XML syntax of the |
746 | | | message is not correct. |
747 +-----------------+----------------------+--------------------------+
748 | | | |
749 | 302 | Invalid value | The message |
750 | | | contains an invalid |
751 | | | parameter value. |
752 +-----------------+----------------------+--------------------------+
753 | | | |
754 | 303 | Conflicting values | The message |
755 | | | contains values that |
756 | | | cannot be used together.|
757 +-----------------+----------------------+--------------------------+
758 | | | |
759 | 400 | Semantic errors | Semantic errors in the |
760 | | | received CLUE protocol |
761 | | | message. |
762 | | | |
763 +-----------------+----------------------+--------------------------+
764 | | | |
765 | 401 | Version not supported| The protocol version |
766 | | | used in the message |
767 | | | is not supported. |
768 | | | |
769 +-----------------+----------------------+--------------------------+
770 | | | |
771 | 402 | Invalid sequencing | Sequence number gap; |
772 | | | repeated sequence number;|
773 | | | sequence number outdated.|
774 +-----------------+----------------------+--------------------------+
775 | | | |
776 | 403 | Invalid identifier | The clueId used in |
777 | | | the message is |
778 | | | not valid or unknown. |
779 +-----------------+----------------------+--------------------------+
780 | | | The sequence number of |
781 | 404 | advertisement | the advertisement the |
782 | | Expired | configure refers to is |
783 | | | out of date. |
784 +-----------------+----------------------+--------------------------+
785 | | | |
786 | 405 | Subset choice not | The subset choice is not |
787 | | allowed | allowed for the specified|
788 | | | Multiple Content Capture |
789 +-----------------+----------------------+--------------------------+
791 Figure 9: CLUE response codes
793 6. Protocol state machines
795 The CLUE protocol is an application protocol used between two CPs in
796 order to properly configure a multimedia telepresence session. CLUE
797 protocol messages flow over the CLUE Data Channel, a DTLS/SCTP
798 channel established as depicted in [I-D.ietf-clue-datachannel]. We
799 herein discuss the state machines associated, respectively, with the
800 CLUE Participant (Figure 10), with the MC process (Figure 11) and
801 with the MP process (Figure 12). Endpoints often wish to both send
802 and receive media, i.e., act as both MP and MC. As such there will
803 often be two sets of messages flowing in opposite directions; the
804 state machines of these two flows do not interact with each other.
805 Only the CLUE application logic is considered. The interaction of
806 CLUE protocol and SDP negotiations for the media streams exchanged is
807 treated in [I-D.ietf-clue-signaling].
809 The main state machines focus on the behavior of the CLUE Participant
810 (CP) acting as a CLUE channel initiator/receiver (CI/CR).
812 The initial state is the IDLE one. When in the IDLE state, the CLUE
813 data channel is not established and no CLUE-controlled media are
814 exchanged between the two considered CLUE-capable devices (if there
815 is an ongoing exchange of media streams, such media streams are not
816 currently CLUE-controlled).
818 When the CLUE data channel set up starts ("start channel"), the CP
819 moves from the IDLE state to the CHANNEL SETUP state.
821 If the CLUE data channel is successfully set up ("channel
822 established"), the CP moves from the CHANNEL SETUP state to the
823 OPTIONS state. Otherwise if "channel error", it moves back to the
824 IDLE state. The same transition happens if the CLUE-enabled
825 telepresence session ends ("session ends"), i.e., when an SDP
826 negotiation for removing the CLUE data channel is performed.
828 When in the OPTIONS state, the CP addresses the initiation phase
829 where both parts agree on the version and on the extensions to be
830 used in the subsequent CLUE messages exchange phase. If the CP is
831 the Channel Initiator (CI), it sends an 'options' message and waits
832 for the 'optionsResponse' message. If the CP is the Channel Receiver
833 (CR), it waits for the 'options' message and, as soon as it arrives,
834 replies with the 'optionsResponse' message. If the negotiation is
835 successfully completed ("OPTIONS phase success"), the CP moves from
836 the OPTIONS state to the ACTIVE state. If the initiation phase fails
837 ("OPTIONS phase failure"), the CP moves from the OPTIONS state to the
838 IDLE state. The initiation phase might fail because of one of the
839 following reasons:
841 1. the CI receives an 'optionsResponse' with an error response code
843 2. the CI does not receive any 'optionsResponse' and a timeout error
844 is raised
846 3. the CR does not receive any 'options' and a timeout error is
847 raised
849 When in the ACTIVE state, the CP starts the envisioned sub-state
850 machines (i.e., the MP state machine and the MC state machine)
851 according to the roles it plays in the telepresence sessions. Such
852 roles have been previously declared in the 'options' and
853 'optionsResponse' messages involved in the initiation phase (see
854 OPTIONS sections Section 5.1 and Section 5.2 for the details). When
855 in the ACTIVE state, the CP delegates the sending and the processing
856 of the CLUE messages to the appropriate MP/MC sub-state machines. If
857 the CP receives a further 'options'/'optionsResponse' message, it
858 MUST ignore the message and stay in the ACTIVE state.
860 +----+
861 +---------------------->|IDLE|<----------------------------+
862 | +-+--+ |
863 | | |
864 | | start |
865 | | channel |
866 | v |
867 | channel error/ +--------+ |
868 | session ends | CHANNEL| |
869 +----------------------+ SETUP | |
870 | +--+-----+ |
871 | | |
872 | | channel |
873 | | established |
874 | channel error/ v OPTIONS phase |
875 | session ends +-------+ failure |
876 +-----------------------+OPTIONS+--------------------------+
877 | +-+-----+
878 | |
879 | | OPTIONS phase
880 | | success
881 | v
882 | channel error/ +---------+
883 | session ends | ACTIVE |
884 +----------------------+ |
885 | +----+ +------------------+
886 | | MP | | send/receive |
887 | +----+ | CLUE messages |
888 | |<-----------------+
889 | +----+ |
890 | | MC | |
891 | +----+ |
892 | |
893 +---------+
895 Figure 10: CLUE Participant state machine
897 6.1. Media Provider's state machine
899 As soon as the sub-state machine of the MP (Figure 11) is activated,
900 it is in the ADV state. In the ADV state, the MP prepares the
901 'advertisement' message reflecting its actual telepresence
902 capabilities.
904 After the 'advertisement' has been sent ("advertisement sent"), the
905 MP moves from the ADV state to the WAIT FOR ACK state. If an 'ack'
906 message with a successful response code arrives ("ack received"), the
907 MP moves to the WAIT FOR CONF state. If a NACK arrives (i.e., an
908 'ack' message with an error response code), the MP moves back to the
909 ADV state for preparing a new 'advertisement'. When in the WAIT FOR
910 ACK state, if a 'configure' message with the element set to
911 TRUE arrives ("configure+ack received"), the MP goes directly to the
912 CONF RESPONSE state. 'configure+ack' messages referring to out-of-
913 date (i.e., having a sequence number equal to or less than the
914 highest seen so far) advertisements MUST be ignored, i.e., they do
915 not trigger any state transition. If the telepresence settings of
916 the MP change while in the WAIT FOR ACK state ("changed telepresence
917 settings"), the MP switches from the WAIT FOR ACK state to the ADV
918 state to create a new 'advertisement'.
920 When in the WAIT FOR CONF state, the MP listens to the channel for a
921 'configure' request coming from the MC. When a 'configure' arrives
922 ("configure received"), the MP switches to the CONF RESPONSE state.
923 If the telepresence settings change in the meanwhile ("changed
924 telepresence settings"), the MP moves from the WAIT FOR CONF back to
925 the ADV state to create the new 'advertisement' to be sent to the MC.
927 The MP in the CONF RESPONSE state processes the received 'configure'
928 in order to produce a 'configureResponse' message. If the MP
929 successfully processes the MC's configuration, then it sends a 200
930 'configureResponse' ("success configureResponse sent") and moves to
931 the ESTABLISHED state. If there are errors in the 'configure'
932 processing, then the MP issues a 'configureResponse' carrying an
933 error response code and it goes back to the WAIT FOR CONF state to
934 wait for a new configuration request. Finally, if there are changes
935 in the MP's telepresence settings ("changed telepresence settings"),
936 the MP switches to the ADV state.
938 The MP in the ESTABLISHED state has successfully negotiated the media
939 streams with the MC by means of the CLUE messages. If there are
940 changes in the MP's telepresence settings ("changed telepresence
941 settings"), the MP moves back to the ADV state. In the ESTABLISHED
942 state, the CLUE-controlled media streams of the session are those
943 described in the last successfully processed 'configure' message.
945 +-----+
946 +------------>| ADV |<-------------------+
947 | +-+---+ |
948 | advertisement| NACK received |
949 | sent| |
950 | v |
951 changed| +--------+ |
952 telepresence+-------------+WAIT FOR+-----------------+
953 settings| +----------+ ACK |
954 | |configure +-+------+
955 | | + ack |
956 | |received |ack received
957 | | v
958 | | +--------+
959 +-------------+WAIT FOR|
960 | | | CONF |
961 | | +-+------+<-----------------------------+
962 | | | |
963 | | |configure received |
964 | | v |
965 | +--------->+---------+ error configureResponse sent|
966 +-------------+CONF |-----------------------------+
967 | +--------->|RESPONSE +
968 | | +---------+
969 | | |
970 | | |success
971 | | |configureResponse
972 | | |sent
973 | | |
974 | | |
975 | |configure |
976 | |received v
977 | | +-----------+
978 | +----------+ESTABLISHED|
979 +-------------+-----------+
981 Figure 11: Media Provider's state machine
983 6.2. Media Consumer's state machine
985 As soon as the sub-state machine of the MC (Figure 12) is activated,
986 it is in the WAIT FOR ADV state. An MC in the WAIT FOR ADV state is
987 waiting for an 'advertisement' coming from the MP. If the
988 'advertisement' arrives ("ADV received"), the MC reaches the ADV
989 PROCESSING state. Otherwise, the MC stays in the WAIT FOR ADV state.
991 In the ADV PROCESSING state, the 'advertisement' is parsed by the MC.
992 If the 'advertisement' is successfully processed, there are two
993 possibilities. In the former case, the MC issues a successful 'ack'
994 message to the MP ("ACK sent") and moves to the CONF state. This
995 typically happens when the MC needs some more time to produce the
996 'configure' message associated with the received 'advertisement'. In
997 the latter case, the MC is able to immediately prepare and send back
998 to the MP a 'configure' message. Such a message will have the
999 field set to "200" ("configure+ack sent") and will allow the MC to
1000 move directly to the WAIT FOR CONF RESPONSE state.
1002 If the ADV processing is unsuccessful (bad syntax, missing XML
1003 elements, etc.), the MC sends a NACK message (i.e., an 'ack' with an
1004 error response code) to the MP and optionally further describes the
1005 problem via a proper reason phrase. In this way ("NACK sent"), the
1006 MC switches back to the WAIT FOR ADV state, waiting for a new
1007 'advertisement'.
1009 When in the CONF state, the MC prepares the 'configure' request to be
1010 issued to the MP on the basis of the previously ack-ed
1011 'advertisement'. When the 'configure' has been sent ("configure
1012 sent"), the MC moves to the WAIT FOR CONF RESPONSE state. If a new
1013 'advertisement' arrives in the meanwhile ("advertisement received"),
1014 the MC goes back to the ADV PROCESSING state.
1016 In the WAIT FOR CONF RESPONSE state, the MC waits for the MP's
1017 response to the issued 'configure' or 'configure+ack'. If a 200
1018 'configureResponse' message is received ("successful
1019 configureResponse received"), it means that the MP and the MC have
1020 successfully agreed on the media streams to be shared. Then, the MC
1021 can move to the ESTABLISHED state. On the other hand, if an error
1022 response is received ("error configureResponse received"), the MC
1023 moves back to the CONF state to prepare a new 'configure' request.
1024 If a new 'advertisement' is received in the WAIT FOR CONF RESPONSE
1025 state, the MC switches to the ADV PROCESSING state.
1027 When the MC is in the ESTABLISHED state, the telepresence session
1028 configuration has been set up at the CLUE application level according
1029 to the MC's preferences. Both the MP and the MC have agreed on (and
1030 are aware of) the CLUE-controlled media streams to be exchanged
1031 within the call. While in the ESTABLISHED state, it might happen
1032 that the MC decides to change something in the call settings. The MC
1033 then issues a new 'configure' ("configure sent") and goes to wait for
1034 the new 'configureResponse' in the WAIT FOR CONF RESPONSE state. On
1035 the other hand, in the ESTABLISHED state, if a new 'advertisement'
1036 arrives from the MP ("advertisement received"), it means that
1037 something has changed on the MP's side. The MC then moves to the ADV
1038 PROCESSING state.
1040 +----------+
1041 | WAIT FOR |
1042 | ADV |
1043 +----+-----+<--------+
1044 | |
1045 advertisement| NACK sent|
1046 received| |
1047 v |
1048 +-----------+--------+
1049 | ADV +
1050 | PROCESSING|<-----------------------+
1051 +-+-----+---+ |
1052 | | |
1053 configure+ack | | ack |
1054 sent | | sent |
1055 | v |
1056 | +-----+ |
1057 | |CONF | advertisement received |
1058 +----------------------->| +-------------------------+
1059 |error | +--+--+ |
1060 |configureResponse | | |
1061 |received | |configure |
1062 | | |sent |
1063 | | | |
1064 | v v advertisement |
1065 +------------------+---------------+ received |
1066 +--------->| WAIT FOR +---------------------+
1067 | | CONF RESPONSE+ |
1068 | +-------+-------+ |
1069 | | |
1070 | | |
1071 | |successful |
1072 | |configureResponse |
1073 | |received |
1074 |configure v |
1075 |sent +-----------+ advertisement received|
1076 +------------+ESTABLISHED+-----------------------+
1077 +-----------+
1079 Figure 12: Media Consumer's state machine
1081 7. Versioning
1083 CLUE protocol messages are XML messages compliant to the CLUE
1084 protocol XML schema [I-D.ietf-clue-data-model-schema]. The version
1085 of the protocol corresponds to the version of the schema. Both
1086 client and server have to test the compliance of the received
1087 messages with the XML schema of the CLUE protocol. If the compliance
1088 is not verified, the message cannot be processed further.
1090 Obviously, client and server cannot communicate if they do not share
1091 exactly the same XML schema. Such a schema is associated with the
1092 CLUE URN "urn:ietf:params:xml:ns:clue-protocol". If all CLUE-enabled
1093 devices use that schema there will be no interoperability problems
1094 due to schema issues.
1096 This document defines XML schema version 1.0. The version usage is
1097 similar in philosophy to XMPP ([RFC6120]). A version number has
1098 major and minor components, each a non-negative integer. Major
1099 version changes denote non-interoperable changes. Minor version
1100 changes denote schema changes that are backward compatible by
1101 ignoring unknown XML elements, or other backward compatible changes.
1103 The minor versions of the XML schema MUST be backward compatible, not
1104 only in terms of schema but also semantically and procedurally as
1105 well. This means that they should define further features and
1106 functionality besides those defined in the previous versions, in an
1107 incremental way, without impacting the basic rules defined in the
1108 previous version of the schema. In this way, if a MP is able to
1109 speak, e.g., version 1.5 of the protocol while the MC only
1110 understands version 1.4, the MP should have no problem in reverting
1111 the dialogue back to version 1.4 without exploiting 1.5 features and
1112 functionality. Version 1.4 is the one to be spoken and has to appear
1113 in the "v" attribute of the subsequent CLUE messages. In other
1114 words, in this example, the MP MUST use version 1.4 and downgrade to
1115 the lower version. This said, and coherently with the general IETF
1116 "protocol robustness principle" stating that "an implementation must
1117 be conservative in its sending behavior, and liberal in its receiving
1118 behavior" [RFC1122], CLUE Participants MUST ignore unknown elements
1119 or attributes that are not envisioned in the negotiated protocol
1120 version and related extensions.
1122 8. Extensions
1124 Although the standard version of the CLUE protocol XML schema is
1125 designed to thoroughly cope with the requirements emerging from the
1126 application domain, new needs might arise and extensions can be
1127 designed. Extensions specify information and behaviors that are not
1128 described in a certain version of the protocol and specified in the
1129 related RFC document. Such information and behaviors can be
1130 optionally used in a CLUE dialogue and MUST be negotiated in the CLUE
1131 initiation phase. They can relate to:
1133 1. new information, to be carried in the existing messages. For
1134 example, more fields may be added within an existing message;
1136 2. new messages. This is the case if there is no proper message for
1137 a certain task, so a brand new CLUE message needs to be defined.
1139 As to the first type of extensions, it is possible to distinguish
1140 between protocol-specific and data model information. Indeed, CLUE
1141 messages are envelopes carrying both:
1143 o (i) XML elements defined within the CLUE protocol XML schema
1144 itself (protocol-specific information)
1146 o (ii) other XML elements compliant to the CLUE data model schema
1147 (data model information)
1149 When new protocol-specific information is needed somewhere in the
1150 protocol messages, it can be added in place of the elements and
1151 elements envisioned by the protocol schema. The
1152 policy currently defined in the protocol schema for handling
1153 and elements is:
1155 o elementFormDefault="qualified"
1157 o attributeFormDefault="unqualified"
1159 The new information must be qualified by namespaces other than
1160 "urn:ietf:params:xml:ns:clue-protocol" (the protocol URN) and
1161 "urn:ietf:params:xml:ns:clue-info" (the data model URN). Elements or
1162 attributes from unknown namespaces MUST be ignored.
1164 The other matter concerns data model information. Data model
1165 information is defined by the XML schema associated with the URN
1166 "urn:ietf:params:xml:ns:clue-info". Also for the XML elements
1167 defined in such a schema there are extensibility issues. Those
1168 issues are overcome by using and placeholders.
1169 New information within data model elements can be added in place of
1170 and schema elements, as long as they are
1171 properly namespace qualified.
1173 On the other hand (second type of extensions), "extra" CLUE protocol
1174 messages, i.e., messages not envisioned in the latest standard
1175 version of the schema, can be needed. In that case, the messages and
1176 the associated behavior should be defined in external documents that
1177 both communication parties must be aware of.
1179 As reported in Figure 13, the values of the fields of the
1180 element (either new information or new messages) take the following
1181 values:
1183 o a name;
1184 o an external XML Schema defining the XML information and/or the XML
1185 messages representing the extension;
1187 o the major standard version of the protocol that the extension
1188 refers to.
1190
1191
1192
1193
1194
1195
1196
1197
1198
1200 Figure 13: The element
1202 The above described element is carried within the
1203 'options' and 'optionsResponse' messages to represent the extensions
1204 supported both by the CI and the CR.
1206 Extensions MUST be defined in a separate XML schema file and MUST be
1207 provided with a companion document describing their semantics and
1208 use.
1210 8.1. Extension example
1212 An example of extension might be a "new" capture attribute (i.e., a
1213 capture attribute which is not envisioned in the current standard
1214 defining the CLUE data model in [I-D.ietf-clue-data-model-schema])
1215 needed to further describe a video capture.
1217 The CLUE data model document ([I-D.ietf-clue-data-model-schema])
1218 envisions the possibility of adding this kind of "extra" information
1219 in the description of a video capture by keeping the compatibility
1220 with the CLUE data model schema. This is made possible thanks to the
1221 presence of the element in the XML definition of the video
1222 capture, allowing for the introduction of a new XML field in the XML
1223 description. For the sake of convenience, the XML definition of a
1224 video capture taken from [I-D.ietf-clue-data-model-schema] is
1225 reported in Figure 14 below.
1227
1228
1229
1230
1231
1232
1234
1235
1236
1237
1238
1240 Figure 14: XML definition of a CLUE video capture
1242 According to such a definition, a video capture might have, after the
1243 set of the generic media capture attributes, a set of new attributes
1244 defined elsewhere, i.e., in an XML schema defining an extension. The
1245 XML schema defining the extension might look like the following
1246 (Figure 15):
1248
1249
1256
1262
1263
1264
1265
1266
1267
1268
1269
1271
1273
1274
1276 Figure 15: XML schema defining an extension
1278 By using the extension above, a video capture can be further
1279 described in the advertisement using the element
1280 containing two extra information ( and
1281 ) besides using the attributes envisioned for a
1282 generic media capture. As stated in this document, both participants
1283 must be aware of the extension schema and related semantics to use
1284 such an extension and must negotiate it via the 'options' and
1285 'optionsResponse' mechanism.
1287 9. XML Schema
1289 NOTE TO THE RFC-Editor: Please replace "data-model-schema-17.xsd"
1290 with the right schema location for the CLUE data model schema
1291 document (which is still to be defined at the time of this writing)
1292 in this section prior to publication as an RFC.
1294 In this section, the XML schema defining the CLUE messages is
1295 provided (Figure 16).
1297
1298
1306
1307
1309
1310
1311
1312
1313
1314
1315
1317
1318
1319
1320
1321
1322
1323
1325
1326
1327
1328
1329
1330
1331
1332
1333
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1366
1368
1370
1371
1372
1373
1374
1375
1376
1377
1378
1380
1381
1382
1383
1384
1385
1386
1387
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1411
1413
1414
1416
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1432
1433
1434
1436
1439
1440
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1469
1471
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1486
1487
1488
1489
1490
1491
1493 Figure 16: Schema defining CLUE messages
1495 10. Examples
1497 In this section we provide examples of 'advertisement' messages
1498 representing the telepresence environment described in
1499 [I-D.ietf-clue-data-model-schema], Section "Sample XML file" and
1500 Section "MCC example" respectively.
1502 10.1. Simple 'advertisement'
1504 Figure 17 presents a simple 'advertisement' message. The associated
1505 Media Provider's telepresence capabilities are described in
1506 [I-D.ietf-clue-data-model-schema], Section "Sample XML file".
1508
1509
1512 Napoli CLUE Endpoint
1513 34
1514
1515
1519 CS1
1520
1521
1522
1523 0.0
1524 0.0
1525 10.0
1526
1527
1528 0.0
1529 1.0
1530 10.0
1531
1532
1534
1535 true
1536 EG1
1537 main audio from the room
1538
1539 1
1540 it
1541 static
1542 room
1543
1544 alice
1545 bob
1546 ciccio
1547
1548
1549
1552 CS1
1553
1554
1555
1556 -2.0
1557 0.0
1558 10.0
1559
1560
1561
1562
1563 -3.0
1564 20.0
1565 9.0
1566
1567
1568 -1.0
1569 20.0
1570 9.0
1571
1572
1573 -3.0
1574 20.0
1575 11.0
1576
1577
1578 -1.0
1579 20.0
1580 11.0
1581
1583
1584
1585 true
1586 EG0
1587 left camera video capture
1588
1589 1
1590 it
1591 static
1592 individual
1593
1594 ciccio
1595
1596
1597
1600 CS1
1601
1602
1603
1604 0.0
1605 0.0
1606 10.0
1607
1608
1609
1610
1611 -1.0
1612 20.0
1613 9.0
1614
1615
1616 1.0
1617 20.0
1618 9.0
1619
1620
1621 -1.0
1622 20.0
1623 11.0
1624
1625
1626 1.0
1627 20.0
1628 11.0
1629
1630
1632
1633 true
1634 EG0
1635 central camera video capture
1636
1637 1
1638 it
1639 static
1640 individual
1641
1642 alice
1643
1644
1645
1648 CS1
1649
1650
1651
1652 2.0
1653 0.0
1654 10.0
1655
1656
1657
1658
1659 1.0
1660 20.0
1661 9.0
1662
1663
1664 3.0
1665 20.0
1666 9.0
1667
1668
1669 1.0
1670 20.0
1671 11.0
1672
1673
1674 3.0
1675 20.0
1676 11.0
1677
1678
1679
1680 true
1681 EG0
1682 right camera video capture
1683
1684 1
1685 it
1686 static
1687 individual
1688
1689 bob
1690
1691
1692
1695 CS1
1696
1697
1698
1699 -3.0
1700 20.0
1701 9.0
1702
1703
1704 3.0
1705 20.0
1706 9.0
1707
1708
1709 -3.0
1710 20.0
1711 11.0
1712
1713
1714 3.0
1715 20.0
1716 11.0
1717
1718
1719
1720
1721 SE1
1722
1723 SoundLevel:0
1724 EG0
1725 loudest room segment
1726 2
1727 it
1728 static
1729 individual
1730
1731
1734 CS1
1735
1736
1737
1738 0.0
1739 0.0
1740 10.0
1741
1742
1743
1744
1745 -3.0
1746 20.0
1747 7.0
1748
1749
1750 3.0
1751 20.0
1752 7.0
1753
1754
1755 -3.0
1756 20.0
1757 13.0
1758
1759
1760 3.0
1761 20.0
1762 13.0
1763
1764
1765
1766 true
1767 EG0
1768 zoomed out view of all people in the
1769 room
1770 2
1771 it
1772 static
1773 room
1774
1775 alice
1776 bob
1777 ciccio
1778
1779
1780
1781
1782
1783 600000
1784
1785 ENC1
1786 ENC2
1787 ENC3
1788
1789
1790
1791 300000
1792
1793 ENC4
1794 ENC5
1795
1796
1797
1798
1799
1800
1801
1802
1803 VC0
1804 VC1
1805 VC2
1806
1807
1808
1809
1810 VC3
1811
1812
1813
1814
1815 VC4
1816
1817
1818
1819
1820 AC0
1821
1822
1823
1825
1826
1827
1828
1829 VC3
1830 SE1
1831
1832
1833 VC0
1834 VC2
1835 VC4
1836
1837
1838
1839
1840
1841
1842 Bob
1843
1844
1845 minute taker
1846
1847
1848
1849
1850 Alice
1851
1852
1853 presenter
1854
1855
1856
1857
1858 Ciccio
1859
1860
1861 chairman
1862 timekeeper
1863
1864
1865
1867 Figure 17: 'advertisement' message example
1869 10.2. 'advertisement' with Multiple Content Captures
1871 Figure 18 presents a simple 'advertisement' message containing a
1872 Multiple Content Capture (MCC). The associated Media Provider's
1873 telepresence capabilities are described in
1874 [I-D.ietf-clue-data-model-schema], Section "MCC example".
1876
1877
1880 Napoli CLUE Endpoint
1881 34
1882
1883
1887 CS1
1888
1889
1890
1891 0.0
1892 0.0
1893 10.0
1894
1895
1896 0.0
1897 1.0
1898 10.0
1899
1900
1901
1902 true
1903 EG1
1904 main audio from the room
1905
1906 1
1907 it
1908 static
1909 room
1910
1911 alice
1912 bob
1913 ciccio
1914
1915
1916
1919 CS1
1920
1921
1922
1923 0.5
1924 1.0
1925 0.5
1926
1927
1928 0.5
1929 0.0
1930 0.5
1931
1932
1933
1934 true
1935 EG0
1936 left camera video capture
1937
1938 1
1939 it
1940 static
1941 individual
1942
1943 ciccio
1944
1945
1946
1949 CS1
1950
1951
1952
1953 0.0
1954 0.0
1955 10.0
1956
1957
1958
1959
1960 -1.0
1961 20.0
1962 9.0
1963
1964
1965 1.0
1966 20.0
1967 9.0
1968
1969
1970 -1.0
1971 20.0
1972 11.0
1973
1974
1975 1.0
1976 20.0
1977 11.0
1978
1979
1980
1981 true
1982 EG0
1983 central camera video capture
1984
1985 1
1986 it
1987 static
1988 individual
1989
1990 alice
1991
1992
1993
1996 CS1
1997
1998
1999
2000 2.0
2001 0.0
2002 10.0
2003
2004
2005
2006
2007 1.0
2008 20.0
2009 9.0
2010
2011
2012 3.0
2013 20.0
2014 9.0
2015
2016
2017 1.0
2018 20.0
2019 11.0
2020
2021
2022 3.0
2023 20.0
2024 11.0
2025
2026
2027
2028 true
2029 EG0
2030 right camera video capture
2031
2032 1
2033 it
2034 static
2035 individual
2036
2037 bob
2038
2039
2040
2043 CS1
2044
2045
2046
2047 -3.0
2048 20.0
2049 9.0
2050
2051
2052 3.0
2053 20.0
2054 9.0
2055
2056
2057 -3.0
2058 20.0
2059 11.0
2060
2061
2062 3.0
2063 20.0
2064 11.0
2065
2066
2067
2068
2069 SE1
2070
2071 SoundLevel:0
2072 EG0
2073 loudest room segment
2074 2
2075 it
2076 static
2077 individual
2078
2079
2082 CS1
2083
2084
2085
2086 0.0
2087 0.0
2088 10.0
2089
2090
2091
2092
2093 -3.0
2094 20.0
2095 7.0
2096
2097
2098 3.0
2099 20.0
2100 7.0
2101
2102
2103 -3.0
2104 20.0
2105 13.0
2106
2107
2108 3.0
2109 20.0
2110 13.0
2111
2112
2113
2114 true
2115 EG0
2116
2117 zoomed out view of all people in the room
2118
2119 2
2120 it
2121 static
2122 room
2123
2124 alice
2125 bob
2126 ciccio
2127
2128
2129
2132 CS1
2133
2134
2135
2136 -3.0
2137 20.0
2138 9.0
2139
2140
2141 3.0
2142 20.0
2143 9.0
2144
2145
2146 -3.0
2147 20.0
2148 11.0
2149
2150
2151 3.0
2152 20.0
2153 11.0
2154
2155
2157
2158
2159 SE1
2160
2161 SoundLevel:1
2162 penultimate loudest room segment
2163
2164 it
2165 static
2166 individual
2167
2168
2171 CS1
2172
2173
2174
2175 -3.0
2176 20.0
2177 9.0
2178
2179
2180 3.0
2181 20.0
2182 9.0
2183
2184
2185 -3.0
2186 20.0
2187 11.0
2188
2189
2190 3.0
2191 20.0
2192 11.0
2193
2194
2195
2196
2197 SE1
2198
2199 SoundLevel:2
2200 last but two loudest room segment
2201
2202 it
2203 static
2204 individual
2206
2207
2210 CS1
2211
2212
2213
2214 -3.0
2215 20.0
2216 9.0
2217
2218
2219 3.0
2220 20.0
2221 9.0
2222
2223
2224 -3.0
2225 20.0
2226 11.0
2227
2228
2229 3.0
2230 20.0
2231 11.0
2232
2233
2234
2235
2236 VC3
2237 VC5
2238 VC6
2239
2240 3
2241 EG0
2242 big picture of the current speaker +
2243 pips about previous speakers
2244 3
2245 it
2246 static
2247 individual
2248
2249
2250
2251
2252 600000
2253
2254 ENC1
2255 ENC2
2256 ENC3
2257
2258
2259
2260 300000
2261
2262 ENC4
2263 ENC5
2264
2265
2266
2267
2268
2269
2270
2271 participants' individual
2272 videos
2273
2274 VC0
2275 VC1
2276 VC2
2277
2278
2279
2280 loudest segment of the
2281 room
2282
2283 VC3
2284
2285
2286
2287 loudest segment of the
2288 room + pips
2289
2290 VC7
2291
2292
2293
2294 room audio
2295
2296 AC0
2297
2298
2299
2300 room video
2301
2302 VC4
2303
2304
2305
2306
2307
2308
2309
2310 VC3
2311 VC7
2312 SE1
2313
2314
2315 VC0
2316 VC2
2317 VC4
2318
2319
2320
2321
2322
2323
2324 Bob
2325
2326
2327 minute taker
2328
2329
2330
2331
2332 Alice
2333
2334
2335 presenter
2336
2337
2338
2339
2340 Ciccio
2341
2342
2343 chairman
2344 timekeeper
2345
2346
2347
2348 Figure 18: An example of 'advertisement' message with MCC
2350 11. Security Considerations
2352 As a general consideration, we remark that the CLUE framework (and
2353 related protocol) has been conceived at the outset by embracing the
2354 security-by-design paradigm. This entails that a number of
2355 requirements have been identified and properly standardized as
2356 mandatory within the entire set of documents associated with the CLUE
2357 architecture. Requirements include: (i) the use of cryptography and
2358 authentication; (ii) protection of all sensitive fields; (iii) mutual
2359 authentication between CLUE endpoints; (iv) the presence of
2360 authorization mechanisms; (v) the presence of native defence
2361 mechanisms against malicious activities such as eavesdropping,
2362 selective modification, deletion, replay (and related combinations
2363 thereof). Hence, security of the single components of the CLUE
2364 solution cannot be evaluated independently of the integrated view of
2365 the final architecture.
2367 The CLUE protocol is an application-level protocol allowing a Media
2368 Producer and a Media Consumer to negotiate a variegated set of
2369 parameters associated with the establishment of a telepresence
2370 session. This unavoidably exposes a CLUE-enabled telepresence system
2371 to a number of potential threats, most of which are extensively
2372 discussed in the framework document [I-D.ietf-clue-framework]. The
2373 security considerations section of the mentioned document actually
2374 discusses issues associated with the setup and management of a
2375 telepresence session both in the basic case involving two CLUE
2376 endpoints acting, respectively, as MP and MC, and in the more
2377 advanced scenario envisaging the presence of an MCU.
2379 The framework document also mentions that the information carried
2380 within CLUE protocol messages might contain sensitive data, which
2381 SHOULD hence be accessed only by authenticated endpoints. Security
2382 issues associated with the CLUE data model schema are discussed in
2383 [I-D.ietf-clue-data-model-schema].
2385 There is extra information carried by the CLUE protocol which is not
2386 associated with the CLUE data model schema and which exposes
2387 information that might be of concern. This information is primarily
2388 exchanged during the negotiation phase via the 'options' and
2389 'optionsResponse' messages. In the CLUE Participant state machine
2390 OPTIONS state, both parties agree on the version and on the
2391 extensions to be used in the subsequent CLUE messages exchange phase.
2392 A malicious participant might either try to retrieve a detailed
2393 footprint of a specific CLUE protocol implementation during this
2394 initial setup phase, or force the communicating party to use a non-
2395 up-to-date version of the protocol which they know how to break.
2397 Indeed, exposing all of the supported versions and extensions could
2398 conceivably leak information about the specific implementation of the
2399 protocol. In theory an implementation could choose not to announce
2400 all of the versions it supports if it wants to avoid such leakage,
2401 though at the expenses of interoperability. With respect to the
2402 above considerations, it is noted that the OPTIONS state is only
2403 reached after the CLUE data channel has been successfully set up.
2404 This ensures that only authenticated parties can exchange 'options'
2405 and related 'optionsResponse' messages and hence drastically reduces
2406 the attack surface which is exposed to malicious parties.
2408 The CLUE framework clearly states the requirement to protect CLUE
2409 protocol messages against threats deriving from the presence of a
2410 malicious agent capable to gain access to the CLUE data channel.
2411 Such a requirement is met by the CLUE data channel solution described
2412 in [I-D.ietf-clue-datachannel], which ensures protection from both
2413 message recovery and message tampering. With respect to this last
2414 point, any implementation of the CLUE protocol compliant with the
2415 CLUE specification MUST rely on the exchange of messages which flow
2416 on top of a reliable and ordered SCTP over DTLS transport channel
2417 connecting two CLUE Participants.
2419 12. IANA Considerations
2421 This document registers a new XML namespace, a new XML schema and the
2422 MIME type for the schema. This document also registers the "CLUE"
2423 Application Service tag and the "CLUE" Application Protocol tag and
2424 defines registries for the CLUE messages and response codes.
2426 12.1. URN Sub-Namespace Registration
2428 This section registers a new XML namespace,
2429 ""urn:ietf:params:xml:ns:clue-protocol"".
2431 URI: urn:ietf:params:xml:ns:clue-protocol
2433 Registrant Contact: IESG (iesg@ietf.org).
2435 XML:
2437 BEGIN
2438
2439
2441
2442
2443 CLUE Messages
2444
2445
2446 Namespace for CLUE Messages
2447 urn:ietf:params:xml:ns:clue-protocol
2448 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2449 with the RFC number for this specification.]]
2450 See
2451 RFCXXXX.
2452
2453
2454 END
2456 12.2. XML Schema registration
2458 This section registers an XML schema per the guidelines in [RFC3688].
2460 URI: urn:ietf:params:xml:schema:clue-protocol
2462 Registrant Contact: IESG (iesg@ietf.org).
2464 Schema: The XML for this schema can be found as the entirety of
2465 Section 9 of this document.
2467 12.3. MIME Media Type Registration for 'application/clue+xml'
2469 This section registers the ""application/clue+xml"" MIME type.
2471 To: ietf-types@iana.org
2473 Subject: Registration of MIME media type application/clue+xml
2475 MIME media type name: application
2477 MIME subtype name: clue+xml
2479 Required parameters: (none)
2481 Optional parameters: charset
2482 Same as the charset parameter of "application/xml" as specified in
2483 [RFC7303], Section 3.2.
2485 Encoding considerations: Same as the encoding considerations of
2486 "application/xml" as specified in [RFC7303], Section 3.2.
2488 Security considerations: This content type is designed to carry
2489 protocol data related to telepresence session control. Some of the
2490 data could be considered private. This media type does not provide
2491 any protection and thus other mechanisms such as those described in
2492 Section Security are required to protect the data. This media type
2493 does not contain executable content.
2495 Interoperability considerations: None.
2497 Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please
2498 replace XXXX with the RFC number for this specification.]]
2500 Applications that use this media type: CLUE participants.
2502 Additional Information: Magic Number(s): (none),
2503 File extension(s): .xml,
2504 Macintosh File Type Code(s): TEXT.
2506 Person & email address to contact for further information: Simon
2507 Pietro Romano (spromano@unina.it).
2509 Intended usage: LIMITED USE
2511 Author/Change controller: The IETF
2513 Other information: This media type is a specialization of
2514 application/xml [RFC7303], and many of the considerations described
2515 there also apply to application/clue+xml.
2517 12.4. CLUE Protocol Registry
2519 The document requests that the IANA creates new registries for CLUE
2520 messages and response codes.
2522 12.4.1. CLUE Message Types
2524 The following summarizes the registry for CLUE messages:
2526 Related Registry: CLUE Message Types Registry
2528 Defining RFC: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace XXXX
2529 with the RFC number for this specification.]]
2530 Registration/Assignment Procedures: Following the policies outlined
2531 in [RFC5226], the IANA policy for assigning new values for the CLUE
2532 message types for the CLUE protocol is Specification Required.
2534 Registrant Contact: IESG (iesg@ietf.org).
2536 The initial Message table is populated using the CLUE messages
2537 described in Section 5 and defined in the XML schema in Section 9.
2539 +-------------------+-----------------------------------+-----------+
2540 | Message | Description | Reference |
2541 +-------------------+-----------------------------------+-----------+
2542 | options | Sent by the CI to the CR in the | RFCXXXX |
2543 | | initiation phase to specify the | |
2544 | | roles played by the CI, the | |
2545 | | supported versions and the | |
2546 | | supported extensions. | |
2547 | optionsResponse | Sent by the CI to the CR in reply | RFCXXXX |
2548 | | to an 'options' message to | |
2549 | | finally estabilsh the version and | |
2550 | | the extensions to be used in the | |
2551 | | following CLUE messages exchange. | |
2552 | advertisement | Sent by the MP to the MC to | RFCXXXX |
2553 | | specify the telepresence | |
2554 | | capabilities of the MP expressed | |
2555 | | according to the CLUE framework. | |
2556 | ack | Sent by the MC to the MP to | RFCXXXX |
2557 | | acknowledge the reception of an | |
2558 | | 'advertisement' message. | |
2559 | configure | Sent by the MC to the MP to | RFCXXXX |
2560 | | specify the desired media | |
2561 | | captures among those specified in | |
2562 | | the 'advertisement'. | |
2563 | configureResponse | Sent by the MP to the MC in reply | RFCXXXX |
2564 | | to a CONFIGURE message to | |
2565 | | communicate if the configuration | |
2566 | | request has been successfully | |
2567 | | processed or not. | |
2568 +-------------------+-----------------------------------+-----------+
2570 IANA-CLUE
2572 12.4.2. CLUE Response Codes
2574 The following summarizes the requested registry for CLUE response
2575 codes:
2577 Related Registry: CLUE Response Code Registry
2578 Defining RFC: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace XXXX
2579 with the RFC number for this specification.]]
2581 Registration/Assignment Procedures: Following the policies outlined
2582 in [RFC5226], the IANA policy for assigning new values for the
2583 Response codes for CLUE shall be Specification Required.
2585 Registrant Contact: IESG (iesg@ietf.org).
2587 The initial Response-code table is populated using the Response codes
2588 defined in Section 5.7 as follows:
2590 +--------+---------------+------------------------------+-----------+
2591 | Number | Default | Description | Reference |
2592 | | Response | | |
2593 | | String | | |
2594 +--------+---------------+------------------------------+-----------+
2595 | 200 | Success | The request has been | RFCXXXX |
2596 | | | successfully processed. | |
2597 | 300 | Low-level | A generic low-level request | RFCXXXX |
2598 | | request | error has occurred. | |
2599 | | error. | | |
2600 | 301 | Bad syntax | The XML syntax of the | RFCXXXX |
2601 | | | message is not correct. | |
2602 | 302 | Invalid value | The message contains an | RFCXXXX |
2603 | | | invalid parameter value. | |
2604 | 303 | Conficting | The message contains values | RFCXXXX |
2605 | | values | that cannot be used | |
2606 | | | together. | |
2607 | 400 | Semantic | Semantic errors in the | RFCXXXX |
2608 | | errors | received CLUE protocol | |
2609 | | | message. | |
2610 | 401 | Version not | The protocol version used in | RFCXXXX |
2611 | | supported | the message is not | |
2612 | | | supported. | |
2613 | 402 | Invalid | Sequence number gap; | RFCXXXX |
2614 | | sequencing | repeated sequence number; | |
2615 | | | sequence number outdated. | |
2616 | 403 | Invalid | The clueId used in the | RFCXXXX |
2617 | | identifier | message is not valid or | |
2618 | | | unknown. | |
2619 | 404 | advertisement | The sequence number of the | RFCXXXX |
2620 | | Expired | advertisement the configure | |
2621 | | | refers to is out of date. | |
2622 | 405 | Subset choice | The subset choice is not | RFCXXXX |
2623 | | not allowed | allowed for the specified | |
2624 | | | Multiple Content Capture. | |
2625 +--------+---------------+------------------------------+-----------+
2627 13. Acknowledgments
2629 The authors thank all the CLUErs for their precious feedbacks and
2630 support, in particular Paul Kyzivat, Christian Groves and Scarlett
2631 Liuyan.
2633 14. References
2635 14.1. Normative References
2637 [I-D.ietf-clue-data-model-schema]
2638 Presta, R. and S. Romano, "An XML Schema for the CLUE data
2639 model", draft-ietf-clue-data-model-schema-17 (work in
2640 progress), August 2016.
2642 [I-D.ietf-clue-datachannel]
2643 Holmberg, C., "CLUE Protocol data channel", draft-ietf-
2644 clue-datachannel-14 (work in progress), August 2016.
2646 [I-D.ietf-clue-framework]
2647 Duckworth, M., Pepperell, A., and S. Wenger, "Framework
2648 for Telepresence Multi-Streams", draft-ietf-clue-
2649 framework-25 (work in progress), January 2016.
2651 [I-D.ietf-clue-signaling]
2652 Hansen, R., Kyzivat, P., Xiao, L., and C. Groves, "Session
2653 Signaling for Controlling Multiple Streams for
2654 Telepresence (CLUE)", draft-ietf-clue-signaling-13 (work
2655 in progress), November 2017.
2657 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2658 Requirement Levels", BCP 14, RFC 2119,
2659 DOI 10.17487/RFC2119, March 1997,
2660 .
2662 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
2663 Jacobson, "RTP: A Transport Protocol for Real-Time
2664 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
2665 July 2003, .
2667 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
2668 DOI 10.17487/RFC3688, January 2004,
2669 .
2671 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
2672 IANA Considerations Section in RFCs", RFC 5226,
2673 DOI 10.17487/RFC5226, May 2008,
2674 .
2676 [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303,
2677 DOI 10.17487/RFC7303, July 2014,
2678 .
2680 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2681 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
2682 May 2017, .
2684 14.2. Informative References
2686 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
2687 Communication Layers", STD 3, RFC 1122,
2688 DOI 10.17487/RFC1122, October 1989,
2689 .
2691 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the
2692 Session Initiation Protocol (SIP)", RFC 4353,
2693 DOI 10.17487/RFC4353, February 2006,
2694 .
2696 [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
2697 DOI 10.17487/RFC5117, January 2008,
2698 .
2700 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
2701 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
2702 March 2011, .
2704 [RFC7262] Romanow, A., Botzko, S., and M. Barnes, "Requirements for
2705 Telepresence Multistreams", RFC 7262,
2706 DOI 10.17487/RFC7262, June 2014,
2707 .
2709 [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667,
2710 DOI 10.17487/RFC7667, November 2015,
2711 .
2713 Authors' Addresses
2715 Roberta Presta
2716 University of Napoli
2717 Via Claudio 21
2718 Napoli 80125
2719 Italy
2721 EMail: roberta.presta@unina.it
2722 Simon Pietro Romano
2723 University of Napoli
2724 Via Claudio 21
2725 Napoli 80125
2726 Italy
2728 EMail: spromano@unina.it