TOC 
Network Working GroupS P. Romano
Internet-DraftA. Amirante
Expires: July 26, 2008T. Castaldi
 L. Miniero
 University of Napoli
 A. Buono
 CRIAI Consortium
 January 23, 2008


A Framework for Distributed Conferencing
draft-romano-dcon-framework-02.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on July 26, 2008.

Abstract

This document defines the framework for Distributed Conferencing (DCON). The framework draws inspiration from the work carried out in the XCON working group, which has defined a complete architecture for centralized conferencing. DCON is based on the idea that a distributed conference can be setup by appropriately orchestrating the operation of a number of XCON focus elements, each in charge of managing a certain number of participants. Interaction between each participant and the corresponding conference focus is based on the standard XCON framework, whereas inter-focus interaction is defined in this document.


Table of Contents

1.  Introduction
2.  Conventions
3.  Terminology
4.  Overview
5.  Towards Distributed Conferencing
    5.1.  Setting up a distributed conferencing environment
    5.2.  Use-case scenarios and examples
        5.2.1.  Creating a new distributed conference
        5.2.2.  Retrieving information about available conferences
        5.2.3.  Joining a conference hosted by a foreign island
        5.2.4.  Dispatching XCON protocols in DCON
6.  Security Considerations
7.  References
    7.1.  References
    7.2.  Informational References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements



 TOC 

1.  Introduction

This document presents an architecture capable to move the XCON scenario towards a distributed framework. The requirements for DCON are presented in a separate document [I‑D.romano‑dcon‑requirements] (Romano, S., Amirante, A., Castaldi, T., Miniero, L., and A. Buono, “Requirements for Distributed Conferencing,” January 2010.). In such an architecture a number of entities are used to manage conference setup in the presence of clients which are distributed across a geographical network. Each managing entity plays the role of a conference focus as defined in the XCON working group documents [I‑D.ietf‑xcon‑framework] (Barnes, M., Boulton, C., and O. Levin, “A Framework for Centralized Conferencing,” April 2008.).

Indeed, an XCON focus is in charge of managing a certain number of clients falling under its own "realm". In order to move the XCON scope towards a distributed environment, we introduce inter-focus coordination, which is needed to effectively setup and manage conference instantiation and coordination. As in the centralized case, we define logical entities and naming conventions. An appropriate data model for distributed conferencing will be defined in a subsequent document and will extend, when needed, the XCON data model [I‑D.ietf‑xcon‑common‑data‑model] (Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, “Conference Information Data Model for Centralized Conferencing (XCON),” February 2010.). Furthermore, we propose the adoption of a suitable set of protocols which are complementary to the call signaling protocols and are needed to support advanced conferencing applications.


 TOC 

2.  Conventions

In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) and indicate requirement levels for compliant implementations.


 TOC 

3.  Terminology

Distributed conferencing uses, when appropriate, and expands on the terminology introduced in the both the SIPPING [RFC4353] (Rosenberg, J., “A Framework for Conferencing with the Session Initiation Protocol (SIP),” February 2006.) and XCON conferencing frameworks. The following additional terms are defined for specific use within the distributed conferencing context.



Conferencing Cloud:

A specific pair composed of a centralized focus entity (XCON) and its associated distributed focus (DCON). We will herein indifferently use both "cloud" and "island" to refer to a conferencing cloud.

DCON Focus:

A specific entity enabling communication of a centralized conferencing system with the outside world. A DCON focus allows for the construction of a distributed conferencing system as a federation of centralized conferencing components.

Focus Discovery:

The capability to detect the presence of new focus entities in a distributed conferencing framework.

Information Spreading:

The spreading of conference related information among the focus entities in a distributed environment.

Protocol Dispatching:

The capabilty to appropriately forward/distribute messages of a natively centralized protocol in order to let them spread across a distributed environment.

Label Swapping:

The opportune swap of labels assigned to a specific resource, needed to avoid conflicts in the assignment of labels across several point-to-point communications regarding the same resource.

 TOC 

4.  Overview

