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

[Min Wang]

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 at 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 at 192.168.122.32;tag=f6a40771.
> From: sip:101 at 192.168.122.32;tag=a6a1c5f60faecf035a1ae5b6e96e979a-5724.
> CSeq: 4 NOTIFY.
> Call-ID: c7c52dd058268596ec84dd3c645a2f17 at 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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users