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

[Steve Totaro]

On Wed, Nov 12, 2008 at 6:57 PM, Alex Balashov <abalashov at evaristesys.com>wrote:

> 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
>
>
Anyone more "senior" than Alex care to weigh in?

-- 
Thanks,
Steve Totaro
+18887771888 (Toll Free)
+12409381212 (Cell)
+12024369784 (Skype)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20081112/16ae5fc0/attachment.htm