Hi
I am trying to use fr_inv_timer_avp like the following in Kamailio 3.1:
#!KAMAILIO ... modparam("tm", "fr_inv_timer_avp", "$avp(i:2)") modparam("tm", "fr_inv_timer", 180000)
.. $avp(i:2)=10 ... # t_set_fr(10000); ... t_on_failure("failroute");
It seems it is not working. the invite will timeout in 3 min, not 10 seconds.
If t_set_fr is used, it is working ( 10 seconds timeout). the t_set_fr issue is it can only accept the constant, not avp.
I saw there was a discussion in the april 2010,
http://lists.sip-router.org/pipermail/sr-users/2010-April/027101.html
Not sure fr_inv_timer_avp has been tested or not in Kamailio 3.0/3.1?
A bug or my misuage the fr_inv_timer_avp?
thanks
Hello,
On 3/21/11 4:13 PM, Min Wang wrote:
Hi
I am trying to use fr_inv_timer_avp like the following in Kamailio 3.1:
#!KAMAILIO ... modparam("tm", "fr_inv_timer_avp", "$avp(i:2)") modparam("tm", "fr_inv_timer", 180000)
.. $avp(i:2)=10 ... # t_set_fr(10000); ... t_on_failure("failroute");
It seems it is not working. the invite will timeout in 3 min, not 10 seconds.
If t_set_fr is used, it is working ( 10 seconds timeout). the t_set_fr issue is it can only accept the constant, not avp.
t_set_fr() accepts any pseudo-varaibles as parameters, how did you use it?
I saw there was a discussion in the april 2010,
http://lists.sip-router.org/pipermail/sr-users/2010-April/027101.html
Not sure fr_inv_timer_avp has been tested or not in Kamailio 3.0/3.1?
It was an issue related to time unit reported in that message, but it got fixed and should work now -- since I did the fix I tested it, hopefully there was no commit later to cause the regression. Can you do avp_print() before t_relay() and check if the avp with the timeout really exists? You have to run in debug mode.
Cheers, Daniel
A bug or my misuage the fr_inv_timer_avp?
thanks
Hi Daniel
Again. Thanks a lot.
On 03/24/2011 09:26 AM, Daniel-Constantin Mierla wrote:
t_set_fr() accepts any pseudo-varaibles as parameters, how did you use it?
You are correct! I messed with time unit in the avp. I should times 1000 for the avp
$avp(i:2)=20 //seconds t_set_fr($avp(i:2)*1000); // correct ok // t_set_fr($avp(i:2)); // previous wrong one.
I saw there was a discussion in the april 2010,
http://lists.sip-router.org/pipermail/sr-users/2010-April/027101.html
Not sure fr_inv_timer_avp has been tested or not in Kamailio 3.0/3.1?
It was an issue related to time unit reported in that message, but it got fixed and should work now -- since I did the fix I tested it, hopefully there was no commit later to cause the regression. Can you do avp_print() before t_relay() and check if the avp with the timeout really exists? You have to run in debug mode.
if fr_inv_timer_avp is used:
xlog("my fr_inv_timer is $avp(i:2)\n");
printed correct 20 seconds, but it seems avp2timer failed to get the correct value:
modules/tm/t_funcs.c: line 510 avp = search_first_avp( type | AVP_TRACK_TO, name, &val_istr, 0);
if changed to: avp = search_first_avp( type, name, &val_istr, 0);
the fr_inv_timer_avp started to working correctly.
It seems the problem is related to this AVP_TRACK_TO??
Kind regards / Mit freundlichen Grüßen
Min Wang
Cheers, Daniel
A bug or my misuage the fr_inv_timer_avp?
thanks
Hi Min,
On 3/24/11 3:47 PM, Min Wang wrote:
Hi Daniel
Again. Thanks a lot.
On 03/24/2011 09:26 AM, Daniel-Constantin Mierla wrote:
t_set_fr() accepts any pseudo-varaibles as parameters, how did you use it?
You are correct! I messed with time unit in the avp. I should times 1000 for the avp
$avp(i:2)=20 //seconds t_set_fr($avp(i:2)*1000); // correct ok// t_set_fr($avp(i:2)); // previous wrong one.
I saw there was a discussion in the april 2010,
http://lists.sip-router.org/pipermail/sr-users/2010-April/027101.html
Not sure fr_inv_timer_avp has been tested or not in Kamailio 3.0/3.1?
It was an issue related to time unit reported in that message, but it got fixed and should work now -- since I did the fix I tested it, hopefully there was no commit later to cause the regression. Can you do avp_print() before t_relay() and check if the avp with the timeout really exists? You have to run in debug mode.
if fr_inv_timer_avp is used:
xlog("my fr_inv_timer is $avp(i:2)\n"); printed correct 20 seconds, but it seems avp2timer failed to getthe correct value:
modules/tm/t_funcs.c: line 510 avp = search_first_avp( type | AVP_TRACK_TO, name, &val_istr, 0);
if changed to: avp = search_first_avp( type, name, &val_istr, 0);
the fr_inv_timer_avp started to working correctly.
It seems the problem is related to this AVP_TRACK_TO??
thanks for troubleshooting. Indeed this was an issue, I did a commit to fix it last evening. During the times when SER and Kamailio were developped separately, SER added extra avp lists, in Kamailio was still one, corresponding to AVP_TRACK_FROM.
The commit is here, if you can give it a try and it works fine for you, then I will do a backport to 3.x: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=26f757d0...
If you want to read more about these AVPs lists specific to SER, then go to: http://sip-router.org/wiki/devel/avps-ser
Cheers, Daniel
Kind regards / Mit freundlichen Grüßen
Min Wang
Cheers, Daniel
A bug or my misuage the fr_inv_timer_avp?
thanks
Hi Daniel:
On 03/25/2011 03:03 AM, Daniel-Constantin Mierla wrote:
thanks for troubleshooting. Indeed this was an issue, I did a commit to fix it last evening. During the times when SER and Kamailio were developped separately, SER added extra avp lists, in Kamailio was still one, corresponding to AVP_TRACK_FROM.
The commit is here, if you can give it a try and it works fine for you, then I will do a backport to 3.x: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=26f757d0...
I cherry-picked the commit to my local 3.1 branch, Yes, it is working.
thanks a lot for the fix and explanation!
Kind regards / Mit freundlichen Grüßen
Min Wang
If you want to read more about these AVPs lists specific to SER, then go to: http://sip-router.org/wiki/devel/avps-ser
Cheers, Daniel
Kind regards / Mit freundlichen Grüßen
Min Wang
Cheers, Daniel
A bug or my misuage the fr_inv_timer_avp?
thanks
Hello,
On 3/25/11 3:29 PM, Min Wang wrote:
Hi Daniel:
On 03/25/2011 03:03 AM, Daniel-Constantin Mierla wrote:
thanks for troubleshooting. Indeed this was an issue, I did a commit to fix it last evening. During the times when SER and Kamailio were developped separately, SER added extra avp lists, in Kamailio was still one, corresponding to AVP_TRACK_FROM.
The commit is here, if you can give it a try and it works fine for you, then I will do a backport to 3.x: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=26f757d0...
I cherry-picked the commit to my local 3.1 branch, Yes, it isworking.
thanks a lot for the fix and explanation!
thanks for reporting back. Today I backported the commit to branch 3.1.
Cheers, Daniel
Kind regards / Mit freundlichen Grüßen
Min Wang
If you want to read more about these AVPs lists specific to SER, then go to: http://sip-router.org/wiki/devel/avps-ser
Cheers, Daniel
Kind regards / Mit freundlichen Grüßen
Min Wang
Cheers, Daniel
A bug or my misuage the fr_inv_timer_avp?
thanks
Hi Daniel
thanks.
On 03/24/2011 09:26 AM, Daniel-Constantin Mierla wrote:
It was an issue related to time unit reported in that message, but it got fixed and should work now -- since I did the fix I tested it, hopefully there was no commit later to cause the regression. Can you do avp_print() before t_relay() and check if the avp with the timeout really exists? You have to run in debug mode.
Regarding the debug mode: i have following:
loadmodule "debugger.so" modparam("debugger", "cfgtrace", 1) #modparam("debugger", "breakpoint", 1) #modparam("debugger", "log_level", 1) #modparam("debugger", "log_facility", "LOG_DAEMON")
..... dbg_breakpoint("1"); //set the break point here???? # avp_print(); xlog("my fr_inv_timer is $avp(i:2)\n"); t_set_fr($avp(i:2)*1000); #t_set_fr(20000); .....
when sip msg comes, somehow dbg.ls show all processes state are 0. and passed that break point. does dbg_breakpoint suppose to set the break point there?
maybe I misunderstand how to use debugger module?
/// see the log: the xlog printed out, it should stop at Mar 24 10:51:49 sip1 /usr/sbin/kamailio[6055]: ERROR: *** cfgtrace: c=[/etc/kamailio/kamailio.cfg] l=5517 a=26 n=xlog Mar 24 10:51:49 sip1 /usr/sbin/kamailio[6055]: ERROR: <script>: my fr_inv_timer is 20 Mar 24 10:51:49 sip1 /usr/sbin/kamailio[6055]: ERROR: *** cfgtrace: c=[/etc/kamailio/kamailio.cfg] l=5524 a=26 n=t_on_failure Mar 24 10:51:49 sip1 /usr/sbin/kamailio[6055]: ERROR: *** cfgtrace: c=[/etc/kamailio/kamailio.cfg] l=5530 a=17 n=if Mar 24 10:51:49 sip1 /usr/sbin/kamailio[6055]: ERROR: *** cfgtrace: c=[/etc/kamailio/kamailio.cfg] l=5527 a=42 n=isflagset Mar 24 10:51:49 sip1 /usr/sbin/kamailio[6055]: ERROR: *** cfgtrace: c=[/etc/kamailio/kamailio.cfg] l=5530 a=25 n=t_relay
Kind regards / Mit freundlichen Grüßen
Min Wang
Cheers, Daniel
A bug or my misuage the fr_inv_timer_avp?
thanks
Hello,
the dbg_breakpoint(...) is not yet enabled internally, iirc. I left it this way since I thought there are some potential issues which need a bit more analysis, for now you have to use the global parameter to enable the breakpoint. Since you reminded it, I will try to find time for it asap.
Cheers, Daniel
On 3/24/11 4:02 PM, Min Wang wrote:
Hi Daniel
thanks.
On 03/24/2011 09:26 AM, Daniel-Constantin Mierla wrote:
It was an issue related to time unit reported in that message, but it got fixed and should work now -- since I did the fix I tested it, hopefully there was no commit later to cause the regression. Can you do avp_print() before t_relay() and check if the avp with the timeout really exists? You have to run in debug mode.
Regarding the debug mode: i have following:
loadmodule "debugger.so" modparam("debugger", "cfgtrace", 1) #modparam("debugger", "breakpoint", 1) #modparam("debugger", "log_level", 1) #modparam("debugger", "log_facility", "LOG_DAEMON")
..... dbg_breakpoint("1"); //set the break point here???? # avp_print(); xlog("my fr_inv_timer is $avp(i:2)\n"); t_set_fr($avp(i:2)*1000); #t_set_fr(20000); .....
when sip msg comes, somehow dbg.ls show all processes stateare 0. and passed that break point. does dbg_breakpoint suppose to set the break point there?
maybe I misunderstand how to use debugger module?/// see the log: the xlog printed out, it should stop at Mar 24 10:51:49 sip1 /usr/sbin/kamailio[6055]: ERROR: *** cfgtrace: c=[/etc/kamailio/kamailio.cfg] l=5517 a=26 n=xlog Mar 24 10:51:49 sip1 /usr/sbin/kamailio[6055]: ERROR: <script>: my fr_inv_timer is 20 Mar 24 10:51:49 sip1 /usr/sbin/kamailio[6055]: ERROR: *** cfgtrace: c=[/etc/kamailio/kamailio.cfg] l=5524 a=26 n=t_on_failure Mar 24 10:51:49 sip1 /usr/sbin/kamailio[6055]: ERROR: *** cfgtrace: c=[/etc/kamailio/kamailio.cfg] l=5530 a=17 n=if Mar 24 10:51:49 sip1 /usr/sbin/kamailio[6055]: ERROR: *** cfgtrace: c=[/etc/kamailio/kamailio.cfg] l=5527 a=42 n=isflagset Mar 24 10:51:49 sip1 /usr/sbin/kamailio[6055]: ERROR: *** cfgtrace: c=[/etc/kamailio/kamailio.cfg] l=5530 a=25 n=t_relay
Kind regards / Mit freundlichen Grüßen
Min Wang
Cheers, Daniel
A bug or my misuage the fr_inv_timer_avp?
thanks
Hi Daniel On 03/25/2011 03:07 AM, Daniel-Constantin Mierla wrote:
Hello,
the dbg_breakpoint(...) is not yet enabled internally, iirc. I left it this way since I thought there are some potential issues which need a bit more analysis, for now you have to use the global parameter to enable the breakpoint. Since you reminded it, I will try to find time for it asap.
thanks. It would be great to have this feature. :)
Kind regards / Mit freundlichen Grüßen
Min Wang
Cheers, Daniel
On 3/24/11 4:02 PM, Min Wang wrote:
Hi Daniel
thanks.
On 03/24/2011 09:26 AM, Daniel-Constantin Mierla wrote:
It was an issue related to time unit reported in that message, but it got fixed and should work now -- since I did the fix I tested it, hopefully there was no commit later to cause the regression. Can you do avp_print() before t_relay() and check if the avp with the timeout really exists? You have to run in debug mode.
Regarding the debug mode: i have following:
loadmodule "debugger.so" modparam("debugger", "cfgtrace", 1) #modparam("debugger", "breakpoint", 1) #modparam("debugger", "log_level", 1) #modparam("debugger", "log_facility", "LOG_DAEMON")
..... dbg_breakpoint("1"); //set the break point here???? # avp_print(); xlog("my fr_inv_timer is $avp(i:2)\n"); t_set_fr($avp(i:2)*1000); #t_set_fr(20000); .....
when sip msg comes, somehow dbg.ls show all processes stateare 0. and passed that break point. does dbg_breakpoint suppose to set the break point there?
maybe I misunderstand how to use debugger module?/// see the log: the xlog printed out, it should stop at Mar 24 10:51:49 sip1 /usr/sbin/kamailio[6055]: ERROR: *** cfgtrace: c=[/etc/kamailio/kamailio.cfg] l=5517 a=26 n=xlog Mar 24 10:51:49 sip1 /usr/sbin/kamailio[6055]: ERROR: <script>: my fr_inv_timer is 20 Mar 24 10:51:49 sip1 /usr/sbin/kamailio[6055]: ERROR: *** cfgtrace: c=[/etc/kamailio/kamailio.cfg] l=5524 a=26 n=t_on_failure Mar 24 10:51:49 sip1 /usr/sbin/kamailio[6055]: ERROR: *** cfgtrace: c=[/etc/kamailio/kamailio.cfg] l=5530 a=17 n=if Mar 24 10:51:49 sip1 /usr/sbin/kamailio[6055]: ERROR: *** cfgtrace: c=[/etc/kamailio/kamailio.cfg] l=5527 a=42 n=isflagset Mar 24 10:51:49 sip1 /usr/sbin/kamailio[6055]: ERROR: *** cfgtrace: c=[/etc/kamailio/kamailio.cfg] l=5530 a=25 n=t_relay
Kind regards / Mit freundlichen Grüßen
Min Wang
Cheers, Daniel
A bug or my misuage the fr_inv_timer_avp?
thanks
-
Daniel-Constantin Mierla -
Min Wang -
Min Wang