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

[John Todd]

Sure, that sounds fine, and is indeed more flexible.

I was trying to perhaps be overly pragmatic, and spare the programmer 
(whoever that may be) from building a whole set of subroutines that 
did CIDR or subnet expansion logic and corresponding matching.  Plus, 
your example below needs to encompass multiple network entries, which 
further adds complexity.  Personally, I'd be happy with either way - 
your way is more flexible, but "hard coding" the information from 
RFC1918 might end up with something submitted to CVS more quickly.

JT


>Why not let you specify a netblock for nat or nonat.  i.e.
>nat=172.16.0.0/255.255.240.0 or nonat=63.173.166.0/255.255.255.0 and
>then make natdefault=nat or natdefault=nonat
>
>Seems to me like a more flexable system than guessing if we should nat
>or not.
>
>--Eric
>
>On Wed, 2003-04-16 at 19:47, 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