[OpenSIPS-Users] SIP Presence Aggregation Issue

[Iñaki Baz Castillo]

2010/4/4 Adrian Georgescu <ag at ag-projects.com>:
> Hi Inaki,
>
> If you hate your own work so much why are you doing it?

Well, it was my spare time :)
I spent so many time because I thought SIMPLE presence could be cool,
but that's not true as anyone reading the full specifications does
know.


> SIP as a protocol is also broken cause it caries IP and port numbers
> into its payloads, this breaks many things and is architecturally wrong.

Well, these are other kind of issues present in SIP core itself,
something we've already learnt to live with.
This is because RFC 3261 was written without handling NAT scenarios,
but at least there are new specifications solving it (rport, STUN,
ICE...). But there are no new specifications trying to fix the pain of
SIMPLE presence specifications.


> There are many wrong and bad things in life if you only look at the
> empty side of the glass.
>
> I personally love what I am doing otherwise I would not do it.

I love SIP, I just hate SIMPLE presence specifications. These
specifications are not completed at all, are too wide/abstract ("I'm
available via mail"??) and force interoperability problems. And worst,
they provide less than 15% of the features provides by any other
presence protocol. This is what we want? this is what we accept?

A good example is this mail thread in which the author asks for a way
to aggretate presentity content. Sorry, no real way to achieve it as
SIMPLE itself makes it unfeasible. The presence server will get
various presentities for the same AoR and there is no way to determine
which one should have prioriry over others. Just OMA specifications
comments something really abstract trying to achieve it (but it's
still unuseful and unclear).


Please, don't take me wrong, I criticize SIMPLE presence after
studying and implementing most of it. Also SIMPLE/XCAP specifications
are fully managed by telcos/operators (3GPP) and their specifications
are not really suitable for IP networks, so far from their private
infrastructure.

Regards.

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