[asterisk-dev] STUN support in chan_sip revisited

[Simon Perreault]

On 2010-08-06 10:54, Klaus Darilion wrote:
> having Asterisk saying "this is a symmetric NAT, VoIP
> will not work" is IMO a useful option to help users with NAT traversal.

Even though VoIP might very well work?

>> The better approach is to be agnostic to the type of NAT. Just try to
>> traverse it using all possible ways, and see what works. Dynamically
>> pick the best alternative.
> 
> Pick the best alternative based on what?

Based on trying them all. That's the idea behind ICE. You tell your
peer: "I have these adddresses assigned to me, and I obtained this
address from STUN, and I allocated this address on a TURN relay, and I
opened these ports using UPnP/NAT-PMP, and I have this address on a VPN,
etc. Try them all, I'll tell you when I hear from you on one of them."

>> Note also that keep-alive can be done with pure SIP. This has the
>> advantage that the peer doesn't need to support STUN. See RFC 5626
>> section 3.5.1.
> 
> Of course, yes. But using STUN would also detect changes of the public IP.

It cannot change while it is being kept alive. Once a NAT binding is
opened, the 5-tuple is fixed. Unless the NAT device reboots, in which
case we're screwed anyway.

> What is the standard STUN usage that works? RFC 5626? How long will it
> take until all SIP proxies/registrars deployed will be updated to
> support RFC 5626?

Yes, SIP-outbound and ICE. The deployment time is irrelevant. When
you're talking to a peer that supports it, you use it. Otherwise, you
don't. You just cannot start using STUN in a broken way and expect
everything to be rosy. It's going to help in some circumstances, but
it's going to be really broken in others. And you'll be trying to
outsmart the server, which is not a good thing to do.

>> Working with servers that do not support SIP-outbound and/or ICE is
>> simple: don't do anything. It is up to these servers to do their thing
>> (i.e. latching). If they don't do any of that, then they can't
>> reasonably expect to work with clients behind NATs.
> 
> Is this the IETF approach? Non-RFC5626 compatible servers are
> responsible for NAT traversal?

Of course not!

> That would be great - then we could drop "old style" STUN from all
> clients immediately.

I repeat, what I being described here is not "old style STUN". It is
Asterisk-specific. Clients generally do not take the results from STUN
and stick them in SIP headers.

My point is that Asterisk should not do non-standard STUN.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org