10 Jun
2008
10 Jun
'08
7:02 p.m.
On Tue, 10 Jun 2008, Iñaki Baz Castillo wrote:
El Tuesday 10 June 2008 13:59:42 Aymeric Moizard
escribió:
Right.
1-> I'm talking about SIP and contact management. (not about RTP). In this
case, the STUN server must be on the same socket as the SIP server. This
is planned in 'outbound' draft from ietf.
2-> As you said, for RTP there is no working easy solution. Only ICE
and TURN can help.
Stun can work even behind symmetric NAT if the
stun server was
running on the same socket the SIP server is running... I hope
this feature will come soon!
Sure? AFAIK a symmetric NAT not only depends on the destination IP but
also on the port. So unless you have a STUN server listening in all the
ports available for RTP proxing you don't know if STUN will work. Also, clients implementing STUN will refuse using STUN
if they discover
they are behind symmetric NAT. The STUN server needs 2 public IP's so
probably each one will see a different public source port from the NAT
router. In this case STUN will report "Symmetric NAT" so the client will
not trust it.
For example Twinkle or Ekiga don't use STUN if STUN discovers they are
behind symmetric NAT.
There is no such standard: may be they are doing this way, but I don't...
Mybe I'm forgotting something? :)
I don't think you are! Except this:
It is not possible to know wether a NAT will always behave as you have
detected. For example, short testing usually show that basic iptables
is port restricted cone nat while it turns into a symmetric 50% of the
time...
STUN is only a protocol to help: my *own* opinion is that it's not because
you detect a full cone nat that it will behave as a full cone nat for
the voip call...
tks,
Aymeric MOIZARD / ANTISIP
amsip - http://www.antisip.com
osip2 - http://www.osip.org
eXosip2 - http://savannah.nongnu.org/projects/exosip/
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
_______________________________________________
Users mailing list
Users(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users