[asterisk-dev] STUN support in chan_sip revisited

[Simon Perreault]

On 2010-08-06 04:31, Klaus Darilion wrote:
>> 5. Ignoring TCP, the NAT device may assign a different address/port when
>> we are talking to the STUN server than when we are talking to the remote
>> SIP device. Using terminology defined in RFC 4787, such a NAT device
>> would exhibit Address-Depend or Address and Port-Dependent mapping
>> behaviour.
> 
> Is this what we usually just call "symmetric NAT"?

Not necessarily.

> This can be detected by Asterisk by sending multiple STUN requests to 
> the various IP addresses and ports offered by the STUN server.

Current STUN servers usually listen only on a single IP address and
port. The requirement that STUN servers listen on two addresses has been
dropped in RFC 5389. And this is a feature. Discovering a NAT device's
behaviour is bound to fail. (For example, some NAT devices' behaviour
changes according to their load. Try to discover that.)

> But how 
> should Asterisk react in such a case? IMO it should log warnings and use 
> the local IP address in requests.

Correct usage of STUN succeeds even behind symmetric NATs.

> Further it would be cool to get the STUN results on the console, e.g:
>  > stun show status
> STUN server: 1.2.3.4:5678
> last STUN request: 23:00:59 2010-08-10
> next STUN request: 23:01:14 2010-08-10
> detected STUN type: Address-Depend or Address and Port-Dependent mapping

It would be very wrong to try to discover the NAT device's behaviour
using STUN.

> external SIP UDP address: 5.6.7.8:64344
> external SIP address used for mapping: no
> 
>> 6. The address obtained from the STUN server (the Server-Reflexive
>> Address) may not be usable for reaching us by the remote SIP device,
>> depending on characteristics of the NAT device. Assuming
>> Endpoint-Independent mapping behaviour (so that issue 5 does not apply),
>> a NAT device with Address-Dependent or Address and Port-Dependent
>> filtering behaviour would discard packets sent from the remote SIP
>> device to the address learned using STUN.
> 
> Is this a practical scenario? How will the remote SIP device know the 
> public IP address? Because the client sent a REGISTER (or any other SIP 
> request) first, thus opening the pin-hole in the NAT for the reverse 
> direction.

Remember, Asterisk is the one behind the NAT device here. I don't
understand your question. Which client are you talking about?

>> 7. This usage is non-standard. It is Asterisk-specific, and it has
>> issues. As an example, devices behind the same NAT device could not
>> speak to each other if the NAT device does not support hairpinning.
>> Correct STUN usage for SIP is documented in RFC 5626 while correct STUN
>> usage for RTP/RTCP is documented in RFC 5245.
> 
> RFC 5626 describes how the client and the server can traverse the NAT in 
> case of both support RFC 5626. If the Asterisk as client behind supports 
> 5626, but the server does not support it, then 5626 is useless for 
> Asterisk

Right.

> and it still has to follow old-style STUN based NAT traversal 
> with replacing of IP addresses in the SIP messages.

I disagree. What has been documented here is not "old-style STUN". It is
Asterisk-specific, non-standard STUN usage.

> Thus, yes RFC 5626 would be nice, but it is useless if only the client 
> supports it.

Of course. Just like implementing SIP itself would be useless unless you
have a SIP peer to talk to.

This kind of reasoning leads nowhere.

>>> Forgetting how Asterisk does STUN support in chan_sip all together.
>>> How do you expect/want STUN support to work in relation to chan_sip?
>>
>> :)
>>
>> My answer would be: a full implementation of RFC 5626 and RFC 5245.
> 
> and the old-style STUN based NAT traversal for cases where the server 
> does not support RFC 5626 and 5245.

I think this is actually harmful. It adds nothing to what is currently
deployed, i.e. server-based NAT traversal (latching). And it may in fact
create issues when e.g. talking to clients behind the same NAT device or
when the NAT device doesn't exhibit Endpoint-Independent mapping and
filtering behaviour. Both examples are fairly common.

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