idnits 2.17.1 draft-presta-clue-protocol-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 142 instances of too long lines in the document, the longest one being 60 characters in excess of 72. ** The abstract seems to contain references ([I-D.kyzivat-clue-signaling], [I-D.ietf-clue-framework], [I-D.ietf-clue-telepresence-requirements]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 833: '... aspect MUST be explicitly advertise...' RFC 2119 keyword, line 874: '...om unknown namespaces MUST be ignored....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 657 has weird spacing: '...receive sen...' == Line 769 has weird spacing: '...receive rece...' -- The document date (November 5, 2013) is 3824 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: 'TBC' is mentioned on line 940, but not defined == Outdated reference: A later version (-17) exists of draft-ietf-clue-data-model-schema-00 == Outdated reference: A later version (-25) exists of draft-ietf-clue-framework-12 == Outdated reference: A later version (-07) exists of draft-ietf-clue-telepresence-requirements-06 == Outdated reference: A later version (-08) exists of draft-kyzivat-clue-signaling-05 -- Obsolete informational reference (is this intentional?): RFC 5117 (Obsoleted by RFC 7667) Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CLUE Working Group R. Presta 3 Internet-Draft S P. Romano 4 Intended status: Standards Track University of Napoli 5 Expires: May 9, 2014 November 5, 2013 7 CLUE protocol 8 draft-presta-clue-protocol-03 10 Abstract 12 The CLUE protocol is an application protocol conceived for the 13 description and negotiation of a CLUE telepresence session. The 14 design of the CLUE protocol takes into account the requirements and 15 the framework defined, respectively, in [I-D.ietf-clue-framework] and 16 [I-D.ietf-clue-telepresence-requirements]. The companion document 17 [I-D.kyzivat-clue-signaling] delves into CLUE signaling details, as 18 well as into the SIP/SDP session establishment phase. We herein 19 focus on the application level perspective. Message details, 20 together with the behavior of CLUE participants acting as Media 21 Providers and/or Media Consumers, are 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 9, 2014. 40 Copyright Notice 42 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Overview of the CLUE protocol . . . . . . . . . . . . . . . . 4 60 3.1. ADVERTISEMENT . . . . . . . . . . . . . . . . . . . . . . 7 61 3.2. CONFIGURE . . . . . . . . . . . . . . . . . . . . . . . . 8 62 3.3. RESPONSE . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 3.4. RE-ADV . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 3.5. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 4. Protocol state machines . . . . . . . . . . . . . . . . . . . 12 66 5. CLUE Participant state machine . . . . . . . . . . . . . . . . 13 67 6. Media Consumer's state machine . . . . . . . . . . . . . . . . 15 68 7. Media Provider's state machine . . . . . . . . . . . . . . . . 17 69 8. About CLUE protocol XML schema versioning . . . . . . . . . . 19 70 9. Extensibility issues . . . . . . . . . . . . . . . . . . . . . 20 71 9.1. Aspect 1 - new information within existing messages . . . 20 72 9.2. Aspect 2 - new messages . . . . . . . . . . . . . . . . . 21 73 10. Managing protocol version negotiation and extensions: the 74 OPTIONS request . . . . . . . . . . . . . . . . . . . . . . . 22 75 10.1. An example using OPTIONS . . . . . . . . . . . . . . . . . 24 76 11. XML Schema of CLUE protocol messages . . . . . . . . . . . . . 25 77 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 78 13. Handling channel errors . . . . . . . . . . . . . . . . . . . 29 79 14. Diff with the -02 version . . . . . . . . . . . . . . . . . . 29 80 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 81 16. Informative References . . . . . . . . . . . . . . . . . . . . 29 83 1. Introduction 85 The CLUE protocol is an application protocol used by two CLUE 86 Participants to enhance the experience of a multimedia telepresence 87 session. The main goals of the CLUE protocol are: 89 1. enabling a MP to advertise its current telepresence capabilities 90 to the MC in terms of available media captures, encodings, and 91 simultaneity constraints; 93 2. enabling a MC to request the desired multimedia streams from the 94 offering MP. 96 CLUE Participants are connected by means of the CLUE signaling 97 channel. Such channel has been conceived as a DTLS/SCTP/UDP channel 98 in [I-D.kyzivat-clue-signaling] and it is established as depicted in 99 the same document. CLUE protocol messages flow across such channel. 101 While [I-D.kyzivat-clue-signaling] focuses on protocol signaling 102 details and on its interaction with the SIP/SDP session establishment 103 phase, we herein investigate the protocol in action. We assume the 104 DTLS/SCTP/UDP channel is established and define the behiavior of the 105 CLUE Participants communicating on it. We discuss how the CLUE 106 dialogue between them can be exploited to successfully setup the 107 telepresence session according to the principles and concepts pointed 108 out in in [I-D.ietf-clue-framework]. 110 In Section 3 we provide an overview of the CLUE protocol and describe 111 CLUE messages along with their features and functionality. The CLUE 112 participant state machine is introduced in Section 4. Versioning, 113 extensions and options management mechanisms are discussed in 114 Section 8, Section 9 and Section 10, respectively. The XML schema 115 defining the CLUE messages is reported in Section 11. 117 2. Terminology 119 This document refers to the same terminology used in 120 [I-D.ietf-clue-framework] and in 121 [I-D.ietf-clue-telepresence-requirements]. We briefly recall herein 122 some of the main terms used in the document. We further introduce 123 the definition of CLUE participant. 125 CLUE Participant An entity able to use the CLUE protocol within a 126 telepresence session. It can be either an endpoint or an MCU able 127 to use the CLUE protocol. 129 Endpoint The logical point of final termination through receiving, 130 decoding and rendering, and/or initiation through capturing, 131 encoding, and sending of media streams. An endpoint consists of 132 one or more physical devices which source and sink media streams, 133 and exactly one [RFC4353] Participant (which, in turn, includes 134 exactly one SIP User Agent). Endpoints can be anything from 135 multiscreen/multicamera room controllers to handheld devices. 137 MCU Multipoint Control Unit (MCU) - a device that connects two or 138 more endpoints together into one single multimedia conference 139 [RFC5117]. An MCU may include a Mixer [RFC4353]. 141 Media Any data that, after suitable encoding, can be conveyed over 142 RTP, including audio, video or timed text. 144 Media Capture A "Media Capture", or simply "Capture", is a source of 145 Media. 147 Capture Encoding A specific encoding of a Media Capture, to be sent 148 via RTP [RFC3550]. 150 Media Stream The term "Media Stream", or simply "Stream", is used as 151 a synonymous of Capture Encoding. 153 Media Provider A CLUE participant (i.e., an Endpoint or an MCU) 154 capable to send Media Streams. 156 Media Consumer A CLUE participant (i.e., an Endpoint or an MCU) 157 capable to receive Media Streams. 159 3. Overview of the CLUE protocol 161 The CLUE protocol has been conceived to enable telepresence sessions. 162 It is designed in order to address SDP limitations in terms of the 163 description of several qualitative parameters about the multimedia 164 streams that are involved in a real-time multimedia conference 165 session. Indeed, by simply using SDP we are not able to convey all 166 the information about the features of the flowing multimedia streams 167 that is needed to enable a "being there" rendering experience. Such 168 information is being designed in the CLUE framework draft and 169 formally defined and described in the CLUE data model draft. The 170 CLUE protocol represents the mechanism that enables the exchange of 171 CLUE information between CLUE participants. 173 The CLUE protocol, as defined in this document, is a stateful, 174 client-server, XML-based application protocol. CLUE protocol 175 messages flow on a DTLS/SCTP/UDP channel connecting two CLUE 176 Participants. The main goals of the CLUE protocol are: 178 1. enabling a MP to advertise its current telepresence capabilities 179 to the MC in terms of available media captures, encodings, and 180 simultaneity constraints; 182 2. enabling a MC to request the desired multimedia streams from the 183 offering MP. 185 Three main design layers can be identified: 187 1. Establishment of the CLUE channel. 189 2. Negotiation of the CLUE protocol version and extensions 191 3. Media session description and negotiation 193 Signaling issues about the CLUE channel establishment are considered 194 in [I-D.kyzivat-clue-signaling]. In particular, the CLUE channel is 195 a DTLS/SCTP/UDP channel connecting two CLUE Participants. While 196 [I-D.kyzivat-clue-signaling] focuses on protocol signaling details 197 and on its interaction with the SIP/SDP session establishment phase, 198 we herein investigate the protocol in action at the CLUE application 199 level. 201 As soon as the channel is ready, the CLUE Participants must agree on 202 the protocol version and extensions to be used within the 203 telepresence session. A mechanism for the negotiation of the CLUE 204 protocol version and extensions is proposed in Section 10. According 205 to such solution, the CP which is the CLUE Channel Initiator (CI) 206 issues a proper CLUE message (OPTIONS) to the CP which is the Channel 207 Receiver (CR). Such a message specifies the supported version and 208 extensions. The CR answers by selecting the subset of the CI's 209 extensions that it is able to support and determines the protocol 210 version to be used. 212 After that negotiation phase is completed, CLUE Participants define 213 the characteristics of the media streams to be exchanged in both 214 directions. Indeed, being A and B the considered CLUE Participants, 215 it is possible to distinguish between two dialogues: 217 1. the one needed to describe and set up the media streams sent from 218 A to B, i.e., the dialogue between A's Media Provider side and 219 B's Media Consumer side 221 2. the one needed to describe and set up the media streams sent from 222 B to A, i.e., the dialogue between B's Media Provider side and 223 A's Media Consumer side 225 CLUE messages for the media session description and negotiation are 226 designed by considering the MP side as the server side of the 227 protocol, since it produces and provides media streams, and the MC 228 side as the client side of the protocol, since it requests and 229 receives media streams. The messages that are exchanged to set up 230 the telepresence media session are described by focusing on a single 231 MP-MC dialogue. 233 The MP first advertises the media captures and associated encodings 234 to the MC, as well as possible simultaneity constraints. The 235 description of such telepresence features is made according to the 236 information defined in the CLUE framework and data model 237 ([I-D.ietf-clue-framework] and [I-D.ietf-clue-data-model-schema]). 238 The CLUE message conveing the MP's multimedia offer is the 239 ADVERTISEMENT message. Such message leverages the XML definitions 240 provided in [I-D.ietf-clue-data-model-schema] for the description of 241 media captures, encodings, and simultaneity constraints features. 243 The MC selects the desired streams coming from the MP by using the 244 CONFIGURE message, which makes reference to the information carried 245 in the ADVERTISEMENT previously received by the MP. 247 In the following, a bird's-eye view of the CLUE protocol messages is 248 provided. For each message it is indicated who sends it, who 249 receives it, a brief description of the information it carries, and 250 how/when it is used. Besides ADVERTISEMENT and CONFIGURE, new 251 messages have been conceived in order to provide all the mechanisms 252 and operations envisaged in [I-D.kyzivat-clue-signaling]. 254 o ADVERTISEMENT (ADV) 256 o ACKNOWLEDGEMENT (ACK) 258 o CONFIGURE (CONF) 260 o CONFIGURE RESPONSE 262 o RE-ADV 264 o RE-ADV RESPONSE 266 o OPTIONS 268 o OPTIONS RESPONSE 270 3.1. ADVERTISEMENT 272 +---------- ---+-----------------------------------------------------+ 273 | | | 274 | FROM | MP | 275 | | | 276 +--------------+-----------------------------------------------------+ 277 | | | 278 | TO | MC | 279 | | | 280 +--------------+-----------------------------------------------------+ 281 | | | 282 | TYPE | Notification | 283 | | | 284 +--------------+-----------------------------------------------------+ 285 | | | 286 | DESCRIPTION | This message is used by the MP to advertise the | 287 | | available media captures and related information | 288 | | to the MC. | 289 | | The ADV contains elements compliant with the | 290 | | CLUE data model and other information like the | 291 | | CLUE protocol version and a sequence number. | 292 | | | 293 +--------------+-----------------------------------------------------+ 294 | | | 295 | USAGE | The MP sends this message as soon as the | 296 | | CLUE channel is ready. The MP sends an ADV to the | 297 | | MC each time there is a modification of the MP's | 298 | | telepresence capabilities. | 299 | | The ADV message is also sent back to the MC | 300 | | when the MP receives a RE-ADV request. | 301 +--------------+-----------------------------------------------------+ 303 The ADV message is considered a notification since, during the 304 session, it can be sent from the MP also on a per-event basis, i.e. 305 when the CLUE capabilities of the MP change with respect to the last 306 issued ADV. It is still to be discussed if a "delta" mechanism for 307 advertising only the changes with respect to the previous 308 notification should be adopted. Similar approaches have been 309 proposed for partial notifications in centralized conferencing 310 frameworks ([RFC6502]), leveraging the XML diff codification 311 mechanism defined in [RFC5261]. 313 3.2. CONFIGURE 315 +--------------+-----------------------------------------------------+ 316 | | | 317 | FROM | MC | 318 | | | 319 +--------------+-----------------------------------------------------+ 320 | | | 321 | TO | MP | 322 | | | 323 +--------------+-----------------------------------------------------+ 324 | | | 325 | TYPE | Request | 326 | | | 327 +--------------+-----------------------------------------------------+ 328 | | | 329 | DESCRIPTION | This message allows a MC to ask for the | 330 | | desired (advertised) capture. It contains capture | 331 | | encodings and other information like the CLUE | 332 | | protocol version and a sequence number. | 333 | | | 334 +--------------+-----------------------------------------------------+ 335 | | | 336 | USAGE | The MC can send a CONF after the reception of | 337 | | an ADV or each time it wants to request other | 338 | | advertised captures from the MP. | 339 +--------------+-----------------------------------------------------+ 341 3.3. RESPONSE 342 +--------------+-----------------------------------------------------+ 343 | | | 344 | FROM | MP | 345 | | | 346 +--------------+-----------------------------------------------------+ 347 | | | 348 | TO | MC | 349 | | | 350 +--------------+-----------------------------------------------------+ 351 | | | 352 | TYPE | Response | 353 | | | 354 +--------------+-----------------------------------------------------+ 355 | | | 356 | DESCRIPTION | This message allows a MP to answer a CONF | 357 | | message. Besides the protocol version and a | 358 | | sequence number, it contains a response code with | 359 | | a response string indicating either the success | 360 | | or the failure (along with failure details) of | 361 | | a CONF request elaboration. Example response | 362 | | codes and strings are provided in the following | 363 | | table. | 364 | | | 365 +--------------+-----------------------------------------------------+ 366 | | | 367 | USAGE | The MP sends this message in response to a CONF | 368 | | message. | 369 +--------------+-----------------------------------------------------+ 371 Response codes can be designed by adhering to the HTTP semantics, as 372 shown below. 374 +-----------------+----------------------+--------------------------+ 375 | | | | 376 | Response code | Response string | Description | 377 | | | | 378 +-----------------+----------------------+--------------------------+ 379 | | | | 380 | 410 | Bad syntax | The XML syntax of the | 381 | | | CONF message is not | 382 | | | correct. | 383 +-----------------+----------------------+--------------------------+ 384 | | | | 385 | 411 | Invalid value | The CONF message | 386 | | | contains an invalid | 387 | | | parameter value. | 388 +-----------------+----------------------+--------------------------+ 389 | | | | 390 | 412 | Invalid identifier | The identifier used for | 391 | | | requesting a capture is | 392 | | | not valid or unknown. | 393 +-----------------+----------------------+--------------------------+ 394 | | | | 395 | 413 | Conflicting values | The CONF message | 396 | | | contains values that | 397 | | | cannot be used together.| 398 +-----------------+----------------------+--------------------------+ 399 | | | | 400 | 420 | Invalid sequencing | The sequence number of | 401 | | | the CONF message is out | 402 | | | of date or corresponds | 403 | | | to an obsoleted ADV. | 404 +-----------------+----------------------+--------------------------+ 405 | | | | 406 | 510 | Version not supported| The CLUE protocol | 407 | | | version of the CONF | 408 | | | message is not supported| 409 | | | by the MP. | 410 +-----------------+----------------------+--------------------------+ 411 | | | | 412 | 511 | Option not supported | The option requested in | 413 | | | the CONF message is not | 414 | | | supported by the MP. | 415 +-----------------+----------------------+--------------------------+ 417 ... TBC. 419 +---------------+------------------------+ 420 | | | 421 | Response code | Description | 422 | family | | 423 +---------------+------------------------+ 424 | | | 425 | 1XX | Temporary info | 426 | | | 427 +---------------+------------------------+ 428 | | | 429 | 2XX | Success | 430 | | | 431 +---------------+------------------------+ 432 | | | 433 | 3XX | Redirection | 434 | | | 435 +---------------+------------------------+ 436 | | | 437 | 4XX | Client error | 438 | | | 439 +---------------+------------------------+ 440 | | | 441 | 5XX | Server error | 442 | | | 443 +---------------+------------------------+ 445 3.4. RE-ADV 446 +---------- ---+-----------------------------------------------------+ 447 | | | 448 | FROM | MC | 449 | | | 450 +--------------+-----------------------------------------------------+ 451 | | | 452 | TO | MP | 453 | | | 454 +--------------+-----------------------------------------------------+ 455 | | | 456 | TYPE | Request | 457 | | | 458 +--------------+-----------------------------------------------------+ 459 | | | 460 | DESCRIPTION | This message allows a MC to request a MP to | 461 | | issue a new copy of the ADV. This message can | 462 | | contain a reason string indicating the motivation | 463 | | for the request (e.g., refresh, missing elements | 464 | | in the received ADV, wrong syntax in the received | 465 | | ADV, invalid capture area, invalid line of | 466 | | capture point, etc). | 467 | | | 468 +--------------+-----------------------------------------------------+ 469 | | | 470 | USAGE | The MC sends this message to the MP when the | 471 | | timeout for the ADV is fired, or when the ADV is | 472 | | not compliant with the CLUE specifications (this | 473 | | can be useful for interoperability testing | 474 | | purposes) | 475 | | | 476 +--------------+-----------------------------------------------------+ 478 3.5. OPTIONS 480 ToDo. See Section 10. 482 4. Protocol state machines 484 The CLUE protocol is an application protocol used between a Media 485 Provider (MP) and a Media Consumer (MC) in order to establish a 486 multimedia telepresence session. CLUE protocol messages flow upon a 487 DTLS/SCTP channel established as depicted in 488 [I-D.kyzivat-clue-signaling]. Over such a channel there are 489 typically two CLUE streams between the channel terminations flowing 490 in opposite directions. In other words, typically, both channel 491 terminations act simultaneously as a MP and as a MC. We herein 492 discuss the state machines associated, respectively, with the CLUE 493 Participant, with the MC process and with the MP process. 495 5. CLUE Participant state machine 497 The main state machines focus on describing the states of CLUE 498 channel from a CLUE channel initiator/receiver perspective. In the 499 IDLE state, when the CP has established a CLUE channel, the main 500 state moves to the ESTABLISHED state. When in the ESTABLISHED state, 501 if the CP is the Channel Initiator (CI), it sends an OPTIONS message 502 for version negotiation; otherwise, if the CP is the Channel Receiver 503 (CR), it listens to the channel for an OPTIONS message associated 504 with version negotiation. If an OPTIONS message is sent (or 505 received), the CP moves to the NEGOTIATING state. If the CP detects 506 errors in the request message received, the main state goes back to 507 the IDLE state. When in the NEGOTIATING state, the CR prepares an 508 OPTIONS response message while the CI listens to the channel for an 509 OPTIONS response. If an OPTIONS response message for version 510 negotiation is sent (or received), the main state moves to the ACTIVE 511 state. If the CP detects errors in the response message received or 512 receives an error response, it goes back to the IDLE state. When the 513 party enters the ACTIVE state, it creates two sub state machines: the 514 MC state machine and the MP state machine. When in the ACTIVE state, 515 if the CP receives an OPTIONS message for version negotiation (or an 516 OPTIONS response message for version negotiation), it must ignore the 517 message and stay in the ACTIVE state. When in the ACTIVE state, a CP 518 which receives CLUE messages (including ADV, RE-ADV and CONF, as well 519 as the corresponding response messages) dispatches them to the proper 520 underlying sub state machine for further processing. The same 521 happens in case of changes in the telepresence settings. The 522 TERMINATED state is reachable from each of the aforementioned states 523 whenever the session is canceled or released. The IDLE state is 524 reachable from each of the aforementioned states whenever the 525 underlying channel is closed (only due to connection errors). 527 +-------------+<------------------------------+-------------+ 528 +----------->+ IDLE +<--------------------------+ + TIME OUT + 529 | +------+------+<-----------+ | +------+------+ 530 | | | | | 531 | | | | | 532 Connection CLUE | | | 533 error channel | | | 534 | has been established | | | 535 | | | | | 536 | V Receive error | | 537 +------------+-------------+ (version mismatch, | | 538 +------------------+ ESTABLISHED + missing elements,..) | time out 539 | +------+------+ | | | 540 | | | Connection | 541 | | | error | 542 | Send/Receive request | | | 543 | Version negotiation | | | 544 | | | | | 545 | V | | | 546 | +-------------+------------+ | | 547 | +------------+ NEGOTIATING +---------------------------+ | 548 | | +------+------+---------------------------|----------+ 549 | | | | 550 | | | | 551 | | Receive/Send response Connection 552 | | Version negotiation error 553 Session | | | 554 end | V | 555 | | +-------------+---------------------------+ 556 | | | ACTIVE +<-------------------+ 557 | | | +-------+ | Receive(request/response) 558 | | | |SUBIDLE| | Version negotiation 559 | Session | |MC | +--------------------+ 560 | end | +-------+ | 561 | | | +-------+ +<-------------------+ 562 | | | |SUBIDLE| | Send/Receive(ADV/CONF/RE-ADV/RESP) 563 | | | |MP | | Change telepresence settings 564 | | | +-------+ | | 565 | | +------+------+--------------------+ 566 | | | 567 | | | 568 | | Session 569 | | end 570 | | | 571 | | V 572 | | +-------------+ 573 | +----------->+ TERMINATED + 574 +----------------->+-------------+ 576 6. Media Consumer's state machine 578 An MC in the WAIT FOR ADV state is waiting for an ADV coming from the 579 MP. If the timeout expires ("timeout"), the MC switches to the 580 TIMEOUT state. 582 In the TIMEOUT state, if the number of trials is below the retry 583 threshold, the MC sends a RE-ADV/refresh message to the MP ("send RE- 584 ADV"), switching back to the WAIT FOR ADV. Otherwise, the MC moves 585 to the TERMINATED state. 587 When the ADV has been received ("receive ADV"), the MC goes into the 588 ADV RECEIVED state. The ADV is then parsed. If something goes wrong 589 with the ADV (bad syntax, missing XML elements, etc.), the MC sends a 590 NACK message to the MP specifying the encountered problem via a 591 proper reason phrase. In this way, the MC switches back to the WAIT 592 FOR ADV state, waiting for a new copy of the ADV. If the ADV is 593 successfully processed, the MC issues an ACK message to the MP and 594 moves to the ADV ACKED state. When the CONF request is ready, the MC 595 sends it and moves to the TRYING state. Alternatively, if the ADV is 596 successfully processed, and the CONF request is timely available, the 597 MC can piggyback the ACK message within a CONF request and move from 598 the ADV RECEIVED state directly to the TRYING state. 600 While in the TRYING state, the MC is waiting for a CONF RESPONSE 601 message (to the issued CONF) from the MP. If the timeout expires 602 ("timeout"), the MC moves to the TIMEOUT state and sends a RE-ADV in 603 order to solicit a new ADV from the MP. If a CONF RESPONSE with an 604 error code is received ("receive 4xx, 5xx not supported"), then the 605 MC moves back to the ADV RECEIVED state and produces a new CONF 606 message to be sent to the MP. If a successful RESPONSE arrives 607 ("receive 200 OK"), the MC gets into the CONF COMPLETED state. state. 609 When the MC is in the CONF COMPLETED state, it means that the 610 telepresence session configuration has been set up according to the 611 MC's preferences. Both the MP and the MC have agreed on (and are 612 aware of) the media streams to be exchanged within the call. If the 613 MC decides to change something in the call settings, it issues a new 614 CONF ("send CONF") and moves back to the TRYING state. If a new ADV 615 arrives from the MP ("receive ADV"), it means that something has 616 changed on the MP's side. The MC then moves to the ADV-RCV state and 617 prepares a new CONF taking into account the received updates. When 618 the underlying channel is closed, the MC moves into the TERMINATED 619 state. 621 The TERMINATED state is reachable from each of the aforementioned 622 states whenever the underlying channel is closed. The corresponding 623 transitions have not been reported for the sake of simplicity. This 624 termination condition is a temporary solution. 626 +-----+ 627 +---------------+-------------timeout------>+----+--+ | 628 | WAIT FOR ADV |<----+ |TIMEOUT| | 629 +---------------+<----+--------send---------+-------+ | 630 | | RE-ADV(refresh) ^ | 631 | | | | 632 | | | | 633 receive send | | 634 ADV NACK | | 635 +---receive-------+ | (missing elements, | | 636 | error RESP | | invalid area,...) | | 637 | v v | | | 638 +----------------+---------+----+ +--------+ | | 639 +---------------->| ADV |---send--->| ADV | timeout | 640 | | RECEIVED| ACK | ACKED | | | 641 | +---------->| | | | | | 642 | recv +----->+-----+---+<--recv----+----+---+ | | 643 | error | | ADV | | | 644 | RESP | send | | | 645 receive + | CONF, send| | | 646 ADV | | CONF+ACK CONF| | | 647 | | | | | | | 648 | | receive v | | | 649 | | ADV +-----------+<----------+ | | 650 | | | | |+-------------------------+ | 651 | +----|--------+| TRYING | | 652 +----------|---------| | | 653 +---|---------+-----------+ | 654 | | | ^ | 655 | | | | | 656 | | | | | 657 receive| | receive send retry 658 error RESP,| 200 OK CONF expires 659 retry | | | | | 660 expired| | | | | 661 | | | | | 662 | | v | | 663 | | +---------+ | | 664 | +-------| CONF | | | 665 | |COMPLETED|---+ | 666 | +---------+ | 667 | | | 668 | | | 669 | | | 670 | | | 671 | connection | 672 | closed | 673 | | | 674 | | | 675 | | | 676 | | | 677 | | | 678 | v | 679 | +----------+<---------------------------------+ 680 +----------->+TERMINATED| 681 +----------+ 683 7. Media Provider's state machine 685 In the PREPARING ADV state, the MP is preparing the ADV message 686 reflecting the actual telepresence capabilities. After the ADV has 687 been sent, the MP moves to the WAIT FOR ACK state. If the ACK 688 arrives, the MP moves to the WAIT FOR CONF state. If a NACK arrives, 689 it goes back to the PREPARING ADV state. 691 When in the WAIT FOR ACK state, if a CONF or a CONF+ACK arrives, the 692 MP switch to the CONF RECEIVED state directly. 694 When in the WAIT FOR CONF state, the MP is listening to the channel 695 for a CONF coming from the MC. If a RE-ADV is received, the MP goes 696 back to the IDLE state and issues an ADV again. If telepresence 697 settings change in the meanwhile, it moves back to the PREPARING ADV 698 state and prepares a new ADV to be sent to the MC. If a CONF 699 arrives, the MP switches to the CONF RECEIVED state. If nothing 700 happens and the timeout expires, than the MC falls into the TIMEOUT 701 state. 703 In the TIMEOUT state, if the number of trials does not exceed the 704 retry threshold, the MC comes back to the PREPARING ADV state for 705 sending a new ADV. Otherwise, it goes to the TERMINATED state. 707 The MP in the CONF RECEIVED state is processing the received CONF in 708 order to produce a CONF RESPONSE message. If the MP is fine with the 709 MC's configuration, then it sends back a 200 OK successful CONF 710 RESPONSE and moves to the IN CALL state. If there are errors duting 711 CONF processing, then the MC returns a CONF RESPONSE carrying an 712 error response code. Finally, if there are changes in the 713 telepresence settings, it goes back to the PREPARING ADV state to 714 issue an updated ADV. 716 When in the CONF COMPLETED state, the MP has successfully configured 717 the telepresence session according to the MC's specifications. If a 718 new CONF arrives, it switches to the CONF RECEIVED state to analyze 719 the new request. If a RE-ADV arrives, or some modifications are 720 applied to the telepresence options, then it moves to the PREPARE-ADV 721 state to issue the ADV. When the channel is terminated, the MP falls 722 into the TERMINATED state. 724 The TERMINATED state is reachable from each of the aforementioned 725 states whenever the underlying channel is closed. The corresponding 726 transitions have not been reported for the sake of simplicity. This 727 termination condition is a temporary solution. 729 +-----------+ 730 | | 731 | PREPARING | 732 +----------------->| ADV |<--------------------------+ 733 | +------------->| |<-----------retry----------+---------+ 734 | | +----->| |<--+ not | | 735 | | | +-----------+ | expired | | 736 | | | | | | | 737 | | change send receive | ++------+ 738 | | telepresence ADV NACK | |TIMEOUT| 739 | | settings | | | ++--+---+ 740 | | | | | | ^ | 741 | | | v | | | | 742 | | | +-------------+---+ | | | 743 | | +----+ WAIT FOR +------------timeout--------+---------+ | 744 | | +--+ ACK | | | 745 change | +-------+-----+ | | 746 telepresence | | | | 747 settings | recv | + 748 + + | ACK + | 749 | | | | | | 750 | | | v | | 751 | | | +-----------+ | | 752 | | recv | WAIT FOR | | | 753 | | CONF, | CONF |<-+ | | 754 | | CONF+ACK +----+------+ | | | 755 | | | | + | | 756 + | | receive CONF error, + | 757 | + | CONF retry not expired, | + 758 | | | | send error RESP | | 759 | | | | | | | 760 | | | | | | | 761 | | | v | | | 762 | | +--->+-----------+---+ | | 763 +---+-------------+| CONF | | | 764 | +----->| RECEIVED |----CONF error, | | 765 | | +-----+-----+ retry expired | | 766 | | | + | | 767 | | | | | | 768 | | | | | | 769 receive receive send | | | 770 RE-ADV CONF 200 OK | | retry| 771 | | | | | expired 772 | | | | | | 773 | | | | | | 774 | | v | | | 775 | | +----------+ | change | | 776 | +-------| CONF |----|---telepresence-------+ | 777 +---------------| COMPLETED| | settings | 778 +----------+ | | 779 | | | 780 | | | 781 | | | 782 connection | | 783 closed | | 784 | | | 785 | | | 786 v | + 787 +----------------+<-+ | 788 | TERMINATED |<-------------------------------------+ 789 | | 790 +----------------+ 792 8. About CLUE protocol XML schema versioning 794 CLUE protocol messages are XML messages compliant to the CLUE 795 protocol XML schema. The version of the protocol corresponds to the 796 version of the schema. Both client and server have to test the 797 compliance of the received messages with the XML schema of the CLUE 798 protocol. If the compliance is not verified, the message cannot be 799 processed further. 801 Obviously, client and server can not communicate if they do not share 802 exactly the same XML schema. Such a schema is the one included in 803 the yet to come RFC, and associated with the CLUE URN 804 "urn:ietf:params:xml:ns:clue-message". If all CLUE-enabled devices 805 use that schema there will be no interoperability problems due to 806 schema issues. 808 The version of the XML schema contained in the standard document 809 deriving from this draft will be 1.0. The subsequent versions of the 810 XML schema should be backward compatible, not only in terms of schema 811 but also semantically and procedurally as well. This means that they 812 should define further features and functionality besides those 813 defined in the previous versions, in an incremental way, without 814 impacting the basic rules defined in the previous version of the 815 schema. In this way, if a MP is able to speak, e.g., version 5.0 of 816 the protocol while the MC only understands version 4.0, the MP should 817 have no problem in reverting the dialogue to version 4.0 without 818 exploiting 5.0 features and functionality. 820 It is expected that, before the CLUE protocol XML schema reaches a 821 steady state, prototypes developed by different organizations will 822 conduct interoperability testing. In that case, in order to 823 interoperate, they have to be compliant to the current version of the 824 XML schema, i.e., the one copied in the most up-to-date version of 825 the draft defining the CLUE protocol. The versions of the non- 826 standard XML schema will be numbered as 0.01, 0.02, and so on. 827 During the standard development phase, the versions of the XML schema 828 will probably not be backward compatible so it is left to prototype 829 implementers the responsibility of keeping their products up to date. 831 Even though strongly discouraged, if a future version of the protocol 832 is designed which breaks the backward compatibility constraint, this 833 aspect MUST be explicitly advertised in the corresponding new RFC 834 document. In such a case, it would be up to developers to update 835 their systems accordingly. 837 9. Extensibility issues 839 Although the standard version of the CLUE protocol XML schema will be 840 designed to thoroughly cope with the requirements emerging from the 841 application domain, new needs might arise in the future. Such needs 842 may relate to two main aspects of the protocol: 844 the information carried in the existing messages (for example, we 845 may want to add more fields within an existing message); 847 the meaning of the messages. This is the case if there is no 848 proper message for a certain task, so a brand new CLUE message 849 needs to be defined. 851 9.1. Aspect 1 - new information within existing messages 853 CLUE messages are envelopes carrying two types of information: 855 XML elements defined within the CLUE protocol XML schema itself 856 (protocol-specific information) 858 other XML elements compliant to the CLUE data model schema (data 859 model information) 861 When new protocol-specific information is needed somewhere in the 862 protocol messages, it can be added in place of the elements and 863 elements envisioned by the protocol schema. The 864 policy currently defined in the protocol schema for handling 865 and elements is: 867 elementFormDefault="qualified" 869 attributeFormDefault="unqualified" 871 In that case, the new information must be qualified by namespaces 872 other than "urn:ietf:params:xml:ns:clue-message" (the protocol URN) 873 and "urn:ietf:params:xml:ns:clue-info" (the data model URN). 874 Elements or attributes from unknown namespaces MUST be ignored. 876 The other matter concerns data model information. Data model 877 information is defined by the XML schema associated with the URN 878 "urn:ietf:params:xml:ns:clue-info". Also for the XML elements 879 defined in such a schema there are extensibility issues. Those 880 issues are overcome by using and placeholders. 881 Similarly to what said before, new information within data model 882 elements can be added in place of and schema 883 elements, as long as they are properly namespace qualified. 885 9.2. Aspect 2 - new messages 887 New CLUE protocol messages, not envisioned in the standard version of 888 the schema, are needed. Also in that case we have three chances: 890 writing down a new version of the protocol schema, with the new 891 messages added after the existing ones. The same considerations 892 of the first option above hold here. 894 putting all the new messages inside a brand new schema to be 895 linked to a new URN that the most up to date telepresence system 896 must be aware of. 898 designing a wildcard envelope for future messages. This is an 899 approach used also within the CCMP protocol (Centralized 900 Conferencing Manipulation Protocol, [RFC6503]). In that case, a 901 mechanism for the extension negotiation is also envisioned. 903 10. Managing protocol version negotiation and extensions: the OPTIONS 904 request 906 In this section we provide a mechanism for handling both protocol 907 extension and version negotiation issues. 909 We propose a new request message issued by the CI towards the CR as 910 soon as the CLUE channel is istantiated: the OPTIONS message. This 911 message carries: 913 the CLUE protocol version adopted by the CI 915 the data model extensions supported by the CI 917 the protocol extensions supported by the CI 919 When the CR receives the OPTIONS message, it reads the CLUE protocol 920 version of the CI (the highest protocol version of the CI). If the 921 CI's version is higher than the CR's one, then the CR responds to the 922 CI by using in the OPTIONS RESPONSE message its own version. The CI 923 has to downgrade the CLUE dialogue to the version specified by the CR 924 in the subsequent CLUE messages. If CI's version is equal to or 925 lower than CR's version, then the CR will use in the OPTIONS RESPONSE 926 message the same version as the one in the OPTIONS message and all 927 subsequent CLUE messages must carry that version number. In the 928 latter case, it is the CR who has to to downgrade the CLUE dialogue 929 in order to be understood by the CI. 931 A data model extension is a set of XML definitions related to the 932 description of telepresence capabilities that is contained in an XML 933 schema and which is different from the normative CLUE data model 934 schema. Such XML definitions can represent further entities not 935 envisioned in the CLUE framework at the time of writing of the data 936 model draft. The entities defined in a data model extension can 937 appear in place of the and elements included in 938 the data model document. A data model extension is then represented 939 by a reference to the defining XML schema. The schema reference is 940 represented by a URI defining the schema location. [TBC] If a data 941 model extension is supported by both a CR and a CI, this means that 942 both are aware of the associated XML schema and of the meanings of 943 the elements therein defined. 945 A protocol extension is a set of XML definitions related to the CLUE 946 protocol that is contained in an XML schema which is different from 947 the normative CLUE protocol schema. Such definitions can represent: 948 (i) information to be carried within the existing messages in place 949 of and elements; (ii) new messages designed for 950 the CLUE telepresence control. Such XML definitions refer to 951 information not envisioned during the CLUE protocol design phase. A 952 protocol extension is then represented by a reference to the defining 953 XML schema. If a protocol extension is supported by both a CI and a 954 CR, it means that both are aware of the associated XML schema and of 955 the meanings of the elements defined within it. 957 When the CR receives the CI's OPTIONS message, it selects the data 958 model extensions and the protocol extensions that it is able to 959 support, and then provides them into the OPTIONS RESPONSE message 960 back to the CI. Only the extensions included in the RESPONSE message 961 can be used during the telepresence session. 963 The XML schema definition of the OPTIONS message is provided in the 964 following. 966 967 968 969 970 971 972 973 975 976 977 978 980 981 983 984 985 986 988 989 991 992 993 994 995 996 997 10.1. An example using OPTIONS 999 An example of OPTIONS dialogue is provided in the following. 1001 +------+ +------+ 1002 | CI | | CR | 1003 | | | | 1004 +--+---+ +--+---+ 1005 | | 1006 | OPTIONS 3.0 | 1007 | dm-ext: s1, s2, s3 | 1008 | pr-ext: s4, s5 | 1009 |<--------------------+| 1010 | | 1011 | RESPONSE 1.0 | 1012 | dm-ext: s1 | 1013 | pr-ext: - | 1014 |+-------------------->| 1015 | | 1016 | | 1017 | ADV 1.0 | 1018 |+-------------------->| 1019 | | 1020 | CONFIGURE+ACK 1.0 | 1021 |<--------------------+| 1022 | | 1023 | | 1024 v v 1026 When the CLUE channel is ready, the CI issues an OPTIONS request to 1027 the CR. The CI uses the 3.0 version of the CLUE protocol, and 1028 supports schemas s1, s2, s3 as data model extensions and schemas s4, 1029 s5 as protocol extensions. 1031 The CR speaks the 1.0 version of the CLUE protocol and supports only 1032 the first data model extension among those indicated by the CI. It 1033 then issues a v. 1.0 RESPONSE to the CI copying only the supported 1034 option. The CI is able to understand that it can use only the 1.0 1035 version of the protocol and the s1 extension. 1037 After the negotiation phase is completed, both CP starts their MP and 1038 MC machines and the dialouge for the media sessions set up starts. 1039 An example of possible messaging flowing on the channel is 1040 represented by the ADV issued by the CI's MP towards the CR's MC and 1041 the following CONF+ACK, both version 1.0. 1043 11. XML Schema of CLUE protocol messages 1045 In this section we paste the XML schema defining the ADVERTISEMENT, 1046 CONFIGURE and RESPONSE messages contained in 1047 [I-D.kyzivat-clue-signaling]. At the time of writing, it assumes 1048 that encodings are described in SDP as m-lines with a text 1049 identifier, and that the identifier has the same value as the 1050 encodingIDs embedded in the . However, that 1051 assumption is still under discussion in the context of the CLUE-SDP 1052 coupling issues. 1054 *** TO BE UPDATED *** 1056 1057 1067 1068 1071 1072 1073 1074 1075 1076 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1097 1098 1099 1100 1101 1102 1103 1104 1106 1107 1108 1109 1111 1112 1114 1115 1116 1117 1119 1120 1122 1123 1124 1125 1126 1127 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1151 1152 1153 1154 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1168 1169 1170 1171 1172 1173 1174 1175 1177 1179 1181 1183 1184 1186 1188 1189 1190 1191 1193 1194 1195 1196 1197 1198 1199 1200 1201 1203 1205 1206 1207 1208 1210 1211 1212 1213 1214 1215 1216 1217 1219 1220 12. Examples 1222 TBD 1224 13. Handling channel errors 1226 TBD 1228 14. Diff with the -02 version 1230 1. "Terminology" section added. 1232 2. Introduced the concept of "CLUE Participant" - an Endpoint or a 1233 MCU able to use the CLUE protocol within a telepresence session. 1234 A CLUE Participant can act as a Media Provider and/or as a Media 1235 Consumer. 1237 3. INtroduced the ACK/NACK mechanism for the ADVERTISEMENT. 1239 4. MP and MC state machines have been updated. The CP state machine 1240 has been added. 1242 15. Acknowledgments 1244 We would like to thank Liuyan Scarlett for her precious feedback on 1245 the protocol document, as well as for proposing the introduction of 1246 the concept of a main state machine including the MP and MC sub state 1247 machines. 1249 16. Informative References 1251 [I-D.ietf-clue-data-model-schema] Presta, R. and S. Romano, 1252 "An XML Schema for the 1253 CLUE data model", draft- 1254 ietf-clue-data-model- 1255 schema-00 (work in 1256 progress), July 2013. 1258 [I-D.ietf-clue-framework] Duckworth, M., Pepperell, 1259 A., and S. Wenger, 1260 "Framework for 1261 Telepresence Multi- 1262 Streams", draft-ietf-clue- 1263 framework-12 (work in 1264 progress), October 2013. 1266 [I-D.ietf-clue-telepresence-requirements] Romanow, A., Botzko, S., 1267 and M. Barnes, 1268 "Requirements for 1269 Telepresence Multi- 1270 Streams", draft-ietf-clue- 1271 telepresence-requirements- 1272 06 (work in progress), 1273 October 2013. 1275 [I-D.kyzivat-clue-signaling] Kyzivat, P., Xiao, L., 1276 Groves, C., and R. Hansen, 1277 "CLUE Signaling", draft- 1278 kyzivat-clue-signaling-05 1279 (work in progress), 1280 September 2013. 1282 [RFC3550] Schulzrinne, H., Casner, 1283 S., Frederick, R., and V. 1284 Jacobson, "RTP: A 1285 Transport Protocol for 1286 Real-Time Applications", 1287 STD 64, RFC 3550, 1288 July 2003. 1290 [RFC4353] Rosenberg, J., "A 1291 Framework for Conferencing 1292 with the Session 1293 Initiation Protocol 1294 (SIP)", RFC 4353, 1295 February 2006. 1297 [RFC5117] Westerlund, M. and S. 1298 Wenger, "RTP Topologies", 1299 RFC 5117, January 2008. 1301 [RFC5261] Urpalainen, J., "An 1302 Extensible Markup Language 1303 (XML) Patch Operations 1304 Framework Utilizing XML 1305 Path Language (XPath) 1306 Selectors", RFC 5261, 1307 September 2008. 1309 [RFC6502] Camarillo, G., Srinivasan, 1310 S., Even, R., and J. 1311 Urpalainen, "Conference 1312 Event Package Data Format 1313 Extension for Centralized 1314 Conferencing (XCON)", 1315 RFC 6502, March 2012. 1317 [RFC6503] Barnes, M., Boulton, C., 1318 Romano, S., and H. 1319 Schulzrinne, "Centralized 1320 Conferencing Manipulation 1321 Protocol", RFC 6503, 1322 March 2012. 1324 Authors' Addresses 1326 Roberta Presta 1327 University of Napoli 1328 Via Claudio 21 1329 Napoli 80125 1330 Italy 1332 EMail: roberta.presta@unina.it 1334 Simon Pietro Romano 1335 University of Napoli 1336 Via Claudio 21 1337 Napoli 80125 1338 Italy 1340 EMail: spromano@unina.it