The Calendar module uses the unique identifying information of a person's Google calendar to access information about their schedule. It runs repeatedly according to a predefined scheduling, checking for changes to the user's calendar.
Operating System : Windows.
Language: Java
Hardware: None
Software: MJSIP sipstack, Publish class, Google Calendar jar files.
A user must have a Google calendar account.
Configuration File: A configuration file is used by the module to setup the presence server information it needs. The configuration file includes information about a user's calendar information such as a magic cookie unique to each user's calendar and the email address associated with the calendar account.
The project Final ABD contains the following directories
1) log: log files are kept which show the publish messages and the responses received to them.
2)config: configuration files such as calendar.cfg which lets users setup username, hostname and dest-port information, user email address information, magic cookie information needed to access the calendar, the duration after which the program should be run again.
3) lib: contains all the jar files needed the project such as sip.jar (sip stack), and jar files needed for the Google API.
To run the program: java -classpath lib\sip.jar;lib\gdata-calendar-1.0.jar;
lib\gdata-client-1.0.jar;lib\gdata-codesearch-1.0.jar;caledar.jar
BusyDiscovery.calendar.AutomatedDiscoveryCalendar
The configuration file used by the calendar is parsed using the Parser class in the MJSIP library. A sample calendar.cfg file is shown below:
# Automated Busy Discovery Calendar
configuration file
# ___________________________________________
#
# ********** sip ***********
local_port=6060
username=Rekha
hostname=cs.columbia.edu
min_duration=30
email_address=rekha.duthulur@gmail.com
magic_cookie=private-5bb3919cc7b768c48bf51b554621627a
The local_port parameter contains the information about the port that the sip stack is listening on for incoming responses. The username host name parameters are used in the creation of the PUBLISH message such as for the SIP Request. The min_duration parameter specifies how often the program is run. Finally the email_address and magic_cookie parameters contain information specific to a user's Google calendar account.
The program runs a check on the Google calendar at startup. The configuration file contains a parameter min_duration which contains the duration in minutes after which the calendar must be checked for appointments. Therefore the calendar module is run even min_duration minutes. The program reads the entries in the calendar in a given time frame where
start-time = current time
end-time = start-time + min_duration.
The calendar returns all the entries which fall within the time range. The program iterates through the list of entries and sends a publish message for every one of them. If the entry contains location information, the location information is translated into the PIDF body of the message.
Since the program is run according to the configured duration parameter, a schedule appointment which encompasses more than one duration may send multiple publish messages to the presence server.
Incase the calendar does not have any event or any information for a given time period, the program sends a PUBLISH message to the presence server notifying it that the calendar entry is empty. The Publish Message is described in the Publish Module.The PIDF skeleton structure is fixed with each module filling in information such as the location, activity of the user, username and whether they are busy or not, which is set in the <basic> xml element as closed or opened.
Sample PUBLISH message sent to the presence server
PUBLISH sip:Rekha@cs.columbia.edu SIP/2.0
Via: SIP/2.0/UDP honamsun.cs.columbia.edu:5060;rport;branch=z9hG4bK49200
Max-Forwards: 70
To: <sip:Rekha@cs.columbia.edu>
From: <sip:Rekha@cs.columbia.edu>;tag=z9hG4bK18880005
Call-ID: 659985915641@honamsun.cs.columbia.edu
CSeq: 1 PUBLISH
Contact: <sip:Rekha@cs.columbia.edu:6060>
Expires: 3600
User-Agent: mjsip stack 1.6
Event: presence
Content-Length: 742
Content-Type: application/cpim-pidf+xml
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:cpim-pidf"
xmlns:local="urn:automatedBusy:pidf-status-type"
xmlns:dm="urn:ietf:params:xml:ns:pidf:person"
xmlns:es="urn:ietf:params:xml:ns:pidf:status:rpid-status"
xmlns:et="urn:ietf:params:xml:ns:pidf:rpid-tuple"
xmlns:ts="urn:ietf:params:xml:ns:pidf:timed-status"
entity="pres:Rekha@cs.columbia.edu">
<tuple id="329c8b20">
<status>
<basic>opened</basic>
<dm:person>
<et:class>Rekha</et:class>
<dm:status>
<es:activities>
<es:activity>Calendar Entry empty</es:activity>
</es:activities>
</dm:status>
</dm:person>
</status>
</tuple>
</presence>
The calendar application was tested by adding various entries to the Google Calendar. The program was tested by:
Adding entries to the calendar which are missing some information
By creating entries which span multiple slots of time
Leaving slots empty
Creating multiple short appointments.
The publish messages generated were observed to ensure that key information was being sent to the presence server.
Some appointments may slip through gaps in reporting, depending on the frequency with which the program runs.