[sr-dev] why new tcp connection?

[Iñaki Baz Castillo]

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 at aliax.net>