The main goal of adding Resource List Server (RLS) to Presence server is to provide a solution for environments in which access bandwidth is limited such as wireless networks. In such environments, generating excessive messages can be a serious problem for the network. Without RLS, Presence server accepts and manages individual subscription for every single resource which the watcher is interested in and sends notification to the watcher when the presence information of the resource changes. However, sending individual request for each subscription might cause a network traffic problem since a watcher is usually interested in multiple resources.
RLS is the functional entity for the Presence server to reduce the SUBSCRIBE traffic. RLS applies the extension to the 'Session Initiation Protocol (SIP) - Specific Event Notification' mechanism. The general concept of the event notification is that entities in the network can subscribe to resource and those entities can be notified when the state of the resource changes.[1] (see Message Flow) However, in the extension, instead of sending a SUBSCRIBE request for each resource individually, the watcher can subscribe to an entire list by sending a SUBSCRIBE request to the RLS and then receive NOTIFY requests whenever the state of any of the resources in the list changes.[2] (see Message Flow)
A resource list for RLS is basically identified by a URI, and it has a list of zero or more URIs. Each of these URIs is an identifier for an individual resource for which the watcher wants to receive information. [2]
The organization of the report is as follows:
1) Introduction
2) Operation
3) Class Diagram
4) Call Flow
5) Message Flow
6) Program Documentation
7) References
Presence server without RLS accepts individual subscription for each resource and notifications of changes in the state of a particular resource. The basic functionalities supported by Presence server are as follows [3]
RLS is providing a functionality for the Presence server to reduce SUBSCRIBE traffic. RLS supports Presence server to be a notifier for the watcher with resource list. However, RLS can be a standalone server as well as the part of the Presence server. With RLS, the watcher can subscribe to lists of resources by sending a SUBSCRIBE request with a resource list identified by a URI and receive NOTIFY requests from resources in the list. The list contains zero or more resources that can have their individual states. RLS accepts the subscriptions to the resource lists and send notifications to update watchers of the state of the resources in the resource list.
For each list subscription, it creates at least one virtual subscription for every resource in the resource list being subscribed to. In some cases, such as when the RLS is not in the same domain with the resource in the list, this virtual subscription will be associated with a back-end subscription. The back-end subscription is the subscription created by the RLS to learn of the state of a resource in different domain. In back-end subscription, RLS acts as a watcher. It subscribes to the external RLS to obtain the presence information of the resource which is in different domain. In other cases, such as when the RLS is in the same domain with the resource in the list, the virtual subscirpion will not have a corresponding back-end subscription. [1]
When the users wish to subscribe to the resource list, the following mechanism is used. The first step is the creation of a resource list. The resource list could be manipulated through a web page or some other protocol. But, this functionality is not supported by this project. The users now can subscribe to resource list by sending a SUBSCRIBE to a RLS. The RLS creates subscriptions and generates notifications to the watcher if the resources are in the same domain, otherwise it generates back-end subscriptions. For back-end subscription, the RLS subscribes to the resources in different domain on behalf of the watcher. There are 3 main parts of the operation of List Subscriptions [2]
MySIP_PA will call the appropriate handler from sub-handlers of the 'PresenceHandler' depending on the application when a request is received. In the case of RLS, it calls the 'SubscribeEventlistHandler' to take care of the SUBSCRIBE request.
There are two main classes for RLS, 'SubscribeEventlistHandler' and 'SendEventlistNotification'. The first one is derived from the 'PresenceHandler' and second one is derived from the 'PresenceFunction'. 'SubscribeEventlistHanlder' validates, authorizes and creats a subscription for the SUBSCRIBE request and generates notifications using 'SendEventlistNotification' to create body of the NOTIFY request.
'SubscribeEventlistHandler' creates 'SendEventlistNotification' to make the body of the NOTIFY request when it generates a NOTIFY request.
When the request is received from the resources, the library calls first 'OnReceiveRequest' function on a sip session object which is MySIP_PA. From there, RLS can branch its call based on the request. The following diagram is to show how RLS works when the SUBSCRIBE request is received
The following diagram shows how RLS works when the NOTIFY request is received
'Event Notification' mechanism employed by Presence server can be explained by following simple diagram. [1] The general concept is that entities in the network can subscribe to resource or call state for various resources or calls in the network, and those entities (or entities acting on their behalf) can send notifications when those states change. The typical message flow would be as follows:
RLS employs the concept of 'Event Notification' mechanism. Furthermore, it extends its idea by sending a SUBSCRIBE request to the resource list and receive NOTIFY requests when the state of any of resources in the list changes. The typical message flow for RLS is described by the following diagram. In the following diagram, we request a subscription to a resource list and two of the resources in the list are in the different domain with the local RLS.