Date: 12/16/1998

Name of group: Phonedation

Team members: Zhongwei Li and Xiangjiang Ma

Task: Multiparty audio conferencing + whiteboard

1. What did we set out to do?

We are working in a multiparty audio conferencing plus whiteboard project in Phonedation, a start-up company that develops Internet Telephony products. Following picture shows what Internet Telephony looks like.

Our task is to design and implement an audio conference application to allow participants to join and leave conferences. The conference control scheme will allow a speaker to cede control to one of a set of waiting speakers. The scheme will also allow users who may not be accessible on the Internet to have an audio-only connection to a conference. In addition, a shared whiteboard, which allows participants to share a graphic workspace, will be created.

Following picture shows what whiteboard looks like. Computer users in the same conference group can share text and graphical information on the whiteboard in addition to voice conversation.

Following is the highlight of the basic feature:

• User interface is designed and implemented in JAVA.
• Whiteboard can be used after one joins or creates a conference successfully.
• Each conference has a property, which is labeled as two alternatives: public or private. When one creates a new conference, he/she should decide the type of conference. If " Private" is selected, the conference creator should set a password of the new conference.
• When one applies to join an existing conference, he/she can choose the conference from the conference list. What’s more, the conference creator can invite any one by dialing his/her telephone number to join the conference.
• Telephone user can also join the conference by entering login userid and password.
• Member of the conference group can leave the conference at any time, but if the host quit, the conference will be ended.

We have achieved all the goals we set out to do and added more on whiteboard application. We made a schedule at the beginning of this project and we made sure that everything is on schedule throughout this project. Our design is based on open structure, so that future expansion of this project is straightforward. The user interface we designed is comprehensive and all of the functionality has been implemented successfully (for which we responsible). In addition, we have successfully built JAVA RMI server for each conference for whiteboard application. Following is a screen shot of the user interface that we designed and implemented in JAVA.

Above user interface is pop up after the user has successfully input his/her username and password, which are stored in a database built by directory service team. Both the menu and the buttons can be used.

User can create new conference by clicking the "Create New Conference" button. A dialog box will pop out, and a new conference will be created after proper information is filled in. If the "Use Password?" checkbox is chosen, the conference will be private. In such a case,

the conference creator will set the password and only those who know the password can join the conference.

Users can also choose to join an existing conference by clicking "Choose Conference" button. All existing conference names will be shown on the left panel and the user can pick any conference of interest to join. When the existing conference group is clicked, the user names in that group will be displayed on the right panel. Following is a screen shot.

Anyone who wants to join the conference has to be registered. This can be accomplished by choosing "add new user" item from User menu. A dialog box will pop up and the filled information will be sent to the database maintained by the Directory Service.

The whiteboard can be invoked from App menu. The RMI white server is created at the time when new conference is created. Basically, we build a white board server for each conference group through RMI so that different group cannot share a whiteboard. Only users in the same conference group can communicate and share the information on the whiteboard.

We added this part as a bonus. Since it seems not required for us to do anything more on whiteboard application except simply running it. Though the recommended whiteboard application may satisfy our demo purpose, we decided to do some extra work and tried to make our project more impressive by introducing a new whiteboard written in JAVA and modified it to suit our application. The new whiteboard was downloaded from CMU, and we added a RMI server thread and client thread to each conference group so that different conference group will have separate whiteboard channel. Our efforts will help us get around limitation of local computer domain and build a portable application for Phonedation.

Another bonus work we have done is to help telephone user to join the conference. We built a phoneuser RMI server which implements the remote interface to signaling at the time when telphone users dial in (join the conference) or hang up (leave the conference).

Most conference control has been implemented successfully. We have fulfilled all the tasks for which we are responsible. Since our application is written in Java, we use RMI to communicate with our peer teams. In addition, thread is used throughout our program. When our application starts, all initial threads such as whiteboard server/client, phoneuser server, message receiver will be invoked automatically. Flow control is basically provided by team 1 (data). In our application, we added a speaker button trying to avoid congestion.

Following shows a list of the whole conference control mechanism. Highlighted items are related to our job.

1. Create conference with group id, name, property (private/public)
2. Send info to directory service, return multicast address
3. Let signaling tell Billing + Directory Service (DS)
4. Establish UDP connection with group multicast address, return a connection id

1. Get the list of conference groups from DS
2. User picks an existing conference to join
3. if private, user gives password
4. Get information for that conference from DS, including

Multicast IP, password if applicable, and group member list

5. Let Signaling tell Billing
6. EstablishConn(multicast add.), return a connection id

1. If the current client is the conference creator, then tells signaling to call destroy(conference name), else tells signaling to leave (conference name)
2. Signaling telling Billing, DS; tell gateway to tear down phone links
3. If the creator quits, send message("Destroy") to multicast address, else, send message("Quit")
4. Destroy Connection

1. User enters login userid/passwd, signaling verify them with DS

