idnits 2.17.1 draft-presta-clue-protocol-01.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 94 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** 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 571: '...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 396 has weird spacing: '...receive sen...' == Line 490 has weird spacing: '...receive rece...' -- The document date (September 17, 2013) is 3874 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-25) exists of draft-ietf-clue-framework-11 == Outdated reference: A later version (-08) exists of draft-kyzivat-clue-signaling-05 Summary: 4 errors (**), 0 flaws (~~), 5 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: Informational University of Napoli 5 Expires: March 21, 2014 September 17, 2013 7 CLUE protocol 8 draft-presta-clue-protocol-01 10 Abstract 12 ToDo. 14 Status of This Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF). Note that other groups may also distribute 21 working documents as Internet-Drafts. The list of current Internet- 22 Drafts is at http://datatracker.ietf.org/drafts/current/. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 This Internet-Draft will expire on March 21, 2014. 31 Copyright Notice 33 Copyright (c) 2013 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Overview of the CLUE protocol messages . . . . . . . . . . . . 3 51 3.1. ADVERTISEMENT . . . . . . . . . . . . . . . . . . . . . . 4 52 3.2. CONFIGURE . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3.3. RESPONSE . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3.4. RE-ADV . . . . . . . . . . . . . . . . . . . . . . . . . . 8 55 4. Protocol state machines . . . . . . . . . . . . . . . . . . . 9 56 5. Media Consumer's state machine . . . . . . . . . . . . . . . . 10 57 6. Media Provider's state machine . . . . . . . . . . . . . . . . 12 58 7. About CLUE protocol XML schema extensibility and versioning . 14 59 7.1. Aspect 1 - new information within existing messages . . . 15 60 7.2. Aspect 2 - new messages . . . . . . . . . . . . . . . . . 16 61 8. Diff with -00 version . . . . . . . . . . . . . . . . . . . . 16 62 9. Informative References . . . . . . . . . . . . . . . . . . . . 16 64 1. Introduction 66 The CLUE protocol is an application protocol used by a Media Provider 67 (MP) and a Media Consumer (MC) in order to establish a multimedia 68 telepresence session. CLUE protocol messages flow upon a DTLS/SCTP 69 channel established as depicted in [I-D.kyzivat-clue-signaling]. 70 While [I-D.kyzivat-clue-signaling] focuses onto signaling details 71 about the protocol and its interaction with the SIP/SDP session 72 establishment, we herein concentrate only on the protocol in action 73 (?) and try to define the behavior of both the MP and the MC at the 74 CLUE application level. In other words, we assume the DTLS/SCTP 75 channel is established and discuss how the CLUE dialogue between the 76 MP and the MC can be exploited to successfully setup the telepresence 77 session according to the principles and concepts pointed out in in 78 [I-D.kyzivat-clue-signaling] and in [I-D.ietf-clue-framework]. 80 In Section 3 we provide the list of the CLUE messages and an overview 81 of their features and functionality. MC's and MP's state machines 82 are introduced in Section 4 and further described in Section 5 and 83 Section 6 respectively. 85 2. Terminology 87 This document refers to the same terminology used in 88 [I-D.ietf-clue-framework] and in [I-D.kyzivat-clue-signaling]. 90 3. Overview of the CLUE protocol messages 92 This section contains a bird's-eye view of the CLUE protocol 93 messages. For each message it is indicated who sends it, who 94 receives it, a brief description of the information it carries, and 95 how/when it is used. Besides the well-known ADVERTISEMENT and 96 CONFIGURE ones, new messages have been conceived in order to fulfill 97 the mechanisms and operations pointed out in 98 [I-D.kyzivat-clue-signaling]. 100 o ADVERTISEMENT (ADV) 102 o CONFIGURE (CONF) 104 o RESPONSE 106 o RE-ADV 108 3.1. ADVERTISEMENT 110 +---------- ---+-----------------------------------------------------+ 111 | | | 112 | FROM | MP | 113 | | | 114 +--------------+-----------------------------------------------------+ 115 | | | 116 | TO | MC | 117 | | | 118 +--------------+-----------------------------------------------------+ 119 | | | 120 | TYPE | Notification | 121 | | | 122 +--------------+-----------------------------------------------------+ 123 | | | 124 | DESCRIPTION | This message is used by the MP to advertise the | 125 | | available media captures and related information | 126 | | to the MC. | 127 | | The ADV contains elements compliant with the | 128 | | CLUE data model and other information like the | 129 | | CLUE protocol version and a sequence number. | 130 | | | 131 +--------------+-----------------------------------------------------+ 132 | | | 133 | USAGE | The MP sends this message as soon as the CLUE | 134 | | CLUE channel is ready. The MP sends an ADV to the | 135 | | MC each time there is a modification of the MP's | 136 | | telepresence capabilities. | 137 | | The ADV message is also sent back to the MC | 138 | | when the MP receives a RE-ADV request. | 139 +--------------+-----------------------------------------------------+ 141 3.2. CONFIGURE 142 +--------------+-----------------------------------------------------+ 143 | | | 144 | FROM | MC | 145 | | | 146 +--------------+-----------------------------------------------------+ 147 | | | 148 | TO | MP | 149 | | | 150 +--------------+-----------------------------------------------------+ 151 | | | 152 | TYPE | Request | 153 | | | 154 +--------------+-----------------------------------------------------+ 155 | | | 156 | DESCRIPTION | This message allows a MC to request for the | 157 | | desired advertised capture. It contains capture | 158 | | encodings and other information like the CLUE | 159 | | protocol version and a sequence number. | 160 | | | 161 +--------------+-----------------------------------------------------+ 162 | | | 163 | USAGE | The MC can send a CONF after the reception of | 164 | | an ADV or each time it wants to request other | 165 | | advertised captures to the MP. | 166 +--------------+-----------------------------------------------------+ 168 3.3. RESPONSE 169 +--------------+-----------------------------------------------------+ 170 | | | 171 | FROM | MP | 172 | | | 173 +--------------+-----------------------------------------------------+ 174 | | | 175 | TO | MC | 176 | | | 177 +--------------+-----------------------------------------------------+ 178 | | | 179 | TYPE | Response | 180 | | | 181 +--------------+-----------------------------------------------------+ 182 | | | 183 | DESCRIPTION | This message allows a MP to answer to a CONF | 184 | | message. Besides the protocol version and a | 185 | | sequence number, it contains a response code with | 186 | | a response string indicating the success or the | 187 | | failure (along with failure details) of the CONF | 188 | | request elaboration. Example of response codes | 189 | | and strings are provided in a following table. | 190 | | | 191 +--------------+-----------------------------------------------------+ 192 | | | 193 | USAGE | The MP sends this message in response to CONF | 194 | | messages. | 195 +--------------+-----------------------------------------------------+ 197 Response code can be designed by following the HTTP semantics as 198 below. 200 +-----------------+----------------------+--------------------------+ 201 | | | | 202 | Response code | Response string | Description | 203 | | | | 204 +-----------------+----------------------+--------------------------+ 205 | | | | 206 | 410 | Bad syntax | The XML syntax of the | 207 | | | CONF message is not | 208 | | | correct. | 209 +-----------------+----------------------+--------------------------+ 210 | | | | 211 | 411 | Invalid value | The CONF message | 212 | | | contains an invalid | 213 | | | parameter value. | 214 +-----------------+----------------------+--------------------------+ 215 | | | | 216 | 412 | Invalid identifier | The identifier used for | 217 | | | requesting a capture is | 218 | | | not valid or unknown. | 219 +-----------------+----------------------+--------------------------+ 220 | | | | 221 | 413 | Conflicting values | The CONF message | 222 | | | contains values that | 223 | | | cannot be used together.| 224 +-----------------+----------------------+--------------------------+ 225 | | | | 226 | 420 | Invalid sequencing | The sequence number of | 227 | | | the CONF message is out | 228 | | | of date or corresponds | 229 | | | to an obsoleted ADV. | 230 +-----------------+----------------------+--------------------------+ 231 | | | | 232 | 510 | Version not supported| The CLUE protocol | 233 | | | version of the CONF | 234 | | | message is not supported| 235 | | | by the MP. | 236 +-----------------+----------------------+--------------------------+ 237 | | | | 238 | 511 | Option not supported | The option requested in | 239 | | | the CONF message is not | 240 | | | supported by the MP. | 241 +-----------------+----------------------+--------------------------+ 243 ... TBC. 245 +---------------+------------------------+ 246 | | | 247 | Response code | Rescription | 248 | family | | 249 +---------------+------------------------+ 250 | | | 251 | 1XX | Temporary info | 252 | | | 253 +---------------+------------------------+ 254 | | | 255 | 2XX | Success | 256 | | | 257 +---------------+------------------------+ 258 | | | 259 | 3XX | Redirection | 260 | | | 261 +---------------+------------------------+ 262 | | | 263 | 4XX | Client error | 264 | | | 265 +---------------+------------------------+ 266 | | | 267 | 5XX | Server error | 268 | | | 269 +---------------+------------------------+ 271 3.4. RE-ADV 272 +---------- ---+-----------------------------------------------------+ 273 | | | 274 | FROM | MC | 275 | | | 276 +--------------+-----------------------------------------------------+ 277 | | | 278 | TO | MP | 279 | | | 280 +--------------+-----------------------------------------------------+ 281 | | | 282 | TYPE | Request | 283 | | | 284 +--------------+-----------------------------------------------------+ 285 | | | 286 | DESCRIPTION | This message allows a MC to request for the MP | 287 | | issuing a new copy of the ADV. This message can | 288 | | contain a reason string indicating the motivation | 289 | | for the request (e.g., refresh, missing elements | 290 | | in the received ADV, wrong syntax in the received | 291 | | ADV, invalid capture area, invalid line of | 292 | | capture point, etc). | 293 | | | 294 +--------------+-----------------------------------------------------+ 295 | | | 296 | USAGE | The MC sends this message to the MP when the | 297 | | timeout for the ADV is fired, or when the ADV is | 298 | | not compliant with the CLUE specifications (this | 299 | | can be useful for interoperability testing | 300 | | purposes) | 301 | | | 302 +--------------+-----------------------------------------------------+ 304 4. Protocol state machines 306 The CLUE protocol is an application protocol used between a Media 307 Provider (MP) and a Media Consumer (MC) in order to establish a 308 multimedia telepresence session. CLUE protocol messages flow upon a 309 DTLS/SCTP channel established as depicted in 310 [I-D.kyzivat-clue-signaling]. Over such a channel there are 311 typically two CLUE streams between the channel terminations flowing 312 in opposite directions. In other words, typically, both channel 313 terminations act simultaneously as a MP and as a MC. We herein 314 discuss the state machines associated with the MP process and with 315 the MC process. 317 5. Media Consumer's state machine 319 An MC in the IDLE state is waiting for an ADV coming from the MP. If 320 the timeout expires ("timeout"), the MC switch to the TIMEOUT state. 322 In the TIMEOUT state, if the number of trials is under the retry 323 threshold, the MC issues a RE-ADV/refresh message to the MP ("send 324 RE-ADV"), coming back to the IDLE state. Otherwise, the MC moves to 325 the TERMINATED state. 327 When the ADV has been received ("receive ADV"), the MC goes into the 328 ADV RECEIVED state. The ADV is then parsed. If something goes wrong 329 with the ADV (bad syntax, missing XML elements, etc.), the MC sends a 330 RE-ADV message to the MP specifying the encountered problem via a 331 proper reason phrase. By this way, the MC comes back to the IDLE 332 state, waiting for a new copy of the ADV. If the ADV is successfully 333 processed, the MC issues a CONF message to the MP ("send CONF") and 334 switches to the TRYING state. 336 When in the TRYING state, the MC is waiting for a RESPONSE message 337 from the MP to the issued CONF. If the timeout expires ("timeout"), 338 the MC moves to the TIMEOUT state and sends a RE-ADV in order to 339 solicit a new ADV from the MP. If a RESPONSE with an error code is 340 received ("receive 4xx, 5xx not supported"), then the MC comes back 341 to the ADV-RCVD state and produces a new CONF message to be sent to 342 the MP. If a successful RESPONSE arrives ("receive 200 OK"), the MC 343 gets the IN CALL state. If a new ADV arrives in the while, it is 344 ignored. Indeed, after the timeout is exceeded, the MC goes to the 345 TIMEOUT state and then sends a RE-ADV to the MP. 347 When the MC is in the IN CALL state, it means that the telepresence 348 session has been set up according to the MC's preferences. Both MP 349 and the MC have agreed on (and are aware of) the media streams to be 350 exchanged within the call. If the MC decides to change something in 351 the call settings, it issues a new CONF ("send CONF") and comes back 352 to the TRYING state. If a new ADV arrives from the MP ("receive 353 ADV"), it means that something has changed on the MP's side. The MC 354 then moves to the ADV-RCV state and prepares a new CONF taking into 355 account the received updates. When the underlying channel is closed, 356 the MC moves into the TERMINATED state. 358 The TERMINATED state is reachable from each of the aforementioned 359 states whenever the underlying channel is closed. The corresponding 360 transitions have not been reported for the sake of simplicity. This 361 termination condition is a temporary solution. 363 The TERMINATED state is reachable from each of the aforementioned 364 states whenever the underlying channel is closed. The corresponding 365 transitions have not been reported for the sake of simplicity. This 366 termination condition is a temporary solution. 368 +-----+ 369 +--------+-------------timeout------>+----+--+ | 370 | IDLE +<----+ |TIMEOUT| | 371 +---+----+<----+--------send---------+-------+ | 372 | | RE-ADV(refresh) ^ | 373 | | | | 374 | | | | 375 receive send | | 376 ADV RE-ADV | | 377 +---receive-------+ | (missing elements, | | 378 | error RESP | | invalid area,...) | | 379 | v v | | | 380 +---------------++---------+ | | | 381 +---------------->+ ADV +----+ timeout | 382 | +----->| RECEIVED|<-----+ | | 383 | | +---+-----+ | | | 384 receive | | | | | 385 ADV | | | | | 386 | | | | | | 387 | receive send receive | | 388 | ADV CONF error RESP, | | 389 | | | retry not expired | | 390 | | v | | | 391 +-----------------+--------+-------+------------------------+ | 392 +---+------+ TRYING +-------+ | 393 | | +---+----+<----+ | 394 | | | | | 395 | | | | | 396 receive| | receive send retry 397 error RESP,| 200 OK CONF expires 398 retry | | | | | 399 expired| | | | | 400 | | | | | 401 | | v | | 402 | | +------+ | | 403 | +-------+ IN | | | 404 | | CALL +------+ | 405 | +--+---+ | 406 | | | 407 | | | 408 | | | 409 | | | 410 | connection | 411 | closed | 412 | | | 413 | | | 414 | | | 415 | | | 416 | | | 417 | v | 418 | +----------+<---------------------------------+ 419 +----------->+TERMINATED| 420 +----------+ 422 6. Media Provider's state machine 424 In the IDLE state, the MP is preparing the ADV message reflecting the 425 actual telepresence capabilities. After the ADV has been sent, the 426 MP moves to the WAIT FOR CONF state. 428 When in the WAIT FOR CONF state, the MP is listening the channel for 429 a CONF coming from the MC. If a RE-ADV is received, the MP comes 430 back to the IDLE state and issues an ADV again. If telepresence 431 settings change in the while, it comes back to the IDLE state too, 432 and prepare a new ADV to be sent to the MC. If a CONF arrives, the 433 MP switches to the CONF RECEIVED state. If nothing happens and the 434 timeout exceeds, than the MC falls into the TIMEOUT state. 436 In the TIMEOUT state, if the number of trials does not exceed the 437 retry threshold, the MC comes back to the IDLE state for sending a 438 new ADV. Otherwise, it goes to the TERMINATED state. 440 The MP in the CONF RECEIVED state is processing the received CONF in 441 order to produce a RESPONSE message. If the MP is ok with the MC's 442 configuration, then it sends a 200 OK successful RESPONSE and flows 443 to the IN CALL state. If there are errors while processing the CONF, 444 then the MC returns a RESPONSE carrying an error response code. 445 Finally, if there are changes in the telepresence settings, it goes 446 back to the IDLE state to issue an updated ADV. 448 When in the IN CALL state, the MP has successfully set up the 449 telepresence session according to the MC's specifications. If a new 450 CONF arrives, it switches to the CONF RECEIVED state to analyze the 451 new requests. If a RE-ADV arrives, or some modifications are applied 452 to the telepresence options, then it moves to the IDLE state to issue 453 the ADV. When the channel is terminated, the MP falls into the 454 TERMINATED state. 456 The TERMINATED state is reachable from each of the aforementioned 457 states whenever the underlying channel is closed. The corresponding 458 transitions have not been reported for the sake of simplicity. This 459 termination condition is a temporary solution. 461 +------------------->+-----+-+<----------------------------+ 462 | +--------------->| IDLE |<-------------retry----------+---------+ 463 | | +------->+---+---+<----+ not | | 464 | | | | | expired | | 465 | | | | | | | 466 | | change send receive | ++------+ 467 | | telepresence ADV RE-ADV | |TIMEOUT| 468 | | settings | | | ++--+---+ 469 | | | | | | ^ | 470 | | | v | | | | 471 | | | +-------------+---+ | | | 472 | | +----+ WAIT FOR +------------timeout--------+---------+ | 473 | | | CONF | | | 474 change +-------+-----+<--+ | | 475 telepresence | | | | 476 settings | | | | 477 | | receive CONF error, | | 478 | | CONF retry not expired, | | 479 | | | send error RESP | | 480 | | | | | | 481 | | | | | | 482 | | v | | | 483 | | +-----------+---+ | | 484 +---+-------------+| CONF | | | 485 | +----->| RECEIVED |----CONF error, | | 486 | | +-----+-----+ retry expired | | 487 | | | | | | 488 | | | | | | 489 | | | | | | 490 receive receive send | | | 491 RE-ADV CONF 200 OK | | retry| 492 | | | | | expired 493 | | | | | | 494 | | | | | | 495 | | v | | | 496 | | +----------+ change | | 497 | +-------+ IN CALL +--------telepresence-------+ | 498 +---------------+----+-----+ settings | 499 | | | 500 | | | 501 | | | 502 | | | 503 connection | | 504 closed | | 505 | | | 506 | | | 507 v | | 508 +------------+<-----+-----------------------------+ 509 | TERMINATED | | 510 +------------+<-----+ 512 7. About CLUE protocol XML schema extensibility and versioning 514 CLUE protocol messages are XML messages compliant to the CLUE 515 protocol XML schema. Both client and server have to test the 516 compliance of the received messages with the XML schema of the CLUE 517 protocol. If the compliance is not verified, the message cannot be 518 processed. 520 Obviously, client and server can not communicate if they do not share 521 exactly the same XML schema. Such schema will be the one included in 522 the to-be-written RFC, and associated with the CLUE URN 523 "urn:ietf:params:xml:ns:clue-message". If all CLUE-enabled devices 524 use that schema there will be no interoperability problems due to 525 schema issues. 527 It is hoped that, before the CLUE protocol XML schema reaches a 528 steady state, prototypes developed by different organizations would 529 perform some tests. In that case, in order to interoperate, they 530 have to be compliant to the current version of the XML schema, i.e., 531 the one copied in the most up-to-date version of the draft defining 532 the CLUE protocol. It is up to prototype implementors to keep up to 533 date their products. 535 Although the standard version of the CLUE protocol XML schema will be 536 designed to thoroughly cope with the requirements emerging from the 537 application domain, new needs can arise in the future. A mechanism 538 assuring forward compatibility must be envisioned. New needs can 539 interest two main aspects of the protocol: 541 the information carried in the existing messages (for example, we 542 may want to add more fields within an existing message); 544 the meaning of the messages. This is the case if there is no a 545 message for a certain task, so a brand new CLUE message needs to 546 be defined. 548 7.1. Aspect 1 - new information within existing messages 550 CLUE messages are envelopes carrying two types of information: 552 XML elements defined within the CLUE protocol XML schema itself 553 (protocol-specific information) 555 other XML elements compliant to the CLUE data model schema (data 556 model information) 558 When new protocol-specific information are needed somewhere in the 559 protocol messages, they can be added in place of the elements 560 and elements envisioned by the protocol schema. The 561 policy currently defined in the protocol schema for handling 562 and elements is: 564 elementFormDefault="qualified" 566 attributeFormDefault="unqualified" 568 In that case, the new information must be qualified by namespaces 569 other than "urn:ietf:params:xml:ns:clue-message" (the protocol URN) 570 and "urn:ietf:params:xml:ns:clue-info" (the data model URN). 571 Elements or attributes from unknown namespaces MUST be ignored. 573 The other matter interests data model information. Data model 574 information is defined by the XML schema associated with the URN 575 "urn:ietf:params:xml:ns:clue-info". Also for the XML elements 576 defined in such schema there are extensibility issues. Those issues 577 are overcome by using and placeholders. 578 Similarly to what said before, new information within data model 579 elements can be added in place of and schema 580 elements, as long as they are properly namespace qualified. If brand 581 new data model elements are needed, then there are three options: 583 write down a new version of the data model schema, with the new 584 elements added after the existing ones. This is a possible 585 solution. However, we must state that telepresence applications 586 are forced to check the version attribute of the schema they use. 587 [To be discussed] 589 put all the new elements inside a brand new schema to be linked to 590 a new URN that the most up to date telepresence system must be 591 aware of. [To be discussed] 593 design a wildcard envelope for future data model elements. [To be 594 discussed] 596 7.2. Aspect 2 - new messages 598 New CLUE protocol messages, not envisioned in the standard version of 599 the schema, are needed. Also in that case we have three chances: 601 write down a new version of the protocol schema, with the new 602 messages added after the existing ones. The same considerations 603 of the first option above hold here. [To be discussed] 605 put all the new messages inside a brand new schema to be linked to 606 a new URN that the most up to date telepresence system must be 607 aware of. :( [To be discussed] 609 design a wildcard envelope for future messages. This is an 610 approach used also within the CCMP protocol (Centralized 611 Conferencing Manipulation Protocol, [RFC6503]). In that case, a 612 mechanism for the extension negotiation is also envisioned. [To 613 be discussed] 615 8. Diff with -00 version 617 MC and MP state diagrams have been updated for discussion in 618 http://www.ietf.org/mail-archive/web/clue/current/msg02650.html 620 Consideration about protocol extension and versioning have been 621 added to foster discussion. 623 9. Informative References 625 [I-D.ietf-clue-framework] Duckworth, M., Pepperell, A., and S. 626 Wenger, "Framework for Telepresence 627 Multi-Streams", 628 draft-ietf-clue-framework-11 (work in 629 progress), July 2013. 631 [I-D.kyzivat-clue-signaling] Kyzivat, P., Xiao, L., Groves, C., and 632 R. Hansen, "CLUE Signaling", 633 draft-kyzivat-clue-signaling-05 (work 634 in progress), September 2013. 636 [RFC6503] Barnes, M., Boulton, C., Romano, S., 637 and H. Schulzrinne, "Centralized 638 Conferencing Manipulation Protocol", 639 RFC 6503, March 2012. 641 Authors' Addresses 643 Roberta Presta 644 University of Napoli 645 Via Claudio 21 646 Napoli 80125 647 Italy 649 EMail: roberta.presta@unina.it 651 Simon Pietro Romano 652 University of Napoli 653 Via Claudio 21 654 Napoli 80125 655 Italy 657 EMail: spromano@unina.it