<br><br><div class="gmail_quote">On Wed, Nov 12, 2008 at 7:58 PM, Tilghman Lesher <span dir="ltr"><<a href="mailto:tilghman@mail.jeffandtilghman.com">tilghman@mail.jeffandtilghman.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c">On Wednesday 12 November 2008 18:34:45 Steve Totaro wrote:<br>
> On Wed, Nov 12, 2008 at 6:57 PM, Alex Balashov<br>
<<a href="mailto:abalashov@evaristesys.com">abalashov@evaristesys.com</a>>wrote:<br>
> > Steve Totaro wrote:<br>
> > > I believe that if you are speaking of code and Asterisk's<br>
> > > implementation of the SIP RFC it is already very borked in many many<br>
> > > ways. I speak from what I see in userspace, real-world, although, as I<br>
> > > said, I am going from memory and could be wrong.<br>
> ><br>
> > Yeah, I know. But deciding whether to elevate a hack to default<br>
> > behaviour status is a question that cannot be governed purely by<br>
> > someone's perceived "real-world" use cases, because not all use cases<br>
> > are universal. That's typically not how questions of standards<br>
> > compliance (alleged existing noncompliance therewith by Asterisk<br>
> > notwithstanding) are settled.<br>
> ><br>
> > If we did things this way, we would constantly be arguing about whose<br>
> > "real-world" is more "real" or more "importantly" real than the others'.<br>
> ><br>
> > For instance, there are a variety of setups that your suggested approach<br>
> > would break, uncommon as they may be. What if the requests come from an<br>
> > internal subnet fronted by a NAT device but to which the Asterisk host<br>
> > also has a direct route that the return path or the media path should<br>
> > take? Or what if the user agents are configured for near-end NAT<br>
> > traversal fixups (sort of like Asterisk's 'externip' option) for which<br>
> > overriding them to the received IP information would present problems?<br>
> ><br>
> > I realise that's probably not the sort of thing you see in the<br>
> > deployments you are leveraging as part of the claim to "real world"<br>
> > insight, but the point is that many people reside in many different<br>
> > kinds of "real world." Default configuration options should implement<br>
> > standard behaviour as much as possible. If I am a new user of Asterisk<br>
> > unfamiliar with the 'nat' option, I shouldn't have to explicitly set it<br>
> > to 'no' (because the default behaviour is 'yes') in order to get<br>
> > Asterisk to behave in a more standards-compliant way; it should be the<br>
> > other way around. The package shouldn't come with a hack enabled<br>
> > out-of-the-box. The standards are the reasonable, pragmatic departure<br>
> > point for the common denominator, and the standards say that Contact<br>
> > URIs and SDP endpoint attributes are to be believed and mandatorily used.<br>
> ><br>
> > >> Also, I am curious - what is the definition of "LAN device" as you<br>
> ><br>
> > are<br>
> ><br>
> > >> using it here? Is it a network with 1) an RFC1918 address and 2)<br>
> > >> a network on which the system running Asterisk has a physical<br>
> ><br>
> > interface<br>
> ><br>
> > >> binding? If so, what about other routed subnets also on a LAN?<br>
> > ><br>
> > > I define a LAN based on layer 2 and more recently layer 3 (layer 3<br>
> > > aware switches) of the OSI reference model. Call me old school but I<br>
> > > got my CCNA in the nineties.<br>
> ><br>
> > I know how you define a LAN; it's how I'd define a LAN too.<br>
> ><br>
> > Asterisk, however, is not Layer 2-aware, so the question is how IT<br>
> > defines a LAN. If, hypothetically, the behaviour you suggested (nat=yes<br>
> > behaviour is not applied to requests originating from LAN endpoints),<br>
> > then Asterisk would have to know that the source address is a LAN<br>
> > address. How? What are the criteria?<br>
> ><br>
> > > "If so, what about other routed subnets also on a LAN?", sorry, I do<br>
> > > not understand what you are asking......<br>
> ><br>
> > It's related to the above. In other words, perhaps Asterisk can<br>
> > conceivably know if a request originated from a LAN address if it comes<br>
> > from the subnet of one of the host's IP interfaces and is off a private<br>
> > range, but what if the address is off a private range but not on a<br>
> > subnet to which the Asterisk host is directly connected. Is it a LAN<br>
> > endpoint then?<br>
><br>
</div></div><div class="Ih2E3d">> Anyone more "senior" than Alex care to weigh in?<br>
<br>
</div>I don't really see a need to. He was right on the money, when he said that<br>
nat=yes breaks the SIP specification, although it generally works to your<br>
advantage to have it set.<br>
</blockquote><div><br>When does it not was the original question?<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
While Asterisk's SIP implementation may be "buggy", "broken", or various other<br>
words that you can dream up to describe that it's not strictly compliant, it<br>
is, in fact, one of the most interoperable SIP stacks currently available.<br>
Due to this distinction, it is by far the tool of choice for other SIP<br>
implementers to use to distinguish just how interoperable their own products<br>
are. </blockquote><div><br>Citation needed.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">That says oodles about just how bad other implementations are and just<br>
how good Asterisk's is, by comparison. That may still not mean much in terms<br>
of overall compliance, but it means a whole lot in terms of market position.</blockquote><div><br>Citation needed.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
You should remember that next time you pooh-pooh Asterisk's SIP stack.<br>
</blockquote><div><br>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? <br><br>I have no issue with it for the most part. What happened to Olle? He might pooh-pooh it, but not I.<br>
<br>I will pooh-pooh IAX2 all day long, however.....<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
--<br>
<font color="#888888">Tilghman<br>
</font><div><div></div><div class="Wj3C7c"><br></div></div></blockquote><div><br></div></div>-- <br>Thanks,<br>Steve Totaro <br>+18887771888 (Toll Free)<br>+12409381212 (Cell)<br>+12024369784 (Skype)<br>