Telium Support Group

Yes – you will need HAAst version 2.5.0 or later for Asterisk 16 support

Telium’s software is an standalone product, which can run with pure Asterisk, as well as with configuration generators like Issabel, FreePBX, PIAF, etc. Telium’s software is not a plug-in module of FreePBX. (Sangoma signing applies only to FreePBX modules. ) HAAst operates between the operating system and Asterisk levels, while FreePBX operates above Asterisk as a ‘configuration generator’ that presents a pretty GUI and creates Asterisk config files for you.

You should also be aware that some companies use module signing to protect their system, while other companies use module signing solely as a way of generating profits. In the latter case any developer can have their module signed if they pay for a signing key – even a bad module which steals your data or crashes your PBX can be signed. So signing is not always meaningful, but will always increase your cost.

So module signing does not apply to HAAst, but be sure you understand the benefits really provided by module signing in the case of FreePBX.

I’ll start by answering this question in the context of ANY cluster (eg: gateway cluster, router cluster, file server cluster, etc.). If the nodes which make up the cluster cannot talk to one another then they have no way of knowing if the other node is dead or alive. As such, the correct action for any isolated cluster node is to promote to active and assume the other node is dead. Once the nodes contact each other again they discover that multiple nodes are active (a situation called “dual-active contention”). Then the nodes should negotiate who should remain active, and who should demote itself.

This is exactly what happens with HAAst. If the management connection between nodes is lost, then there is no way for either node to know that the other is alive. And so both nodes try to take over telephony service. Once the nodes reconnect then one node will automatically demote itself.

You will find this scenario plays out identically with any commercial HA product (eg: CISCO routers with HSRP). Dual-active contention is the worst case scenario for any cluster as the two nodes are competing, and they will both contend for the resources / traffic / data / etc.

There is a workaround called STONITH – available using event handlers in the Commercial Unlimited edition of HAAst. STONITH is an acronym for “Short The Other Node In The Head”, which basically tells one node to power off the other node. Although HAAst supports STONITH this functionality is disabled by default as the concept of STONITH is hotly debated as risky (a failing node may mistaking shoot the healthy node). And there are many scenarios where STONITH does not work (eg: two isolated nodes) without another out of band connection (eg: serial, 3rd network connection, etc)

This message means that the operating system is having trouble enumerating hardware on your host. This is due to a bug in your BIOS or Linux OS.

Telium software tries to work around this bug, and everything SHOULD work fine. But if you have any problem with hardware failure detection or licensed features please contact Telium support and we’ll try to incorporate a fix specific to your BIOS/Linux.

All of our support services are in English. We have some native French, German, and Hindi language skills, but that depends on the support representatives on duty.

However, for customers who can’t speak English we try to support them through Google Translate, translating each message in/out to the language of the customer’s choice.

(Sin embargo, para los clientes que no hablan inglés, intentamos ayudarlos a través de Google Translate, traduciendo cada mensaje de entrada / salida al idioma que elija el cliente.)

We would be happy to SSH into your hosts to help with configuration.

Our support machines have pre-installed VPN clients for the most popular protocols: Microsoft Windows protocols (PPTP/L2TP/IPSec/IKEv2), and Cisco VPN protocols (IPSec, PPTP/MPPE, L2TP/IPSec).

If you chose not to use one of these protocols, or you require that we install a VPN client that is locked to your VPN concentrator / host, then we must build a virtual machine for our support techs to use when connecting to your system. Our support techs cannot (and may not) install any other software on their machines, in order to protect our computing environment.

If you cannot use one of the pre-installed VPN protocols above, and you cannot port forward SSH from your public IP to your nodes, then we will have to charge you an additional 2 hours of support time to build and maintain a support VM dedicated to your environment. We will also archive this VM (while your maintenance agreement is active) to ensure we can continue to support you going forward.

See FAQ 10042 for additional information: https://autocommander.aws2.ocg.ca/faq1042

