Telium Support Group

Yes. HAast fully supports containers. Normally HAast will run inside the container with Asterisk; however, we have seen deployments where HAast runs on the host and starts a container (containing Asterisk) on demand.

If this is you first exposure to HAast we recommend installing HAast inside the container with Asterisk (and optionally a GUI).

You have described two very different needs in your question, so I’ll try to answer them separately. If you choose Hardware Fingerprint activation on AWS, then your license is tied to your instance ID and MAC address. So you can safely move the instance between hosts (i.e. hypervisors, not guest VM’s), change instance size, etc. The license will remain activated (tied to that instance). You can safely start/stop the instance, just don’t ever delete it or delete the NIC as that will invalidate your license.

If you plan to have multiple AWS instances ready to start but will only use one at a time, then you should choose Cloud activation. Cloud activation is not tied to any (virtual/physical) hardware so whichever instance is running is the one that will use the license. However, do not start more than one instance at a time (i.e. don’t try to use a single license on multiple instances simultaneously) or that will invalidate your license.

I should point out that we use a third party license product, and they have no obligation to issue a new license once an existing one has been invalidated. In other words, if you invalidate your license you will most likely have to buy an entirely new license (full price). So plan your deployment carefully to avoid wasting a license. We have no ability to “un-invalidate” a license – we are at the mercy of the license vendor, and we understand their need to prevent license fraud as that’s the only way they can stay in business.

No! Unlike most of the other configuration generators, FreePBX does something a little unusual. Every time you add a module (or even upgrade a module) to your system FreePBX might change the structure of the database / add tables to hold the additional data.

So if you now sync from your primary node to your secondary node, settings would be lost because the associated tables/fields are missing on the secondary node. Conversely, if you now sync from your secondary node to your primary node, settings would be missing because the necessary source settings are absent. (See image below). This is why the HAAst installation guide and maintenance manual provide specific installation/upgrade instructions relating to FreePBX. Every year we have at least one customer that damages their FreePBX cluster because they did not follow the installation/maintenance guides.

Similarly, updating a module might change table structure, and that’s why we say to disable any automatic updates in FreePBX. Most other configuration generators are smart enough to detect a configuration mismatch between versions/modules, but FreePBX does not and will probably break (dialplan failure) unless the two nodes are kept identical (in terms of modules enabled/installed/versions).

Even if HAAst were to copy the metadata (table structure) as well, you would still have problems since the PHP code which makes up FreePBX will not understand the settings (if the code version doesn’t match the settings version). This may result in the PBX failing to process calls as the dialplan crashes, and/or failure to configure, and/or failing to complete an APPLY button push.

To read more about how to properly setup your nodes with FreePBX see sections 3.6 and 10.1.5 of the Detailed Installation Guide, and sections 7 and 8 of the Maintenance and Operations Guide.

If you have already corrupted your FreePBX setup and your cluster won’t process calls (due to dialplan fialure) see this forum post

Since Red Hat 8 uses SystemD, the best way to delay HAAst start is with a service timer. Create the file haast.timer in the /etc/systemd/system directory with the following contents

[Unit]
Description=Delay HAAst start by 1 minute on bootup

[Timer]
OnBootSec=1min
Unit=haast.service

[Install]
WantedBy=basic.target

Then, enable the HAAst timer and disable the service:

systemctl enable haast.timer
systemctl disable haast.service

And finally, in your haast.service file change the WantedBy line to read:

[Install]
WantedBy=haast.timer

Next inform systemd of your changes:

systemctl daemon-reload

And your HAAst start will delay by 1 minute on bootup. You can adjust the delay as you need.

This error is the result of incompatibilities between the Qt library expected by SecAst, and the Qt library installed on your system (or possibly because you are missing the Qt library altogether). SecAst version 1.7.0 is built against Qt version 5.9.8, so that is the library version you should install (at this date).

There is often a gap between the Qt version we use for a software release, and what is available across all Linux distributions / repos. (Each distribution / repo makes a slightly different version available). This problem should resolve itself once the repos catch caught up. Note that even version 5.9.8 is many releases behind the most current Qt version, so we are staying well away from leading edge.

As of July 13 2020 the Qt library available from Ubuntu 18’s official repos is 5.9.5. If you are a customer with a SecAst maintenance agreement we can build a release for you using Qt library 5.9.5 (or whatever version you need) at no charge. If you are using the free edition you can either wait (for your repo to catch up), or install the Qt open source libraries from: http://www.qt.io/download-open-source as those will always offer the very latest libraries

