[Asterisk-Users] two NAT patches and STUN
William Waites
asterisk at lists.styx.org
Fri Oct 31 10:32:16 MST 2003
On Fri, 31 Oct 2003 09:09:22 -0800 (PST), Chris Albertson wrote
>
> 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.
I agree, I was worrying more about the functionality than
the config file.
> 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.
Careful though -- we don't necessarily want to send a stun
query each time ast_sip_ouraddrfor() is called. That would
introduce unnecessary traffic as well as delay in setting
up the call.
> 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
stun.conf?
in order for other protocols to use stun, maybe it should be
its own module, exporting ast_stun_ouraddrfor() or similar...
> 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"
having it as its own module would also isolate the C++ stuff
(in which the reference implementation is written) as well as
the differently licensed code...
-w
More information about the asterisk-users
mailing list