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

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

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