Sometimes people wonder why it takes so much time and effort to make the RCS working when LINE, Whatsapp, Viber, Skype, Lync and others just work and they are (nearly) for free. One of the reasons is the enormous amount of standards and specifications for SIP/IMS/RCS. Just take a look on RFC 4480 where we can find ridiculous definitions like:
Activities such as <appointment>, <breakfast>, <dinner>, <holiday>, <lunch>, <meal>, <meeting>, <performance>, <travel>, or <vacation> can often be derived from calendar information.
dinner: The person is having his or her main meal of the day, eaten in the evening or at midday.
holiday: This is a scheduled national or local holiday.
in-transit: The person is riding in a vehicle, such as a car, but not steering. The <place-type> element provides more specific information about the type of conveyance the person is using.
looking-for-work: The presentity is looking for (paid) work.
lunch: The person is eating his or her midday meal.
“RCS standardized itself to death” – I’m not sure who said it first but there is definitely something about it 🙂
We have already seen a bit of presence in the post Is the Presence Social? This time we’ll extend our framework with other nodes from OMA specification.
There are also some other network elements and interfaces but for now it is more than enough. Just think about it – we need all these servers and databases for a simple information whether is our friend present or not and maybe some tag line or avatar. No wonder that many OTTs use either very simple or proprietary presence solution. Even the RCS doesn’t rely on the full presence implementation and only SIP OPTIONS support is mandatory.
In the previous post we saw the basic presence flow. But we didn’t explain it much. When we start our client the first thing it does (after the registration) is obtaining of presence of contacts in its buddy-list. Because our architecture is not final yet (yes, some pieces are still missing) we will assume that the buddy-list is already in the client. Client will send a SUBSCRIBE request and in the response it will receive presence and capabilities of the contacts. Internally this operation will fall apart into two phases. Firstly the Presence System – Resource List Server (RLS) needs to translate the contact list into particular contacts and check the rules (who we are allowed to watch and who we want to watch). In the second phase the RLS queries the presence of contacts one by one. Preferences of contacts which restrict who can watch them are applied. Mind that some contacts can be registered in foreign networks (the Presence Server is also in the foreign network).
In our first example Jorgen will publish his new state + avatar image. The Event State Publication is described in the RFC 3903 and the flow could look like this
After Jorgen publishes his state (over the Ut Interface) the XDMS will create a new document and will notify all subscribed watchers. The Presence contains three basic operations: conditions, actions and transformations. Conditions define watchers to whom the authorization rules apply. They can be applied for URIs as well as for domains. Actions define how to handle subscriptions as ‘allow’, ‘block’, ‘polite-block’, ‘confirm’. The Transformations define what presence information is provided. More information about Subscription and Publication Authorization Rules can be found in RFC 4745 and RFC 5025.
As described above to become a watcher client sends SIP SUBSCRIBE to the RLS. The primary role of the RLS/RLS XDMS is not the presence itself. The purpose of RLS is more general – it manages and authorizes all the operations which use lists (e.g. the presence). The RLS XDMS is its repository for XML documents that define services which are associated with a list of resources. For the details refer to RFC 4826, RFC 5367 and RFC 4662.
Once the RLS has all the information about particular contacts it will start to send the SIP SUBSCRIBE to the responsible Presence Servers. Each Presence Server will then send request to its own Presence XDMS.
RLS will gather all the presence information. When it’s complete it will send the SIP NOTIFY back. This SIP NOTIFY will contain the information about all the contacts.
Actually there will be probably more of SUBSCRIBE/NOTIFY/XCAP. When we would inspect a tcpdump we could find the difference between particular SUBSCRIBEs. It is the Event header. There can be something like this:
Presence – Event header
There are many documents which can be stored in XDMS.
The following applications are provided by XCAP, by using a specific auid (Application Unique Id):
- XCAP capabilities (auid = xcap-caps). Capabilities shared via Presence System.
- RLS services (auid = rls-services). A Resource List Server (RLS) services application allows to subscribe to a given resource list.
- Resource lists (auid = resource-lists). A resource lists application is any application that needs access to a list of resources, identified by a URI (e.g. buddy-list, coference-list), to which operations, such as subscriptions, can be applied.
- Presence rules (auid = pres-rules). A Presence Rules application is an application which uses authorization policies, in order to restrict what presence information can be given to which watchers, and when.
- PIDF manipulation (auid = pidf-manipulation). Pidf-manipulation application usage defines how XCAP is used to manipulate the contents of PIDF based presence documents.
- Hard State Data (auid = pres-content). This document contains the Icons, Web links, Tag lines etc.
There are more auids – the full list can be found at http://technical.openmobilealliance.org/Technical/technical-information/omna/omna-xcap-auid-registry
Note that pres-rules can contain other lists of subscribers (who are allowed/blocked to watch). This means we need to send another resource-list request. An example of SIP/XCAP message you can see in the IBM’s implementation of XDMS.
The XCAP/XML response is described in its own post. We will just take a look on the final response where Jorgen can find the list of his buddies and their presence information.
In our flow the client gets only XML. That means a text payload. But presence can also contain multimedia – as avatar image, animation or any other data (important for M2M). The final SIP NOTIFY which is sent to the client can contain links. These links point either to a Content Sever or XDMS (via Aggregation Proxy).
In its own way the presence is also following the Signalling/Media plane pattern. The logic who can/want to watch who is done in PS/RLS. Moreover SIP presence signalling allows ASs to use presence/capabilities information from more sources (presence, SIP OPTIONS, implicit presence, registration, GSM).
Let’s have a final example – how it looks like when Jorgen updates his avatar.
If you’re hooked and want to know more you can try one of the free implementations as it is for example Kamailio (info on asipto):
Or you can use Red Hat’s SIP Presence Service as a case study. You can see their Presence architecture:
And Red Hat’s implementation of XDMS:
It is not enough? Than check Some’s watching or Presence – from the other site.