MACS a modular Collaboration Environment

rangaleclickΛογισμικό & κατασκευή λογ/κού

4 Νοε 2013 (πριν από 4 χρόνια και 8 μέρες)

121 εμφανίσεις


1

MACS


a modular Collaboration Environment



O. Brand, W. Mahalek*, D. Sturzebecher, M. Zitterbart

Institute of Operating Systems and Computer Networks

Technical University Braunschweig


* German Aerospace Agency


{brand | mahalek | sturze | zit}@ibr.cs.tu
-
bs.de


http://macs.ibr.cs.tu
-
bs.de/



Keywords:

Collaboration,
Framework,
Multimedia


Abstract


The trend towards collaborative systems including CS
CW (Computer Supported Cooperative Work) has led to the
development of a variety of collaborative systems. MACS (Modular Advanced Collaboration System) is a flexible,
modular and portable CSCW framework designed to offer advanced session control, integrate
d information services
and a user friendly GUI (Graphical User Interface). These issues are mostly not addressed in current CSCW
frameworks. Due to the pure Java implementation, MACS can easily be deployed in today's typical heterogeneous
networks includin
g the Internet.


1.

Introduction

Currently, a strong trend towards developing frameworks to support collaborative work (CSCW) instead of creating
single, CSCW enabled applications can be observed. The aim of such systems is to provide flexibility and portabil
ity.
The latter is achieved by the use of Java, that enables the possibility to use such CSCW frameworks in heterogeneous
environments. A number of frameworks, each with its own focus and distinct functionality, have been developed
recently and deployed o
n the Internet. Frameworks, such as TANGO [Tngo] and JETS [ShGe97] are implemented in
Java and are WWW
-
based. An example for a framework that is not WWW
-
based but implemented in JAVA can be
found in [CGJP98]. NetMeeting or systems based on MBone use more t
raditional implementation languages.


MACS (Modular Advanced Collaboration System) is a flexible, modular and portable CSCW framework designed to
offer advanced, graphical based, session control, integrated information services and a user friendly GUI (Gra
phical
User Interface). A number of standard tools are provided with this framework, such as a whiteboard and a chat tool.
Audio and video tools are currently under development. Furthermore, a CASE (Computer Aided Software Engineering)
tool called TelSEE,
has been adapted to optionally run in the MACS framework.


The paper is structured as follows. Section 2 gives an overview of the state of the art for collaboration systems. Section
3 explains the structure of the MACS framework. Section 4 describes the MA
CS control and is subdivided into system
control and session control. In section 5 two sample applications for the MACS framework are presented. Finally
section 6 contains the conclusion and an outlook on further developments.

2.

State of the art

A strong tre
nd towards WWW based systems can be observed. These systems promise no need for user installation.
Two such systems are JETS [ShGe97] from MCRLab at the University of Ottawa, Canada and TANGO [Tngo] from
NPAC at Syracuse University. Both run in a Java 1.1
enabled browser and allow basic interaction via chat and
whiteboard. Both provide a number of sample programs, but lack audio/video support. For JETS no user installation is
necessary, except that of a Java 1.1 enabled browser. However, Java 1.1 enabled br
owsers are currently not standard
installations especially in a non
-
academic environment, though this might change soon. An extended WWW server
offers the access to JETS and has to be installed locally. For TANGO, the requirement for a Java 1.1 compliant b
rowser
applies as well. Further a plug
-
in needs to be installed by each user. Thus, also TANGO is a WWW
-
based system user

2

installation is required. Furthermore, it should be noted, that currently running Java in a browser results in a drastically
decreased

performance in comparison to running Java directly on the specific platform. This is as well a fast changing
area as efforts are taken to reduce the overhead of the browser and to provide the same speed improvements gained by
using for example JIT (Just I
n Time compilation) techniques on the platform specific Java interpreters within the
browser environment.


