Presence Model in RCS

Presence is the mechanism that lets one user or application learn the service availability, device state, or communication capability of another user. In RCS, presence is commonly built from SIP subscription procedures and XML presence documents, so the important part is understanding both the SIP dialog and the presence document carried in the SIP body.

The basic terminology is based on the presence model described in RFC 2778. The same logical entities appear repeatedly in RCS presence procedures, especially when a user subscribes to another user's status or when a presence server distributes updates to watchers.

Presence Model Overview
Main Presence Entities
SIP Presence Flow
- SUBSCRIBE Clip
- NOTIFY Clip
Presence Document
- PIDF XML Clip
Troubleshooting Points

Presence Model Overview

The following diagram summarizes the major presence-model entities and their relationship. The model separates the user or device that owns the presence state from the user or application that watches that state. This separation is useful because the presence server can aggregate and distribute updates without every watcher directly polling the presentity.

Main Presence Entities

Presentity is the logical user, device, or service whose presence state is being published or observed. In RCS, this can represent a user identity whose availability or service capability is exposed to other users.

Watcher is the user or application that requests presence information. The watcher typically sends a SIP SUBSCRIBE request and receives status updates through SIP NOTIFY requests.

Presence Agent receives subscriptions and generates notifications on behalf of the presentity. In an IMS/RCS deployment, this role is commonly implemented by a presence server or related application server.

Presence Document is the XML body that describes the presentity state. The document can include tuple identifiers, contact addresses, basic status, service capability, and timestamps depending on the RCS service profile.

SIP Presence Flow

Presence subscription is controlled by SIP. A watcher subscribes to the presence event package, and the presence agent confirms the subscription and sends NOTIFY requests whenever the subscribed presence state changes or when the subscription state itself changes.

SUBSCRIBE Clip

The following clip shows a watcher subscribing to presence information for a presentity.

SUBSCRIBE sip:user2@example.com SIP/2.0

Via: SIP/2.0/UDP ue1.example.com;branch=z9hG4bK-pres-001

From: <sip:user1@example.com>;tag=watcher01

To: <sip:user2@example.com>

Call-ID: pres-sub-001@example.com

CSeq: 1 SUBSCRIBE

Contact: <sip:user1@ue1.example.com>

Event: presence

Accept: application/pidf+xml

Expires: 3600

In this SUBSCRIBE clip, Request-URI identifies the presentity, From identifies the watcher, To identifies the target presentity, Event selects the presence event package, Accept declares the expected presence document format, and Expires requests the subscription lifetime.

NOTIFY Clip

The following clip shows a presence agent notifying the watcher with a PIDF presence document.

NOTIFY sip:user1@ue1.example.com SIP/2.0

Via: SIP/2.0/UDP presence.example.com;branch=z9hG4bK-pres-002

From: <sip:user2@example.com>;tag=presentity01

To: <sip:user1@example.com>;tag=watcher01

Call-ID: pres-sub-001@example.com

CSeq: 1 NOTIFY

Event: presence

Subscription-State: active;expires=3580

Content-Type: application/pidf+xml

In this NOTIFY clip, Request-URI identifies the watcher contact, Call-ID correlates the notification with the subscription dialog, CSeq identifies the NOTIFY transaction, Event confirms the presence package, Subscription-State reports subscription status and remaining expiry, and Content-Type declares the XML presence body.

Presence Document

The actual presence state is normally described in an XML document such as PIDF. The SIP message delivers the document, but the XML body contains the presentity URI, service tuple, status, contact address, and timestamp that applications use to update the user interface or service state.

PIDF XML Clip

The following clip shows a simplified PIDF body carried inside the NOTIFY request.

<contact>sip:user2@device.example.com</contact>

</tuple>

</presence>

In this PIDF clip, presence entity identifies the presentity, tuple id identifies a specific service or device state entry, basic reports open or closed availability, contact provides the reachable contact URI, and timestamp records when the state was generated.

Troubleshooting Points

When RCS presence does not update correctly, first verify the SIP subscription dialog. The SUBSCRIBE and NOTIFY messages should use the same Call-ID, compatible From and To tags after dialog creation, the Event header should be presence, and the subscription state should remain active until expiry or termination.

After the SIP dialog is confirmed, inspect the XML body. A valid NOTIFY can still be unusable if the Content-Type does not match the body, the presence entity does not match the expected presentity, the tuple status is missing, or the contact and timestamp values are stale or malformed.