idnits 2.17.1 draft-ietf-clue-protocol-19.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 5, 2019) is 1747 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: '1-9' is mentioned on line 1355, but not defined == Missing Reference: '0-9' is mentioned on line 1361, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-clue-signaling-14 Summary: 0 errors (**), 0 flaws (~~), 4 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. P. Romano 4 Intended status: Experimental University of Napoli 5 Expires: January 6, 2020 July 5, 2019 7 Protocol for Controlling Multiple Streams for Telepresence (CLUE) 8 draft-ietf-clue-protocol-19 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 January 6, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Overview of the CLUE protocol . . . . . . . . . . . . . . . . 4 61 5. Protocol messages . . . . . . . . . . . . . . . . . . . . . . 7 62 5.1. options . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 5.2. optionsResponse . . . . . . . . . . . . . . . . . . . . . 11 64 5.3. advertisement . . . . . . . . . . . . . . . . . . . . . . 12 65 5.4. ack . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 5.5. configure . . . . . . . . . . . . . . . . . . . . . . . . 14 67 5.6. configureResponse . . . . . . . . . . . . . . . . . . . . 15 68 5.7. Response codes and reason strings . . . . . . . . . . . . 16 69 6. Protocol state machines . . . . . . . . . . . . . . . . . . . 18 70 6.1. Media Provider's state machine . . . . . . . . . . . . . 21 71 6.2. Media Consumer's state machine . . . . . . . . . . . . . 22 72 7. Versioning . . . . . . . . . . . . . . . . . . . . . . . . . 25 73 8. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 25 74 8.1. Extension example . . . . . . . . . . . . . . . . . . . . 27 75 9. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 29 76 10. Call flow example . . . . . . . . . . . . . . . . . . . . . . 34 77 10.1. CLUE message nr. 1: 'options' . . . . . . . . . . . . . 37 78 10.2. CLUE message nr. 2: 'optionsResponse' . . . . . . . . . 39 79 10.3. CLUE message nr. 3: 'advertisement' . . . . . . . . . . 39 80 10.4. CLUE message nr. 4: 'configure + ack' . . . . . . . . . 47 81 10.5. CLUE message nr. 5: 'confResponse' . . . . . . . . . . . 47 82 10.6. CLUE message nr. 6: 'advertisement' . . . . . . . . . . 48 83 10.7. CLUE message nr. 7: 'ack' . . . . . . . . . . . . . . . 58 84 10.8. CLUE message nr. 8: 'configure' . . . . . . . . . . . . 58 85 10.9. CLUE message nr. 9: 'confResponse' . . . . . . . . . . . 59 86 11. Security Considerations . . . . . . . . . . . . . . . . . . . 60 87 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 88 12.1. URN Sub-Namespace Registration . . . . . . . . . . . . . 61 89 12.2. XML Schema registration . . . . . . . . . . . . . . . . 62 90 12.3. MIME Media Type Registration for 'application/clue+xml' 62 91 12.4. CLUE Protocol Registry . . . . . . . . . . . . . . . . . 63 92 12.4.1. CLUE Message Types . . . . . . . . . . . . . . . . . 63 93 12.4.2. CLUE Response Codes . . . . . . . . . . . . . . . . 64 94 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 66 95 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 66 96 14.1. Normative References . . . . . . . . . . . . . . . . . . 66 97 14.2. Informative References . . . . . . . . . . . . . . . . . 67 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 100 1. Introduction 102 The CLUE protocol is an application protocol used by two CLUE 103 Participants to enhance the experience of a multimedia telepresence 104 session. The main goals of the CLUE protocol are: 106 1. enabling a Media Provider (MP) to properly announce its current 107 telepresence capabilities to a Media Consumer (MC) in terms of 108 available media captures, groups of encodings, simultaneity 109 constraints and other information defined in 110 [I-D.ietf-clue-framework]; 112 2. enabling an MC to request the desired multimedia streams from the 113 offering MP. 115 CLUE-capable endpoints are connected by means of the CLUE data 116 channel, an SCTP over DTLS channel that is opened and established as 117 described in [I-D.ietf-clue-signaling] and 118 [I-D.ietf-clue-datachannel]. CLUE protocol messages flowing over 119 such a channel are detailed in this document, both syntactically and 120 semantically. 122 In Section 4 we provide a general overview of the CLUE protocol. 123 CLUE protocol messages are detailed in Section 5. The CLUE Protocol 124 state machines are introduced in Section 6. Versioning and 125 extensions are discussed in Section 7 and Section 8, respectively. 126 The XML schema defining the CLUE messages is reported in Section 9. 128 2. Terminology 130 This document refers to the same terminology used in 131 [I-D.ietf-clue-framework] and in [RFC7262]. We briefly recall herein 132 some of the main terms used in the document. The definition of "CLUE 133 Participant" herein proposed is not imported from any of the above 134 documents. 136 Capture Encoding: A specific encoding of a Media Capture, to be sent 137 via RTP [RFC3550]. 139 CLUE Participant (CP): An entity able to use the CLUE protocol 140 within a telepresence session. It can be an endpoint or an MCU 141 (Multipoint Control Unit) able to use the CLUE protocol. 143 CLUE-capable device: A device that supports the CLUE data channel 144 [I-D.ietf-clue-datachannel], the CLUE protocol and the principles 145 of CLUE negotiation, and seeks CLUE-enabled calls. 147 Endpoint: A CLUE-capable device that is the logical point of final 148 termination through receiving, decoding and rendering, and/or 149 initiation through capturing, encoding, and sending of media 150 streams. An endpoint consists of one or more physical devices 151 that source and sink media streams, and exactly one [RFC4353] 152 Participant (which, in turn, includes exactly one [RFC3261] User 153 Agent). Endpoints can be anything from multiscreen/multicamera 154 rooms to handheld devices. 156 Multipoint Control Unit (MCU): a CLUE-capable device that connects 157 two or more endpoints together into one single multimedia 158 conference [RFC7667]. An MCU includes an [RFC4353]-like Mixer, 159 without the [RFC4353] requirement to send media to each 160 participant. 162 Media: Any data that, after suitable encoding, can be conveyed over 163 RTP, including audio, video or timed text. 165 Media Capture: a source of Media, such as from one or more Capture 166 Devices or constructed from other Media streams. 168 Media Consumer (MC): A CLUE Participant (i.e., an Endpoint or an 169 MCU) able to receive Capture Encodings. 171 Media Provider (MP): A CLUE Participant (i.e., an Endpoint or an 172 MCU) able to send Capture Encodings. 174 Stream: a Capture Encoding sent from a Media Provider to a Media 175 Consumer via RTP [RFC3550]. 177 3. Conventions 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 181 "OPTIONAL" in this document are to be interpreted as described in BCP 182 14 [RFC2119] [RFC8174] when, and only when, they appear in all 183 capitals, as shown here. 185 4. Overview of the CLUE protocol 187 The CLUE protocol is conceived to enable CLUE telepresence sessions. 188 It is designed in order to address SDP limitations in terms of the 189 description of some information about the multimedia streams that are 190 involved in a real-time multimedia conference. Indeed, by simply 191 using SDP it is not possible to convey information about the features 192 of the flowing multimedia streams that are needed to enable a "being 193 there" rendering experience. Such information is contained in the 194 CLUE framework document [I-D.ietf-clue-framework] and formally 195 defined and described in the CLUE data model document 196 [I-D.ietf-clue-data-model-schema]. The CLUE protocol represents the 197 mechanism for the exchange of telepresence information between CLUE 198 Participants. It mainly provides the messages to enable a Media 199 Provider to advertise its telepresence capabilities and to enable a 200 Media Consumer to select the desired telepresence options. 202 The CLUE protocol, as defined in the following, is a stateful, 203 client-server, XML-based application protocol. CLUE protocol 204 messages flow on a reliable and ordered SCTP over DTLS transport 205 channel connecting two CLUE Participants. Messages carry information 206 taken from the XML-based CLUE data model 207 ([I-D.ietf-clue-data-model-schema]). Three main communication phases 208 can be identified: 210 1. Establishment of the CLUE data channel: in this phase, the CLUE 211 data channel setup takes place. If it completes successfully, 212 the CPs are able to communicate and start the initiation phase. 214 2. Negotiation of the CLUE protocol version and extensions 215 (initiation phase): the CPs connected via the CLUE data channel 216 agree on the version and on the extensions to be used during the 217 telepresence session. Special CLUE messages are used for such a 218 task ('options' and 'optionsResponse'). The version and 219 extensions negotiation can be performed once during the CLUE 220 session and only at this stage. At the end of that basic 221 negotiation, each CP starts its activity as a CLUE MP and/or CLUE 222 MC. 224 3. CLUE telepresence capabilities description and negotiation: in 225 this phase, the MP-MC dialogues take place on the data channel by 226 means of the CLUE protocol messages. 228 As soon as the channel is ready, the CLUE Participants must agree on 229 the protocol version and extensions to be used within the 230 telepresence session. CLUE protocol version numbers are 231 characterized by a major version number (single digit) and a minor 232 version number (single digit), both unsigned integers, separated by a 233 dot. While minor version numbers denote backward compatible changes 234 in the context of a given major version, different major version 235 numbers generally indicate a lack of interoperability between the 236 protocol implementations. In order to correctly establish a CLUE 237 dialogue, the involved CPs must have in common a major version number 238 (see Section 7 for further details). The subset of the extensions 239 that are allowed within the CLUE session is also determined in the 240 initiation phase. It includes only the extensions that are supported 241 by both parties. A mechanism for the negotiation of the CLUE 242 protocol version and extensions is part of the initiation phase. 243 According to such a solution, the CP that is the CLUE Channel 244 Initiator (CI) issues a proper CLUE message ('options') to the CP 245 that is the Channel Receiver (CR) specifying the supported version 246 and extensions. The CR then answers by selecting the subset of the 247 CI extensions that it is able to support and determines the protocol 248 version to be used. 250 After the negotiation phase is completed, CLUE Participants describe 251 and agree on the media flows to be exchanged. In many cases CPs will 252 seek to both transmit and receive media. Hence in a call between two 253 CPs, A and B, there would be two separate message exchange sequences, 254 as follows: 256 1. the one needed to describe and set up the media streams sent from 257 A to B, i.e., the dialogue between A's Media Provider side and 258 B's Media Consumer side 260 2. the one needed to describe and set up the media streams sent from 261 B to A, i.e., the dialogue between B's Media Provider side and 262 A's Media Consumer side 264 CLUE messages for the media session description and negotiation are 265 designed by considering the MP side as the server side of the 266 protocol, since it produces and provides media streams, and the MC 267 side as the client side of the protocol, since it requests and 268 receives media streams. The messages that are exchanged to set up 269 the telepresence media session are described by focusing on a single 270 MP-MC dialogue. 272 The MP first advertises its available media captures and encoding 273 capabilities to the MC, as well as its simultaneity constraints, 274 according to the information model defined in 275 [I-D.ietf-clue-framework]. The CLUE message conveying the MP's 276 multimedia offer is the 'advertisement' message. Such message 277 leverages the XML data model definitions provided in 278 [I-D.ietf-clue-data-model-schema]. 280 The MC selects the desired streams of the MP by using the 'configure' 281 message, which makes reference to the information carried in the 282 previously received 'advertisement'. 284 Besides 'advertisement' and 'configure', other messages have been 285 conceived in order to provide all the needed mechanisms and 286 operations. Such messages are detailed in the following sections. 288 5. Protocol messages 290 CLUE protocol messages are textual, XML-based messages that enable 291 the configuration of the telepresence session. The formal definition 292 of such messages is provided in the XML Schema provided at the end of 293 this document (Section 9). This section includes non-normative 294 excerpts of the schema to aid in describing it. 296 The XML definitions of the CLUE information provided in 297 [I-D.ietf-clue-data-model-schema] are included within some CLUE 298 protocol messages (namely the 'advertisement' and the 'configure' 299 messages), in order to use the concepts defined in 300 [I-D.ietf-clue-framework]. 302 The CLUE protocol messages are the following: 304 o options 306 o optionsResponse 308 o advertisement 310 o ack 312 o configure 314 o configureResponse 316 While the 'options' and 'optionsResponse' messages are exchanged in 317 the initiation phase between the CPs, the other messages are involved 318 in MP-MC dialogues. Please note that the word "dialog" in this 319 document is not related to SIP's usage of the same term. It refers 320 to message exchange sequences between a CLUE Media Provider and a 321 Clue Media Consumer. 323 Each CLUE message inherits a basic structure depicted in the 324 following excerpt (Figure 1): 326 327 328 329 330 331 333 334 336 337 338 339 340 341 343 Figure 1: Structure of a CLUE message 345 The information contained in each CLUE message is: 347 o clueId: an optional XML element containing the identifier (in the 348 form of a generic string) of the CP within the telepresence 349 system; 351 o sequenceNr: an XML element containing the local message sequence 352 number. The sender MUST increment the sequence numbers by one for 353 each new message sent, the receiver MUST remember the most recent 354 sequence number received and send back a 402 error if it receives 355 a message with an unexpected sequence number (e.g., sequence 356 number gap, repeated sequence number, sequence number too small). 357 The initial sequence number can be chosen randomly by each party; 359 o protocol: a mandatory attribute set to "CLUE", identifying the 360 procotol the messages refer to; 362 o v: a mandatory attribute carrying the version of the protocol. 363 The content of the "v" attribute is composed by the major version 364 number followed by a dot and then by the minor version number of 365 the CLUE protocol in use. The major number cannot be "0" and, if 366 it is more than one digit, it cannot start with a "0". Allowed 367 values are of this kind are, e.g., "1.3", "2.0", "20.44" etc. 368 This document describes version 1.0. 370 Each CP is responsible for creating and updating up to three 371 independent streams of sequence numbers in messages it sends: (i) one 372 for the messages sent in the initiation phase, (ii) one for the 373 messages sent as MP (if it is acting as a MP), and (iii) one for the 374 messages sent as MC (if it is acting as a MC). 376 In particular, CLUE response messages ('optionsResponse', 'ack', 377 'configureResponse') derive from a base type, inheriting from the 378 clueMessageType, which is defined as follows (Figure 2): 380 381 382 383 384 385 386 387 388 389 391 Figure 2: Structure of CLUE response messages 393 The elements and get populated as 394 detailed in Section 5.7 396 5.1. options 398 The 'options' message is sent by the CLUE Participant that is the 399 Channel Initiator to the CLUE Participant that is the Channel 400 Receiver as soon as the CLUE data channel is ready. Besides the 401 information envisioned in the basic structure, it specifies: 403 o : a mandatory boolean field set to "true" if the CP 404 is able to act as a MP 406 o : a mandatory boolean field set to "true" if the CP 407 is able to act as a MC 409 o : the list of the supported versions 411 o : the list of the supported extensions 413 The XML Schema of such a message is reported below (Figure 3): 415 416 417 418 419 420 421 422 424 426 428 429 430 431 432 434 435 436 437 439 440 441 442 444 445 446 447 449 450 451 452 454 455 456 457 458 459 460 461 462 463 464 Figure 3: Structure of CLUE 'options' message 466 contains the list of the versions that are 467 supported by the CI, each one represented in a child 468 element. The content of each element is a string made by 469 the major version number followed by a dot and then by the minor 470 version number (e.g., 1.3 or 2.4). Exactly one element 471 MUST be provided for each major version supported, containing the 472 maximum minor version number of such a version, since all minor 473 versions are backward compatible. If no is 474 carried within the 'options' message, the CI supports only the 475 version declared in the "v" attribute and all the versions having the 476 same major version number and lower minor version number. For 477 example, if the "v" attribute has a value of "3.4" and there is no 478 tag in the 'options' message, it means the CI 479 supports only major version 3 with all the minor versions comprised 480 between 3.0 and 3.4, with version 3.4 included. If a 481 is provided, at least one tag MUST be 482 included. In this case, the "v" attribute SHOULD be set to the 483 largest minor version of the smallest major version advertised in the 484 list. Indeed, the intention behind the "v" 485 attribute is that some implementation that receives a version number 486 in the "v" field with a major number higher than it understands is 487 supposed to close the connection, since it runs a risk of 488 misinterpreting the contents of messages. The minor version is less 489 useful in this context, since minor versions are defined to be both 490 backwards and forwards compatible, but it is more useful to know the 491 highest minor version supported than some random minor version, as it 492 indicates the full feature set that is supported. The reason why it 493 is less useful is that the value can in any case be parsed out of the 494 list. 496 The element specifies the list of extensions 497 supported by the CI. If there is no in the 498 'options' message, the CI does not support anything other than what 499 is envisioned in the versions it supports. For each extension, an 500 element is provided. An extension is characterized by a 501 name, an XML schema of reference where the extension is defined, and 502 the version of the protocol which the extension refers to. 504 5.2. optionsResponse 506 The 'optionsResponse' (Figure 4) is sent by a CR to a CI as a reply 507 to the 'options' message. The 'optionsResponse' contains a mandatory 508 response code and a reason string indicating the processing result of 509 the 'options' message. If the responseCode is between 200 and 299 510 inclusive, the response MUST also include , 511 , and elements; it MAY 512 include them for any other response code. and 513 elements (which are of a boolean nature) are 514 associated with the supported roles (in terms of, respectively MP and 515 MC), similarly to what the CI does in the 'options' message. The 516 field indicates the highest commonly supported version 517 number. The content of the element MUST be a string made 518 of the major version number followed by a dot and then by the minor 519 version number (e.g., 1.3 or 2.4). Finally, the commonly supported 520 extensions are copied in the field. 522 523 524 525 526 527 529 531 532 534 536 537 538 539 540 542 Figure 4: Structure of CLUE 'optionsResponse' message 544 Upon reception of the 'optionsResponse' the version to be used is the 545 one provided in the tag of the message. The following CLUE 546 messages MUST use such a version number in the "v" attribute. The 547 allowed extensions in the CLUE dialogue are those indicated in the 548 of the 'optionsResponse' message. 550 5.3. advertisement 552 The 'advertisement' message is used by each MP to advertise the 553 available media captures and related information to the corresponding 554 MC. The MP sends an 'advertisement' to the MC as soon as it is ready 555 after the successful completion of the initiation phase, i.e., as 556 soon as the version and the extensions of the CLUE protocol are 557 agreed between the CPs. During a single CLUE session, an MP may send 558 new 'advertisement' messages to replace the previous advertisement, 559 if, for instance, its CLUE telepresence media capabilities change 560 mid-call. A new 'advertisement' completely replaces the previous 561 'advertisement'. 563 The 'advertisement' structure is defined in the schema excerpt below 564 (Figure 5). The 'advertisement' contains elements compliant with the 565 CLUE data model that characterize the MP's telepresence offer. 566 Namely, such elements are: the list of the media captures 567 (), of the encoding groups (), of the 568 capture scenes (), of the simultaneous sets 569 (), of the global views (), and of the 570 represented participants (). Each of them is fully described 571 in the CLUE framework document and formally defined in the CLUE data 572 model document. 574 575 576 577 578 579 580 581 582 583 584 586 588 589 591 592 593 594 595 597 Figure 5: Structure of CLUE 'advertisement' message 599 5.4. ack 601 The 'ack' message is sent by a MC to a MP to acknowledge an 602 'advertisement' message. As it can be seen from the message schema 603 provided in the following excerpt (Figure 6), the 'ack' contains a 604 response code and may contain a reason string for describing the 605 processing result of the 'advertisement'. The 606 carries the sequence number of 'advertisement' message the 'ack' 607 refers to. 609 610 611 612 613 614 615 617 618 619 620 621 623 Figure 6: Structure of CLUE 'ack' message 625 5.5. configure 627 The 'configure' message is sent from a MC to a MP to list the 628 advertised captures the MC wants to receive. The MC MUST send a 629 'configure' after the reception of an 'advertisement', as well as 630 each time it wants to request other captures that have been 631 previously advertised by the MP. The content of the 'configure' 632 message is shown below (Figure 7). 634 635 636 637 638 639 640 641 643 645 647 648 649 650 651 653 Figure 7: Structure of CLUE 'configure' message 655 The element contains the sequence number of the 656 'advertisement' message the 'configure' refers to. 658 The optional element, when present, contains a success response 659 code, as defined in Section 5.7. It indicates that the 'configure' 660 message also acknowledges with success the referred advertisement 661 ('configure' + 'ack' message). The element MUST NOT be present 662 if an 'ack' message (associated with the advertisement carrying that 663 specific sequence number) has been already sent back to the MP. 665 The most important content of the 'configure' message is the list of 666 the capture encodings provided in the element (see 667 [I-D.ietf-clue-data-model-schema] for the definition of 668 ). Such an element contains a sequence of capture 669 encodings, representing the streams to be instantiated. 671 5.6. configureResponse 673 The 'configureResponse' message is sent from the MP to the MC to 674 communicate the processing result of requests carried in the 675 previously received 'configure' message. It contains (Figure 8) a 676 response code (and optionally a reason string) indicating either the 677 success or the failure (along with failure details) of a 'configure' 678 request processing. Following, the field contains 679 the sequence number of the 'configure' message the response refers 680 to. There is no partial execution of commands. As an example, if a 681 MP is able to understand all the selected capture encodings except 682 one, then the whole command fails and nothing is instantiated. 684 685 686 687 688 689 690 692 693 694 695 696 698 Figure 8: Structure of CLUE 'configureResponse' message 700 5.7. Response codes and reason strings 702 Response codes are defined as a sequence of three digits. A well- 703 defined meaning is associated with the first digit. Response codes 704 beginning with "2" are associated with successful responses. 705 Response codes that do not begin with either "2" or "1" indicate an 706 error response, i.e., that an error occurred while processing a CLUE 707 request. In particular, response codes beginning with "3" indicate 708 problems with the XML content of the message ("Bad syntax", "Invalid 709 value", etc.), while response codes beginning with "4" refer to 710 problems related to CLUE protocol semantics ("Invalid sequencing", 711 "Version not supported", etc.). 200, 300 and 400 codes are the most 712 generic ones in their respective categories. Further response codes 713 can be either defined in future versions of the protocol, or defined 714 by leveraging the extension mechanism. In both cases, the new 715 response codes MUST be registered with IANA. Such new response codes 716 MUST NOT override the ones here defined and they MUST respect the 717 semantics of the first code digit. 719 This document does not define response codes starting with "1", and 720 such response codes are not allowed to appear in major version 1 of 721 the CLUE protocol. The range from 100 to 199 inclusive is reserved 722 for future major versions of the protocol to define response codes 723 for delayed or incomplete operations if necessary. Response codes 724 starting with "5" through "9" are reserved for future major versions 725 of the protocol to define new classes of response, and are not 726 allowed in major version 1 of the CLUE protocol. Response codes 727 starting with "0" are not allowed. 729 The response codes and strings defined for use with version 1 of the 730 CLUE protocol are listed in Figure 9. The "Description" text 731 contained in the table can be sent in the element of a 732 response message. Implementations can (and are encouraged to) 733 include more specific descriptions of the error condition, if 734 possible. 736 +-----------------+----------------------+--------------------------+ 737 | | | | 738 | Response code | Reason string | Description | 739 | | | | 740 +-----------------+----------------------+--------------------------+ 741 | | | | 742 | 200 | Success | The request has been | 743 | | | successfully processed. | 744 | | | | 745 +-----------------+----------------------+--------------------------+ 746 | | | | 747 | 300 | Low-level request | A generic low-level | 748 | | error. | request error has | 749 | | | occurred. | 750 | | | | 751 +-----------------+----------------------+--------------------------+ 752 | | | | 753 | 301 | Bad syntax | The XML syntax of the | 754 | | | message is not correct. | 755 +-----------------+----------------------+--------------------------+ 756 | | | | 757 | 302 | Invalid value | The message | 758 | | | contains an invalid | 759 | | | parameter value. | 760 +-----------------+----------------------+--------------------------+ 761 | | | | 762 | 303 | Conflicting values | The message | 763 | | | contains values that | 764 | | | cannot be used together.| 765 +-----------------+----------------------+--------------------------+ 766 | | | | 767 | 400 | Semantic errors | Semantic errors in the | 768 | | | received CLUE protocol | 769 | | | message. | 770 | | | | 771 +-----------------+----------------------+--------------------------+ 772 | | | | 773 | 401 | Version not supported| The protocol version | 774 | | | used in the message | 775 | | | is not supported. | 776 | | | | 777 +-----------------+----------------------+--------------------------+ 778 | | | | 779 | 402 | Invalid sequencing | Sequence number gap; | 780 | | | repeated sequence number;| 781 | | | sequence number outdated.| 782 +-----------------+----------------------+--------------------------+ 783 | | | | 784 | 403 | Invalid identifier | The clueId used in | 785 | | | the message is | 786 | | | not valid or unknown. | 787 +-----------------+----------------------+--------------------------+ 788 | | | The sequence number of | 789 | 404 | advertisement | the advertisement the | 790 | | Expired | configure refers to is | 791 | | | out of date. | 792 +-----------------+----------------------+--------------------------+ 793 | | | | 794 | 405 | Subset choice not | The subset choice is not | 795 | | allowed | allowed for the specified| 796 | | | Multiple Content Capture | 797 +-----------------+----------------------+--------------------------+ 799 Figure 9: CLUE response codes 801 6. Protocol state machines 803 The CLUE protocol is an application protocol used between two CPs in 804 order to properly configure a multimedia telepresence session. CLUE 805 protocol messages flow over the CLUE Data Channel, a DTLS/SCTP 806 channel established as depicted in [I-D.ietf-clue-datachannel]. We 807 herein discuss the state machines associated, respectively, with the 808 CLUE Participant (Figure 10), with the MC role (Figure 11) and with 809 the MP role (Figure 12). Endpoints often wish to both send and 810 receive media, i.e., act as both MP and MC. As such there will often 811 be two sets of messages flowing in opposite directions; the state 812 machines of these two flows do not interact with each other. Only 813 the CLUE application logic is considered. The interaction of CLUE 814 protocol and SDP negotiations for the media streams exchanged is 815 treated in [I-D.ietf-clue-signaling]. 817 The main state machines focus on the behavior of the CLUE Participant 818 (CP) acting as a CLUE Channel Initiator/Receiver (CI/CR). 820 The initial state is the IDLE one. When in the IDLE state, the CLUE 821 data channel is not established and no CLUE-controlled media are 822 exchanged between the two considered CLUE-capable devices (if there 823 is an ongoing exchange of media streams, such media streams are not 824 currently CLUE-controlled). 826 When the CLUE data channel sets up ("start channel"), the CP moves 827 from the IDLE state to the CHANNEL SETUP state. 829 If the CLUE data channel is successfully set up ("channel 830 established"), the CP moves from the CHANNEL SETUP state to the 831 OPTIONS state. Otherwise if "channel error", it moves back to the 832 IDLE state. The same transition happens if the CLUE-enabled 833 telepresence session ends ("session ends"), i.e., when an SDP 834 negotiation for removing the CLUE data channel is performed. 836 When in the OPTIONS state, the CP addresses the initiation phase 837 where both parts agree on the version and on the extensions to be 838 used in the subsequent CLUE messages exchange phase. If the CP is 839 the Channel Initiator (CI), it sends an 'options' message and waits 840 for the 'optionsResponse' message. If the CP is the Channel Receiver 841 (CR), it waits for the 'options' message and, as soon as it arrives, 842 replies with the 'optionsResponse' message. If the negotiation is 843 successfully completed ("OPTIONS phase success"), the CP moves from 844 the OPTIONS state to the ACTIVE state. If the initiation phase fails 845 ("OPTIONS phase failure"), the CP moves from the OPTIONS state to the 846 IDLE state. The initiation phase might fail because of one of the 847 following reasons: 849 1. the CI receives an 'optionsResponse' with an error response code 851 2. the CI does not receive any 'optionsResponse' and a timeout error 852 is raised 854 3. the CR does not receive any 'options' and a timeout error is 855 raised 857 When in the ACTIVE state, the CP starts the envisioned sub-state 858 machines (i.e., the MP state machine and the MC state machine) 859 according to the roles it plays in the telepresence sessions. Such 860 roles have been previously declared in the 'options' and 861 'optionsResponse' messages involved in the initiation phase (see 862 OPTIONS sections Section 5.1 and Section 5.2 for the details). When 863 in the ACTIVE state, the CP delegates the sending and the processing 864 of the CLUE messages to the appropriate MP/MC sub-state machines. If 865 the CP receives a further 'options'/'optionsResponse' message, it 866 MUST ignore the message and stay in the ACTIVE state. 868 +----+ 869 +---------------------->|IDLE|<----------------------------+ 870 | +-+--+ | 871 | | | 872 | | start | 873 | | channel | 874 | v | 875 | channel error/ +--------+ | 876 | session ends | CHANNEL| | 877 +----------------------+ SETUP | | 878 | +--+-----+ | 879 | | | 880 | | channel | 881 | | established | 882 | channel error/ v OPTIONS phase | 883 | session ends +-------+ failure | 884 +-----------------------+OPTIONS+--------------------------+ 885 | +-+-----+ 886 | | 887 | | OPTIONS phase 888 | | success 889 | v 890 | channel error/ +---------+ 891 | session ends | ACTIVE | 892 +----------------------+ | 893 | +----+ +------------------+ 894 | | MP | | send/receive | 895 | +----+ | CLUE messages | 896 | |<-----------------+ 897 | +----+ | 898 | | MC | | 899 | +----+ | 900 | | 901 +---------+ 903 Figure 10: CLUE Participant state machine 905 6.1. Media Provider's state machine 907 As soon as the sub-state machine of the MP (Figure 11) is activated, 908 it is in the ADV state. In the ADV state, the MP prepares the 909 'advertisement' message reflecting its actual telepresence 910 capabilities. 912 After the 'advertisement' has been sent ("advertisement sent"), the 913 MP moves from the ADV state to the WAIT FOR ACK state. If an 'ack' 914 message with a successful response code arrives ("ack received"), the 915 MP moves to the WAIT FOR CONF state. If a NACK arrives (i.e., an 916 'ack' message with an error response code), the MP moves back to the 917 ADV state for preparing a new 'advertisement'. When in the WAIT FOR 918 ACK state, if a 'configure' message with the element set to 919 TRUE arrives ("configure+ack received"), the MP goes directly to the 920 CONF RESPONSE state. 'configure+ack' messages referring to out-of- 921 date (i.e., having a sequence number less than the highest generated 922 so far) advertisements MUST be ignored, i.e., they do not trigger any 923 state transition. If the telepresence settings of the MP change 924 while in the WAIT FOR ACK state ("changed telepresence settings"), 925 the MP switches from the WAIT FOR ACK state to the ADV state to 926 create a new 'advertisement'. 928 When in the WAIT FOR CONF state, the MP listens to the channel for a 929 'configure' request coming from the MC. When a 'configure' arrives 930 ("configure received"), the MP switches to the CONF RESPONSE state. 931 If the telepresence settings change in the meanwhile ("changed 932 telepresence settings"), the MP moves from the WAIT FOR CONF back to 933 the ADV state to create the new 'advertisement' to be sent to the MC. 935 The MP in the CONF RESPONSE state processes the received 'configure' 936 in order to produce a 'configureResponse' message. If the MP 937 successfully processes the MC's configuration, then it sends a 200 938 'configureResponse' ("success configureResponse sent") and moves to 939 the ESTABLISHED state. If there are errors in the 'configure' 940 processing, then the MP issues a 'configureResponse' carrying an 941 error response code and it goes back to the WAIT FOR CONF state to 942 wait for a new configuration request. Finally, if there are changes 943 in the MP's telepresence settings ("changed telepresence settings"), 944 the MP switches to the ADV state. 946 The MP in the ESTABLISHED state has successfully negotiated the media 947 streams with the MC by means of the CLUE messages. If there are 948 changes in the MP's telepresence settings ("changed telepresence 949 settings"), the MP moves back to the ADV state. In the ESTABLISHED 950 state, the CLUE-controlled media streams of the session are those 951 described in the last successfully processed 'configure' message. 953 Messages not shown for a state do not cause the state to change. 955 +-----+ 956 +------------>| ADV |<-------------------+ 957 | +-+---+ | 958 | advertisement| NACK received | 959 | sent| | 960 | v | 961 changed| +--------+ | 962 telepresence+-------------+WAIT FOR+-----------------+ 963 settings| +----------+ ACK | 964 | |configure +-+------+ 965 | | + ack | 966 | |received |ack received 967 | | v 968 | | +--------+ 969 +-------------+WAIT FOR| 970 | | | CONF | 971 | | +-+------+<-----------------------------+ 972 | | | | 973 | | |configure received | 974 | | v | 975 | +--------->+---------+ error configureResponse sent| 976 +-------------+CONF |-----------------------------+ 977 | +--------->|RESPONSE + 978 | | +---------+ 979 | | | 980 | | |success 981 | | |configureResponse 982 | | |sent 983 | | | 984 | | | 985 | |configure | 986 | |received v 987 | | +-----------+ 988 | +----------+ESTABLISHED| 989 +-------------+-----------+ 991 Figure 11: Media Provider's state machine 993 6.2. Media Consumer's state machine 995 As soon as the sub-state machine of the MC (Figure 12) is activated, 996 it is in the WAIT FOR ADV state. An MC in the WAIT FOR ADV state is 997 waiting for an 'advertisement' coming from the MP. If the 998 'advertisement' arrives ("ADV received"), the MC reaches the ADV 999 PROCESSING state. Otherwise, the MC stays in the WAIT FOR ADV state. 1001 In the ADV PROCESSING state, the 'advertisement' is parsed by the MC. 1002 If the 'advertisement' is successfully processed, there are two 1003 possibilities. In the former case, the MC issues a successful 'ack' 1004 message to the MP ("ACK sent") and moves to the CONF state. This 1005 typically happens when the MC needs some more time to produce the 1006 'configure' message associated with the received 'advertisement'. In 1007 the latter case, the MC is able to immediately prepare and send back 1008 to the MP a 'configure' message. Such a message will have the 1009 field set to "200" ("configure+ack sent") and will allow the MC to 1010 move directly to the WAIT FOR CONF RESPONSE state. 1012 If the ADV processing is unsuccessful (bad syntax, missing XML 1013 elements, etc.), the MC sends a NACK message (i.e., an 'ack' with an 1014 error response code) to the MP and optionally further describes the 1015 problem via a proper reason phrase. In this way ("NACK sent"), the 1016 MC switches back to the WAIT FOR ADV state, waiting for a new 1017 'advertisement'. 1019 When in the CONF state, the MC prepares the 'configure' request to be 1020 issued to the MP on the basis of the previously ack-ed 1021 'advertisement'. When the 'configure' has been sent ("configure 1022 sent"), the MC moves to the WAIT FOR CONF RESPONSE state. If a new 1023 'advertisement' arrives in the meanwhile ("advertisement received"), 1024 the MC goes back to the ADV PROCESSING state. 1026 In the WAIT FOR CONF RESPONSE state, the MC waits for the MP's 1027 response to the issued 'configure' or 'configure+ack'. If a 200 1028 'configureResponse' message is received ("successful 1029 configureResponse received"), it means that the MP and the MC have 1030 successfully agreed on the media streams to be shared. Then, the MC 1031 can move to the ESTABLISHED state. On the other hand, if an error 1032 response is received ("error configureResponse received"), the MC 1033 moves back to the CONF state to prepare a new 'configure' request. 1034 If a new 'advertisement' is received in the WAIT FOR CONF RESPONSE 1035 state, the MC switches to the ADV PROCESSING state. 1037 When the MC is in the ESTABLISHED state, the telepresence session 1038 configuration has been set up at the CLUE application level according 1039 to the MC's preferences. Both the MP and the MC have agreed on (and 1040 are aware of) the CLUE-controlled media streams to be exchanged 1041 within the call. While in the ESTABLISHED state, it might happen 1042 that the MC decides to change something in the call settings. The MC 1043 then issues a new 'configure' ("configure sent") and goes to wait for 1044 the new 'configureResponse' in the WAIT FOR CONF RESPONSE state. On 1045 the other hand, in the ESTABLISHED state, if a new 'advertisement' 1046 arrives from the MP ("advertisement received"), it means that 1047 something has changed on the MP's side. The MC then moves to the ADV 1048 PROCESSING state. 1050 Messages not shown for a state do not cause the state to change. 1052 +----------+ 1053 | WAIT FOR | 1054 | ADV | 1055 +----+-----+<--------+ 1056 | | 1057 advertisement| NACK sent| 1058 received| | 1059 v | 1060 +-----------+--------+ 1061 | ADV + 1062 | PROCESSING|<-----------------------+ 1063 +-+-----+---+ | 1064 | | | 1065 configure+ack | | ack | 1066 sent | | sent | 1067 | v | 1068 | +-----+ | 1069 | |CONF | advertisement received | 1070 +----------------------->| +-------------------------+ 1071 |error | +--+--+ | 1072 |configureResponse | | | 1073 |received | |configure | 1074 | | |sent | 1075 | | | | 1076 | v v advertisement | 1077 +------------------+---------------+ received | 1078 +--------->| WAIT FOR +---------------------+ 1079 | | CONF RESPONSE+ | 1080 | +-------+-------+ | 1081 | | | 1082 | | | 1083 | |successful | 1084 | |configureResponse | 1085 | |received | 1086 |configure v | 1087 |sent +-----------+ advertisement received| 1088 +------------+ESTABLISHED+-----------------------+ 1089 +-----------+ 1091 Figure 12: Media Consumer's state machine 1093 7. Versioning 1095 CLUE protocol messages are XML messages compliant to the CLUE 1096 protocol XML schema [I-D.ietf-clue-data-model-schema]. The version 1097 of the protocol corresponds to the version of the schema. Both 1098 client and server have to test the compliance of the received 1099 messages with the XML schema of the CLUE protocol. If the compliance 1100 is not verified, the message cannot be processed further. 1102 Client and server cannot communicate if they do not share exactly the 1103 same XML schema. Such a schema is associated with the CLUE URN 1104 "urn:ietf:params:xml:ns:clue-protocol". If all CLUE-enabled devices 1105 use that schema there will be no interoperability problems due to 1106 schema issues. 1108 This document defines XML schema version 1.0. The version usage is 1109 similar in philosophy to XMPP ([RFC6120]). A version number has 1110 major and minor components, each a non-negative integer. Major 1111 version changes denote non-interoperable changes. Minor version 1112 changes denote schema changes that are backward compatible by 1113 ignoring unknown XML elements, or other backward compatible changes. 1115 The minor versions of the XML schema MUST be backward compatible, not 1116 only in terms of schema but also semantically and procedurally as 1117 well. This means that they should define further features and 1118 functionality besides those defined in the previous versions, in an 1119 incremental way, without impacting the basic rules defined in the 1120 previous version of the schema. In this way, if a MP is able to 1121 speak, e.g., version 1.5 of the protocol while the MC only 1122 understands version 1.4, the MP should have no problem in reverting 1123 the dialogue back to version 1.4 without exploiting 1.5 features and 1124 functionality. Version 1.4 is the one to be spoken and has to appear 1125 in the "v" attribute of the subsequent CLUE messages. In other 1126 words, in this example, the MP MUST use version 1.4. This said, and 1127 coherently with the general IETF "protocol robustness principle" 1128 stating that "an implementation must be conservative in its sending 1129 behavior, and liberal in its receiving behavior" [RFC1122], CLUE 1130 Participants MUST ignore unknown elements or attributes that are not 1131 envisioned in the negotiated protocol version and related extensions. 1133 8. Extensions 1135 Although the standard version of the CLUE protocol XML schema is 1136 designed to thoroughly cope with the requirements emerging from the 1137 application domain, new needs might arise and extensions can be 1138 designed. Extensions specify information and behaviors that are not 1139 described in a certain version of the protocol and specified in the 1140 related RFC document. Such information and behaviors can be 1141 optionally used in a CLUE dialogue and MUST be negotiated in the CLUE 1142 initiation phase. They can relate to: 1144 1. new information, to be carried in the existing messages. For 1145 example, more fields may be added within an existing message; 1147 2. new messages. This is the case if there is no proper message for 1148 a certain task, so a brand new CLUE message needs to be defined. 1150 As to the first type of extensions, it is possible to distinguish 1151 between protocol-specific and data model information. Indeed, CLUE 1152 messages are envelopes carrying both: 1154 o (i) XML elements defined within the CLUE protocol XML schema 1155 itself (protocol-specific information) 1157 o (ii) other XML elements compliant to the CLUE data model schema 1158 (data model information) 1160 When new protocol-specific information is needed somewhere in the 1161 protocol messages, it can be added in place of the elements and 1162 elements envisioned by the protocol schema. The 1163 policy currently defined in the protocol schema for handling 1164 and elements is: 1166 o elementFormDefault="qualified" 1168 o attributeFormDefault="unqualified" 1170 The new information must be qualified by namespaces other than 1171 "urn:ietf:params:xml:ns:clue-protocol" (the protocol URN) and 1172 "urn:ietf:params:xml:ns:clue-info" (the data model URN). Elements or 1173 attributes from unknown namespaces MUST be ignored. 1175 The other matter concerns data model information. Data model 1176 information is defined by the XML schema associated with the URN 1177 "urn:ietf:params:xml:ns:clue-info". Also for the XML elements 1178 defined in such a schema there are extensibility issues. Those 1179 issues are overcome by using and placeholders. 1180 New information within data model elements can be added in place of 1181 and schema elements, as long as they are 1182 properly namespace qualified. 1184 On the other hand (second type of extensions), "extra" CLUE protocol 1185 messages, i.e., messages not envisioned in the latest standard 1186 version of the schema, can be needed. In that case, the messages and 1187 the associated behavior should be defined in external documents that 1188 both communication parties must be aware of. 1190 As reported in Figure 13, the fields of the element 1191 (either new information or new messages) take the following values: 1193 o a name; 1195 o an external XML Schema defining the XML information and/or the XML 1196 messages representing the extension; 1198 o the major standard version of the protocol that the extension 1199 refers to. 1201 1202 1203 1204 1205 1206 1207 1208 1209 1211 Figure 13: The element 1213 The above described element is carried within the 1214 'options' and 'optionsResponse' messages to represent the extensions 1215 supported both by the CI and the CR. 1217 Extensions MUST be defined in a separate XML schema file and MUST be 1218 provided with a companion document describing their semantics and 1219 use. 1221 8.1. Extension example 1223 An example of extension might be a "new" capture attribute (i.e., a 1224 capture attribute that is not envisioned in the current standard 1225 defining the CLUE data model in [I-D.ietf-clue-data-model-schema]) 1226 needed to further describe a video capture. 1228 The CLUE data model document ([I-D.ietf-clue-data-model-schema]) 1229 envisions the possibility of adding this kind of "extra" information 1230 in the description of a video capture. For the sake of convenience, 1231 the XML definition of a video capture taken from 1232 [I-D.ietf-clue-data-model-schema] is reported in Figure 14 below. 1234 1235 1236 1237 1238 1239 1241 1242 1243 1244 1245 1247 Figure 14: XML definition of a CLUE video capture 1249 According to such a definition, a video capture might have, after the 1250 set of the generic media capture attributes, a set of new attributes 1251 defined elsewhere, i.e., in an XML schema defining an extension. The 1252 XML schema defining the extension might look like the following 1253 (Figure 15): 1255 1256 1263 1269 1270 1271 1272 1273 1274 1275 1276 1278 1280 1281 1283 Figure 15: XML schema defining an extension 1285 By using the extension above, a video capture can be further 1286 described in the advertisement using the element 1287 containing two extra information ( and 1288 ) besides using the attributes envisioned for a 1289 generic media capture. As stated in this document, both participants 1290 must be aware of the extension schema and related semantics to use 1291 such an extension and must negotiate it via the 'options' and 1292 'optionsResponse' mechanism. 1294 9. XML Schema 1296 NOTE TO THE RFC-Editor: Please replace "data-model-schema-19.xsd" 1297 with the right schema location for the CLUE data model schema 1298 document (which is still to be defined at the time of this writing) 1299 in this section prior to publication as an RFC. 1301 In this section, the XML schema defining the CLUE messages is 1302 provided (Figure 16). 1304 1305 1313 1314 1316 1317 1318 1319 1320 1321 1322 1324 1325 1326 1327 1328 1329 1330 1332 1333 1334 1335 1336 1337 1338 1339 1340 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1373 1375 1377 1378 1379 1380 1381 1382 1383 1384 1385 1387 1388 1389 1390 1391 1392 1393 1394 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1418 1420 1421 1423 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1439 1440 1441 1443 1446 1447 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1476 1478 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1493 1494 1495 1496 1497 1498 1500 Figure 16: Schema defining CLUE messages 1502 10. Call flow example 1504 In this section the CLUE protocol messages exchanged in the following 1505 call flow are detailed. Only one direction of media is shown for 1506 simplicity, as the other direction is precisely symmetric. 1508 +-----+ +-----+ 1509 | | | | 1510 | CP1 | | CP2 | 1511 | | | | 1512 +--+--+ +--+--+ 1513 | | 1514 | 1.options | 1515 +----------------->| 1516 | | 1517 | | 1518 |2.optionsResponse | 1519 |<-----------------+ 1520 | | 1521 | | 1522 | 3.advertisement | 1523 +----------------->| 1524 | | 1525 | | 1526 |4.configure+ack | 1527 |<-----------------+ 1528 | | 1529 | | 1530 |5.confResponse | 1531 +----------------->| 1532 | | 1533 | | 1534 |6.advertisement | 1535 +----------------->| 1536 | | 1537 | | 1538 | 7.ack | 1539 |<-----------------+ 1540 | | 1541 | | 1542 | 8.configure | 1543 |<-----------------+ 1544 | | 1545 | | 1546 | 9.confResponse | 1547 +----------------->| 1548 | | 1549 | | 1550 . . 1551 . . 1552 . . 1554 Two CLUE Participants, CP1 and CP2, have successfully set up the CLUE 1555 channel according to document [I-D.ietf-clue-datachannel]. CP1 is 1556 the Channel Initiator (CI) and CP2 is the Channel Receiver (CR). 1558 The initiation phase starts (negotiation of the CLUE protocol version 1559 and extensions). CP1, as the CI, sends to CP2 an 'options' message 1560 specifying the supported versions and extensions (Section 10.1). CP1 1561 supports: (i) version 1.4 with extensions E1, E2 and E3, (ii) version 1562 2.7 with extensions E4 and E5. Because of such capabilities, CP1 1563 sends an 'options' message with the 'v' attribute set to 1.4 and 1564 specifies explicitly all the supported versions and extensions in the 1565 corresponding fields of the 'options' message. In the 'options' 1566 message, CP1 specifies also that it intends to act both as a MP and 1567 as a MC. 1569 CP2 supports version 3.0, version 2.9 and version 1.9 of the CLUE 1570 protocol, each version without any extension. Version 2.7 is the 1571 best common choice. Given the received 'options' message, CP2 1572 answers with an 'optionsResponse' message in which it specifies only 1573 version 2.7 as the agreed version of the CLUE protocol to be used, 1574 leaving blank the extensions part of the message to say that no 1575 extension will be used in the CLUE session (Section 10.2). In the 1576 'optionsResponse' message, CP2 specifies also that it intends to act 1577 both as a MP and as a MC. 1579 After the initiation phase is completed, CP1 and CP2 start their 1580 activity as MP and as MC. For the sake of simplicity, the following 1581 call flow focuses only on the dialogue between MP CP1 and MC CP2. 1583 CP1 advertises a telepresence configuration like the one described in 1584 [I-D.ietf-clue-data-model-schema], Sec. Sample XML File, where there 1585 are (i) three main video streams captured by three cameras, the 1586 central one capable of capturing a zoomed-out view of the overall 1587 telepresence room, (ii) a multi-content capture of the loudest 1588 segment of the room, and (iii) one audio capture for the audio of the 1589 whole room (Section 10.3). 1591 CP2 receives CP1's 'advertisement' message and, after processing it, 1592 sends back to CP1 a 'configure + ack' message where it declares to be 1593 interested only in the multi-content capture and in the audio capture 1594 (Section 10.4). 1596 CP1 answers to CP2's 'configure + ack' message with a 1597 'configureResponse' message including a response code '200 - Success' 1598 to accept all CP2's requests (Section 10.5). 1600 To reflect the changes in its telepresence offer, CP1 issues a new 1601 'advertisement' message to CP2 (Section 10.6), this time adding also 1602 a composed capture made by a big picture representing the current 1603 speaker and two picture-in-picture boxes representing the previous 1604 speakers (see more details about the telepresence description in 1605 [I-D.ietf-clue-data-model-schema], Sec. MCC example). 1607 CP2 acknowledges the second 'advertisement' message with an 'ack' 1608 message (Section 10.7). 1610 In a second moment, CP2 changes the requested media streams from CP1 1611 by sending to CP1 a 'configure' message replacing the previously 1612 selected video streams with the new composed media streams advertised 1613 by CP1 (Section 10.8). Media from the previous configuration 1614 continue to flow during the reconfiguration process. 1616 Finally, CP1 accept the last requests of CP2 with a 'confResponse' 1617 message (Section 10.9) 1619 We also remark that in the depicted flow three distinct sequence 1620 number spaces per sender are involved (two of which appear in the 1621 snippets since we only show one direction of media). The 1622 discontinuity between the sequence number values in Section 10.2 and 1623 Section 10.3 is hence correct. 1625 10.1. CLUE message nr. 1: 'options' 1626 1627 1634 CP1 1635 51 1636 true 1637 true 1638 1639 1.4 1640 2.7 1641 1642 1643 1644 E1 1645 URL_E1 1646 1.4 1647 1648 1649 E2 1650 URL_E2 1651 1.4 1652 1653 1654 E3 1655 URL_E3 1656 1.4 1657 1658 1659 E4 1660 URL_E4 1661 2.7 1662 1663 1664 E5 1665 URL_E5 1666 2.7 1667 1668 1669 1671 10.2. CLUE message nr. 2: 'optionsResponse' 1673 1674 1681 CP2 1682 62 1683 200 1684 Success 1685 true 1686 true 1687 2.7 1688 1690 10.3. CLUE message nr. 3: 'advertisement' 1692 1693 1700 CP1 1701 11 1702 1703 1707 CS1 1708 1709 1710 1711 0.0 1712 0.0 1713 10.0 1714 1715 1716 0.0 1717 1.0 1718 10.0 1719 1720 1721 1722 true 1723 EG1 1724 main audio from the room 1725 1726 1 1727 it 1728 static 1729 room 1730 1731 alice 1732 bob 1733 ciccio 1734 1735 1736 1739 CS1 1740 1741 1742 1743 -2.0 1744 0.0 1745 10.0 1746 1747 1748 1749 1750 -3.0 1751 20.0 1752 9.0 1753 1754 1755 -1.0 1756 20.0 1757 9.0 1758 1759 1760 -3.0 1761 20.0 1762 11.0 1763 1764 1765 -1.0 1766 20.0 1767 11.0 1768 1769 1770 1771 true 1772 EG0 1773 left camera video capture 1774 1775 1 1776 it 1777 static 1778 individual 1779 1780 ciccio 1781 1782 1783 1786 CS1 1787 1788 1789 1790 0.0 1791 0.0 1792 10.0 1793 1794 1795 1796 1797 -1.0 1798 20.0 1799 9.0 1800 1801 1802 1.0 1803 20.0 1804 9.0 1805 1806 1807 -1.0 1808 20.0 1809 11.0 1810 1811 1812 1.0 1813 20.0 1814 11.0 1815 1816 1817 1818 true 1819 EG0 1820 central camera video capture 1821 1822 1 1823 it 1824 static 1825 individual 1826 1827 alice 1828 1829 1830 1833 CS1 1834 1835 1836 1837 2.0 1838 0.0 1839 10.0 1840 1841 1842 1843 1844 1.0 1845 20.0 1846 9.0 1847 1848 1849 3.0 1850 20.0 1851 9.0 1852 1853 1854 1.0 1855 20.0 1856 11.0 1857 1858 1859 3.0 1860 20.0 1861 11.0 1862 1863 1864 1865 true 1866 EG0 1867 right camera video capture 1868 1869 1 1870 it 1871 static 1872 individual 1873 1874 bob 1875 1876 1877 1880 CS1 1881 1882 1883 1884 -3.0 1885 20.0 1886 9.0 1887 1888 1889 3.0 1890 20.0 1891 9.0 1892 1893 1894 -3.0 1895 20.0 1896 11.0 1897 1898 1899 3.0 1900 20.0 1901 11.0 1902 1903 1904 1905 1906 SE1 1907 1908 SoundLevel:0 1909 EG0 1910 loudest room segment 1911 2 1912 it 1913 static 1914 individual 1915 1916 1919 CS1 1920 1921 1922 1923 0.0 1924 0.0 1925 10.0 1926 1927 1928 1929 1930 -3.0 1931 20.0 1932 7.0 1933 1934 1935 3.0 1936 20.0 1937 7.0 1938 1939 1940 -3.0 1941 20.0 1942 13.0 1943 1944 1945 3.0 1946 20.0 1947 13.0 1948 1949 1950 1951 true 1952 EG0 1953 zoomed out view of all people in the 1954 room 1955 2 1956 it 1957 static 1958 room 1959 1960 alice 1961 bob 1962 ciccio 1963 1964 1965 1966 1967 1968 600000 1969 1970 ENC1 1971 ENC2 1972 ENC3 1973 1974 1975 1976 300000 1977 1978 ENC4 1979 ENC5 1980 1981 1982 1983 1984 1985 1986 1987 1988 VC0 1989 VC1 1990 VC2 1991 1992 1993 1994 1995 VC3 1996 1997 1998 1999 2000 VC4 2001 2002 2003 2004 2005 AC0 2006 2007 2008 2009 2010 2011 2012 2013 VC3 2014 SE1 2015 2016 2017 VC0 2018 VC2 2019 VC4 2020 2021 2022 2023 2024 2025 2026 Bob 2027 2028 2029 minute taker 2030 2031 2032 2033 2034 Alice 2035 2036 2037 presenter 2038 2039 2040 2041 2042 Ciccio 2043 2044 2045 chairman 2046 timekeeper 2047 2048 2049 2050 10.4. CLUE message nr. 4: 'configure + ack' 2052 2053 2060 CP2 2061 22 2062 11 2063 200 2064 2065 2066 AC0 2067 ENC4 2068 2069 2070 VC3 2071 ENC1 2072 2073 SE1 2074 2075 2076 2077 2079 10.5. CLUE message nr. 5: 'confResponse' 2080 2081 2088 CP1 2089 12 2090 200 2091 Success 2092 22 2093 2095 10.6. CLUE message nr. 6: 'advertisement' 2097 2098 2105 CP1 2106 13 2107 2108 2111 CS1 2112 2113 2114 2115 0.0 2116 0.0 2117 10.0 2118 2119 2120 0.0 2121 1.0 2122 10.0 2123 2124 2125 2126 true 2127 EG1 2128 main audio from the room 2129 2130 1 2131 it 2132 static 2133 room 2134 2135 alice 2136 bob 2137 ciccio 2138 2139 2140 2143 CS1 2144 2145 2146 2147 0.5 2148 1.0 2149 0.5 2150 2151 2152 0.5 2153 0.0 2154 0.5 2155 2156 2157 2158 true 2159 EG0 2160 left camera video capture 2161 2162 1 2163 it 2164 static 2165 individual 2166 2167 ciccio 2168 2169 2170 2173 CS1 2174 2175 2176 2177 0.0 2178 0.0 2179 10.0 2180 2181 2182 2183 2184 -1.0 2185 20.0 2186 9.0 2187 2188 2189 1.0 2190 20.0 2191 9.0 2192 2193 2194 -1.0 2195 20.0 2196 11.0 2197 2198 2199 1.0 2200 20.0 2201 11.0 2202 2203 2204 2205 true 2206 EG0 2207 central camera video capture 2208 2209 1 2210 it 2211 static 2212 individual 2213 2214 alice 2215 2216 2217 2220 CS1 2221 2222 2223 2224 2.0 2225 0.0 2226 10.0 2227 2228 2229 2230 2231 1.0 2232 20.0 2233 9.0 2234 2235 2236 3.0 2237 20.0 2238 9.0 2239 2240 2241 1.0 2242 20.0 2243 11.0 2244 2245 2246 3.0 2247 20.0 2248 11.0 2249 2250 2251 2252 true 2253 EG0 2254 right camera video capture 2255 2256 1 2257 it 2258 static 2259 individual 2260 2261 bob 2262 2263 2264 2267 CS1 2268 2269 2270 2271 -3.0 2272 20.0 2273 9.0 2274 2275 2276 3.0 2277 20.0 2278 9.0 2279 2280 2281 -3.0 2282 20.0 2283 11.0 2284 2285 2286 3.0 2287 20.0 2288 11.0 2289 2290 2291 2292 2293 SE1 2294 2295 SoundLevel:0 2296 EG0 2297 loudest room segment 2298 2 2299 it 2300 static 2301 individual 2302 2303 2306 CS1 2307 2308 2309 2310 0.0 2311 0.0 2312 10.0 2313 2314 2315 2316 2317 -3.0 2319 20.0 2320 7.0 2321 2322 2323 3.0 2324 20.0 2325 7.0 2326 2327 2328 -3.0 2329 20.0 2330 13.0 2331 2332 2333 3.0 2334 20.0 2335 13.0 2336 2337 2338 2339 true 2340 EG0 2341 2342 zoomed out view of all people in the room 2343 2344 2 2345 it 2346 static 2347 room 2348 2349 alice 2350 bob 2351 ciccio 2352 2353 2354 2357 CS1 2358 2359 2360 2361 -3.0 2362 20.0 2363 9.0 2364 2365 2366 3.0 2367 20.0 2368 9.0 2369 2370 2371 -3.0 2372 20.0 2373 11.0 2374 2375 2376 3.0 2377 20.0 2378 11.0 2379 2380 2381 2382 2383 SE1 2384 2385 SoundLevel:1 2386 penultimate loudest room segment 2387 2388 it 2389 static 2390 individual 2391 2392 2395 CS1 2396 2397 2398 2399 -3.0 2400 20.0 2401 9.0 2402 2403 2404 3.0 2405 20.0 2406 9.0 2407 2408 2409 -3.0 2410 20.0 2411 11.0 2412 2413 2414 3.0 2416 20.0 2417 11.0 2418 2419 2420 2421 2422 SE1 2423 2424 SoundLevel:2 2425 last but two loudest room segment 2426 2427 it 2428 static 2429 individual 2430 2431 2434 CS1 2435 2436 2437 2438 -3.0 2439 20.0 2440 9.0 2441 2442 2443 3.0 2444 20.0 2445 9.0 2446 2447 2448 -3.0 2449 20.0 2450 11.0 2451 2452 2453 3.0 2454 20.0 2455 11.0 2456 2457 2458 2459 2460 VC3 2461 VC5 2462 VC6 2463 2464 3 2465 EG0 2466 big picture of the current speaker + 2467 pips about previous speakers 2468 3 2469 it 2470 static 2471 individual 2472 2473 2474 2475 2476 600000 2477 2478 ENC1 2479 ENC2 2480 ENC3 2481 2482 2483 2484 300000 2485 2486 ENC4 2487 ENC5 2488 2489 2490 2491 2492 2493 2494 2495 participants' individual 2496 videos 2497 2498 VC0 2499 VC1 2500 VC2 2501 2502 2503 2504 loudest segment of the 2505 room 2506 2507 VC3 2508 2509 2510 2511 loudest segment of the 2512 room + pips 2513 2514 VC7 2515 2516 2517 2518 room audio 2519 2520 AC0 2521 2522 2523 2524 room video 2525 2526 VC4 2527 2528 2529 2530 2531 2532 2533 2534 VC3 2535 VC7 2536 SE1 2537 2538 2539 VC0 2540 VC2 2541 VC4 2542 2543 2544 2545 2546 2547 2548 Bob 2549 2550 2551 minute taker 2552 2553 2554 2555 2556 Alice 2557 2558 2559 presenter 2561 2562 2563 2564 2565 Ciccio 2566 2567 2568 chairman 2569 timekeeper 2570 2571 2572 2574 10.7. CLUE message nr. 7: 'ack' 2576 2577 2584 CP2 2585 23 2586 200 2587 Success 2588 13 2589 2591 10.8. CLUE message nr. 8: 'configure' 2592 2593 2600 CP2 2601 24 2602 13 2603 2604 2605 AC0 2606 ENC4 2607 2608 2609 VC7 2610 ENC1 2611 2612 SE5 2613 2614 2615 2616 2618 10.9. CLUE message nr. 9: 'confResponse' 2620 2621 2628 CP1 2629 14 2630 200 2631 Success 2632 24 2633 2635 11. Security Considerations 2637 As a general consideration, we remark that the CLUE framework (and 2638 related protocol) has been conceived at the outset by embracing the 2639 security-by-design paradigm. This entails that a number of 2640 requirements have been identified and properly standardized as 2641 mandatory within the entire set of documents associated with the CLUE 2642 architecture. Requirements include: (i) the use of cryptography and 2643 authentication; (ii) protection of all sensitive fields; (iii) mutual 2644 authentication between CLUE endpoints; (iv) the presence of 2645 authorization mechanisms; (v) the presence of native defence 2646 mechanisms against malicious activities such as eavesdropping, 2647 selective modification, deletion, replay (and related combinations 2648 thereof). Hence, security of the single components of the CLUE 2649 solution cannot be evaluated independently of the integrated view of 2650 the final architecture. 2652 The CLUE protocol is an application-level protocol allowing a Media 2653 Producer and a Media Consumer to negotiate a variegated set of 2654 parameters associated with the establishment of a telepresence 2655 session. This unavoidably exposes a CLUE-enabled telepresence system 2656 to a number of potential threats, most of which are extensively 2657 discussed in the framework document [I-D.ietf-clue-framework]. The 2658 security considerations section of the mentioned document actually 2659 discusses issues associated with the setup and management of a 2660 telepresence session both in the basic case involving two CLUE 2661 endpoints acting, respectively, as MP and MC, and in the more 2662 advanced scenario envisaging the presence of an MCU. 2664 The framework document also mentions that the information carried 2665 within CLUE protocol messages might contain sensitive data, which 2666 SHOULD hence be accessed only by authenticated endpoints. Security 2667 issues associated with the CLUE data model schema are discussed in 2668 [I-D.ietf-clue-data-model-schema]. 2670 There is extra information carried by the CLUE protocol that is not 2671 associated with the CLUE data model schema and which exposes 2672 information that might be of concern. This information is primarily 2673 exchanged during the negotiation phase via the 'options' and 2674 'optionsResponse' messages. In the CLUE Participant state machine 2675 OPTIONS state, both parties agree on the version and on the 2676 extensions to be used in the subsequent CLUE messages exchange phase. 2677 A malicious participant might either try to retrieve a detailed 2678 footprint of a specific CLUE protocol implementation during this 2679 initial setup phase, or force the communicating party to use a non- 2680 up-to-date version of the protocol which they know how to break. 2681 Indeed, exposing all of the supported versions and extensions could 2682 conceivably leak information about the specific implementation of the 2683 protocol. In theory an implementation could choose not to announce 2684 all of the versions it supports if it wants to avoid such leakage, 2685 though at the expenses of interoperability. With respect to the 2686 above considerations, it is noted that the OPTIONS state is only 2687 reached after the CLUE data channel has been successfully set up. 2688 This ensures that only authenticated parties can exchange 'options' 2689 and related 'optionsResponse' messages and hence drastically reduces 2690 the attack surface that is exposed to malicious parties. 2692 The CLUE framework clearly states the requirement to protect CLUE 2693 protocol messages against threats deriving from the presence of a 2694 malicious agent capable to gain access to the CLUE data channel. 2695 Such a requirement is met by the CLUE data channel solution described 2696 in [I-D.ietf-clue-datachannel], which ensures protection from both 2697 message recovery and message tampering. With respect to this last 2698 point, any implementation of the CLUE protocol compliant with the 2699 CLUE specification MUST rely on the exchange of messages that flow on 2700 top of a reliable and ordered SCTP over DTLS transport channel 2701 connecting two CLUE Participants. 2703 12. IANA Considerations 2705 This document registers a new XML namespace, a new XML schema and the 2706 MIME type for the schema. This document also registers the "CLUE" 2707 Application Service tag and the "CLUE" Application Protocol tag and 2708 defines registries for the CLUE messages and response codes. 2710 12.1. URN Sub-Namespace Registration 2712 This section registers a new XML namespace, 2713 ""urn:ietf:params:xml:ns:clue-protocol"". 2715 URI: urn:ietf:params:xml:ns:clue-protocol 2717 Registrant Contact: IESG (iesg@ietf.org). 2719 XML: 2721 BEGIN 2722 2723 2725 2726 2727 CLUE Messages 2728 2729 2730

