[Asterisk-Users] two NAT patches and STUN

[Chris Albertson]

Summary,

I'll start messing with getting STUN to work with Asterisk
There are two patches that address "asterisk as a NAT'd
SIP client"



"Christopher Stephens" <asterisk at chuljin.com>
Showed me a modified chan_sip.c that address the problem of
connecting with a SIP server like FWD, ADALINA ICONNECTHERE,
or the line in this case Asterisk acts like a SIP client.
Ask Christopher directly for a copy of his work

 "William Waites" <asterisk at lists.styx.org>
Posted a patch to this mailing list that looks to be very
much like Christopher Stephens fix but implemented totally
independently

Stephens, I think preferably, introduces one new sip.conf
line for the internal _network_ which acceprts a "network
address in the form inside=192.168.111.0/14  Where the "14"
would be the number of zero bits in a 32-bit mask

Waites used two .conf lines one for the IP address and one
for the mask.   IMO Stephens' approach is more cleaner.

Both of these have an "if" statment that checks to see if
the public address needs to be stuffed into the outbound
SIP packet.  I would replace this "if" with one that checks
the result of a STUN query.  STUN simply makes Asterisk
more self-configuring.

Ho, and one more thing.  I think the NAT configuration stuff
needs to go in a more global place and not in sip.conf  
as part of my STUN integration I'll look for a logical place
to but NAT stuff.  I could add a nat.conf file but, "Oh no
not yet another *.conf file!"  Suggestions????
We need a place to list known STUN servers and a place to
put manual "overrides" to handle cases whereeither STUN fails
or gives a misleading result

The STUN license is quite good.  It is basically "BSD-like".
or X11-like and reads in short "do what you want with this
but keep this notice and don't blame us if this is broken"


--- William Waites <asterisk at lists.styx.org> wrote:
> On Thu, 30 Oct 2003 16:18:23 -0800 (PST), Chris Albertson wrote
> >
> > This would be VERY much like the two current patches do except
> > that we would no longer need the new lines in sip.conf as STUN
> > would figure this out for us.
> > 
> 
> you would still need the lines to specify the internal network/mask.
> either that or an ioctl() to get that info from the interface -- 
> although using ioctl() that would break in the case of a subnetted
> internal 
> network. without this there would be no way to distinguish between
> an internal and an external address even with stun.


I don't think I _have_ to distinguish between an external and internal
address.  All Asterisk needs to know is if there is a NAT firewall
between it and some SIP server.

That said, I think Asterisk will need to look at the routing
tables and for each gateway and the local, non-gateway'd network
make a test using STUN. There are lots of caes to cover like
if the internal network has a NAT'd island with a SIP server inside
and the case of multiple "stacked" firewalls.  We have to be
carfue to solve the fully generized case.  After 15 minutes of
reading I think the STUN library is pretty good at figuring out
what's there and we don't need to work at the raw STUN protocol
level

I've actually started work on this.  MY plan
is to go slowly in stages, first just integrate the STUN code with
Asterisks and then to have Asterisk use STUN in more sophicticated
ways.

Like I said before, STUN does not do anything about NAT other then
to discover what is "out there". 



=====
Chris Albertson
  Home:   310-376-1029  chrisalbertson90278 at yahoo.com
  Cell:   310-990-7550
  Office: 310-336-5189  Christopher.J.Albertson at aero.org
  KG6OMK

__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/