Greetings and salutations...

For my final year project at university I've been asked to research and build a video conferencing server. The requirements are that it be low cost (If the uni wanted to just throw money at the problem there are several commercial solutions, which I'll talk about in due course), low bandwidth (my reasons will be explained in a moment), and be able to use a web browser as a client.

The reason they want this server is so that they can communicate with distance learning students in other countries. Here's where the low bandwidth specification comes in. A lot of the universities distance learning students (referred to as DLSs from here out) reside in less technically developed countries where the internet infrastructure is even more primitive than it is in this country.

The web browser specification is for a few of reasons. First, everyone has a web browser on their machine. No one needs to mess around installing one, which removes one of the hurdles of this working. If someone who is totally non-technical can just navigate to a page (the link for which could be emailed to them or whatever) then they will be able to make use of this tool and participate in a conference. A second reason is to circumvent any firewalling that may be in place. If the conferences can be streamed straight into a browser via port 80 using http then there will be no need for any party participating in a conference to start putting holes in their firewall. This leads into another reason for using a web browser. Access privileges. This method will potentially allow a DLS to go into any webcam equipped web cafe, or whatever, and without any need to install software or adjust security settings they can just get on with the conference.

As I've mentioned already, there are several solutions to this out there at the moment. There are hosted solutions like TokBox, and there are self-host solutions such as Adobe Acrobat Connect. The problems with these is that the former allows the uni (hereafter referred to as the client) no control of the server itself and no opportunity to make configuration changes and optimise the system for their own use, and the latter, and its ilk, are prohibitively expensive for a service which would probably not see enough use to be worth the large investment.

The reasons for this blog are mostly selfish. It's an attempt to document the project as I go along, thereby making the writing of the final dissertation a little less stressful. A less selfish knock on of this is that my progress will be documented here for anyone attempting a similar project to refer to and hopefully avoid running into the same issues that I inevitably will.