In order to build distributed conferencing on top of the already available centralized conferencing framework, we basically need to introduce two major functions: (i) a coordination level among conference focus entities; (ii) a way to effectively distribute conference state information. As to the first point above, the coordination level is needed in order to manage a distributed conference along its entire life-cycle. For instance, once a user decides to create a new conference, the corresponding conference focus has to distribute conference information to all other foci, in such a way as to enable other potential participants to retrieve the needed data and possibly subscribe to the event. We herein assume that all the operations needed inside a single conference cloud are managed via the protocols and interfaces defined inside the XCON working group. Hence, each single cloud keeps on being based on a star-topology graph for all what concerns the call signaling part. The various available stars are then connected through an upper-layer mesh-based topology providing inter-focus communication. As depicted in Figure 1 (DCON architecture overview), the overall topology of the distributed conferencing scenario thus looks like an overlay network of focus entities, each managing an underlying "centralized" conferencing island. In the most general case, we envisage to exploit extended Instant Messaging (IM) protocols for inter-focus communication. 




                o      o     o
                 \     |    /
                  \    |   /
                   +------+
               o---| XCON |---o
                   +---^--+
                       |
                   +---v--+
                   | DCON |
                   +------+
                 //        \\
                //          \\
               //            \\
              //              \\
             //                \\
            //                  \\
           //                    \\
          //                      \\
         //                        \\
     +------+                   +------+
     | DCON |===================| DCON |
     +---^--+                   +---^--+
         |                          |
     +---v--+                   +---v--+
 o---| XCON |---o           o---| XCON |---o
     +------+                   +------+
    /    |   \                 /    |   \
   /     |    \               /     |    \
  o      o     o             o      o     o
 Figure 1: DCON architecture overview 

As to the second point mentioned above, it looks clear that a way to propagate information about conferences is needed when switching the view from a centralized to a distributed perspective. Indeed, whenever a new conference is created (or an active conference changes its state) such an event has to be communicated to all interested (or active) participants. Given the intrinsic nature of the distributed framework (which actually expands the centralized one through the introduction of an overlay network of focus entities), the actual flow of information will always foresee the interaction among conference focus entities for both conference information exchanging and state changes notifications. The same obviously applies also to the involved natively centralized protocols defined in the XCON framework. A suitable mechanism has to be defined allowing for the dispatching of such centralized messages across the DCON network. The mechanism in question must be fully compliant with the existing operation of XCON clouds, which must keep their local participants totally unaware of the potential distributed nature of conferences.

Conference state propagation can take place in a number of alternative ways. For instance, each focus might flood the received information across the inter-focus communication mesh, thus guaranteeing that potential participants belonging to heterogeneous islands can be reached. In such case, focus entities are "stateful", i.e. each of them stores information about current sessions and forwards such information to all peering entities in order to get them up-to-date with respect to available conference sessions.

On the other hand, a distributed repository might be employed for the sake of storing conference information. Focus entities would access such repository, both to publish (either upon creation of a new conference, or to notify a change in the state of an active conference) and to retrieve information about active conferences (e.g. when a new participant wants to access the list of ongoing/scheduled conference sessions he might be interested to join). In this last case, focus entities are "stateless".

Finally, a pure peer-to-peer approach can also be exploited for the purpose of conference state information spreading.


 TOC 

5.  Towards Distributed Conferencing

In this section we first describe the overall architecture of a distributed conferencing framework, by highlighting both the involved entities and their interrelations. Then, we delve into the details of some key use cases which help understand the typical interaction paradigm of a decentralized environment.

As to the architecture, Figure 2 (Distributed conferencing framework) depicts how various XCON islands (just two in the picture to avoid confusion) can interact through the exchanging of synchronization messages between each pair of conferencing systems. Such messages are needed in order to circulate conference information among all involved entities. A dedicated protocol is obviously needed to take care of the communication between each pair: since its task is to synchronize the XCON and DCON pair, it will from now on be called XCON-DCON Synchronization Protocol (XDSP). The requirements for this protocol are further analyzed in a companion draft [I‑D.romano‑dcon‑xdsp‑reqs] (Romano, S., Amirante, A., Castaldi, T., Miniero, L., and A. Buono, “Requirements for the XCON-DCON Synchronization Protocol,” January 2010.).

