Shared Whiteboard for collaborative
computing using Java Multicast and RTP

Program Documentation

Evelyn Lai-Tee Cheok
Center for Telecommunications Research
801 Schapiro Research Building
Department of Electrical Engineering
Columbia University
New York, NY 10027

Chi-Hao Li
Department of Computer Science
Columbia University
New York, NY 10027

Abstract

Future computing environments will be designed to support interaction with people at least as much as with computers. With the increase in the use of computers for human interaction, the drive is towards developing a collaborative and distributed computing environments. This project focuses on building chat tool and white board for collaborative computing. Our approach is to develop the application using Java multicast and Real-Time Transport Protocol (RTP) as the underlying transport protocol. This project report focuses on the suitability of using such an approach in implementing groupware application. Java programming language is used since it represents state-of-the-art in platform-independent application development.


1. System and Software Requirements

Since this application is developed as a platform-independent Java application, there is no requirements for any specific operating system on which this application can be run. Other requirements include :

1. JDK 1.0.2. (The current Java application has been developed using JDK 1.0.2. With JDK 1.0.2, another class: InetAddress.class has to be downloaded.)

With JDK 1.1 Beta 2 Release, the InetAddress class needs not be downloaded since it's already been included in the standard Java packages of this JDK version. MulticastSocket class is also included in this package. However, since java.lang.String has been rewritten, a part of this application that uses String constructor has to be modified. A copy of this application that has been modified to run under JDK 1.1 Beta 2 version will be made available in another directory.

2. Installation

To install, simply download the Java .class files into a single directory, add the directory's path into your $CLASSPATH environment variable and type :

java wb

3. Please refer to the "improvement list" for the latest improvements and additional enhanced features.

4. User Manual

When the user first runs the application, the following dialog box appears.

The dialog allows the user to enter a multicast address and port as well as his/her name and email address. The user's name and email address serve as a means of identifying him/herself to other users in the group. Internally, the system always uses a combination of login and host names to distinguish between users.

Once the user has completed entry of the dialog, the following User Statistics Dialog will be displayed.

This dialog displays a number of summary usage statistics of the group in the multicast session. These include the login name of the user, IP address and the machine name the user has logged on, the number of detected participants, the transmission interval of RTCP reports in seconds, and the number of active senders since the last interval.

Next, the following main interface will appear.

This primary interface consists of a whiteboard, chat tool and user information panel. Users can access the chat tool by typing into the text entry field and pressing the "Enter" key. Messages exchanged are displayed on the text display area (a Java text area below the text entry field). The next text area is used to display information such as the IP address and the machine that the user is currently logged on. Several "standard greetings" buttons are also provided for the users' convenience.

