[OpenSIPS-Users] SIP Presence Aggregation Issue

[Saúl Ibarra Corretgé]

Hi Anca,

On 1/4/10 10:02 AM, Anca Vamanu wrote:
> Hi all,
>
> This mail is a request for your comments about presence aggregation.
> What is your opinion about this? Do you consider it to be a real problem
> and which could be the solutions?
>
> Although it is possible to have more clients registering for the same
> account and publishing presence information, there are not so many
> clients ( none that I know of in fact ) that are able to show more than
> one presence state per buddy. So, even if the presence server does
> aggregate all the presence information for a contact and sends it to its
> watchers, they will see only one presence state, most likely the one in
> the top most record.

I think this happens because of how SIMPLE was initially designed. The 
presence status is undefined if different UAs provide different 
information. XMPP uses the concept of a resource, and each one has a 
different state. XMPP clients do aggregate the presence status by 
setting it to the most 'restrictive' one (if you are online + away your 
global state is away). But still, you're able to see each resources 
presence.

> Therefore, if a contact is registered on three sip clients and two have
> the status 'open' and third has 'closed', if it happens that the
> published information from the third phone is first in the aggregated
> body, its watchers will think that the contact is not online. More than
> this, the logic in OpenSIPS presence server at this moment, orders the
> records after the criteria 'newest info first'. This means in fact that
> if you have a buddy with more phones registered and different states set
> on them, you will see a continuous switch of states, depending on which
> phone updated the publication last ( not only at status changes, but
> also for expires refresh).
>
> In consequence, since the clients are not able to interpret the
> aggregated information correctly, we raise the question whether it is
> useful to have more intelligence in the presence server. Instead of
> merely concatenating the published info and ordering it after the
> criteria 'newest-first', maybe we should analyze those contents and
> decide which is the most important and should be placed first. What
> precedence rules should we consider in this case? If one contact is
> 'open' probably the first tuple should be open, but how should we deal
> with substatuses? Should we concatenate them all? Or maybe we should
> permit users to define priorities for the contacts of their phones in an
> web interface for example, and use those priorities to order the
> presence information. Are there other solutions?
>
> We are interested to know your opinion about this subject.
>

Having the above said, this looks like something hard to solve but there 
are two things that can be done IMHO:
   - Nothing: UAs go figure :-(
   - Try to 'fix' this in the server side: find a way to detect which is 
the 'active' contact, that is, which is the one that is doing something 
and only take that contact's presence information as valid. The way of 
selecting which is the active contact has to be something deterministic, 
an action only a user would do by himself, like sending an INVITE, 
MESSAGE or subscribing to a new buddy for example.

That's my two cents.


Regards,

-- 
Saúl Ibarra Corretgé
AG Projects