Sip Presence Server
Ankit Malhotra
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. The server described here currently supports only the ‘presence’ event package but its extensible nature allows new event packages to be added dynamically.
1. Introduction
Our server uses the National Institute Of Standard and
Technology’s (NIST) SIP [6] stack using the Java APIs for
Integrated Networks (JAIN) SIP
The Presence information is sent by clients in Presence Information Data Format (PIDF) as payload in a PUBLISH request. This is stored by the server in the database and sent to any watcher that is authorized to receive this data.
The Presence Server currently supports only one event package, ‘presence’ [3], but has been designed to allow processing of more event packages. The intention behind the server is to implement all basic presence event functions and allow implementation of other event packages to alter these presence messages as the event package deems fit. The remaining sections describe details of the implementation and the components of the server and how a developer can add an event package to the Server.
2. Related Work
There has been a lot of work going on in SIP Presence recently. BaseVoice LLC’s SIP Presence Server [5], Microsoft Windows Live Communications Server 2005 [8] and NIST’s JAIN SIP Presence Proxy [9] are some of the many Presence Servers available currently. But most these Servers have been designed to be some combination of a Registrar, Proxy and Presence Server. This Presence Server has been designed to be a stand alone Presence Server which processes only presence events. A Proxy or Registrar is expected to forward presence events to the server and users ‘register’ with the server through a web form for authentication and authorization purposes only. Moreover, the extensible design of the server makes it truly unique.
3. Background
The Presence Server is basically a stand alone Presence
Agent (PA) which accepts and stores information about users. It then sends
notifications to subscribers when the user’s presence state changes. A user can
have multiple devices, such as a PDA, laptop or cell phone, contributing his or
her presence information. For each device, a PUA pushes presence information to
the Server. When an end user wants to determine another user's availability
(his presence information), he or she requests that information. The request
identifies the target user by the unique
At each of these steps, publishing presence information by the user, subscribing to the presence information of another user and unsubscribing, the Server authenticates the user or watcher as the case may be using the username/password information received through the Server Registration web form.
4. ARCHITECTURE
4.1 SIP Architecture
Figure 1: SIP Presence Components
Figure 1 shows all the SIP Presence components and how they interact. The interaction between the various components can be understood as follows:
- The presentities and watchers interact with the presence Server through the Proxy/Registrar. The proxy must forward all presence Requests (PUBLISH, SUBSCRIBE and NOTIFY) to the Presence Server for processing.
- Presentities push their state information via a PUBLISH request to the Presence Server using rules as in [4].
- Watchers then subscribe to this information via a SUBSCRIBE request.
- The Server then processes the SUBSCRIBE request and checks authorization policy of the presentity and sends a NOTIFY containing the presence information of the presentity.
The Server must authenticate the clients each time a request is received and sends a 200 OK response for each correct request received.
4.2 Presence Server Software Architecture
Figure 2: Software architecture
Server
Server is the main class of the Presence Server which instantiates the SIP Stack and creates Listening Points for incoming messages. It loads all Event Package classes at run time by reading class names from the DB. All incoming messages are checked for proper format, the peers authenticated using their login information in the database and authorized via the access control list specified by the presentity for subscribe requests. A response for each message is then sent out accordingly.
Manager
The main purpose of the Manager is book keeping. It maps all the subscribers/watchers to their presentities/notifiers. Hashtables are used to store all notifiers and subscribers and each notifier has a table of all its subscribers. The class also stores any subscriptions for which no presence state is yet known so that the watcher can be notified when this data becomes available through a PUBLISH request by the presentity. A separate thread keeps track of the expires time of each subscription and presence data and the manager removes any presence data or subscription which has expired.
Event Parser
Event Parser is for event specific packages which performs a variety of event specific functions. It may be used to process subscription filters to the event, if any, check that the Content type and content for the event are compatible, set the default expires value for the event and create the content type header for the NOTIFY request. All event packages must implement the Event Parser interface to be dynamically loaded at run time.
DB Handler
DB Handler consists of static methods to access the backend MySQL database. Methods within this class include loading event specific classes, checking subscription authorization against the presentity’s access control list, reading user password for authentication purposes, storing and removing presence data.
Authentication
This implements the MD5 message digest algorithm to authenticate
the user. Users register using a password and the digest is created using the
username, password, the realm, a nonce, the request method and the
4.3 Database Schema:
Figure 3: Database schema
· Login: It stores a username and password for authentication with the server. The id is auto-incrementing
·
Acl: It contains an access control list with
<user-id,subscriber,eventid> tuples where subscriber is the SIP
· Events: A list of events supported by the server.
· Pdata: It contains a list of user’s presence data (pidf) which can store upto 2000 characters along with a timestamp and etag from the Etag Header of the Publish request which uniquely identifies the presence data. The eventid is for one of the events in the Events table.
· Eventloader: This is used to dynamically load classes for different eventpackages represented by ‘eventpack ‘.
5. PROGRAM DOCUMENTATION
Program Documentation along with extensibility framework can be found here
Javadoc can be found here
6. REFERENCES
[1] RFC 3261 SIP: Session
Initiation Protocol, J.
[2] RFC 3265 Session Initiation Protocol (SIP)-Specific Event Notification, A. B. Roach, Dynamicsoft, June 2002.
[3] RFC 3856 A Presence Event Package for the Session Initiation Protocol (SIP), J. Rosenberg, Dynamicsoft, August 2004.
[4] Scenarios for the SIP functionality of PUBLISH method
[5] SIP Center – A portal for the commercial development of SIP applications.
[6] JAIN SIP Project Home – Java.net home
for the JAIN SIP project, last accesses
[7] Javaworld – Dynamically extend your apps – A step by step tutorial to dynamically extend java applications.
[8] Microsoft
Windows Live Communications Server 2005 – Microsoft Live Communication
Server, accessed
[9] Jain SIP Presence Proxy – NIST’s
implementation of a Presence Proxy using JAIN SIP
Last Updated: 2008-19-02 by Ankit Malhotra