[sr-dev] why new tcp connection?
klaus.mailinglists at pernau.at
Fri Nov 6 14:29:38 CET 2009
Personally I do not like the alias approach. IIRC correctly there were
some security issues with aliases (at least some time ago) and ser does
hand aliases a little bit different then described by IETF to avoid this
To solve the situation there are 2 other solutions:
1. in client
2. in server
The client learns the public socket during REGISTER (Via received+rport
in response) and changes its contact in REGISTER and INVITE messages to
the new one learned. This is for example what xlite and pjsip does. This
approach does not work if the client does not register - if it only
sends INVITE then there is no learned socket available in the initial
I use the pragmatic, and well working UDP approach. Just call
fix_nated_contact/register also for TCP clients. I never had any issues
Juha Heinanen schrieb:
> 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: INFO: Routing first INVITE to <sip:jh_test_fi at 126.96.36.199:5074;transport=tcp> and <<null>>
> Nov 6 07:16:21 localhost /usr/sbin/sip-proxy: 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
> 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?
> -- juha
> sr-dev mailing list
> sr-dev at lists.sip-router.org
More information about the sr-dev