[OpenSIPS-Users] SIP Presence Aggregation Issue

[Iñaki Baz Castillo]

2010/4/12 Bogdan-Andrei Iancu <bogdan at voice-system.ro>:
> Hi Iñaki,
>
Hi Bogdan, replies inline:


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

SIMPLE is not just poor, but also inneficient at server level (a
single change in a XCAP document requires the presence server to
reload all the permissions for that user).
Even in case of solving it, the result owuld be poor, sure.


>    - come up with a new spec

Yes. I'm doing a presence spec for SIP from scratch, by learning about
XMPP and so. I've already defined the concept of "resources",
"different status priority", "global status". And best of all, there
is no HTTP/XCAP, but just SIP. Well, I have to spent lot of hours yet
:)


>    - do feedback to IETF to make SIMPLE simpler and working

IMHO this is not possible at this point, as IETF already chose XCAP
for buddies and permissions management (along with others). IMHO there
is no way to improve/fix current SIMPLE specs.



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

OMA tries to define an aggregation mechanism (like rules). I've read
it, and it's a pain, a dirty hack over IETF *incomplete*
specifications.


Sorry for sounding so rude :)




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