Template version : v0.5 <01/2009>

Cafe Presence Simulator One Pager

[

|(TableOfContentstitle='')]

1. Introduction

1.1. Project/Component Working Name:

Cafe Presence Simulator

1.2. Name(s) and e-mail address of Document Author(s)/Supplier:

Erik: erik.van.der.velden@ericsson.com

1.3. Date of This Document:

24/02/2010

2. Project Summary

2.1. Project Description:

The Cafe Presence Simulator will offer a designer the possibility to do (limited) testing of application using the presence related user procedures.
This way converged applications that use presence can be created and tested. The simulator is installed together with the Cafe-addon and does not require any configuration.
The simulator includes an XCAP/XDM server for RLS, shared XDM and presence XDM. It also includes a presence server, handling the publications and subscriptions.

Although the simulator tries to mimic the workings of a IMS network, not all the capabilities and performance of a real IMS network is guaranteed.

See below for a longer, more detailed technical description.

2.2. Risks and Assumptions:

The simulator is just that, a simulator. There is no solid guarantee that a service will work equally well in a real IMS network.

The simulator implements a subset of the full capabilities of an IMS network, i.e., the subset used by the presence related user procedures.
For example, aggregation and throttling is not supported.
However, the way it is designed, it could be used as a standalone simulator as well, for non-CAFE applications. Provided they conform to the mentioned subset of functionality.

3. Problem Summary

3.1. Problem Area:

Easy testing of cafe applications without the need to setup external network elements (like an openIMS network, or external presence server).

3.2. Justification:

To lower the threshold for application developers to design and test services.

4. Technical Description:

4.1. Details:

4.1.1 Overview

The Simulator is developed as a separate application, packaged as a WAR.
The Simulator has two servlets;

• The XCAPServlet - an HTTPServlet handling the XCAP requests
• The PGMServlet - an SIPServlet handling subscribe, publish and option requests

The XCAP related data is stored in memory.
The PGM related data is stored in various SipApplicationSessions.

4.1.2 XCAP handling

XCAP at its core can be seen as a document management system with versioning and specified access (read/write/delete) to parts of documents.
In a sense it is a REST architecture, where resources are documents or parts of documents.

XCAP handling is done using the xpath library which is already a part of CAFE.
In order to access parts of documents xpath is used.

In the architecure, the various XCAP documents are stored using a DAO pattern, without any intepretation of the content of these documents.
However, for several usages an interceptor can be registered.
Such an interceptor will interpret the stored, deleted or updated XCAP document as e.g., a shared list, a presence list or a rules document.
These interceptors will store the interpreted documents using their own respective DAOs and also will notify any PGM sessions that are affected by the change.
These notifications are done using SAS-targeted OPTIONS methods.

4.1.3 PGM handling

The Presence and Group Management handling involves the SIP handling part of the simulator.
The following Application Sessions are represented.

group subscription
Represented by a Sip Application Session.
This lives as long as there are live subscriptions for this group.
For each incoming subscription there are multiple outgoing subscriptions, one for each member in the group.

user
Represented by a SAS.
This lives as long as there are incoming user subscriptions or active publications.

user subscription
Either a direct subscription or an indirect subscription (via the group subscription).
The first type is not yet supported by CAFE, but the simulator allows for it.
This is represented as a Sip Session and a Servlet Timer to guard the duration.

user publication
An active publication is represented by a servlet timer and the published data.

rules
Rules are not represented by any SIP artifact, but a cached version of the rules is present in the user object.

The following relations are there:

• rules document and user

When a rules document changes (noticed by the interceptor) the corresponding user object (if any) is notified.
The user objects need to re-evaluate the subscriptions, to see if all the subscriptions are still allowed and get the correct notifications.
(e.g., a rules change might put somebody that has an active subscription on the blocked list, meaning that the subscription has to be terminated).

• presence list and group subscription

When a presence list is modified the corresponding group subscription object is notified using an OPTIONS message.
The change might impact the set of users in the list, so some outgoing user subscription might have to be removed or added.
Or the group is removed, in which case the group subscription has to be terminated.

• shared list and user and group

The changes to the shared lists are the worst, since this can influence both the rules (which can refer to lists) and the presence list (which refers to lists)
So in case of a shared list both types of objects are notified and the above actions can be taken.

4.2. Bug/RFE Number(s):

4.2.1 Bug/RFE Numbers from Issue Tracker

N.A.

4.2.2 Requirememt Ids that are being addressed as a part of this proposal.

N.A.

4.3. In Scope:

Basic simulator for XCAP and Presence.

4.4. Out of Scope:

Not all the functionality of a real IMS network is implemented.
Among others the following is missing:

• throttling/combination of notifications
• aggregation of different presence sources (although the basics are there)
• default presence document configuration
• any configuration of any type
• persistency of the information over restarts
• watcherinfo subscriber handling (there is preparation for this though).

At the time of writing the simulator CAFE did not support this.

• no filtering support

4.5. Interfaces:

The following standards are supported. All are quite stable.

4.5.1 Exported Interfaces

Disclose all interfaces that this project exports.

• Interface: RFC3903
• Stability: standard
• Former Stability (if changing):
• Comments:

• Interface:RFC4826
• Stability: standard
• Former Stability (if changing):
• Comments:

• Interface:RFC5025
• Stability: standard
• Former Stability (if changing):
• Comments:

• Interface:RFC4662
• Stability: standard
• Former Stability (if changing):
• Comments:

• Interface:4825
• Stability: standard
• Former Stability (if changing):
• Comments:

4.5.2 Imported interfaces

Disclose interfaces this project imports.

• Interface: XCAP client API library
• Stability: Stable
• Exporting Project: Sailfin CAFE
• Comments:

• Interface: JAXB2
• Stability: stable
• Exporting Project: JSE/JEE
• Comments:

4.6. Doc Impact:

Developers guide.

4.7. Admin/Config Impact:

None.

4.7.1 Configuration changes needed

4.7.2 CLI / GUI impact if any

4.8. HA Impact:

First of all, this is a simulator, and it is not the intention that this is used for real traffic.

The PGM component is created based on the Sip Application Sessions, so it will benefit from the HA-features of SIP.

The XCAP data (both unparsed and parsed) is currently not stored in a cluster-wide manner, but in memory on the instance where the HTTP request was routed.
This will not work correctly in a cluster in the current implementation.
(in the notifications to the user and group objects the data itself is not included, but it is just a trigger for the object to invalidate its cached data).
A solution would be to either store this data in a real database or make it accessible in the cluster, loosing the data in case of a cluster failure/restart.

The decision to model a publication as data associated with a sip application session related to a servlet timer means that the publication data is not persisted.

4.9. I18N/L10N Impact:

No

4.10. Packaging & Delivery:

The simulator is packaged as a war, which is deployed on system level.
It could be delivered and used standalone from sailfin CAFE, but currently will install together with the addon.

4.10.1 Binaries in which the code is delivered

PresenceAndGroupManagementSimulator.war

4.11. Security Impact:

Security is NOT implemented in the simulator.

4.12. Compatibility Impact

None.

4.13. Dependencies:

The functionality of the simulator is indirectly linked to the functionality of the user procedures in sailfin cafe.

4.13.1 Changes required in GlassFish

No

4.13.2 Third Party APIs

None.

4.14 Miscellaneous

5. Open Issues

Please list areas of the design and requirement which are not clear and need a discussion or clarification

6. Reference Documents:

None.

7. Schedule:

7.1. Projected Availability:

A first version is available.
Planned improvements include support for watcherinfo subscriber and aggregation.