1. User picks "2" to join conference
2. Input conference id (suppose caller know it before calling)
3. Signaling checks conference id with DS, if private, verify the password entered by the caller. Signaling tells gateway to play RM5.
4. Signaling inform gateway to setup connection
5. Gateway: EstablishConn, return connection id
6. Signaling tells the conference application
7. Application: recvMsg(parameters), if the participant is the first phone call user, then EstablishConn(parameters) to gateway at an available port.
8. Signaling tells billing + DS

1. User calls hangup() which is an interface provided by Signaling

1. Signaling tells Gateway
2. Gateway: disconnect the phone link sending (c, "Quit")
3. Signaling tells Billing + DS
4. Signaling tells conference application

Following is the class hierarchy of our source code.

class java.lang.Object

• class C1_Connection (From Team 1)
• class java.awt.Component (implements java.awt.image.ImageObserver, java.awt.MenuContainer, java.io.Serializable)
• class java.awt.Canvas
• class ImageCanvas
• class java.awt.Container
• class com.sun.java.swing.JComponent (implements java.io.Serializable)
• class com.sun.java.swing.JPanel (implements com.sun.java.accessibility.Accessible)
• class InfoPanel
• class java.awt.Window
• class java.awt.Dialog
• class TrivialAlert
• class java.awt.Frame (implements java.awt.MenuContainer)
• class ChannelsWindow
• class ChooseConference
• class ConferenceFrame
• class LoginDialog (implements java.awt.event.ActionListener)
• class Debug
• class Demo
• class DirService (From Team 4)
• class java.rmi.server.RemoteObject (implements java.rmi.Remote, java.io.Serializable)
• class java.rmi.server.RemoteServer
• class java.rmi.server.UnicastRemoteObject
• class PhoneUserServer (implements PhoneSignalInterface, java.lang.Runnable) (From Team 2)
• class User (implements java.lang.Runnable)

Following is the interface hierarchy of our source code.

• interface java.rmi.Remote
• interface PhoneSignalInterface

We have run into a large number of problems since we took this project. Looking back on this painful process, we feel relieved that all those unexpected problems were solved and we have made progresses throughout this project. Following are some main problems we encountered.

• Lack of co-operation with the peer teams on whom we depend in the beginning of this project. We have paid a lot for it. At the beginning of this project, not all group members understood what was going on. We were trying to specify the interface we would use from our peer teams as early as possible and we had to worry too many things around. Not until our management team was in control, we were getting confident on this project. Specific meetings are essential for teamwork of such magnitude we never got involved before.

• Late integration with some peer teams on whom we depend. Since our team has to use interface provided by other teams, we have to wait for their bug-free interface. We got around part of this problem by writing our own test codes and finished all those jobs for which we are responsible.

• Hard to make JAVA work for us. We were unable to use the latest version of the java development kid on the NT machines because of our lack of administrative permissions. This led to problems since old jdk version does not run the remote method invocation. We got around this problem by installing a new jdk directly on our own account. It looks trivial, but we lost some time figuring this out. When we tried to implement RMI server for whiteboard application, we faced unexpected problem such as java.security.accessControlException. In addition, We had problems dealing with the "portability" of java. We have used both Microsoft Visual J++ and JDK to debug our java source codes. It seems that they are quite different. We were trying everything we can to make our java codes to be 100% pure. This effort will help us to run our application in both NT and UNIX.

• Hard to use the whiteboard. At the beginning of this project, we were told that we could use any existing whiteboard application. So we chose the recommended whiteboard application, wbd.exe, and tested it in MENG lab. When Phonedation has its own machine, we found four problems with wbd. First, it could not working properly in CSUGLAB where multicast is not available. Next, it is not clear how to keep it "private". Third, it is not portable because it is a Windows application. Last and not the least, it does not support multiple conference. Though it would not be a problem for us to show it on demo since only two telephones and one computer will be used, we decided to use another whiteboard written in JAVA and implemented RMI server on it. We feel excited that we have made additional contribution to Phonedation.

We have learnt a lot through out this project. Though it is a painful process, we feel that it will benefit for our future career.

• It is rewarding to understand how internet telephony works. Without experience in this project, we will not be able to fully understand what taught in CS519.

• It is important to learn how to co-operate with each other in such a big project. It is especially important to co-operate with the peer teams on whom we depend. We did not have experience working in such a big team, and we have learnt the importance of co-operation.

• It is important to get a clear picture of this project as early as possible.

• It is important to read all related information of the undertaking project. Sometimes, we can get inspiration from what others did for similar projects.

• It is very helpful to make a schedule and try stick to it throughout the project. The schedule should be made both specific and flexible. Since many unexpected problems would happen, we learn how to adjust our schedule to meet our new needs. Looking back, it seems impossible to finish this project without sticking to the schedule.

• It is rewarding to understand all other teams’ work within our group even if our work is not directly dependent on all of them.

• It is challenging to take an extra job (whiteboard application plus RMI server) at the end of this project. Since we were not familiar with RMI stuff, and it is interested to see that we can make it work for us. We found this practice useful and rewarding.

• It is rewarding to do programming in JAVA. All of the source codes were written in Java, which we were not very familiar when we first took this project. Being able to master JAVA is the bonus of taking this project.

