This chapter describes the Parlay X 2.1 Presence communication service in detail:
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.
An application acting as a watcher can:
Possible attribute types include:
Non-attribute notification parameters can include:
An application acting as a presentity can:
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. |
Off the shelf, the Presence communication service is configured to support the following network protocol:
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:
There are two Presence/SIP-specific CDRs. They are generated when the following criteria are met:
A Presence CDR contains the standard information with this additional information in the additional_info
field for a notification call:
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-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. |
The Parlay X 2.1 Presence/SIP communication service supports the SIP URI
address scheme.