The SIP Buddy List System
Advanced Internet Services Final Project

Moshe Sambol
Columbia University, Spring 1998
New York, NY 10027
mjs@cs.columbia.edu

Abstract

A Buddy List system, based on the Instant Messenger service of America Online, which is implemented in Java and uses the Session Initiation Protocol for messaging and session setup.

Contents

Introduction
Related Links
Accomplishments
Screen Captures
SIP Availability API (sample code)
Tools Used, Installation Instructions
Design Decisions
Future Work

Introduction

With the popularization of the internet and increasing electronic connectivity, traditional email has been complimented with more interactive messaging services to provide online chats and multimedia conferences. Live interaction requires the presence of the involved parties themselves, not just software servers which can respond to queries and save messages for later consumption. Users therefore must plan sessions and schedule apropriate times with each other. Unplanned casual encounters are not provided for in the electronic medium. At the very least users must be aware of each other's availability online: both the physical presence and the access to the required resources. Thus a demand has arisen for utilities which track the online "presence" of individuals and alert a user when someone of interest is available for potential interaction.

America Online provided the first widely used such utility, called Instant Messenger. It maintains "buddy lists" and alerts the user when one of the members of the buddy list is using his or her account, and is thus available for live interaction. ICQ provides a more comprehensive system which is more flexible and customizable but provides essentially the same service. The primary difference between these two systems is the way they define "available." The simplest definition of available, AOL's original assumption, was that the user is logged into his or her account. ICQ users are available whenever they have the ICQ application running; thus users have some control over the public broadcast of their availability. ICQ users can also selectively control the response of the system to others' inquiries by specifying groups of buddies for whom they are available. (Current versions of both systems now allow users to switch between "here" and "away" modes.)

Clearly then a better mechanism would be desired with which to configure when a user is available and to whom, and even with which media. Several other improvements might include: expanding the types of interaction available to users (currently they can only choose between simple text chat and email); allowing for conferences of more than two parties; allowing flexibility in the conference-time expansion of the list of participants and the involved media and resources, etc.

Another weakness of the current systems is that they require a central point of registration for all users. To use the system, or to be found by the system, every internet user has to have a copy of the software, whether it be AOL's or ICQ's, and has to be registered with the respective server. (The two systems are also not compatable: ICQ users cannot have Instant Messenger users as buddies unless they use both services at once.) This promises to scale poorly and to allow for a central point of failure.

Finally, from the consumer's perspective it is a weakness of each of the existing systems that they are closed-ended applications; they provide a specific set of functionality and no API for adding to that or creating other applications based on their information base. It would be to the benefit of the general consumer market if there were a publicly available API which would allow application developers to utilize the already existing databases and registration servers and write programs which perform actions based on information of when a party is online and available to them. (It would make interesting further work to expand the system so that resources, in addition to users, could be tracked for availability within the same system. Users would be notified when a specific machine or other resource (software license) was available for their use.)

The Session Initiation Protocol provides a way to address each of these issues. It is a vendor independent standard which is not locked to any specific implementation, platform or application. It provides for excellent scalability, roaming users, multi-party conference setup and maintenance and conference-time resource negotiation. SIP provides mechanisms for extremely customized rule sets which can be used to define availability based on requesting party, time of day, priority of message, media requested or available for interaction, and more. SIP negotiates session details but interacts with external applications which actually handle the conversation data. It leverages already existing software and allows users to choose their own communication packages and media of preference.

The purpose of this project is to write a new buddy list system, implemented in Java for portability, which will use SIP for messaging and session management. It hopes to address at least some of the above mentioned issues and to result in an open system which provides a Java API to querying and using SIP "availability" information.

Because of time restrictions only a simple application and user interface will be created which will provide only simple services at the level of AOL's Instant Messenger. The intent is that this will serve as a proof of concept and that the available API and documentation will make it easy to expand the functionality or write other, more robust systems. In general, it is assumed that a buddy list application as a separate entity is not particularly useful, and that the functionality would actually be encompassed within a fully fledged SIP user agent, the details of which can be found in the online SIP documentation.

Related Links

America Online
I C Q
The Session Initiation Protocol

Accomplishments

