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: [email protected] [mailto:users- > [email protected]] 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 [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
