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. -- 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/20081112/51b7692a/attachment.htm
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
On Wed, Nov 12, 2008 at 4:47 PM, Alex Balashov <abalashov at evaristesys.com>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) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20081112/c01e8ee6/attachment.htm
Steve Totaro wrote:> 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.That is not my understanding from the code. Also, I am curious - what is the definition of "LAN device" as you are using it here? Is it a network with 1) an RFC1918 address and 2) a network on which the system running Asterisk has a physical interface binding? If so, what about other routed subnets also on a LAN? -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599
Actually I would nat=yes always, even if clients are not behind NAT os otherwise the clietn can put some garbage into the contact header (e.g. IP address of an upstream provider) and influence routing. The only thing were nat=yes is bad is if you have an asymmetric client. I do not know any RTP asymmetric client, but there are still SIp asymmetric clients, e.g. some Cisco phones and Cisco Gateways klaus Steve Totaro schrieb:> 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. > > -- > 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
Klaus Darilion wrote:> Of course we know that we should implement RFC conform. But RFC 3261 has > ignored the fact that the Internet is full of NATs and standard conform > implementations can not work. This in the case of SIP it necessary to > break the RFC.By default? NAT itself is a hack; therefore, I would think that NAT traversal assistance should be enabled when NAT is used. Why would we presume NAT and implement behaviour that is only desirable under NAT as a default? -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599
Alex Balashov schrieb:> Klaus Darilion wrote: > >> Of course we know that we should implement RFC conform. But RFC 3261 has >> ignored the fact that the Internet is full of NATs and standard conform >> implementations can not work. This in the case of SIP it necessary to >> break the RFC. > > By default? > > NAT itself is a hack; therefore, I would think that NAT traversal > assistance should be enabled when NAT is used. Why would we presume NAT > and implement behaviour that is only desirable under NAT as a default?Because NAT is the default. At least in Austria - most customers get a NAT router with their DSL Account. klaus