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