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

Klaus Darilion klaus.mailinglists at pernau.at
Tue Jun 26 13:37:07 CEST 2012 


On 26.06.2012 12:22, Min Wang wrote:
> 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 think the client should be smart enough to retry also if the previous 
error was a "permanent" reasons, e.g. the client should try to 
resubscribe once a day, or after restart.

regards
Klaus


>
>        I have re-posted the issue to the sim-implementors :
>
> https://lists.cs.columbia.edu/pipermail/sip-implementors/2012-June/028585.html
>
>
>
>        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 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
>>>
>>>
>>
>
>
> _______________________________________________
> 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