Presence sharing is a very important functionality when it comes to Rich Communication. We know it from many communicators such as Skype, Google Hangout, Facebook, Jabber, etc. But maybe you noticed that each of these applications has a different set of statuses, allows to share a different type of hard-state data (e.g. avatar, idea of the the day, web link ..). Mobile operators require some more unified approach as a particular status should be interpreted in the same way in all the networks (‘busy’ should have the same meaning in T-Mobile, Vodafone, or any other network).
That’s why Open Mobile Alliance (OMA) standardized Presence sharing for RCS using SIMPLE – Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions (see http://technical.openmobilealliance.org/Technical/technical-information/release-program/historic-releases/presence-simple-v2-0). But that can be quite confusing, as the presence system is not simple at all. It is very complex and sometimes a bit difficult to grasp.
Let’s start from the beginning – what is the presence?
What is Presence?
By presence information in RCS we understand sharing of:
- Availability
- Device Capabilities
- User’s (un)willingness to communicate,
- Portrait icon, depicting the user (e.g. a photo or image provided by the contact himself),
- Free text, including textual note and possibility to add emoticons (automatic translation
of some specific characters into smileys), - Favourite link, to publish hypertext link of personal and/or favourite site,
- Timestamp, date of the last update of the profile, generated automatically,
- Geolocation, depicts the user location.
Actually presence is not limited to RCS only, also in VoLTE/ViLTE we need to share device capabilities.
In Presence we have two basic roles:
- Watcher – Presence Source, the one who wants to discover the presence information.
- Presentity – The one who is publishing his/her presence data.
When a Watcher opens her addressbook, she wants to see what is the social status of her buddies, what are there pictures and what communication channels they support (e.g. can I do an Instant Messaging with them?).
SIP OPTIONS
The easiest why how to obtain presence information is to use SIP OPTIONS method.
SIP OPTIONS
OPTIONS exchange is a simple end2nd SIP request response. In the request the originator shares her own capabilities. From the 200 OK response then learns the availability and capabilities of her buddy.
In VoLTE the Contact header field in a 200 OK response message to a SIP OPTIONS request must include the IMS Communication Service Identifier (ICSI) value of “urn:urn-7:3gppservice.ims.icsi.mmtel”, as defined in 3GPP TS 24.173. In ViLTE in addition, a contact header in a 200 OK response message to a SIP OPTIONS request must include a “video” media feature tag. More details in GSMA IR.94, IR.65.
In RCS the SIP OPTIONS exchange is used as the default method or as a fallback mechanism (see GSMA IR.90).
The disadvantage is the number and frequency of signalling messages.
SIP OPTIONS – full mesh
Of course, watcher can be a presentity at the same time.
SIP OPTIONS can be seen in an IMS network very often as a ping message sent between network entities for monitoring purposes.
More about SIP OPTIONS in a dedicated post What are you capable of?
Presence Server
In order to reduce the number of unnecessary signaling and still get close-to-realtime presence data a Presence Server (PS) has been introduced.
Presence Server – PUBLISH/SUBSCRIBE/NOTIFY
Presence server receives the presence information from the presentity. Watcher can subscribe to someone’s presence information. The presence server then updates the watcher with all the status changes.
A great thing is that the presentity doesn’t need to update each watcher individually. It is the responsibility of the Presence Server to broadcast the information.
Presence Notification
On the other hand a watcher still have to subscribe to all the her buddies one-by-one.
Resource List Server
To solve this issue we employ a Resource List Server (RLS). Instead of sending subscriptions to presence for all the entries in addressbook, watcher can subscribe to a list of all her contacts. The RLS will then do the individual (back-end) subscriptions.
RLS – Backend Subscription
Note that the Presence Server is always located in the home network of a presentity. That means that RLS probably has to talk to many Presence Servers. RLS collects all the responses and sends one big notify to the watcher.
RLS – PS
This approach allows interesting optimizations like notification rate/size control, Limit number of real time buddies (VIP contacts), Server based Notification Throttling, etc.
XDMS
The third component of the presence system is XML Data Management Server (XDMS). Thanks to XDMS users can manage their lists and manage them using Ut Interface (XCAP/http).
XDMS – RLS
Over the Ut interface presentities can also set their presence rules (who is allowed to watch their status) and hard state data (e.g. avatar picture).
PS – XDMS
The flow already starts to be a bit complex. We should add, that PS and RLS can communicate with XDMS over both SIP and XCAP protocol. When it comes to hard state data, the NOTIFY sent to a watcher contains just a link to XDMS. The data (picture) is retrieved over Ut.
Icon Update
For more information about presence system you can read posts
- Is the Presence Social?
- Presence – More Than You Wanted to Know
- Presence – from the other site
- Someone’s Watching
And if you are serious about using it, check also GSMA Presence Best Practice Optimization Guidelines.
Real Time Communication 
Good article over present to get overview of presence evaluation
LikeLike