Elastix behind NAT, Inbound call woes.

ToMaC

Joined
Feb 26, 2009
Messages
6
Likes
0
Points
0
#1
Did a fresh install today just to see what Elastix was all about. So far I like what I see but haven't got inbound calls to work. I have my elastix machine behind a NAT. I have one SIP trunk to a local ISP, I have had my Cisco 7960 directly connected to this trunk behind the NAT with no issues in/out whatsoever. I have set up the incoming destination, port forwarded 5004-5082tcp/udp & 10000-20000 UDP to my Elastix Machine (even though I never had to do this with the cisco phone). 'sip show registry' shows I am registered with the trunk, but it just rings & rings when I try to call into it. sip_additional.conf is as follows. Any insight would be helpful.


[200]
type=friend
secret=200
record_out=Adhoc
record_in=Adhoc
qualify=yes
port=5060
pickupgroup=
nat=yes
mailbox=200@default
host=dynamic
dtmfmode=rfc2833
dial=SIP/200
context=from-internal
canreinvite=no
callgroup=
callerid=device <200>
call-limit=4
accountcode=
call-limit=50

[5415852297]
secret=xxx
type=user
context=from-trunk

[BendTel]
host=xx.xx.xx.xx
username=xxxxxxxxxx
secret=xxx
type=peer
 

ToMaC

Joined
Feb 26, 2009
Messages
6
Likes
0
Points
0
#2
Really, No one? I figured this would be a no brainer. :(
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#3
And your "inbound routes" send the calls where?

If you are getting "ring-back" it appears your calls are landing on your server, this is good.
 

ToMaC

Joined
Feb 26, 2009
Messages
6
Likes
0
Points
0
#4
I have in inbound route to terminate at extension 200. I know packets are hitting the server upon the calls, if I do a tcpdump -vv on my interface I can see a REGISTER sip:66.39.x.x SIP/2.0 followed by a NOTIFY sip:541575xxxx@66.220.x.x followed by a couple invites. I never see anything at all in the CLI during this process.
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#5
You can get even more detail with

from the Asterisk CLI:

sip debug ip 66.39.x.x and/or sip debug 66.220.x.x, you can increase the verbosity and debug level with set debug 99(or less) and set verbose 99, 3 is default for both (sip debug ip <local ip of 200> probably the most informative though.) . (unfortunately it is hard to follow high verbosity, so /var/log/asterisk/full is easier to debug from).
Sip show peers will show phones AND providers 200 should be there of course (and on your local network).

(what is your internal network, 66.39.x.x seems to be an ISP in PA (pair), and 66.220.x.x. Hurricane networks, a COLO provider and the phone number in Oregon?, is this a physical box?)
(p.s. The cisco 7960, is a simple client not a "back-to-back User agent" as is asterisk, one way NAT traversal is far easier than two-way)
 

ToMaC

Joined
Feb 26, 2009
Messages
6
Likes
0
Points
0
#6
It basically goes like this..

(ISP SIP Gateway*66.39.x.x*)<----->(My Asterisk box eth0 *66.220.x.x*)|(My Asterisk box eth1 *192.168.10.75*)<----->(Cisco 7960 *192.168.10.105*)

I'll do some debugging within the CLI to see if I can find something.
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#7
As documenetd here and in other places,
you should probably have in the /etc/asterisk/sip*.conf family (preferably the nat one)
something like:

externip=<your externalip>
and
localnet=192.168.10.0/255.255.255.0
(or preferably externhost)
?


If you are multi-homed on your asterisk box, the routing/natting/firewalling between WAN and LAN must be impeccable. As must be sip.conf and it's inclusions, or the SIP via's wont via properly ;)


FWIW:

a little snippet I developed
Code:
 echo "externip=`wget -q -O - checkip.dyndns.org:8245|sed -e 's/.*Current IP Address: //' -e 's/<.*$//'`"
But beware if you are provisioned by DHCP it can and probably will change occasionally!!
If
(ISP SIP Gateway*66.39.x.x*)<----->(My Asterisk box eth0 *66.220.x.x*)
is correct, can I assume you have no router between the asterisk box and the internet, and you in fact have a static IP/network and that the asterisk box is the only router involved?
 