Habanero is a pure Java based CSCW framework that is not integrated into a browser [CGJP98]. It provides a number
of sample applications including th
e typical chat/whiteboard combination. Again no audio/video is supported as a pure
Java implementation does not currently allow this. Habanero is aimed at smaller groups without special requirements
for floor control. Information about other users in the s
ession is provided together with the list of participants. A list of
active tools per participant is not necessary, as launching a tool locally will cause the tool to be launched at all other
participants in the session.


Earlier developments can be divide
d into two categories: MBone
-
based vs. ITU
-
based conferencing systems. The
MBone
-
tools [Kuma96] have experienced a fairly wide distribution in the academic environment. They were designed
to enable and demonstrate multicasting of audio and video via the MB
one and not to serve as collaboration or
conferencing systems. MBone based systems do in general lack floor
-
control functionality. Often only the most
simplest forms of floor control are implemented (i.e. locking everybody except the creator). Furthermore,

MBone based
systems were designed by and for computer scientists. Due to complexity, the high number of windows and the
installation effort they are not suited for non computer scientists. There is no communication provided between the
different tools in
a session resulting in lack of synchronization, no enforcement of access rights and difficult
information retrieval. The main advantage of the MBone tools can be seen in the high scalability they offer, due to the
multicasting of data and the loosely coupl
ed architecture.


The ITU H.323 [H323] and T.120 [T120] based tools are common on the MS
-
Windows platform. The best known ones
are ProShare from Intel and NetMeeting from Microsoft. The H.323 and T.120 standards offer all mechanisms needed
for providing a
more advanced floor control than provided by the above mentioned tools. Both systems do not use this
to provide the user with an advanced control. The main aim of these tools is to provide an easy to use conferencing
facility for small groups. A conference

can be easily initiated by placing a direct call from the users address book, or by
choosing a user from a (filtered) list of users currently registered at their server of choice. The ITU H.323 and T.120
based tools are nearly the opposite of the MBone to
ols in regards to their weaknesses and strength. The tools are easy to
use and provide status and user information readily, but do offer only a very limited scalability.


The aim of MACS is to combine ease of use, advanced floor control and portability int
o a single framework. Especially
modular design and customizability play an important role, as the CSCW field is too wide to provide a "one size fits
all" solution.

3.

Basic structure of MACS

The MACS framework is organized into four logical levels:
Basic net
work services
,
tools
,
control

and
display



(cf., figure 1). These levels are described below, except control, which is discussed in section 4 in detail.

3.1.

Basic network services

The level of basic network services provides an abstraction layer hiding the de
tails of the network from the
applications. The currently integrated protocols are LRMP [Liao], TCP/IP, CORBA and RTP. Real time data is
transmitted via RTP, while non real time user data and control data use one of the other protocols. Each application ca
n
individually select the protocol best suited to its needs.


Additional protocols can easily be added by programming a wrapper that implements the MACS network interface.
The protocol packages are loaded at runtime and can be integrated into to the system

by modifying the property files,
which are text based configuration files. Thus, a high degree of configurability is achieved without the necessity to edit
a single line of code or to recompile any packages.




3

Figure
1
: Stru
cture of MACS


3.2.

Tools

The tools level contains the specific functionality of the tools (e.g., codecs for a video tool, synchronization and play
-
out code). To distribute data to other participants the basic network services are used. The data (e.g., the actu
al decoded
pictures) can, then, be displayed by using the display level. Each tool is connected to the control and, therefore, able to
use the services offered by the control. The minimum requirement for a tool to operate in the MACS framework is to
implem
ent the MACS application interface. The control uses this interface to perform basic tasks such as initialization
and termination of the tool itself. The tool must further use a specific minimum set of control functions, indicating at
least its state and a
vailability to the control.


