Date: 12/16/98

Group Name: Keshav’s Kids (Group 3)

Team Members: Rishi Khanna, PhilYen

Task: Multi-party Audio Conferencing and Whiteboard (Team 8)

Essentially, we wanted to cooperatively build a whiteboard and multi-user voice conferencing application. We would have to build a portion of the application and rely on the other members of our group to develop the rest. The principle is that, given services provided by the other teams, we can build our application on top of the base that those services provide.

The application is based around conferences composed of a number of computer and/or telephone users. At the root is the voice conference, which works much like any typical multi-party voice conference over a phone line. It is a full-duplex conference, so users can transmit and receive data at the same time, exactly like higher quality speakerphones, where the incoming voices are not cancelled out when you speak.

The model we are basing the conference upon is much closer to telephone-style voice conferencing than Internet-style IRC chat. This makes it much easier for us to deal with phone users; instead of assuming all users will be on a computer and having to "remove" features to let telephones in, we are making the telephones the common ground and adding features for the computer users. Specifically, we are adding whiteboard and image sharing capabilities for computer users.

The whiteboard is a shared drawing space, which allows multiple users to collaborate by viewing and drawing upon the same document. The lines drawn by any user are seen by all other users, so ideas and sketches can be shared. Image sharing is a function of the whiteboard that allows an image to be drawn upon instead of a blank space, so all the users could conceivably edit or comment a schematic or plan. There is no support for sharing text between computers, since everyone can already communicate by talking over the voice line. At worst, the users could "draw" the letters to point out important details.

Our primary concern is the whiteboard, since both the "multi-user" and "voice" portions of our conferencing application are entirely built by other groups. The signaling group takes care of the multi-user networking, and the data transfer group handles the transmission of voice (and computer-related) data. Also, in order to use multi-party conferences we need the directory services group as well, since they provide us with access to the conference database. This allows users to register individual and conference identities and network addresses, as well as perform searches on these details.

Conferences are created by a computer user declaring itself as the "host", and registering its address with the conference name in the database. This poses some problems with regard to phone users. Phone lines do receive an Internet-style address when they dial in, but they won’t be able to deal with whiteboard data. Thus, phone users cannot create conferences. They must be initially created ("hosted") by a computer user, so that other computer users joining the conference will be able to communicate with the conference whiteboard.

When other users want to join a conference, they simply use the signaling team's methods to connect to the address listed for the conference host. If the address is not known, it can be found by using the directory service methods for searching the database for the conference name. This returns an address, which can then be used to connect to the conference. When a conference is joined, the user is added to a list of conference participants by the host, and they are then able to receive all relevant data from all other members in the conference, and vice versa. By relevant data, we mean that computers will receive both whiteboard and voice data, while phones will only receive voice data. The updated list of participants is immediately made available to all members of the conference, including the new member.

Leaving the conference is as simple as announcing, via other signaling methods, that the user is leaving the conference. Then the host removes the departing network address from the participant list, and distributes the new list, so that each remaining member of the conference no longer contacts the departing member. This style of handling membership causes two special cases. One is where there is no one left in the conference except the host, and the host "leaves", thereby ending the conference. In this case, in addition to updating the participant list (so it is now empty), the host must "un-register" the conference with the database.

The other special case is where the host leaves while there are still other members in the conference. There are two possible choices in this situation: either the host can "pass along" control to another member, making them the host, or the host can simply end the conference immediately, dumping all the other members of the conference. We’ve decided to follow the latter, "selfish", model, whereby the host ends the conference when it leaves, instead of allowing the rest of the members to continue the conference. This is due primarily to the added difficulty of implementing the "nicer" model, where the host passes control.

Passing control of the conference to a new host requires that the database entry be changed to account for the new host address, and there are cases where the remaining members cannot be hosts. For example, if a computer user (the host) is in a conference with two phone users, and the computer leaves, one of the two phones would attempt to become the host, which is disallowed above. So it is more convenient to simply disallow host transferals than to deal with these secondary issues (ie, which member of the conference attempts to become the new host?).

Another way of joining a conference is to be "pulled in" by a member of an existing conference. This is much the same as actively joining an existing conference, but in this case, the conference is pulling in the user, rather than waiting for the user to come into the conference. The same updating of recipient lists and sharing of networking data occurs, as with a normal join.

While in the conferences, the connections between all members have already been set up by the join process, so all that remains is to use the voice transfer methods to broadcast the voice and whiteboard data from each member to the conference. Practically, this may cause some problems with bandwidth and network traffic, because there are no controls in place to limit the amount of data being generated and sent across the network. Realistically, we could have implemented some sort of control mechanism which only allowed one member to speak at once, but with full-duplex communications, we felt that it made more sense to allow simultaneous conversations. As a result, the same decision prevented us from controlling the whiteboard in a similar fashion.

