[asterisk-dev] STUN support in chan_sip revisited

[Klaus Darilion]

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. Is it to be assumed that all 
proxies (service providers) nowadays do NAT traversal?

>>> 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.

There are people operating Asterisk on a DSL line where daily IP address 
changes are familar.

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 and 
the proxy (service provider) should do NAT traversal.

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".

regards
Klaus