Tools are assumed to be written in Java. If this is not the case, a Java wrapper can be used to integrate them into the
MACS
-
framework. MACS tools can be added or exchanged as easily as network protocols, without editing a sing
le
line of source code. A configuration file contains the tool setup and name of the corresponding class. During runtime
this class is loaded and checked to ensure that basic requirements for a MACS tool are met. The tools will then run in
the same Java Vi
rtual Machine (JVM) as the rest of MACS. This approach reduces system requirements drastically.
Further, no Inter Process Communication (IPC) is needed, as threads within the same JVM do share memory. A tool
can send Java objects to another tool. It is up
to the receiving tool to interpret the received object and to react
appropriately.

3.3.

Display

The display level determines the GUI and, thus, has a strong influence on the way the user perceives the system. To
provide a clear and easy to use GUI the total num
ber of windows in the MACS framework has been reduced and the
controls for all tools have been grouped into a single control window. Only tools used to represent graphical data do
open an individual data window (e.g., video or whiteboard). The control info
rmation is always displayed in the
designated part of the control window. Tools not working on graphical data should use their designated part of the
control window to display all their information and controls (e.g., audio and chat).


It is important to
reduce the number of windows, as screen space is a very limited resource. If a component opens a
new window for every configuration option, the screen space will soon be exhausted, resulting in overlapping or hidden
windows. This makes an application hard
to use even for an experienced user.

LRMP

(
Light
-
weight Reliable Multicast Protocol
)

Video

White
-

Board

Audio

TelSEE

Control


TelSEE
-

Windo
w

WB
-
Window


Video
-

Window

TelSEE

Panel

Control
-
Window

Video
-

Panel

Control

Panel

Display

Control

Tools

Basic
Network

Services

Audio

Panel

Network Glue

TCP / UDP




RTP

(Real Time Protocol)

CORBA


4

4.

Control

There are two aspects to control. The
system control

is responsible for the framework as such, independently of any
session. The
session control

is responsible for a session and relies on the system control for
anything outside its
session. Each session in which a user participates will have its own local entity of a session control.

4.1.

System control

From the functional point of view, system control consists of three different parts of components:
databases
,
libr
aries

and a
communication module

(cf., figure 2).


Figure
2
: Structure of Control

4.1.1

Databases

The databases cover the following three aspects: users, sessions and applications. The user database contains
information about all cu
rrent MACS users within the configured scope of the system control (i.e., if a multicast
protocol is used this could be a TTL=64). Further information about users registered on a ILS (Internet Location
Server) can be optionally integrated via the ILS
-
modul
e. The ILS
-
module uses LDAP (Light
-
weight Directory Access
Protocol) [LDAP] part of Suns JNDI framework [JNDI] to access a given ILS
-
server and to list the available users.
This is the first step to allow interworking of MACS with ITU H.323/T.120 based sys
tems like NetMeeting and
ProShare. Figure 3 shows a MACS
-
user entry, as contained in the user database.


The user database is the main source of information about a user and provides all parameters needed to place a direct
call to the selected user. The us
er database provides information about the users hardware resources. This allows the
user to determine beforehand, if a communication will be possible, i.e., if a minimal overlap in supported media exists.
A minimal overlap would mean that each user has at

least one tool available that can send data in a format that all other
users can decode with one of their tools. If, for example, two participants enter a session with the first participant only
able to send/receive audio, while the second participant can

only send/receive video, no communication can take place
as no overlap exists.


Figure
3
: User data entry


The session database contains details about available sessions. All MACS sessions are listed. Furthermore, all MBone
sessions, for which an announcement has been received are listed. This allows the user to participate in any MBone
session for which compatible tools are installed. In such a case, the MACS specific features (e.g., user information and
session control) wil
l not be operational. MACS sessions provide a set of additional features depending on the settings
used to create the sessions. These settings can be changed on a per session basis, allowing, for example, the
simultaneous use of different session controlle
rs in each session.


The application database is the most complex of the three databases, as it contains not only information about locally
available (installed) tools, but also about currently used tools. At this point there is no way to start a remote ap
plication,
i.e., to force the start of certain tools when joining a session. The user himself is responsible for starting the selected
tools. This allows the use of different tools for the same media even within a single session (e.g., two different chat
t
ools working with the same media). Directly after the start of MACS the database entry for an application contains
Databases

