6 Nov
2009
6 Nov
'09
7:09 p.m.
El Viernes, 6 de Noviembre de 2009, Klaus Darilion escribió:
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.
Could I know about those security issues? (just a brief description).
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
What about if the server doesn't challenge the client? XDD
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.
If the client doesn't register then it cannot receive responses anyway.
However, the fact is that during a TCP dialog there "should" exist *two* TCP
connections (assuming binding port = 5060):
a) UA:random_port - Proxy:5060
b) Proxy:random_port - UA:5060
If UA initiates the dialog the connection a) is created.
If Proxy sends an in-dialog request the connection b) is created.
Of course b) is not created when using "alias" or forcing the proxy to reuse
the connection established by UA (server solution).
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.
Neither me, but it could fail if some UA doesn't allow that (never seen it
however).
Regards.
--
Iñaki Baz Castillo <ibc(a)aliax.net>