Inter-island coordination can be achieved via a number of available solutions (e.g. SIP/SIMPLE, XMPP). In this document we propose the exploitation of IM-based interaction. More precisely, we think that the Server-to-Server (S2S) module based on the XMPP protocol perfectly satisfies the requirements imposed by the new architecture.

Finally, media streams will directly flow between the XCON clouds once a distributed conference has been setup. Distributed mixing, however, will be only marginally discussed in this draft, in favour of the distribution of signaling and control messages. 




 +-DCON-----------+                                 +-DCON-----------+
 | +------------+ |                                 | +------------+ |
 | | Dispatcher | <=== Inter-focus communication ===> | Dispatcher | |
 | +------------+ |                                 | +------------+ |
 +----------^-----+                                 +----^-----------+
    ^       |                                            |        ^
    |       | XDSP                                  XDSP |        |
    |       |                                            |        |
+---|-------|----XCON-+                         +-XCON---|--------|---+
|   |     +-v-------+ |                         | +------v--+     |   |
|   |     | Gateway | |                         | | Gateway |     |   |
|   |     +--^---^--+ |                         | +--^---^--+     |   |
|   |    BFCP|   |CCP |                         | CCP|   |BFCP    |   |
|   |        |   |    |                         |    |   |        |   |
|   |     +--v---v--+ |                         | +--v---v--+     |   |
|   +-----o Conf.   | |                         | | Conf.   o-----+   |
|  Notify | Object  |<======= Media Flow ========>| Object  | Notify  |
|         |         | |                         | |         |         |
|         +---------+ |                         | +---------+         |
+---------------------+                         +---------------------+

    XCON Cloud 1                                      XCON Cloud 2
 Figure 2: Distributed conferencing framework 

 TOC 

5.1.  Setting up a distributed conferencing environment

In the following we are going to describe the typically required steps to setup a distributed conferencing environment. As described in the introductory sections, an overlay network of focus entities, each managing an underlying "centralized" conferencing island, will be needed, and the following points will help clarify how to effectively setup a distributed conferencing and manage it.




  1. Overlay Creation and Management

    To enable effective operation of the distributed conferencing framework, an overlay network made of all interconnected conferencing clouds MUST be created. As an example, the mentioned overlay MAY be built by interconnecting all focus entities (with each such entity being the root of a local centralized conferencing cloud) through a full-meshed topology. Once the overlay is created, appropriate management of its structure SHOULD be envisaged; this includes, for example, dynamic updating of the topology information at the occurrence of relevant events (grafting/pruning of new centralized conferencing islands, etc.).


  2. Focus Discovery

    An appropriate mechanism for the discovery of peering focus entities SHOULD be provided. Given the sensitive nature of the shared information, an appropriate authentication mechanism SHOULD be adopted. The trigger of the discovery process MAY be related to the concept of "presence"; in such case, an Instant Messaging (IM) based paradigm is RECOMMENDED. Alternatively, a logically centralized, physically distributed repository (e.g. UDDI) MAY be employed as a single reference point for the discovery of peering entities. A pure peer-to-peer approach can also be exploited for the same purpose.


  3. Self-configuration

    At the occurrence of events like the grafting of a new cloud onto the overlay distributed conferencing network, the needed configuration steps SHOULD be performed in an automated fashion. This entails that all the news are appropriately exchanged across the overlay and, if needed, notified to the underlying centralized clouds as well.


  4. Information Sharing

    The core of the operation of a distributed conferencing framework resides in the possibility to exchange information among all involved entities. The information sharing process SHOULD be made as effective as possible, e.g. by limiting the information that is forwarded outside a single centralized conferencing cloud to the data that are strictly necessary in order to guarantee that the overall state of the overaly is consistent, yet not redundant. Information sharing MAY be achieved either by exploiting a request/response paradigm, or through the adoption of asynchronous notification messages. A combined use of both the aforementioned paradigms is RECOMMENDED.


  5. Dynamic Update

    All the clouds participating in the distributed overlay MUST keep the peers updated with respect to worth-noting events happening in their local realm. This MAY be achieved either by exploiting a request/response paradigm, or through the adoption of asynchronous notification messages. A combined use of both the aforementioned paradigms is RECOMMENDED. A pure peer-to-peer approach can also be exploited for the same purpose.


  6. Distributed Conference Management

    In order to allow users' access to remotely created conferences, appropriate mechanisms MUST be provided by the framework. Such mechanisms SHOULD enable transparent management of both locally- and remotely-created conference instances. A pure peer-to-peer approach can be exploited for the same purpose.


  7. Centralized Protocols Routing and Dispatching

    Focus entities MUST forward any centralized protocol message to their related peer in the distributed overlay whenever the message is directed to a receiver who does not belong to the local centralized system. Natively centralized protocol messages include, but are not limited to, any protocol defined and specified in the XCON framework (e.g. conference control management and floor control) as well as DTMF messages propagation. An example could be BFCP [RFC4582] (Camarillo, G., Ott, J., and K. Drage, “The Binary Floor Control Protocol (BFCP),” November 2006.) messages the local floor control server might need to send to a user who is remotely participating in the conference (because she/he does not belong to the current XCON cloud). Another example concerns BFCP messages a local user might send to the remote floor control server handling the remote distributed conference she/he is involved in. Any message sent by local entities to local entities has to be treated in the usual centralized way according to the relative protocol specifications (i.e. dispatching shall not be involved).


  8. Distributed Mixing

    As soon as two or more centralized conferencing islands get connected in order to provide for a distributed conferencing scenario, the need arises to cope with the issue of mixing media flows generated by the conference participants. This challenging issue is currently considered out-of-scope in this document, which mainly focuses on the distribution of conference signalling/control information rather than addressing media management.

 TOC 

