[sr-dev] why new tcp connection?

Andrei Pelinescu-Onciul andrei at iptel.org
Fri Nov 6 08:36:54 CET 2009

On Nov 06, 2009 at 08:12, Juha Heinanen <jh at tutpro.com> wrote:
> i started to test the latest sr_3.0 that includes andrei's tcp/socket
> related changes.
> twinkle is registered over tcp to sr using source port 59056 destination
> port 5060.  in contact uri twinkle has put port 5074 (i need to configure
> some fixed port there).
> when another ua calls twinkle and i see this in syslog:
> Nov  6 07:16:21 localhost /usr/sbin/sip-proxy[30133]: INFO: Routing first INVITE to <sip:jh_test_fi at;transport=tcp> and <<null>>
> Nov  6 07:16:21 localhost /usr/sbin/sip-proxy[30133]: INFO: <core> [tcp_main.c:1928]: tcp_send: quick connect for 0xb54f3e60
> when i look wireshark output, i see that sr has created a new tcp
> connection to twinkle at port 5074 even when there is already is one, but
> not to that port.
> is this twinkle's fault, i.e., should it put in contact uri port 59056
> instead?

Yes, it should do either that, or add an alias parameter to its Via
(assuming that the port in Via _is_ 5074).
If it does add "alias" to the Via, make sure you have
tcp_accept_aliases=yes in the config.

> or should sr figure out that twinkle in fact is behind the tcp
> connection it created when it registered itself no matter what the port in
> contact uri is?

You can force that, using force_tcp_alias() (adds src_ip:port_in_via as
an alias for src_ip:src_port).
If the port in Via is not 5074 then you can work around that too, using
force_tcp_alias(5074) (based maybe on looking at the contact?), but in
this case it's better to reconfigure/fix twinkle.

In general, especially if you have NATed UACs, it's better to always have
force_tcp_alias() in the config. It will cause problems only if you have
 non-NATed broken UACs that don't expect/support symmetric signalling
 over TCP (e.g. open a new connection for each new request and expect
 only replies to that request on the connection).
OTOH if you  don't force_tcp_alias() and the UACs don't add alias to the
Via, it's a very slim chance that NATed UACs will work over tcp.

BTW: this is not a change introduced by my recent tcp
force_send_socket() change. This is the way tcp always worked.
The force_send_socket() change forces the ip of the forced socket. The
difference from k behaviour is that k did that only when opening a new
connection (if an existing connection did exist albeit with a different
src_ip, it would have been used) while sr will reuse a connection only
if the src_ip matches with that of the forced socket.


More information about the sr-dev mailing list