Telium Support Group

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 shared Cisco VPN protocols.

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 address, 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 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

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

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.

Could you post the [database] stanza of your secast.conf file?

Does the contents of the database appear correct in the web interface?

There’s the problem: you are running a derivative of Red Hat 6 yet the rpm command you issued above was trying to install a package designed for Red Hat 7. That’s why you got the GLIBC error.

If you google how to add EPEL to your distro (CentOS 6) you will find detailed instructions; or try this link: https://www.tecmint.com/how-to-enable-epel-repository-for-rhel-centos-6-5/ That will make installation of qt5 (and other non-core packages) easier.

If you want to install a single package directly from a repo (as you did above), you can do so but ensure you are using CentOS 6 repo. (Not CentOS 7).

From your ldd output it appears that you are missing the Qt5 package(s). It’s not clear why you cannot install the packages qt5-qtbase and qt5-qtbase-mysql packages. The ldd output you posted just says qt5 packages are missing.

I have a feeling there is something else you are not telling. Why are you talking about glibc? (The libc.so is installed and running fine according to that ldd output).

Are you also getting a GLIBC error? In that case you probably mixing packages / programs designed for different versions of the operating system.

Distribution type 11 would be correct for your setup, so that’s not the problem. I would focus solely on ensuring HAAst can start your FreePBX instance properly. The problem could even be that FreePBX is starting but shutting down with an error code, or is getting severely delayed (see Sangoma notes on very slow FreePBX startup) causing HAAst to treat the startup as failed.

I would suggest you look at:

1. Try to start/stop the FreePBX service using systemctl from the commandline. Does Asterisk start/stop properly with it?
2. Confirm permissions on FreePBX and Asterisk resources, relative to who you are logged in as (and relative to root)
3. Start FreePBX using the commands within the systemd service script directly to look for errors
4. Look for FreePBX startup errors
5. Look for severe FreePBX startup delays (and follow Sangoma wiki instructions on correcting very slow startup if necessary)

Yes – you can create a high availability cluster for your VICIDIAL server, using our HAAst product. With HAAst you can have 2 VICIDIAL servers, and all clients will automatically connect to the active node (server). In case of any type of failure of the active node, the standby node will take over and agents can continue making calls through the other server. All of this happens automatically in the background.

There’s a lot more to it (HAAst will synchronize settings, voicemails, call scripts, VICIDIAL settings, etc) to ensure your nodes are always in sync and one node is always ready to take over, and HAAst will sense failures, control active nodes, etc. But the bottom line is that HAAst will solve your problem.