7 Nov
2009
7 Nov
'09
7:06 p.m.
6 nov 2009 kl. 14.54 skrev Klaus Darilion:
Iñaki Baz Castillo schrieb:
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 :-)
e.g. call-setup would work, but BYE from callee would fail.
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
El Viernes, 6 de Noviembre de 2009, Klaus
Darilion escribió:
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.
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
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.