6 Nov
2009
6 Nov
'09
1:06 p.m.
On Nov 06, 2009 at 08:12, Juha Heinanen <jh(a)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@192.98.101.10:5074;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.
Andrei