On Wed, Nov 12, 2008 at 4:47 PM, Alex Balashov <[EMAIL PROTECTED]>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. > > -- > Alex Balashov > Evariste Systems > Web : http://www.evaristesys.com/ > Tel : (+1) (678) 954-0670 > Direct : (+1) (678) 954-0671 > Mobile : (+1) (706) 338-8599 > > 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. So if a "hack" overwrites something with the same something then did you really break the RFC? -- Thanks, Steve Totaro +18887771888 (Toll Free) +12409381212 (Cell) +12024369784 (Skype)
_______________________________________________ -- 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
