2 Jul
2010
2 Jul
'10
11:18 a.m.
On Jul 01, 2010 at 21:27, Juha Heinanen <jh(a)tutpro.com> wrote:
i have noticed that after i restart sip router, it
does not immediately
try to do tcp quick connect when it relays request over tcp.
after restarting sr, i start twinkle and relaying over tcp fails:
Jul 1 21:19:53 localhost /usr/sbin/sip-proxy[24197]: INFO: Routing initial SUBSCRIBE
<sip:jh@vm.test.fi> to <sip:127.0.0.1:5082;transport=tcp>
Jul 1 21:19:53 localhost /usr/sbin/sip-proxy[24197]: INFO: t_relay failed with result
-1
Jul 1 21:19:53 localhost /usr/sbin/sip-proxy[24197]: INFO: Routing initial PUBLISH
<sip:jh@test.fi> to <sip:127.0.0.1:5082;transport=tcp>
Jul 1 21:19:53 localhost /usr/sbin/sip-proxy[24197]: INFO: t_relay failed with result
-1
then i restarted twinkle and quick connect was correctly done:
Jul 1 21:20:23 localhost /usr/sbin/sip-proxy[24199]: INFO: Routing initial SUBSCRIBE
<sip:jh@vm.test.fi> to <sip:127.0.0.1:5082;transport=tcp>
Jul 1 21:20:23 localhost /usr/sbin/sip-proxy[24199]: INFO: <core>
[tcp_main.c:1926]: tcp_send: quick connect for 0xb4e70878
why is quick connect not done reliably?
My guess is that is something else that prevents even trying to forward
the first time (e.g. blacklisted destination, onsend_route).
What reply does it send back?
A dump of the tcp traffic and runnning with a high debug level will also
help finding out what's happening.
Last but not least: sercmd dst_blacklist.view
Regarding "quick connect" note that this message appears only when a
connect() finishes immediately and the following send() is able to
send all the data. This happens mostly on localhost or fast local
networks. In general the connect() will not complete so fast and the
data will be queued for sending later (after the connection is
established).
Even on localhost, you might not see this message always.
Andrei