[SR-Users] Subscription-State: terminated;reason=terminated?
Anca Vamanu
anca.vamanu at 1and1.ro
Tue Jun 26 15:22:09 CEST 2012
Hi Min,
You are right, "deactivated" probably is not a good choice either and
there isn't any reason phrase that will achieve what you want.
The "terminated" reason that is sent now, I think it's a bug, it was
probably mistaken with the Subscription-Status.
Analyzing again the problem that you described I reached the following
conclusions:
From the point of view of the server, removing a contact from your list
could probably mean denying that user permission to see your state -
like "block", and in this case "rejected" reason would seem more
appropriate.
From the point of view of the client, you say this is not ok, as the
RFC says the client should not attempt reSubscription. I also agree with
Klaus that this is ok and that the client can be intelligent enough deal
correctly with this situation.
Here is one behavior scenario:
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.
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.
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