5.2.  Use-case scenarios and examples

In this subsection we provide some examples of the operation of the distributed conferencing framework.


 TOC 

5.2.1.  Creating a new distributed conference

Figure 3 (Creating a new conference) illustrates how a distributed conference can be created and managed in a distributed environment. A participant contacts its corresponding focus entity in order to request the creation of a new conference instance. With respect to the centralized scenario, upon conference instantiation, in this case the focus has to publish conference information by notifying its related DCON focus. This is done in order to allow other remote focus entities to get up-to-date information about available conferencing sessions. 




Client                    XCON                    DCON
  |                         |                       |
  |  Request creation of    |                       |
  |  a new XCON conference  |                       |
  |------------------------>|                       |
  |                         |--+ Schedule           |
  |                         |  | new XCON           |
  |                         |<-+ conference         |
  |                         |                       |
  |                         |  Notify scheduling    |
  |                         |  of new conference    |
  |                         |---------------------->|
  |                         |                       |--+ Manage
  |                         |                       |  | new XCON
  |                         |                       |<-+ conference
  |                         |                       |
  |                         |                       | Spread new
  |                         |                       | information
  |                         |                       |-------->  ~~~
  .                         .                       .
  .                         .                       .
 Figure 3: Creating a new conference 

 TOC 

5.2.2.  Retrieving information about available conferences

Figure 4 (Retrieving information about available conferences) illustrates how information about available centralized and distributed conferences can be retrieved. A participant contacts its corresponding focus entity in order to request the above information. With respect to the centralized scenario, upon reception of a participant's request, the XCON focus has to forward the request to the related DCON focus. It will be up to the distributed focus entity to provide such information, which will include the list of both centralized (local) and distributed (remote) conferences. This way, a participant will be able to transparently keep on contacting the XCON focus to get all the information she/he needs in both cases. 




Client                    XCON                     DCON
  |                         |                        |
  | Request list of         |                        |
  | available conferences   |                        |
  |------------------------>|                        |
  |                         |--+ Process             |
  |                         |  | client's            |
  |                         |<-+ request             |
  |                         |                        |
  |                         | Forward request        |
  |                         | to DCON focus          |
  |                         |----------------------->|
  |                         |                        |--+ Process
  |                         |                        |  | forwarded
  |                         |                        |<-+ request
  |                         |  Send conferences list |
  |   Send conferences list |<-----------------------|
  |<------------------------|                        |
  .                         .                        .
  .                         .                        .
 Figure 4: Retrieving information about available conferences 

 TOC 

5.2.3.  Joining a conference hosted by a foreign island

