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

[Tilghman Lesher]

On Wednesday 12 November 2008 18:34:45 Steve Totaro wrote:
> 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?
>
> Anyone more "senior" than Alex care to weigh in?

I don't really see a need to.  He was right on the money, when he said that
nat=yes breaks the SIP specification, although it generally works to your
advantage to have it set.

While Asterisk's SIP implementation may be "buggy", "broken", or various other
words that you can dream up to describe that it's not strictly compliant, it
is, in fact, one of the most interoperable SIP stacks currently available.
Due to this distinction, it is by far the tool of choice for other SIP
implementers to use to distinguish just how interoperable their own products
are.  That says oodles about just how bad other implementations are and just
how good Asterisk's is, by comparison.  That may still not mean much in terms
of overall compliance, but it means a whole lot in terms of market position.
You should remember that next time you pooh-pooh Asterisk's SIP stack.

-- 
Tilghman