Telium Support Group

This may be possible but it really depends on:

• If the endpoints use TCP for the SIP connection then they may detect the cluster failover (as the TCP connection closes, possibly with a FIN)
• If the endpoints generate SIP traffic (eg: reregistering) then the lack of response or out of sequence response may cause the endpoint to terminate RTP connections

Telium does not provide assistance for creating this type of configuration – but we know clients have made this work. Telium only endorses the method used by HAAst OEM edition, as this is the only proper means for call continuity.

Once you have received the USB dongle(s) containing your license,

1. Plug each dongle into the appropriate physical machine. (The dongle will have a tag attached showing the machine name, in case you have multiple dongles).

2. From the VMware console edit the virtual machine, and add a new USB device:

3. Select the device name which should be something similar to “Phillips Elite”, and click save. (On some occasions you have to shut down and restart the VM for the hardware to be added).

4. From the VM’s command line, confirm in Linux that the USB dongle is present using the “lsusb” command. Notice the Phillips (NXP) device is present – that is the USB dongle.

5. Telnet to the local PBXSync instance and issue the “license usbdongle” command and follow the steps presented on screen.

• This reply was modified 4 years, 4 months ago by WebMaster.

Asterisk 16 has numerous architectural changes that impact connected products. Our development team has implemented Asterisk 16 compatibility, but will not release thr code until Asterisk 16 has stabilized, and we see companies implementing Asterisk 16 in production.

As of March 2019 Asterisk 16 is not widely placed into production yet, and so we advise you to NOT upgrade to Asterisk 16 at this time. Since you are a registered HAAst user you are welcome to download a pre-release version of HAAst which supports Asterisk 16.

Asterisk 16 has undergone some significant changes since initial release, and until the product has stabilized we do not recommend placing Asterisk 16 in production.[/i][/color]

The problem you are encountering has nothing to do with HAAst, and everything to do with the basics of networking. You have setup 2 NIC’s in each PC, but they are on the same subnet! That means that Linux has no idea where (out which NIC) to route traffic for your 192.168.1.0/24 subnet. You should not do this as it confuses Linux. This topic is part of what’s known as “multihoming”, and I would suggest you research this topic a bit further before you continue to setup your networks. As well, reread the HAAst installation guide – there’s a bit more information on this topic there. (This isn’t the first time we’ve seen this issue in the support group).

By shutting down NIC1 on either PC you allow Linux to figure out how to properly route, but then your management NIC is gone so the cluster fails over.

The solution (for 2 NIC’s per PBX) is to ensure that each NIC is on it’s own subnet. For example:

Whenever you switch from a standalone to a clustered PBX there will be an outage. This can last from seconds to an hours depending on how to perform the cutover.

It is possible to install HAAst into a live environment, but the “best” way depends a bit on your situation. If you cannot tolerate downtime, then you need to:

1. Install HAAst on the live system but do not start the HAAst service
2. Setup the second node (Asterisk and HAAst) but do not start the HAAst service
3. Fully configure HAAst so the nodes will see each other
4. At the next failure, maintenance window, or opportunity you chose, start the HAAst service on both nodes and the cluster will form

If you are running FreePBX as your configuration generator we do not generally recommend the above approach, as FreePBX will crash/misbehave if you synchronize configuration data from (even slightly) different versions / enabled options / installed options. (And it’s very easy to accidentally install/enable different modules on FreePBX nodes). For this reason if you run FreePBX we recommend the following procedure:

1. Install HAAst on the live system (per the installation guide)
2. Configure HAAst on the live system
3. Apply any Asterisk updates you wish
4. Finalize your Asterisk dialplan and ensure Asterisk works as you wish
5. During your maintenance window shutdown the PBX
6. Use ‘dd’ or similar tool to mirror the PBX to a second PBX
7. Restart both PBX’s (leave the new PBX unplugged from the network)
8. Customize the second PBX with unique network and HAAst information
9. Reconnect the second PBX to the network and the nodes should find each other
10. The nodes should now report the cluster is live

At a high level this should get you up and running with a working cluster. Our detailed installation guide has more specifics that take you through each of the steps above. As well, be sure to read the maintenance guide for instructions on updating.

When Telium performs a live site installation, we bring up the cluster with minimal interruption in phone service (unless of course the customer approves more extensive failover test) as described above.

HAAst depends on Asterisk to report the number of calls in progress. From the Asterisk CLI issue the command “core show calls” and you will see how call are calculated/reported.

If you are running a configuration generator (eg: PIAF, FreePBX) then you will discover that the configuration generator triggers automatic internal (local) calls every X seconds to handle time variable updates and other checks. (Not a good design as they are loading up your PBX with background “calls”). There have been an number of discussions about this topic (on various websites) and causing a lot of frustration with users who are seeing their PBX being loaded up with CPU/disk activity to do little more than update a variable. Since some product vendors only have PHP development experience they must solve every problem using PHP scripts, call files, etc. Other vendors are quite sophisticated (eg: code in C++/C) and their products (eg: XCally) use minimal system resources.

If you are running only Asterisk then check for channels not being released. (There are some documented bugs in Asterisk – depending on the version you are running).

HAAst is correctly NOT failing over because your PBX is operational and in-progress calls remain up. From HAAst’s perspective your PBX has reached capacity (but is still operational).

First of all, be careful you don’t try to solve a security problem with an HA solution. Even if HAAst fails over to the other node, then that other node will subsequently be subject to those same DoS attacks and it will fail back, etc. So HA failover is not a solution. If you want HAAst to failover once your number of RTP ports in use reach a threshold you set, you can setup a HAAst sensor to monitor the number of RTP ports in use and factor this into each node’s health score. Then, HAAst will failover once the threshold you set for that sensor has been reached.

Second, a more appropriate solution is to block the DoS attacked. Have a look at our Security for Asterisk product (http://www.telium.io/?secast) which is designed to block DoS attacks (and a lot more).

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://telium.io/faq1042