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