Telium Support Group

As of Dec 11th 2016 we now officially support Debian 8 LTS. Look for the Debian option on the download page.

Please note that we will create custom builds of our products for any major distribution / architecture for users of the commercial editions. Custom builds are created at no charge (for major platforms) and for-fee (for rare/unusual platforms).

If you’ve never used Linux before, then installing any third party product onto Linux can be a challenge. Creating a Linux system from a CD/ISO is easy: click next>next>finish. So unfortunately that might artificially raise your confidence. Linux is not the most friendly system (compared to Windows).

Although our products target large commercial installations, we realize that a some of these organizations experiment with Asterisk using one of the free configuration generators (like Issabel(TM), FreePBX(TM), Elastix(TM), PIAF(TM), etc). For the convenience of these users we can create a virtual machine with Linux & FreePBX & Asterisk & HAAst & SecAst preinstalled. This should help Windows admins get up and running quickly.

If you want to install our products on an existing Linux PBX, then we’re here to help. We include support with all product sales – but I suspect you will exhaust the included support incidents quickly. I would recommend you purchase support assistance along with your software purchase. For a straight forward setup Telium can perform the entire installation and configuration with/for you in 4 hours, assuming this is a very simple cluster design. (But not setup your users/devices/dialplan etc in Asterisk).

We have also helped customers create prebuilt software images to their specifications. (This is useful if you plan to deploy PBX’s to numerous sites.) We can create bare metal images in Ghost, dd, and G4L formats to suit your needs, which you can use to deploy new systems at your convenience.

We get hundreds of product downloads per week, many from people wanting to use the free edition. If we were to try to support these people by phone then we would have to add 10 people to our call center (which we can’t afford).

We created the support forums so that users could help solve each other’s problems, with input from the Telium support group to ensure the answers are accurate and complete.

Phone support is reserved for customers who have purchased 24/7 support agreements, while e-mail support is reserved for customers who have active maintenance agreements. But everyone is welcome to use the forums for self-service and occasional help from our support team.

This message is normal; i.e. nothing to fix.

Dual standby contention means that one (or both) PBX’s discovered that it is in standby mode and the remote peer is as well. Once this condition is detected the PBX’s begin negotiation to determine who should promote.

After a manual failover, or following the failure of one peer, the other peer will detect that no one is in active mode and record the event.

This is a normal condition (so long as it is followed by a promotion by one peer).

Depending on the combination of Linux, Qt library version, and local timezone (> UTC) this problem might appear. We have modified HAAst to detect the combination of libraries+Linux issue to avoid the problem. Please upgrade to HAAst version 2.3.1.16 or later and the problem should be resolved.

Dual active contention means that both peers in the cluster are active, and one or both peers discover that the other is active as well (they are contending). Upon discovering this situation the peers automatically negotiate which should remain active, and which should demote itself.

At a high level the cause of this problem is that the (previously) standby peer thought that the other peer was dead/unresponsive and needed to take over, so it promoted itself to active. However, the real question that needs answering is why did that peer think the other was dead/unresponsive?

The most common causes are:

1. HAAst Misconfiguration: If one of the peers continually cycles back and forth between active and standby then the most likely cause is peerlink misconfiguration in haast.conf (peer A can talk to peer B, but peer B can’t talk to peer A). To resolve this carefully check the settings in the peerlink stanza of haast.conf. If they look correct perform telnet connectivity tests to the HAAst port from each peer to the other, and continual ping tests (using only management IP’s) between peers and watch what happens before/after a contention.
2. Network Misconfiguration: If one of the peers occasionally cycles back and forth between active and standby then the most likely cause is network misconfiguration. Again, peer A can talk to peer B, but peer B can’t talk to peer A. To resolve this ensure the network settings at the OS level are correct, and the network settings are correct in HAAst.conf (voipnic stanza). This includes checking default routes (which may change if using a shared IP), accidentally reusing an IP address already in use, etc. If they look correct perform continual ping tests (using only management IP’s) between peers and watch what happens before/after a contention.
3. Peer Load/Responsiveness: If one of the peers suffers from periodic extreme load then HAAst will correctly assess its health as failing and allow the other peer to take over. To resolve this problem examine both hosts for CPU load, runaway process, high IO processes, etc. For example, the backup script included in FreePBX is poorly written and will cause very high CPU and/or IO load when it runs (causing the PBX to become unresponsive briefly). To resolve this problem identify the process(es) or device(s) causing the high load and correct their behavior (e.g.: switch to a real backup program).
4. LAN/WAN Latency: In cases where peers are separated by large geographic distances the maximum latency setting in haast.conf may be set too low. On rare occasions, an overloaded or problematic LAN can cause the same problem. Although the root cause of the problem can be accommodated by increasing HAAst’s maximum latency setting, this is not always desirable. Be sure to understand the implications on detection and fail-over time (for legitimate peer failure situations). As well, if you are running the Commercial Unlimited edition of HAAst then latency is already being compensated for dynamically – so the maximum latency setting will reflect how severe the problem really is, and may warrant a general network diagnostic.
5. Network Interruption: This is actually not a problem. It means there was a network outage (one node could not reach the other), and the standby node correctly promoted itself. Once network connectivity was restored, it demoted itself. If this problem occurs rarely then there is nothing you need to do – HAast is doing it’s job! If this problem occurs frequently, then you should investigate a network outage/intermittency.

This type of problem can be one of the most challenging to resolve. You will need to enable full debugging in the HAAst logs, as well as system logs, to capture the data needed to diagnose. You may need to involve your network admin, and possibly your WAN carrier. Telium will often work with clients through SSH to help identify the root cause, and suggest a resolution.

The Free Edition of PBXSync will synchronize Asterisk configuration files, but not information held in SQL databases. So your Asterisk configuration files (in /etc/asterisk) will synchronize and the nodes will work properly, but if you edit the configuration through FreePBX on one peer you will not see these changes appear in the GUI of the other peer.

To synchronize the SQL database you will need a commercial unlimited edition of PBXSync.

Assuming this is not a switch issue (which you confirmed by the arp packet missing in the packet capture), we can diagnose the problem as follows:

1. In one shell set a simple packet capture as follows:

   tcpdump -i ethX -vvv -x arp

2. ethX is the ‘physicaldevice’ setting in haast.conf which should match the ethernet adapter you are using for VoIP traffic.

[*]In another shell issue an arping from the command line (exactly as follows):

arping -U -I ethX -c 5 sharedIP
[*]ethX is the ‘physicaldevice’ key set in haast.conf which should match the ethernet adapter you are using for VoIP traffic.
[*]If ‘vlanid’ is set in haast.conf the “.haast” is appended to the ethX adapter name
[*]sharedIP is the IP address moving between peers, set in the ‘address’ key of the ‘voipnic’ stanza of haast.conf
[*]Stop the tcpdump and show the interface details using ifconfig

ifconfig
[*]Post the full output of command and response from all 3 steps above. If any of the information above is security sensitive (eg: a public IP is in the output) email the above to support@telium.io , do not obfuscate the data.

If traffic did not start to flow with the above command (and assuming there were no errors reported above), can you try a variation of the arping syntax that consistently works for you? Please post what worked for you.

If the above arping command generated any errors then we can offer a workaround. Although rare, we have seen the above command syntax fail on a Linux distro that customized its arping command. What distro and arping (from what package) are you using? And what exact syntax would allow the arping command to be successful? If we see enough need for that particular arping syntax we’ll add support directly to HAAst. As well, we can offer a workaround if that’s the only arping package available for your distro.