[OpenSIPS-Users] SIP Presence Aggregation Issue

Thu Apr 1 15:10:58 CEST 2010

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.

In reply to Saul
>  - 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.

I think it would be quite impossible to determine the correct user behavior on the server side. Example:
- My SIP IM client (softphone) should have a high priority. I will send messages from it, it is active in that way. I won't call from it.
- My SIP hardphone has a lower priority. It supports PUBLISH and is active sending INVITE regularly.
- Only in case of calls, the BUSY triggered by my SIP hard phone's PUBLISH should set me to busy. This should override the softphone's presence state.
- Now, I am in a long conference. How to override it back (I set the service not to send messages when busy), i.e., set the IM client as available and override the phone state that is higher.
This is a problem.

Maybe this scenario is too particular, but I personally see the efforts of touching SIMPLE presence and implementing some complex state model too high for only some "work-around".

Either a customer does not care, or is an "early adopter" who wants to use it as he likes (comparing to XMPP what we all know about).
A server side implementation, if OpenSIPS logic will be changed, should then allow sth. per customer with different options (not per module parameter what should be used to determine). This will be quite complex... Some web front-end could help to set all this (somehow extend the presence from each client with rich attributes that are lacking and acc. these rules create the overall state.). I personally don't see another way or any hard-configured settings that satisfy more customers than they would disturb...

Sebastian

> -----Original Message-----
> From: users-bounces at lists.opensips.org [mailto:users-
> bounces at lists.opensips.org] On Behalf Of Bogdan-Andrei Iancu
> Sent: Thursday, 01. April 2010 14:13
> To: OpenSIPS users mailling list
> Subject: Re: [OpenSIPS-Users] SIP Presence Aggregation Issue
> 
> Hi Sebastian,
> 
> Ideally, that is correct - I agree that this is something to be done by
> the UAC.
> 
> But the problem I see is that the UACs are not able to handle multiple
> presence information (per contact) and because of this, the watcher may
> get some really confusing view over the other party.
> 
> Like if A has 2 presence-enabled devices, one publishing Busy, another
> one jsut Online, each re-publishing after 10 minutes, a watcher will
> alternatively receive NOTIFYs with BUSY and ONLINE - so you it will see
> a continue toggling between BUSY and ONLINE at each 5 minutes.....
> 
> And mainly the question is - until the UAC will do a proper job, does it
> make sense to address this issue on server side, to, at least, normalize
> the viewing and get some consistent info  ?
> 
> Regards,
> Bogdan
> 
> Schumann Sebastian wrote:
> > Hi
> >
> > I think the topic touches client-side implementations more. On the server-side, it
> is the best to distribute all information and leave it up to the client to interpret it.
> This is also how XMPP does it.
> >
> >
> >> -----Original Message-----
> >> From: users-bounces at lists.opensips.org [mailto:users-
> >> bounces at lists.opensips.org] On Behalf Of Saúl Ibarra Corretgé
> >> Sent: Thursday, 01. April 2010 13:30
> >> To: OpenSIPS users mailling list
> >> Subject: Re: [OpenSIPS-Users] SIP Presence Aggregation Issue
> >>
> >> 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.
> >>
> >
> > Talking about XMPP resources, the "overall" state shown by the program is also
> determined by it itself.
> >
> > The difference to SIP is that the client has the states and priorities from all
> resources available. Usually, the highest resource is responsible for the overall
> state shown by the client (e.g., one resource priority 10 online, another one
> resource priority 20 away: User state indicated by client is away (orange buddy
> icon)).  It is however usually still possible to get the states from all resources that
> are not invisible.
> >
> > The difference is that the full JID distributes the state of one presence source.
> Multiple clients, multiple full JIDs, multiple presence states with different priorities.
> The actual implementation shows the overall state of the bare JID usually in the
> buddy list.
> >
> > SIP has only the URI (w/o indicating or differing between the endpoints) in the
> PIDF <presence> element.
> >
> > However, you can put more information inside the element: <contact>s and
> priorities could be used to determine the "highest" prioritized SIP endpoint for
> communication. RPID and DM could further separate several SIP endpoints. Two
> things are required: SIP clients need to publish all this information and they need
> to interpret it and generate the overall acc. to it in the buddy list.
> >
> > The problem is that for e.g., the case in RFC 3863 (4.3.1) fixed states set (e.g.,
> permanent mail set with XCAP pidf-manipulation) could have a higher priority than
> automatic states. The example shows mail over IM contact (as IM device is busy).
> The correct derivation is that the user wants to be contacted by mail preferably and
> so far correct. However, I would consider it not wanted by the user to show him
> available in the buddy list (because usually a double click would start IM then and
> not mail). But this would be wrong acc. priorities...
> >
> > Summarizing, I think if the clients provide correctly published information, it is up
> to the presence server to distribute it and the client to interpret it. This is my
> understanding in XMPP and should be similar in SIP.
> >
> > Sebastian
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
> 
> 
> --
> Bogdan-Andrei Iancu
> www.voice-system.ro
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users