Hello, I'm seeing the following issues when using the latest kamailio 1.4 (Revision: 5689) to set an AVP to control fr_inv_timer: - if I set the AVP to an empty string, according to tm doc, the value of the timer would fall back to the default value. This doesn't happen and the fr_inv_timer is set to zero (not a problem as I just have to set it to the static value. It is just inconsistent with the doc). - if I try to set the timer to something bigger than 60 seconds, the setting doesn't work and it seems the default value is used instead (I tested this with both hard-coding the assignment in the cfg and loading the avp from the usr_preferences).
regards, takeshi
On Thursday 12 March 2009, mayamatakeshi wrote:
Hello, I'm seeing the following issues when using the latest kamailio 1.4 (Revision: 5689) to set an AVP to control fr_inv_timer:
- if I set the AVP to an empty string, according to tm doc, the value
of the timer would fall back to the default value. This doesn't happen and the fr_inv_timer is set to zero (not a problem as I just have to set it to the static value. It is just inconsistent with the doc).
Hi mayamatakeshi,
i checked the source code, when the fr_inv_timer_avp string is not defined it is indeed set to zero. I guess the documentation means is ignored when the _avp_ is set to an empty string, where you set the modparam, but this is unclear, i'll fix it.
- if I try to set the timer to something bigger than 60 seconds, the
setting doesn't work and it seems the default value is used instead (I tested this with both hard-coding the assignment in the cfg and loading the avp from the usr_preferences).
Looking to the source code i can't confirm this at the moment. Can you perhaps test with debug mode enabled, and look for the "FR_INV_TIMER =" string? Do you get an error that the string can be converted to an integer?
Cheers,
Henning
On Sat, Mar 14, 2009 at 3:04 AM, Henning Westerholt henning.westerholt@1und1.de wrote:
On Thursday 12 March 2009, mayamatakeshi wrote:
- if I try to set the timer to something bigger than 60 seconds, the
setting doesn't work and it seems the default value is used instead (I tested this with both hard-coding the assignment in the cfg and loading the avp from the usr_preferences).
Looking to the source code i can't confirm this at the moment. Can you perhaps test with debug mode enabled, and look for the "FR_INV_TIMER =" string? Do you get an error that the string can be converted to an integer?
Hello, Henning, actually, my interpretation of the problem was wrong. Enabling debugging and checking a trace of the messages I realized the problem is that the softphone (a Nokia E51) resends"180 Ringing" exactly 60 seconds after sending the first one. This caused fr_inv_timer to reset. So the customized timeout was not happening and I was mislead to believe the timer cannot be set to values over 60 seconds. I was not aware of the parameter restart_fr_on_each_reply. So I set it to 0 (disabled) and now everything is OK. Sorry for wrong report.
regards. takeshi
On Saturday 14 March 2009, mayamatakeshi wrote:
- if I try to set the timer to something bigger than 60 seconds, the
setting doesn't work and it seems the default value is used instead (I tested this with both hard-coding the assignment in the cfg and loading the avp from the usr_preferences).
Looking to the source code i can't confirm this at the moment. Can you perhaps test with debug mode enabled, and look for the "FR_INV_TIMER =" string? Do you get an error that the string can be converted to an integer?
Hello, Henning, actually, my interpretation of the problem was wrong. Enabling debugging and checking a trace of the messages I realized the problem is that the softphone (a Nokia E51) resends"180 Ringing" exactly 60 seconds after sending the first one. This caused fr_inv_timer to reset. So the customized timeout was not happening and I was mislead to believe the timer cannot be set to values over 60 seconds. I was not aware of the parameter restart_fr_on_each_reply. So I set it to 0 (disabled) and now everything is OK. Sorry for wrong report.
Hi takeshi,
ok, good that it works for you now. :-)
Henning