[Kamailio-Users] Kamailio 3.0.0: configuration request regarding VARIABLES usage (custom variables + $var(x))

[Henning Westerholt]

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.html
 
> 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