Conferences come in all shapes and sizes. For some, no floor control,
with everyone sending audio when they wish, and sending video continuously is fine.
For others, this is not satisfactory due to insufficient available bandwidth
or a number of other reasons. It should be possible to provide floor
control functionality, but the providers of audio, video and workspace
applications should not specify which policy is to be used. Many different
floor control policies can be envisaged. A few example scenarios are:
- Explicit chaired conference, with a chairperson deciding when someone
can send audio and video. Some mechanism equivalent to hand raising to
request to speak. Granting the floor starts video transmission, and enables
the audio device. Essentially this is a schoolroom type scenario, requiring
no expertise from end users.
- Audio triggered conferencing. No chairperson, no explicit floor
control. When someone wants to speak, they do so using ``push to talk;SPM_quot;.
Their video application automatically increases its data rate from, for
example, 10Kb/s to 256Kb/s as they start to talk. 20 seconds after they
stop speaking it returns to 10Kb/s.
- Audio triggered conferencing with a CMMC[#mice##1#] Conference
Management and Multiplexing Centre - essentially one or more points where
multiple streams are multiplexed together for the benefit of people on
unicast links, ISDN and hardware codecs. The CMMC can mix four
streams for decoding by participants with hardware codecs. The four streams
are those of the last four people to speak, with only the current speaker
transmitting at a high data rate. Everyone else stops sending video
automatically.
- A background Mbone engineering conference that's been idle for 3
hours. All the applications are iconised, as the participant is doing
something else. Someone starts drawing on the whiteboard, and the audio
application plays an audio icon to notify the participant.