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? -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 _______________________________________________ -- 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