[Asterisk-Users] Asterisk behind LinkSys NAT Routing

Robert L Mathews lists at tigertech.com
Mon Nov 3 19:05:21 MST 2003


At 11/3/03 2:41 PM, Martin Pycko <martinp at digium.com> wrote:

>It's not for phones, it's for asterisk behind a NAT.

My apologies; I'm not making my question clear.

I realize this option is for Asterisk behind a NAT, but of course 
Asterisk uses this parameter to talk to SIP clients (which I referred to, 
perhaps too specifically, as "phones"), and that's what I meant.

In other words, Asterisk might be talking to SIP phones on either side of 
the NAT. A given SIP phone acting as an extension may be on the same 
private network as Asterisk, or it may be on the other side of the NAT 
(out on the public Internet, possibly even behind its own NAT on the 
other end).

Imagine I have both Asterisk and a SIP phone on my local office network 
using private IP addresses, and I also have a second SIP phone that is in 
another location, at someone's home office on the public Internet.

The "externip=a.b.c.d" doesn't help in this situation, because it forces 
Asterisk to use the external IP address in all cases, which breaks the 
functionality for local phones. That is, the new option presumably makes 
it possible to have *all* your SIP phones on the other side of the NAT 
from Asterisk, but you can't some phones on both sides. (Indeed, I just 
tried it, and using "externip=something" prevents SIP phones on the same 
private network as Asterisk from working.)

In Bug ID 0000104, a patch was suggested that takes the netmask into 
effect and makes the right decision for phones on either side of the NAT. 
However, the code that was added for "externip" in the current CVS isn't 
that patch; it's just a way of giving me a choice of having SIP phones on 
the outside of the NAT working, or having SIP phones on the inside of the 
NAT working, but not both at the same time.

I guess I'm curious why the hard-coded global option was used, because it 
doesn't really solve the problem in the general case. The whole trouble 
with NAT is that Asterisk may need to use a different IP address 
depending on the IP address of the SIP client it's communicating with, 
and that address needs to be determined on the fly. In a perfect word, 
this would all be handled by magic so it required no configuration (e.g., 
STUN), but the patch in 0000104 would at least allow phones on both sides 
of the NAT to work with a small amount of configuration, which isn't 
possible now with the CVS code.

Thanks again for the hard work you're putting in to Asterisk!

-- 
Robert L Mathews, Tiger Technologies      http://www.tigertech.net/




More information about the asterisk-users mailing list