Being a trainer is a nice job. But one shouldn’t use an instant messenger (Skype, Lync, Google Hangout, Jabber, etc.). I always forget to switch it off or change my presence to ‘off-work’ (sometimes does’t help it either). For example it is 9 pm, I’m tired after two weeks of training at a hotel room and watching some movie on my laptop. Then suddenly a window with my IM jumps out and one of my friends (sitting in a different timezone) is asking for some technical advice. He/She sees I’m online and active so it’s not twice polite to ignore the request. Sure, no need to be a trainer, I guess you know it as well.
Presence indication is one of the key attributes of Instant Messaging or Real Time Communication in general. RCS 5.2 is defining the social presence with following attributes:
- Availability, indicates the 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.
We shouldn’t limit ourselves only to them. Stop for a while to think about Real Time Communication as about something dedicated to human beings only. For the Machine to Machine communication (M2M/M2X/IoT) it is the presence important maybe even more.
For example a distributor of gas has smart monitoring devices which are all connected to a monitoring station. Moreover some of the devices are interconnected among themselves. Their “social” presence can be related to their readiness, actual throughput, power supply, strength of radio signal, reliability and condition. (However it is true that SIP/IMS/RCS were designed primarily for humans and there are also other ways how to solve presence for M2M.)
UEs and Application Servers rely on the presence information very much. It can be important for both signaling and data. Based on the presence we can choose which device to use, which access method is the best, what timeouts are optimal, which codecs are applicable etc.
Anyway before we’ll dive in the RCS concept of the social presence we should recap the standard mechanisms for SIP defined in the RFC 3903, RFC 2778 and RFC 3856 and the Presence Service for IMS defined in 3GPP 24.141.
Basic Presence
The presence information is stored in a dedicated Application Server – Presence Server. Users can use SIP PUBLISH to update their status. They can also subscribe via SIP SUBSCRIBE to events related to other users they are watching. The information they receive is sent via SIP NOTIFY. Basically the stuff is very similar to what we already know form the 3rd party registration just we use SIP PUBLISH instead of the SIP REGISTER. In the message we also use a different Event header:
Event = presence
The content is defined as Presence Information Data Format (PIDF) or Rich Presence Information Data Format (RPID).
The most basic flow can be:
Basic Presence Flow
It is simple and works also for application servers. Just don’t forget that one user can have multiple devices and each can publish different data. Because of that the Event State is associated with an Event Package and Address of Record (AoR).
In our example a gas pump doesn’t need to know what all the entities are interested and authorized to see its status. When there is an outage in power supply it will publish its status (running on backup) to the presence server. Presence server then notifies all watchers.
Mind that not all the devices support the PUBLISH method. Simply for voice (VoLTE devices, SIP phones) you don’t need to know the presence or capabilities of your counter part in advance. If necessary, clients may probe for the support of PUBLISH using the SIP OPTIONS request. The SIP OPTIONS can be also used as a light variant of a presence (200 OK will indicate user is active). This is used also in RCS 5.2.
Generally we don’t want to deal with each of our contacts separately. Instead we want to work with lists. That’s why the IMS architecture is a bit more complex. There is a dedicated entity called Resource List Server (RLS) and XML Document Management Servers (XDMS).
PRS
The supported functionalities are:
- Resource List Server – accepts and manages subscriptions to presence lists, which enables a watcher application to subscribe to the presence information of multiple presentities using a single subscription transaction. See RFC 4662 and RFC 4826.
- Presence Server – manages presence information uploaded by presence sources and handles presence subscription requests.
- XDMS – application servers that store presence service related data. Four different ASes are defined:
- Presence XDMS – contains rules for presence information subscriptions and rules for presence information publication
- RLS XDMS – contains user’s presence buddylist
- Presence Content XDMS – manages media files for the Presence Service
- Shared XDMS – stores URI Lists which may be referenced from other documents
If a user wants to subscribe to list of contacts (e.g. start of an application), he/she will send just one SIP SUBSCRIBE to RLS. RLS will firstly respond with SIP NOTIFY which has an empty body. Then the RLS checks presence of all the members of the list one by one. Once the information is complete it is forwarded back to the originator as an XML content of SIP NOTIFY.
PRS Flow
In order to indicate lists the SUBSCRIBE has to include the Supported header set to
Supported = eventlist
similarly the NOTIFY has to put the
Require = eventlist
in its header.
Let’s have a break here. There are still too many things missing (Where is the multimedia? Where is the addressbook? Policies?) but we need to digest PUBLISH/SUBSCRIBE/NOTIFY first. More details in Presence – more then you wanted to know.
Real Time Communication 