User

Application

Session

Libraries

Floor passing

Token

Communication

Control actions

Object
distribution


5

only its name, class name and some technical details used by MACS. After loading an application the class itself is
contained in the applicat
ion database. For each instantiation a link to the corresponding session is stored. So the
application database does not only contain the application descriptions and classes, but also instances of the actually
running applications.

4.1.2

Libraries

Functionality

common to different modules can be integrated into MACS in form of libraries. These are currently
determined at compile time, but in a future version will be loadable, just like applications or session controllers.
Currently only a floor control library i
s provided. It makes several floor policies available (see section 4.2.2 for details)
and can be used by any of the MACS components or applications.

4.1.3

Communication Module

The communication module offers an API to the communication system providing functiona
lity such as session create,
join, invite, modify, leave, expel or terminate. Calls using this API result in the exchange and processing of pre
-
defined
MACS messages by the controls involved. A further function of the communication module is to ensure the
consistency of local and remote control databases. Announcements of new sessions or users are directly propagated to
the corresponding local database. Figure 4 shows how such a message is received by the net (1) and then processed by
the communication modu
le. The database will then be updated (2). Modules interested in receiving notifications about
such events must attach a listener to the corresponding database (3), as it is not possible to receive notification directly
from the communication module.

Figu
re
4
: Message sequence


To show the interactions among the different parts of the system the process of creating a session shall be considered.
The sequence below illustrates the events needed to successfully create the sessio
n. Invitation of the participants is not
considered for brevity:


1.

The user requests a new session from its local control.

2.

The local control checks the available resources and generates a unique session name/id.

3.

The local control sends a create request to
the group of remote controls.

4.

Each remote control checks conflicts and sends a response if a conflict exists.

5.

If no conflicts were detected the local control creates a session entry and enters it into the local database.

6.

The local control starts the sessio
n controller and sends announcements to the group of remote controls.

7.

Each remote control enters the new session based on the received announcement into its session list and
database.

4.2.

Visual Session Controller ViSCO

The session control consists of two part
s: the session controller as such and the visual session control module (ViSCO).
The main component in each session is the session controller. Figure 5 shows a screen dump of the session controller
for a sample scenario with different users that joined an
active session.


6

4.2.1

Design of the GUI of ViSCO

The right hand part of the session tab is used by the application to display their control and data elements. These
elements will be grouped to improve orientation. If the area needed to display the elements incre
ases beyond the
window size, a scrollbar is added to provide access to hidden elements.


The left hand part of the window is owned by the ViSCO module. To avoid confusion of the participants caused by an
immense set of buttons, sliders and the like, ViSCO

aims at creating an easy to use interface by using common
graphical representations for entities and objects in the session. This helps non
-
technical participants to understand the
system and to use it without the often encountered problem of a too steep
learning curve. Furthermore, the feeling of a
real conference scenario is mediated.







Figure
5
: MACS
-
Window

ViSCO performs session control in a virtual meeting room, in which the participants of a se
ssion are represented by
small thumbnails (cf., figure 5). Instead of a thumbnail, a live video stream may be displayed from the participant’s
camera. This feature requires support of the JAVA Media Framework, which is currently under development. For this

reason, this feature is planned for a future release of MACS. If no thumbnail or live video from a user is available, a
symbolic graphical representation is used. Various information about the participant's resources are represented within
the symbols or
thumbnails. Resources in this context refer to available multimedia equipment. If a participant, for
example, is capable of sending audio data, a small microphone icon is displayed above his thumbnail. A loud speaker
represents the capability of listening
to playing back audio information. Information about the states of participants are
likewise represented in a graphical manner. These states reflect the "degree of presence" [GrBe95]. The temporarily
absence of a participant from the conference, for exampl
e, is indicated by the text "I'll be right back" in the graphical
representation.

