[sr-dev] tcp problem

Klaus Darilion klaus.mailinglists at pernau.at
Thu Oct 29 08:16:01 CET 2009


Long time ago, ser always used the OS default interface for new TCP 
connections. In Openser this was changed to the first listening TCP 
address, and further could be specified by force_send_socket.

I know there were some changes in ser/sr too, but do not know exactly 
what was changed.

btw: another strange thing is that sr even tries to open a new TCP 
connection. There should be already a TCP connection opened to Twinkle - 
do you call fix_nated_contact() on the 200 OK from Twinkle?

regards
klaus

Juha Heinanen schrieb:
> 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 at 192.168.0.169:5074;transport=tcp> and <<sip:JzlUogbN0_q5BaWAN1Zv at 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 at foo.bar> to <sip:foo at 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
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev



More information about the sr-dev mailing list