9 Parlay X 2.1 Presence/SIP

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, and so on.)

    • Place (User's current location: Home, In a Public Place, and so on.)

    • Privacy (Degree of privacy the user has: Surrounded by Others, Alone and Can Talk Openly, and so on.)

    • Sphere (User's personal status: In his Work Capacity; In his Personal Capacity)

    • Communication means (Type of communication client preferred: Phone, Email, SMS, and so on.)

    • 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

    • 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.

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.

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.

Event Data Records

Table 9-1 lists IDs of the EDRs created by the Presence/SIP communication service. This list does not include EDRs created when exceptions are thrown.

Charging Data Records

Presence/SIP-specific CDRs are generated under the following conditions:

• 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.

A Presence CDR contains an additional_info field for a notification call. This field contains the endpoint.

Statistics

Table 9-2 maps methods invoked from either the application or the network to the transaction types collected by the Services Gatekeeper statistics counters.

Alarms

For the list of alarms, see Services Gatekeeper Alarms Handling Guide.

expireskey

Description

This value is used to cancel a subscription to a user presence. The parameter is configured in the SIP plug-in.

If set, this value replaces the default SubscribeExpiryValue configured in the PresenceMBean.

Can be set using parameter tunneling.

Format

String

Example

<xparams> <param key="expireskey" value="1210"/> </xparams>

passidkey

Description

This value is used among trusted intermediaries to assert the identity of a user sending a SIP message as it was identified by authentication.

Can be set using parameter tunneling.

Format

String

Example

<xparams> <param key="passidkey" value="sip:leffe@keffo.com"/> </xparams>

URI Cache

In Parlay X 2.1 Presence, the SIP URI of the user (the presentity in Presence Supplier cases, the watcher in Presence Consumer cases) is not passed as an argument. Instead, Services Gatekeeper maps the user URI to the application instance ID of the user application. The URI mapping is configured as a part of the service provider and application provisioning workflow and is then stored in the URI cache.

For requests that originate from an application, the URI is fetched from this cache before being put into the from header in the SIP requests. For application-terminating requests, the to header URI passed in the SIP NOTIFY requests is used to look up the account user name and application instance ID.

In the case of the Presence Supplier interface, the application can override the default mapping by including a tunneled parameter in the header of its request.

Subscriptions Cache

Every subscription, pending or not, is stored in the subscriptions cache during the subscription's lifetime. It is added when an application invokes the subscribePresence method on the application-facing interface. It is removed when the subscription is terminated.

Notifications Cache

All registered notifications are cached. The entries are created when an application calls the startPresenceNotification on the application-facing interface. They are removed when endPresenceNotification is called, the end criteria are reached, or the subscription is ended.

Properties for Parlay X 2.1 Presence/SIP

Table 9-3 lists the technical specifications for the communication service.

Configuration Workflow for Parlay X 2.1 Presence/SIP

Following is an outline for configuring the plug-in using the PresenceMBean in the Administration Console or an MBean browser.

1. Select the MBean described in "Properties for Parlay X 2.1 Presence/SIP".

2. Configure these fields of the network protocol plug-in instance:

   • DefaultNotificationCount

   • DefaultNotificationDuration

   • NotificationCleanupTimerValue

   • NotificationCleanupTimerValue

3. Configure connection information to the SIP server using the SubscriptionCleanupTimerValue attribute.

4. Set up the routing rules to the plug-in instance. See the discussion about configuring and managing the plug-in manager in Services Gatekeeper System Administrator's Guide. Use the plug-in instance ID and address schemes listed in the "Properties for Parlay X 2.1 Presence/SIP" section.

5. If required, create and load a node SLA. For details see the discussion about "Defining Gobal Node and Service Provider Group Node SLAs and Managing SLAs in the Services Gatekeeper Accounts and SLAs Guide.

6. Provision the service provider accounts and application accounts. For information, see Services Gatekeeper Portal Developer's Guide.

Provisioning Workflow for Parlay X 2.1 Presence/SIP

For every application, use the setApplicationInstanceSIPURI method of PresenceMBean to define a mapping between a SIP URI and application instance ID.

Use the getApplicationInstanceSIPURI method to display the mapping.

If an application is deleted, use the removeApplicationInstanceFromCache method to remove the data for the application.

Management Methods for Parlay X 2.1 Presence/SIP

You use these methods to the PresenceMBean to manage Parlay X 2.1 Presence/SIP:

• clearCache

• listNotificationsCache

• istSubscriptionsCache

• listURImappingCache

• updateSubscriptionToBeconfirmed

For a description of the attributes and operations of PresenceMBean, see the "All Classes" section of Services Gatekeeper OAM Java API Reference.