WebSphere brand IBM WebSphere Presence Server, Version 7.0

The Presence Server entry point

The Presence Server entry point provides ways for handling incoming PUBLISH and SUBSCRIBE requests more efficiently. You can designate a separate resource list server (RLS) component to handle all subscriptions on Presence lists requests, and you can set up a routing scheme in which different Presence Server clusters handle requests from different sets of users.

Collectively, this set of services is referred to as the Presence Server entry point.

Using the SystemConfiguration.xml file, you can enable a routing service for distributing requests among different Presence Server clusters. At the same time, you can also configure Presence Server to run in RLS mode. RLS mode is required if the routing service is enabled. For details, refer to the topic Configuring routing using the Presence Server entry point.

The following diagram shows the Presence Server and its relationship to other network elements in a typical configuration. In the diagram, an RLS cluster–representing the Presence Server entry point–receives traffic after it has passed through a DMZ or firewall and then directs the traffic to clusters in which Presence Server and IBM® XDMS are running.
Figure 1. Presence Server entry pointThe Presence Server entry point, positioned in a typical network configuration

Using routing to distribute SIP requests among clusters

You can deploy a number of different Presence Server clusters and have each one handle incoming SIP requests for a particular subset of users. This can facilitate workload balancing, especially as your network serves increasing numbers of users.

A routing component within the Presence Server application provides a default routing scheme by hashing user IDs. There is also a customizable interface (SPI) that you can use if you would like to develop alternative routing algorithms. You use this interface by mapping each user's fundamental ID to the SIP address of one of your Presence Server instances.

The routing process is applied the first SUBSCRIBE request and to all incoming PUBLISH requests for a single resource. Note that the first SUBSCRIBE request passes through the RLS and is then routed to the Presence Server instance. Subsequent SUBSCRIBE requests (resubscribe and unsubscribe) go directly to the Presence Server instance. All PUBLISH requests pass through the RLS and are then routed to the Presence Server instance.

The routing process works as follows: Presence Server extracts the "To" URI from the request header to and uses it to calculate the fundamental ID of the user who is the object of the PUBLISH or SUBSCRIBE. The fundamental ID is then passed to the routing component, which determines the SIP address of the Presence Server cluster to which the request should be routed.

The routing component and the routing SPI do not preclude any external routing element that you might have defined between the network entry point application and your collection of Presence Server clusters.

Note that the routing options apply only to the following:
  • Incoming PUBLISH and SUBSCRIBE requests on single resource, not on a list of resources
  • SIP requests, not HTTP requests

Deploying a separate resource list server

You can deploy a separate resource list server (RLS) component to handle all subscriptions on Presence lists, as described in the standard OMA-TS-Presence_SIMPLE-V1_1-20080627-A, chapter 5.5.

When the RLS component receives a subscription on a resource list, it interacts with Shared list XDMS to receive the list members. For each list member, the RLS creates a back-end subscription to the network entry point–for example, the S-CSCF. The back-end subscription is routed to the correct network and then to the correct Presence Server by means of the routing component within the Presence Server application.

The back-end subscription is established on behalf of the RLS, and as such it will remain active as long as there is at least one incoming subscription that includes the list member. When notifications are received from Presence Server, the presence information is stored in the RLS cluster database and is used to establish future subscriptions that include this member. When the presence information for all list members is received, the RLS applies presence rules filtering, combines the RLMI document, and send a notification to the original subscriber.

Note: Resource List Meta-Information (RLMI), as defined in IETF RFC 4662, is used as the document format.

This use of the RLS is designed to reduce network traffic and improve performance by reducing the number of subscriptions that have to be established between the RLS cluster and the Presence Server clusters. So that Presence Server can continue to generate full watcher information for every user, the original subscriber information is propagated by means of a PUBLISH request. The PUBLISH request is a proprietary message sent from the RLS to Presence Server.

This RLS component is deployed together with the routing component as a single application, referred to as the Presence Server entry point. The S-CSCF server forwards all presence related SIP requests to the Presence Server entry point, which performs the initial processing for each request.

Presence Server entry point does the initial processing of every incoming request. If the request is a PUBLISH or a SUBSCRIBE on a single resource, the request is routed to the correct Presence Server cluster. If the request is a SUBSCRIBE on a list of resources, the RLS component handles it.

The Presence Server entry point can handle HTTP requests as well. For each incoming HTTP request, Presence Server creates a matching SIP request and sends it to the S-CSCF. Alternatively, you can set up a cluster of Presence Server instances that handle all HTTP requests. The outgoing SIP messages are routed to the S-CSCF. When you use this approach, you reduce the burden on the RLS cluster and provide a separate mechanism for handling HTTP requests.




Terms of use
(C) Copyright IBM Corporation 2009. All Rights Reserved.