[sr-dev] why new tcp connection?

[Olle E. Johansson]

6 nov 2009 kl. 14.39 skrev 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).
>
Imaging having TLS. The B connection would not work unless we had a  
valid certificate in the UA.

For TLS each TCP connection needs a property on when it's allowed to  
reuse.

/O