Installation Instructions

• How to run Presence Server with RLS (Server)
• Copy the binaries in 'pa' directory to a directory you want to install. The 'pa' stands for Presence server Agent.
• Locate XML file to the directory in which 'pa' is installed
• XML file name SHOULD match with SIP URI for resource list, for example if the SIP URI is 'yb2149-buddies@seoul.clic.cs.columbia.edu', the XML file name must be 'yb2149-buddies.xml'.
• Run the Presence server Agent by typing './runua.sh' at the directory you install 'pa'. Note that there are some option tags you might want to use.
• -v: Print version and exit
• -d category: verbose mode for the category. (category: all, sql, net, sdp, misc)
• -o tracefile: put debug trace in this file
• -a audiotool: specify a different audio tool
• -p port: listening SIP port, default is 5060
• -f file: command file to be executed
• -n: non interactive mode, forbackground.
• -i: use dotted decimal for self address.
• -t: print timing (latency) information.
• -P port: media self port number. Default is 10000
• -H HostName: IPv6 host name, if different from normal
• -S: Do not use SSL, to avoid annoying error messages
• -l: Default payload type for testing. 0 = PCMU, 8=PCMA, etc.
• How to run SIP User Agent (Client)
• Copy the binaries in 'sipua' directory to a directory you want to install. The 'sipua' stands for SIP User Agent.
• Run the SIP User Agent by typing './runua.sh' at the directory you install 'sipua'. You can also use above option tags for 'sipua'
• After running 'sipua', you can use following command format for each request. The exact command in test case is used to help easy understanding
• For PUBLISH request:
  • publish sip:won@seoul.clic.cs.columbia.edu proxy=sip:seoul.clic.cs.columbia.edu
• For SUBSCRIBE request:
  • subscribe sip:yb2149-buddies@seoul.clic.cs.columbia.edu from=sip:yb2149@seoul.clic.cs.columbia.edu proxy=sip:seoul.clic.cs.columbia.edu event=presence supported=eventlist
• For UNSUBSCRIBE request:
  • unsubscribe sip:yb2149-buddies@seoul.clic.cs.columbia.edu from=sip:yb2149@seoul.clic.cs.columbia.edu proxy=sip:seoul.clic.cs.columbia.edu event=presence supported=eventlist

Code Documentation

• The Modified Classes - mentioned only the functions created or modified
• 'DataManager' Class
• Some accessor(get)/mutator(set) functions for resource list
• Functions that create and remove the 'RLSPresentityDS'
• 'MySIP_PA' Class
• 'RLSSubscribe' and 'RLSNotify' functions - The SUBSCRIBE/NOTIFY requests SHOULD have additional header fields such as 'Supported' for SUBSCRIBE and 'Require' for NOTIFY
• 'OnSubscribe' and 'OnNotify' functions - 'MySIP_PA' calls the appropriate handler for RLS in 'OnSubscribe' function and sends the NOTIFY request for back-end subscription in 'OnNotify' function
• 'SubscribePresHandler' Class
• Constructor - 'SubscribePresHandler' SHOULD check the 'Expires' header field and process for making unsubscription if needed
• The Created Classes
• 'RLSPresentityDS' Class
• Provides RLSPresentity Data API's
• Contains functions that create, store, retrieve and delete RLS's presentity
• Has mapping table between incoming call and outgoing call so that RLS can send a NOTIFY request to the proper subscriber
• 'SubscribeEventlistHandler' Class
• Validates, authorizes and creates a subscription for a SUBSCRIBE request
• Generates a notification with the appropriate state if the resource is in the same domain with local RLS
• Sends a SUBSCRIBE request to the external RLS if the resource is in the different domain with local RLS
• 'SendEventlistNotification' Class
• Creates an appropriate body of the NOTIFY request
• 'UnSubscription' Class
• Derives from the 'PresenceFunction' class
• Has an 'apply' function so that RLS can schedule the unsubscription
• Removes the subscriptioin and its presentity

Test Case

User should locate XML file for resource list in the directory which 'pa' is installed at and XML file name should match with SIP URI for resource list. For example, if the SIP URI is 'yb2149-buddies@seoul.clic.cs.columbia.edu', the XML file name must be 'yb2149-buddies.xml'. For this project, there is no interface to manipulate the XML file. However, the RLS will detect the change of XML file and update the information if needed. For automatic detection, user needs to turn on 'inotify' for the XML file by typing the command 'inotify' at the command line prompt in the directory which 'pa' is installed at. (Not implemented. see Future Work)

The following is the resource list with SIP URI, 'yb2149-buddies@seoul.clic.cs.columbia.edu' which represents the XML file, 'yb2149-buddies.xml'



The following picture shows how RLSes work when a user sends a SUBSCRIBE request with resource list. The resouce list has three resources. One is in the same domain (seoul.clic.cs.columbia.edu) with the local RLS resides and two are in the different domain (vienna.clic.cs.columbia.edu and delhi.clic.cs.columbia.edu). Note that we are not using an aggregating mechanism to create body of the NOTIFY request.



The resources in the list should PUBLISH first to their RLSes respectively. The list subscriber will not be notified of any information from the resource who does not PUBLISH to its RLS. After subscribing to a resource list, local RLS can notify first of the state of the resource in the same domain. For resource in the different domain, local RLS sends the SUBSCRIBE request to another RLS in the domain which the resource belongs to. After receiving NOTIFY requests from the RLSes, local RLS can notify to the list subscriber.

If the SUBSCRIBE request to resource list has the 'Expires = 0' header field, RLS makes unsubscription for the resource list. After receiving current state of the resources in the list, the subscriber will not be notified from them and the subscriptions for the resources will be removed according to the 'Subscription-State' header field in the NOTIFY request.

The requests for test are as follows:

• Initiate the list subscription by sending a SUBSCRIBE request to the local RLS (seoul.clic.cs.columbia.edu)

• Local RLS sends a NOTIFY request immediately upon accepting the subscription.

• For the resource in the different domain (vienna.clic.cs.columbia.edu), local RLS subscribes to the RLS in vienna on behalf of the list subscriber.

• RLS in vienna is the local RLS for the resource in vienna and notify the state of the resource to the RLS in seoul

Future Work

• One risk introduced by the ability to nest resource lists is the possibility of creating lists that ultimately contain themselves as a sub-list. Implementations of RLS that creates back-end subscriptions must implement safeguards to prevent such nestings from creating an infinite loop of subscriptions.
• Can't install 'inotify' on the clic machine. If we can install the 'inotify' on the clic machine, the functionality, automatic detection, can be easily added to the RLS

Acknowledgements

Vishal K. Singh   For providing guideline of the project implementation.