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.

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.

What Are You Capable Of?

You have seen a couple of IMS flows. You know the registration, the 3rd party registration. Flows of SIP INVITE, SDP, SIP MESSAGE, RTP and RTCP, MSRP … do you think you know enough? For the core functionality this is nearly all we need. But for a real service there are many other things we have to learn. Yes in theory there is the Signaling and Media Plane. But there is also a parallel world of Presence and Capabilities. (And some other parallel worlds of billing, provisioning, monitoring, etc.)

The cornerstone mechanism for all the VoLTE/ViLTE, Instant Messaging and particularly for the RCS is a capability discovery. Users want to see their contacts with the RCS services that are available to communicate. This can be implemented either using the SIP OPTIONS or using a Presence-based solution defined in RCS Release 1 -4. Both will result in one of three types of response:

1. The contact is registered for service resulting in the contacts current service capabilities
   being received and logged, or,
2. the contact is not registered (they are provisioned but not registered),
3. the contact is not found (they are not provisioned for service).

This discovery mechanism is important since it ensures that users can determine what services are available before the communication starts. The same mechanisms can be used to initially discover (and/or periodically check) the service capabilities of all the contacts within an address book when we first register for the service. For the Service Providers it is also very useful because they can add new types of communication channels without compatibility issues.

Capabilities of a device are shared during SIP Registration, over SIP OPTIONS and using the presence system.

SIP OPTIONS for VoLTE

In practice in VoLTE networks we can find the SIP OPTIONS messages to be used as application-layer pings or heart-beats. Via them we can monitor an availability of IMS network servers (instead of SNMP traps for example). E.g. S-CSCF monitors Applications Servers using SIP OPTIONS. If TAS is able to respond with 200 OK, it means it is up and running and not overloaded.

Moreover in VoLTE/ViLTE the SIP OTIONS can be also used for capabilities sharing. The IR.94 says that a 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 addition for ViLTE, a contact header in a 200 OK response message to a SIP OPTIONS request must include a “video” media feature tag.

SIP OPTIONS for Presence and Capability Discovery

In this post we’ll address mainly the SIP OPTIONS presence/capabilities discovery and basic presence system.  The SIP OPTIONS method is send as end-to-end message. It is used both to query the capabilities (services which the other user has available) of the target contact and to pass the information about which capabilities are supported by the requester. Using this method, both users get updated information in a single transaction.

SIP OPTIONS

Is the Presence Social?

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