[sr-dev] kamailio 3.1.3 Presence + XCAP problem, is it a

[laura testi]

Hello,
do you have any news about this case?


About the described scenario:

I think the step 4a) may be a bug:
the subscription STATUS of  B (watcher of A) to A should remain ACTIVE (1)
instead of PENDING(2). this state is very strange and that causes the
strange step 4b) after A having removed B. Because B does still subscribe
A’s presentity! And probably do this causes the incorrect behavior of step
5)?
Should the presence server also remove the record of the subscription from
A(watcher) to B(presentity)  from both active_watchers and watchers tables
instead of only from active_wtachers table? Because if A remove B
(unsubscribe B), that mean A don’t want to see the presentity of B. Or maybe
it’s correct put A’s subscription status of B in TERMINATED(3) instead of
removing the record (actually remains in ACTIVE(1)).
When the presence server is doing pres_refresh_watchers in step 5), I think
it checks the xcap table and see A is watcher of B  (A is in B’s
presence_allow rule) and is in B’s resource-list, and B is also
active_watcher of A in the active_watchers table, A’s subscription status of
B is ACTIVE(1) in watchers table, B’s subscription status of A is in
Pending(2), it send a NOTIFY to B. That’s really strange! Probabely the step
4) also causes this strange behavior.
I think in step 1, in addition to remove the record of A’s subscription of B
from active_watchers table, the PS should also remove the record of A’s
subscription of B from the watchers table or put the STATUS=TERMINATED.
That’s because A is not interested the B’s presentity anymore.
In step 4, the PS should not change watchers table, because B’s subscription
of A is still active (should not becomes pending), and should not send the
Pending notify too.
Same for step 5.

thanks in advance,
laura
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20110531/b20ca319/attachment.htm>