24 Feb
2010
24 Feb
'10
4:41 p.m.
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
--
Sicherer, schneller und einfacher. Die aktuellen Internet-Browser -
jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser
24 Feb
24 Feb
4:44 p.m.
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 Balashov - Principal
Evariste Systems LLC
Tel : +1 678-954-0670
Direct : +1 678-954-0671
Web : http://www.evaristesys.com/
5:01 p.m.
New subject: function calling in the config script with $var() as attribute(s)
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,
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 Balashov - Principal
Evariste Systems LLC
Tel : +1 678-954-0670
Direct : +1 678-954-0671
Web : http://www.evaristesys.com/
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
5:03 p.m.
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,
--
Alex Balashov - Principal
Evariste Systems LLC
Tel : +1 678-954-0670
Direct : +1 678-954-0671
Web : http://www.evaristesys.com/
5:01 p.m.
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
5385
days inactive
5385
days old
4 comments
3 participants
participants (3)
-
Alex Balashov -
Klaus Darilion -
Klaus Feichtinger