RFEngineer - sent you a PM , if you are still having an issue take a look at it
Damn, I had deleted all my incoming routes except for two, one for each of my DIDs, so I did not have a default route to handle odd-ball or missing DIDs.
Iâve added an any DID / any CID route and now my calls are being routed to an extension.
If your (non default) inbound routes arenât working, my guess is that Flowroute is putting the DID in the To: header of the INVITE, which Asterisk is using rather than the trunk name.
If your DID is e.g. 212-555-1212, then try setting your inbound routeâs DID Number to 2125551212. If no luck, try 12125551212 and also +12125551212. If none of these work, look at the packet with sip debug to see what Flowroute is actually sending, then set DID Number to match.
RFEngineer - If you watch the most basic debug it will say âreceived incoming call fromâ that has to be your trunk name unless you have SIP guests on, a bad idea. So just because it is working, we donât know if it is really working. I donât know why Stewart asked you to do more steps than this.
As far as firewall status, remember all the commands support a ? to list their options. You ask how to check the firewall. Once you learn a command you should play with it to see what else it can do. So in this case the âservice iptables statusâ is the permutation you are looking for.
You are correct I called my system from my cellphone.
A block of data with INVITE in the second line has in it:
âTo: sip:+1âŚmy office numberâ
From: sip:+1âŚmy cell number
Their is a âless thanâ symbol before each sip: above but apparently the new system takes it as a command character.
Iâve tried all of those combinations but incoming calls still arrive on my No DID route.
Incoming calls sort of worked for most of the weekend and then stopped, just like last weekend. Itâs strange, the system responds to flowroute requests for about two days and then stops responding.
I am back to the original problem of no incoming calls. According to Flowroute, registration is no longer an issue since I am using URI:SIP. But the problem may be related to the lack of registration in that the FreePBX box is not responding to requests from Flowroute.
I did a tcpdump of an incoming call this morning and sent it to Flowroute. They responded with this:
Thank you for the packet capture. Your system is receiving the INVITEs but makes no response to the INVITEs. Normally there should be a 100 TRYING immediately returned to Flowroute from your system; however your system does not make any response. On Flowrouteâs side since we do not receive a response from your system we go to the failover route. This indicates that there is an issue with the FreePBX configuration for this inbound route; please review your inbound configuration.
What inbound configuration? the incoming route is a description, DID number, DID name prefix and a ring group.
Is there somewhere else I need to look for inbound settings? Incoming settings on the trunk are blank as per flowrouteâs directions and the registration string (it is even necessary any more since I use URI:SIP?) is cut-and-pasted from the flowroute configuration window.
Boy, Murphy is working overtime on your system!
AFAIK, Asterisk will never totally ignore an incoming INVITE, even if your inbound settings are messed up. Try stopping fail2ban and iptables, then see if you still have the trouble. If so, do calls between extensions still work? If not, maybe Asterisk stopped altogether; check logs for what the cause may have been. If calls between extensions do work but incoming still fails, post Asterisk log (including sip debug) for a failing incoming call.
Though itâs unlikely that these are related to the present problem, please post:
Do you have a static public IP address? If not, has the address changed since incoming calls were working?
Does White Russian get a public IP address on its WAN interface? If not, either your cable modem is configured as a router, or your ISP is doing NAT. Please provide details.
fail2ban and iptables stopped. I typed asterisk -vvvvr and made an incoming call. Nothing. No packets on the CLI terminal screen.
Calls between extensions work fine and lots of packets appear in the terminal window.
Full Asterisk log file for the past several hours:
Ăż
Ăż<------------->
[2014-06-16 17:35:00] VERBOSE[10427] chan_sip.c: â (9 headers 0 lines) â
[2014-06-16 17:35:00] VERBOSE[10427] chan_sip.c: Really destroying SIP dialog â[email protected]â Method: INVITE
[2014-06-16 21:36:50] VERBOSE[8564] asterisk.c: â Remote UNIX connection disconnected
[2014-06-16 21:37:36] VERBOSE[10409] asterisk.c: â Remote UNIX connection
[2014-06-16 21:38:34] VERBOSE[9153] asterisk.c: â Remote UNIX connection disconnected
[2014-06-16 21:42:09] VERBOSE[10409] asterisk.c: â Remote UNIX connection
Here are the results of sip debug during an incoming call:
marvinCLI> sip set debug peer RFE_FRte
SIP Debugging Enabled for IP: 216.115.69.144
marvinCLI>
==========================
Over the weekend, when it seemed like things were working I hooked up some new extensions, Panasonic KX-UT123. The extensions would not work unless they were in the same subnet as the server, but I canât put the phones in the DMZ for practical reasons. SO, I activated eth1 and put it on my LAN. The new extensions now work. I donât know if having two ethernet ports in two separate LANs is contributing to the problem, but I want you to know about the configuration change.
The new network config is HERE.
And, yes, I sshâed into the server on one LAN, ran the tests, then sshâed into the server from the other LAN and reran the tests, no difference.[quote=âStewart1, post:47, topic:22477â]
Though itâs unlikely that these are related to the present problem, please post:Do you have a static public IP address? If not, has the address changed since incoming calls were working?Does White Russian get a public IP address on its WAN interface? If not, either your cable modem is configured as a router, or your ISP is doing NAT. Please provide details.
[/quote]
Yes I have a static IP. The WAN side address of the White Russian is my publicly switched static IP.
Keep in mind regular Asterisk CLI verbosity is only for dial plan. It actually gets in the way.
You want to do a core set verbose 0 then a sip set debug on
This will then show you decoded SIP messages live as they are RXâd
OK, after a reboot I stopped fail2ban and iptables, ran asterisk -r, sip set debug.
An incoming call produced no activity on the terminal.
I then made an outgoing call, lots of data appeared.
I then made another incoming call, no data and as before my call went to the failover route.
The screen dump can be seen HERE
I did a tcpdump of port 5060 on the DMZ side of the FreePBX server. I made an incoming call which was delivered to my failover route. I looked at the tcpdump, I donât know how to interpret the data but it looks like six nearly identical groups of packets with an INVITE label.
since I see no activity from sip debug does this indicate that the incoming call INVITE is being ignored by my FreePBX server? Would it be useful to you to see the tcpdump?
Though itâs probably ok for short-term testing, I would not use the new network config in production. If an attacker somehow got into the PBX, even non-root, he would have unrestricted access to everything on your main LAN.
If your LAN switch has VLAN capability, you could put the phones (in a separate VLAN) on the 192.168.1.0 subnet. (If you are daisy-chaining a workstation off of each phone, the phones would also need VLAN support.)
Another possibility is putting the phones in a sub-range of 192.168.0.0, e.g. 192.168.0.192 through 192.168.0.223. Then, youâd set up restricted non-NAT routing on the Cisco, allowing Asterisk to access the phones and vice-versa. In this configuration, you would include 192.168.0.0 in Local Networks in FreePBX.
Iâm not a security pro and the suggestions above may not be secure, either. If you donât have someone on your staff with the required skills, I recommend that you have a professional review your setup.
With your present (two NIC) configuration, confirm that Asteriskâs default route is through the 192.168.1.0 interface. Otherwise, the source port of replies will get rewritten, causing them to probably not work.
If I see anything in the captures, Iâll post a separate reply.
Possibly Flowroute is sending the call from an IP address different from 216.115.69.144. Try enabling SIP Debug as
sip set debug on
which will log all SIP packets in and out, then test an incoming call. Youâll see some noise from extensions registering, etc., but it should still be obvious if any INVITEs arrive from the outside and if any replies are sent by Asterisk.
Also, confirm with
netstat -r
that the default route Iface is eth0 and its Gateway is the address of White Russian.
I do NOT see the White Russian address (192.168.1.1) listed as the gateway for eth0.
[root@marvin pickles]# netstat -r
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
192.168.0.0 * 255.255.255.0 U 0 0 0 eth1
link-local * 255.255.0.0 U 0 0 0 eth0
link-local * 255.255.0.0 U 0 0 0 eth1
default 192.168.0.1 0.0.0.0 UG 0 0 0 eth1
[root@marvin pickles]#
Done.
There was considerable activity as expected. I made two incoming calls and saved the terminal results to a file. I searched the file for âINVITE.â The only ones I found were in lines beginning with âAllow:â
I also searched for â216.115.69.144â, it was not found.
I can post the text file if you think it would be useful.
Could I be looking at some sort of elusive hardware problem with my server?
Any thoughts on me buying a Raspberry Pi or Beaglebone Black and installing a distro on it? Or would it be a better idea to buy a more traditional computer?
You may indeed have a hardware issue, but Iâm not yet convinced itâs with the server. You might try shutting down the server and hooking up an IP phone in its place, to see if it can reliably make and receive calls via Flowroute. Unfortunately, it took two days for your previous setup to show a problem, so it wonât be a quick test.
Although I have some RPi, IMO they are not robust enough for commercial use. Their power management is flaky (a voltage dip will cause incorrect execution before power-up reset activates). BBB doesnât have that problem, but I donât have enough experience to recommend it.
Regarding the present situation, you need to fix the default route so Internet packet go out the way they came in. Thatâs normally just a matter of editing /etc/sysconfig/network http://www.cyberciti.biz/faq/howto-rhel-fedora-linux-setup-default-gateway/ , but I donât understand why simply adding a NIC caused it to change.
Is Asterisk currently binding to both NICs, i.e. do extensions on 192.168.0.0 and on 192.168.1.0 networks both work?
If fixing the above doesnât help, it would be useful to see a tcpdump and sip debug taken simultaneously.
1 Like
Flowroute already had me do that. I reconfigured the softphone on my pc to connect directly to their system. This is back when the problem was with registration. It connected, registered and worked just fine, however I did not leave it connected for very long.
My server room (closet) runs off a dedicated circuit with a ferroresonant UPS, so power is pretty stable. Also we are a very small engineering company (a mom & pop as it were) so a handful of IP phones and a max of five simultaneous calls is sufficient capacity. Additionally, we do a lot of work with Arduino computers and an RPi would not go to waste here if it was not needed for VoIP service.
/etc/sysconfig/network contained only two lines:
NETWORKING=yes
HOSTNAME-marvin
I added one line, GATEWAY=192.168.1.1, and restarted networking
I donât have any phones in the DMZ.
Done. Before I share these files with the rest of the Universe, is there any information I should redact?
Also, as a very unimportant aside, I tried to redirect the std out of the SIP debug to a file and apparently â> filespecâ is not acceptable to follow a command under asterisk CLI. Is there a way to do this?
Update:
I setup FreePBX on the Raspberry Pi. Since the RPi only has a single network interface, and since my phones donât seem to work through my bridge router I had to place the RPi in my LAN and open ports in the bridge.
The new server will not sip register with Flowroute.
I am now running strictly URI SIP. Outbound is OK but inbound will not detect the DID even though I can see it in the To: field of the INVITE packets.
I am giving up on getting SIP to work with Flowroute, so I am abandoning this topic as UNSOLVED.
I will likely start a new topic on the undetected DID.
Thank you to everyone who tried to help. Too bad we couldnât get it fixed.