The major accomplishments of this project can be broken into two categories: the SIP BuddyList application and the SIP Availability API.

The application is very similar to America Online's Instant Messenger. It provides a small GUI in which the user can define buddies based on name and SIP URL. The application tracks these buddies and visually cues the user when they become available and unavailable.

Screen captures:

The new SIP availability API provides an open architecture to allow clients to take advantage of SIP's availability information base. Getting access to and using the SIP information is made extremely simple and the API was designed in the style already familiar to Java programmers.

A simple application which uses SIP availability information is presented below. The client simply imports the SIP Java classes, creates a user agent and then adds event listeners:

   // test program to wait till Bill Gates is available and then notify the user

   import edu.columbia.sip.*;

   public class TestAvailable {

      // our SIP User Agent Server
      private SIPServer _server;

      public static void main(String args[]) {

         _server = new SIPServer(SIPServer.USER_AGENT, 0);

         SIPAvailabilityListener sal = new SIPAvailabilityListener() {

             // the URL of the person we want to get in touch with...
             private SIPURL billurl = new SIPURL("SIP://Bill.Gates@microsoft.com");

             public SIPURL getURL() {
                return billurl;
             }
             public void here(SIPAvailabilityEvent sae) {
                System.out.println("Attention: Bill is available!");
            }
            public void gone(SIPAvailabilityEvent sae) {
               System.out.println("Sorry, now he's gone.");
            }
            public void unknown(SIPAvailabilityEvent sae) {
              System.out.println("Sorry, can't find SIPServer where " +
                                           " that user is registered.  Giving up.");
              System.exit(1);
            }
       });

       _server.addAvailabilityListener(sal);
       System.out.println("Now waiting to hear status of Bill's availability...");
    }  // end main();
  }  // end class TestAvailable

SIPAvailabilityListener is actually an interface, so it is easy to build new classes which constructively take advantage of it:


	import edu.columbia.sip.*;
	import java.awt.*;

	public class BuddyLabel extends  Label implements SIPAvailabilityListener {
		private SIPURL _myurl;

		public BuddyLabel(String nickname, SIPURL url) {
			super(nickname);
			_myurl = url;
		}

		public SIPURL getURL() {
			return _myurl;
		}

		public void here(SIPAvailabilityEvent sae) {
			setForeground(Color.green);
		}

		public void gone(SIPAvailabilityEvent sae) {
			setForeground(Color.black);
		}

		public void unknown(SIPAvailabilityEvent sae) {
			setForeground(Color.red);
		}
	}  // end class BuddyLabel


The SIP Java API is documented in the online javadoc generated pages, as is the buddy package.


Tools Used, Installation Instructions

This project was designed to be maximally portable. It relies only on Java tools and code written in 100% Java. The libraries which are referenced are:

The 1.1.5 Standard JDK Distribution
Swing 1.0, the graphics extention to the JDK
The Java Generic Library from Objectspace, which provides robust and efficient containers and algorithms much like the C++ STL

The edu.columbia.sip package, the Java implementation of SIP.

To install and use the SIP BuddyList application, first download each of the above mentioned libraries and install them. Jar files are provided which need to be included in a CLASSPATH environment variable so that the java executable can find them.

Once each of the libraries are installed, download the edu.columbia.sip.buddy package (jar file) and install it as well. The system can then be run as follows:

java edu.columbia.sip.buddy.BuddyListApp [userSIPURL] [password] [lookAndFeel (M or L)]

Running just java edu.columbia.sip.buddy.BuddyListApp will give usage instructions.


Design Decisions

SIP HERE and GONE requests cause a reference to the interested party to be held at the receiving end. This party is kept informed, through new connections and SIP meseages, of the status of the registrant. A mechanism is required for terminating the reference and ending the communication; perhaps 'BYE' would suffice. The best way to carry out the conversation has yet to be figured out.


Future Work

Actually starting a session and interacting
Tree organization of buddies for AOL-like user controlled structure
Make buddy lists serializable and restorable
Once session is active, drag and drop buddies onto session control window to add (invite) them.
SIP services themselves: locating a server based on SIP URL, messaging.
Both: Improve documentation!