To draw on the whiteboard (which is bounded by the blue rectangular area), first choose a desired color (default is black) from the color panel on the bottom of the user interface, then followed by the line, rectangle, circle or the oval icon on the object panel that`s positioned on the leftmost of the whiteboard. To enter text on the whiteboard, choose the "ABC" icon instead.

Objects on the whiteboard can be selected, deleted, moved, copied and pasted. To delete and/or move an object, click on the "DEL" and/or "MOV" icon before selecting the object on the whiteboard. To copy and paste objects, click on the "SEL" icon, then select the object, followed by clicking on the "CPY" (denotes "copy"), then "PAS" (denotes "paste") icons.

The scrolled list on the user information panel, which is on the left of the chat tool, displays the list of all users currently participating in the multicast session. Each of the displayed users can be selected and additional information displayed by clicking on a user and then on the "OK" button. When this occurs, the following dialog is displayed :

The dialog currently displays only the name and email address of the selected user but can be easily customized to display more items of information if necessary.

To quit from the application, the user simply chooses the "Exit" submenu from the "File" menu of the main user interface.

5. Java classes documentation

This section provides a detailed documentation of classes belonging to each module, interfaces and repository classes (where shared information are being stored).


5.1 Classes for Communication Module

Class Names

Class Descriptions

SenderMCSocket Class implements sender multicast sockets. Class constructor takes in the specified multicast address, port number and time-to-live as parameters and constructs both a mutlicast socket and InetAddress from the specified multicast address. Provides mutlicast capability using the sending method associated with the Java multicast socket. (Does not need to join mutlicast group).
ReceiverMCSocket Class implements receiver multicast sockets. Class constructor takes in the specified multicast address and port number as parameters, constructs both a multicast socket and InetAddress and joins the multicast group. Provides mutlicast capability using the receiving method associated with the Java multicast socket.
PacketHandler An RTP packet handler that assembles any drawn graphics objects and chat strings (from the Chat Tool) with the RTP header before disseminating the RTP packet via the sender multicast socket (SenderMCSocket). This packet handler also disassembles incoming RTP packets received via the receiver mutlicast socket (ReceiverMCSocket). The disassembler effectively segments the RTP header from the rest of the packet body. The segmented header is then stored in a RTP_Header class (see below). The packet body, being encapsulated in application-specific format is then dispatched via the data dispatcher of the Data Handler (see below) to the appropriate graphics object classes (Line.java, Rect.java, Circle.java or Oval.java) or ChatPanel class (see below) for further processing.

NB: Further processing here means for display on the whiteboard canvas and storing in the graphics object stack (for the case of graphics object) or display onto the text display area of the chat tool panel (for the case of chat strings).
RTCP_PacketHandler An RTCP packet handler for assembling a RTCP packet by concatenating a Receiver Report (with RC = 0) with a SDES packet or a BYE packet before transmission through the sender multicast socket. This packet handler also disassembles an incoming datagram packet received via the receiver multicast socket by segmenting the Recevier Report from the SDES information. Includes method for computing the RTCP transmission interval. (Does not involve data dispatcher function of the DataHandler).
DataHandler Contains a data dispatcher function for dispatching received graphics objects or chat strings (as being segmented from the RTP header by the RTP packet disassembler) to methods in the chat tool panel (processInData() of ChatPanel.java) or the sketch panel (processInData() of SketchPanel.java) respectively. (See description below for ChatPanel and description above for SketchPanel). The decision to dispatch to either the sketch panel or the chat tool panel is based on the first byte read from the packet body passed to this dispatcher from the RTP packet disassembler.
ObjBaseClass Contains the base function that invokes the RTP packet assembler function. This base function is called by graphics object classes (Line.java, Rect.java, Circle.java, Oval.java, Text.java) after these classes have completed assembling the graphics object in an application-specific format . Each graphics object class extends from this base class.
RTP_Thread Class implements a thread for receiving RTP packets over the receiver multicast socket. This thread calls forth the RTP packet disassembler for segmenting RTP header from the rest of the packet body before passing the packet body to the dispatcher function of the Data Dispatcher. A check is made to ascertain that the received multicast packet is not sent by oneself before pasing to the dispatcher. No threads need to be implemented for sending RTP packets.
RTCP_Sender_Thread Class implements a thread for assembling and sending RTCP packets. At initial application start-up, this thread computes a transmission interval. Subsequently, the thread sleeps for an amount of time equivalent to the transmission interval calculated, hence, assembling, sending RTCP packets and updating a statistics window (see StatisticsWindow class below) at the end of each transmission interval. Each transmission interval calculated based on the number of participants, bandwidth, etc. (See Section below).
RTCP_Thread Class implements a thread for receiving and disassembling RTCP packets. The disassembled SDES information are stored to be displayed in the user panel (UserPanel).
RTP_Header RTP_Header for storing the header information of each RTP packet received. These header information are stored by the RTP packet disassembler.


5.2 Classes for Whiteboard Module

    Class Names

Class Descriptions

SketchArea Represents the drawing canvas of the whiteboard. Includes event handlers for trapping mouseUp, mouseDown and mouseDrag events on the canvas. Detects which objects are associated with such events and trigger the appropriate actions by calling forth the methods in the classes for implementing the graphics objects (line, rectangle, oval and circle). Process incoming graphics objects received from other users by passing on to the correct graphics object classes for further processing.
ObjPanel Object panel presents users with a list of graphics objects (line, rectangle, circle and oval). Also includes options for moving and deleting existing objects on the drawing canvas of the whiteboard.
ColorPanel Color panel presents users with a list of colors for drawing graphics objects.
SketchPanel Instantiates sketch area (SketchArea), object panel (ObjPanel) and color panel (ColorPanel). Dispatches incoming graphics objects to the sketch area for further processing.
Line Line class contains methods associated with the line object. Includes event handlers for trapping mouse events (mouseUp, mouseDown and mouseDrag events) and methods for constructing, moving, deleting and painting line objects onto the drawing canvas of the whiteboard. Incorporates parts of the communcation module for assembling drawn line objects in an application-specific format and the RTP header before transmitting over the multicast network. Also processes incoming line objects passed on from the sketch area (SketchArea). These incoming objects are those disseminated from other users.
Rectangle Rectangle class contains methods associated with the rectangle object. Includes event handlers for trapping mouse events (mouseUp, mouseDown and mouseDrag events) and methods for constructing, moving, deleting and painting rectangle objects onto the drawing canvas of the whiteboard. Incorporates parts of the communcation module for assembling drawn rectangle objects in an application-specific format and the RTP header before transmitting over the multicast network. Also processes incoming rectangle objects passed on from the sketch area (SketchArea). These incoming objects are those disseminated from other users.
Circle Circle class contains methods associated with the circle object. Includes event handlers for trapping mouse events (mouseUp, mouseDown and mouseDrag events) and methods for constructing, moving, deleting and painting circle objects onto the drawing canvas of the whiteboard. Incorporates parts of the communcation module for assembling drawn circle objects in an application-specific format and the RTP header before transmitting over the multicast network. Also processes incoming circle objects passed on from the sketch area (SketchArea). These incoming objects are those disseminated from other users.
Oval Oval class contains methods associated with the oval object. Includes event handlers for trapping mouse events (mouseUp, mouseDown and mouseDrag events) and methods for constructing, moving, deleting and painting oval objects onto the drawing canvas of the whiteboard. Incorporates parts of the communcation module for assembling drawn oval objects in an application-specific format and the RTP header before transmitting over the multicast network. Also processes incoming oval objects passed on from the sketch area (SketchArea). These incoming objects are those disseminated from other users.
Text Text class contains methods associated with the text string object. Includes event handlers for trapping mouse events (mouseUp, mouseDown and mouseDrag events) and methods for constructing, moving, deleting and painting text string objects onto the drawing canvas of the whiteboard. Incorporates parts of the communcation module for assembling drawn text string objects in an application-specific format and the RTP header before transmitting over the multicast network. Also processes incoming text string objects passed on from the sketch area (SketchArea). These incoming objects are those disseminated from other users.
ProcessCmd Class that processes copy and paste commands, implements a clipboard onto which objects are copied and a paste function for cloning and pasting objects from the clipboard.


5.3 Class for implementing User Panel

Class Name

Class Description
UserPanel Class implements the user information panel of the application. Participants' canonical names (username@hostname) are displayed on the user list of the panel. A hashtable is maintained to store SDES information corresponding to each participant. These SDES infotmation are updated everytime the rtcp thread (RTCP_Thread) disassembles a received RTCP packet. A window pops up to display the SDES informaton of the participant by selecting from the user list and clicking on the OK button of the user panel.


5.4 Class for implementing Chat Tool Panel

Class Name

Class Description
ChatPanel Class implements the chat tool panel which consists of a text entry field, a text display area, a status display area and shortcut buttons. User's input into the text entry field triggers off two actions: one which appends user's name (as specified during login session) to user's chat string input in the form: <name : chat string> and displays the resultant string on the user's text display area; the other action also appends user's name to chat string in the same format but assembles this resultant string in an application-specific format (in this case, writing a "ChatToolDataType" (see DataType), followed by the resultant chat string). The RTP packet assembler is then called to assemble with the RTP header. The chat tool panel also receives chat string deciphered from the data dispatcher of the Data Handler class and display them onto the text display area. The status display area displays status such as those used to indicate to the user which IP address and machine the user has logged on. The shortcut buttons contains short phrases like "Hello", "Hi" and "How are you" and when pressed, triggers off the same two actions as triggered by users' input into the text entry field.


5.5 Classes for storing information

Class Name

Class Description
StateInfo Stores information regarding the state of the application. Some of these parameters are necessary for calculating the RTCP transmission interval such as the "we_sent" and "initial" flag and the variables to keep track of the number of participants and the number of active senders during the last interval.Two vectors: the activeSenderVec and the memberVec are maintained to keep track and to set such variables.Other state information/parameters include the "exit" flag which is set to true when user presses on the exit sub-menu item. This will then send off a BYE instead of an SDES packet before the application exits.
UserInfo Stores the account name (login name), SSRC, hostname, IP address of users, along with the name and email address specified by users during the login session.


5.6 Classes for type declaration

Class Names

Class Descriptions
rtcp_sdes_type Class for defining the RTCP SDES item type : END, CNAME, NAME, EMAIL, PHONE, LOC, TOOL, NOTE and PRIV.
ColorType Class for defining the color types for drawing graphics objects : blue, red, magenta, cyan and green.
ObjType Class for defining the various object type: line, rectangle, oval, circle. Delete and move have also been defined within this class.
DataType Class for defining the data type for whiteboard and chat tool. This data type definition is the first byte written to the RTP packet following the RTP header. This data type is read by the data dispatcher of the Data Handler class to dispatch received parameters to either the whiteboard or the chat tool modules for processing.


5.7 Class for implementing main User Interface

Class Name

Class Description
MenuWindow Class for implementing the main user interface of this application. Instantiates RTP and RTCP sender and receiver sockets, an RTP packet handler and a Data Handler. Also starts a RTP receiver thread and RTCP sender and receiver threads. Includes event handler for handling events triggered by pressing on the sub-menu items. Brings up statistics window (See StatisticsWindow below) and provides an exit function for terminating the application.


5.8 Classes for implementing windows for displaying user information, statistics and for setting supervisor options

Class Names

Class Descriptions
UserStatisticsDlg Class implements a popup dialog box to indicate SDES information (name and email address entered at login session) of both the current user and other group users. This dialog box can be activated by selecting a user from the user list and then clicking on the OK button.of the user panel (UserPanel).
StatisticsWindow Class implements a dialog box for displaying a list of information such as user login name, IP address and name of machine the user is currently logged on, the number of group participants, the number of active senders during the last transmission interval, and the updated transmission interval.
SuperSettingWindow Class implements a dialog box to allow changing of the session bandwidth of this application. Intended for demonstrating the effect of a change in bandwidth on the RTCP transmission interval. A change in the default bandwidth of 100kbps (as recommended by Professor Henning Schulzrinne) to 10 kbps is observed to lead to a decrease in transmission interval from an average 5 seconds to approximately 10 seconds.


5.9 Source Code Listing


6. Design, Implementation and Functional Description of modules

This section provides a detailed description of each of the module that made up the system. The implementation, design issues and alternatives are also discussed.

6.1 Whiteboard Module

The Whiteboard Module consists of six individual subcomponents: Graphics Object, Object Panel, Sketch Panel, Color Panel and Object Stack. The sketch panel, sketch area, color panel and object panel, as well as each graphics object: line, rectangle, oval, circle and text are each implemented as separate Java classes (SketchPanel.java, SketchArea.java, ColorPanel.java, ObjPanel.java, Line.java, Rect.java, Oval.java, Circle.java and Text.java), while the object stack operations are implemented as methods within the sketch area.

The sketch panel forms the core class of the whiteboard that provides interaction among the sketch area, object panel and color panel, while the sketch area implements the drawing canvas onto which graphics objects are drawn.

The object panel provides users the means to select the type of graphics objects to draw on the sketch area, as well as the ways of manipulating the objects (move, delete, copy, paste), while the color panel provides users with a range of selectable colors. Both are extended from an abstract class (not shown here) that traps mouse events and identifies the type of objects (or commands) and colors being selected at any instant of time.

The Graphics Object comprises of graphics objects such as line, rectangle, circle and text, each implemented as a Java class. These are tightly coupled with the Communication Module, since not only are they associated with drawing the objects, but also with notifying the completion of a drawn object, after which the object is being assembled and the methods within the Communication Module called for dispatching them to the multicast network.

For our application, double buffering using offscreen graphics context and images are used to reduce flickering, while normal graphics context is used for intermediate painting which occurs when objects are dragged/moved across the sketch area. An offscreen buffer is used to save the drawn object to decrease the overhead in stack operation. There is no need to pop every drawing object when refreshing display.

Since the rest of the subcomponents require excessive explanation, we dedicate the following section for detailed description of the graphics object implementation, graphics object manipulation and the object stack implementation.

6.1.1 Graphics Objects

Graphics Objects refer to the line, rectangle, circle, oval objects and text string. Each of these objects is implemented as separate classes and drawn using JAVA AWT graphics classes for drawing lines, rectangles, circles, ovals and text strings. The object classes extend a base class (not shown in diagram) that provides the coupling between these objects and the Communication Module. In addition, each class implements an assembler function for assembling application-specific header information with the object parameters before invoking methods from the base class that provides coupling services.

These classes also implements Java's cloneable interface for the purpose of copy and paste objects (See below). An interface has also been written for these object classes, which specifies compulsory methods that need to be implemented by these object classes. Mouse events on the sketch area (drawing canvas of the whiteboard) are trapped by the sketch area and passed to the appropriate object classes for performing drawing operations.

6.1.2 Graphics Object Manipulation

There are basically four manipulation methods (graphics commands) in our Whiteboard Module, namely: move, delete, copy and paste commands.

(1) Move and delete objects

Users are allowed to move and/or delete objects by first selecting the icons marked "MOV" and/or "DEL" on the object panel before selecting the objects. Since these actions requires object selection, they involve stack operation. We would anticipate that stack operation would be tremendously exhaustive for the case of moving objects, since each movement are multicasted and requires immediate update on all users` sketch area, that is to say, if an object is moved from point A to point B across 100 points on the sketch area, participating users would need to perform 100 stack operation in order to see live update of each movement ! Such is prevented by keeping note of the previously searched object, thus improving efficiency.

