<br><br><div class="gmail_quote">On Wed, Nov 12, 2008 at 4:47 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 have done some large installs where people are going to be in the<br>
> office, sometimes out, work from home, it always changes sorta thing......<br>
><br>
> I have found that setting all device profiles to Nat=yes "Just Works"<br>
> whether they are on the LAN or not and this is even on larger scale<br>
> systems with hundreds of "phones".<br>
><br>
> Is there any reason why this would be frowned upon as a default? Even<br>
> to the point of, if nat= is not specified, it would default to yes?<br>
><br>
> Is there a performance hit somewhere, or some other downside?<br>
><br>
> If not, I suggest making it the default.<br>
<br>
</div>The premise of nat=yes is that the domain portion of the Contact URI is<br>
overridden with the real, received source IP of the request and that the<br>
default expectation of port 5060 (if not specified in the Contact URI)<br>
is dropped in favour of the actually received source UDP port.<br>
Similarly for SDP (without SIP-aware ALG).<br>
<br>
I think the reason this would be frowned upon as a default is<br>
philosophical in essence; by default, per the RFC, a SIP UAC is<br>
expected to behave such and such way, i.e. use the Contact URI that<br>
arrives in a REGISTER request and/or INVITE. Overriding that with the<br>
received IP:port is a "hack" around prescribed behaviour, and enabling<br>
hacks as default behaviour is generally considered a bad idea.<br>
<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>
<br>
</blockquote></div><br clear="all">While not taking the time to look, and if memory serves me correctly, LAN devices appear on the correct ports even with nat=yes. I may be wrong.... I will have to double check this when I have a moment.<br>
<br>So if a "hack" overwrites something with the same something then did you really break the RFC?<br><br>-- <br>Thanks,<br>Steve Totaro <br>+18887771888 (Toll Free)<br>+12409381212 (Cell)<br>+12024369784 (Skype)<br>