The primary goal of our project was to create a phone interface for someone to check and send email messages using the functionality of the underlying telephony system. This type of telephony system would typically be implemented within a company that most likely has its own mail server. Traditionally, a computer is required to access one’s email but we allow a phone to be a new access point to the mail system via the Internet telephony structure. The core of this structure directly supplies live voice communication between two computers or between a phone and a computer. Our application provides an extra feature to the core system. The additional functionality provided by our project almost replaces a typical voicemail system and could be easily extended to function as a complete answering service as well.

In implementing the voice-email gateway, we supply the user with a menu-oriented system with the basic functions of checking mail and sending mail. Users are identified by a unique extension number and have an associated PIN for security. When checking mail, the system could read out text messages, sending the audio data to the phone. The user could scroll through the headers and selectively choose which message bodies to have read to them. For sending mail, the user can select the recipient by their unique extension and leave a spoken message. This voice data would be saved as a file and sent as an attachment to the recipient.

What did we actually accomplish?

Essentially all of the major components of our system appeared to work. Complete testing with a phone was not possible but the testing that was done verified most of the code.

One component of our system involved capturing the tones or buttons that the user may press on the phone for purposes of function and data control. We received these tones from the signaling team, who forwarded the information from the gateway team. We ran a server thread in our application that listened on a predetermined port so the signaling team could send us TCP packets when a connected user pressed a button. This functionality was simple to test by running a separate application to connect to our server and send the appropriate data to simulate button presses.

Another fundamental part of the voice-email system was sending audio data out to the phone and capturing voice data from the user. The data team provided us with the required interfaces for these functions. All of the interactions with the local machines involved audio files that would be either transmitted to or recorded from the phone line. It was difficult to completely test this component without actually using a phone and connected to the system. Since we were never able to test our project by dialing into the system, we cannot be entirely sure that this part was successful.

The menu functionality worked successfully. When the user connects, it asks them for their extension number. If this entered extension is a valid user, it then asks for the PIN; otherwise, it asks for a new extension. If the PIN is correct, it then proceeds to the main menu, otherwise it asks for the user extension again. The user typically terminates the input of a sequence of numbers, such as an extension or a PIN, with the # button. All of the validation for users required functions from the Directory Services. The main menu consisted of options for checking mail, sending a message, quitting, or reading the menu again.

Checking mail contained its own menu where the user could read the headers of their messages and optionally the bodies. Part of checking a user’s mail involves the parsing of mail files to be read out to the user. Since our project was running on a computer running Linux, and we were able to get the users name from Directory Services, their mail file is in the "/var/spool/mail/" directory. When we initially open the mail file, it is scanned to find the starting point of each header. Put simply, headers start after a blank line, with a line starting with the word "From" and then followed by several lines of fields, such as "To:", "Subject:" and so on. Although we had random access to any message of the mailfile, we implemented a user interface with linear access. When checking their mail, the user has three options: Press 1 to play the next header, Press 2 to play the body of this message, Press 3 to quit back to the main menu. If the user input a 1, the program would seek to the spot in the file where the next message header began. Then, it would read through the header and write the fields for the message date, who the message was from, and the subject of the message to a temporary text file. This text file was then converted to a wave file for playing out to the user. Also, the "From:" field indicating who the message was from, was parsed to replace @ with the word `at', and replace the periods in an IP address with the word `dot'. So, the user would hear for example "Date one December nineteen ninety eight. From Dave at Cornell dot edu. Subject Meeting on Thursday." The user then decides if they want to hear the body of the message, or just skip to the next message. If they decide to hear the body, the text from the message body (not any attachments) was parsed into a text file, converted to a wave file, and then played out to the user.

Sending mail to another user required accepting voice input from the network to save and send as an attachment to a mail file. To leave a message, the user would specify a recipient using tones. We would look up the user in Directory Services to get their email address and verify that they exist. The instructions to the user are simple, start speaking and press the pound sign to end the message. Then we would have used the Data teams FilePipe which allows us to specify a file as a destination of data from the network, but we didn’t have a working implementation provided long enough for us to actually implement this. This would have written the audio data to a wave file. The wave file is then converted to Real Audio format using the Real Media Encoder. Next, using the users name, and the specified recipients name, a mail file is written out. The subject and body of the message both indicate that there is a Real Audio file attached to the message. The Real Audio file is encoded using base 64 encoding and appended to the mail file. Finally, the Unix program "sendmail" is called to actually send the file.

