[OpenSIPS-Users] SIP Presence Aggregation Issue

[Iñaki Baz Castillo]

2010/4/1 Adrian Georgescu <ag at ag-projects.com>:

> 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.

But all the UA's sharing AoR would re-PUBLISH its presence so we get
with a race condition. There is no way to determine where the "human"
is exactly.



> 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.

Humm, this is not possible within SIP. When I use a phone to call
there is no way for the server to determine which presentity is
associated to me. Presence publisher is an independent entity within
my phone. The PUBLISH has no Contact header and there is no info in
the SIP PUBLISH (neither into its buddy) to match such origin with the
caller UA.

This would be solved with the "resource" concept as it exists in XMPP.
But there is NO way AT ALL to inroduce it within the current and
abominable SIMPLE specifications.

> 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
>>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>



-- 
Iñaki Baz Castillo
<ibc at aliax.net>