Due to the fact that only a limited number of users can be visualized in the meeting room, preferable small and medium
conferences are addressed by the graphical session cont
rol. If a conference with a large number of participants shall be
performed with MACS, a different, non graphical, session controller must be used. This is easily possible because
MACS allows the use of different session controllers (cf., section 4.1.1).

current
session

multimedia resources

floor policy selection

session control

applications

chat floor

control

chat

application

session list

user list


7


Session control is performed within the virtual meeting room. Possible actions include joining and leaving a session,
which is done by normal users, and inviting or expelling a participant, which can only performed by the session chair.
For example, to exp
el a user from the conference, the session chair just drags the user’s representation in the meeting
room and moves it to the exit door.


For some conference scenarios, hierarchical structures are desirable. To conduct a confidential conversation to one or
e
more participants without disturbing the main conference, a user may wish to establish a private communication to
other participants. To discuss a former presented topic in detail, the creation of several working groups is desirable. In
this manner, a pa
rticipant can talk only to those participants he prefers.


ViSCO supports such hierarchical conference structures. To conduct a private conversation, a participant drags his
symbol through the virtual meeting room and drops it onto the symbol of the other
participant. As a result, a private
audio channel is established between both participants. This is visible to all other participants, but they aren’t able to
take part in the private communication. It is possible for other participants to join this privat
e communication. This
directly reflects a "conference within a conference" without disturbing the main conference.

As a further scenario, the creation of working groups is also supported. The participants may decide to form several
groups to discuss some
former presented topics in detail. To achieve this, two or more independent discussion groups
are created by the session chair, which the participants can take part in. Each participant is able to participate only in
one group. Interaction among the groups

is not supported.

4.2.2

Floor control library

The floor control library is attached to the session controller. It makes several floor control policies available that are
used to control the applications in a dedicated session. The integrated policies cover both

implicit and explicit
strategies. The implicit strategies, for example, contain policies like fifo, round
-
robin, agenda
-
based etc. Agenda
-
based
means that the floor chair fixes the order of users the floor will be granted to. In explicit strategies it is
up to the floor
chair to determine the next floor holder.


Floor control in MACS is attached with resources, not with entire applications. Each application represents at least one
resource to the floor control. For example, a whiteboard application may rep
resent one resource for drawing and one
for loading slides. Each resource can be assigned with a different floor policy, which offers a great flexibility. The
floors for the specific resources are handled independently from each other, even if they belong
to the same application.
Therefore, it is up to the applications to decide whether they represent one or more resources and accordingly need one
ore more floors. This could be useful especially in a teaching scenario, where the pupils may be allowed to wri
te text
on the teacher’s whiteboard (to ask some questions), but they shouldn’t be allowed to load some slides onto the
whiteboard which could disturb the lesson.


Floor control for several resources, as audio, is performed within the virtual meeting room.

If a conference participant
is requesting the audio floor, a "speaking bubble" is displayed on top of his image, indicating a “raising hand”.
According to the current audio floor policy, the floor is gained (perhaps after a certain delay) either from the
system or
from the floor chair.

5.

Examples of MACS applications

A number of MACS applications are currently under development. To provide some examples the Whiteboard and
TelSEE will be introduced in this section.

5.1.

Whiteboard

The whiteboard developed as a pa
rt of MACS (cf., figure 6) is designed to replace real world mediums like blackboard,
flipchart, overhead
-

or slide
-
projectors and laser pointer with a single tool suited for network based interactive
collaboration. The whiteboard is able to depict postsc
ript
-
pages, JPEG
-

and GIF
-
pictures and animated GIFs along
with graphical primitives like lines, arrows, arcs, rectangles and text. This enables the participants of a session to
prepare slides for a presentation with a tool of their choice, load them into
the whiteboard and eventually enhance some
tools during the demonstration. It is possible to place a marker on the drawing panel to focus the attention on certain
topics. The whiteboard imposes no restriction on the number of different pages it is able to
manage. The user may
scroll through the available pages and change their content or create new ones. The possible changes are restricted to
objects created with the whiteboard, excluding imported postscript files and images.


