Of course this won't work if you route to the other proxies also using
lookup() with permanent entries in location table. If you really have
such a setup you can try to set a certain flag for this entries and then
do not call set_forward_no_connect().
klaus,
i checked and i'm already calling set_forward_no_connect() when initial
request is forwarded to a tcp contact. however, it seems more tricky to
prevent useless tcp connection attempts for in-dialog requests. for
example, here the UA has gone away when presence server sends a notify
to it:
Dec 22 14:50:48 sip /usr/sbin/sip-proxy[3207]: INFO: Routing in-dialog NOTIFY
<sip:gmuodqxs@192.98.102.10:50279;transport=tcp> from <sip:jh@vm.test.fi> to
<sip:192.98.102.10:60550;transport=tcp>
Dec 22 14:50:48 sip /usr/sbin/sip-proxy[3207]: ERROR: <core> [tcp_main.c:2743]:
connect 192.98.102.10:60550 failed (RST) Connection refused
Dec 22 14:50:48 sip /usr/sbin/sip-proxy[3207]: ERROR: <core> [tcp_main.c:2753]:
192.98.102.10:60550: connect & send for 0xb2d1c490 failed: Connection refused (111)
Dec 22 14:50:48 sip /usr/sbin/sip-proxy[3207]: ERROR: tm [../../forward.h:169]: msg_send:
ERROR: tcp_send failed
Dec 22 14:50:48 sip /usr/sbin/sip-proxy[3207]: ERROR: tm [t_fwd.c:1382]: ERROR:
t_send_branch: sending request on branch 0 failed
Dec 22 14:50:48 sip /usr/sbin/sip-proxy[3207]: INFO: Failed to relay in-dialog request
NOTIFY <sip:gmuodqxs@192.98.102.10:50279;transport=tcp>
it does not seem like a good idea to call set_forward_no_connect() for
all in-dialog requests. for example, presence server might have been
restarted when in-dialog subscribe arrives to it and it would make sense
to for sr to try to setup a tcp session with presence server. same for
pstn gateways and other proxies.
-- juha