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

[Steve Totaro]

On Thu, Nov 13, 2008 at 12:19 PM, Alex Balashov
<abalashov at evaristesys.com>wrote:

> 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.
>

What is Asterisk designed to be?  A PBX. (yes that is a period)


>
> -- 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
>

Yes, if I want to read a book, I do, this is a mailing list so I really
didn't read much of what you said above, if you cannot get to the point in a
few lines within a few paragraphs, you are wasting my time....

Not sure why you feel like you need to correct me so badly or

Who I have attacked?  I take exception to this statement.  That is the only
clarification I request from you, no book needed.

Sounds personal, let it go, it failed, but I washed my hands of it long
ago.....

--
Thanks,
Steve Totaro
+18887771888 (Toll Free)
+12409381212 (Cell)
+12024369784 (Skype)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20081113/65eb6f1d/attachment.htm