[SR-Users] [sr-dev] Tutorial: SIP SIMPLE Presence Made Simple with Kamailio 3.1

[Iñaki Baz Castillo]

2010/9/30 Daniel-Constantin Mierla <miconda at gmail.com>:
> I wonder if a delete can change the status of watcher. Usually is translation
> from none to pending to active, but can be other way around triggered by
> xcap operation?

In OMA specs *any* change (PUT/DELETE) in resource-lists document must
trigger a reload of pres-rules and other applications including
references to lists in 'resource-lists'. The same in 'pres-rules'
document, sure.


If for example Bob is included in <list id="friends> and such list is
referred by <list id="oma_buddies"> and 'oma_buddies' is referred by a
rule in pres-rules with action 'allow', then removing Bob from <list
id="friends"> requires the *complete* (UGLY) pres-rules to be
re-calculated so Bob's subscription status would change from "active"
to "terminated".


Now to demostrate how ugly is all this stuff, let imagine you want to
temporally block Bob (so he cannot see your current real presence
status). According to OMA specs (and there are no other specs):

1) First you should do a partial DELETE operation in 'resource-list'
to remove Bob uri from your granted <list>.

2) Later you should do a partial PUT operation in 'resource-lists' to
include Bob in a <list id="oma_polite_blocked"> (or something
similar).


Oppps, problem! After step 1 the presence server should *terminate*
the subscription dialog with you (the watcher) so you receive a NOTIFY
with "Subscription-Status: terminated;reason=rejected".
Then it's *up to you* to subscribe to Bob again or not.

Imagine you subscribe again to Bob's presence upon receipt of the
NOTIFY (but before the above step 2). Then your SUSBCRIBE would be
rejected again. Will you try *again* a new SUSBCRIBE? for how long?
After step 2, if you send a new SUBSCRIBE then the server will accept
your subscription but notify you with false presence status (or no
info at all) as you are polite-blocked.


Obviously this design is ugly. In contrast, in XMPP there is like an
API to "authorize"/"desauthorize" a contact, "block" him... you must
not deal with tedious XML files for *all*, neither you need to expect
that the presence server and all your UA's (same AoR) interpret the
whole XML documents in the same way (bob is included in "oma_granted"
list but he is also included in 'pres-rules' document as a separate
blocked entry, should I understand he is blocked or allowed? will the
presence server understand the same as my UA?).

Also, in XMPP a change in your buddylist doesn't require the presence
server to re-compute all the permissions of all your watchers.


Well, coming back to the original question: yes, any incremental/total
change (PUT/DELETE) in pres-rules or resource-lists document should
trigger a complete reload of watchers permissions. Also, the RLS
application uses a reference to a <list> into resource-lists, so if a
item in such list is modified the RLs should recompute the list of
AoR's it must subscribe in behalf of the user (so ugly all of
this...).


Regards.




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