Many configuration generators are trying to compete with one another on secondary features – covering everything from security, faxing, messaging, email, router, SBC, security, high availability, and more. Most users disable/ignore these add-ons as they can be poorly designed or integrated (the real strength of configuration generators is in managing the Asterisk configuration files). If you are planning to use their add-ons compare each carefully to stand alone products so you know what you are getting. (You may even find that a commercial module that you are buying is just a collection of open source packages).

Next there are more sophisticated PBX’s which use Asterisk as the media engine/call processing engine but extend the functionality using a variety of other programs. PBX’s like Amtelco’s Genesis / ISS fall into this category. Telium is also pleased to work directly with manufacturers of more sophisticated PBX’s suchs as Amtelco Genesis / ISS to ensure full compatibility and deep product integration.

And finally there are some ‘closed’ PBX’s which are Asterisk based, but according to their vendors they are not compatible with ANY add-ons (unless sold from that same manufacturer). In reality we have helped customers install HAAst/SecAst/and many other 3rd party products onto these systems. However, we don’t want to upset these vendors so we leave it up to the customer to determine if they can/want to reset the root password and install other products. (It’s your product, so you probably have a right to modify it as you see fit). But we don’t offer any assistance that might violate the DMCA in the USA, or similar laws in other countries. (e.g. you can find instructions on how to unlock/remove vendor protections on the internet, but we can’t give those instructions to you). Also if you are an authorized vendor of such closed systems read your reseller agreement carefully; your customer can do what he wants with the PBX but you might violate your reseller agreement if you unlock the box for them.

HAAst tries to work well with every configuration generator. We are pleased to add support for new products/databases, but we also deprecate support for little used configuration generators / databases / features. If you are a large corporation or critical call center using Asterisk directly (no configuration generator) then HAAst can fully support you as well. You don’t need a configuration generator or add-on to use HAAst, SecAst, etc.

So if you are designing a telephony solution we recommend:

1. Pure asterisk (no configuration generator) if you are ok doing some basic diaplan coding
2. If you need a configuration generator pick one that is fully open source (avoid anything with ‘distro’ in the name)
3. Use flat-files to hold config information
4. If you need a database (or your config generator needs a database) insist on MariaDB/MySQL

If you need to stray from this advice be sure to understand the compromises you are making

I should start by saying that we don’t officially support this design because some of the steps involved are beyond the skill of an average administrator.

If you are very comfortable with networking, iptables, and routing then the answer is YES this can be done. (But our support team cannot assist you further with this topic).

Suppose you have

• one NIC in each node
• a single subnet 192.168.1.0/24 (i.e. 255.255.255.0 subnet) used by each NIC
• Node A uses 192.168.1.1, and Node B uses 192.168.1.2

and you wish to have HAAst add 192.168.1.3 to the active node (while leaving the management IP accessible). The steps to do so are:

• Setup the OS to assign the static address 192.168.1.1 and 192.168.1.2 to their respective nodes
• Setup haast.conf to enable the VoIP NIC feature, and tell HAAst to use 192.168.1.3 as the shared IP
• Setup the HAAst pre-start event handler to add the following postrouting rules in the NAT chain to source-NAT all outgoing voice traffic (5060 + RTP ports) as the shared IP:
  iptables -A POSTROUTING -t nat -p udp –dport 5060 -j SNAT –to-source 192.168.1.3
  iptables -A POSTROUTING -t nat -p udp –dport 10000:32768 -j SNAT –to-source 192.168.1.3
• Setup the HAAst post-stop event handler to remove the above rules.

The end result will be that all voice related traffic will have their headers rewritten to show 192.168.1.3 instead of 192.168.1.1 (or 192.168.1.2). Depending on the VoIP protocols you use, TCP vs UDP selection, and other socket services you offer you may have to expand on or customize these rules. But the above should be sufficient to show how to accomplish what you want.

Note that Sangoma made a change to FreePBX in late-2019 (release 1904 or later) that could cause incomplete synchronization or other failure. We recommend that all customers using FreePBX with HAAst upgrade to HAAst version 2.5.9 or later to ensure critical issues are addressed. (Now even tables with invalid structures will sync)

For further details of updates and fixes please see the ‘changelog’ file included with the distribution package.