Since early 1992, a multicast virtual network has been constructed over the
Internet. This multicast backbone or Mbone[#mbone##1#] has been used for a number of
applications including multimedia (audio, video and shared workspace)
conferencing. These applications involved include vat (LBL's Visual Audio Tool), ivs
(INRIA Videoconferencing System[#turletti##1#]), nv (Xerox's Network Video tool,
[#frederick##1#]) and wb (LBL's shared whiteboard) amongst others. These applications
have a number of things in common:
These applications are designed so that conferencing will scale effectively
to large numbers of conferees. At the time of writing, they have been used
to provide audio, video and shared whiteboard to conference with about 500
participants. Without multicast , this is clearly not possible. It is also clear
that, with unreliable networks, these applications cannot achieve complete
consistency between all participants, and so they do not attempt to do so -
the conference control they support usually consists of:
- The are all based on IP Multicast.
- They all report who is present in a conference by occasional multicasting
of session information.
- The different media are represented by separate applications
- There is no conference control, other than each site deciding when and
at what rate they send.
Thus any form of conference control that is to work with these applications
should at least provide these basic facilities, and should also have scaling
properties that are <#1914#> no worse that the media applications themselves<#1914#>.
The domains these applications have been applied to vary immensely. The
same tools are used for small (say 20 participants), highly interactive
conferences as for large (500 participants) dissemination of seminars, and
the application developers are working towards being able to use these
applications for ``broadcasts;SPM_quot; that scale towards millions of receivers.
It should be clear that any proposed conference control scheme
should not restrict the applicability of the applications it controls, and
therefore should not impose any single conference control policy. For
example we would like to be able to use the same audio encoding engine (such
as vat), irrespective of the size of the conference or the conference
control scheme imposed. This leads us to the conclusion that <#1915#> the media
applications (audio, video, whiteboard, etc) should not provide any
conference control facilities themselves, but should provide the handles for
external conference control and whatever policy is suitable for the
conference in question.<#1915#>
- Periodic (unreliable) multicast reports of receivers.
- The ability to locally mute a sender if you do not wish to hear or see
them. However, in some cases stopping the transmission at the sender is
actually what is required.