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

Klaus Darilion klaus.mailinglists at pernau.at
Tue Jun 26 10:09:31 CEST 2012


Hi Min!

As your already digging into the standards please propose a solution for 
correct behavior :-)


On 26.06.2012 00:07, 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 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
>
>
> _______________________________________________
> 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




More information about the sr-users mailing list