[prev in list] [next in list] [prev in thread] [next in thread] 

List:       serdev
Subject:    [sr-dev] kamailio 3.1.3 Presence + XCAP problem, is it a
From:       laura testi <lau.testi () gmail ! com>
Date:       2011-05-31 13:20:32
Message-ID: BANLkTimFsa+23iA78deFVpFkGNH0k5RR1A () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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

[Attachment #5 (text/html)]

<div>Hello,<br>do you have any news about this case?</div>
<div> </div>
<div> </div>
<div>About the described scenario:</div>
<div> </div>
<div>I think the step 4a) may be a bug:<br>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)? <br> 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)).<br> 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.<br> </div>
<div>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.<br> 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.<br>Same for step 5.<br></div> \
<div> </div> <div>thanks in advance,<br>laura</div>
<div> </div>



_______________________________________________
sr-dev mailing list
sr-dev@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev


[prev in list] [next in list] [prev in thread] [next in thread]