[asterisk-dev] STUN support in chan_sip revisited

[Simon Perreault]

On 2010-08-09 04:35, Klaus Darilion wrote:
> 
> Am 06.08.2010 17:09, schrieb 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?
> 
> Only if the proxy performs NAT traversal.

This is not true. STUN-based NAT traversal works when at least one peer
is not behind such a restrictive NAT. TURN-based NAT traversal always
works and does not rely on the service provider.

Therefore, being behind a symmetric NAT doesn't imply that VoIP will not
work. It depends on:
- is the peer also behind a symmetric NAT?
- do you have access to a TURN server (or other relay)?

>>>> 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.
> 
> There are people operating Asterisk on a DSL line where daily IP address 
> changes are familar.

Ah I understand what you mean. See my response to David Vossel on this
particular issue.

> Based on your arguments I see the following conclusion (Asterisk as 
> client): Asterisk should use STUN for SIP only as a keep-alive when 
> using UDP and RFC 5626 is supported by the server. For RTP, STUN should 
> be used as part of ICE. In all other cases STUN should not be used

Right.

> and the proxy (service provider) should do NAT traversal.

No. In this discussion, I only care about Asterisk. It would be futile
to impose constraints on the service provider.

> I would see one more scenario where Asterisk behaves client like, but 
> does not REGISTER to a proxy - e.g. Asterisk behind NAT as an autonomous 
> PBX which accept calls from everywhere (e.g. ENUM, Dundi ...). In this 
> case usually the NAT device is configured with static port forwarding. 
> This can be solved with "externip", or if the IP address of the NAT 
> router is dynamic we need "externhost" or still "stunaddr".

Yes. The core difference is that we control the NAT device. This opens
up many more possibilities. I'm not sure that I personally would use
STUN in this case, but it's not as problematic when we control the network.

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