IMS Presence Illustrated: Beginners Guide

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?

Presence – from the other site

You know it. When you see a new smart phone/navigation/camera or any other gadget for the first time, it seems to be complex. It takes some time and you get used to. And then finally you get bored. It’s the same with the IMS. The VoLTE flows are not challenging for you any more. Maybe the conferencing or SRVCC – a bit. But in general there isn’t anything really complex. That’s why I like presence. There are many various flows and use-cases. (And I don’t deliver these trainings that often as VoLTE :)).

Sure, we’ve went through a couple of presence topics and flows (Is the Presence Social?, Presence – More than you wanted to know, What are you capable of?, Someone is watching). This time we can do it slightly more complex and check how it looks like from multi-site perspective.

Presence – two sites

We’ll go through the most basic flows and we’ll focus on what service is originating and what service is terminating. Each site can belong to a different operator or it can be just one network. For simplicity the DNS will assign the primary AS based on geolocation. Geo-redundancy scenarios will be described some other time.

XCAP Protocol

The more protocols you know, the more of the IMS you are. Right, the IMS is not only about SIP, Diameter or RTP. There are many various protocols involved. This time we’ll take a look at self-provisioning and configuration of services via http, more specifically XML Configuration Access Protocol (XCAP). We have seen it already in the posts about Ut Interface and Aggregation Gateway.

XCAP protocol is a kind of RESTful protocol. If you know a bit about the RESTfull approach, then you should easily become familiar with XCAP.

However the XCAP was created separately and has its own specifics. It was designed as a dedicated protocol for telecommunication environment as a set of conventions for mapping XML documents and document components into HTTP URIs, along with operations allowing to read/write/modify/delete these documents. That means it is not a general purpose XML search protocol. Still the XCAP is meant to support the configuration needs for a multiple applications such as supplementary services, capabilities, resource lists, presence rules and others.

Let’s take as an example the management of VoLTE supplementary services. XCAP allows an user to retrieve the information about the provisioned services and manage the content.

 

XCAP

 

As we want to limit the amount of the exchanged data, XCAP allows to define the scope of the document we are working with. The scope can be the whole document, or an xml element or even only an attribute.

Aggregation Proxy and Bootstraping

There were three telco engineers.

One was confused.

Second one was unsure.

And the third one also worked with IMS.

The self-confidence is a key for a trainer. And honestly that’s what I lack with IMS. There are so many things, specifications, flows which I’m not sure about. I can read several different specs about one network functionality, each claiming something slightly different but all of them very vague about some particular feature I’m interested in. That’s why I like the wireshark. The problem is that even the traces can differ deployment to deployment, vendor to vendor. But at least that is something I can touch.

When I started with the RCS I’ve seen various callflows which contained some ‘AP’ or ‘AG’ box. This network function is an http or ws API (REST/SOAP/XCAP/any other) gateway into the IMS network. I was a bit confused, because always it was called by a different name and the function was not always the same. It took me some time to sort it out (at least partially ;)).

We’ve already seen one of those boxes – the Authentication Proxy. This time we will discuss the Aggregation and Cross-Network Proxies. The Authentication proxy is standardized by GSMA as VoLTE network function. In contrast to that the Aggregation Proxy is an RCS network element defined by OMA in XML Document Management specs.

Otherwise they are very similar and in practice they can be implemented within the same physical system as both of them are used to allow users to manipulate data over http without the need to go through the SBC.

 

Aggregation Proxy

 

And indeed, when we take a closer look, we can see (as stated in the specification) that for a 3GPP IMS or 3GPP2 MMD realisation, the XDM-3 and XDM-5 reference points correspond to the Ut reference point. In other words Aggregation and Authentication proxy are supposed to work in the same way from the UE perspective (e.g. we’ll use GAA or Http Digest for authentication). We can reuse the BSF and NAF functionality we have implemented for Authentication proxy. So if we know the Authentication Proxy we already know most of the stuff.

Someone’s Watching

The quantum physics says that some events will happen differently if someone is watching. And one doesn’t need to be a physics to have that experience. At least my performance is always worst when someone is watching me playing piano.

Authors of IMS Presence System were either aware of it or they knew that there can be a thin line between being a watcher and being a stalker. Either way IMS allows to inform a presentity about watchers and authorize their subscription.

The key specification is the RFC 3857 which defines so called watcher info (winfo) event “template-package”. Event template-packages are event packages that can be applied to any other event package (so not only presence). The winfo provides the users with information about who is watching the subscribed resource. If the winfo is applied to presence (see previous posts Presence – More than you wanted to know and Is the Presence Social?) the value of the Event header field is set to presence.winfo.

Event: presence.winfo

The package defines a new MIME type application/watcherinfo+xml. When a SIP request or response contains a Content-Type header field set to application/watcherinfo+xml, it is indicating that the body is an XML document that contains watcher information.

NOTIFY sip:Richard@operator.com SIP/2.0

Content-Type: application/watcherinfo+xml

<?xml version="1.0"?>
   <watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
                version="0" state="full">
      <watcher-list resource="sip:Richard@operator.com"
                    package="presence">
        <watcher id="23456abcd" event="subscribe"
                 status="pending">sip:Jorgen@operator.com</watcher>
      </watcher-list>
   </watcherinfo>

Presence – More Than You Wanted to Know

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.

OMA Presence

 

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.