On Monday 22 February 2010, Alex Balashov wrote:
Is it
impossible using a variable for requesting a SRC_IP address? With
my current configuration I always see an entry in the SYSLOG that looks
as follows: "<core> [route.c:1531]: BUG: comp_ip: invalid type for
src_ip or dst_ip (20)"
The configuration lines look like:
$var(lst_gwIpRange) = "10.16.48.6[0-2]";
[...]
if (src_ip=~$var(lst_gwIpRange)) {
[...]
}
The problem is that 'src_ip' is one of the composite types used in the
core and cannot be evaluated against a regular expression. The type
that 'src_ip' has is just not part of the grammar surrounding the '=~'
operator.
Klaus,
one thing that is useful with regards to the 'src_ip' variable that you can
compare against networks, e.g. src_ip == 192.168.1.0/24 - perhaps this can be
used to implement your requirements as well.
QUESTION 2:
==========
The second problem I found is, that the config variables can be
configured within a route block only and not - as expected - e.g. at the
top of the config file (in the same way as the custom variables). I can't
use the custom variablesas they are, because I will use more complex
variables, which are a mixture of up to three custom variables. These
"complex" variables will be used in more than one routing block.
Therefore I have to define these variables in every routing block......
Is an alternative (easier) solution with a single definition available,
too?
This question I cannot answer and will defer to the developers, because
I am confused by your use of custom "selects." It was my impression
that select namespaces are only defined by modules and the user cannot
come up with them on his own, e.g. like 'tst'.
Its possible to define them also on your own:
http://by-miconda.blogspot.com/2009/12/best-of-new-in-kamailio-300-4-cfg.ht…
I also am not sure that there is a nice, elegant way
to initialise
variables in a global namespace right now except shared variables
($shv(...), in the 'pv' module), even though I would agree that such a
thing would be immensely useful.
With regards to the question of the OP, if you need to access this variable
only in one place then perhaps you could just ommit the temporary definition.
If you only have the problem of visibility, what about using another type of
storage, like Alex suggested, '$shv' or perhaps '$avp'?
Regards,
Henning