On Jul 01, 2010 at 21:27, Juha Heinanen jh@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