From: [email-masked]
Date: Mon, 22 Mar 93 15:42:28 +0000

Conference Control BOF Template
		    -------------------------------

1. Name of project, program and/or protocol.

	PREPARE (Prepilot in Advanced Resource Management - R2004)
	Part of the Commission of the European Communities RACE II program

2. Contact person, affiliation and e-mail address.

	David Lewis
	Computer Science Department
	University College London
	Gower Street
	London WC1E 6BT
	U.K.

	e-mail: [email-masked]
	tel: +44 (0)71 387 7050 x 3706
	fax: +44 (0)71 387 1397

3. Target operating environment and key design considerations:

   - WAN vs LAN 
	the project is developing its own broadband testbed network
	consisting of:
	- a 3-node 155Mbps ATM WAN network (in cooperation with the 
	  Danish BATMAN project)
	- a MAN network
	- Token Ring LANs
	- ATM PBXs

   - digital vs analog media
	all digital audio and video using the following equipment and 
	techniques:
	- SPARCstation inbuilt audio
	- VideoPix card in SPARCstations
	- GEC px64kbps H.261 codecs
	- software H.261 coding/decoding (IVS from INRIA, France)

   - the kinds of collaborative media used in your system 
	The conferenceing system used is a development of the conferencing
	system developed at UCL for the RACE I project CAR. This allows
	the inclusion of both custom built shared applications and standard,
	X-window based applications into conferences. Audio and video 
	conferencing application (e.g. VAT, IVS) are included in this way.

   - packet technology vs ISDN
	Both. IP used for workstations connected to Token Rings, and B-ISDN
	in the form of ATM AAL1 connections are used for workstations 
	connected ATM PBXs 

   - room-to-room vs desktop conferencing
   	desktop, workstation-based conferencing used

4.a Type of conference styles supported by your system/protocol.

4.b Profile of user community: 

   - expertise level
	the conferencing application is used only for the demonstration of
	network management techniques, which is the aim of the project. THus
	the conferencing system will not be used "in service" as part of the 
	project, but this is planned for both the depatment at UCL and the
	CEC MICE project, using the same system. 

   - formality of meetings
	The demo's in PREPARE are based on groups of engineers working closely
	together using shared CAD packages. Floor control is "free for all".

   - demand for quality of service
	Floor control will be request by the user in qualitative term through
	the conferencing application. The aim in PREPARE is that the 
	QoS is then supplied by the network management system.

5. Architecture assumptions: 

   - distributed vs centralized model
	The software model is essentially centralised, relying on a single
	conference server. However there is no central hub or video 
	distribution site, so for the purposes of demonstrating interaction
	with the network management, the conferencing system is distributed.
	We are working generally towards making the software truely 
	distributed. 

   - system component(s) responsible for conference control
	The central conference server process is responsible for conference
	control. Each particpant runs a conference control application that
	provides a user interface to the facilities offered by the server.

   - degree of homogeneity in end-system capabilities 
	currently the system runs only on SPARCstations, however use of
	H.261 encoding allows interworking between workstation with either
	hardware or software CODECs

   - multicast integration
	multicast used for audio and video transmission, though  mulitcast
	may not be implemented in all parts of the PREPARE tesbed.

   - directory services
	X.500 directory services will be available through network management
	services

   - support for quality of service
	implemented through network management services

6.a How do you define conference control?  
	by the following functions:
		- creating a conference
		- joining a conference
		- leaving a conference
		- browsing existing conferences
		- including an application in a conference
		- removing an application from a conference
		- requesting and receiving the floor

6.b Conference control functionality supported.
	see 6.a

6.c Other control functions you would like to support.
	- floor control by chairperson
	- separate floor control for different media

7. Conference control protocol details: 

  - explicit vs implicit setup
	explicit set-up by user by named participants and included 
	application only
  - interconnectivity of participants
	through conference server
  - state sharing
	ditto
  - robustness
	conference server obvious weak point
  - scaling properties
	limited by capabilities of machine running conference server

8. Hardware/software platforms.  
	SPARCstation, 
	SunOS,
	requires IP multicast and SUN RCP or ANSA RCP

9.a What specifically has or has not been implemented?
	All conference control mentioned is implemented and well tested
	over local and wide area Internet.
	Interface to network management, QoS control and testing over
	PREPARE testbed not yet performed

9.b What was unexpectedly easy or difficult to implement?
	Use of ANSA for RCP mechanism was found to weigh down the rest
	of the system, hence change to SUN RCP

9.c What might you change as a result?
	We hope to evolve the system to be fully distributed, with
	conference control communication over multicast

10. If available, a couple of suggested readings about your work
    on confctrl.

The following are available anonymous ftp from uk.ac.ucl.cs in directory
car:

collab_write.ps.Z
  Multimedia Conferencing as a Tool for Collaborative Writing: A Case Study
    - S. Baydere et al, 1991

complexity.ps.Z
  Coping with complexity and interference: design issues in multimedia
  conferencing systems - M.A.Sasse, M.J.Handley & N.Ismail, 1992

inet92.ps.Z
  Multimedia Conferencing: from prototype to national pilot
    - Mark Handley and Steve Wilbur, 1992

janetvid.ps.Z
  Some Multimedia Traffic Characterisation Results
    - Crowcroft et al, 1992

----- End Included Message -----