idnits 2.17.1
draft-ietf-clue-protocol-10.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 1008 has weird spacing: '... | sent retr...'
== Line 1010 has weird spacing: '...expired v ...'
-- The document date (November 1, 2016) is 2726 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 1205, but not defined
== Missing Reference: '0-9' is mentioned on line 1205, but not defined
== Unused Reference: 'RFC3958' is defined on line 2429, 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-09
** 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)
Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 CLUE Working Group R. Presta
3 Internet-Draft S. Romano
4 Intended status: Standards Track University of Napoli
5 Expires: May 5, 2017 November 1, 2016
7 CLUE protocol
8 draft-ietf-clue-protocol-10
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 upon 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 http://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 May 5, 2017.
40 Copyright Notice
42 Copyright (c) 2016 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
59 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
60 4. Overview of the CLUE protocol . . . . . . . . . . . . . . . . 5
61 5. Protocol messages . . . . . . . . . . . . . . . . . . . . . . 7
62 5.1. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 9
63 5.2. OPTIONS RESPONSE . . . . . . . . . . . . . . . . . . . . . 11
64 5.3. ADVERTISEMENT . . . . . . . . . . . . . . . . . . . . . . 12
65 5.4. ADVERTISEMENT ACKNOWLEDGEMENT . . . . . . . . . . . . . . 13
66 5.5. CONFIGURE . . . . . . . . . . . . . . . . . . . . . . . . 14
67 5.6. CONFIGURE RESPONSE . . . . . . . . . . . . . . . . . . . . 14
68 5.7. Response codes and reason strings . . . . . . . . . . . . 15
69 6. Protocol state machines . . . . . . . . . . . . . . . . . . . 17
70 6.1. Media Provider's state machine . . . . . . . . . . . . . . 19
71 6.2. Media Consumer's state machine . . . . . . . . . . . . . . 22
72 7. Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . 25
73 8. Extensions and options . . . . . . . . . . . . . . . . . . . . 25
74 9. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 27
75 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
76 10.1. Simple ADV . . . . . . . . . . . . . . . . . . . . . . . . 31
77 10.2. ADV with MCCs . . . . . . . . . . . . . . . . . . . . . . 37
78 11. Security Considerations . . . . . . . . . . . . . . . . . . . 44
79 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
80 12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 46
81 12.2. XML Schema registration . . . . . . . . . . . . . . . . . 47
82 12.3. MIME Media Type Registration for 'application/clue+xml' . 47
83 12.4. CLUE Protocol Registry . . . . . . . . . . . . . . . . . . 48
84 12.4.1. CLUE Message Types . . . . . . . . . . . . . . . . . 48
85 12.4.2. CLUE Response Codes . . . . . . . . . . . . . . . . . 50
86 13. Diff with draft-ietf-clue-protocol-06 . . . . . . . . . . . . 51
87 14. Diff with draft-ietf-clue-protocol-05 . . . . . . . . . . . . 51
88 15. Diff with draft-ietf-clue-protocol-04 . . . . . . . . . . . . 51
89 16. Diff with draft-ietf-clue-protocol-03 . . . . . . . . . . . . 51
90 17. Diff with draft-ietf-clue-protocol-02 . . . . . . . . . . . . 51
91 18. Diff with draft-ietf-clue-protocol-01 . . . . . . . . . . . . 52
92 19. Diff with draft-ietf-clue-protocol-00 . . . . . . . . . . . . 52
93 20. Diff with draft-presta-clue-protocol-04 . . . . . . . . . . . 53
94 21. Diff with draft-presta-clue-protocol-03 . . . . . . . . . . . 53
95 22. Diff with draft-presta-clue-protocol-02 . . . . . . . . . . . 53
96 23. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
97 24. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
98 24.1. Normative References . . . . . . . . . . . . . . . . . . . 53
99 24.2. Informative References . . . . . . . . . . . . . . . . . . 55
101 1. Introduction
103 The CLUE protocol is an application protocol used by two CLUE
104 Participants to enhance the experience of a multimedia telepresence
105 session. The main goals of the CLUE protocol are:
107 1. enabling a Media Provider (MP) to properly announce its current
108 telepresence capabilities to a Media Consumer (MC) in terms of
109 available media captures, groups of encodings, simultaneity
110 constraints and other information envisioned in
111 [I-D.ietf-clue-framework];
113 2. enabling an MC to request the desired multimedia streams from the
114 offering MP.
116 CLUE-capable endpoints are connected by means of the CLUE data
117 channel, an SCTP over DTLS channel which is opened and established as
118 described in [I-D.ietf-clue-signaling] and
119 [I-D.ietf-clue-datachannel]. CLUE protocol messages flowing upon
120 such a channel are detailed in this document, both syntactically and
121 semantically.
123 In Section 4 we provide a general overview of the CLUE protocol.
124 CLUE protocol messages are detailed in Section 5. The CLUE
125 Participant state machines are introduced in Section 6. Versioning
126 and extensions are discussed in Section 7 and Section 8,
127 respectively. The XML schema defining the CLUE messages is reported
128 in Section 9.
130 2. Terminology
132 This document refers to the same terminology used in
133 [I-D.ietf-clue-framework] and in [RFC7262]. We briefly recall herein
134 some of the main terms used in the document. The definition of "CLUE
135 Participant" herein proposed is not imported from any of the above
136 documents.
138 CLUE Participant (CP): An entity able to use the CLUE protocol
139 within a telepresence session. It can be an endpoint or an MCU
140 able to use the CLUE protocol.
142 CLUE-capable device: A device that supports the CLUE data channel
143 [I-D.ietf-clue-datachannel], the CLUE protocol and the principles
144 of CLUE negotiation, and seeks CLUE-enabled calls.
146 Endpoint: The logical point of final termination through receiving,
147 decoding and rendering, and/or initiation through capturing,
148 encoding, and sending of media streams. An endpoint consists of
149 one or more physical devices which source and sink media streams,
150 and exactly one [RFC4353] Participant (which, in turn, includes
151 exactly one SIP User Agent). Endpoints can be anything from
152 multiscreen/multicamera room controllers to handheld devices.
154 MCU: Multipoint Control Unit (MCU) - a device that connects two or
155 more endpoints together into one single multimedia conference
156 [RFC7667]. An MCU may include a Mixer [RFC4353].
158 Media: Any data that, after suitable encoding, can be conveyed over
159 RTP, including audio, video or timed text.
161 Media Capture: A "Media Capture", or simply "Capture", is a source
162 of Media.
164 Media Consumer (MC): A CLUE Participant (i.e., an Endpoint or an
165 MCU) able to receive Media Streams.
167 Capture Encoding: A specific encoding of a Media Capture, to be sent
168 via RTP [RFC3550].
170 Media Provider (MP): A CLUE Participant (i.e., an Endpoint or an
171 MCU) able to send Media Streams.
173 Media Stream: The term "Media Stream", or simply "Stream", is used
174 as a synonym of Capture Encoding.
176 3. Conventions
178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
180 document are to be interpreted as described in BCP 14, RFC 2119
181 [RFC2119].
183 4. Overview of the CLUE protocol
185 The CLUE protocol is conceived to enable CLUE telepresence sessions.
186 It is designed in order to address SDP limitations in terms of the
187 description of some information about the multimedia streams that are
188 involved in a real-time multimedia conference. Indeed, by simply
189 using SDP we are not able to convey information about the features of
190 the flowing multimedia streams that are needed to enable a "being
191 there" rendering experience. Such information is designed in the
192 CLUE framework document and formally defined and described in the
193 CLUE data model document. The CLUE protocol represents the mechanism
194 for the exchange of CLUE information between CLUE Participants. It
195 mainly provides the messages to enable a Media Provider to advertise
196 its telepresence capabilities and to enable a Media Consumer to
197 select the desired telepresence options.
199 The CLUE protocol, as defined in the following, is a stateful,
200 client-server, XML-based application protocol. CLUE protocol
201 messages flow on a reliable and ordered SCTP over DTLS transport
202 channel connecting two CLUE Participants. Messages carry information
203 taken from the XML-based CLUE data model
204 ([I-D.ietf-clue-data-model-schema]). Three main communication layers
205 can be identified:
207 1. Establishment of the CLUE data channel: in this phase, the CLUE
208 data channel setup takes place. If it completes successfully,
209 the CPs are able to communicate and start the initiation phase.
211 2. Negotiation of the CLUE protocol version and options (initiation
212 phase): the CPs connected via the CLUE data channel agree on the
213 version and on the options to be used during the telepresence
214 session. Special CLUE messages are used for such a task (OPTIONS
215 and OPTIONS RESPONSE). The version and options negotiation can
216 be performed once and only at this stage. At the end of that
217 basic negotiation, each CP starts its activity as a CLUE MP
218 and/or CLUE MC.
220 3. CLUE telepresence capabilities description and negotiation: in
221 this phase, the MP-MC dialogues take place on the data channel by
222 means of the CLUE protocol messages.
224 As soon as the channel is ready, the CLUE Participants must agree on
225 the protocol version and extensions to be used within the
226 telepresence session. CLUE protocol version numbers are
227 characterized by a major version number (single digit) and a minor
228 version number (single digit), both unsigned integers, separated by a
229 dot. While minor version numbers denote backward compatible changes
230 in the context of a given major version, different major version
231 numbers generally indicate a lack of interoperability between the
232 protocol implementations. In order to correctly establish a CLUE
233 dialogue, the involved CPs MUST have in common a major version number
234 (see Section 7 for further details). The subset of the protocol
235 options and extensions that are allowed within the CLUE session is
236 also determined in the initiation phase, such subset being the one
237 including only the options that are supported by both parties. A
238 mechanism for the negotiation of the CLUE protocol version and
239 extensions is is part of the initial phase. According to such a
240 solution, the CP which is the CLUE Channel initiator (CI) issues a
241 proper CLUE message (OPTIONS) to the CP which is the Channel Receiver
242 (CR) specifying the supported version and extensions. The CR then
243 answers by selecting the subset of the CI extensions that it is able
244 to support and determines the protocol version to be used.
246 After that negotiation phase is completed, CLUE Participants describe
247 and agree on the media flows to be exchanged. In many cases CPs will
248 seek to both transmit and receive media. Hence in a call between two
249 CPs, A and B, there would be two separate dialogs, as follows:
251 1. the one needed to describe and set up the media streams sent from
252 A to B, i.e., the dialogue between A's Media Provider side and
253 B's Media Consumer side
255 2. the one needed to describe and set up the media streams sent from
256 B to A, i.e., the dialogue between B's Media Provider side and
257 A's Media Consumer side
259 CLUE messages for the media session description and negotiation are
260 designed by considering the MP side as the server side of the
261 protocol, since it produces and provides media streams, and the MC
262 side as the client side of the protocol, since it requests and
263 receives media streams. The messages that are exchanged to set up
264 the telepresence media session are described by focusing on a single
265 MP-MC dialogue.
267 The MP first advertises its available media captures and encoding
268 capabilities to the MC, as well as its simultaneity constraints,
269 according to the information model defined in
270 [I-D.ietf-clue-framework]. The CLUE message conveying the MP's
271 multimedia offer is the ADVERTISEMENT message. Such message
272 leverages the XML data model definitions provided in
273 [I-D.ietf-clue-data-model-schema].
275 The MC selects the desired streams of the MP by using the CONFIGURE
276 message, which makes reference to the information carried in the
277 previously received ADVERTISEMENT.
279 Besides ADVERTISEMENT and CONFIGURE, other messages have been
280 conceived in order to provide all the needed mechanisms and
281 operations. Such messages will be detailed in the following
282 sections.
284 5. Protocol messages
286 CLUE protocol messages are textual, XML-based messages that enable
287 the configuration of the telepresence session. The formal definition
288 of such messages is provided in the XML Schema provided at the end of
289 this document (Section 9).
291 The XML definitions of the CLUE information provided in
292 [I-D.ietf-clue-data-model-schema] are included within some CLUE
293 protocol messages (namely the ADVERTISEMENT and the CONFIGURE
294 messages), in order to use the concepts defined in
295 [I-D.ietf-clue-framework].
297 The CLUE protocol messages are the following:
299 o OPTIONS
301 o OPTIONS RESPONSE
303 o ADVERTISEMENT (ADV)
305 o ADVERTISEMENT ACKNOWLEDGEMENT (ACK)
307 o CONFIGURE (CONF)
309 o CONFIGURE RESPONSE (CONF RESPONSE)
311 While the OPTIONS and OPTIONS RESPONSE messages are exchanged in the
312 initiation phase between the CPs, the other messages are involved in
313 MP-MC dialogues.
315 Each CLUE message inherits a basic structure depicted in the
316 following excerpt:
318
319
320
321
322
323
324
326
327
329
330
331
332
333
334
335 The basic structure determines the mandatory information that is
336 carried within each CLUE message. Such an information is made by:
338 o clueId: an XML element containing the identifier (in the form of a
339 generic string) of the CP within the telepresence system;
341 o sequenceNr: an XML element containing the local message sequence
342 number. The sender must increment the sequence numbers by one for
343 each new message sent, the receiver must remember the most recent
344 sequence number received and send back a 402 error if it receives
345 a message with an unexpected sequence number. The initial
346 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. Allowed values are of this kind: "1.3",
355 "2.4", etc.
357 Each CP MUST be able to manage up to three (independent) streams of
358 sequence numbers: (i) one for the messages exchanged in the
359 initiation phase, (ii) one for the messages exchanged as MP, and
360 (iii) one for the messages exchanged as MC.
362 5.1. OPTIONS
364 The OPTIONS message is sent by the CP which is the CI to the CP which
365 is the CR as soon as the CLUE data channel is ready. Besides the
366 information envisioned in the basic structure, it specifies:
368 o mediaProvider: a mandatory boolean field set to "true" if the CP
369 is able to act as a MP
371 o mediaConsumer: a mandatory boolean field set to "true" if the CP
372 is able to act as a MC
374 o supportedVersions: the list of the supported versions
376 o supportedOptions: the list of the supported options
378 The XML Schema of such a message is reported below:
380
381
382
383
384
385
386
387
389
391
392
393
394
395
396
398
399
400
401
403
404
405
406
408
409
410
411
413
414
415
416
418
419
420
421
422
423
424
425
426
427
428 contains the list of the versions that are
429 supported by the CI, each one represented in a child
430 element. The content of each element is a string made by
431 the major version number followed by a dot and then by the minor
432 version number (e.g., 1.3 or 2.4). Exactly one element
433 MUST be provided for each major version supported, containing the
434 maximum minor version number of such a version, since all minor
435 versions are backward compatible. If no is
436 carried within the OPTIONS message, the CI supports only the version
437 declared in the "v" attribute and all the versions having the same
438 major version number and lower minor version number. For example, if
439 the "v" attribute has a value of "3.4" and there is no
440 tag in the OPTIONS message, it means the CI
441 supports only major version 3 with all the minor versions comprised
442 between 3.0 and 3.4, with version 3.4 included. If a
443 is provided, at least one tag MUST be
444 included.
446 The element specifies the list of options
447 supported by the CI. If there is no in the
448 OPTIONS message, the CI does not support anything other than what is
449 envisioned in the versions it supports. For each option, an