[New Zealand Digital Library] [Computer Science Technical Reports] [Query Results] ---------------------------------------------------------------------------- CERC Technical Report Series Research Note CERC-TR-RN-91-009 MONET: A Multi-media System for Conferencing and Application Sharing in Distributed Systems Kankanahalli Srinivas Ramana Reddy Aliasghar babadi Srinivas Kamana Vinay Kumar Zhao Dai Feb 1992 ACKNOWLEDGEMENT: This effort has been sponsored by Defense Advance Research Projects Agency (DARPA), under contract No. MDA972-88-C-0047 for DARPA Initiative in Concurrent Engineering (DICE). Concurrent Engineering Research Center West Virginia Univeraisity 955 Hartman Run Road, Drawer 2000, Morgantown WV 26505 ---------------------------------------------------------------------------- MONET:A Multi-media System for Conferencing and Application Sharing in Distributed Systems1 Kankanahalli Srinivas Ramana Reddy Aliasghar Babadi Srinivas Kamana Vinay Kumar Zhao Dai Concurrent Engineering Research Center & Computer Science Dept. West Virginia University Abstract: MONET is a multimedia conferencing system which facilitates colocation and cooperation among geographically-dispersed people ( the virtual team)in a networked environment. The collocation of people is achieved by providing effective communication mechanisms using multiple-media including audio, video and graphics.The cooperation among the members of the virtual team is enabled by a conferencing system, whose capabilities include transparent access to the resources in the network using directory services, sharing X-window applications simultaneously by multiple participants across the network and the ability to communicate using real-time audio, real-time video, images, graphics and CAD data. 1. Introduction Solutions to complex engineering and scientific problems require the functional expertise of many diverse areas and hence dictates cooperation of multiple people working as a problem solving team. When the members of the problem solving team are not in the same place at the same time, the synergy between team members is absent. To aleviate this problem the notion of a virtual team is proposed. A virtual team consists of physically dislocated team members virtually colocated using the computer and communication technologies to form a cooperative environment. People can effectively communicate with each other in person and in face-to-face meetings because they can see each other, notice each others facial expressions, hear each others voices 1. This work has been sponsored by the Defense Advanced Research Projects Agency(DARPA), under contract No.MDA972-88-C-0047. for DARPA Initiative in Concurrent Engineering(DICE). ---------------------------------------------------------------------------- clearly and use blackboards and other media to draw pictures, to take notes and to point to things. Since effective communication is crucial for cooperative work, systems that provide computer support for cooperative work should provide an environment that emulates face-to-face meetings. In fact computer based cooperative environements provide currently in most physically colocated meetings and conferences, the participants are not equipped with their ideal tools that make them effective. In other words they are dislocated from their ideal work environment. MONET is a computer-based, real-time multimedia conferencing system to facilitate collocation of people , computers and information resources.. It is an enabling tool for effective communication and cooperation amongst multiple participants over a computer network (Srinivas et al. 1991). Such systems are known as Desktop Conferencing Systems (Ahuja et al. 1988; Sarin & Greif, 1985, Vin et al, 1991, Watabe et al, 1990).The need for such systems arise from the fact that most office workers spend a large percentage (20 - 70%) of their time attending meetings and conferences (Stefik et al.1987). Currently, the only existing tools that enable interaction and collaboration are electronic mail and file transfer (Abdel-Whippet al.1988), which are primarily asynchronous in nature and hence do not provide the ability to communicate in real-time. The other motivation for desktop conferencing systems stems from the fact that increased processor speeds and higher network bandwidths have made multimedia -based desktop conferencing systems a reality. Desktop conferencing systems such as MONET, provide a viable tool for collaboration and interaction, not only by reducing travel expenses, time and effort required for geographically dispersed collaborators, but also by providing efficient and transparent mechanisms for sharing of programs and data over a distributed computer network. This paper is organized as follows: section 2 briefly describes the system architecture. Directory services are described in section 3. Section 4 describes the conferencing capabilities of the system. We discuss application sharing in section5 and multimedia services in section 6. 2. System Architecture The architecture of MONET is shown in Figure 1. The system consists of a directory server, a conference server, a multimedia server, an applications sharing server, and a common X- window based user interface which provides easy access to all the services provided by these servers. 3. Directory Services The directory server is responsible for providing directory and registration services in MONET. The role of directory services is to provide a catalog of various resources such as people, machines and tools across the network. This aids in transparent access to the various resources scattered over the network.The intention of these directory services is to provide one unified logical name space, which actually may comprise of different systems, people and applications. ---------------------------------------------------------------------------- Figure 1. MONET System Architecture Registration services deals with registering participants and groups for conferences that are frequent in nature. Preregistration of conference participants saves the conference initiator from calling each of the individual participants. In addition to registration services, the directory server provides a number of additional capabilities such as: Console Ownership and Display Characteristics Identification: Traditionally, directory services provide information about machines, login characteristics, people currently logged on and some other information about some of the applications resident on the machine. However, in a conferencing system based on a windowing system such as X-windows, console ownership identification is also important. In a conference utilizing multiple media display characteristics are important because different displays have different characteristics. If the information such as number of bit planes, the active window manager (such as uwm, twm, mwm, etc.), color characteristics are available to the conference server, it can automatically process the images and render it appropriately for the targeted display. Expertise Identification: In many scenarios such as integrated product design, the need to confer with a person with a particular expertise arises. For example, while designing a complex VLSI chip, the logic designer may need to confer with the manufacturing engineer or the process engineer. So the directory server should be able to identify people based on their expertise. Conference Application Sharing Server Multimedia Server User Interface Applications Server Directory Server ---------------------------------------------------------------------------- Application Location Identification: For the conference to be natural and effective, tools and data should be seamlessly shared amongst the various participants. Since the application sharing server facilitates multiple participants to share a single-user application, the directory server should provide information about the location of these applications such as CAD tools, analysis tools and other useful applications. The directory server is implemented as a part of Local Communication Manager (LCM) (Kannan et. al, 1990) which is a collection of hierarchical and layered modules which provide user level services for distributed computing. The directory service here extends the functionality of other types of directory service to suit the conferencing needs. We are also investigating the use of systems such as the Wide Area Information Server (WAIS) from Thinking Machines Corporation as a mechanism for implementing directory services. 4. Conferencing The conferencing capabilities of the system are provided by the conference server. The conference server manages the conference and interacts with the application sharing server, the directory server, the multimedia server and the client or the application. The graphical user interface provides access to the various system services of MONET. . The communications infrastructure for the conference is provided by UNIX-BSD sockets and TCP/IP protocols. Each conference server waits for messages by listening on a pre-assigned port. The server manages multiple conferences by associating a unique value to each conference, which is shared by other involved servers. Messages from any participant that could lead to a change in the current status of the conference are sent to every server of a particular conference.There are seven types of messages by which the server manages one or more conferences. They are elaborated below with a state transition diagram (Figure 2). Originate_Conference: Every client program begins by sending a message of this type to its sever. The server acknowledges this message with a packet containing information about the number of current participants in the conference. Upon receiving this message, the server makes a state transition from the idle state to the initiate state. Call_Participant: The conference initiator sends this message to servers of all those participants who have registered for a conference. The server on each individual?s machine checks the availability of the person and if currently available, notifies the originator of the call. This also causes a state transition from the idle state to the notify state. Not_Responding: If a callee is unavailable, the server on the callee?s machine broadcasts a message of this type to all the other servers in the conference. Each of these servers in turn notify the participants on their respective machines. In situations where an outstanding acknowledgment exists (i.e. no response from the callee), the server preserves its state till the server receives an acknowledgment. The server makes a state transition from notify call to idle state. It periodically notifies the user of the conference and also checks for any change in the particpants status ---------------------------------------------------------------------------- Refuse_Connection: When a callee voluntarily refuses to join the conference, each server is sent a message of this type. The server updates the conference and makes a state transition from the notify call state to the idle state. Accept_Connection: If the callee accepts the call, this message is sent to all the servers. The server updates the conference information. If there are any previous messages that have been saved for this callee, the server forwards these messages to the callee to update the conference list of the client. If the server is in either initiate or notify call state, this message drives the server to the active state. Add_Particpants: When additional members need to be requested into the conference, this message is sent by the conference chairperson to all servers of the current participants of the conference. The server updates the conference list and forwards the same message to participants associated with this server. In contrast, the chairperson sends a Call_Participant message to the servers of the callees. The server loops in the active state on receipt of this message. Exit_Conference: When a participant decides to quit a conference, a message of this type is sent to all servers which in turn is forwarded to other participants on each server. The conference list is updated and if there are no other persons in the conference for a server, the conference is eliminated. Also, the server which managed the exiting participant checks to see if there are any other local participants for which it need to manage this conference and if not, the conference is removed and the server returns to idle state. Here too, a message might be enqueued by the server for possible outstanding participants. If the exiting person were the chairperson, the privileges of this person are passed on to a designated person in the conference by the chair, thus ensuring protocol consistency. Figure 2. State Transition Diagram of the Conference Server. Idle Originate_ Conference Notify CallInitiate Active Add_Participants *Not_Responding Accept_Connection Call_ *Exit_Conference *Refuse_Connection Participant ---------------------------------------------------------------------------- The person wishing to initiate the conference can browse the directory by requesting the directory server to display the list of potential participants.Once the list is displayed he/she can click on the appropriate names to initiate the conference. This person thus assumes the role of the conference chairperson and the conference is initiated by automatically notifying all the invitees with the help of an acknowledgment window on their displays and accompanied by a ringer (Figure 3). The notified persons can accept or refuse to participate in the conference. Once a subset of the requested participants join, the conference proceeds. The system also displays the icons of the current participants of the conference. It permits further additions to the conference as it progresses and the chairperson can also transfer the privileges to the next person in the conference if he/she decides to quit. A server allows for the existence of multiple participants in a given conference and the existence of multiple conferences on the same machine. In summary, the system allows the following transactions: . View and browse the directory of possible participants . Initiate a conference. . Accept a call or refuse to join an ongoing conference. . Invite additional people to participate. . Leave a conference. * Communicate with selected participants in a whisper mode. . Display the conference theme and the participant list. . Tag a file to the current text message. . Share on-screen images between participants by screen grabs. . Archive the conference proceedings. . Retrieve specific parts based on keywords and other suitable indexing schemes. Figure 3. Invitation window or call for participation in the conference accompanied by a Ringer. ---------------------------------------------------------------------------- Figure 4. Participant icons and the conference window. 5. Application Sharing X based application programs (or X-clients) can be shared over the network using the applications sharing server. The applications sharing server is also known as COoperative Multiuser Interface to X applications (COMIX) (Babadi, 1990). This module facilitates several users to view the graphical output of any existing single user X application at their screen and interact with the application from their workstations. In otherwords, a single application such as a drawing program can be shared by multiple conference participants providing them with a Shared or Group workspace. This sharing is transparent to the application, so any X based application can be shared without the need for any source code modifications, recompilation or linking to any specific libraries. There is only a single copy of application running but the graphical output is shared amongst several screens over a network. The X-server that is active when the X-client is first initiated is referred to as the primary server. ---------------------------------------------------------------------------- Only one instance of the application sharing server is enough to support a sharing application session and can run at any machine in the network. Since a single copy of a single-user application is shared amongst multiple users, there exists a need to serialize the inputs given by the multiple users. This serialization is achieved by using floor control or chalk passing mechanisms (See 5.1). The client server model of the X-window system is shown in Figure 5. The X-server controls all accesses to the input as well as output devices. The typical input devices include the mouse and the keyboard and display screens form the typical output device. Figure 5. Client Server Model of X Window System. Applications request different services from the server, for example a request to create a window. The X-server services these client requests in addition to transmission of events (such as keypress or mouse click) and other information (reply and error packets) to the client.The X-server listens for client requests at some prespecified ports. The particular port number is dependent on the communication protocol used for interaction amongst the client and the server.With TCP/IP connections the X-server listens on port 6000+D, where D is display number (6000 is the default port used for connection to X server). X-clients can connect to the server via the display parameter. In the process of application sharing, the set of transactions between the shared x-client and the application sharing server (COMIX) is called a session. Every application that is shared during the conference is deemed a unique session. The application sharing server is like a transparent layer between the client and the server. It uses the above feature to intercept the protocol stream between the client and the server by listening on port 6000+i (i > 0), where i is the session number. As shown in Figure 6, clients can connect to application sharing server on port 6000+i via display parameter and The application sharing server connects to the X-servers which are listening on port 6000 + 0 (usually the display is 0). X Application X Server Network or Client ---------------------------------------------------------------------------- Figure 6. Architecture of Application Sharing Server. The participant initiating a client can select the list of participants he/she wishes to share the application with. In the conferencing scenario, if no specific list is specified by the initiator of the client, the client will be shared by all the participants in the conference. The application sharing server (COMIX) uses this information to identify the X-servers of the selected participants and establish connections with them. Clients issue requests to connect to COMIX which are handled by the server. In the handleconnection state the server inturn broadcasts the connection request to all the X-servers of the conference participants. After establishing the connections, necessary information about the various resources of the X- servers and connection information is saved in the store server information state. Some of this information is also forwarded to the client. The client continues to send the request packets as a byte stream. This byte stream is processed to identify the request packets which corresponds to the state identify packets. After identifying the request packets, they are further decoded to determine the request type. After determining the request type (i.e. create GC request), the request is appropriately translated for each X-server. This translation is necessary due to the following reasons. The original request from the client is intended for the primary X-server (the initiator or chairman?s X-server). But now, the application has to be shared amongst multiple X-servers possibly using different resources X Client Application Sharing Server X Server 1 X Server 2 X server N . Network . . . ---------------------------------------------------------------------------- thereby necessitating a translation. The translated and modified request is then sent to the appropriate X-server. The request packets from the servers undergo a similar transformation. The application sharing server actually permits only one X-server to send data back to the client at any point in time. This is necessary because the client is originally designed to interact with a single X-server. Furthermore, the client only executes on one machine on the network and since it is shared by multiple participants, there exists a need for concurrency control and serialization of requests. These features are achieved by a chalk passing mechanism. Chalk passing mechanisms are also known as floor control protocols. The floor control protocol ensures that only one participant has the chalk at any point in time. Floor control protocols are discussed in detail in the next subsection. From the client?s perspective, its only interaction is with the primary X-server. The packets from various X-servers (Event, Reply and Error Packets) will be identified and decoded to determine the specific request type (i.e. mouse click event). These request types will be translated appropriately depending on the primary server resources and then shipped to the client. The client is hence given the illusion of sending and receiving requests only to and from the primary X-server. The initiator of the application sharing server is called the chairperson or primary user.The chairperson has the privileges to pass the control to other participants or get the control back at any time. Users can request for the chalk and they are informed upon receipt of the chalk. When a participant releases the chalk the chairperson is notified so that he/she can pass the control to other participants requesting it. The chairperson can take the chalk back even if the participant holding the chalk have not released the chalk. This type of chalk passing method is provided to give maximum control to the initiator. Other methods for chalk passing described below are also being implemented. 5.1 Floor Control Protocols When a single user application is shared amongst multiple conference participants, the window executing the application is shared and every user is in a WYSIWIS (What You See Is What I See) mode. However, since the application is a single user one, only one participant may provide input to the application. The serialization of input from multiple participants is achieved using a Floor Control or Chalk Passing protocols. The various preemptive floor control protocols are Centralized Chairperson: The person initiating the conference becomes the chairperson by default and the chairperson has the chalk. The chairperson can pass the chalk to any of the conference participants requesting the chalk, upon his discretion and can get the chalk form a user at any time. Users can request for the chalk but they are not allowed to pass the chalk amongst themselves. If a user is done with the chalk he can release the chalk and the chalk will be passed to the chairperson (Figure 8). FIFO with time limit: In this method there is a maximum time-limit M for which a user can possess the chalk.If the chalk is free and there is a request for the chalk, the requester gets the chalk. If the chalk is not free requests are queued. If the chalk holder has used his time limit a message will be sent to him that the chalk will be taken in some period T of time. After time period T is ---------------------------------------------------------------------------- over, the chalk will be given to the first requesting person in the queue. If the chalk holder has not used his time limit he can use the chalk up to his time limit. The chalk holder can use the chalk for any amount of time if there are no pending requests. Combination: This method is s combination of centralized and FIFO with time limit.In this method the chairperson can get the chalk form a user at any time and can give the chalk to a user even if he is not the first in the request queue. If the chairperson does not interfere the control will be passed as in FIFO with time limit. The State transition diagram of the Application Sharing server (COMIX) is shown in Figure 7. Figure 9 shows a drawing application called idraw being shared by two participants namely, Zhao and Ali on two different machines named Preston and Randolph respectively. The participants window indicates the current participants in the conference. The chalk control window indicates the current chalk holder, the chairman who has the authority to relinquish the chalk and the list of participants who have requested the chalk. Figure 7. State Transition Diagram of the Application Sharing Server (COMIX) X Servers X ServersX Servers X Client Identify Packets Decode Packets Translate Packets Handle ConnectionRequest to Request to Connect to X serversConnect to COMIX Request Event, Reply and Error Data Packet Decoded Packet Translated and Modified Packets for each X server Translated and Modified Packets for the X Client Data X Client Store Server Information Server Info. Primary Server Info. X Servers X Servers ---------------------------------------------------------------------------- Figure 8. Initiator?s control window using Centralized Chairperson floor control protocol. Figure 9. Application Sharing Server is used to share the drawing application idraw between two users. ---------------------------------------------------------------------------- 6. Multimedia Services The multimedia services are provided by the multimedia server shown in Figure 9. Clients requiring multimedia support for their transactions, send these requests to the multimedia server. 6.1 Audio Desktop conferencing systems should support interchange of audio data since voice is the most effective form of communication used among humans.(Crowcroftd et al. 1991; Jeffay & Smith, 1991). The audio conference server uses a connectionless datagram service to transmit audio packets. It is well designed to completely support the state changing activities of a conference such as calling, joining and exiting. If two or more participants were allowed to speak simultaneously, the audio data recieved by a participant will be interleaved and most likely be incomprehensible. This scenario is avoided by providing central control over the microphone to the chairman and passing this control upon request to other participants as has been explained earliar for sharing applications. An important feature of the server involves silence supression so that the audio data packets over the network are minimized thereby improving the efficiency in delivering audio to meet timing constraints. Additional features of this system are listed as follows. . Customizing recording and playback levels of a participant?s input and output data. . Adjusting the silence supression level to account for noisy environs at a particular site. . Ability to have a sidechat with a member of the conference by briefly interrupting the main conference and retuning to it at the end of the sidechat session. . Turning the sound compression off or on at the audio input end. 6.2 Video The effectiveness of communication is enhanced by video transmissions (Watabe et al. 1990). Participants can discuss on a friendlier basis and accelerate progress of informal discussions with real-time shared video. Also in situations involving negotiations amongst participants, video helps (Ensor, et. al, 1991). It is also useful when machine parts and assemblies are to be diagnosed. In our current implementation, the video capture is done using CCD cameras connected to Parallax boards. A separate coaxial video network carries the video signals to multiple workstations. Real-time video transmission requires a large amount of bandwidth (~ 150 Mb/s) which is currently not supported by existing local area networks such as Ethernet.We are investigating dynamic compression techniques using Digital Video Interactive (DVI).We are also investigating high bandwidth video transmission using Broadband ISDN (BISDN). 6.3 Graphics Graphics media is necessary when the interaction amongst participants is complex. Graphics aids perception. Graphics exchange is very crucial in engineering design scenarios where CAD and graphics data form an integral part of the interaction. MONET supports many X-window based graphics programs such as idraw, Xfig and others. ---------------------------------------------------------------------------- Figure 10. State Transition Diagram for the Multimedia Server 6.4 Multimedia Server One of the major issues in the design of multimedia server is that of intermedia synchronization. The isochronous nature of voice and video data imposes a set of timing constraints. These timing constraints become exceedingly important in systems such as MONET, due to its distributed nature and its use of digital media for physical transmission. More specifically, the network introduces transmission and packetization delays and analog to digital conversions introduce sampling and other delays. In packet switched networks lost packets and packets arriving in the wrong sequence are additional sources of jitter. Synchronization in the multimedia context refers to mechanisms employed by different media Client Identify Request Identify media type Identify media type Input Request Output Request Video Audioaudio video composite Video Audio Introduce synchronization events Process synchronization events video audio composite video stream video stream audio stream audio stream Decompress Decompress Sampling and compress Sampling and compress input device input device output device output device N E T W O R K ---------------------------------------------------------------------------- (and/or their related processes) to achieve coordination and right ordering in the time domain (Steinmetz, 1990, Nicolaou, 1990). This type of synchronization is also referred to as intermedia synchronization. In our multimedia server, we are investigating upcall based intermedia synchronization using stream variables similar to the techniques described in Nicolaou (1990). We are currently designing hardware mechanisms for introducing and processing synchronization events. MONET also supports asynchronous multimedia interchange by providing a multimedia mail and archival system. In the conferencing context, multimedia conference transactions are archived for future reference. 6.5 Multimedia Mail and Archival System In the current version MONET supports voice mail and archival of audio data. Audio input from an external microphone is digitized using and analog to digital converter. The digitized samples are stored as audio files in compressed unix file formats. This feature will be used to archive the conference proceedings by the conference server. The digitized audio files can be augmented with graphics, text and other media and shipped over the network after appropriately encoding the file in a format suitable for transmission using the mail transfer protocol. The voice mail and archival system has an X-window based user interface as shown in Figure10 for accessing various system functions such as: Prepare Mail: To annotate voice files with text and/or graphics. Record Message: To record voice through an external microphone. Play Message: To playback the recorded voice message or to play the voice (annotated) message received. Send Mail: To mail the voice (or annotated) message to a distant user(s). Receive Mail: To display the list of voice-mails received and to decode the file and separate the various media into appropriate formats. The application is developed in a modular fashion, isolating the audio specific functions so that it can be easily ported in future to a more desirable networked audio-server environment. The digital audio sampling, audio output gain is software controlled and the resulting audio quality is equivalent to that used in telephony. ---------------------------------------------------------------------------- Figure 11. Voice Mail and Archival System 7. Future Developments We are currently investigating the operating system support needed for building integrated applications such as MONET. When multiple media is transmitted using extremely high bandwidth channels, one is faced with numerous resource control and synchronization problems. Audio signals also provide real-time delivery constraints which are not handled in Unix like operating systems. We are also investigating techniques for updating data and providing control for participants who join the conference long after it?s initiation. 8. Acknowledgments We are grateful to Wayne Uejio, Joe Cleetus and Bob Shank for their insights and constructive criticisms. ---------------------------------------------------------------------------- 9. References [1] Abdel-Wahab, H. M., Guan, S. & Nievergelt, J., 1988. Shared Workspaces for Group Collaboration: An Experiment using Internet and Unix Interprocess Communications.IEEE Communications Magazine, November,pp. 10-16. [2] Ahuja, S. R., Ensor, J & Horn, D., 1988. The Rapport Multimedia Conferencing System. Proceedings of the Conference on Office Automation Systems, Palo Alto, pp. 1-8. [3] Babadi, A. 1990. Cooperative Multiuser Interface to X-applications. Masters Project, Department of Computer Science, West Virginia University. [4] Crowcroft, J., Kirstein, P. T. & Timm, D., 1991. Multimedia TeleConferencing over International Packet Switched Networks. Proceedings of TriComm 91, Chapel Hill, NC, pp. 23-33. [5] Ensor, J.R., Ahuja, S.R., Connaghan, R.,Horn, D., Pack, M. &Seligmann, D.D. 1991. Control Issues in Multimedia Conferencing Proceedings of TriComm 91, Chapel Hill,NC, pp. 133-143 . [6] Vin, H.M., Zellweger, P.T., Swinehart, D.C. & Rangan, P.V. 1991. Multimedia Conferencing in the Etherphone Environment. IEEE Computer, October, pp 69-79. [7] Jeffay, K. & Smith, F. D., 1991. System Design for Workstation-Based Conferencing with Digital Audio and Video Proceedings of TriComm 91, Chapel Hill, NC, pp. 169-177. [8] Kannan, R., Cleetus, K. J. & Reddy, Y.V. 1990. The Local Concurrency Manager in Distributed Computing. Proceedings of the Second National Symposium on Concurrent Engineering, Morgantown, W.V. pp 219-240. [9] Nicolaou, C. 1990. An Architecture for Real-Time Multimedia Communication Systems. IEEE Journal on Selected Areas in Communications, Vol. 8, No. 3, April, pp. 391-400. [10] Sarin, S. & Greif, I., 1985. Computer-based Real-time Conferencing Systems. IEEE Computer, vol. 18, No. 10, pp 33-45. [11] Srinivas, K., Reddy, Y.V., Chang, L., Babadi, A., Kamana, S., Dai, Z. &Kumar, V. 1991. MONET: A Multimedia Conferencing System for Collocating People and Programs. Proceedings of the CALS & CE Third National Conference on Concurrent Engineering, Washington, D.C. pp 433-441. [12 Stefik, M., Bobrow, D. G., Foster, G., Lanning, S. & Tatar, S., 1987. WYSIWIS Revisited: Early Experiences with Multiuser Interfaces. ACM Transactions on Office Information Systems, vol. 5, No. 2, pp.147-167. [13] Steinmetz, R.,. 1990. Synchronization Properties in Multimedia Systems,IEEE Journal on Selected Areas in Communications, Vol. 8, No. 3, April, pp. 401-412. ---------------------------------------------------------------------------- [14] Watabe, K., Sakata, S., Maeno, K., Fukuoka, H. & Ohmori, T. 1990. Distributed Multiparty Desktop Conferencing System: MERMAID Proceedings of the Conference on Computer - Supported Cooperative Work, CSCW 90, Los Angeles, pp. 27-38. ----------------------------------------------------------------------------