HAAst can handle that easily using the event handler system. There are 2 aspects to your cluster that must be handled separately: the FreePBX configuration, and the Asterisk configuration. Remember that FreePBX is a pretty GUI with it’s own configuration database (in MySQL), and it regenerates the Asterisk configuration files (flat files) when you click apply changes. So we have to handle each a bit differently.

I should also point out that because FreePBX creates a relationship between DIALPLAN->ROUTES->TRUNKS, you cannot simply delete a trunk on one node but have it present on the other. To effectively remove the second trunk from London we modify one trunk configuration to ensure it cannot be activated by Asterisk (so it will be ignored in the dialplan). We do so by setting the SIP port to an invalid number.

FreePBX Configuration
To make your life simpler (and setup less confusing), on your New York FreePBX name your NY1 and NY2 trunks:

Quote:
MASTER_TRUNK1 (for the trunk)
MASTER_TRUNK1_IN (for inbound)
MASTER_TRUNK1_OUT (for outbound)
MASTER_TRUNK2
MASTER_TRUNK2_IN
MASTER_TRUNK2_OUT

Next, add to your New York FreePBX your LON trunk named exactly as follows:

Quote:
SLAVE_TRUNK1 (for the trunk)
SLAVE_TRUNK1_IN (for inbound)
SLAVE_TRUNK1_OUT (for outbound)

Finally, add to your New York FreePBX a duplicate the above SLAVE_TRUNK1 to be named SLAVE_TRUNK2:

Quote:
SLAVE_TRUNK2
SLAVE_TRUNK2_IN
SLAVE_TRUNK2_OUT

In FreePBX (on Master) edit your routes to use:

1. MASTER_TRUNK1
2. SLAVE_TRUNK1
3. MASTER_TRUNK2
4. SLAVE_TRUNK2

in that order. Don’t worry about NY using SLAVE trunks, or London using MASTER trunks. HAAst will disable them to ensure only the right trunks are used in the right location.

HAAst FreePBX MySQL event handler
HAAst will be responsible for enabling all master trunks in New York (and disabling all slave trunks), and enabling all slave trunks in London (and disabling master trunks there), and changing the external IP address (for SIP config). HAAst will also disable SLAVE_TRUNK2 in London so it won’t be used (contents ignored). HAAst will also change the external IP address in SIP settings. Assuming that you are using the sample HAAst configuration file for Sangoma FreePBX, you will have a sync job named ‘freepbx-mysql’. You need to create a post-sync event handler (file) called sync.stop.post.freepbx-mysql in the /usr/local/haast/events folder. That event handler will be responsible for enabling/disabling trunks:


#!/bin/bash

HAAst Asterisk file event handler
HAAst will be responsible for ensuring the trunk information (in sip.conf) has the contents appropriate for the node it is running on. There are also 2 distinct use cases we must consider. First use case: if SLAVE becomes active and the admin edits the configuration in FreePBX then Asterisk must accept that configuration and run normally (even if no event handlers have run). In this case there is nothing to be done since the disabled trunks will not generate any config data for Asterisk since they have been disabled in FreePBX. (Nothing to do). Second use case: The Asterisk configuration files from MASTER has been sent to SLAVE, and the SLAVE trunks contain information relevant for New York. To handler this situation we replace trunk content (in the Asterisk config files), and we also remove the MASTER_ prefix from any Asterisk config files (for clarity). Assuming that you are using the sample HAAst configuration file for Sangoma FreePBX, you will have a sync job named ‘freepbx-conf’. You need to create a post-sync event handler (file) called sync.stop.post.freepbx-conf in the /usr/local/haast/events folder. That event handler will be responsible for modify the Asterisk config files:


#!/bin/bash

Notice that the above event handler also disables TRUNK2 by adding an incorrect sip port number (9999), and uses the open source ‘crudini’ package to accomplish this. This will cause the trunk connection to fail, and Asterisk will ignore the trunk. The result is that the ROUTES as setup in FreePBX will skip this trunk.

Notice as well that we hard coded a bit of information at the start of the event handlers; this is for simplicity. If you want to get really fancy, you can extract the relevant trunk data from the MySQL database and use that to update the Asterisk files. But the above explains the concept in the simplest way possible.