# Communication Service Reference

# Parlay X 2.1 Presence Communication Service

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

- An Overview of the Parlay X 2.1 Presence Communication Service

- The Client as Presence Consumer
- The Client as Presence Supplier
- Supported Network Protocols

- Configuration Specifics for the Parlay X 2.1 Presence Communication Service

- Charging Data Records
- Event Data Records
- Statistics
- Supported Address Schemes

## An Overview of the Parlay X 2.1 Presence Communication Service

The SOAP Service Facade Presence communication service implements the both the watcher aspect and the presentity 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.

Note: | The RESTful Service Facade Presence interfaces provide RESTful access to this same functionality. The internal representations are identical, and for the purposes of creating SLAs and reading CDRs, etc., they are the same.

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.

### The Client as Presence Consumer

An application acting as a watcher can:

- 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 when 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

### The Client as Presence Supplier

An application acting as a presentity can:

- Publish present information
- Get a list of new watchers who have asked to subscribe to the client’s presence information
- Approve new watchers and update the subscriptions of current watchers
- Get a list of currently subscribed watchers
- Block the subscription of a currently subscribed watcher

Note: | The Presentity functionality requires a presence server in the underlying network. To approve new watchers and update the subscriptions of current watchers, there must also be a data manipulation server (DMS) in the underlying network. The block functionality is supported in two modes, one using a DMS and one not.

### Supported Network Protocols

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

- SIP

## Configuration Specifics for the Parlay X 2.1 Presence Communication Service

Communication services share many common features, covered in “Introducing Communication Services” in 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
- Event Data Records
- Statistics
- Supported Address Schemes

### 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 12-1 Additional Info in Presence CDR
Column | Description
--- | ---
additional_info | Endpoint (string)

### Event Data Records

Table 12-2 lists EDR IDs 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 12-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 | publish
2010 | blockSubscription
2011 | getMyWatchers
2012 | getOpenSubscriptions
2013 | updateSubscriptionAuthorization
2015 | onRequest (Watcher Info Notifiy)

### Statistics

Table 12-3 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 Oracle Communications Services Gatekeeper for the Parlay X 2.1 Presence/SIP communication service:

Note: | Method names for network-initiated requests are specified by the internal Oracle Communications Services Gatekeeper name, which is not necessarily the same as the message from the network.

Table 12-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`SIP URI` address scheme.