Re: [SR-Users] default kamailio configuration
On 25.06.2012 14:44, Vitaliy Aleksandrov wrote: Hi All, After reading default kamailio configuration i can't understand why does kamailio remove preloaded route headers from the incoming initial INVITE before calling record_route(). remove_hf(Route); if (is_method(INVITE|SUBSCRIBE)) record_route(); Pre-loaded route sets can be used to abuse the proxy as an open relay. This is bad. If a request hits my proxy, then I want to define how the message is routed, and I do not want to route the message like somebody else wants it. What will happen if an INVITE comes from another SIP proxy which wants to stay in the middle of the dialogue ? Only Route headers are removed, not Record-Route headers which create the route-set. For example, during Re-INVITE UA from our local site will construct in-dialog INVITE with R-URI taken from the remote contact and send it to our local proxy according to RR. Local proxy will process it in route[WITHNDLG] where loose_route() function will remove top most RR header because it points to us and since there is no more RR records forward the request to a destination from the R-URI. As i understand in that case remote proxy will not receive any in-dialog requests from us. Sure it does. As only the pre-loaded route is remove, not the Record-Route headers. Thus, the in-dialog route set is not affected, only the out-of-dialog route set (pre-loaded) is manipulated. regards Klaus ___ 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
Re: [SR-Users] Subscription-State: terminated;reason=terminated?
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@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=detailstask_id=133 http://sip-router.org/tracker/index.php?do=detailstask_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
Re: [SR-Users] Subscription-State: terminated;reason=terminated?
HI Klaus thanks. I will try Sip-implementors first to see if others have the similar issue :) kind regards min On 06/26/2012 10:09 AM, Klaus Darilion wrote: 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@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=detailstask_id=133 http://sip-router.org/tracker/index.php?do=detailstask_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
Re: [SR-Users] Subscription-State: terminated;reason=terminated?
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=detailstask_id=133 http://sip-router.org/tracker/index.php?do=detailstask_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
Re: [SR-Users] Subscription-State: terminated;reason=terminated?
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@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=detailstask_id=133 http://sip-router.org/tracker/index.php?do=detailstask_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
Re: [SR-Users] Subscription-State: terminated;reason=terminated?
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=detailstask_id=133 http://sip-router.org/tracker/index.php?do=detailstask_id=133 but I did not see the explaination of
Re: [SR-Users] Kamailio : Listening on multiple ports behind NAT
Thanks Richard for the tip :) Reda On Sun, Jun 24, 2012 at 7:28 PM, Richard Brady rnbr...@gmail.com wrote: Hi Reda A bit late for a reply but I found your post recently and it helped me to solve a similar problem, so I wanted to share one possible solution. On 21 January 2012 23:19, Reda Aouad reda.ao...@gmail.com wrote: After endless tests, I tried to replace record_route_preset with insert_hf, writing the complete record route headers. A light started to come out of the tunnel. Suppose User A is registered to port 53, User B to port 5060. In the case of double record route, when A sends an INVITE to B, I write the following in the SIP header of the INVITE forwarded to B : Record-Route: sip:public_ip:5060;r2=on;lr=on Record-Route: sip:public_ip:53;r2=on;lr=on The first transaction, INVITE / 200OK goes well, with Kamailio forwarding packets correctly from the corresponding socket of each user. The problem arises when User B sends BYE to the 5060 port, with both route headers in the SIP header of the BYE. I get the following error : WARNING: rr [loose.c:747]: no socket found for match second RR after which Kamailio forwards the BYE from the 5060 socket to User A. User A being registered on port 53, ignores the packet coming with source port 5060. The BYE is never replied to. I guess that means that Kamailio is not able to find the private_ip:53 socket from the public_ip:53 record-route header. I hope it was clear. One way to get around this is to populate the RR with a hostname instead of an address. Then you can configure it so that the external clients resolve public_ip but the Kamailio server itself resolves private_ip. This can be done through an entry in /etc/hosts to override the public DNS entry. Not exactly elegant but it works for me. I think there's a fundamental issue with running Kamailio behind NAT and listening on multiple port numbers. Am I the only one suffering from this type of configuration? (Part of the problem is also tied to dumb ALG NAT routers which try to out-smart SIP servers, without which I wouldn't run Kamailio on multiple ports, and life would be much easier) Regards, Richard ___ 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
Re: [SR-Users] default kamailio configuration.
I have lost in Route and Record-Route headers. But now it's clear for me. Huge thanks. On 25.06.2012 14:44, Vitaliy Aleksandrov wrote: Hi All, After reading default kamailio configuration i can't understand why does kamailio remove preloaded route headers from the incoming initial INVITE before calling record_route(). remove_hf(Route); if (is_method(INVITE|SUBSCRIBE)) record_route(); Pre-loaded route sets can be used to abuse the proxy as an open relay. This is bad. If a request hits my proxy, then I want to define how the message is routed, and I do not want to route the message like somebody else wants it. What will happen if an INVITE comes from another SIP proxy which wants to stay in the middle of the dialogue ? Only Route headers are removed, not Record-Route headers which create the route-set. For example, during Re-INVITE UA from our local site will construct in-dialog INVITE with R-URI taken from the remote contact and send it to our local proxy according to RR. Local proxy will process it in route[WITHNDLG] where loose_route() function will remove top most RR header because it points to us and since there is no more RR records forward the request to a destination from the R-URI. As i understand in that case remote proxy will not receive any in-dialog requests from us. Sure it does. As only the pre-loaded route is remove, not the Record-Route headers. Thus, the in-dialog route set is not affected, only the out-of-dialog route set (pre-loaded) is manipulated. regards Klaus ___ 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
Re: [SR-Users] Subscription-State: terminated;reason=terminated?
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
Re: [SR-Users] Subscription-State: terminated;reason=terminated?
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
[SR-Users] TM module timer question
Hello All, Situation, sip client on a smart phone, with a minimum registration time of 10 minutes, connected through wifi. Just after a reregister I walk out of range of the wifi connection. Then someone tries to call me, lookup location gives back that I am online and can be found at ip address w.x.y.z on port number , but I am not there because I walked out of the wifi range. Which timer do I need to use to get a failure route to reroute the call to a pstn gateway? I have tried the fr_timer which works, I set it to 5000, downside is that when I am in wifi range, I only have 5 seconds to answer the call. The fr_inv_timer is not the right one I think, as I will not get any message from the called number, as that device is not connected.. Link to a thread I missed is more than welcome. Thanks. Gertjan ___ 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
Re: [SR-Users] Subscription-State: terminated;reason=terminated?
On 26.06.2012 16:19, Min Wang wrote: 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. What about adding a module parameter (string) with probation as default? regards Klaus ___ 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
Re: [SR-Users] Subscription-State: terminated;reason=terminated?
HI Klaus , Anca: 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. What about adding a module parameter (string) with probation as default? I guess it is a good solution from practical point of view. Also how about adding another parameter as well: retry_after , something default 10 or 30 minutes? 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
[SR-Users] Question about git update
Hello. Can someone help me on how to update a module patch using GIT? I need to update the module dialog….. Currently I have the directory /usr/local/src/kamailio-3.2 And under this I have kamailio/ all this was created using : git clone --depth 1 git://git.sip-router.org/sip-router kamailio cd kamailio git checkout -b 3.2 origin/3.2 I’ll appreciate any help. Thanks in advance, Ricardo Martinez.- ___ 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
