[OpenSIPS-Users] SIP Presence Aggregation Issue

[Schumann Sebastian]

Hi Adrian

> -----Original Message-----
> From: users-bounces at lists.opensips.org [mailto:users-
> bounces at lists.opensips.org] On Behalf Of Adrian Georgescu
> Sent: Thursday, 01. April 2010 16:31
> To: OpenSIPS users mailling list
> Subject: Re: [OpenSIPS-Users] SIP Presence Aggregation Issue
> 
> 
> On Apr 1, 2010, at 3:10 PM, Schumann Sebastian wrote:
> 
> > Hi Bogdan
> >
> > Yes, in an "ideal world", this re-publishing with BUSY and ONLINE is
> > wanted, but the toggling not. Priorities would help (you'd receive
> > that but not trigger anything on the user interface as the highest
> > priority will keep its state), but we don't have them yet, so in
> > that case the decision must be made somewhere else or not at all.
> >
> 
> All we need is a good client to figure out how to use these concepts,
> right?

I think yes, at least for this particular question.

Clients that make use of rich presence when publishing and clients that interpret it when creating the user state.

The question is IMHO only how to interpret it and how to display the information to reflect the presentity state properly.

An XMPP client has the same options IMHO (not to start a flame: I mean for this question, not in regard of presence implementations and standards in general): It could for example also display a user as busy because one resource is busy (maybe used by the user, hence he is busy). It could also use always the state if the highest prioritized resource. This depends more or less on how the information it receives from the service is processed and displayed. 

It does not necessarily matter if each half minutes comes a new state (BUSY and ONLINE by turns). As long as a) either one resource BUSY marks the whole presentity busy or b) the resources have priorities one consistent state would be shown. 

Only for the "last published" model it would alternate, but interpreting the last state as the current user state does not seem right for me. The last state _actively changed_ by the user yes, but not the last one due to refreshing a PUBLISH expiration.

Sebastian