Figure 5 (Joining a foreign conference) illustrates how a participant can join a conference which is managed by a focus entity belonging to a foreign centralized island. The whole sequence diagram has been split in three parts to better help understanding all the required steps. A participant contacts its corresponding focus entity in order to send the join request. With respect to the centralized scenario, upon reception of the participant's request, the local focus has to forward join information to the focus entity belonging to the island in which the conference in question was created.

The following steps are performed in sequence:



  1. once the client has locally joined the distributed conference by placing a SIP call to the focus she/he belongs to (XCON (A)), the focus chooses a new label for the client (A) which will be needed to opportunely dispatch all the messages related to her/him;


  2. XCON (A) at this point forwards the join request to its related DCON focus entity (DCON (A)); in this example this is done by sending, through the XDSP protocol, a message called AddUser containing the newly assigned client's label A;


  3. DCON (A) receives the join request; since it regards a new client, the DCON focus entity chooses a new label (e.g. XYZ) and associates it with the just received label A; depending on the distributed conference the client wants to join, it associates the label (XYZ) with the DCON focus entity managing the XCON focus physically hosting the conference (DCON (B)) and forwards the join request to it;


  4. DCON (B) receives the forwarded message through the XMPP-based S2S channel; since it regards a new client, DCON (B) chooses a new label (e.g. B) and associates it with the just received label XYZ; since the conference the remote client (A) wants to join is physically hosted by XCON (B), the join request is forwarded there using the XDSP protocol, with an AddUser message containing the newly assigned label B which identifies the remote client;


  5. XCON (B) receives the request, and thus associates the received label B with the remote Client (A); all the operations needed to add the new user to the conference are performed, and the new information is sent back to the client through the same path. All the involved labels (B, XYZ, A) will be opportunely swapped to route all the XCON protocols messages between the two entities.


Once XCON (A) receives the confirmation that the user has been successfully added to the remote conference, together with the needed information, the client (A) is updated through a SIP REINVITE containing the BFCP information she/he will need to communicate with the Floor Control Server. All BFCP messages sent from now on by the client to the Floor Control Server will be intercepted by the gateway, and then forwarded to the Floor Control Server of XCON (B). This case will be furtherly presented and discussed in the next section. 




Client(A)             XCON(A)          DCON(A)                DCON(B)
  |                     |                 |                      |
  |  SIP INVITE         |                 |                      |
  |-------------------->|                 |                      |
  |         SIP Trying  |                 |                      |
  |<--------------------|                 |                      |
  |             SIP OK  |                 |                      |
  |<--------------------|                 |                      |
  |  SIP ACK            |                 |                      |
  |-------------------->|                 |                      |
  |                     |--+ Choose a     |                      |
  |                     |  | Label (A)    |                      |
  |                     |<-+ for new user |                      |
  |                     |                 |                      |
  |                     |  AddUser (A)    |                      |
  |                     |---------------->|                      |
  |                     |                 |--+ Choose a Label    |
  |                     |                 |  | (XYZ) and find    |
  |                     |                 |  | destination       |
  |                     |                 |<-+ (DCON (B))        |
  |                     |                 |                      |
  |                     |                 |--+ Label             |
  |                     |                 |  | Swap              |
  |                     |                 |<-+ (A=>XYZ)          |
  |                     |                 |                      |
  |                     |                 |  XMPP (AddUser)      |
  |                     |                 |----  ~~(S2S)~~  ---->|
  |                     |                 |                      |
  .                     .                 .                      .
  .                     .                 .                      .



          DCON(A)              DCON(B)             XCON(B)
            .                    .                    .
            .                    .                    .
            |                    |                    |
            |--+ Label           |                    |
            |  | Swap            |                    |
            |<-+ (A=>XYZ)        |                    |
            |                    |                    |
            |  XMPP (AddUser)    |                    |
            |---  ~~(S2S)~~  --->|                    |
            |                    |--+ Choose a        |
            |                    |  | Label (B)       |
            |                    |<-+ for new user    |
            |                    |                    |
            |                    |  AddUser           |
            |                    |------------------->|
            |                    |                    |--+ Assign new
            |                    |                    |  | User ID
            |                    |                    |  | to remote
            |                    |                    |<-+ participant
            |                    |      UserAdded (B) |
            |                    |<-------------------|
            |           Label +--|                    |
            |            Swap |  |                    |
            |        (B=>XYZ) +->|                    |
            |                    |                    |
            |  XMPP (UserAdded)  |                    |
            |<---  ~~(S2S)~~  ---|                    |
   Label +--|                    |                    |
    Swap |  |                    |                    |