In addition to the conference functions, there is also a function that allows users to establish a normal two-way voice-only connection, just like using a phone. The rationale here is that there will probably be occasions which don’t warrant a full conference, such as a brief conversation between two people. For these connections, the same signaling and data transfer methods are used as with a normal conference, but the whiteboard is not instantiated, and the connection is not logged as a conference in the database, so as a result, there shouldn't be more than two parties involved in a connection.

By the time of the demo we had most of our end of the application completed. We have a working whiteboard, and a base GUI. Our interface has working buttons, menu bars, checkboxes and text fields that we use to link in the networking functionality.

At the core of our application is our Shell class, which sets up the signaling manager and monitors for incoming calls, as well as dealing with outgoing connections. The Shell class is an extension of class Frame, and is the main window of the application. The Shell has a menu bar as well as function buttons. Basically, the buttons are redundant, but provide quick access to the items in the menu bar.

The menu bar has the following sections and choices:

Session Menu

Start Conference

Join Conference

Leave Conference

Quit

User Menu

Add User

User Properties

Help Menu

Getting Started

About Konnect

Start Conference – This choice calls the StartDialog class to produce to start a conference. It accepts

Join Conference – This option instantiates the JoinDialog class to join an existing conference.

User Properties – This choice calls UserDialog to prompt the user for an email address, password,

In addition to spawning the dialog classes in response to the menu/button selection actions, the Shell class does signaling setup (by instantiating a SessionManager) and makes the actual calls to Connection() to handle data transfer. Signaling calls made to open new connections and close existing ones are done in the shell, and data transfer usually is called from within one of the dialogs boxes.

When a connection is coming into the Shell, an AcceptSignalDialog dialog box is spawned, giving the user the option of accepting the incoming call. If the incoming call is accepted from a conference, then a whiteboard should be instantiated to allow participation in the conference.

When an outgoing connection is going to be established, be it to a user or a conference, we provide search capability, through the SearchDialog box, which uses directory services methods to query the database. This allows the user to look up another user or a conference by their name, and use the corresponding address to connect over the network. Alternately, it also lists all of the users or conferences currently in the database, depending on which is being searched for, so a specific user or conference can be selected out of a list. Technically, this would cause a real problem once the number of users or conferences increased substantially, so a filter system would be needed to break down the list, perhaps listing the names by first letter, or in some other hierarchy.

Not all of our goals were accomplished. We had initially planned to build our end of the system, with comments and perhaps some text output to give us correlation, then progressively plug in the signaling, data transfer and directory services methods to give us network capability and database functionality, respectively. We had the most success with directory services, as we can connect reliably to their database and perform a query that returns the information that we need. But the network methods were much slower to integrate. Communicating between processes required much more work than anticipated.

As a result, or perhaps because of that, we spent a large amount of time dealing with the signaling, data transfer and directory services teams. We hadn't anticipated the need to keep in constant contact with them, since we had assumed that we only had to use the code they provided us with. While this line of thinking was solid in theory, it actually required a substantial effort to keep up with the other teams, monitor their progress, and anxiously wait on code updates, instead of just waiting to plug in methods from their final product, as we had expected.

Unfortunately, not all of the functionality for the application was completed. Late integration problems with the signaling code are at the root of our problems. We had the directory service methods fully integrated, in that we could search on a name and connect based on the address returned, as well as search the database and list data tuples. But we were unable to get a two-way regular voice connection established between two computers, nor were we able to join a conference. We could start a conference, but that did little more than add an entry to the database (which worked) and listen on a specified port for incoming requests. Requests from a second computer to join that conference and attempts to pull in the second computer met with failure. The usual culprit was a bug in the signaling code that caused all the signals we passed across connections to become null. So, we were able to make contact with the other members of the network, but little more. We'd get the listener on each application to echo the information received. On the first computer, it would give back the packet data that we had sent. But on the second, we'd get an exception within our event call, showing us that the packet data was null, and the connection would never be opened. The same sort of thing occurred with regular voice connections. We would be able to get the connection opened, and have the second computer receive all data properly, but return messages for accepting the connection would invariably become null signals, and fail to establish the connection. This happened no matter which machines were trying to connect to which. It was tested with fully operational directory services methods, as well as with hardcoded addressing and identity information. We had it explained as a bug by the signaling team, but attempts to integrate their bug fixed version were killed by a compile time problem in MS Visual J++ 6.0, since the signaling team had built their code with JDK. Further attempts to remedy the situation were derailed by the deadline.

