2 Jul
2010
2 Jul
'10
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