(2) Copy and paste objects

Users are allowed to copy and paste objects by clicking on the "SEL" icon on the object panel, selecting the object, then clicking on the "CPY" (denotes "copy") and finally the "PAS" (denotes "PASTE") icon. Copying and pasting objects are made possible by having each of the graphics object classes (Line.java, Rect.java, Circle.java, Oval.java and Text.java) implementing Java's cloneable interface, then overwrite the clone() method in each of the classes. A clipboard for copied objects has been implemented to keep track of the last object copied.

6.1.3 Object Stack Implementation

Two stacks are maintained to handle the object selection. Stacks are chosen over Java's Vector class, since it operates in a LIFO manner. This is important for selecting objects that are piled one-on-top-of-the-other since it provides the means of locating easily the most recently drawn objects among the rest of the other objects that appear within the same drawing space.

All drawn objects are stored in a single stack while the other stack is used for performing searching operations. Whenever an object from the sketch area is selected, the stack is searched through to determine which object from the stack has been selected. Stack searching involves popping each object from the first stack (which stores all drawn objects) and performing computation on the x, y coordinate of the mouseDown event. Each popped objects are then pushed onto the second stack. As soon as the selected object has been identified, the objects from the second stack are popped and pushed back to the first stack.

To improve the efficiency of the stack operation, any previously searched object are stored, so that the need for searching through the stack is greatly reduced. This eliminates the graphics effect of having temporary "ghostly" images that appear whenever objects are dragged across the sketch area.

