Carlos Basto Hemang Bhojani Jorge L. Noyola-Picazzo Carlos E. Olguin Vicente Zamora

The objective of this project is to build an integrated application that will allow distance learning by using computers distributed along a computer network, integrating digital video, audio, data and group collaboration.

By the use of this application, a lecturer can broadcast a lecture throughout the network to different attendants located in remote locations. This attendants will receive in their computers, with a different application, digital video and audio from the lecturer’s workstation, as well as a "whiteboard" with whatever data the lecturer wishes to display. They will be able to interact with him by typing their questions in their computers, and sending them to the teacher.

Also, in order to provide better control when large audiences are involved, there will be a moderator which will act as an assistant to the lecturer, by receiving first the questions from the attendants, moderating (filtering or summarizing) them, and relaying them to the lecturer, so he can answer to them within his lecture. Also, this assistant can communicate via two-way video with the lecturer in order to assist him, and correct the whiteboard the teacher is displaying.

The whiteboard can be modified by the teacher as he displays it in order to point specifics of it or to make last minute corrections, and can also allow the moderator to make this corrections. Once any correction is completed, the new whiteboard is broadcasted again to the attendant workstations. On their workstations, the student can also make annotations to the whiteboard and submit these to the moderator or to the professor.

The attendants will sign on into a lecture by selecting it from a directory service which will provide the security required for the application, such as allowing lecturers to start broadcasting a lecture, verifying the identities of lecturers, moderators and attendants, and keep the security-administrative database.

Mainly, the application will consist of four main modules with different functionalities, depending on the role of the user. These modules will be the Teacher module, the Moderator module (which actually is the teacher module, but with limited capabilities), the Student module and the Directory module, each usually running on separate computers. A detailed explanation of the functions that each application will have is shown below:
 

Module	Functions
Teacher	Broadcast real-time, live video to each workstation attending the lecture Receive video transmitted from the moderator’s workstation Read slides from files into the whiteboard, and broadcast them to the students Modify the contents of the whiteboard Receive questions forwarded from the moderator or from the students if there’s no moderator present Allow the moderator to modify the slide that’s currently being displayed Relay selected questions to students workstations Sign-on in a lecture
Moderator	Receive questions and comments via text from the students and relay selected or new ones to the teacher Send real-time, live video to the teacher’s workstation Receive broadcasted video from teacher’s workstation Modify whiteboards provided by the teacher Broadcast text messages to students’ workstations Sign-on in a lecture Keep a log of asked and relayed questions
Student	Receive broadcasted video from the teacher’s workstation Receive broadcasted whiteboard from teacher’s workstation Receive broadcasted messages from moderator’s workstation Send questions to teacher/moderator workstations Sign-on in a lecture
Directory	Manage security Allow teachers to sign-on to start a lecture Show available lectures Create lecture "tickets" and issue them to students and moderators

The module interaction would be structured as follows:

The sequence followed by the workstations to bring up all the modules of the application would be as follows:

• The Directory would always be up and running, since it is in charge of the security of the whole application and acts as a server for the rest of the modules.
• For a lecture to begin, the Teacher must sign-on in the Directory, thus activating his lecture and making it available for the rest of the applications. When the teacher signs-on, a ticket is issued to the module, which keeps it for the rest of the lecture. This ticket will be used to authenticate other users that try to sign-on to the lecture.
• The moderator plays an optional role in the application. It will also sign-on with the Directory, that will check its identity and issue a ticket that will identify him as a moderator, and returning to the application the address of the Teacher, where it will connect automatically, authenticating itself with the ticket it will receive from the Directory.
• The role of the Moderator is optional. If the Moderator is not present, the Teacher will receive all the data that is supposed to be sent to the Moderator. A Moderator can also sign-on late, in which case the Teacher will broadcast the new location of the moderator to all the Student workstations.
• The Student workstations sign-on to the directory and get a listing of all the active lectures they’re allowed to attend. Once they pick one, the Directory will issue the ticket for the lecture and give the address where it should connect, this connection will be performed automatically by the application.
• Every workstation that tries to attend the lecture, either Student or Moderator, will be accepted by the Teacher only if the ticket they carry is the same as the one given to it when the lecture was started. This authentication will be transparent, no user intervention will be required.
• The Teacher workstation will be continuously broadcasting video, audio and graphics to every workstation connected to it.
• When a Student wishes to ask a question, he will type it in his application and submit it. This question will be automatically sent to the Moderator, or to the Teacher, if no Moderator is present.
• The Moderator will select or summarize the questions, and relay them to the Teacher. When they’re sent to the Teacher, it will also be broadcasted to the Students, so they’re aware of what was exactly the question asked to the Teacher.
• The Teacher will be able to modify the whiteboard that’s being broadcasted to the Students. When he does that, the modified whiteboard will be transmitted to the other workstations.
• Since the Teacher will have two-way communication with the Moderator, the Teacher will also be able to share the whiteboard with him, allowing modifications to the whiteboard, that will be broadcasted back to the Students.
• When the Teacher decides to finish the lecture, it will notify all the workstations before signing off.

The platform that will be used to implement the application will be Java, in order to allow portability across different platforms, and because of the facilities provided to handle TCP/IP networking.

The different modules will reside as independent classes or applets in a web server, and will be launched from a web browser such as Netscape of Microsoft Internet Explorer. This applets will only be accessible after a secure login and won’t allow access to them without a proper authentication.

The audio and video will be transmitted over the network as a real-time stream, and the libraries required to handle it will also be developed in Java.

The application will have a Java based GUI, and each of the modules will have it’s own independent interface that will be displayed (except for the Directory) in a Java console on the screen.

The interface for each of the modules will be the following:

All the modules would have a similar interface, varying only in some of the capabilities they can have, and the audio/video source. For example, the Teacher interface would have also a button to share the whiteboard with the moderator, and the Moderator would have a control to forward the messages and graphics received to the Teacher.