Conference Control Channel Protocol (CCCP)

A Scalable Base for Building Conference Control Applications

Mark Handley
M.Handley@cs.ucl.ac.uk

Ian Wakeman
I.Wakeman@cs.ucl.ac.uk

Conference Control Platforms - Generic Requirements

scalable
decentralised
application independent
heterogeneous
simple
extendible

Conference Control Channel Protocol - Requirements

modularity
unified user interface
flexible floor control policies
scalable from tightly to loosely coupled conferences
easily extendible

Conference Control Tasks

application control
membership control
floor management
network management
meta conference management

Conference Control - "State of the Art"

Two schools:

tightly coupled
- usually know conference membership
- explicit join and leave
- limited scalability
- examples: mmconf, showme, communique, many others
loosely coupled
- usually IP multicast based
- membership known due to session messages, if at all
- conf ctrl limited to local muting of remote sites
- scalable to very large conferences
- currently separate applications for separate media
- examples: vat, wb, nv, ivs, nevot, a few others

Statements

Any proposed conference control scheme should not restrict the applicability of the applications it controls.

The mechanism of application control should be separate from the policy of conference control.

The mechanism of conference control should scale at least as well as the applications it is controlling.

It should also cope with tightly coupled "closed" conferences as we may wish to use the same media applications.

Conference control should not assume homogeneity of either media or control applications.

Implications?

A modular approach to conference control applications.

Media applications should not provide conference control facilities themselves -- they should provide the handles for external conference control.

Media applications should only provide a media specific user interface when under external control.

How To Achieve This?

If it is going to scale, message passing is a good solution.

But we don't really know who to address a particular message to?

Address messages to a group. Allow scoping based on application type and location.

Allow dynamic type-groups.

Shield the application writer from the implementation.

Can provide enhancements for reliability and ordering.

Conceptualisation of CCCP

Figure (GIF - 41219 bytes)

CCCP Tuples

(instantiation, type, address)
possibly also include a conference id?
address
- a location: hostname, username@hostname
type
- a class hierarchy of application groups, e.g.:
instantiation
- an identifier to provide a globally unique tuple
- provided by CCC library

CCCP Messages

(source tuple){list of (destination tuple)s} FUNCTION [parameter list]

source tuple: one of the tuples registered with the CCC library by the application (globally unique)
destination tuple: a CCC address, possibly with some fields wildcarded, e.g.:
function: the name of a function. this is dependent of the destination type-group(s)

CCCP messages will also gain a sequence number and timestamp from the CCC library. These are passed to the receiving application.

Using CCCP to Unify Interfaces

Figure (GIF - 13576 bytes)

   From               To               Message

the following will be sent periodically:

   (1,audio.recv,x)   (*,sm.local,x)   KEEPALIVE
   (1,video.recv,x)   (*,sm.local,x)   KEEPALIVE
   (1,wb,x)           (*,sm.local,x)   KEEPALIVE

the following will be sent periodically with interval:

   (1,sm,x)           (*,sm.remote,*)             
   ... I_HAVE_MEDIA user_name audio.recv video.recv wb

audio data arrives at the audio application from y:

   (1,audio.recv,x)   (*,sm.local,x)   
   ... MEDIA_STARTED audio y

session manager highlights the speaker

speech burst finishes:

   (1,audio.recv,x)   (*,sm.local,x)   
   ... MEDIA_STOPPED audio y

session manager de-highlights the speaker

video starts from z:

   (1,video.recv,x)   (*,sm.local,x)   
   ... MEDIA_STARTED video z

periodically:

   (1,video.recv,x)   (*,sm.local,x)   
   ... MEDIA_ACTIVE video z

Using CCCP For Simple Floor Control

Figure (GIF - 14314 bytes)

   From                To                                 Message

a user at y starts sending audio and video data.
The local audio and video tools report this to the session manager:

   (1,audio.recv,x)    (*,sm.local,x)                     MEDIA_STARTED audio y
   (1,video.recv,x)    (*,sm.local,x)                     MEDIA_STARTED video y

...as in previous example, sm highlights sender's name

Also y's floor manager reports what's happening:

   (1,floor.master,y)  (*,floor.master,*)                 MEDIA_STARTED audio y
   (1,floor.master,y)  (*,floor.master,*)                 MEDIA_STARTED video y

the local floor manager tells the local video tool to stop sending:

   (1,floor.master,x)  (*,video.send,x)                   STOP_SENDING video

...this causes the video at x to stop sending:

   (1,audio.send,x)    (*,sm.local,x),(*,floor.master,x)  MEDIA_STOPPED video x

...

   From                To                                 Message

the user at x starts speaking. Silence suppression cuts out, and the audio tool starts sending:

   (1,audio.send,x)    (*,sm.local,x),(*,floor.master,x)  MEDIA_STARTED audio x

...this causes the sm to highlight the "you are sending audio" icon

It also causes the floor manager to report to the other floor managers:

   (1,floor.master,x)  (*,floor.master,*)                 MEDIA_STARTED audio x

and also it requests the local video to send video:

   (1,floor.master,x)  (*,video.send,x)                   START_SENDING video

...this causes the video tool to start sending:

   (1,video.send,x)    (*,sm.local,x),(*,floor.master,x)  MEDIA_STARTED video x

...which, in turn, causes the sm to highlight the "you are sending video" icon

the user at x stops speaking. Silence suppression cuts in, and the audio tool stops sending:

   (1,audio.send,x)    (*,sm.local,x),(*,floor.master,x)  MEDIA_STOPPED audio x

...this causes the sm to de-highlight the "you are sending audio" icon
...the session manager starts a timeout procedure before it will stop sending video

Other Issues

reliability
ordering
security
membership discovery
"need-to-know"

Questions

Will it work?
Can it do what you want?
Is it any use?
Are other ideas?

Paper Available

ftp://cs.ucl.ac.uk/mice/publications/cccp{_us}.ps{gz}
ftp://ftp.isi.edu/confctrl/bib/cccp{_us}.ps{gz}