Re: [SR-Users] Subscription-State: terminated;reason=terminated?

HI I did more analysis: as before, the configure is: 101 --- kamailio proxy/xcap server -- 102 101/102 : jitsi night build, xcap/SIMPLE mode kamailio is 3.3 101 has 102 on its contacts list, and 102 has 101 on its contacts list as well now 101 remove 102 from its contact, proxy will send out NOTIFY to 102 (1) if reason=terminated returned in NOTIFY ( this is the current kamaili behavior) According to RFC 3265: If no reason code or an unknown reason code is present, the client MAY attempt to re- subscribe at any time (unless a "retry-after" parameter is present, in which case the client SHOULD NOT attempt re-subscription until after the number of seconds specified by the "retry-after" parameter). Jitsi 1.1 nightly will keep on re-subscribe ( at some random time ). And kamailio/proxy will keep on reject the subscribe with: NOTIFY, with reason=terminated. It seems to waste some resources (bandwidth/db/cpu etc). Image if there are a lot of deleted contacts :(. (2) if reason=rejected returned in NOTIFY according to the same RFC: rejected: The subscription has been terminated due to change in authorization policy. Clients SHOULD NOT attempt to re-subscribe. The "retry-after" parameter has no semantics for "rejected". So the client will not send any re-subscribe, which is good, will save some resources. But there is an issue: when 101 add 102 again, after 101 puting pres-rules (allow 102) to the xcap server , there will be two cases: (2.a). If that subscription expired, or deleted by the kamailio timer ( I hope I understand the code correctly) of course kamailio will not send any NOTIFY (to 102). (2.b). if that subscription do still exist in active_watcher, that subscriptions will be marked as active kamailio will send the NOTIFY to 102 indicating 101's status But from 102 point of view: since the subscription has been terminated , this notify will be rejected as 481 non-exist. In neither case, can 102 see 101's status ( since 102 to 101's subscription has been rejected/terminated from 102 point of view) So from pure end-user point of view, that is not the expected behavior. User expect the 102 can see 101's status since 101 now allow 102 again and 102 did not remove 101 from his contact list The question is: how can we do it right? Thanks. min On 06/25/2012 05:43 PM, Min Wang wrote: