Telium Support Group

The answer to this question depends on the specific product you are referring to. However, here are some points to consider:

1. Most manufacturers require that only a single copy of a license be in use at one time. Since HAAst keeps only one Asterisk peer active at a time, you should be ok keeping the same license on both computers peers at once and remain compliant.
2. Some manufacturers require that only a single copy of a license be installed at once. Using the pre-start & post-stop event handlers you can move the licenses into place before Asterisk starts, and out of place after Asterisk stops, and remain compliant.
3. A few manufacturers require that you purchase a license for each host regardless of whether it is used for standby/clustering/testing/development/etc. However, most manufacturers will offer such a license at no/minimal charge.

When you evaluate licensed products for purchase, the above should be one of your evaluation criteria. Most manufacturers are reasonable and recognize that charging for a standby license is excessive – and only antagonizes their customers. Still…we know of one manufacturer in particular that takes a rather hostile view towards their customers and expects a full price license even for standby servers. In some cases you may find open source alternatives that help alleviate unfair license restrictions (for example see: https://telium.io/topic/g729-licenses-invalidated-after-cluster-failover/)

Note that SecAst (Security for Asterisk) includes a second no-charge license for use in a HAAst cluster; so one license covers 2 peer installations.

Please note that the above is not legal advice – you should check with your legal counsel for all matters of license compliance, etc.

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

Support hours available to you depend on the edition of HAAst you are using, whether you have an active maintenance agreement, and whether you have a 24/7 support contract:

1. All users: Telium offers self-serve forums for users of non-commercial and commercial editions of its products. These forums are monitored by Telium support and questions are answered on a best effort basis.
2. Maintenance Agreements: Telium offers e-mail support during business hours for users with an active maintenance agreement. Telium business hours are 9am-5pm Eastern time, Monday to Friday (except holidays). Typical response times are under an hour, and typical problem resolution is less than 30 minutes. Telium may also respond up to 11pm Eastern time on weekdays, and anytime on weekends – depending on whether an on-call support rep was already activated for a 24/7 Support Contract (and answers outstanding questions before wrapping up).
3. 24/7 Support Contract: Telium offers 24/7 support for users who have a 24/7 support agreement in place. Support is offered by phone / skype / teamviewer / email / chat / etc, and includes rapid callback from the account manager / support lead / on-call technician (depending on time of day). Typical response times are under 20 minutes, and typical problem resolution is less than 30 minutes. Note that remote desktop connections are only for simple viewing/assistance, not complex work or complete installations.

So if it’s 2am Pacific time and you don’t have a 24/7 support contract in place then your only course for immediate support is the online forums.

Please note: If you are doing an installation and would like to book assistance from Telium professional services outside of normal business hours, we would be happy to work with you anytime from 8am to 2am Eastern time to perform your installation.

The license file contains a ‘signature’ to verify the license has not been changed. You are inadvertently changing the license file; there are subtle differences between Linux text files and Windows text files. (In particular, Windows uses CRLF while Linux uses CR only.) You don’t need to know the details, but even opening the file in Notepad and then saving it again is changing the file!

This time go to your mail client and save the attachment directly from the message (without opening in Notepad) to the PBX. Your license should then work fine.

Exit code 158 means that HAAst is unable to find the service/executable file needed to control Asterisk. Since you installed Asterisk from source, I assume you are not using any configuration generator (eg: Elastix) as well. If that’s the case then the ‘distribution’ setting in the [asterisk] stanza of the haast.conf file should be set to 2 (Digium Asterisk). Confirm that setting – then proceed to the steps below if the error remains.

Next ensure that you installed an Asterisk service file appropriate for your Linux distribution. Most recent Linux distributions have switched to systemd, which requires you use an asterisk.service file. If you are using an older Linux distribution then you require a SysV / initd style service file.

While Asterisk includes a sample SysV style service file for Asterisk, it might not include a systemd style service file just yet (as of Dec 2016). You can find one by searching the Digium support forums, but here’s an example you can use:


[Unit]
Description=Asterisk PBX and telephony daemon
Documentation=man:asterisk(8)
Wants=network.target
After=network.target
 
[Service]
Type=simple
User=asterisk
Group=asterisk
ExecStart=/usr/bin/asterisk -f -C /etc/asterisk/asterisk.conf
ExecStop=/usr/bin/asterisk -rx ‘core stop now’
ExecReload=/usr/bin/asterisk -rx ‘core reload’
 
[Install]
WantedBy=multi-user.target


Save the above as ‘asterisk.service’ and place it in /etc/systemd/system/ and set file permissions to 755. Don’t add restart directives (like you might find on the internet) since HAAst should be responsible for restarting Asterisk when necessary. You will also have to tell Linux about the new service file with the ‘systemctl daemon-reload’ command (or similar depending on your Linux distro).

If you want to use the SysV / initd style service file that’s ok too, but you’ll need to tell HAAst which style of service file you are using. To do so contact Telium support and we will provide you with details specific to your Linux distribution. (But in general if your Linux distro uses systemd, stick with systemd service files).

The problem is that you have a space character after the backslash on line 5 (based on analyzing the config file sent). If you add any character after a backslash it means ‘escape’ as opposed to ‘continuation’. So SecAst stops reading your excludes at line 5.

The solution is to ensure you have no characters following the backslash character.

Yes. No problem!

Many call centers are keeping their primary PBX’s on site (for performance and other reasons), and using the cloud for their backup PBX’s. HAAst will run on Amazon Web Services (AWS) + Amazon Elastic Cloud 2 (EC2), Microsoft Azure, and more, to create your primary PBX, backup PBX, or both. You can even place the HAAst operational database in Amazon Relational Data Services (RDS) or equivalent with both peers writing performance and operating data to the shared database. (The HAAst web GUI allows you to view combined and individual PBX reports in many areas). We do not recommend placing Asterisk configuration databases in RDS or equivalent – but this should not be a problem as they are fairly static and small.

Unlike other open source and closed source commercial HA products, HAAst does not use any LAN based protocols (NFS/DRBD/hearbeat/etc). HAAst is designed around only WAN based protocols, primarily it’s own PeerLink protocol. HAAst can accommodate large swings in network latency as would be seen in links between in-house servers and the cloud. HAAst (Commercial Unlimited edition) even learns these variations and adapts to the changes, so you never have a false positive fail-over of the cluster. This approach allows customers to even place their PBX instances in different Amazon Recovery Zone’s, and in different Regions.

With AWS, or any cloud provider, you will want to use their static network hardware option; Amazon calls it Elastic Network Interfaces (ENI). As of August 2016 Azure (ARM and ASM) support static network hardware (MAC address).

Telium’s call continuity feature (available in HAAst OEM edition) maintains all SIP/RTP traffic data in the event of a failover. When HAAst transitions from one cluster node to another, HAAst reconstructs the calls in/out of Asterisk exposing identical IP/port numbers to the outside world. The allows calls to resume without any user agents realizing a cluster failover has taken place. HAAst can also initiate events with Asterisk to resume call recordings, log data, etc. ensuring business requirements can be satisfied as well.

If you cannot use Telium’s call continuity capability you can still create a simplistic workaround. First of all it’s important to understand the limitations of the SIP protocol (regardless of HA product), and then design around those limitations. The SIP protocol does not allow for the midpoints (e.g. PBX) or endpoints (e.g. phone) to be seized without the midpoints/endpoints participating in SIP negotiation. This means that failure of a midpoint or endpoint results in failure of the call(s) since SIP communications cease. A future version of SIP may support seizing channels, but the IETF has not indicated any such upcoming functionality.

We know of at least one product on the market that claims a proprietary / ‘patented’ way to keep SIP calls up, but all they do is introduce a SIP proxy in front of the PBX which tries to re-establish the missing leg of a dropped call. These products don’t have much commercial success because they introduce a new single point of failure in front of the cluster (so if the proxy dies the entire cluster dies). In the case of power outage or network outage these proxy solutions do nothing and all calls drop. Telium has worked with vendors to design solutions for emergency call centers, hospitals, large commercial call centers, etc. and they all frown on placing a single point of failure in front of the cluster. An on-PBX solution (as offered by Telium) is the preferred solution.

Even large proprietary PBX vendors don’t support salvaging SIP calls in case of a complete PBX failure. They may offer “HA” options which transition calls in progress within or between PBX’s so long as the core of the PBX is still functional (so for example the PBX could withstand a media processor failure). However, they cannot salvage SIP calls in the event of a complete and immediate disconnect of the PBX (e.g. power failure, data center network failure, etc).

If you really want to try to salvage calls in progress (sometimes called ‘call continuity’ or ‘call survival’) with a do-it-yourself solution the best way to do so is at the ITSP/trunk provider. You can request that your carrier redirect any calls in progress which terminate without a SIP BYE command be redirected to a backup number/trunk. If your ITSP/Carrier will not do so, you can create your own SIP proxy but it should be collocated at your ITSP/carrier’s POP. Placing such a proxy on your premises is worthless (your cluster will appear to perform well in simplistic tests, but fail in real world outage scenarios), and is no different than the solutions mentioned above. You can try to use direct media with user agents (phones) that don’t drop a call if the SIP connection is unresponsive (eg; to registration) but this depends heavily on details of your implementation.

We would like to emphasize that Telium discourages adding a black box device or proxy in front of a cluster. However, if you still want to go down the DIY path you can create an open source version of the above (not recommended) product as described here: https://telium.io/topic/patented-call-survival-add-on/ or you could design a solution which attempts to keep RTP up without SIP (we have a few posts on that topic).

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