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