Namespace for CLUE Messages

2731

urn:ietf:params:xml:ns:clue-protocol

2732 [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX 2733 with the RFC number for this specification.]] 2734

See 2735 RFCXXXX.

2736 2737 2738 END 2740 12.2. XML Schema registration 2742 This section registers an XML schema per the guidelines in [RFC3688]. 2744 URI: urn:ietf:params:xml:schema:clue-protocol 2746 Registrant Contact: IESG (iesg@ietf.org). 2748 Schema: The XML for this schema can be found as the entirety of 2749 Section 9 of this document. 2751 12.3. MIME Media Type Registration for 'application/clue+xml' 2753 This section registers the ""application/clue+xml"" MIME type. 2755 To: ietf-types@iana.org 2757 Subject: Registration of MIME media type application/clue+xml 2759 MIME media type name: application 2761 MIME subtype name: clue+xml 2763 Required parameters: (none) 2765 Optional parameters: charset 2766 Same as the charset parameter of "application/xml" as specified in 2767 [RFC7303], Section 3.2. 2769 Encoding considerations: Same as the encoding considerations of 2770 "application/xml" as specified in [RFC7303], Section 3.2. 2772 Security considerations: This content type is designed to carry 2773 protocol data related to telepresence session control. Some of the 2774 data could be considered private. This media type does not provide 2775 any protection and thus other mechanisms such as those described in 2776 Section Security are required to protect the data. This media type 2777 does not contain executable content. 2779 Interoperability considerations: None. 2781 Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please 2782 replace XXXX with the RFC number for this specification.]] 2784 Applications that use this media type: CLUE participants. 2786 Additional Information: Magic Number(s): (none), 2787 File extension(s): .xml, 2788 Macintosh File Type Code(s): TEXT. 2790 Person & email address to contact for further information: Simon 2791 Pietro Romano (spromano@unina.it). 2793 Intended usage: LIMITED USE 2795 Author/Change controller: The IETF 2797 Other information: This media type is a specialization of 2798 application/xml [RFC7303], and many of the considerations described 2799 there also apply to application/clue+xml. 2801 12.4. CLUE Protocol Registry 2803 The document requests that the IANA creates new registries for CLUE 2804 messages and response codes. 2806 12.4.1. CLUE Message Types 2808 The following summarizes the registry for CLUE messages: 2810 Related Registry: CLUE Message Types Registry 2812 Defining RFC: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace XXXX 2813 with the RFC number for this specification.]] 2814 Registration/Assignment Procedures: Following the policies outlined 2815 in [RFC8126], the IANA policy for assigning new values for the CLUE 2816 message types for the CLUE protocol is Specification Required. 2818 Registrant Contact: IESG (iesg@ietf.org). 2820 The initial Message table is populated using the CLUE messages 2821 described in Section 5 and defined in the XML schema in Section 9. 2823 +-------------------+-----------------------------------+-----------+ 2824 | Message | Description | Reference | 2825 +-------------------+-----------------------------------+-----------+ 2826 | options | Sent by the CI to the CR in the | RFCXXXX | 2827 | | initiation phase to specify the | | 2828 | | roles played by the CI, the | | 2829 | | supported versions and the | | 2830 | | supported extensions. | | 2831 | optionsResponse | Sent by the CI to the CR in reply | RFCXXXX | 2832 | | to an 'options' message to | | 2833 | | finally estabilsh the version and | | 2834 | | the extensions to be used in the | | 2835 | | following CLUE messages exchange. | | 2836 | advertisement | Sent by the MP to the MC to | RFCXXXX | 2837 | | specify the telepresence | | 2838 | | capabilities of the MP expressed | | 2839 | | according to the CLUE framework. | | 2840 | ack | Sent by the MC to the MP to | RFCXXXX | 2841 | | acknowledge the reception of an | | 2842 | | 'advertisement' message. | | 2843 | configure | Sent by the MC to the MP to | RFCXXXX | 2844 | | specify the desired media | | 2845 | | captures among those specified in | | 2846 | | the 'advertisement'. | | 2847 | configureResponse | Sent by the MP to the MC in reply | RFCXXXX | 2848 | | to a CONFIGURE message to | | 2849 | | communicate if the configuration | | 2850 | | request has been successfully | | 2851 | | processed or not. | | 2852 +-------------------+-----------------------------------+-----------+ 2854 IANA-CLUE 2856 12.4.2. CLUE Response Codes 2858 The following summarizes the requested registry for CLUE response 2859 codes: 2861 Related Registry: CLUE Response Code Registry 2862 Defining RFC: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace XXXX 2863 with the RFC number for this specification.]] 2865 Registration/Assignment Procedures: Following the policies outlined 2866 in [RFC8126], the IANA policy for assigning new values for the 2867 Response codes for CLUE shall be Specification Required. 2869 Registrant Contact: IESG (iesg@ietf.org). 2871 The initial Response-code table is populated using the Response codes 2872 defined in Section 5.7 as follows: 2874 +--------+---------------+------------------------------+-----------+ 2875 | Number | Default | Description | Reference | 2876 | | Response | | | 2877 | | String | | | 2878 +--------+---------------+------------------------------+-----------+ 2879 | 200 | Success | The request has been | RFCXXXX | 2880 | | | successfully processed. | | 2881 | 300 | Low-level | A generic low-level request | RFCXXXX | 2882 | | request | error has occurred. | | 2883 | | error. | | | 2884 | 301 | Bad syntax | The XML syntax of the | RFCXXXX | 2885 | | | message is not correct. | | 2886 | 302 | Invalid value | The message contains an | RFCXXXX | 2887 | | | invalid parameter value. | | 2888 | 303 | Conficting | The message contains values | RFCXXXX | 2889 | | values | that cannot be used | | 2890 | | | together. | | 2891 | 400 | Semantic | Semantic errors in the | RFCXXXX | 2892 | | errors | received CLUE protocol | | 2893 | | | message. | | 2894 | 401 | Version not | The protocol version used in | RFCXXXX | 2895 | | supported | the message is not | | 2896 | | | supported. | | 2897 | 402 | Invalid | Sequence number gap; | RFCXXXX | 2898 | | sequencing | repeated sequence number; | | 2899 | | | sequence number outdated. | | 2900 | 403 | Invalid | The clueId used in the | RFCXXXX | 2901 | | identifier | message is not valid or | | 2902 | | | unknown. | | 2903 | 404 | advertisement | The sequence number of the | RFCXXXX | 2904 | | Expired | advertisement the configure | | 2905 | | | refers to is out of date. | | 2906 | 405 | Subset choice | The subset choice is not | RFCXXXX | 2907 | | not allowed | allowed for the specified | | 2908 | | | Multiple Content Capture. | | 2909 +--------+---------------+------------------------------+-----------+ 2911 13. Acknowledgments 2913 The authors thank all the CLUErs for their precious feedbacks and 2914 support, in particular Paul Kyzivat, Christian Groves and Scarlett 2915 Liuyan. 2917 14. References 2919 14.1. Normative References 2921 [I-D.ietf-clue-data-model-schema] 2922 Presta, R. and S. Romano, "An XML Schema for the CLUE data 2923 model", draft-ietf-clue-data-model-schema-17 (work in 2924 progress), August 2016. 2926 [I-D.ietf-clue-datachannel] 2927 Holmberg, C., "CLUE Protocol data channel", draft-ietf- 2928 clue-datachannel-18 (work in progress), April 2019. 2930 [I-D.ietf-clue-framework] 2931 Duckworth, M., Pepperell, A., and S. Wenger, "Framework 2932 for Telepresence Multi-Streams", draft-ietf-clue- 2933 framework-25 (work in progress), January 2016. 2935 [I-D.ietf-clue-signaling] 2936 Hansen, R., Kyzivat, P., Xiao, L., and C. Groves, "Session 2937 Signaling for Controlling Multiple Streams for 2938 Telepresence (CLUE)", draft-ietf-clue-signaling-14 (work 2939 in progress), October 2018. 2941 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2942 Requirement Levels", BCP 14, RFC 2119, 2943 DOI 10.17487/RFC2119, March 1997, 2944 . 2946 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2947 Jacobson, "RTP: A Transport Protocol for Real-Time 2948 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 2949 July 2003, . 2951 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2952 DOI 10.17487/RFC3688, January 2004, 2953 . 2955 [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, 2956 DOI 10.17487/RFC7303, July 2014, 2957 . 2959 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 2960 Writing an IANA Considerations Section in RFCs", BCP 26, 2961 RFC 8126, DOI 10.17487/RFC8126, June 2017, 2962 . 2964 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2965 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2966 May 2017, . 2968 14.2. Informative References 2970 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 2971 Communication Layers", STD 3, RFC 1122, 2972 DOI 10.17487/RFC1122, October 1989, 2973 . 2975 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2976 A., Peterson, J., Sparks, R., Handley, M., and E. 2977 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2978 DOI 10.17487/RFC3261, June 2002, 2979 . 2981 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 2982 Session Initiation Protocol (SIP)", RFC 4353, 2983 DOI 10.17487/RFC4353, February 2006, 2984 . 2986 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 2987 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 2988 March 2011, . 2990 [RFC7262] Romanow, A., Botzko, S., and M. Barnes, "Requirements for 2991 Telepresence Multistreams", RFC 7262, 2992 DOI 10.17487/RFC7262, June 2014, 2993 . 2995 [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, 2996 DOI 10.17487/RFC7667, November 2015, 2997 . 2999 Authors' Addresses 3000 Roberta Presta 3001 University of Napoli 3002 Via Claudio 21 3003 Napoli 80125 3004 Italy 3006 EMail: roberta.presta@unina.it 3008 Simon Pietro Romano 3009 University of Napoli 3010 Via Claudio 21 3011 Napoli 80125 3012 Italy 3014 EMail: spromano@unina.it