The tele
-
pointer function of t
he MACS whiteboard enables the participants of a session to follow the mouse
movements of the currently active user. This is achieved by propagating every mouse position change to the other
whiteboards, where a mouse
-
pointer symbol is painted on the corres
ponding position. To avoid an overflow of these

8

symbols the receive of mouse
-
pointer movements can be disabled. The whiteboard offers the possibility to suppress the
sending or receiving of tele
-
pointer messages individually, if the user has no interest in

them.

For the use of the whiteboard in a collaborative session, it is important that all actions of a user are almost instantly
visible to the other users. This is implemented by propagating every object creation or modification as well as every
action ev
ent of one whiteboard to all other whiteboards. For example, if one user draws a line all other users are able to
follow the drawing process on their whiteboard. The communication overhead imposed through the propagation of
every action event is significan
tly reduced if the whiteboard uses a multicast implementation for its network
communication, e.g. LRMP that is integrated in the MACS framework.


To guarantee the consistency of data presented by the whiteboard, all content objects are identified by an own
er
-

and
sequence number, as well as by a timestamp. If a user starts a whiteboard and joins a session, his whiteboard will send
an enter conference message to other whiteboards in the group. As an answer to this first message, the new whiteboard
will recei
ve object creation messages from the other whiteboards in the session. Each whiteboard owns the objects
created by it and is responsible for their update. If a whiteboard leaves a session, the responsibility for all the objects
created by this whiteboard w
ill be transferred to another whiteboard. Thus, contents of the whiteboard session are
always available and up to date as long as a session exists. To reduce network load on startup of a new whiteboard, big
objects like pictures and postscript pages are tr
ansferred only on demand.


Figure
6
: Whiteboard


The whiteboard can be used outside the MACS framework or together with the MBone
-
tools. This has already been
successfully demonstrated in a tele
-
teaching project [ZBHB98], [St
EZ98].

file operations

clipboard

graphical elements

font size

colors

pages

pagin
g

slide import

tele
-
marker


9

5.2.

TelSEE

The distributed multi
-
user CASE
-
tool TelSEE (Tele Software Engineering Editor) is developed as a part of the MACS
project. Its objective is to present an extensible environment for distributed software development, including text
editors, di
agram editors and versioning tools. As a MACS application, TelSEE has access to the databases and facilities
of MACS. The user database, for example, is used to gain information on the status of participants of a session.
Depending on the information store
d there, MACS will behave differently when processing a communication request
from TelSEE. If the users are online the result might be a video
-

and audio conference (again, depending on the
facilities the corresponding user possesses and announced to the d
atabase) or MACS might suggest a recorded
notification. TelSEE can be started from sessions or initiate new sessions on user demand. The user interface of
TelSEE is shown in figure 7.


A typical application for TelSEE can be seen in the implementation of

a software project that involves a group of
distributed developers. They can start a new project through an online video
-

and audio
-
conference using the features
provided by MACS (e.g., Whiteboard) to outline their work and define the work packages for ea
ch participant. TelSEE
provides the facility to create and maintain a project consisting of smaller units such as subprojects, files and parts of
files. Single developers work on their special part of the project and TelSEE is responsible to propagate chan
ges to the
other developers. The update of the project status may be done manually by the users or automatically by TelSEE. The
delayed update may cause consistency conflicts if two or more users are working on the same object. Such a conflict is
detected
by TelSEE. If there is no automated conflict resolution implemented for the object, TelSEE will create a
communication connection through MACS among the involved parties, bringing them from asynchronous to
synchronous work.

Figure
7
: TelSEE


