1 Jul
2010
1 Jul
'10
9:27 p.m.
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
1 Jul
1 Jul
10:34 p.m.
2010/7/1 Juha Heinanen <jh(a)tutpro.com>om>:
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(a)aliax.net>
10:41 p.m.
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
2 Jul
2 Jul
1:10 a.m.
2010/7/1 Juha Heinanen <jh(a)tutpro.com>om>:
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?
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(a)aliax.net>
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?
9:34 a.m.
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
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
1:55 p.m.
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
5257
days inactive
5258
days old
6 comments
3 participants
participants (3)
-
Andrei Pelinescu-Onciul -
Iñaki Baz Castillo -
Juha Heinanen