[asterisk-users] Why Nat=yes Nat=no Option?

[Alex Balashov]

Steve Totaro wrote:

> Alex is going to cling to to the RFC as if it were the gospel, and not 
> look at what would essentially be a "good thing".  

The RFC is not "the gospel," but nor is it just a "request for comment," 
historical nomenclature aside.

It is the de facto standard for the implementation of the protocol, the 
product of IETF working groups, various standards bodies, and private 
and academic industry consortia.  It is essential for interoperability 
and is the source of the justification for the appeal to "sameness" in 
the claim that two elements or services speak the "same" protocol.

Inconsistencies, omissions, or deviations from the standard in 
implementations do not materially undermine this point.  Nothing is 
perfect, including the RFC itself, which is replete with ambiguities 
open to interpretation and disagreements about those interpretations. 
However, it does provide the anchor for essential adherence, especially 
when it comes to points that are spelled out clearly (i.e. the basic 
purpose and function of registration and contact bindings) as opposed to 
more marginal scenarios.

Do I really have to explain why it is important to follow the RFC when 
implementing an IETF protocol?

One thing you need to appreciate is that when you are recommending 
changes to default settings, you are engaging in a kind of standards 
work.  That's because the potential implications apply to everyone.  In 
light of that, I find it bizarre that you solicit "input" on your 
suggestion but then proceed to personally attack those who disagree, 
especially with arguments proceeding from standards.

> Making many NAT questions drop off IRC and and the list.  Making 
> administration and system deployments "Just Work".

More precisely, make administration and system deployments that are 
readily conceptualised in _your_ imagination and experience "just work."

The behaviour you are suggesting would break any number of other 
scenarios common in the engineering of VoIP service delivery platforms.

You are making a claim from the standpoint of someone who goes around 
installing phones that transact directly with an Asterisk PBX, and you 
are attempting to universalise your use case as though it were 
cosmologically significant.  That is just one of the many scenarios in 
which SIP is used, and certainly only one of the manifold applications 
of Asterisk's SIP stack, in theory and in practice.  What is important 
to phone installers isn't what matters to others.

When recommending changes to standard behaviour, you have to argue in 
reasonable terms and contend with valid arguments rather than just 
dismissing them.  I suppose we should be grateful that standards bodies 
for the most part consist of people considerably more judicious and 
insightful than that.

The RFC provides an architectural model for how SIP works, and if you're 
going to suggest changes to an implementation of that model, it's 
important to understand what the model actually is on a level of 
abstraction that may considerably surpass your narrowminded assumptions 
based on your own use.  The world of SIP entails considerably more 
complexity than phones and PBXs.

-- Alex

-- 
Alex Balashov
Evariste Systems
Web    : http://www.evaristesys.com/
Tel    : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599