Subject: Re: Confctrl BOF at upcoming IETF

From: schooler
Date: Wed, 24 Mar 1993 10:02:41 -0800

----- Begin Included Message -----

---

From: Jack Jansen <[email-masked]>
Date: Wed, 24 Mar 1993 11:30:26 +0100

Conference Control BOF Template
    		    -------------------------------
    
    1. Name of project, program and/or protocol.
    	The (internal) name of the project is simply 'Meeting'.
    
    2. Contact person, affiliation and e-mail address.
        Jack Jansen
	CWI, Kruislaan 413, Amsterdam, the Netherlands
	[email-masked]
    
    3. Target operating environment and key design considerations:

        Current experiments are all done over an IP LAN. We attempt to
	make this dependence minimal, though, and will probably start
	experimenting with WANs shortly. Upto recently the emphasis
	has been on media handling, but conference control is getting
	more and more attention.

	The previous incarnation of the program was a monolithic
	one, but it is now being split into media handlers and a
	control application. This should theoretically also allow use
	of different communication channels for different media.
    
    4.a Type of conference styles supported by your system/protocol.

        Currently we support closed conferences of 2-5 members, but
	one of the plans with the separate control module is to allow
	different control modules with different policies.
    
    4.b Profile of user community: 

        No experiments with novice users have been done yet, our
	current users are all computer professionals. Meetings are
	informal, there are no facilities for floor-control, etc.
	Meeting scheduling is done through outside means.
    
    5. Architecture assumptions: 

        For the current closed meetings we use a centralized model (A
	conference control module that is more geared towards large
	meetings (informal 'chatbox' style) will probably use
	distributed algorithms). Conference control uses a simple TCP
	protocol to manage the conference, media communication uses IP
	multicast whenever possible. Current experiments are done on
	SGI Indigi only, but heterogeneity is a design goal (a
	previous version worked on Suns as well).
	
    6.a How do you define conference control?
        Managing sessions, both from a user point of view (multiple
	sessions per user) as from a system point of view (multiple
	users with different hardware capabilities and bandwidth in a
	single conference).
    
    6.b Conference control functionality supported.

        Very little: basic conference setup, join, leave. Checking is
	done to make sure that all participants are still actually
	there. (well, their machines, that is:-) Users can add media
	(like live video) to the conference.
    
    6.c Other control functions you would like to support.

        More dynamic media addition will be added shortly, as will be
	more control over which users get which mediastreams, and in
	what format. Merging of conferences (usually a multi-person
	conference and a single point-to-point conference) will also
	be added shortly. Scheduling and invitation handling are
	also wanted but will have to wait a while.
    
    7. Conference control protocol details: 

        Conference control is currently explicit, with a single
	participant (the initator) keeping the 'master copy' of the state
	information and all other participants having shadow copies of
	this. Media streams that can tolerate loss are sent
	distributed, others (screen snapshots, etc) are currently sent
	centralized. The conference control rptocol should probably
	scale up to 20 members or so. The other loose conference
	control we want to do will be distributed and should scale a
	lot further.
    
    8. Hardware/software platforms.
        In principal heterogenous, but the current implementation is
	confined to SGI Indigi. Previous versions ran on Suns as well.
    
    9.a What specifically has or has not been implemented?

        A fair amount of work has been put into a reasonable user
	interface: you get cute photographs of everyone with a little
	light showing who's doing the talking. If your machine has
	live video input your picture is replaced by a 2-4 fps video.

	We have specifically not done anything in the area of floor
	control. We feel that, for groups of this size, this is a
	social issue, not a technical one.
    
    9.b What was unexpectedly easy or difficult to implement?

        A lot of work has gone into echo supression and silence/speech
	detection. We now have something that works fairly well most
	of the times.

	We found it pretty difficult to come up with a control
	mechanism that would work fine with the whole spectrum of
	conferences, from small closed meetings to large, mainly
	one-to-many presentations to large, many-to-many, chatbox
	meetings.
    
    9.c What might you change as a result?

        We're treating the different conference styles as wholly
	separate issues. We'll need some sort of communication between
	different style meetings (like what do you do when you merge a
	tightly-controlled conference into a loosely controlled one)
	but we feel this should be solvable.
    
    10. If available, suggested readings about your work on confctrl.

        Nothing published yet. I have an 8-page document describing
	all the mistakes I made and the problems I came across that I
	can send to interested parties. It is mainly on media
	handling, though, and the conference control part is already
	pretty outdated.
--
Jack Jansen        | If I can't dance I don't want to be part of
[email-masked] | your revolution             -- Emma Goldman
uunet!cwi.nl!jack    G=Jack;S=Jansen;O=cwi;PRMD=surf;ADMD=400net;C=nl

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