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