[Asterisk-Dev] Feature request: auto-guessing NAT status based on From: IP address

[John Todd]

I'll be darned, you're right.  I think I was using pre-last-week's 
experiences on which to base my message, because I had one ATA-186 
device that just would NOT work if I had nat=1 set and they were not 
behind NAT (that lesson cost me at least an hour of debugging, and 
was repeatable.)  However, that doesn't seem to be the case any more. 
I'll also say that the tests I've just done were not with that 
device, and not all ATA-186's are created equal regardless of 
software revision, so final verdict will have to wait a bit.  Either 
the changes in SIP have cured that issue entirely, or the particular 
ATA I was using was unpleasantly unreliable.

So I suppose one might say that the "nat=1" should probably be put in 
the general configuration examples, since it really doesn't hurt that 
much to be turned on by default, except that it's not completely RFC 
compliant in the way that it re-writes SIP messages.  (so what... big 
deal...)

JT


>What sort of device do you have that does not work with nat=1 when nat is
>not actually taking place?
>
>As far as I know, the pingtel is the only one.
>
>Mark
>
>On Wed, 16 Apr 2003, John Todd wrote:
>
>>
>>  [Sorry to put this up to the list instead of submitting code; I can't
>>  code my way out of a wet paper bag, as I've said before.]
>>
>>
>>  Proposal:
>>
>>  Extension to the "nat=" flag in sip.conf to automatically guess on 
>>NAT status.
>>
>>  Reason:
>>
>>  I have a bunch of people that keep moving their SIP devices between
>>  home and work (NAT and non-NAT IP space) and I get tired of switching
>>  their "nat=" status every time they move.  Most (but of course, not
>>  all) NAT devices give out RFC1918 addresses, so in any given REGISTER
>>  or INVITE status we have a pretty good idea if a device is NAT'ed or
>>  not.  Why not use that data to solve the problem for the 90% of the
>>  people who have NATs that provide addresses in this space?  Retaining
>>  the "yes" and "no" flags maintains backwards static compatibility for
>>  those who need it or for address spaces that are NAT'ed but do not
>>  fall into the RFC1918 area.
>>
>>
>>  Syntax:
>>
>>  Old syntax:
>>    nat=[1,0]
>>
>>  New Syntax
>>    nat=[1,0,yes,no,auto]
>>
>>  The "0" and "1" definitions will retain their historical meaning, and
>>  will also have duplicates with the terms "yes" and "no" to mean "1"
>>  and "0" respectively.
>>
>>  If the keyword "auto" is specified, the system will make a 'best
>>  guess' as to the status of the NAT flag for that SIP peer.  If the IP
>>  address in the "From:" field in an INVITE or REGISTER is set to one
>>  of the common RFC1918 addresses, then the system will assume "yes"
>>  and the appropriate re-write and "via" headers will be set.
>>
>>
>>  Definitions:
>>
>>  RFC1918 space:
>>
>>  10/8
>>     - match on first octet being a "10"
>>
>>  172.16/12
>>    -  match on first octet being 172, and second octet being 
>>between 16 and 31
>>
>>  192.168/16
>>    - match on first octet being 192, and second octet being 168
>>
>>  See RFC1918 (http://www.zvon.org/tmRFC/RFC1918/Output/index.html)
>>
>>
>>  JT
>>  _______________________________________________
>>  Asterisk-Dev mailing list
>>  Asterisk-Dev at lists.digium.com
>>  http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>
>_______________________________________________
>Asterisk-Dev mailing list
>Asterisk-Dev at lists.digium.com
>http://lists.digium.com/mailman/listinfo/asterisk-dev