• It is interested to learn how RMI works. By using RMI in JAVA, we also polished our knowledge on RPC.

Next time when we undertake a large collaborative project like this, we will try to approach the problem differently and avoid the same mistakes we made this time.

• We will start up the job from the first day we take the project.

• We will make specification as clear as possible before we wrote the codes. We learned the theory from CS501 (Software Engineering) and we made practice in this project.

• We will make a practical and flexible schedule and try to stick to our schedule throughout the project.

• Before writing our own codes, we will read more information on what other people did for the similar job.

• Before writing our own codes, we will spend much more time in cooperating with our peer teams. Getting involved with those teams on whom we depend and by whom we are depended at the earliest stage is crucial in a collaborative project. We will try our best to improve co-ordination with our peer teams.

• We will try to get familiar with any new tools or new languages which will be used in the project as early as possible.

• We will try to integrate our code within the main project as early as possible. It is not necessary to wait for other teams to finish their jobs before we can test our codes. It is rewarding to do the dry run earlier in order to discover unexpected problems.

1. Interface that our team provided to other teams or used:

 

Interfaces that we used from team1 (data), team2 (signal), and team4 (directory) have been specified. We also provided a JAVA RMI interface to team2. Details can be found in the source codes, which is placed on babbage in the directory /amd/babbage/a/cs519pdt/t8/. This report in Word format and HTML format can be found on babbage in the directory /amd/babbage/a/cs519pdt/reprot/. Following is the exact procedure calls that we used and provided:

From Team1 (data):

native long EstablishConnection(String dest_name, short dest_port,

long sample_size, long input_type,

String input_file, long output_type,

String output_file, short loop_file,

long primary_enc, long secondary_enc,

String err);

native long DestroyConnection(long c);

native long ModifyConnection(long c, long size, long input_type,

String input_file, long output_type,

String output_file, short loop_file,

long primary_enc, long secondary_enc);

// lc is the long EstablishConnection returned

native long SendMessage(long lc, String buf, long buf_size);

// msec is how long to wait for a message, in milliseconds

// 0 means (try to) wait forever (system calls will interrupt)

native String RecvMessage(long lc, long buf_size, long msec);

 

From Team2 (signal):

public interface DesktopSignalInterface extends Remote

{

// create a conference

public boolean Construction(String groupname, String ipaddress, int portnum) throws RemoteException;

// join the conference

public boolean Connection(String groupname, String ipaddress, int portnum) throws RemoteException;

// conference creator invite telephone user

public boolean Dial(String calledtelephone, String ipaddress, int portnum) throws RemoteException;

// quit the conference

public void Hangup(String ipaddress, int portnum, boolean isCreator) throws RemoteException;

}

To Team2 (signal):

public interface PhoneSignalInterface extends Remote

{

public void DialIn(String phoneNumber, String callerName) throws RemoteException;

public void Hangup(String phoneNumber, String callerName) throws RemoteException;

}

From Team4 (directory):

native void CreateNewConference(String cname, String userid,

int priority, String pword);

native void DeleteConference(String cname, String userid, String pword);

// Return the multicast IP address

native String GetMulticastAddr(String cname);

// Return 1 for public, 0 for private

native int GetConfPublic(String cname);

// Return password for the conference

native String GetConfPword(String cname);

// Return all userids in the conference

native String GetMemberList(String cname);

// Return the number of members in the conference

native int GetNumMembers(String cname);

native void AddUser(String userid, String cname, String cpword);

native void DeleteUser(String userid, String cname);

// Verify that password matches user, Return 0 for fail, 1 for success

native int Verify(String userid, String pword);

 

2. Advice for the course staff:

 

It would be better if all hardware for this project is ready at the beginning of this project. In addition, more computers and more telephones are needed for this project since we are dealing with multiparty conference. It would be excited in Demo if we could show all of functionality we have implemented.

 

3. References:

"An Engineering Approach to Computer Network" by S. Keshav

Record of meeting with Professor Keshav on 9/25/1998

Record of several meetings within Phonedation in November 1998.

Record of several meetings within Phonedation in December 1998.

http://www.sun.com/java/index.html

http://www.cs.cornell.edu/cs519/project/description.html

http://www.cs.cornell.edu/cs519/project/overview.pdf

http://simon.cs.cornell.edu/home/bba/javagroups.html

http://oac3.hsc.uth.tmc.edu/staff/snewton/tcp-tutorial/

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-mbus-transport-00.txt

http://www-in.npu.edu/introjava/week12/udp.html

http://www.ietf.org/1id-abstracts.html

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sip-09.ps

We would like to express our appreciation to Prof. Keshav for introducing this interesting project. We would also like to thank our peer teams in Phonedation for co-operation.

The whiteboard application was written by Robert Kraut and William Schelis (scherlis@cs.cmu.edu), CMU, and it is available publicly. This code was modified to suit our application. The big picture on the first page of this documentation is downloaded from http://www.cs.cornell.edu/cs519/project.