6 nov 2009 kl. 14.54 skrev Klaus Darilion:
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:
in client
in server
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:
- REGISTER with local socket
- 407
- REGISTER with local socket
- 200 ok (learn public socket)
- deREGISTER local socket
- 200 ok
- REGISTER with public socket
- 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 INVITE.
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.
SIP-outbound for when NAT is involved and connection-reuse drafts (that Andrei referred to earlier) for when there's no NAT, like between two sip proxys on the public Internet or a local network.
And in addition, there's a lot of work done for TCP/TLS that makes it even more complicated. If you opened a connection to a proxy for berlin.example.com and approved the server certificate and then realize that you're about to set up a new connection to the same proxy, but now for stockholm.example.com - you're not allowed to reuse the first connection.
/O