[asterisk-users] Why Nat=yes Nat=no Option?

[Alex Balashov]

Steve Totaro wrote:

> I believe that if you are speaking of code and Asterisk's implementation 
> of the SIP RFC it is already very borked in many many ways.  I speak 
> from what I see in userspace, real-world, although, as I said, I am 
> going from memory and could be wrong.

Yeah, I know.  But deciding whether to elevate a hack to default 
behaviour status is a question that cannot be governed purely by 
someone's perceived "real-world" use cases, because not all use cases 
are universal.  That's typically not how questions of standards 
compliance (alleged existing noncompliance therewith by Asterisk 
notwithstanding) are settled.

If we did things this way, we would constantly be arguing about whose 
"real-world" is more "real" or more "importantly" real than the others'.

For instance, there are a variety of setups that your suggested approach 
would break, uncommon as they may be.  What if the requests come from an 
internal subnet fronted by a NAT device but to which the Asterisk host 
also has a direct route that the return path or the media path should 
take?  Or what if the user agents are configured for near-end NAT 
traversal fixups (sort of like Asterisk's 'externip' option) for which 
overriding them to the received IP information would present problems?

I realise that's probably not the sort of thing you see in the 
deployments you are leveraging as part of the claim to "real world" 
insight, but the point is that many people reside in many different 
kinds of "real world."  Default configuration options should implement 
standard behaviour as much as possible.  If I am a new user of Asterisk 
unfamiliar with the 'nat' option, I shouldn't have to explicitly set it 
to 'no' (because the default behaviour is 'yes') in order to get 
Asterisk to behave in a more standards-compliant way;  it should be the 
other way around.  The package shouldn't come with a hack enabled 
out-of-the-box.  The standards are the reasonable, pragmatic departure 
point for the common denominator, and the standards say that Contact 
URIs and SDP endpoint attributes are to be believed and mandatorily used.

>>     Also, I am curious - what is the definition of "LAN device" as you are
>>     using it here?  Is it a network with 1) an RFC1918 address and 2) a
>>     network on which the system running Asterisk has a physical interface
>>     binding?  If so, what about other routed subnets also on a LAN?
>  
> I define a LAN based on layer 2 and more recently layer 3 (layer 3 aware 
> switches) of the OSI reference model.  Call me old school but I got my 
> CCNA in the nineties. 

I know how you define a LAN;  it's how I'd define a LAN too.

Asterisk, however, is not Layer 2-aware, so the question is how IT 
defines a LAN.  If, hypothetically, the behaviour you suggested (nat=yes 
behaviour is not applied to requests originating from LAN endpoints), 
then Asterisk would have to know that the source address is a LAN 
address.  How?  What are the criteria?

> "If so, what about other routed subnets also on a LAN?", sorry, I do not 
> understand what you are asking......

It's related to the above.  In other words, perhaps Asterisk can 
conceivably know if a request originated from a LAN address if it comes 
from the subnet of one of the host's IP interfaces and is off a private 
range, but what if the address is off a private range but not on a 
subnet to which the Asterisk host is directly connected.  Is it a LAN 
endpoint then?

-- 
Alex Balashov
Evariste Systems
Web    : http://www.evaristesys.com/
Tel    : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599