(XYZ=>A) +->|                    |                    |
            |                    |                    |
            .                    .                    .
            .                    .                    .




Client(A)             XCON(A)          DCON(A)                DCON(B)
  .                     .                 .                      .
  .                     .                 .                      .
  |                     |                 |                      |
  |                     |                 |     XMPP (UserAdded) |
  |                     |                 |<----  ~~(S2S)~~  ----|
  |                     |        Label +--|                      |
  |                     |         Swap |  |                      |
  |                     |     (XYZ=>A) +->|                      |
  |                     |                 |                      |
  |                     |   UserAdded (A) |                      |
  |                     |<----------------|                      |
  |  Manage received +--|                 |                      |
  | info on new user |  |                 |                      |
  |       (e.g. IDs) +->|                 |                      |
  |                     |                 |                      |
  |                     |                 |                      |
  |SIP REINVITE (+BFCP) |                 |                      |
  |<--------------------|                 |                      |
  |  SIP Trying         |                 |                      |
  |-------------------->|                 |                      |
  |  SIP OK             |                 |                      |
  |-------------------->|                 |                      |
  |            SIP ACK  |                 |                      |
  |<--------------------|                 |                      |
  |                     |                 |                      |
  .                     .                 .                      .
  .                     .                 .                      .
  .                     .                 .                      .
 Figure 5: Joining a foreign conference 

 TOC 

5.2.4.  Dispatching XCON protocols in DCON

Figure 6 (Centralized protocols dispatching) illustrates how natively centralized XCON protocols (BFCP, in the figure) can be opportunely dispatched in order to let them spread across a distributed environment. Such mechanism would allow users participating in distributed conferences to avoid knowing the transport addresses needed to communicate with remote focus entities, and to keep transparently referring to the local focus entity instead.

In order to understand who the actual receiver of a message shall be, all messages are intercepted by a logical entity, called Gateway, belonging to the XCON focus. The Gateway will understand whether a message is directed to a local entity (e.g. a user belonging to the XCON focus, or the local Floor Control Server) or to a remote entity belonging to another focus (e.g. a remotely participating user, or a remote Floor Control Server). 




+---------------------------------------------------------+
| Client 1: Label A (Server Leg: FCS)                     |
| Client 2: Label B (Server Leg: Remote FCS-->Dispatcher) |
| Client 3: Label C (Server Leg: FCS)                     |
+---------------------------------------------------------+

                +--DCON-------------+
                |                   |
                |    +------------+ |
                |    | Dispatcher |<=== (BFCP: Label Swap) ===...>
                |    +------------+ |
                +-------------^-----+
                              |
                              |  XDSP Message: Label B
                              | (BFCP encoded in Base64)
                              |
                        +-----|-------------------XCON--+
                        |     |                         |
                        |     +--- Notify (B) ---+      |
                        |     |                  |      |
+----------+            |     v                  v      |
| Client 1 |<---+       | +---------+       +---------+ |
+----------+    |       | |  Floor  |<--A-->|  Floor  | |
                +-A------>| Control |       | Control | |
+~~~~~~~~~~+            | |  Server |<--C-->|  Server | |
ì Client 2 ì<------B----->| Gateway |       +---------+ |
+~~~~~~~~~~+            | +---------+                   |
                        +---^---------------------------+
+----------+                |
| Client 3 |<-------C-------+
+----------+
 Figure 6: Centralized protocols dispatching 

To make the whole thing clearer, the example in figure Figure 7 (An example: dispatching a BFCP message) will be used. As in the previous case, the whole sequence diagram has been split in three parts to better help understand all the required steps. In this example, a user (Client (A)) belonging to XCON (A) is remotely participating to a distributed conference hosted by XCON (B). Since XCON (B) is physically hosting the conference, floor control will be entirely managed by its Floor Control Server. To allow Client (A) to communicate with Floor Control Server (B) and viceversa, appropriate dispatching of BFCP messages between the two peers will be needed. We have already seen how labels are assigned and swapped: the same labels will be used for dispatching.



