8 Feb
2010
8 Feb
'10
12:41 p.m.
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 <ibc(a)aliax.net>
8 Feb
8 Feb
5:01 p.m.
New subject: [permissions module] allow_source_address_group() drops the request if it returns 0
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
5:35 p.m.
New subject: [permissions module] allow_source_address_group() drops the request if it returns 0
El Lunes, 8 de Febrero de 2010, Juha Heinanen escribió:
Iñaki Baz Castillo writes:
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?
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.
Yes, I didn't want to use group 0, it was a provisioning error but such error
found out the issue :)
--
Iñaki Baz Castillo <ibc(a)aliax.net>
5:40 p.m.
New subject: [permissions module] allow_source_address_group() drops the request if it returns 0
Hello,
On 2/8/10 11:01 PM, Juha Heinanen wrote:
Iñaki Baz Castillo writes:
maybe a pseudo-variable
fits better for this purpose.
Return codes for module functions group in three classes:
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. 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.
--
Daniel-Constantin Mierla
eLearning class for Kamailio 3.0.0
* http://www.asipto.com/
5:34 p.m.
New subject: [permissions module] allow_source_address_group() drops the request if it returns 0
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
--
Daniel-Constantin Mierla
eLearning class for Kamailio 3.0.0
* http://www.asipto.com/
5:48 p.m.
New subject: [permissions module] allow_source_address_group() drops the request if it returns 0
El Lunes, 8 de Febrero de 2010, Daniel-Constantin Mierla escribió:
"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.
--
Iñaki Baz Castillo <ibc(a)aliax.net>
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?
6 p.m.
New subject: [permissions module] allow_source_address_group() drops the request if it returns 0
On 2/8/10 11:48 PM, Iñaki Baz Castillo wrote:
"return 0" is document (AFAIK) but I didn't expect that any
function returning
0 means "exiting".
It means. 'return' is a core function.
El Lunes, 8 de Febrero de 2010, Daniel-Constantin
Mierla escribió:
You can do that ...
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?
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?
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.
--
Daniel-Constantin Mierla
eLearning class for Kamailio 3.0.0
* http://www.asipto.com/
6:33 p.m.
New subject: [permissions module] allow_source_address_group() drops the request if it returns 0
El Martes, 9 de Febrero de 2010, Daniel-Constantin Mierla escribió:
Sure, I've experimented by myself :)
But I don't meant "return" core function, but any other function. Anyhow
understood now.
Thanks.
--
Iñaki Baz Castillo <ibc(a)aliax.net>
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! 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.
6:40 p.m.
New subject: [permissions module] allow_source_address_group() drops the request if it returns 0
On 2/9/10 12:33 AM, Iñaki Baz Castillo wrote:
El Martes, 9 de Febrero de 2010, Daniel-Constantin
Mierla escribió:
Sure, I've experimented by myself :)
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
eLearning class for Kamailio 3.0.0
* http://www.asipto.com/
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!
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.
5443
days inactive
5443
days old
8 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
jh＠tutpro.com