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

Min Wang mwang at sipwise.com
Tue Jun 26 16:19:09 CEST 2012 

Hi Anca:

        Thanks again!

        please see my comment  inline:

 > The "terminated" reason that is sent now, I think it's a bug, it was 
probably mistaken with the Subscription-Status.

        Yes, I guess so.

>
>     Let's say user A deletes user B from its contact list. Let's say 
> user B will receive a Notify with reason 'rejected'. In this moment 
> user B could also delete  the authorization rule for user A.
          Yah it could be. But from pure end user point of view, it is 
some kind of werid.
          B already allowed A to see its status. Why should B disable A 
to see its status just because of A's behavior ( disable B to its status).
A, B should be independent of its contact list and pres-rules.

         e.g: B is kind of generous people,  do not mind A's behavior.

          From my test with (jitsi with reason=rejected), jitsi B will 
not update any of its pres-rules/resource-list etc.

>
>     User B will be allowed again to see the presence of user A when 
> user A will add B again in its contact list. This is the moment when 
> you wanted to announce user B to subscribe again. This is actually be 
> achieved, as user B will receive a Notification for presence.winfo 
> that the user A requests authorization. And in this case probably most 
> of the clients ask if you want to add that user in your contact list 
> also. And this is the moment when user B will subscribe again to user A.

             Yah, you are right. that could be the moment. I remembered 
from my trace I do see the Kamailio send out presence.winfo ( active) to 
B ( in this case B did not remove this pres-rules , otherwise the 
presence.winfo will be pending), unfornately jitsi B did nothing for 
this case of active presence.winfo.

              From strict RFC point of view, sending presence.winfo does 
not mean B need to re-subscribe to A,  this is our interpretation to 
solve this issue. So we have to convince the client people to do this 
way.  will this behavior break any other things?


          I found similar call flow on Oracle site, it is:

           
http://docs.oracle.com/cd/E17667_01/doc.50/e17669/cpt_concepts.htm#

in the Changing Presence Rules section:

              5. Because Alice's updated policy does not authorize Bob 
as a watcher, the presence server sends a NOTIFY request to Bob's 
client, notifying him that his subscription is terminated. In the NOTIFY 
request, the Subscription-State header specifies terminated and the 
reason is set to probation. This ends Bob's subscription with the 
presence server and also ends the underlying SIP dialog. Bob's client 
responds with a 200 OK message.


           It uses **probation** as the reason for updated xcap policy. 
Not sure if it is OMA standard or not or just Oracle interpretation.




kind regards.


min




>
> There can be some other way to that the client knows to reSubscribe 
> again when it has received a Subscription from a user that had 
> previously rejected its subscription. This is just one behavior example.
>
> In this way the moment of reattempting the Subscription is actually 
> determined by an input of a human, which was probably also desired by 
> the RFC.
>
> Regards,
> Anca
>
>
> On 06/26/2012 01:22 PM, 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 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
>>>>
>>>>
>

More information about the sr-users mailing list