Alex Balashov wrote: > Steve Totaro wrote: > >> I have done some large installs where people are going to be in the >> office, sometimes out, work from home, it always changes sorta thing...... >> >> I have found that setting all device profiles to Nat=yes "Just Works" >> whether they are on the LAN or not and this is even on larger scale >> systems with hundreds of "phones". >> >> Is there any reason why this would be frowned upon as a default? Even >> to the point of, if nat= is not specified, it would default to yes? >> >> Is there a performance hit somewhere, or some other downside? >> >> If not, I suggest making it the default. > > The premise of nat=yes is that the domain portion of the Contact URI is > overridden with the real, received source IP of the request and that the > default expectation of port 5060 (if not specified in the Contact URI) > is dropped in favour of the actually received source UDP port. > Similarly for SDP (without SIP-aware ALG). > > I think the reason this would be frowned upon as a default is > philosophical in essence; by default, per the RFC, a SIP UAC is > expected to behave such and such way, i.e. use the Contact URI that > arrives in a REGISTER request and/or INVITE. Overriding that with the > received IP:port is a "hack" around prescribed behaviour, and enabling > hacks as default behaviour is generally considered a bad idea. >
IIRC Uniden phones do not (or did not at one time) work with nat=yes if they were not NAT'd. -- Consulting and design services for LAN, WAN, voice and data. Based near Birmingham, AL. Now accepting clients worldwide. Contact me for Tellabs echo canceling systems. Also see http://www.fnords.org/skillslist.html _______________________________________________ -- 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