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

[Steve Totaro]

On Wed, Nov 12, 2008 at 7:58 PM, Tilghman Lesher <
tilghman at mail.jeffandtilghman.com> wrote:

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

When does it not was the original question?


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


Citation needed.


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


Citation needed.


>
> You should remember that next time you pooh-pooh Asterisk's SIP stack.
>

Stating it is not compliant is not "pooh-pooh"ing Asterisk's SIP stack, it
is stating a fact.  Taking a bit personal aren't you?

I have no issue with it for the most part.  What happened to Olle?  He might
pooh-pooh it, but not I.

I will pooh-pooh IAX2 all day long, however.....


>
> --
> Tilghman
>
>
-- 
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/071f7345/attachment.htm