6.2 Chat Tool Module

Chat tool module is implemented to allow text-based communication. It contains several components as described below.

6.2.1 Text Entry

The Text Entry field accepts user input. User prompts the transmission of the entered text string by pressing the RETURN key, upon which the Java Event Handler invokes the Chat Tool and RTP assemblers before the message is sent as an RTP packet across the multicast network.

6.2.2 Text Display

A multi-lined text area set to non-editable for displaying the messages received by other participating users.

6.2.3 Message Display Field

This field provides display of communication messages. Among them, a message telling users the names of machines which they are logged on and IP address of these machines.

6.2.4 Shortcut Chat Buttons

Shortcut buttons are provided for user interaction.


6. 3 Communication Module

The communication module involves basically the transmission and reception of both data and control information. In order to interoperate with other RTP-compliant products and to ensure scalability for transmitting user information, RTP and RTCP are used respectively as the transport protocol of this application. Since RTP has not been defined for non-real-time application, our own application-specific packet format, augmented with the RTP header, has been designed for our whiteboard application.

Along with the use of RTP in a multicast environment arises important issues such as the generation of unique SSRC and sequence numbers, correct implementation of RTCP transmission interval, and others.

We first start off with describing the design of this module and the justification for such a design. The report then describes implementation and addresses issues/problems faced throughout the design of the sub-modules, as well as alternative designs.