The flow of a typical message exchange can be seen as follows:



  1. The Client (A) sends a BFCP message to the Floor Control Server; the message is intercepted by XCON (A)'s gateway; the label assigned to client (A) is retrieved, and used to forward the BFCP message to the DCON (A) Dispatcher; of course, since BFCP messages are binary, an opportune treatment (e.g. through Base64 encoding) should be done to encapsulate the message in a text-based protocol message (as XDSP will probably be);


  2. Once DCON (A) receives the encapsulated BFCP message, the labels are opportunely swapped (in this case, A=>XYZ) and the message is routed to the right destination (DCON (B));


  3. DCON (B) will receive the message and swap labels again (XYZ=>B); at this point, the encapsulated message will be forwarded to the underlying XCON (B) Gateway to be further processed there;


  4. The XCON (B) Gateway will receive the encapsulated (and probably Base64-encoded) BFCP message; after decoding it (if needed), the Gateway will analyze the label marked in the message (B, in this case), and will understand it is a message sent by a remote user (Client (A)) to the local Floor Control Server. It will forward the (now 'natively' binary) message there, where it will be processed;


  5. In case the FCS (B) needs to send a message to Client (A), exactly the same operations will be performed, and the same path will be followed through the needed label swaps among the involved peers. FCS (A), while not actually managing the floors related to the remote conference Client (A) is participanting in, will however be notified upon each floor status change, so to opportunely update the local media mixes when needed (e.g. to mute Client (A) excluding her/him from XCON (A)'s local mix if FCS (B) has decided so). 





Client(A)           XCON(A)               DCON(A)               DCON(B)
  |                (Gateway)                |                     |
  |                    |                    |                     |
  |  BFCP Message      |                    |                     |
  |------------------->|                    |                     |
  |                    |--+ Get Label (A)   |                     |
  |                    |  | assigned to     |                     |
  |                    |<-+ client/FCS      |                     |
  |                    |                    |                     |
  |                    |  BFCP encoded      |                     |
  |                    |  in Base64         |                     |
  |                    |--(Label A)-------->|                     |
  |                    |                    |--+ Label            |
  |                    |                    |  | Swap             |
  |                    |                    |<-+ (A=>XYZ)         |
  |                    |                    |                     |
  |                    |                    |--+ Get destination  |
  |                    |                    |  | from label XYZ   |
  |                    |                    |<-+ (DCON B)         |
  |                    |                    |                     |
  |                    |                    | XMPP                |
  |                    |                    | (BFCP in Base64)    |
  |                    |                    |----  ~~(S2S)~~  --->|
  |                    |                    |                     |
  .                    .                    .                     .
  .                    .                    .                     .



DCON(A)               DCON(B)            XCON(B)             XCON(B)
  |                     |               (Gateway)             (FCS)
  .                     .                   .                   .
  .                     .                   .                   .
  | XMPP                |                   |                   |
  | (BFCP in Base64)    |                   |                   |
  |---  ~~(S2S)~~  ---->|                   |                   |
  |                     |                   |                   |
  |                     |--+ Label          |                   |
  |                     |  | Swap           |                   |
  |                     |<-+ (XYZ=>B)       |                   |
  |                     |                   |                   |
  |                     |  BFCP encoded     |                   |
  |                     |  in Base64        |                   |
  |                     |-----(Label B)---->|                   |
  |                     |                   |--+ Check Label (B)|
  |                     |                   |  | assigned to    |
  |                     |                   |<-+ FCS/client     |
  |                     |                   |                   |
  |                     |                   |  BFCP Message     |
  |                     |                   |------------------>|
  .                     .                   .                   .
  .                     .                   .                   .
  |                     |                   |     BFCP Message  |
  |                     |                   |<------------------|
  |                     |  Get Label (B) +--|                   |
  |                     |    assigned to |  |                   |
  |                     |     FCS/client +->|                   |
  |                     |                   |                   |
  |                     |      BFCP encoded |                   |
  |                     |         in Base64 |                   |
  |                     |<-----(Label B)----|                   |
  |            Label +--|                   |                   |
  |             Swap |  |                   |                   |
  |         (B=>XYZ) +->|                   |                   |
  |                     |                   |                   |
  |  Get destination +--|                   |                   |
  |   from label XYZ |  |                   |                   |
  |         (DCON A) +->|                   |                   |
  |                     |                   |                   |
  |                XMPP |                   |                   |
  |    (BFCP in Base64) |                   |                   |
  |<---  ~~(S2S)~~  ----|                   |                   |
  |                     |                   |                   |
  .                     .                   .                   .
  .                     .                   .                   .



Client(A)           XCON(A)               DCON(A)               DCON(B)
  |                (Gateway)                |                     |
  |                    |                    |                     |
  |                    |                    |                XMPP |
  |                    |                    |    (BFCP in Base64) |
  |                    |                    |<----  ~~(S2S)~~  ---|
  |                    |           Label +--|                     |
  |                    |            Swap |  |                     |
  |                    |        (XYZ=>A) +->|                     |
  |                    |                    |                     |
  |                    |       BFCP encoded |                     |
  |                    |          in Base64 |                     |
  |                    |<---------(Label A)-|                     |
  | Check Label (A) +--|                    |                     |
  |     assigned to |  |                    |                     |
  |      client/FCS +->|                    |                     |
  |                    |                    |                     |
  |      BFCP Message  |                    |                     |
  |<-------------------|                    |                     |
  |                    |                    |                     |
  .                    .                    .                     .
  .                    .                    .                     .
  .                    .                    .                     .
 Figure 7: An example: dispatching a BFCP message 

 TOC 

6.  Security Considerations

TBD...


 TOC 

7.  References


 TOC 

7.1. References

[RFC2234] Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” RFC 2234, November 1997 (TXT, HTML, XML).
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC2434] Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” BCP 26, RFC 2434, October 1998 (TXT, HTML, XML).
[RFC4353] Rosenberg, J., “A Framework for Conferencing with the Session Initiation Protocol (SIP),” RFC 4353, February 2006 (TXT).
[RFC4582] Camarillo, G., Ott, J., and K. Drage, “The Binary Floor Control Protocol (BFCP),” RFC 4582, November 2006 (TXT).
[I-D.romano-dcon-requirements] Romano, S., Amirante, A., Castaldi, T., Miniero, L., and A. Buono, “Requirements for Distributed Conferencing,” draft-romano-dcon-requirements-06 (work in progress), January 2010 (TXT).
[I-D.romano-dcon-xdsp-reqs] Romano, S., Amirante, A., Castaldi, T., Miniero, L., and A. Buono, “Requirements for the XCON-DCON Synchronization Protocol,” draft-romano-dcon-xdsp-reqs-06 (work in progress), January 2010 (TXT).

 TOC 

