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.
Let’s start with publication of a soft state via SIP PUBLISH. It is the Presence Server (PS) which is storing the soft-state information and it is applying an originating service for the presentity. The AS association is created either during the Third Party Registration or technically it can be done even during the initial publication.
SIP PUBLISH
Well, this was too easy. That’s because we don’t have any watcher yet. So let’s add a watcher. For the watcher the PS applies a terminating service.
Subscription to PS
In order to make the things simpler Alan will be always presentity in our examples and Bonie will be the watcher.
So Bonie subscribed to Alan. But usually Bonie doesn’t subscribe to Alan directly but via RLS as Alan is in her buddy-list. RLS is than applying an originating service for Alice. It also does communicate with her XDMS where Bonie stores her list and list rules. RLS will retrieve the list from XDMS and it will do back-end subscriptions to all the entries of the list. These back-end subscriptions are sent to PSs which apply terminating service and communicate with their XDMS. In our case with the XDMS of Alan, as he stores his hard state data and pres-rules there.
List Subscription
Now let’s show the same flow, in case that Alan is subscribed to his winfo package. The service is handled by his PS as an originating service. That means we can send SIP SUBSCRIBE to RLS and PS and PS can apply either originating or terminating service. The main headers in the SIP message are Supported and Event. Based on these we can base our rules in IFCs.
winfo subscription
Ok, we know how to publish or subscribe. Both PUBLISH or SUBSCRIBE has it’s own Expires time. In case that it is set to 0 (zero) it means un-PUBLISH or un-SUBSCRIBE. The NOTIFY informing watcher about termination will contain
Subscription-State: terminated
Plus the Subscription-State will indicate the reason (e.g. deactivated, rejected, timeout, etc.). For more information refer to RFC 3515 and RFC 6665.
In case that Bonie will remove Alan from her buddy-list, RLS has to un-SUBSCRIBE from his presence.
Remove someone from buddy-list
Similary Bonie receive the NOTIFY – terminated if Alan decides that Bonie is not allowed to watch his status.
Change of pres-rules
Last but not least, remember that if Alan un-PUBLISHes his state, Bonie (if allowed) still remains his watcher. That means the service is persistent even when one gets unregistered.
Real Time Communication 