In addition to this persistent problem with signaling, some features were simply not implemented. Too much time was spent on attempts at integrating to allow for the implementation of other features. Networking for the whiteboards was supposed to occur on top of the data transfer layer, by customizing the data type to handle drawing events, rather than voice data. We felt that this was preferable to having the whiteboards use their own networking mechanism, for the sake of consistency. Using them that way probably would have been easier, simply by giving each whiteboard application a list of network addresses, then multicast UDP packets between them to send data back and forth. But, we didn't actually have a whiteboard package that had existing UDP networking. The one we had used was originally based on Java RMI, so using it in our environment wouldn't have been effective. Therefore, we had to decide between writing our own UDP communication methods in the whiteboard, or attempting to use the existing data plane. By using the data transfer calls, we could send all data through the same transport layer, through the existing connections, instead of having to open new connections. The decision to go with this was based on two factors: time, and the belief that working with the methods from data transfer would go smoothly. We haven't been able to prove this, though, as we haven't been able to test the data transfer methods at all. They may be fully functional, but we still can't establish a reliable connection over which to test them. As a result, we can only guess as to whether our code fragments are correct or not.

These issues with the signaling package highlight our problems coordinating work, as well as the slow development rate by baseline groups. No signaling or data transfer code was given to us until very late. The only development work that could be done was on the GUI. But, even then, its not solely the fault of the baseline teams, as we didn't do that much thinking ahead, with regard to how those packages would be use. We had a very good sense of where those packages would be used, but we didn't have as full an understanding of how and why they worked as we should have. We should have (but didn’t) examined the code and concepts more deeply when placing fragments into the GUI. This would have promoted some pre-emptive thinking about the problems inherent in the next phase, such as when to use directory services, and how to call the directory services GUI from different layers, etc. Technically, we had problems using packages from groups until we all finally settled on using SDK3.1 and Visual J++ 6.0.

At the very beginning, the sum and whole of our Java knowledge was fully contained within a pair of self help books. At the very least, we’ve developed a functional understanding of how to program in Java, including knowledge of the Java AWT classes and other packages, and basics such as the CLASSPATH and the Java package structure. Also, we've well learned the fact that Sun and Microsoft implementations of Java differ greatly enough to cause massive amounts of frustration. Having to worry about link libraries and compiler compatibility between jvc, javac, java and jview wasted large amounts of our time. It’s probably to be expected that the code runs properly under one platform but not the other. For example, our attempts to integrate the signaling team's final release were crushed by the incompatibility of our MS J++ 6.0 compiler and the SDK 3.1 code provided to us.

By the end of the semester, using the AWT has become second nature, so modifying the GUI to handle new features became instinctive. By far, the bulk of our time was spent working with the code provided by other teams. As a result, a large portion of our problems came from working with the code from other teams. Technically, this highlights the need for better communication between teams, as well as for good planning and coordination. Our planning was decent, if a bit optimistic. We hadn't anticipated spending so much time communicating with other teams about their packages. We had pretty much just expected them to churn out a release a couple weeks before the deadline, so we could take the code and plug it into our frame. Naturally enough, those first release didn't cover all the bases, nor did it work completely, so we had to get back to them with our complaints and suggestions, await an update, then attempt to reintegrate again. Then we'd have more problems and be forced to meet in person to work out problems with their code.

We've learned that large projects require time and a good deal of planning. Communication between teams and between team members is also absolutely crucial, and time management skills in general are desirable, as is prioritizing against other coursework. However, large-group projects are different from individual, or even small group problems, in that they are much harder to focus. Forging a group vision for the project requires a great deal of leadership, because working in small groups or alone, changes can be easily and quickly implemented. But with larger teams, decisions across the board must be carefully weighed against the benefits of implementation. For example, there were changes made by the directory services team to help out the management, but at the same time they caused problems for applications. They had to modify their code once more after releasing it to get everyone back "on the level". Perhaps our collective lives would have been made easier if our management team had been more forceful, but, as it stands, they took a very hands off approach to encouraging us to keep on schedule. While we'd prefer this kind of approach in most cases, we think that we really would have needed tougher management to make this project successful.

Key to this planning would be working around the coursework for other classes. Not surprisingly, we weren't able to meet as a team very reliably during the semester, due primarily to differing class loads. When one of us would be busy, invariably the other would have some sort of work to do. So working together became much harder, at least until we figured out how to do some juggling of the schedule to meet up and spend a few hours on the project. In the same vein, simply coordinating work between the two of us was an effort in and of itself because of our course loads. So the time that we spent working on the application became more and more valuable, since it also became less and less abundant.

