A Framework for Distributed Conferencing
University of NapoliVia Claudio 2180125NapoliItalyspromano@unina.itUniversity of NapoliVia Claudio 2180125NapoliItalyalessandro.amirante@unina.itUniversity of NapoliVia Claudio 2180125NapoliItalytobia.castaldi@unina.itUniversity of NapoliVia Claudio 2180125NapoliItalylorenzo.miniero@unina.itAnsaldo Trasporti e Sistemi FerroviariVia Argine, 42580147NapoliItalyalfonso.buono@atsf.it
RAI
Network Working GroupDistributedConferencingXCON (Centralized Conferencing)
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.
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 . 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 .
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 .
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.
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 and
indicate requirement levels for compliant implementations.
Distributed conferencing uses, when appropriate, and expands on the
terminology introduced in the both the SIPPING
and XCON conferencing frameworks.
The following additional terms are defined for specific use within the
distributed conferencing context.
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.
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.
The capability to detect the presence of new focus entities in a
distributed conferencing framework.
The spreading of conference related information
among the focus entities in a distributed environment.
The capabilty to appropriately forward/distribute messages of
a natively centralized protocol in order to let them spread across a
distributed environment.
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.
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 , 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.
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.
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, 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 .
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.
| 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
]]>
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.
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.).
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.
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.
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.
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.
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.
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 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).
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.
In this subsection we provide some examples of the operation of
the distributed conferencing framework.
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.
| |
| |--+ Schedule |
| | | new XCON |
| |<-+ conference |
| | |
| | Notify scheduling |
| | of new conference |
| |---------------------->|
| | |--+ Manage
| | | | new XCON
| | |<-+ conference
| | |
| | | Spread new
| | | information
| | |--------> ~~~
. . .
. . .
]]>
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.
| |
| |--+ Process |
| | | client's |
| |<-+ request |
| | |
| | Forward request |
| | to DCON focus |
| |----------------------->|
| | |--+ Process
| | | | forwarded
| | |<-+ request
| | Send conferences list |
| Send conferences list |<-----------------------|
|<------------------------| |
. . .
. . .
]]>
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:
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;
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;
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;
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;
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.
| | |
| 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 | | |
|<--------------------| | |
| | | |
. . . .
. . . .
. . . .
]]>
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).
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-------+
+----------+
]]>
To make the whole thing clearer, the example in figure
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:
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);
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));
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;
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;
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).
| | |
| |--+ 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 | | |
|<-------------------| | |
| | | |
. . . .
. . . .
. . . .
]]>
TBD...