i have twinkle registered from behind nat over tcp and another sip phone
registered over udp using the same aor and q value. this aor is then
called by another sip phone and sr forks the invite:
Oct 28 17:58:37 localhost /usr/sbin/sip-proxy[28989]: INFO: Routing first INVITE to
<sip:foo@192.168.0.169:5074;transport=tcp> and
<<sip:JzlUogbN0_q5BaWAN1Zv@xx.xx.xx.xx>;q=0>
...
twinkle answers and sends 200 ok. 200 ok is received by the calling
phone, which then sends ack to twinkle via sr, the problem is that
twinkle never receives the ack. instead sr reports a tcp error:
Oct 28 17:58:46 localhost /usr/sbin/sip-proxy[28994]: INFO: Routing in-dialog ACK from
<sip:foo.bar@foo.bar> to <sip:foo@192.168.0.169:5074;transport=TCP>
Oct 28 17:58:46 lohi /usr/sbin/sip-proxy[28994]: WARNING: <core>
[tcp_main.c:1200]: WARNING: tcp_do_connect 192.168.0.169:5074: could not
find corresponding listening socket for 192.X.Y.2, using
default...
...
Oct 28 17:58:51 localhost /usr/sbin/sip-proxy[29140]: ERROR: <core>
[tcp_main.c:3747]: connect 192.168.0.169:5074 failed (timeout)
weird thing about the warning is that it mentions ip address 192.X.Y.2,
which is not any of the ip addresses sr has configured to listen at.
192.X.Y.2 is the ip address of eth0 of sr host, but sr is listening at
192.X.Y.10, which is address of interface eth0:1.
am i missing some magic from sr tcp config or what could be the reason
that sr is trying to find non-existing listening socket?
i do have wireshark capture of this if it helps.
-- juha