[sr-dev] why new tcp connection?
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
> 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
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
More information about the sr-dev