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

hi Anca thanks a lot for the quick response. As you see from the RFC3265, deactivated means the client will try to re-subscribe immediately, which seems to be not good neither. The ideal behavior could: stop the client to re-subscribe if it is not allowed ( this could be done by reason=rejeceted), then make the client to re-subscribe once if it is allowed again, but how to achieve this step? Is there a RFC/protocol way to do it. I have re-posted the issue to the sim-implementors : https://lists.cs.columbia.edu/pipermail/sip-implementors/2012-June/028585.h… As for the code change, could you please wait until there is a further discussion on it? thanks again. min On 06/26/2012 12:02 PM, Anca Vamanu wrote: > Hi Min, > > > I also consider the "terminated" reason is not the best choice in this > case. > I think reason "deactivated" is more appropriate. Since you seem to > have researched about this also, do you agree? I can do this change in > the code. > > > Thanks and regards, > Anca > > > On 06/26/2012 01:07 AM, Min Wang wrote: >> 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: >>> HI >>> >>> when I removed 102 from 101's contact list (using jitsi nightly 1.1 >>> build), kamailio 3.3 send out NOTIFY to 102 like this: >>> >>> >>> NOTIFY >>> sip:102@192.168.122.147:5060;transport=udp;registering_acc=192_168_122_32 >>> >>> >>> SIP/2.0. >>> Via: SIP/2.0/UDP 192.168.122.32;branch=z9hG4bK1bfb.afbf0a85.0. >>> To: sip:102@192.168.122.32;tag=f6a40771. >>> From: >>> sip:101@192.168.122.32;tag=a6a1c5f60faecf035a1ae5b6e96e979a-5724. >>> CSeq: 4 NOTIFY. >>> Call-ID: c7c52dd058268596ec84dd3c645a2f17(a)0.0.0.0. >>> Content-Length: 0. >>> User-Agent: kamailio (3.3.0-rc0 (x86_64/linux)). >>> Max-Forwards: 70. >>> Event: presence. >>> Contact:<sip:192.168.122.32:5060;transport=udp>. >>> Subscription-State: terminated;reason=terminated.<----------------- >>> >>> >>> >>> Note the reason code is:terminated. >>> >>> >>> From rfc3265, The defined reason codes are: deactivated/ >>> probation/rejected/ timeout/giveup/noresource >>> >>> >>> What is the reason to send: reason=terminated instead one of the >>> well-defined reason codes? >>> >>> >>> There was a discussion regarding at: >>> >>> http://sip-router.org/tracker/index.php?do=details&task_id=133 >>> <http://sip-router.org/tracker/index.php?do=details&task_id=133> >>> >>> >>> but I did not see the explaination of reason=terminated. >>> >>> >>> Thanks >>> >>> >>> min >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing >>> list >>> sr-users(a)lists.sip-router.org >>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> _______________________________________________ >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing >> list >> sr-users(a)lists.sip-router.org >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> >>