Internet telephony - project overview


Table of contents


Reports and report format

An important part of the project is learning how to schedule and document your work. Part of the project grade is reserved for reports that you will submit from time to time. Reports should be written by each team of two, and both students will get the same grade for the report.  The third report, due in class on December 3rd, should be   2-3 pages long, and should be in the following format:
 
 

 

Date: 
Group number and name:
Team members: 
Task number and name: 

1. What you did since the  second report: Describe, in a page or so, the work you did in the last month. Are you on schedule?

2. Problems: What problems did you run into? Include both technical problems, and problems in coordinating your work with others.

3. What you learnt: What did you learn by working on the project?

4. What would you do differently next time: Mistakes you don't want to repeat!

5. Interface that your team will provide to other teams or use: Please give the exact procedure calls that you will make or support. 

6. What you need from the course staff: give details on documentation, advice, code, access to hardware

7. References: What sources did you consult in working out the details of your project? URLs for Web pages are acceptable for references.
 
 

Please submit the report using exactly this format. Descriptions not in the proper format will be rejected, and you will be required to resubmit your work.

While we will ask you to submit paper copies of your report, you should also create a HTML version to share with other members of your group. 

The final project report, due at the time of the demo, should be about 10-15 pages long. It should be in the following format:
 

 
Group number and name:
Team members: 
Task number and name: 

1. What did you set out to do? (1-2 pages) Use a figure and accompanying text to describe what you set out to do. You can reuse part of your first report if you wish. You should have sufficient detail so that someone who is not familiar with the project would still be able understand the scope of your work. For instance, imagine giving this to a friend who is not in the class--write something that this person would be able to understand without having to ask you for help.

2. What did you actually accomplish? (2-3 pages) Write down exactly what you managed to get done by the time of the demo. Did you achieve all the goals you set out to do? Did you do something that you didn't expect to be doing when you started?

3. Problems: (1-2 pages) It is possible that you did not actually accomplish what you set out to do :-( If so, why? What problems did you run into? Include both technical problems, and problems in coordinating your work with others. Be as specific as you can about technical problems. This is the only way we have to determine whether you really tried to solve the problem, instead of just giving up with token effort. 

4. What you learnt: (1-2 pages) What did you learn by working on the project? Include details on technical things you learnt, as well as what you learnt about dealing with large projects, collaborating with other busy people, and dealing with other coursework.

5. What would you do differently next time: (1-2 pages) Everyone makes mistakes. But good learners don't repeat mistakes, they make all new ones! This project gave you a lot of freedom to make mistakes. What will you look out for the next time you undertake a large collaborative project?

6. Interface that your team will provide to other teams or use: Please give the exact procedure calls that you will make or support. This is your final interface spec. C/C++/Java code is OK. 

7. Advice for the course staff: What mistakes did we make in running this project? Please help us improve the course.

8. References: What sources did you consult in working out the details of your project? URLs for Web pages are acceptable for references.
 
 


References

Here is a list of references for the project. If you come across other links, please send mail to Cristi.

1. Everyone should read the following paper: "Internet Telephony: Architecture and Protocols an IETF Perspective" by Schulzrinne and Rosenberg. (Pdf format)

2. The following web sites have useful links


Links to team descriptions

Team 1 - Data exchange on the Internet

Team 2 - Signaling

Team 3 - Data flow in the gateway

Team 4 - Directory service

Team 5 - Billing, accounting, and pricing

Team 6 - Management and integration

Team 7 - Voice-email gateway

Team 8 - Multiparty audio conferencing + whiteboard

Teams 9 and 10 - Unspecified applications