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