[OpenSIPS-Users] SIP Presence Aggregation Issue

[Bogdan-Andrei Iancu]

Hi Iñaki,

well, right now there is a kind of pressure coming from the providers 
level - providers do want to offer presence with SIP ; also presence 
comes in a natural way of doing dome enhanced  services (more complex 
than simple BLA, BLF, etc).  -- please note I said presence, not SIMPLE.

So, a natural demand for it there, and we, as developers, are looking 
for solutions to make it happened. and for implementations you need some 
specs.

Now, if you see the SIMPLE specs are wrong - it might be - I'm not 
directly involved in the depth of SIMPLE to be able to say yes or no.  
This "aggregation" problem is the first we encountered during  some 
projects - not only once, but several times, different contexts  ; and 
I'm trying with Anca to see how to get over it.

So, overall, there are 2 options (according to your perception):
    - use SIMPLE and get a poor result (a crippled  presence)
    - come up with a new spec
    - do feedback to IETF to make SIMPLE simpler and working

For SIMPLE, looking at the basics (exchanging the info), the aggregation 
is the biggest issue I see. Whatever is on top (RLS, XCAP, buddy lists, 
etc) is another story and it might need a second look and thought.

One thing that I clearly see and I try to take advantage of is that the 
presence server has full control over the presence information - so you, 
as server, can play and manage the presence info as you want - including 
solving some of the problems, in a transparent way for the client.

But important is to find the right path to go further - because as I 
said in the beginning, there is a big pressure into using presence for SIP.

Regards,
Bogdan


Iñaki Baz Castillo wrote:
> 2010/4/1 Adrian Georgescu <ag at ag-projects.com>:
>   
>> 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?
>>     
>
> And as those concepts are not standarized we would end with a
> custom/propietary implementation, perhaps 100% based on the *vague*
> RFC's about SIMPLE, but just interoperable with itself.
>
> I have another idea: just drop SIMPLE/XCAP, the worst "protocols" in
> the world. After spending more than 6 months fully immersed in
> SIMPLE/XCAP specifications I strongly recommend to everybody not to
> waste your time with this abominable experience.
>
> Even if you get all the specifications to work, you would end with a
> limited presence system:
>
> - An inneficiente presence server because it must re-calculate all the
> user permissions each time the user modifies its resource-lists or
> pres-rules document (there is no concept of "adding a budy" here).
> - A "cool" buddy list in which for each buddy you just can set its uri
> and its display-name (no groups, no other PIM data, no static photo,
> nothing).
> - An unfeaseible way to determine how many "resources" exist for a
> buddy as all its presentities are mixed/grouped with no real
> criterion.
> - A hypercomplex mechanism to publish a photo, mixing different protocols.
> - And better if we don't speak about RLS and so...
>
>
>   


-- 
Bogdan-Andrei Iancu
www.voice-system.ro