Posted: Thu Apr 17, 2003 12:47 am Post subject: [Asterisk-Dev] Feature request: auto-guessing NAT status bas
[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)
Posted: Thu Apr 17, 2003 1:14 am Post subject: [Asterisk-Dev] Feature request: auto-guessing NAT status bas
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:
Quote:
[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)
Posted: Thu Apr 17, 2003 1:28 am Post subject: [Asterisk-Dev] Feature request: auto-guessing NAT status bas
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
Quote:
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@lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
>
Posted: Thu Apr 17, 2003 2:37 am Post subject: [Asterisk-Dev] Feature request: auto-guessing NAT status bas
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:
Quote:
[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)
Posted: Thu Apr 17, 2003 3:46 am Post subject: [Asterisk-Dev] Feature request: auto-guessing NAT status bas
On Wednesday 16 April 2003 20:14, Eric Wieling wrote:
Quote:
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.
I'd go with CIDR blocks instead. Here's a quick set of code
which can be whipped into C easily (the logic is accurate):
Posted: Thu Apr 17, 2003 7:01 am Post subject: [Asterisk-Dev] Feature request: auto-guessing NAT status bas
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
Quote:
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@lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
>
Posted: Thu Apr 17, 2003 10:08 am Post subject: [Asterisk-Dev] Feature request: auto-guessing NAT status bas
On Wed, 16 Apr 2003, John Todd wrote:
Quote:
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.
Hi,
I don't think that the use of RFC1918 addresses "predicts" the use of NAT.
For example, what if the * box is _also_ on a RFC1918 address?
But looking at the code it seems to me that *'s behaviour for SIP incoming
connections is actually closer to the RFC when nat=1 than when nat=0.
For instance: Adding the ;received= to the Via is a "MUST" in the RFC but
this code is currently conditioned by nat=1.
Always including the "received=" thing on the Via also helps clients with
STUN to work properly. For clients with STUN (eg ATA186) they will
automatically fudge their SDP to announce the correct public
address. Asterisk doesn't need to know that they are NATted at all.
But note - received= should not be added if the address is the same at the
address in the Via already.
Posted: Thu Apr 17, 2003 3:58 pm Post subject: [Asterisk-Dev] Feature request: auto-guessing NAT status bas
Quote:
For instance: Adding the ;received= to the Via is a "MUST" in the RFC but
this code is currently conditioned by nat=1.
Originally we *did* always put ;received= but we had some SIP devices
which *could not handle* the ;received= on it and would cause them to
fail.
Quote:
Always including the "received=" thing on the Via also helps clients with
STUN to work properly. For clients with STUN (eg ATA186) they will
automatically fudge their SDP to announce the correct public
address. Asterisk doesn't need to know that they are NATted at all.
Right, but see above.
Quote:
But note - received= should not be added if the address is the same at
the address in the Via already.
Hrm, that might be reasonable :) If there are no objections, I'll do it
that way.
Posted: Thu Apr 17, 2003 11:54 pm Post subject: [Asterisk-Dev] Feature request: auto-guessing NAT status bas
On Thursday, Apr 17, 2003, at 03:08 US/Pacific, Stephen Davies wrote:
Quote:
I don't think that the use of RFC1918 addresses "predicts" the use of
NAT.
For example, what if the * box is _also_ on a RFC1918 address?
Or maybe the * box is not on an 1918 address but it can route to the
1918 addresses without going through NAT. (That's the setup I have in
much of my private network).
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum