Hello SR-users and -developers,
I have the question if parameters for a function in the config script (e.g. "t_relay(host, port)") in general can be set with a variable ($var(xy)). Because of having a set of SIP servers / gateways distributed over a wide area and therefore keeping the configuration as simple as possible, I would like to define a custom variable, assign it to a $var and use this variable as attribute for a relay function. In this case the variable would represent a string of an IP-address (e.g. "10.1.1.55"). When this would work I only have to adapt the custom variables on top of each config script and could let the rest "as it is".
First practical tests have shown, that the functions are NOT happy with these "attributes". It can be used without any problems for if-else- statements, but I fear not for functions....
The practical scenario looks like:
tc.ip11 = "10.16.65.101" desc ""; [...] route { $var(test) = $sel(cfg_get.tc.ip11); [...] if (!t_relay($var(test), "5061")) [...] }
This configuration resulted in following error messages:
<core> [cfg.y:3326]: parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 413, column 18-35: syntax error <core> [cfg.y:3326]: parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 413, column 18-35: call params error#012 <core> [cfg.y:3326]: parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 413, column 18-35: call params error#012 <core> [cfg.y:3326]: parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 413, column 38-41: Function parameter with integer value not allowed#012
Please, could anybody clarify if this should work or not? If not - is any alternative possibility available for "automating" function attributes instead of re-writing each function using the same string attribute?
Thanks in advance,
Klaus
Klaus,
1) Variables are always evaluated in a lexical context, so
func($var(x));
will never work. What you want is:
func("$var(x)");
Just call it an idiosyncrasy of Kamailio/SR.
2) Not ALL core and module functions evaluate pseudo-variables and substitute their values; most do, but there are still some out there that don't and always evaluate their string arguments strictly literally.
These are mostly old-school core functions as rewritehostport(). There are a few module functions that don't support PVs as well, but I imagine that will be changing soon. A number of functions have been upgraded recently to allow PV arguments.
Cheers,
-- Alex
Alex,
thanks for your answer. I have already tried it with quotes before. However, the result is / was that Kamailio thinks the attribute (representing a variable) is a string / hostname (as usual for any characters within quotes).
The error message for t_relay is: <core> [proxy.c:271]: ERROR: mk_proxy: could not resolve hostname: "$var(tc_locIpaddr)" ERROR: tm [tm.c:613]: ERROR: fixup_hostport2proxy: bad host name in URI <$var(test)>
I've learned before, that variables MUST NOT be set in quotes for if-else-statements, because of this (it would not represent the value of the variable, but the name). The statement "if ($rU=~"$var(test)")" does not work because of the quotes; only "if ($rU=~$var(test))" is successful.
So it seems that the function "t_relay" is also an "old-school" module function ;-) I will / have to wait for a future update that will allow pseudo variables, too.
Klaus
Klaus,
Variables are always evaluated in a lexical context, so
func($var(x));
will never work. What you want is:
func("$var(x)");
Just call it an idiosyncrasy of Kamailio/SR.
Not ALL core and module functions evaluate pseudo-variables and
substitute their values; most do, but there are still some out there that don't and always evaluate their string arguments strictly literally.
These are mostly old-school core functions as rewritehostport(). There are a few module functions that don't support PVs as well, but I imagine that will be changing soon. A number of functions have been upgraded recently to allow PV arguments.
Cheers,
-- Alex
-- Alex Balashov - Principal Evariste Systems LLC
Tel : +1 678-954-0670 Direct : +1 678-954-0671 Web : http://www.evaristesys.com/
Klaus,
On 02/24/2010 10:01 AM, Klaus Feichtinger wrote:
So it seems that the function "t_relay" is also an "old-school" module function ;-) I will / have to wait for a future update that will allow pseudo variables, too.
I concur with your assessment. However, I recommend that you use Klaus Darilion's suggestion, because the destination route set ($du) is what t_relay() operates on anyhow in the absence of an overriding argument. If $du is not set, the Request URI ($ru) is used.
Thanks,
Am 24.02.2010 15:41, schrieb Klaus Feichtinger:
Hello SR-users and -developers,
I have the question if parameters for a function in the config script (e.g. "t_relay(host, port)") in general can be set with a variable ($var(xy)). Because of having a set of SIP servers / gateways distributed over a wide area and therefore keeping the configuration as simple as possible, I would like to define a custom variable, assign it to a $var and use this variable as attribute for a relay function. In this case the variable would represent a string of an IP-address (e.g. "10.1.1.55"). When this would work I only have to adapt the custom variables on top of each config script and could let the rest "as it is".
First practical tests have shown, that the functions are NOT happy with these "attributes". It can be used without any problems for if-else- statements, but I fear not for functions....
The practical scenario looks like:
tc.ip11 = "10.16.65.101" desc ""; [...] route { $var(test) = $sel(cfg_get.tc.ip11); [...] if (!t_relay($var(test), "5061"))
A workaround for t_relay:
$du = "sip:"+$var(test)+":5061"; t_relay();
klaus
[...]}
This configuration resulted in following error messages:
<core> [cfg.y:3326]: parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 413, column 18-35: syntax error <core> [cfg.y:3326]: parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 413, column 18-35: call params error#012 <core> [cfg.y:3326]: parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 413, column 18-35: call params error#012 <core> [cfg.y:3326]: parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 413, column 38-41: Function parameter with integer value not allowed#012
Please, could anybody clarify if this should work or not? If not - is any alternative possibility available for "automating" function attributes instead of re-writing each function using the same string attribute?
Thanks in advance,
Klaus
-
Alex Balashov -
Klaus Darilion -
Klaus Feichtinger