[sr-dev] why new tcp connection?

Klaus Darilion klaus.mailinglists at pernau.at
Fri Nov 6 14:54:43 CET 2009

Iñaki Baz Castillo schrieb:
> 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).

I do not remember anymore in detail, but I think by spoofing aliases 
(and the proxy accepts the spoofed alias) it could be possible to 
intercept SIP messages which are targeted to another user/client behind 
the same NAT.

>> 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

No problem - at least for xlite. It does:
1. REGISTER with local socket
2. 407
3. REGISTER with local socket
4. 200 ok (learn public socket)
5. deREGISTER local socket
6. 200 ok
7. REGISTER with public socket
8. 200 ok

I do not know how pjsip handles this (if it is smarter :-)

>> 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
> If the client doesn't register then it cannot receive responses anyway.

e.g. call-setup would work, but BYE from callee would fail.

> 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

that's the broken idea of RFC 3261. In fact that will never work due to 
NAT/FW. The un-standardized approaches are described above and work 
well. The standardized approach would be sip-outbound, which gives the 
same result than the un-standardized approach.


> 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.

More information about the sr-dev mailing list