<br><br><div class="gmail_quote">On Thu, Nov 13, 2008 at 10:19 AM, 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">Alex Balashov wrote:<br>
> Klaus Darilion wrote:<br>
><br>
>> Actually I would nat=yes always, even if clients are not behind NAT os<br>
>> otherwise the clietn can put some garbage into the contact header (e.g.<br>
>> IP address of an upstream provider) and influence routing.<br>
><br>
> No. There is a specific reason RFC 3261 says:<br>
><br>
> "Registration creates bindings in a location service for a particular<br>
> domain that associates an address-of-record URI with one or more<br>
> contact addresses. Thus, when a proxy for that domain receives a<br>
> request whose Request-URI matches the address-of-record, the proxy<br>
> will forward the request to the contact addresses registered to that<br>
> address-of-record."<br>
><br>
> This gives the UAC the necessary level of control to determine how it is<br>
> to be contacted.<br>
><br>
> Imagine, for a example, a scenario in which incoming registrations are<br>
> proxied further upstream for whatever reason - load balancer/distributor<br>
> perhaps? - by an intermediate element. Do you really want to use that<br>
> proximate hop's received IP address in place of the ultimate sending<br>
> UAC's domain?<br>
<br>
</div>In other words, there is a very specific reason why UACs are given the<br>
power to determine where and how to be contacted by the locator,<br>
depending on the application.<br>
<br>
If the UAS wishes to restrict the ability of registrants to specify a<br>
contact URI domain that does not match their received IP, or to<br>
overwrite it with something else, it can do that. Those are<br>
configuration options that can be created with Asterisk. But to enable<br>
standards-breaking behaviour by default (let alone always) is absurd;<br>
there very point of specifying a contact binding in registrations is to<br>
provide the very control and flexibility you are suggesting should be<br>
taken away.<br>
<div><div></div><div class="Wj3C7c"><br>
--<br>
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>
</div></div></blockquote><div><br>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". Making many NAT questions drop off IRC and and the list. Making administration and system deployments "Just Work".<br>
<br>An RFC means "Request for Comment", it is not the Gospel or the Law.<br><br>Here, read this link <a href="http://www.legalzoom.com/legal-articles//article13758.html">http://www.legalzoom.com/legal-articles//article13758.html</a><br>
<br>Good stuff.<br></div></div><br>-- <br>Thanks,<br>Steve Totaro <br>+18887771888 (Toll Free)<br>+12409381212 (Cell)<br>+12024369784 (Skype)<br>