On Wed, Nov 12, 2008 at 7:58 PM, Tilghman Lesher < [EMAIL PROTECTED]> wrote:
> On Wednesday 12 November 2008 18:34:45 Steve Totaro wrote: > > On Wed, Nov 12, 2008 at 6:57 PM, Alex Balashov > <[EMAIL PROTECTED]>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)
_______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users