7.2. Informational References

[I-D.ietf-xcon-framework] Barnes, M., Boulton, C., and O. Levin, “A Framework for Centralized Conferencing,” draft-ietf-xcon-framework-11 (work in progress), April 2008 (TXT).
[I-D.ietf-xcon-common-data-model] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, “Conference Information Data Model for Centralized Conferencing (XCON),” draft-ietf-xcon-common-data-model-18 (work in progress), February 2010 (TXT).

 TOC 

Authors' Addresses

  Simon Pietro Romano
  University of Napoli
  Via Claudio 21
  Napoli 80125
  Italy
Email:  spromano@unina.it
  
  Alessandro Amirante
  University of Napoli
  Via Claudio 21
  Napoli 80125
  Italy
Email:  alessandro.amirante@unina.it
  
  Tobia Castaldi
  University of Napoli
  Via Claudio 21
  Napoli 80125
  Italy
Email:  tobia.castaldi@unina.it
  
  Lorenzo Miniero
  University of Napoli
  Via Claudio 21
  Napoli 80125
  Italy
Email:  lorenzo.miniero@unina.it
  
  Alfonso Buono
  CRIAI Consortium
  Piazzale E. Fermi
  Napoli 80100
  Italy
Email:  alfonso.buono@criai.it

 TOC 

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.