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
Juha Heinanen writes:
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()?
it turned out that i had called set_forward_no_connect(). so only the first problem remains, i.e., setting $fs without proto does not take proto from $du, which is what wiki claims.
-- juha
-
Juha Heinanen