The user can close the connection from the "quit" menu option in the main menu, but it will also successfully disconnect if the user just hangs up at any time. We can keep track of all incoming connections, currently active connections, and disconnected connections via the signaling interface so we can perform the appropriate actions when initializing or closing a connection.

At this time, the entire system only supports one connection to the voice-email gateway at this time; however, it would be simple to extend our application to support multiple simultaneous users. The code is already multithreaded and the only issue in terms of the voice-email system would be capturing tones. As of now, the tones coming from the signaling team do not specify their source. If this information was added to the packets sent to us, we could match the tones with the appropriate users.

We had some problems doing system calls. When trying to use the Real Media encoder to encode a wave file as a Real Audio file, system calls from Java wouldn’t work. The command worked from the command line, from a shell script, and from a C program doing a system call, but not from Java. Fortunately, and almost accidentally, we discovered that by setting an environment variable in our shell, the same error occurred. So the solution was a bit of a hack. Instead of calling the Encoder directly we call a shell script to unset the environment variable and then call the Encoder.

A similar problem is that system call don’t allow for redirection. This caused problems calling the sendmail program which takes input from a file redirected into its standard input. Again the solution was to call a shell scrip to actually run the command.

There were a couple of minor problems related to integration. Some of the interfaces of components that we were using changed during our implementation. It did not require any structural modifications with our code but the documentation was not always updated in a timely fashion. Another slight problem involved InternetPhone application from the signaling team that we used for testing. There were periods where it did and did not work but they had a working version that we used for the demo.

For this project, we learned a lot about protocols and formats for communicating on the Internet. Specifically, we learned about the format of text messages, as specified by the IETF’s rfc821, and how non-text files can be sent by encoding them as text, and specifying their format. Reading throught the rfc’s gave a particular insight to the practical engineering that makes communication on the Internet possible. The format for text messages was specified in 1982, while MIME types were fully specified in 1996. It’s interesting to read and speculate about how they came up with a method of sending non-text data, using the format already set up for sending text data, without making too many changes.

We also learned more about the Unix operating system and environment. Although we both know how to use Unix, there are always more tools and tricks hiding. We learned about the mail system in detail. Mail is stored in a simple text format in the spool, and stored by mail programs in the same format in your home directory. There is nothing terribly complicated about email communication. It’s as simple as connecting to a port on a mail server, and sending the right text to specify a recipient and message. Also, the sendmail program is available to actually send out mail files.

Integrating code from many groups is difficult. We had three levels of integration. With the Directory Service, whom we started talking to early on, everything was working. They provided us with every thing we needed, and we were able to use it except for the occasional crash. Next, with signalling, whom we talked to with emails, and the occasional face to face, most things were working. We used their DesktopSignalling class for listening for connections, and communicating somewhat with clients. Actually sending the tones was worked out, just not functional on their behalf and needed to be faked. Finally, what we needed to use from data was written into our code, but not actually tested or used. We didn’t communicate with them very much except for reading their code, and documentation, and the occasional email later on.

This project definitely gave an insight into how large projects with many groups that need to cooperate can go. Since our application was to use code and functionality implemented by other teams, we learned about how important it is too document and communicate. It was quite frustrating having to sift through some else’s code which had little comments, to find function calls which weren’t clearly documented. Having someone say "Just read the Javadocs" is frustrating when the javadocs are hard to find and haven’t been updated.

Also, communication between people is best face to face. Sending emails may be a wonderful way to communicate in an idealized setting, but we were able to accomplish more in personal meetings. As we mentioned in our last report, the large group meeting, although long, and occasionally boring was quite helpful for learning about the status of other parts of the project.

Data team:

Pipes for data flow

Communications wrapper

Signaling team:

Construct an instance of the required signaling class

Hang-up a connection

Get the ports of the connection (for calls to data function)

Connection information

Connection manipulation

Cleanup DesktopSignaling

Directory Services team:

Construct an instance of the required directory service class

Declare our identity to the directory service (for access purposes)

Functions for access to directory entries

Perhaps having some earlier checkpoints. Having someone in the management staff say "Have your interface finalized" isn’t as imposing has having a course deadline for certain portions of the code. This could have gotten the teams to cooperate together more. Maybe having an earlier run through demo of the individual components, and then leaving a week or two for integration before a final demo.