6.3.1 Module Design

The figure above presents the main components for the Communication Module. This figure is almost similar to the diagram on Software Architecture (Section 5.2 of the project report). In addition, it indicates the functionality of the RTP receiver thread, the RTCP sender thread and the RTCP receiver thread. In our multicast whiteboard application, there is a need for users to constantly send his/her own information and be constantly updated of information from other multicast users. Moreover, we need a constantly running program for users to send and receive data information concurrently. To achieve this, the multi-threaded application has been developed using these three Java threads. The lower section of the diagram indicates the flow of control RTCP packets while the upper portion the flow of data RTP packets. In both sections, green arrows are used to show the outgoing flow (i.e., the sending of RTP or RTCP packets) while the blue arrows indicate incoming flow (the receiving of RTP or RTCP packets).

At the upper portion, objects which are drawn, moved, deleted or pasted on the whiteboard triggers the Whiteboard Assembler which assembles these drawn objects or commands (such as move and delete) into application-specific packet format before passing on to the assembler mechanism in the RTP Packet Handler for assembling with the RTP header before transmission over the network. Likewise, any chat string entered in the chat tool will trigger the Chat Tool Assembler that performs the same function. The RTP receiver thread loops while receiving RTP packets from the network and forwards them to the RTP packet handler for segmenting the RTP header from the rest of the packet. The Data Dispatcher will then dispatch the data to either the whiteboard or the chat tool for processing.