ToMaC

Joined
Feb 26, 2009
Messages
6
Likes
0
Points
0
#8
Right now I have it directly connected to the internet with no router. I just wanted to eliminate the factors that are making this not work. I know now that it isn't a router/firewall issue. I made those additions to my sip.conf, still no ring-through. Kind of at a loss here..
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#9
Now I'm a little confused, the original post was "Elastix behind NAT, Inbound call woes."
yet now you say you are directly connected to the internet, thusly Elastix is NOT behind NAT, So all that externip etc. is not for you.
That you you have the box as a router is a whole different issue, the phones might be NATTED in your LAN but if they can see the server and vice versa, it will work. Asterisk binds by default to 0.0.0.0/0 (all interfaces) and if you know what your doing with your routing/natting between wan and lan interfaces it should all work. (the phones would normally register to the lan interface address, does "sip show peers" from the asterisk CLI so show them registered?)
 

jgutierrez

Joined
Feb 28, 2008
Messages
5,737
Likes
0
Points
0
#10
I suppose that you have added correctly an inbound route, try for instance, that all calls go into one extension.

Edit /etc/asterisk/sip_general_custom.conf
and add the following line:
context=from-pstn

save the file, and execute from the shell the following command: asterisk -rx "reload"
 

ToMaC

Joined
Feb 26, 2009
Messages
6
Likes
0
Points
0
#11
I went ahead and threw out the outside interface to make things less complicated. As it sits now, there is one NIC in my Asterisk box which sits on my NAT'd network with an ip of 192.168.10.75. I removed the externip= and localnet= from the sip.conf. Still in the same scenario.

dicko, sip show peers shows my phone extension 200 registered on the private network, with an "OK" status. It also shows my Sip trunk with a status of "UnMonitored".

jgutierrez, I made that change and it had no noticeable effect.
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#12
NOW you need that externip, localnet stuff for inbound, (you are now in a NAT situation)

you have the endpoint registered, that is good (set up a softphone/another phone and make sure that they can call each other)

It is not normally necessary to register your outbound trunks, just your inbound what does "sip show registry" return?

Next you need to monitor the CLI as you attempt to make an outbound call (following the dial rules you set in outbound routes, unless you changed it, start with a 9 and expect that to be stripped before sending it to your trunk defined in that outbound route, watch the interaction, if the outbound trunk accepts your authentification, then the call will progress, if it doesn't then you have the trunk set setup wrong).

Then back to #17726 for the next steps. . . (Check what BendTel suggests , but providers are not always correct, IMHO it often easier to set up separate Inbound and Outbound Trunks with your provider, it makes it easier to isolate your problems)

I suggest baby steps, eventually knowledge will be king! (Read "Elastix Without Tears". Asterisk is not a no brainer, actually it's very far from that , but luckily others have done the brain-work for us already) ;)
 

wiseoldowl

Joined
Aug 19, 2008
Messages
251
Likes
0
Points
0
#13
When I originally read your message, I did not perceive that you were having audio issues (otherwise I might have referred you to HOWTO: Resolving Audio Problems), instead your subject led me to believe that you were not receiving incoming calls at all. But now I'm thinking you may want to read the aforementioned document anyway. Also, if you have both PEER details and USER details in your trunk configuration, one thing that often works (depending on the provider) is to completely eliminate the USER context and details, and use only the PEER section of trunk configuration, but if you do that be sure you have a context=from-trunk statement in the PEER details, otherwise Asterisk won't know where to send the calls. Then you have to have an incoming route, and the DID must match what the provider is sending - sometimes there's a problem there, in which case the document How to get the DID of a SIP trunk when the provider doesn't send it (and why some incoming SIP calls fail) may provide you with some useful information. Your answer is probably buried somewhere in one of those two documents (hopefully).
 

Members online

No members online now.

Latest posts

Forum statistics

Threads
30,902
Messages
130,888
Members
17,568
Latest member
mehdii_igi
Top