idnits 2.17.1 draft-romano-dcon-framework-12.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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 14, 2012) is 4123 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) == Unused Reference: 'RFC2234' is defined on line 852, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 858, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 4353 ** Obsolete normative reference: RFC 4582 (Obsoleted by RFC 8855) == Outdated reference: A later version (-12) exists of draft-romano-dcon-requirements-11 -- Possible downref: Normative reference to a draft: ref. 'I-D.romano-dcon-requirements' == Outdated reference: A later version (-12) exists of draft-romano-dcon-xdsp-reqs-11 -- Possible downref: Normative reference to a draft: ref. 'I-D.romano-dcon-xdsp-reqs' Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S P. Romano 3 Internet-Draft A. Amirante 4 Expires: June 17, 2013 University of Napoli 5 T. Castaldi 6 L. Miniero 7 Meetecho 8 A. Buono 9 Ansaldo Trasporti e Sistemi 10 Ferroviari 11 December 14, 2012 13 A Framework for Distributed Conferencing 14 draft-romano-dcon-framework-12 16 Abstract 18 This document defines the framework for Distributed Conferencing 19 (DCON). The framework draws inspiration from the work carried out in 20 the XCON working group, which has defined a complete architecture for 21 centralized conferencing. DCON is based on the idea that a 22 distributed conference can be setup by appropriately orchestrating 23 the operation of a number of XCON focus elements, each in charge of 24 managing a certain number of participants. Interaction between each 25 participant and the corresponding conference focus is based on the 26 standard XCON framework, whereas inter-focus interaction is defined 27 in this document. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on June 17, 2013. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 5. Towards Distributed Conferencing . . . . . . . . . . . . . . . 6 68 5.1. Setting up a distributed conferencing environment . . . . 8 69 5.2. Use-case scenarios and examples . . . . . . . . . . . . . 10 70 5.2.1. Creating a new distributed conference . . . . . . . . 10 71 5.2.2. Retrieving information about available conferences . . 11 72 5.2.3. Joining a conference hosted by a foreign island . . . 12 73 5.2.4. Dispatching XCON protocols in DCON . . . . . . . . . . 16 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 78 1. Introduction 80 This document presents an architecture capable to move the XCON 81 scenario towards a distributed framework. The requirements for DCON 82 are presented in a separate document [I-D.romano-dcon-requirements]. 83 In such an architecture a number of entities are used to manage 84 conference setup in the presence of clients which are distributed 85 across a geographical network. Each managing entity plays the role 86 of a conference focus as defined in the XCON working group documents 87 [RFC5239]. 89 Indeed, an XCON focus is in charge of managing a certain number of 90 clients falling under its own "realm". In order to move the XCON 91 scope towards a distributed environment, we introduce inter-focus 92 coordination, which is needed to effectively setup and manage 93 conference instantiation and coordination. As in the centralized 94 case, we define logical entities and naming conventions. An 95 appropriate data model for distributed conferencing will be defined 96 in a subsequent document and will extend, when needed, the XCON data 97 model [I-D.ietf-xcon-common-data-model]. Furthermore, we propose the 98 adoption of a suitable set of protocols which are complementary to 99 the call signaling protocols and are needed to support advanced 100 conferencing applications. 102 2. Conventions 104 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 105 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 106 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 107 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 108 levels for compliant implementations. 110 3. Terminology 112 Distributed conferencing uses, when appropriate, and expands on the 113 terminology introduced in the both the SIPPING [RFC4353] and XCON 114 conferencing frameworks. The following additional terms are defined 115 for specific use within the distributed conferencing context. 117 Conferencing Cloud: 119 A specific pair composed of a centralized focus entity (XCON) and 120 its associated distributed focus (DCON). We will herein 121 indifferently use both "cloud" and "island" to refer to a 122 conferencing cloud. 124 DCON Focus: 126 A specific entity enabling communication of a centralized 127 conferencing system with the outside world. A DCON focus allows 128 for the construction of a distributed conferencing system as a 129 federation of centralized conferencing components. 131 Focus Discovery: 133 The capability to detect the presence of new focus entities in a 134 distributed conferencing framework. 136 Information Spreading: 138 The spreading of conference related information among the focus 139 entities in a distributed environment. 141 Protocol Dispatching: 143 The capabilty to appropriately forward/distribute messages of a 144 natively centralized protocol in order to let them spread across a 145 distributed environment. 147 Label Swapping: 149 The opportune swap of labels assigned to a specific resource, 150 needed to avoid conflicts in the assignment of labels across 151 several point-to-point communications regarding the same resource. 153 4. Overview 155 In order to build distributed conferencing on top of the already 156 available centralized conferencing framework, we basically need to 157 introduce two major functions: (i) a coordination level among 158 conference focus entities; (ii) a way to effectively distribute 159 conference state information. As to the first point above, the 160 coordination level is needed in order to manage a distributed 161 conference along its entire life-cycle. For instance, once a user 162 decides to create a new conference, the corresponding conference 163 focus has to distribute conference information to all other foci, in 164 such a way as to enable other potential participants to retrieve the 165 needed data and possibly subscribe to the event. We herein assume 166 that all the operations needed inside a single conference cloud are 167 managed via the protocols and interfaces defined inside the XCON 168 working group. Hence, each single cloud keeps on being based on a 169 star-topology graph for all what concerns the call signaling part. 170 The various available stars are then connected through an upper-layer 171 mesh-based topology providing inter-focus communication. As depicted 172 in Figure 1, the overall topology of the distributed conferencing 173 scenario thus looks like an overlay network of focus entities, each 174 managing an underlying "centralized" conferencing island. In the 175 most general case, we envisage to exploit extended Instant Messaging 176 (IM) protocols for inter-focus communication. 178 o o o 179 \ | / 180 \ | / 181 +------+ 182 o---| XCON |---o 183 +---^--+ 184 | 185 +---v--+ 186 | DCON | 187 +------+ 188 // \\ 189 // \\ 190 // \\ 191 // \\ 192 // \\ 193 // \\ 194 // \\ 195 // \\ 196 // \\ 197 +------+ +------+ 198 | DCON |===================| DCON | 199 +---^--+ +---^--+ 200 | | 201 +---v--+ +---v--+ 202 o---| XCON |---o o---| XCON |---o 203 +------+ +------+ 204 / | \ / | \ 205 / | \ / | \ 206 o o o o o o 208 Figure 1: DCON architecture overview 210 As to the second point mentioned above, it looks clear that a way to 211 propagate information about conferences is needed when switching the 212 view from a centralized to a distributed perspective. Indeed, 213 whenever a new conference is created (or an active conference changes 214 its state) such an event has to be communicated to all interested (or 215 active) participants. Given the intrinsic nature of the distributed 216 framework (which actually expands the centralized one through the 217 introduction of an overlay network of focus entities), the actual 218 flow of information will always foresee the interaction among 219 conference focus entities for both conference information exchanging 220 and state changes notifications. The same obviously applies also to 221 the involved natively centralized protocols defined in the XCON 222 framework. A suitable mechanism has to be defined allowing for the 223 dispatching of such centralized messages across the DCON network. 224 The mechanism in question must be fully compliant with the existing 225 operation of XCON clouds, which must keep their local participants 226 totally unaware of the potential distributed nature of conferences. 228 Conference state propagation can take place in a number of 229 alternative ways. For instance, each focus might flood the received 230 information across the inter-focus communication mesh, thus 231 guaranteeing that potential participants belonging to heterogeneous 232 islands can be reached. In such case, focus entities are "stateful", 233 i.e. each of them stores information about current sessions and 234 forwards such information to all peering entities in order to get 235 them up-to-date with respect to available conference sessions. 237 On the other hand, a distributed repository might be employed for the 238 sake of storing conference information. Focus entities would access 239 such repository, both to publish (either upon creation of a new 240 conference, or to notify a change in the state of an active 241 conference) and to retrieve information about active conferences 242 (e.g. when a new participant wants to access the list of ongoing/ 243 scheduled conference sessions he might be interested to join). In 244 this last case, focus entities are "stateless". 246 Finally, a pure peer-to-peer approach can also be exploited for the 247 purpose of conference state information spreading. 249 5. Towards Distributed Conferencing 251 In this section we first describe the overall architecture of a 252 distributed conferencing framework, by highlighting both the involved 253 entities and their interrelations. Then, we delve into the details 254 of some key use cases which help understand the typical interaction 255 paradigm of a decentralized environment. 257 As to the architecture, Figure 2 depicts how various XCON islands 258 (just two in the picture to avoid confusion) can interact through the 259 exchanging of synchronization messages between each pair of 260 conferencing systems. Such messages are needed in order to circulate 261 conference information among all involved entities. A dedicated 262 protocol is obviously needed to take care of the communication 263 between each pair: since its task is to synchronize the XCON and DCON 264 pair, it will from now on be called XCON-DCON Synchronization 265 Protocol (XDSP). The requirements for this protocol are further 266 analyzed in a companion draft [I-D.romano-dcon-xdsp-reqs]. 268 Inter-island coordination can be achieved via a number of available 269 solutions (e.g. SIP/SIMPLE, XMPP). In this document we propose the 270 exploitation of IM-based interaction. More precisely, we think that 271 the Server-to-Server (S2S) module based on the XMPP protocol 272 perfectly satisfies the requirements imposed by the new architecture. 274 Finally, media streams will directly flow between the XCON clouds 275 once a distributed conference has been setup. Distributed mixing, 276 however, will be only marginally discussed in this draft, in favour 277 of the distribution of signaling and control messages. 279 +-DCON-----------+ +-DCON-----------+ 280 | +------------+ | | +------------+ | 281 | | Dispatcher | <=== Inter-focus communication ===> | Dispatcher | | 282 | +------------+ | | +------------+ | 283 +----------^-----+ +----^-----------+ 284 ^ | | ^ 285 | | XDSP XDSP | | 286 | | | | 287 +---|-------|----XCON-+ +-XCON---|--------|---+ 288 | | +-v-------+ | | +------v--+ | | 289 | | | Gateway | | | | Gateway | | | 290 | | +--^---^--+ | | +--^---^--+ | | 291 | | BFCP| |CCP | | CCP| |BFCP | | 292 | | | | | | | | | | 293 | | +--v---v--+ | | +--v---v--+ | | 294 | +-----o Conf. | | | | Conf. o-----+ | 295 | Notify | Object |<======= Media Flow ========>| Object | Notify | 296 | | | | | | | | 297 | +---------+ | | +---------+ | 298 +---------------------+ +---------------------+ 300 XCON Cloud 1 XCON Cloud 2 302 Figure 2: Distributed conferencing framework 304 5.1. Setting up a distributed conferencing environment 306 In the following we are going to describe the typically required 307 steps to setup a distributed conferencing environment. As described 308 in the introductory sections, an overlay network of focus entities, 309 each managing an underlying "centralized" conferencing island, will 310 be needed, and the following points will help clarify how to 311 effectively setup a distributed conferencing and manage it. 313 1. Overlay Creation and Management 315 To enable effective operation of the distributed conferencing 316 framework, an overlay network made of all interconnected 317 conferencing clouds MUST be created. As an example, the 318 mentioned overlay MAY be built by interconnecting all focus 319 entities (with each such entity being the root of a local 320 centralized conferencing cloud) through a full-meshed topology. 321 Once the overlay is created, appropriate management of its 322 structure SHOULD be envisaged; this includes, for example, 323 dynamic updating of the topology information at the occurrence 324 of relevant events (grafting/pruning of new centralized 325 conferencing islands, etc.). 327 2. Focus Discovery 329 An appropriate mechanism for the discovery of peering focus 330 entities SHOULD be provided. Given the sensitive nature of the 331 shared information, an appropriate authentication mechanism 332 SHOULD be adopted. The trigger of the discovery process MAY be 333 related to the concept of "presence"; in such case, an Instant 334 Messaging (IM) based paradigm is RECOMMENDED. Alternatively, a 335 logically centralized, physically distributed repository (e.g. 336 UDDI) MAY be employed as a single reference point for the 337 discovery of peering entities. A pure peer-to-peer approach can 338 also be exploited for the same purpose. 340 3. Self-configuration 342 At the occurrence of events like the grafting of a new cloud 343 onto the overlay distributed conferencing network, the needed 344 configuration steps SHOULD be performed in an automated fashion. 345 This entails that all the news are appropriately exchanged 346 across the overlay and, if needed, notified to the underlying 347 centralized clouds as well. 349 4. Information Sharing 351 The core of the operation of a distributed conferencing 352 framework resides in the possibility to exchange information 353 among all involved entities. The information sharing process 354 SHOULD be made as effective as possible, e.g. by limiting the 355 information that is forwarded outside a single centralized 356 conferencing cloud to the data that are strictly necessary in 357 order to guarantee that the overall state of the overaly is 358 consistent, yet not redundant. Information sharing MAY be 359 achieved either by exploiting a request/response paradigm, or 360 through the adoption of asynchronous notification messages. A 361 combined use of both the aforementioned paradigms is 362 RECOMMENDED. 364 5. Dynamic Update 366 All the clouds participating in the distributed overlay MUST 367 keep the peers updated with respect to worth-noting events 368 happening in their local realm. This MAY be achieved either by 369 exploiting a request/response paradigm, or through the adoption 370 of asynchronous notification messages. A combined use of both 371 the aforementioned paradigms is RECOMMENDED. A pure peer-to- 372 peer approach can also be exploited for the same purpose. 374 6. Distributed Conference Management 376 In order to allow users' access to remotely created conferences, 377 appropriate mechanisms MUST be provided by the framework. Such 378 mechanisms SHOULD enable transparent management of both locally- 379 and remotely-created conference instances. A pure peer-to-peer 380 approach can be exploited for the same purpose. 382 7. Centralized Protocols Routing and Dispatching 384 Focus entities MUST forward any centralized protocol message to 385 their related peer in the distributed overlay whenever the 386 message is directed to a receiver who does not belong to the 387 local centralized system. Natively centralized protocol 388 messages include, but are not limited to, any protocol defined 389 and specified in the XCON framework (e.g. conference control 390 management and floor control) as well as DTMF messages 391 propagation. An example could be BFCP [RFC4582] messages the 392 local floor control server might need to send to a user who is 393 remotely participating in the conference (because she/he does 394 not belong to the current XCON cloud). Another example concerns 395 BFCP messages a local user might send to the remote floor 396 control server handling the remote distributed conference she/he 397 is involved in. Any message sent by local entities to local 398 entities has to be treated in the usual centralized way 399 according to the relative protocol specifications (i.e. 400 dispatching shall not be involved). 402 8. Distributed Mixing 404 As soon as two or more centralized conferencing islands get 405 connected in order to provide for a distributed conferencing 406 scenario, the need arises to cope with the issue of mixing media 407 flows generated by the conference participants. This 408 challenging issue is currently considered out-of-scope in this 409 document, which mainly focuses on the distribution of conference 410 signalling/control information rather than addressing media 411 management. 413 5.2. Use-case scenarios and examples 415 In this subsection we provide some examples of the operation of the 416 distributed conferencing framework. 418 5.2.1. Creating a new distributed conference 420 Figure 3 illustrates how a distributed conference can be created and 421 managed in a distributed environment. A participant contacts its 422 corresponding focus entity in order to request the creation of a new 423 conference instance. With respect to the centralized scenario, upon 424 conference instantiation, in this case the focus has to publish 425 conference information by notifying its related DCON focus. This is 426 done in order to allow other remote focus entities to get up-to-date 427 information about available conferencing sessions. 429 Client XCON DCON 430 | | | 431 | Request creation of | | 432 | a new XCON conference | | 433 |------------------------>| | 434 | |--+ Schedule | 435 | | | new XCON | 436 | |<-+ conference | 437 | | | 438 | | Notify scheduling | 439 | | of new conference | 440 | |---------------------->| 441 | | |--+ Manage 442 | | | | new XCON 443 | | |<-+ conference 444 | | | 445 | | | Spread new 446 | | | information 447 | | |--------> ~~~ 448 . . . 449 . . . 451 Figure 3: Creating a new conference 453 5.2.2. Retrieving information about available conferences 455 Figure 4 illustrates how information about available centralized and 456 distributed conferences can be retrieved. A participant contacts its 457 corresponding focus entity in order to request the above information. 458 With respect to the centralized scenario, upon reception of a 459 participant's request, the XCON focus has to forward the request to 460 the related DCON focus. It will be up to the distributed focus 461 entity to provide such information, which will include the list of 462 both centralized (local) and distributed (remote) conferences. This 463 way, a participant will be able to transparently keep on contacting 464 the XCON focus to get all the information she/he needs in both cases. 466 Client XCON DCON 467 | | | 468 | Request list of | | 469 | available conferences | | 470 |------------------------>| | 471 | |--+ Process | 472 | | | client's | 473 | |<-+ request | 474 | | | 475 | | Forward request | 476 | | to DCON focus | 477 | |----------------------->| 478 | | |--+ Process 479 | | | | forwarded 480 | | |<-+ request 481 | | Send conferences list | 482 | Send conferences list |<-----------------------| 483 |<------------------------| | 484 . . . 485 . . . 487 Figure 4: Retrieving information about available conferences 489 5.2.3. Joining a conference hosted by a foreign island 491 Figure 5 illustrates how a participant can join a conference which is 492 managed by a focus entity belonging to a foreign centralized island. 493 The whole sequence diagram has been split in three parts to better 494 help understanding all the required steps. A participant contacts 495 its corresponding focus entity in order to send the join request. 496 With respect to the centralized scenario, upon reception of the 497 participant's request, the local focus has to forward join 498 information to the focus entity belonging to the island in which the 499 conference in question was created. 501 The following steps are performed in sequence: 503 1. once the client has locally joined the distributed conference by 504 placing a SIP call to the focus she/he belongs to (XCON (A)), the 505 focus chooses a new label for the client (A) which will be needed 506 to opportunely dispatch all the messages related to her/him; 508 2. XCON (A) at this point forwards the join request to its related 509 DCON focus entity (DCON (A)); in this example this is done by 510 sending, through the XDSP protocol, a message called AddUser 511 containing the newly assigned client's label A; 513 3. DCON (A) receives the join request; since it regards a new 514 client, the DCON focus entity chooses a new label (e.g. XYZ) and 515 associates it with the just received label A; depending on the 516 distributed conference the client wants to join, it associates 517 the label (XYZ) with the DCON focus entity managing the XCON 518 focus physically hosting the conference (DCON (B)) and forwards 519 the join request to it; 521 4. DCON (B) receives the forwarded message through the XMPP-based 522 S2S channel; since it regards a new client, DCON (B) chooses a 523 new label (e.g. B) and associates it with the just received 524 label XYZ; since the conference the remote client (A) wants to 525 join is physically hosted by XCON (B), the join request is 526 forwarded there using the XDSP protocol, with an AddUser message 527 containing the newly assigned label B which identifies the remote 528 client; 530 5. XCON (B) receives the request, and thus associates the received 531 label B with the remote Client (A); all the operations needed to 532 add the new user to the conference are performed, and the new 533 information is sent back to the client through the same path. 534 All the involved labels (B, XYZ, A) will be opportunely swapped 535 to route all the XCON protocols messages between the two 536 entities. 538 Once XCON (A) receives the confirmation that the user has been 539 successfully added to the remote conference, together with the needed 540 information, the client (A) is updated through a SIP REINVITE 541 containing the BFCP information she/he will need to communicate with 542 the Floor Control Server. All BFCP messages sent from now on by the 543 client to the Floor Control Server will be intercepted by the 544 gateway, and then forwarded to the Floor Control Server of XCON (B). 545 This case will be furtherly presented and discussed in the next 546 section. 548 Client(A) XCON(A) DCON(A) DCON(B) 549 | | | | 550 | SIP INVITE | | | 551 |-------------------->| | | 552 | SIP Trying | | | 553 |<--------------------| | | 554 | SIP OK | | | 555 |<--------------------| | | 556 | SIP ACK | | | 557 |-------------------->| | | 558 | |--+ Choose a | | 559 | | | Label (A) | | 560 | |<-+ for new user | | 561 | | | | 562 | | AddUser (A) | | 563 | |---------------->| | 564 | | |--+ Choose a Label | 565 | | | | (XYZ) and find | 566 | | | | destination | 567 | | |<-+ (DCON (B)) | 568 | | | | 569 | | |--+ Label | 570 | | | | Swap | 571 | | |<-+ (A=>XYZ) | 572 | | | | 573 | | | XMPP (AddUser) | 574 | | |---- ~~(S2S)~~ ---->| 575 | | | | 576 . . . . 577 . . . . 579 DCON(A) DCON(B) XCON(B) 580 . . . 581 . . . 582 | | | 583 |--+ Label | | 584 | | Swap | | 585 |<-+ (A=>XYZ) | | 586 | | | 587 | XMPP (AddUser) | | 588 |--- ~~(S2S)~~ --->| | 589 | |--+ Choose a | 590 | | | Label (B) | 591 | |<-+ for new user | 592 | | | 593 | | AddUser | 594 | |------------------->| 595 | | |--+ Assign new 596 | | | | User ID 597 | | | | to remote 598 | | |<-+ participant 599 | | UserAdded (B) | 600 | |<-------------------| 601 | Label +--| | 602 | Swap | | | 603 | (B=>XYZ) +->| | 604 | | | 605 | XMPP (UserAdded) | | 606 |<--- ~~(S2S)~~ ---| | 607 Label +--| | | 608 Swap | | | | 609 (XYZ=>A) +->| | | 610 | | | 611 . . . 612 . . . 614 Client(A) XCON(A) DCON(A) DCON(B) 615 . . . . 616 . . . . 617 | | | | 618 | | | XMPP (UserAdded) | 619 | | |<---- ~~(S2S)~~ ----| 620 | | Label +--| | 621 | | Swap | | | 622 | | (XYZ=>A) +->| | 623 | | | | 624 | | UserAdded (A) | | 625 | |<----------------| | 626 | Manage received +--| | | 627 | info on new user | | | | 628 | (e.g. IDs) +->| | | 629 | | | | 630 | | | | 631 |SIP REINVITE (+BFCP) | | | 632 |<--------------------| | | 633 | SIP Trying | | | 634 |-------------------->| | | 635 | SIP OK | | | 636 |-------------------->| | | 637 | SIP ACK | | | 638 |<--------------------| | | 639 | | | | 640 . . . . 641 . . . . 642 . . . . 644 Figure 5: Joining a foreign conference 646 5.2.4. Dispatching XCON protocols in DCON 648 Figure 6 illustrates how natively centralized XCON protocols (BFCP, 649 in the figure) can be opportunely dispatched in order to let them 650 spread across a distributed environment. Such mechanism would allow 651 users participating in distributed conferences to avoid knowing the 652 transport addresses needed to communicate with remote focus entities, 653 and to keep transparently referring to the local focus entity 654 instead. 656 In order to understand who the actual receiver of a message shall be, 657 all messages are intercepted by a logical entity, called Gateway, 658 belonging to the XCON focus. The Gateway will understand whether a 659 message is directed to a local entity (e.g. a user belonging to the 660 XCON focus, or the local Floor Control Server) or to a remote entity 661 belonging to another focus (e.g. a remotely participating user, or a 662 remote Floor Control Server). 664 +---------------------------------------------------------+ 665 | Client 1: Label A (Server Leg: FCS) | 666 | Client 2: Label B (Server Leg: Remote FCS-->Dispatcher) | 667 | Client 3: Label C (Server Leg: FCS) | 668 +---------------------------------------------------------+ 670 +--DCON-------------+ 671 | | 672 | +------------+ | 673 | | Dispatcher |<=== (BFCP: Label Swap) ===...> 674 | +------------+ | 675 +-------------^-----+ 676 | 677 | XDSP Message: Label B 678 | (BFCP encoded in Base64) 679 | 680 +-----|-------------------XCON--+ 681 | | | 682 | +--- Notify (B) ---+ | 683 | | | | 684 +----------+ | v v | 685 | Client 1 |<---+ | +---------+ +---------+ | 686 +----------+ | | | Floor |<--A-->| Floor | | 687 +-A------>| Control | | Control | | 688 +~~~~~~~~~~+ | | Server |<--C-->| Server | | 689 i Client 2 i<------B----->| Gateway | +---------+ | 690 +~~~~~~~~~~+ | +---------+ | 691 +---^---------------------------+ 692 +----------+ | 693 | Client 3 |<-------C-------+ 694 +----------+ 696 Figure 6: Centralized protocols dispatching 698 To make the whole thing clearer, the example in figure Figure 7 will 699 be used. As in the previous case, the whole sequence diagram has 700 been split in three parts to better help understand all the required 701 steps. In this example, a user (Client (A)) belonging to XCON (A) is 702 remotely participating to a distributed conference hosted by XCON 703 (B). Since XCON (B) is physically hosting the conference, floor 704 control will be entirely managed by its Floor Control Server. To 705 allow Client (A) to communicate with Floor Control Server (B) and 706 viceversa, appropriate dispatching of BFCP messages between the two 707 peers will be needed. We have already seen how labels are assigned 708 and swapped: the same labels will be used for dispatching. 710 The flow of a typical message exchange can be seen as follows: 712 1. The Client (A) sends a BFCP message to the Floor Control Server; 713 the message is intercepted by XCON (A)'s gateway; the label 714 assigned to client (A) is retrieved, and used to forward the BFCP 715 message to the DCON (A) Dispatcher; of course, since BFCP 716 messages are binary, an opportune treatment (e.g. through Base64 717 encoding) should be done to encapsulate the message in a text- 718 based protocol message (as XDSP will probably be); 720 2. Once DCON (A) receives the encapsulated BFCP message, the labels 721 are opportunely swapped (in this case, A=>XYZ) and the message is 722 routed to the right destination (DCON (B)); 724 3. DCON (B) will receive the message and swap labels again (XYZ=>B); 725 at this point, the encapsulated message will be forwarded to the 726 underlying XCON (B) Gateway to be further processed there; 728 4. The XCON (B) Gateway will receive the encapsulated (and probably 729 Base64-encoded) BFCP message; after decoding it (if needed), the 730 Gateway will analyze the label marked in the message (B, in this 731 case), and will understand it is a message sent by a remote user 732 (Client (A)) to the local Floor Control Server. It will forward 733 the (now 'natively' binary) message there, where it will be 734 processed; 736 5. In case the FCS (B) needs to send a message to Client (A), 737 exactly the same operations will be performed, and the same path 738 will be followed through the needed label swaps among the 739 involved peers. FCS (A), while not actually managing the floors 740 related to the remote conference Client (A) is participanting in, 741 will however be notified upon each floor status change, so to 742 opportunely update the local media mixes when needed (e.g. to 743 mute Client (A) excluding her/him from XCON (A)'s local mix if 744 FCS (B) has decided so). 746 Client(A) XCON(A) DCON(A) DCON(B) 747 | (Gateway) | | 748 | | | | 749 | BFCP Message | | | 750 |------------------->| | | 751 | |--+ Get Label (A) | | 752 | | | assigned to | | 753 | |<-+ client/FCS | | 754 | | | | 755 | | BFCP encoded | | 756 | | in Base64 | | 757 | |--(Label A)-------->| | 758 | | |--+ Label | 759 | | | | Swap | 760 | | |<-+ (A=>XYZ) | 761 | | | | 762 | | |--+ Get destination | 763 | | | | from label XYZ | 764 | | |<-+ (DCON B) | 765 | | | | 766 | | | XMPP | 767 | | | (BFCP in Base64) | 768 | | |---- ~~(S2S)~~ --->| 769 | | | | 770 . . . . 771 . . . . 773 DCON(A) DCON(B) XCON(B) XCON(B) 774 | | (Gateway) (FCS) 775 . . . . 776 . . . . 777 | XMPP | | | 778 | (BFCP in Base64) | | | 779 |--- ~~(S2S)~~ ---->| | | 780 | | | | 781 | |--+ Label | | 782 | | | Swap | | 783 | |<-+ (XYZ=>B) | | 784 | | | | 785 | | BFCP encoded | | 786 | | in Base64 | | 787 | |-----(Label B)---->| | 788 | | |--+ Check Label (B)| 789 | | | | assigned to | 790 | | |<-+ FCS/client | 791 | | | | 792 | | | BFCP Message | 793 | | |------------------>| 794 . . . . 795 . . . . 796 | | | BFCP Message | 797 | | |<------------------| 798 | | Get Label (B) +--| | 799 | | assigned to | | | 800 | | FCS/client +->| | 801 | | | | 802 | | BFCP encoded | | 803 | | in Base64 | | 804 | |<-----(Label B)----| | 805 | Label +--| | | 806 | Swap | | | | 807 | (B=>XYZ) +->| | | 808 | | | | 809 | Get destination +--| | | 810 | from label XYZ | | | | 811 | (DCON A) +->| | | 812 | | | | 813 | XMPP | | | 814 | (BFCP in Base64) | | | 815 |<--- ~~(S2S)~~ ----| | | 816 | | | | 817 . . . . 818 . . . . 820 Client(A) XCON(A) DCON(A) DCON(B) 821 | (Gateway) | | 822 | | | | 823 | | | XMPP | 824 | | | (BFCP in Base64) | 825 | | |<---- ~~(S2S)~~ ---| 826 | | Label +--| | 827 | | Swap | | | 828 | | (XYZ=>A) +->| | 829 | | | | 830 | | BFCP encoded | | 831 | | in Base64 | | 832 | |<---------(Label A)-| | 833 | Check Label (A) +--| | | 834 | assigned to | | | | 835 | client/FCS +->| | | 836 | | | | 837 | BFCP Message | | | 838 |<-------------------| | | 839 | | | | 840 . . . . 841 . . . . 842 . . . . 844 Figure 7: An example: dispatching a BFCP message 846 6. Security Considerations 848 TBD... 850 7. References 852 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 853 Specifications: ABNF", RFC 2234, November 1997. 855 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 856 Requirement Levels", BCP 14, RFC 2119, March 1997. 858 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 859 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 860 October 1998. 862 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 863 Session Initiation Protocol (SIP)", RFC 4353, 864 February 2006. 866 [RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor 867 Control Protocol (BFCP)", RFC 4582, November 2006. 869 [I-D.romano-dcon-requirements] 870 Romano, S., Amirante, A., Castaldi, T., Miniero, L., and 871 A. Buono, "Requirements for Distributed Conferencing", 872 draft-romano-dcon-requirements-11 (work in progress), 873 June 2012. 875 [I-D.romano-dcon-xdsp-reqs] 876 Romano, S., Amirante, A., Castaldi, T., Miniero, L., and 877 A. Buono, "Requirements for the XCON-DCON Synchronization 878 Protocol", draft-romano-dcon-xdsp-reqs-11 (work in 879 progress), June 2012. 881 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for 882 Centralized Conferencing", RFC 5239, June 2008. 884 [I-D.ietf-xcon-common-data-model] 885 Morgan, D., Camarillo, G., Urpalainen, J., and O. Novo, 886 "Conference Information Data Model for Centralized 887 Conferencing (XCON)", draft-ietf-xcon-common-data-model-32 888 (work in progress), September 2011. 890 Authors' Addresses 892 Simon Pietro Romano 893 University of Napoli 894 Via Claudio 21 895 Napoli 80125 896 Italy 898 Email: spromano@unina.it 900 Alessandro Amirante 901 University of Napoli 902 Via Claudio 21 903 Napoli 80125 904 Italy 906 Email: alessandro.amirante@unina.it 908 Tobia Castaldi 909 Meetecho 910 Via Carlo Poerio 89 911 Napoli 80100 912 Italy 914 Email: tcastaldi@meetecho.com 916 Lorenzo Miniero 917 Meetecho 918 Via Carlo Poerio 89 919 Napoli 80100 920 Italy 922 Email: lorenzo@meetecho.com 924 Alfonso Buono 925 Ansaldo Trasporti e Sistemi Ferroviari 926 Via Argine, 425 927 Napoli 80147 928 Italy 930 Email: alfonso.buono@atsf.it