I’m not sure if this problem is related but we recently had a power failure and many of our boxes exhausted their UPS support. This included our PBX. Luckily the batteries seemed to recover okay when power was applied but their lifespan has surely been shortened. Most of our computers and servers also were able to be restarted with no major issues and FREEPBX seemed to be okay.
Our main phone is an 8 station wireless Vtech system connected to a Grandstream HT503. The HT503 is connected to FREEPBX and works just fine though I actually did have to manually change one of its settings after the power failure. Unfortunately I don’t remember what that was but I have my doubts it is related to the problem at hand.
Sometime after the power outage it came to our attention that GS Wave was no longer making a connection to FREEPBX even though WiFi is working just fine for everything else. After trying everything I could think of to resolve the problem (including deleting/recreating the extension on the phone as well as in FREEPBX) I then installed and tried CSIPSIMPLE (which we recently replaced with GS Wave) but no joy.
I am stymied as to where to look for the cause of this issue. I have looked at the Asterisk log files available from the FREEPBX Reports menu but do not see anything that shows the extension trying to connect. I usually get emails when its firewall blocks someone but have not received any indicating a problem.
If anyone can give me some ideas where to look for potential causes of this problem I would appreciate hearing from you.
I assume that both FreePBX and the Android device are on the same LAN. If not, please describe your network. Also that FreePBX is on a physical server; describe virtualization if not.
If not statically assigned, the local IP of the PBX may have changed (use ifconfig -a to check) and you’ll need to make the corresponding change in GS Wave. If static but in the DHCP range of your router, another device could be conflicting.
When you recreated the extension, you may have inadvertently switched between pjsip and chan_sip; check which port it is using and confirm that GS Wave is connecting there.
If it’s not something simple, temporarily stop your iptables (or other software firewall) to rule out firewall issues. Next, capture traffic to/from the PBX with tcpdump, move the capture file to your PC and examine it with Wireshark. Look for REGISTER requests from the Android and whether any error response is given. (If you see none, confirm that requests from the 503 are present, so you know the capture is being done correctly.)
If you still have trouble, report what you found from the above tests and we’ll take it from there.
UPS systems use Deep Cycle batteries, which are designed to be drained. Running a UPS to “dead” will not negatively affect your UPS battery life.
It may be time to get in with the console. Log into the console as ‘root’ (either through SSH or through the local keyboard, depending on your installation).
First, double check your network settings on the remote phone and make sure that it is in the same local network as your PBX. This needs to include any VLAN tagging you may be doing, as this can cause strange sorts of visibility problems.
Once you have to IP address of the phone, use the command “tcpdump -I eth0 host <phone.IP.add.ress>” where the <> and contents are replaced with the IP address of the phone. For example: “tcpdump -I eth0 host 192.168.100.101”. This will dump all of the traffic the server is seeing before the firewall so you can troubleshoot the network. If the traffic from the phone is not making it to your PBX, you have a larger issue with your network.
If the traffic is making it to the PBX, make sure the port numbers (5060 and/or 5160) are being queried. Just watch the tcpdump output and look for the port 5060 incoming traffic. This traffic should reflect in your logs. To check that you can use “tail -F /var/log/asterisk/full” and watch the logged traffic. Watch for password mismatches and “no endpoint found” errors in particular. These are both common.
Go into the FreePBX GUI and double check the status of the local firewall. There are two places where this needs to be done. The first is in the System Admin section (look for Intrusion stuff) and in the Firewall module itself. Turning off the firewall is a good short-term step, but eventually you are going to want to re-enable it and these modules are what controls it. Make sure they are set up correctly and working.
In your DHCP server - IMHO (which, if you’ve ever read a post from me is never very “H”), you need to manage every device in your network, even if the devices are not currently listening to DHCP. For server class and critical workstation assets (like this phone), I highly recommend using a Reserved IP Address. Devices in the ‘pool’ are devices that don’t need to know their address or can run “pretty much anywhere”. Your phone (since it NEEDS to know it’s IP address) should not be in the pool. Note that this means that, even if you set the address in the device, an entry should be included in the DHCP server for it whether you are using it or not. Yes, it is extra work on the front end. It means you actually have to manage your network assets to make sure that things work, which is kind of why you are here.
Okay… very strange update to the situation. I just came in to take a break from mowing my yard, turned my phone on and GS Wave (which I have set to automatically start with my phone) registered to the PBX without any intervention on my part. I thought that was strange so I closed GS Wave and opened CSIPSIMPLE which also registered with no problem. I then closed CSIPSIMPLE and restarted GS Wave and it registered again, right away. WTF!
I had not had a chance to try any of the suggestions received here and had been too busy to thank you guys for responding. I do not consider this matter resolved yet as I have no idea why things stopped working or why they started working again.
Anyway, some quick responses, yes, everything here is on the same LAN and FreePBX is on a physical server (RASPBX… okay a dinky box some would not consider worthy to be called a server). I do not use DHCP with the exception of some WiFi devices (including cell phones) and rather assign static IP’s (which the router does based on MAC) as much as possible as I have found it invaluable for control as well as trouble shooting.
Question: Now that the problem “might” be resolved, where are the historical places (log files, etc) I might look at to see where the blockage (or disconnect) may have been occurring?