The flow of RTCP packets can also be described in similar manner, except that it does not have application-specific format. An RTCP sender thread is necessary in this case since RTCP packets are sent every certain amount of transmission interval.

The multicast communication mechanism is implemented using Java multicast sockets. Typically, a single multicast socket can be used for receiving and sending data at a particular port. However, this does not really work with Java mutlicast socket which hangs under the above situation. Hence, two Java multicast sockets have to be used for sending and receiving data at each of the RTP and RTCP port, resulting in a total of four sockets used for this application.

To handle the creation of multicast sockets and joining of multicast groups, two classes have been written : SenderMCSocket and ReceiverMCSocket. In creating Java multicast sockets and joining multicast groups, programmers have to convert the specified multicast address from String to InetAddress types. The classes written help provide a simple level of transparency. Only multicast address (in String class), RTP port number and TTL need be specified. The classes take care of creating the multicast sockets, converting the String type multicast address to InetAddress type, and registering the user with the specified multicast group at the specified port numbers. Also we need to join the multicast group only when we are receiving information. Programmers need not be concerned about such distinction since these are handled by the classes. The RTCP port number are automatically assigned a value 1 greater than the specified RTP port number. In our application, the multicast port and address are specified by the user at the beginning of the application, when the user is prompted to enter such information, along with his/her name and email address on the Login Session Dialog box.

6.3.2 Data packet using RTP and application-specific format

The RTP header used conforms to Version 2 RTP format in RFC 1889 [1]. However, not all fields of the header are relevant for this whiteboard application. The table below tabulates the RTP header fixed values used for our application:

RTP Header Field Number of bits Fixed Value Used

Version (V)

2

2

Padding (P)

1

0

Extension (X)

1

0

CSRC Count (CC)

4

0

Marker (M)

1

0

Payload Type (PT)

8

88

Sequence Number

16

 Randomly generated for the first packet of each source.
Incremented for each subsequent packet generated from the same source.

Timestamp

32

Not applicable

For this application, the padding, extension and marker bits are allocated a fixed value of 0, since they are not relevant to the correct operation of the application. We have assigned a value of 88 for the Payload Type of our application. This conforms with the unassigned range of PT values (77-95) as described in the RFC 1890 [2]. The timestamp which is used for measuring packet arrival jitter is ignored.

In real-time applications, the SSRC identifier is used to identify transmitting sources and hence several SSRC can be associated with a single user with multiple transmitting sources. In this application, the SSRC is used as an identifier for each application user. Both the SSRC and sequence number (to ensure sequenced delivery) are uniquely generated as in Section 5.3.5 of this report documentation.

Besides using RTP header format, we have defined our own packet format as shown in the diagram below:

Generally, the Object Flag determines whether the incoming data are intended for the chat tool or the whiteboard. A value of 0 implies data transfer request for the chat tool, a value of 1 indicates data transfer request for whiteboard. The RTP headers of incoming RTP packets are stripped off by the packet disassembler of the RTP Packet Handler, before being passed on to the Data Dispatcher. The Dispatcher will extract data following the Object Flag and passes it on to either the Whiteboard or Chat Tool for processing, depending on the value of the Flag. For the case of graphics object forwarded to the Whiteboard Module, another level of segmentation is necessary. This is done by the Object Disassemblers who will determine the Object Type (whether object received is a Line, Rectangle, Circle, Oval object or text string), or whether the packet contains a DELETE or MOVE command. For the former case, the object id, color and Object-Specific parameters (eg: a pair of x,y coordinates for the case of Line object) are passed on to the respective object class for display on the whiteboard panel. The DELETE command invokes stack operation, whereby the object stack is searched for the specified object id. Upon successful search, that object is removed from the stack and cleared from the drawing canvas (sketch area) of the whiteboard. The MOVE command, however, invokes stack searching only if the object id of the previously searched object is not equivalent to the one contained in the packet. The object parameters of the existing object are updated with the received parameters, and the objects position changed to create the effect of "movement". PASTE commands are translated as sending new graphics objects, i.e., it follows the same format as
<RTP Header : Whiteboard Data Type : Object Type : Object ID : color : parameters>.

