Parlay X 2.1 Presence Communication Service

The following chapter describes the Parlay X 2.1 Presence communication service in detail:

An Overview of the Presence Communication Service

Configuration Specifics for the Presence Communication Service

An Overview of the Presence Communication Service

The Presence communication service implements the watcher aspect of the Parlay X 2.1 Presence set of interfaces. For the exact version of the standard these communication services support, see “Appendix A: Standards and Specifications” in Concepts and Architectural Overview, another document in this set.

Presence information is a collection of data on an end user’s status, including such things as current activity, environment, available communication means, and contact addressees. Using the Presence functionality, an application can function as a client in two modes: as a watcher or as a presentity. A watcher is a client that is interested in consuming presence information. A presentity is a client that allows its presence information to be delivered to watchers. WebLogic Network Gatekeeper currently supports the watcher functionality.

The Client as Presence Consumer

Subscribe to obtain presence data. Each subscription requires authorization by the presentity. The authorization is returned asynchronously via the notification interface.
Choose to acquire presence information once a subscription has been established using:

Direct synchronous polling. This is only effective for a single presentity. Groups are not supported
Specific notifications. These can be used for a single presentity. The watcher sets a notification trigger based on certain user presence attribute changes.

Possible attribute types include:

Activity (User’s status: Available, Busy, At Lunch, etc.)
Place (User’s current location: Home, In a Public Place, etc.)
Privacy (Degree of privacy the user has: Surrounded by Others, Alone and Can Talk Openly, etc.)
Sphere (User’s personal status: In his Work Capacity; In his Personal Capacity)
Communication Means (Type of communication client preferred: Phone, Email, SMS, etc.)
Other (name-value pair for arbitrary information)

Non-attribute notification parameters can include:

Maximum frequency of notifications
Duration of time during which notifications should occur
Count - the maximum number of notifications
Whether status should be checked immediately after notification setup

End notifications. In this case the subscription to the presentity is retained, but the specific notification is ended
Receive information that:

The initial conditions of the notification setup have been met (count or duration) and this specific setup has been ended
The subscription itself has ended

Supported Network Protocols

Off the shelf, the Presence communication service is configured to support the following network protocol:

Configuration Specifics for the Presence Communication Service

Communication services share many common features, covered in the “Introducing Communication Services” chapter of Concepts and Architectural Overview, but each one has a few characteristics that are specific only to that service. This section describes those specific features for the Presence communication service, including:

Charging Data Records

Generation of CDRs

There are two Presence/SIP specific CDRs. They are generated when the following criteria are met:

After the result of a poll for presence is successfully returned to the application
After a notification for presence information is successfully sent to the application

CDR Details

A Presence CDR contains the standard information with this additional information in the additional_info field for a notification call:

Table 11-1 Additional Info in Presence CDR
Column	Description
additional_info	Endpoint (string)

Event Data Records

The following is a list of EdrIds created by the Presence/SIP communication service. This list does not include EDRs created when exceptions are thrown. For more information, see Events, Alarms, and Charging..

Table 11-2 Event types emitted in the Presence/SIP communication service
EdrId	Method Called
2000	notifyReceived
2001	makeNotifySubscriptionCallback (includes Endpoint, string)
2002	makeSubscriptionEndedCallback (includes Endpoint, string)
2003	makeStatusChangedCallback (includes Endpoint, string)
2004	makeStatusEndCallback (includes Endpoint, string)
2005	subscribePresence (processes from application)
2006	getUserPresence
2007	startPresenceNotification
2008	endPresenceNotification
2009	subscribePresence (forwards to WLSS)

Statistics

The table below outlines the correlation between the methods being invoked from either the application (in application-initiated requests) or the telecom network (in network-initiated requests) and the transaction type collected by the statistics counters in Network Gatekeeper for the Parlay X 2.1 Presence/SIP communication service:

Table 11-3 Transaction types for Parlay X 2.1 Presence/SIP communication service
Method	Transaction type
getUserPresence	TRANSACTION_TYPE_PRESENCE_SERVICE_INITIATED
makeStatusChangedCallback	TRANSACTION_TYPE_PRESENCE_NETWORK_INITIATED

Supported Address Schemes

The Parlay X 2.1 Presence/SIP communication service supports the tel: address scheme.

Communication Service Reference