[OpenSIPS-Users] SIP Presence Aggregation Issue

[Adrian Georgescu]

This problem is hard to solve in a deterministic way, practically  
there is conflicting information and in general conflicts require a  
manual decision to solve. Asking users to set priorities in their UA  
is not something you can rely upon, people simply forget or machines  
go to sleep or wake up automatically.

I would  have one suggestion that can be built in the server. Having a  
'hard fact' for determining in the server, which UA instance is really  
the one with the last up to date information may help to sort or  
filter the Notify payloads. For clients supporting rich presence  
extension, the server can asses which UA instance is the one active  
based on the most recent "last-input" timestamp. So when you start  
typing or using one UA interface, that is the one that becomes active  
and the server can keep track of it until the Publication is removed  
or another instance takes over.

Adrian

On Apr 1, 2010, at 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.
> 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.
>
> Regards,
>
> -- 
> Anca Vamanu
> www.voice-system.ro
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>