Hi, using Kamailio 1.5 rev 5834 with permissions module.
I do "$avp(i:10) = allow_source_address_group()" for a request whose source address matches a row in "address" table with "grp=0". I expect that allow_source_address_group() would return 0.
However the request is dropped in silence!! How is it possible?
It seems that allow_source_address_group() behaves as "return(0)" when the returned value is 0. But this is not documented and IMHO it cannot be the expected behavior, am I right?
Regards.
Iñaki Baz Castillo writes:
I do "$avp(i:10) = allow_source_address_group()" for a request whose source address matches a row in "address" table with "grp=0". I expect that allow_source_address_group() would return 0.
i checked the code and it returns the number of the group. if group happens to be zero, it returns zero, which exists the script. i need to disallow group number 0 and document it.
so the "fix" is to use some other group number that zero.
-- juha
El Lunes, 8 de Febrero de 2010, Juha Heinanen escribió:
Iñaki Baz Castillo writes:
I do "$avp(i:10) = allow_source_address_group()" for a request whose source address matches a row in "address" table with "grp=0". I expect that allow_source_address_group() would return 0.
i checked the code and it returns the number of the group. if group happens to be zero, it returns zero, which exists the script. i need to disallow group number 0 and document it.
But why is not 0 a valid group? why does 0 exist the script? it's just a return value, does any script function returning 0 ends the script?
so the "fix" is to use some other group number that zero.
Yes, I didn't want to use group 0, it was a provisioning error but such error found out the issue :)
Hello,
On 2/8/10 11:01 PM, Juha Heinanen wrote:
Iñaki Baz Castillo writes:
I do "$avp(i:10) = allow_source_address_group()" for a request whose source address matches a row in "address" table with "grp=0". I expect that allow_source_address_group() would return 0.
i checked the code and it returns the number of the group.
maybe a pseudo-variable fits better for this purpose.
Return codes for module functions group in three classes:
0 - true
==0 - exit <0 - false
They are not very indicated to be used for returning values in the script, although, of course, you need different true/false values to distinguish among various internal behaviors of the function.
Cheers, Daniel
if group happens to be zero, it returns zero, which exists the script. i need to disallow group number 0 and document it.
so the "fix" is to use some other group number that zero.
Hello,
On 2/8/10 6:41 PM, Iñaki Baz Castillo wrote:
Hi, using Kamailio 1.5 rev 5834 with permissions module.
I do "$avp(i:10) = allow_source_address_group()" for a request whose source address matches a row in "address" table with "grp=0". I expect that allow_source_address_group() would return 0.
However the request is dropped in silence!! How is it possible?
returnin 0 from a module function means 'exit': http://www.asipto.com/pub/kamailio-devel-guide/#c16return_values
It seems that allow_source_address_group() behaves as "return(0)" when the returned value is 0. But this is not documented and IMHO it cannot be the expected behavior, am I right?
You mean 'return 0' is not documented or this particular function's behavior with group id 0?
Cheers, Daniel
El Lunes, 8 de Febrero de 2010, Daniel-Constantin Mierla escribió:
returnin 0 from a module function means 'exit': http://www.asipto.com/pub/kamailio-devel-guide/#c16return_values
Ok:
------------- 16.9.1. Return Values
Returning values from the command functions have a special meaning in the configuration file. The command functions return an integer value, and the config file interpreter use it as follows:
- if <0 - evaluation of the return code is FALSE - if 0 - the interpreter stop executing the configuration file - if >0 - evaluation of the return code is TRUE -------------
So what about if I want to develop a module function which can return 0 as a valid integer and store it in a pv? (i.e. a function returning the number of locations for a given AoR).
It seems that allow_source_address_group() behaves as "return(0)" when the returned value is 0. But this is not documented and IMHO it cannot be the expected behavior, am I right?
You mean 'return 0' is not documented or this particular function's behavior with group id 0?
"return 0" is document (AFAIK) but I didn't expect that any function returning 0 means "exiting". Also, in the current module (permissions) and current function (allow_source_address_group) this is a limitation as it doesn't allow returning a group value 0.
Thanks.
On 2/8/10 11:48 PM, Iñaki Baz Castillo wrote:
El Lunes, 8 de Febrero de 2010, Daniel-Constantin Mierla escribió:
returnin 0 from a module function means 'exit': http://www.asipto.com/pub/kamailio-devel-guide/#c16return_values
Ok:
16.9.1. Return Values
Returning values from the command functions have a special meaning in the configuration file. The command functions return an integer value, and the config file interpreter use it as follows:
- if<0 - evaluation of the return code is FALSE
- if 0 - the interpreter stop executing the configuration file
- if>0 - evaluation of the return code is TRUE
So what about if I want to develop a module function which can return 0 as a valid integer
You can do that ...
and store it in a pv?
but it won't get here!
(i.e. a function returning the number of locations for a given AoR).
Return the value in a PV or make the function a new PV. All functions needing such behavior used this approach so far (see group, dispatcher, etc ...).
Returning 0 from a function (core or module) is 'exit' from the beginning of SER in 2001, it is how tm functions absorb retransmissions and the config is not executed further (e.g., t_check_trans(), t_newtran(), ...).
It seems that allow_source_address_group() behaves as "return(0)" when the returned value is 0. But this is not documented and IMHO it cannot be the expected behavior, am I right?
You mean 'return 0' is not documented or this particular function's behavior with group id 0?
"return 0" is document (AFAIK) but I didn't expect that any function returning 0 means "exiting".
It means. 'return' is a core function.
Also, in the current module (permissions) and current function (allow_source_address_group) this is a limitation
not a feature :-) ?!? Do you want to have if's around each functions to see if it is the case to exit the script?
Moreover cfg functions do not follow usual C/other languages patterns where 0 is false and !=0 (negative or positive) is true.
Cheers, Daniel
as it doesn't allow returning a group value 0.
El Martes, 9 de Febrero de 2010, Daniel-Constantin Mierla escribió:
So what about if I want to develop a module function which can return 0 as a valid integer
You can do that ...
and store it in a pv?
but it won't get here!
Sure, I've experimented by myself :)
Returning 0 from a function (core or module) is 'exit' from the beginning of SER in 2001, it is how tm functions absorb retransmissions and the config is not executed further (e.g., t_check_trans(), t_newtran(), ...).
Oh yes, it makes more sense now :)
"return 0" is document (AFAIK) but I didn't expect that any function returning 0 means "exiting".
It means. 'return' is a core function.
But I don't meant "return" core function, but any other function. Anyhow understood now.
Thanks.
On 2/9/10 12:33 AM, Iñaki Baz Castillo wrote:
El Martes, 9 de Febrero de 2010, Daniel-Constantin Mierla escribió:
So what about if I want to develop a module function which can return 0 as a valid integer
You can do that ...
and store it in a pv?
but it won't get here!
Sure, I've experimented by myself :)
Returning 0 from a function (core or module) is 'exit' from the beginning of SER in 2001, it is how tm functions absorb retransmissions and the config is not executed further (e.g., t_check_trans(), t_newtran(), ...).
Oh yes, it makes more sense now :)
"return 0" is document (AFAIK) but I didn't expect that any function returning 0 means "exiting".
It means. 'return' is a core function.
But I don't meant "return" core function, but any other function. Anyhow understood now.
returning 0 from any config function to stop the execution was actually there before 'exit'. Now 'exit' (and 'drop') is associated with an internal flag in the execution state. But I believe changing 'return 0' will create some confusion. I would prefer a clean similar-to-C approach and internal flags usages for special cases, but we have to leave with the history sometimes ... Could be a debate for future major releases and will imply quite some work.
Cheers, Daniel
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
jh＠tutpro.com