[asterisk-users] Why Nat=yes Nat=no Option?
stotaro at totarotechnologies.com
Wed Nov 12 18:34:45 CST 2008
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
> >> 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
> >> 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?
+18887771888 (Toll Free)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the asterisk-users