My goal for the first part of the semester was the development of the signaling component. Initially separate signaling components were envisioned for the computer applications and a separate signaling component for the gateway (for interaction with the Telephone network). As the project developed, the two components were merged into one, with the gateway being treated as just another application. This new design makes the whole ITX project structure extremely modular and would ease the process of building application be it for the gateway or for desktops.

SIP Architecture: The current architecture although derived its ideas from SIP, doesn't truly implement SIP. Modifications to the signaling component should be made to incorporate SIP Architecture as it provides great advantage in terms of flexibility, modularity and ease of making changes to the signaling architecture.

Multi-Conferencing: The current architecture is capable of making multiple calls from the same location, but the multi-conferencing feature is yet to be implemented. There was a proposal for implementing a distributed mechanism of establishing and break-down of multi-conference calls. The other components of ITX can easily be changed to provide this functionality, but much work needs to be done in the signaling component in order to provide a distributed architecture that can establish and maintain a multi-conference call on the fly. The ability for any authorized user to join or leave the call at anytime could be a major step forward from the current systems which provide a Server-based system.

For the later part of the semester, I worked on building an Alarm Clock Application using the ITX API. The Alarm Clock has four components.

The Client: The Client consists of the classes that can be used to provide a web interface for the Alarm Clock Application. Functions like AddRecord, ChangeRecord, DeleteRecord and ShowRecords provide the functionality that can be directly accessed via a web interface. Each of these functions first authenticates the user (Read Section on Authentication below) and only then is the request forwarded to the Request Server via a Serializable class AlarmData. The process of making a request is a two part process, the first being the sending of the request and then listening on a socket for the confirmation or reply. If the Socket times out the class throws an exception so that the web interface can get to know that even though no confirmation has been received so far, the transaction might have been processed.

The Request Server: This component which resides on the same machine as the Call Server and the Alarm Database establishes a DAO connection with the server and listens on a port for incoming requests. For each valid incoming request a new Thread is spawned which acts as the proxy between the database and the Client. The Request Server is basically responsible for making sure that the transaction is completed.

The Call Server: The Call Server is the component that actually makes the calls. This is the real ITX application that utilizes the API to make calls to users. A thread queries the database for the calls that need to me made. For each record obtained in the query result a thread is spawned which makes the required call. If the user presses '#' the alarm is assumed to be turned off, otherwise the messages is played to its completion, the thread hangs up and it is assumed that the user has snoozed the alarm. A maximum of 10 snoozes is allowed after which the alarm is automatically terminated. If the thread is unable to make a call or if a busy signal is received then the call is attempted again during the next query of the database.

Alarm Database: Is a simple table that stores the information about all the calls that need to be made. The data is indexed by an ID field and the field Done keeps track of how many times the user has been called for a particular call.

Authentication: The authentication class currently authenticates each request. This class needs to change according to the type of authentication service we use. If we use Kerberose, then this class should return true or false depending on the result of the authentication process.

SQL Server: The current Alarm Database is on MS Access, which degrades the performance of the system if a lot of calls are to be made. In the event that the system needs to server a lot of user, the Database Engine has to be changed to another DAO supported Engine. The only change to the code would be changing the location of the

Transaction Rollback: There can be situations when a request for a transaction is sent to the database but no confirmation is received. The client assumes that the transaction never went through although it might already have been created. A mechanism is thus required to rollback transaction when a confirmation is not received. Note: For the Alarm clock application this needs to be done only when we are trying to remove a record from the database.