[OpenSIPS-Users] SIP Presence Aggregation Issue

Iñaki Baz Castillo ibc at aliax.net
Thu May 13 22:28:26 CEST 2010


2010/5/11 Adrian Georgescu <ag at ag-projects.com>:
> It makes sense to keep all clients in sync somehow and subscribing to
> itself already provides this data.
>
> But what happens with automatically derived data like keyboard
> activity or on-the-phone activity, they cannot be synchronized can they?
>
> The PIDFs will diverge sooner or later...

Right, this is when the concept of "status priorities" takes place, a
concept that doesn't exist in SIMPLE (but does exist in other presence
protocols).

For example, if alice is subscribed to bob's presence and bob
publishes presence from two devices, alice would receive both
presentities. And alice's device should choose a "winning" status to
display for bob, based on status priorities, something as:

1) on the phone
2) busy
3) dnd
4) online
5) away
6) idle

So if bob's phone 1 publishes "idle" status (no activity in the
computer) and bob's phone 2 publishes "dnd", alice's device would
choose "dnd" as *main* status. Still Alice could click on bob buddy
and see both resources of Bob, each one indicating its own status.

There is an exception: "invisible" status. Bob decides to appear as
"offline" so from one of its devices publishes "invisible" status. The
presence server must be intelligent and shouldn't show to Alice other
status of bob (even if bob's second phone is publishing "online").
This is correctly handled in XMPP for example.

Problems:
- SIMPLE doesn't specify status priorities.
- SIMPLE doesn't specify the concept of "resource".
- SIMPLE doesn't specify the concept of "global invisible status".
- SIMPLE is a big pain. USELESS.


PS: I strongly recommend everybody here to read RCS presence
specifications, mainly based on OMA specs (but different), a lot of
exotic and inneficient XCAP/XDM/SIMPLE. The final result is a joke,
just an "advanced" addressbook bof movile devices (IMS) in which you
can add buddies, subscribe to their presence and reject them as
watchers, no more, forget creating groups or tags for each buddy,
forget the server storage of complete data for each buddy (just the
uri and display-name), forget presence rules based on groups...
nothing. And the reason is that it's not possible to make effective
usage of such painful specifications.


Regards.


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



More information about the Users mailing list