6.3.3 Control packet using RTCP
The specification in RFC 1889 defines several RTCP packet types to carry a variety of control information:
SR : Sender report for transmission and reception statistics from participants that are active senders.
RR : Receiver report for reception statistics from participants that are not active senders.
SDES : Source description items (CNAME is mandatory).
BYE : Indicates end of participation.
APP : Application specific functions.

The SR packet is sent if the user was an active sender in the interval since issuing the last report. It is useful for providing NTP timestamp information used for constructing timing information for packets emitted from different sources. It also carries information of packet and byte count from the sender so that receivers can determine the number of packets lost in transmission. This can be computed by comparing the number of packets received with the number of packets expected. The expected figure can be in term computed by taking the difference between the highest and the first sequence number received. The reception blocks carried in the SR indicates parameters like the number of packet loss, interarrival jitter, etc, associated with packets received from other transmitting sources, and is thus useful for third-party monitoring of network performance for multicast distribution.

Since timing information and network performance are not critical for our application, each of our compound RTCP packet consists of only a receiver report (with RC, the Reception Report Count, set to 0), and a SDES packet. The Source Count, SC, of the SDES packet is set to 0, since we don't consider any RTP mixers. A list of SDES items used in our application are tabulated as belows:

The CNAME (canonical name) has to be unique since the SSRC identifier might change, following a conflict, a collision or when a program is re-started, and can be used to detect SSRC collision. The format used is "user@host" where "user" is the user login name and "host" is the hostname, although we could also use the IP address of the host. Both the login name and host name are derived using Java's system calls. In other applications which allow a user to generate multiple sources from one host, additional syntax will be needed to make the CNAME a unique identifier, or SSRC used. The text of all the SDES items are encoded using UTF-2 (also known as UTF-8 or UTF-FSS) encoding and are contiguous (not padded to 32-bit boundary).

The constant values used for each of the SDES item identifier conforms to that defined in RFC 1889, and can be found in our Java class: rtcp_sdes_type.

The RTP profile for audio and video conferences specifies that the CNAME should be transmitted every report interval whereas other SDES items are transmitted once every five intervals. For our application, higher priority are given to the NAME item which has to be continuously displayed on the user interface.

6.3.4 Calculating RTCP transmission interval

RTP is designed to allow an application to scale automatically over session sizes ranging from a few participants to thousands. The RTCP transmission interval controls the rate of transmission of reception reports from each participant, thus keeping the control traffic in large sessions manageable. The interval is calculated based on the algorithm in Section A.7 of the RFC 1889 (Feb 1, 1996). In order to apply it to our Java whiteboard application, the algorithm has been re-written in Java language. Most of the characteristics of the alogorithm is retained, such as:

The parameters required for calculating the RTCP interval are (1) the number of members in the multicast group, (2) the number of active senders since sending the last report, (3) rtcp bandwidth, (4) we_sent, the flag to mark whether the compound packet just sent contains an SR packet, (5) size of the compound packet just sent, (6) average size of the compound RTCP packet and (7) initial, the flag to mark whether routine is first called since application start-up, so as to calculate the time until the first report should be sent.

In our implementation, the number of group members are obtained by keeping track of the SSRC identifiers contained in the received RTCP packets, while the number of active senders can be derived by keeping track of the SSRC identifiers contained in the RTP packets received since the last RTCP packet sent, i.e. since the last interval. Since a single source with its unique SSRC number can transmit several RTCP and RTP packets, two vectors are used for storing the SSRC numbers in the received RTCP and RTP packets. The pseudocode for implementing this logic is as belows:



Since we need only to keep track of the number of active senders since sending the last report, the variable count has to be set to 0 and the vector emptied, once we have computed the next interval.

The same procedure is adopted for finding the number of members in the group. However, we need not reset count to 0, nor empty the vector for any interval since we are interested in obtaining the figure for the entire session. Whenever a BYE RTCP packet is received, the count is decremented and the corresponding SSRC removed from the vector.

The RTCP bandwidth is assigned a value of 5% of the session bandwidth which is taken to be 100 kbps for this application. A Supervisor Option is provided in main menu of the application to allow the supervisor to change the session bandwidth. This feature is much meant for demo to show the effect of a change of bandwidth on the RTCP transmission interval. (Although this is quite trivial and obvious).

6.3.5 Generating unique SSRC identifiers

The SSRC identifier is a 32-bit number used to associate RTCP packets with their corresponding RTP packets and to identify different sources from either the same host or different hosts. For this purpose, the identifier has to be unique within an RTP session. There are several ways of assigning SSRC identifiers:

