Requirements for Distributed Conferencing
University of Napoli
Via Claudio 21
80125
Napoli
Italy
spromano@unina.it
University of Napoli
Via Claudio 21
80125
Napoli
Italy
alessandro.amirante@unina.it
University of Napoli
Via Claudio 21
80125
Napoli
Italy
tobia.castaldi@unina.it
University of Napoli
Via Claudio 21
80125
Napoli
Italy
lorenzo.miniero@unina.it
Ansaldo Trasporti e Sistemi Ferroviari
Via Argine, 425
80147
Napoli
Italy
alfonso.buono@atsf.it
Transport
Network Working Group
Distributed
Conferencing
Centralized Conferencing (XCON)
Cascaded conferences
This document examines the requirements for Distributed
Conferencing (DCON). Separate documents will map the requirements
to existing protocol primitives, define new protocol extensions, and introduce
new protocols as needed. Together, these documents will provide a guideline for
building interoperable conferencing applications.
The current works in SIPPING and XCON working groups marginally address the
matter, which is nonetheless considered as out-of-scope.
The requirements listed in this document are in part based on thoughts derived
from the cited working groups activities.
This document examines the requirements for an architecture capable
to provide a distributed conferencing service. It draws inspiration from
a number of existing research efforts inside the IETF, mainly in the context
of both the SIPPING and the XCON WGs. We will herein present high-level
requirements, starting from considerations upon the well-known concept of
cascaded conferencing .
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 both the SIPPING and XCON conferencing frameworks. The following additional terms are defined for specific use within the distributed conferencing work.
Focus Discovery -- this term refers to the capability to detect the presence of new focus entities in a distributed conferencing framework.
Information Spreading -- this term refers to the spreading of conference related information among the focus entities in a distributed environment.
Protocol Dispatching -- this term refers to the capabilty of appropriately forwarding/distributing messages of a natively centralized protocol in order to let them spread across a distributed environment.
DCON Focus -- this term refers to 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.
Conferencing Cloud -- this term refers to 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.
The requirements for a distributed conferencing framework have already been partially addressed in previous works within the IETF. Specifically, RFC 4245 (High-Level Requirements for Tightly Coupled SIP
Conferencing) introduces the concept of cascading of conferences and illustrates three different scenarios to which it might be applied: (i) peer-to-peer chaining of signaling; (ii) conferences having hierarchal signaling relations; (iii) cascading as a means to distribute the media "mixing".
For the three scenarios above, a number of possible requirements are identified, among which the availability of a SIMPLE-based Presence and Instant Messaging architecture plays a major role.
The concept of cascaded conferences is further expanded in RFC 4353 (A Framework for Conferencing with the Session Initiation Protocol (SIP)), where the term "Cascaded Conferencing" is used to indicate "a mechanism for group communications in which a set of conferences are linked by having their focuses interact in some fashion". In the same document, a specific scenario called "Simplex Cascaded Conferences" is presented as a typical interaction paradigm envisaging that the user agent representing the focus of one conference is a conference-unaware participant in another conference.
In other terms, a conference "calls" another conference and gets connected to it as if it were a simple participant. For both such conferences, the peering party is just like any other user participating in the conferencing session. For the sake of completeness, we remark that the previous observation is somehow confuted by RFC 4575 (A Session Initiation Protocol Event Package for Conference State) , which explicitely states:
"It is possible that a participant in the conference may in fact be another focus. In order to provide a more complete participant list, the focus MAY subscribe to the conference package of the other focus to discover the participant list in the cascaded conference. This information can then be included in notifications by use of the <cascaded-focus> element as specified by this package".
Even though the simplex cascaded conferencing is an established way to concatenate conferences, we claim that it is not flexible enough to effectively cope with a number of potential distributed conferencing scenarios. More precisely, we envisage a situation where an overlay network infrastructure is in charge of managing distributed conferences, whereas the sinlge focus entities keep on managing their own centralized "realm". As it will come out in the next section, this entails that a specific requirement is formulated about the need for explicit management of distributed conference information.
In the following we are going to list the requirements we have identified for
distributed conferencing. Each requirement is presented in general terms and
some examples about its applicability are provided.
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.
The communication between each distributed focus entity
contains sensitive information, since it envisages the possibility
to spread important data that only authorized parties should
know (e.g. the full internal state of the centralized conference
objects and relevant privacy information about users authenticated
by the system).
Hence it is very important that protocol messages be protected
because otherwise an attacker might spoof the legitimate identity of
the distributed focus entity or inject messages on its behalf.
To mitigate the above threats, all focus entities SHOULD mutually
authenticate upon initial contact. All protocol messages SHOULD be
authenticated and integrity-protected to prevent third-party intervention
and MITM (Man-In-The-Middle) attacks. All messages SHOULD be
encrypted to prevent eavesdropping.