<br><br><div class="gmail_quote">On Wed, Nov 12, 2008 at 6:57 PM, Alex Balashov <span dir="ltr"><<a href="mailto:abalashov@evaristesys.com">abalashov@evaristesys.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 class="Ih2E3d">Steve Totaro wrote:<br>
<br>
> I believe that if you are speaking of code and Asterisk's implementation<br>
> of the SIP RFC it is already very borked in many many ways. I speak<br>
> from what I see in userspace, real-world, although, as I said, I am<br>
> going from memory and could be wrong.<br>
<br>
</div>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>
<div class="Ih2E3d"><br>
>> Also, I am curious - what is the definition of "LAN device" as you are<br>
>> using it here? Is it a network with 1) an RFC1918 address and 2) a<br>
>> network on which the system running Asterisk has a physical interface<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 aware<br>
> switches) of the OSI reference model. Call me old school but I got my<br>
> CCNA in the nineties.<br>
<br>
</div>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>
<div class="Ih2E3d"><br>
> "If so, what about other routed subnets also on a LAN?", sorry, I do not<br>
> understand what you are asking......<br>
<br>
</div>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>
<font color="#888888"><br>
--<br>
</font><div class="Ih2E3d">Alex Balashov<br>
Evariste Systems<br>
Web : <a href="http://www.evaristesys.com/" target="_blank">http://www.evaristesys.com/</a><br>
Tel : (+1) (678) 954-0670<br>
Direct : (+1) (678) 954-0671<br>
Mobile : (+1) (706) 338-8599<br>
<br>
</div><div><div></div></div></blockquote><div><br>Anyone more "senior" than Alex care to weigh in? <br><br>-- <br>Thanks,<br>Steve Totaro <br>+18887771888 (Toll Free)<br>+12409381212 (Cell)<br>+12024369784 (Skype)<br>
</div></div><br>