TelSEE is build on top of NetMVC, that is an enhancement of the MVC (Model View Controller) design pattern
[GHJV95]. The MVC pattern is often used in interactive programs to decouple object data from its representation on
screen. By using
a subscribe/notify protocol, any number of user interfaces (a summary of the view/controller part of
MVC) may connect to the data models they represent. A change in the representation of an object is delegated to the
data model, which in turn notifies all
dependent user interfaces of the new object state. This design appears to be well
suited to support distributed applications in the context of CSCW.


To improve the interactivity of a distributed application, networked MVC replicates special versions of th
e data model
objects, so
-
called proxy objects, on the local system. It is the responsibility of the proxy objects to communicate with

10

the appropriate data models. This is done transparently to the application. Besides better application performance, the
ob
ject replication achieves for users the possibility to create their own private views on a project by delaying the object
updates. Thus, limitations imposed by the strict WYSIWIS (What You See Is What I See) are reduced.

6.

Conclusion

MACS provides an advanc
ed CSCW framework that is flexible, modular and portable. It allows an easy integration of
applications, such as TelSEE. The extended session control and ease of use provides an easy to use interface for
computer user. Computer experts and developers can i
ntegrate individual applications and, thus, customize MACS to
their needs. The Java implementation allows the deployment of the system in today's typically heterogeneous
environments.


Approaches to extend the interoperability to ITU T.120 and H.323 based
systems are currently investigated. As soon as
media capture is integrated into Java, audio
-

and video
-
tools for the MACS framework will be implemented.
Furthermore there are plans to expand the facilities of MACS by providing more applications like, for e
xample, a
voting tool, to augment the functionality of the available applications.




11

References


[CGJP98]

A. Chabert, E. Grossman, L. Jackson, S. Pietrowicz, C. Seguin "Java Object
-
Sharing in Habanero",
Communications of the ACM, pp. 69
-
76, Vol.41, No. 6,

June 1998


[GHJV95]

E. Gamma, R. Helm, R. Johnson, J. Vlissides "Design Patterns: Elements of Reusable Object
-
Oriented
Software", Addison
-
Wesley, 1995


[GrBe95]

C. Greenhalgh, S. Benford, “MASSIVE: A Collaborative Virtual Environment for Tele
-
conferencing
”,
ACM Transactions on Computer Human Interfaces (TOCHI), Vol. 2, Number 3, p. 239


261, September
1995


[H323]

ITU Recommendation H.323, November 1996


[Kuma96]

V. Kumar, "Mbone
-

Interactive Multimedia on the Internet", New Riders, Indianapolis, 1996


[LDAP]

M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)" RFC2251, December 1997


[JNDI]

Sun Micro Systems, http://www.javasoft.com/


[Liao]

T. Liao, "LRMP
-

Light
-
weight Reliable Multicast Protocol as an Extension to RTP", INRIA,
http://monet.inria.fr/lrmp/lrmp_rtp.html


[ShGe97]

S. Shirmohammadi, N.D. Geroganas, "JETS: a Java
-
Enabled Telecollaboration System", proc. IEEE
International Conference on Multimedia Computing and Systems, pp. 541
-
547, June 1997.


[StEZ98]

D. Sturzebeche
r, O. Eggers, M. Zitterbart, "IBR
-
Whiteboard: An advanced whiteboard to improve tele
-
teaching", IN
-
TELE 1998, Strasbourg, France, 1998


[Tngo]

L. Beca, G. Cheng, G. C. Fox, T. Jurga, K. Olszewski, M. Podgorny, P. Sokolowski, T. Stachowiak, K.
Walczak "TA
NGO
-

a Collaborative Environment for the World
-
Wide Web", NPAC, Syracuse
University, New York, USA, "http://trurl.npac.syr.edu/tango/Documentation/Papers/papers.html”


[T120]

ITU Recommendation T.120, Proposed Draft (Study Group 8), October 1994


[ZBHB98
]

M. Zitterbart, A. Boeger, T. Harbaum, O. Brand, "Teaching Computer Networks across Networks",
EDEN Annual Conference, Bologna, Italy, June 1998