I just noticed that db showg tries to use mysql’s \G method for expanded
output even with other db engines.
The dnssec module, at least in the version in debian sid, failes to load
with:
0(23381) ERROR: <core> [sr_module.c:599]: load_module(): ERROR:
load_module: could not open module
</usr/lib/x86_64-linux-gnu/kamailio/modules/dnssec.so>:
/usr/lib/x86_64-linux-gnu/libval-threads.so.14: undefined symbol:
SSL_get_SSL_CTX
My impression is that it should link against -lval_shim rather
than directly against -lval-threads.
app_perl gives this error:
NOTICE: <core> [sr_module.c:654]: load_module():
/usr/lib/x86_64-linux-gnu/kamailio/modules/app_perl.so: exports dlflags
interface is deprecated and it will not be supported in newer versions;
consider using mod_register() instead
-JimC
--
James Cloos <cloos(a)jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
while doing some tests with close to latest master version, i noticed
that forcing send socket does not match wiki $fs description (or i have
misunderstood it):
$fs - reference to the forced socket for message sending (if any) in the
form proto:ip:port
It is R/W variable (you can assign values to it directly in
configuration file). Transport proto can be omitted when assigning
value, in which case it is taken from destination URI of the message.
in config i execute:
xlog("L_INFO", "**** du = <$du>\n");
$fs = "192.98.101.20:5060";
xlog("L_INFO", "**** fs = <$fs>\n");
and i get to syslog:
Sep 14 20:49:18 lohi /usr/bin/sip-proxy[6610]: INFO: **** du = <sip:192.98.102.10;transport=tcp>
Sep 14 20:49:18 lohi /usr/bin/sip-proxy[6610]: INFO: **** fs = <udp:192.98.101.20:5060>
Sep 14 20:49:18 lohi /usr/bin/sip-proxy[6610]: ERROR: tm [../../forward.h:223]: msg_send(): msg_send: ERROR: tcp_send failed
it shows that even when transport of $du is tcp, transport proto of fs
is udp.
another weird thing is that when i add proto to the assignment:
$fs = "tcp:192.98.101.20:5060";
i still get the same tcp_send failed error.
my proxy is definitely listening on tcp:192.98.101.20:5060 and 'telnet
192.98.102.10 5060' shows that tcp connection succeeds.
the only explanation that comes to mind is if i have called
set_forward_no_connect(), but i have not found such a call. is there a
function call to revert set_forward_no_connect()?
is it somehow possible to find out why tcp_send fails?
-- juha