Hi Juha!
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 issues.
To solve the situation there are 2 other solutions: 1. in client 2. in server
1. client: 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 INVITE.
2. server I use the pragmatic, and well working UDP approach. Just call fix_nated_contact/register also for TCP clients. I never had any issues with that.
regards klaus
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[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?
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev