Program Documentation for SIP Presence Server

Ankit Malhotra

Columbia University
New York, NY 10027
USA

am2994@columbia.edu
 
Jong-Yul Kim
Columbia University
New York, NY 10027
USA

jong@cs.columbia.edu
 
Henning Schulzrinne
Columbia University

New York
, NY 10027
USA
hgs@cs.columbia.edu

 

Abstract

 

A Presence Server processes Session Initiation Protocol (SIP) Presence messages on behalf of presentities. The Server stores status information of each of its users and sends presence updates to users who subscribe to this presence information. Thus, user agents need only worry about their own presence information and the Server would forward this information to all the user’s watchers. Similarly, the user agents need only authorize subscriptions while the Server would authenticate the watchers, create subscriptions, remove expired subscriptions and send presence updates. This server supports only the ‘presence’ event package but its extensible nature allows new event packages to be added dynamically.

 

System Requirements

 

  • Operating Systems: Windows 98, 2000, NT, XP, Vista, Linux
  • Java Development Kit (JDK)1.5 or above
  • Java Runtime Environment (JRE) 1.5 or above
  • Network connection for both clients and server
  • Php support
  • MySQL server
  • Web Server

Installation Instructions

  • Download the source code along with the jars needed to run the server : jain-sip-api-1.2.jar , jain-sip-ri-1.2.jar, log4j-1.2.8.jar and mysql-connector-java-5.1.5-bin.jar
  • Make sure the pr_reg.html, php2.php and presence.db are in the document root folder of the web server.
  • Run the server using the server.jar as follows :

java -classpath jain-sip-api-1.2.jar;jain-sip-ri-1.2.jar;log4j-1.2.8.jar;mysql-connector-java-5.1.5-bin.jar;server.jar subsnotify.Server

 

 

Program Operation

 

After the server is started, it instantiates the SIP stack and listens for incoming message events on both its TCP and UDP listening points. The Server processes messages on the basis of request type. A separate thread within the Manager module, checks for expired presence data and subscriptions and removes the same from the database. For detailed description of working of each module, see javadoc here.

 

Clients used

  • Pua.pl – An open source presence user agent  by BerliOS
  • Sip Communicator – Open source Java VoIP and Instant Messaging client.

 

Extensibility Framework

 

The Server allows support for event packages apart from the ‘presence’ event package already implemented. This is achieved by the means of dynamic class loading. The Eventloader table maintains a matching between the event type and the corresponding class to load for that particular event.

 

The EventParser interface allows an implementer to define behaviors for a particular event which would differ across Events. EventParser gives a list of these methods. An implementer has to perform the following steps to define behavior for a particular event:

 

  • Create a new class and implement the EventParser interface. Any additional functionality besides the methods for EventParser must be implemented as private methods within the class.
  • Add an entry to the Eventloader table in the database specifying the event type as seen in a SUBSCRIBE or PUBLISH request under ‘eventpack’ and the full classname, ‘events.foo’, where foo is the new class created under ‘toload’.
  • Add the ‘foo.java’ file to the class path under the ‘events’ package of the server and run the server.

An example loading operation:

 

Class c=Class.forName(classname);

EventParser eventParser=(EventParser)c.newInstance();

 

All EventParser instances are stored in a hashtable (eventClasses) indexed by the ‘event type’ when the Server is started and looked up whenever required. To call a method for the ‘foo’ event package, the following syntax has been used:

 

EventParser eParser=eventClasses.get(foo”);

eParser.method1();

 

Possible Enhancements

 

  • Add watcher events to alert a user when a subscription to any of his supported events is created or requested.
  • Implement TLS (Transport Layer Security) to further enhance the authentication mechanism.
  • Act as an aggregator of presence information rather than just a store and forwarder of event mechanism.
  • Configure with a registrar/proxy as shown in fig above (hyperlink) and anable a proxy to forward presence requests to Server.

Acknowledgements

 

I would like to thank NIST’s team that worked on JAIN SIP Stack that forms the underlying base of the project with excellent documentation and manuals for developers. I would also like to thank Jong-Yul Kim for his great inputs, encouragement and guidance throughout this project. I would also like to thank Prof. Henning Schulzrinne for his vision and guidance without which this project would not have been possible.