CS 778/878 Networked Multimedia Systems

Course Project

S P I C E

Simple Platform-Independent Interactive Collaborative Environment

We call this course project "SPICE" since each letter in the name
reflects one of the project objective:

Simple: to provide a system that can be used by a small group of collaborators. For example, the system could be used by a group of 2-4 students working together on a common project or helping each other on homework. the students could be anywhere, e.g., at homes, dorms, offices or labs.

The Simplicity characteristics are:

• Invocation and set up: Any user can start up a new Session or join any session by typing one simple command or clicking into an icon. We do not force the user to specify values for things like ENVIRINMENT variables (e.g., CLASSPATH), IP addresses, etc. commonly required by many systems which impede the use of the system and discourage users from using the system.

• May function in the absence of some components. We leave it up to the user to determine whether it makes sense to participate in the session if some components are not available or functioning (e.g., no camera).

• The user interface should be kept as simple as possible and avoid giving the user excessive  control and options (e.g., vic and vat interfaces  present the user with too many functions and too much details to control the devices which are rarely used by many users).

Interactive: The system is used live, thus responsiveness is critical. The quality of audio should be high, even if we have to degrade the quality of video (e.g., use still images or low frame rate).

Collaborative Environment: The system is not just audio/video conferencing system, it is used primarily to aid collaboration among a group and thus has to provide an array of shared data tools and applications. The most common used tools are shared white board, presentation tool and application sharing. The design should allow the system to be Extendable by adding/deleting any such collaborative tools.

A. Communications Issues

1. SPICE server

The system is based on the existence of a central Server called SPICE server, where all participants are permanently connected with TCP as shown in  Figure 1 .  A breakdown  of the connection is an  indication of trouble and may result in corrective action by the system. The server is just a mediator/facilitator that helps participants connect to each other and exchange control information among themselves.


Server location and startup:

Where the super server should reside?. One possibility is the host of the first participant. In such case, should the server start automatically as an integral part of the first client or start it separately.  However, there are situations where the server should run on a separate host. For example, consider the case where the first participant is using a home PC connected with 24 Kbps modem to the Internet. In such case it is more appropriate that the server should be located at another place such as a workstation located in  the main campus. SPICE should be designed to accommodate these divers situations.
 

2. SPICE Inter-Client Communications

Among the many possible topologies and communications alternatives,
we have adopted the following three schemes.

Server-based

 Figure 2: shows the overall archeticture of the this scheme.
The  SPICE server acts as the communication hub.
This architecture is simple but the delay communication delay  is doubled.

Complete-Graph-based

Multicast-based

 Figure 4: If all Participants are linked with LAN that supports multicast, we should use multicast for audio and video. As for reliable data streams, we could use either a complete or server-based TCP connections.  In this figure we choose to use a server-based TCP connections.  For those participants who can't use multicasting,
they may use tunneling through the server.

Start with the assumption that all participants can use multicasting. When a new participant P joins, the server conduct a Multicast-test to see if the server can communicate with P using multicasting. If NOT, the tunneling is used to connect P to others.

How Participants knows about specific  SPICE server?. Either manually (by mail or phone), or automatically by contacting a super server that runs on a well known machine/port as shown in Figure 5 . The best solution is to use the automatic solution, but downgrade to use the manual in case the super server is not running or the host where it is running is not reachable.

For this phase of the project, we will not implement the super-server.

Since the current version of JMF does not allow the capture process to use the audio device while a JMF audio player is active, we will not use JMF audio in  SPICE. We then have two alternatives:

1. USE C similar to   IRILite audio processing.
2. Use Java/native methods similar to JCE audio processing.

All teams will use JMF video player for receiving and displaying the video windows of all participnats (at most four windows).  There are two examples that might be used as a guide: JCE and IRILite (as a seperate subproject). However, since the current release of JMF has no capturing component, we will use an already available C video capturing programs
that send video packets as RTP traffic  as required by JMF.

Each team may select to integrate in SPICE  any subset of the avialable application sharing tools. Some of these tools are already used in IRIlite such as White Board (Java application) and XTV (X windows application).
A team may search the Internet and take an existing tool, possible enhance it, and then integrate it with their version of SPICE.
 

We have decided to produce three versions of SPICE by three small teams. Table 1 shows the team members and the communication scheme assigned to each team. In addition, we have created three UNIX groups and directories:

/home/irilite/SPICE/{spice1, spice2, spice3}