Working separately was partially successful, since we'd get a good update on our code, but then would have to either write documentation for the other person, further aggravating our inter-team communication problems, or try to find the time to work with the other person and explain the changes. Thus, it was mostly in the beginning of the semester that we did this, we relied quite heavily on email to keep ourselves updated, as face to face meetings were harder to schedule.

The freedom given to us was probably what hurt us the most. Instead of having strict deadlines and more progress checks, we were given a very open ended project. This should have forced us to better discipline ourselves and pace ourselves accordingly. But, as with many semester projects, the first half of the semester went quickly and without much progress, so most of the work was done late in the semester, primarily in the last two weeks. On any future large projects, the lesson to be learned is to start early, and attempt to make consistent progress. First, this gives a sense of progression as the semester moves along, and it also reduces the amount of work being crammed into the latter half of the semester. Hand in hand with starting early would be to have better scheduling. Setting weekly or biweekly goals to make would help with making consistent progress. Granted, we were supposed to write a timeline for the project, but it gradually slipped out of usage for a number of reasons. So beyond setting those goals, sticking to them, or having someone make us meet them, also looks to be important. Generally, that requires either strong motivation, or strong management.

A large part of our project was based on our dependence upon other groups for our networking capability. As a result, any and all planning that we did, especially in the later stages, relied heavily on their input, as well as their released code. But because of that, long range planning became harder. Better planning to begin with would have eased this problem. Initially, we had treated the application as a very light-weight project, instead of handling it like the kind of monster it became. Had we realized this earlier, we would have been better motivated, at the very least, to avoid the last minute crunch which engulfed us and ate away 4 days of our collective lives. Underestimating the amount of work we were required to put in cost us many hours.

As a result, we can quickly say that communication is key to these larger projects; there is a well defined (by now, at any rate) need to keep in contact with other team and group members on a constant basis while working on the project, be it for application or baseline teams. We had kind of assumed that we wouldn't need to do much inter-group communication because we were an application team, and only had to deal with finished product, instead of being just as involved in their development process, as we were.

Having that communication would have greatly helped us in finding out where our potential development bottlenecks may be, as well as pinpointing areas of possible concern. For example, we were heavily dependent upon signaling, data transfer and directory services to provide us with working code before we could even test. We were able to test our components individually by running our Shell application alone, but testing the entire application with full networking capability required meeting with all of the baseline teams, at least to get their servers up and running for us.

In the future, we hope we'll be able to take these lessons with us, and:

a) Plan ahead!; This should give us a much more realistic expectation of the amount of work

required.

b) Make better use of our meeting time, rare as it became. This would have kept us more efficient,

especially if we did our updating by email, and used meeting times to make forward progress.

d) Try to keep lines of communication open between teams; This is more of a general approach

e) Maintain motivation and focus over the course of the project; Naturally, this is always a goal,

but here especially, it would have helped.

f) Start early! We think this speaks for itself.

As an application team, we don’t provide any procedure calls, but we make use of methods provided by the signaling, data transfer, and directory service teams.

From signaling:

SessionManager ( Application, String, int, String, int);

CreateSession();

AddSession();

From directory service:

Credentials(String, String)

Record(String, String, Credentials)

ClientDsapi(String, int)

Modify(Credentials, Record)

From data transfer:

Connection();

WaveFormat(WaveFormat, int);

DestinationSpeaker(Destination, Application);

InetAddress.getByName(InetAddr);

DestinationNet(Destination,int);

SourceMicrophone();

The project started quite slowly. Support, in terms of the code fragments and web site links, was provided a little late. As a result everything seemed to be pushed back, so that no "real" work was done (at least by our entire group) until late November. The added workload provided by the bi-weekly puzzles also killed off most of our enthusiasm to work on the semester project until late in the semester. After puzzle 5 was completed, to be precise. Speaking of which, the puzzles were much more useful than the project, in terms of concepts learned and implemented. Though this may be a skewed perspective because we were an application team working primarily with finished networking code. The project quickly focused on interacting with the team, rather than simply attacking a technical problem. We had to take on a problem from multiple perspectives, which requires some management/direction/vision. Realizing this, and getting it, cost us a good portion of the semester.

The frequent updates (especially the more recent ones, as the semester came to a close) proved very helpful, certainly in terms of the help they provided, but also as a reminder that the deadline was closing. Perhaps more of these emails earlier in the semester would have pushed up the working schedule by quite a bit.

Most of the resources we referred to were the documentation pages released by our signaling, data transfer, and directory services teams. We also has some supplementary help from the official Java site (www.javasoft.com), for the JDK API, and the Yahoo search engine (www.yahoo.com) from which we found many useful links for whiteboard applications.