tcp quick connect is not done reliably
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? -- juha
2010/7/1 Juha Heinanen <jh@tutpro.com>:
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?
Isn't a bug in Twinle (even if I realized of it using Twinkle and K 1.5 with SIP TCP)? This is: what is the TCP difference between the SUBSCRIBE sent by Twinkle before and after restarting it? -- Iñaki Baz Castillo <ibc@aliax.net>
Iñaki Baz Castillo writes:
Isn't a bug in Twinle (even if I realized of it using Twinkle and K 1.5 with SIP TCP)? This is: what is the TCP difference between the SUBSCRIBE sent by Twinkle before and after restarting it?
inaki, i didn't understand your reply. the quick connect is done to a fixed tcp address by sip proxy when it forwards subscribe to presence server. how can initial subscriber sent by twinkle to sip proxy affect it? -=- juha
2010/7/1 Juha Heinanen <jh@tutpro.com>:
Iñaki Baz Castillo writes:
Isn't a bug in Twinle (even if I realized of it using Twinkle and K 1.5 with SIP TCP)? This is: what is the TCP difference between the SUBSCRIBE sent by Twinkle before and after restarting it?
inaki,
i didn't understand your reply. the quick connect is done to a fixed tcp address by sip proxy when it forwards subscribe to presence server. how can initial subscriber sent by twinkle to sip proxy affect it?
Ok, I didn't know your scenario correctly, but neither now: So Twinkle uses TCP to connect to the proxy and the proxy uses TCP to connect to the presence server, am I right? And you say that, in case of restarting the *proxy* an in-dialog SUBSCRIBE from twinkle doesn't arrive to the presence server due to the error you showed, am I right? Regards. -- Iñaki Baz Castillo <ibc@aliax.net>
Iñaki Baz Castillo writes:
Ok, I didn't know your scenario correctly, but neither now:
So Twinkle uses TCP to connect to the proxy and the proxy uses TCP to connect to the presence server, am I right?
yes, the idea is that proxy forwards request to presence server using the same transport that the ua used to send the request to proxy. this is to avoid extra rr header.
And you say that, in case of restarting the *proxy* an in-dialog SUBSCRIBE from twinkle doesn't arrive to the presence server due to the error you showed, am I right?
no, it is initial subscribe in all cases like my first mail on this topic showed: 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 at 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 at 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 (30 seconds later) 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 at 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 i'm not sure if t_relay in the first two sub/pub requests failed because tcp quick connect failed or for some other reason. -- juha
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
Andrei Pelinescu-Onciul writes:
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?
there is no blacklists in the config, neither onsend_route.
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
i'll come back when i'm able to reproduce this at will. i have noticed it a few times, but it does not happen every time when i restart sr.
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).
the problem has occurred on localhost (destination address 127.0.0.1:5082). -- juha
participants (3)
-
Andrei Pelinescu-Onciul -
Iñaki Baz Castillo -
Juha Heinanen