Option (2) is ruled out since it would lead to conflict among multiple sources running on the same host which has a single network address. For option (3), generating random numbers alone, with no unique seed, will not guarantee that collision will not take place, even if all sources are not started simultaneously. Moreover, this option introduces additional complexity for having to append login name to the random numbers. Option (1) forms the best choice for our application. The unique SSRC identifier is generated using Java's random generator (java.util.Random) and using the current time of generation as the seed for the generator. The current time is measured relative to midnight January 1, 1970 UTC. Although this method does not ensure zero collision probability in the situation that all sources are started simultaneously (as when triggered by session management event), we assume that such probability is negligible. However, it would still be possible to reduce the collision probability further by having new sources to receive RTCP packets from other members before sending it's first packet. In this way, the new source will be able to verify whether it's identifier conflicts with others, before it picks on another random number. This, together with collision resolution, are out of the scope of this project.

Generating unique sequence numbers for the first RTP packet of each source is addressed in similar manner.


7. Future Work

7. 1 Whiteboard Module

Whiteboard can be further extended to have multimedia capability to include audio and video.

Following items may be the possible direction toward future work:

1. Image porting

Porting image to whiteboard area and allow multiple users to sketch and discuss over the image.

2. Snap shot

At any instance, user can take the snap shot of the current canvas as reference.

3. Time/Date/Calendar

Adding current time/date/calendar across different time zone, turning whiteboard to a virtually groupware to enable a group discussion.

4. Special drawing effects

More sophisticated drawing features can be implemented to bring users a more flexible environment.

5. Tag drawing objects with owner names

Putting tags besides the drawing objects to clearly show the ownership of any drawing object.

6. Encripted transmission

Encripting drawing objects and imported images to ensure the authentication of the user actions and unmanipulated images.

7. 2 Chat Tool Module

The chat tool can be extended to be the fully functional audio/video communication service. Combined with whiteboard, the application may be equipped with full multimedia capability.

Possible extensions are:

1. Video/audio Clip import

During a textual chat session, users can send out some emotional audio/video clip such as smiling faces or goodbye sound to other members.

2. Multichannel chatting

User may request a private talk without exposing content of the chat to other members. 3. Compression Compress chat context before sending to network. This is particular important if the application is implemented to full video conferencing version.

7. 3 Communication Module

1. Updated graphics information for new members

For applications that use connection-oriented unicast service (TCP socket connection) with a central server, new members of the application can be kept updated by the server sending centralized information in response to the requests from these new users. However, in a multicast environment, no central depository of information exists. Fortunately, RTCP exists to ensure continuous update of user information to all members of the group by sending RTCP packets every certain interval. In this way, new members will always be ensured of updated user information a certain period of time after joining the group. However, data information (graphics objects and chat string) are not constantly transmitted throughout the multicast network, otherwise network would be unnecessarily overloaded. New users who join the group would not be aware of any graphics interaction that has taken place prior to him/her joining the group.

One solution to this is to have the new user issue a request to obtain all the data information since the commencement of the session. The first existing member to receive this request would then take on the responsiblity of multicasting a copy of all the graphics object that have been received and stored in his/her own local repository. (Eg. vector of graphics objects). This same person will also indicate to others of his responsibility such that only one of the users need to update the new members instead of having all other users, each sending a copy of graphics objects to the new comer.

2. Synchronization problem

In our whiteboard application, situations may occur whereby more than one user attempts to modify the state of the same graphics object simultaneously. For instance, when a user deletes a graphics object, another user moves the same object at the same time.

One way to work around that might be to use token passing control access scheme. A user who have taken control of the token will be allowed to transmit graphics object for up to a certain maximum period of time, after which the token would be grabbed by some one else who wishes to transmit at that time.


8. Acknowledgements

We would like to acknowledge Peter Parnes who has provided important information on the Java Multicast Socket and new InetAddress class. Prior to the release of JDK 1.1 (which includes Multicast Socket and the newly patched InetAddress class for the multicast socket to work), much time was spent on getting the Multicast Socket class, since we have used JDK 1.0.2 which does not contain multicast socket in the Java packages. The multicast socket we have used to implement the communication module of this application is from sun.net package instead.

Also, we have used and modified slightly the Algorithm from the RFC 1889 for computing the RTCP transmission interval.

We have not used other written codes although that would speed up our work, allowing more time to implement other features.


9. References

[1] RFC 1889, February, RTP: A Transport Protocol for Real-Time Applications. , 1996

[2] RFC 1890, May, RTP Profile for Audio and Video Conferences with Minimal Control. , 1996

Please also refer to the Reference Section in the main report.