6 Nov
2009
6 Nov
'09
6:59 p.m.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev