Forum Replies Created

Viewing 15 posts - 151 through 165 (of 258 total)
Previous 1 2 3 … 10 11 12 … 16 17 18 Next
  • Author
    Posts
  • Avatar photoTelium Support Group
    Participant
    June 9, 2017 at 11:28 am
    Post count: 264
    in reply to: Call handling limit on Free Edition #6709

    The call handling limit of the Free Edition means that exceeding 3 simultaneous calls will shut down HAAst (and implicitly Asterisk with it).

    The Free Edition allows you to test compatibility, features, usability, etc. which is usually sufficient for a trial, or even for a small office wishing to create a cluster. The Free Edition is not designed to handle the full call load of a mid to large size business, nor offer all features (of the Commercial Unlimited Edition).

    If you wish to conduct a pilot with all features enabled and capacity limits removed we would be happy to work with you on the pilot (see https://telium.io/faq1002) and provide a temporary Commercial Unlimited Edition license.

    Avatar photoTelium Support Group
    Participant
    June 7, 2017 at 1:33 am
    Post count: 264
    in reply to: HAast OEM Edition UA / unique ID is wrong #6708

    To understand what is going wrong you need to understand a bit more about the HAast CC module. The CC module acts like an SBC or proxy, in that all external UA’s (or services/devices) connect to the CC module, and the CC module connects to Asterisk. Each “session” is actually split into two sessions.

    In the event of cluster failover the UA sessions move to the other node, while the Asterisk sessions are rebuilt. The CC module rebuilds conferences, queues, calls in progress, etc. on Asterisk and then bridges it back to the matching outside UA session.

    With the Unlimited edition the call UniqueID found in asterisk matches what was seen at your gateway. With the OEM edition the call UniqueID found in Asterisk will be different that was is seen at your gateway (the CC module is bridging two separate sessions). In order to for your app to get the UniqueID (or any Asterisk variable) you must use the CC module API and ask it to provide a mapping between the external and internal session variables.

    HAast OEM uniqueid session

    Avatar photoTelium Support Group
    Participant
    May 3, 2017 at 5:48 pm
    Post count: 264
    in reply to: Switching away from FreePBX requires new HAAst license? #6706

    As customers become more sophisticated they often outgrow configuration generators and move to pure Asterisk(TM) from Digium. This has no impact on HAAst.

    HAAst operates at a layer beneath Asterisk, so it doesn’t care if you change configuration generators, Asterisk versions, etc. Your license will continue to operate just fine after your switch.

    Avatar photoTelium Support Group
    Participant
    May 3, 2017 at 12:56 am
    Post count: 264
    in reply to: Cluster status via socket #6704

    To help customers trying to extract status information, here is a sample python script that retrieves and prints the local status:


    # Example python script to retrieve local HAAst status
    import socket
    import sys
    # End of packet marker
    READYPROMPT=’ready>’
    # Create a UDS socket
    sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
    # Connect the socket to the port where the server is listening
    server_address = ‘/run/haast.sock’
    try:
    sock.connect(server_address)
    except socket.error, msg:
    print >>sys.stderr, msg
    sys.exit(1)
    # Wait for a packet
    def receivepacket():
    global sock
    total_data=[];data=”
    while True:
    data=sock.recv(8192)
    if READYPROMPT in data:
    total_data.append(data[:data.find(READYPROMPT)])
    break
    total_data.append(data)
    if len(total_data)>2:
    #check if end_of_data was split
    last_pair=total_data[-2]+total_data[-1]
    if READYPROMPT in last_pair:
    total_data[-2]=last_pair[:last_pair.find(READYPROMPT)]
    total_data.pop()
    break
    return ”.join(total_data).replace(‘r’,”).replace(‘nn’,’n’)
    # Send a packet
    def sendpacket(message):
    global sock
    success = 1
    try:
    # Send data
    message += ‘nn’
    # print >>sys.stderr, ‘sending “%s”‘%message
    sock.sendall(message)
    amount_received = 0
    amount_expected = len(message)
    while amount_received < amount_expected: data = sock.recv(16) amount_received += len(data) finally: # print >>sys.stderr, ‘closing socket’
    # sock.close()
    success = 0
    return success
    got = receivepacket()
    sendpacket(“id:123ncommand:getstatus”)
    got = receivepacket()
    for item in got.split(“n”):
    if “local haast state formatted:” in item:
    print item.strip()
    sock.close()

    Avatar photoTelium Support Group
    Participant
    April 24, 2017 at 10:13 pm
    Post count: 264
    in reply to: Confusing instructions #6717

    We realize that some of our users are new to Linux, and that Asterisk may be the only reason they are working with Linux at all. Many long-time Windows admins have never used (or wanted to use) a command line and find the provided instructions frustrating and/or confusing.

    The problem is that we offer a very technical product (with deep integration into Asterisk and the operating system, etc), requiring a level of Linux expertise that some admins don’t have. If we offered detailed explanations for each Linux command, networking concept, operating system parameter, etc. our installation guide would be huge. Sadly this is not an option for us.

    If you are a commercial user we recommend purchasing installation assistance allowing our professional services group to perform the installation for/with you. We can offer a turnkey solution (from design through implementation) or just step in where you need help.

    If you are a home user you may be better off using a ‘built-in’ option provided by one of the many configuration generators out there. You will be losing a substantial number of features and capabilities, but at least you can install a ‘built-in’ option by clicking BUY/INSTALL on a GUI. Please note that HAAst, SecAst, and SecData are targeted at large and critical commercial call centers – not home office / small office environments (Telium products are on a different scale than ‘built-in’ products/modules). You are welcome to use Telium products in home office / small office environments but realize that it’s like using an 18-wheel truck instead of a bicycle. As a home user the bicycle may be a better fit.

    • This reply was modified 4 years, 8 months ago by WebMaster.
    Avatar photoTelium Support Group
    Participant
    April 23, 2017 at 10:06 pm
    Post count: 264
    in reply to: Can’t download files – all transfer types fail #6716

    The most likely causes of your failures are as follows:

    • FTP Pull: Your firewall is blocking incoming FTP data connections (TCP port 22). You can either enable incoming data connections on your firewall (not ideal), or preferably, set your FTP client to use ‘passive mode’.
    • FTP Push: Your firewall is blocking incoming FTP control/data connection (TCP ports 21 and 22), or your FTP server is not running.
    • wget: You forgot to add the ‘–content-disposition’ parameter to wget when using the HTTP URL. Either rename the downloaded file to match the package name, or add the –content-disposition parameter when using wget.
    • browser: It sounds like your browser connection is being interrupted/corrupted, and the file you downloaded is corrupt. Verify the md5 checksum of the file and try again, or switch to one of the above (more reliable) transfer methods. Browser (HTTP) download is known to be unreliable.
    Avatar photoTelium Support Group
    Participant
    April 20, 2017 at 3:11 pm
    Post count: 264
    in reply to: iptables+fireHOL not blocking IP’s #6705

    Glad you are up and running. If you need SecAst to recreate its iptables rules just restart the SecAst service (it will restore all banned IP since it keeps those in a recovery file). We’ll have to think about how/if SecAst should monitor the iptables. It’s unusual for the iptables rules to be lost (so SecAst shouldn’t have to check that) – but it’s on our discussion list.

    In regards to downloading, what error exactly are you experiencing? (Corrupt download, or download won’t start, etc). Downloading by browser is often unreliable for large files, but FTP normally works perfectly. We just tried FTP (pull) and the file downloaded perfectly (no corruption, etc). We also tried downloading with Firefox version 53 (32 bit) and browser download worked fine 2 of 3 times (one time download was corrupt so it would not untar). Similarly downloading by Chrome worked 3 of 4 times. You can see why we offer FTP…browsers aren’t great for this kind of thing. (Since this is a different topic feel free to email support@telium.io if you have more details on file transfer issue)

    Avatar photoTelium Support Group
    Participant
    April 19, 2017 at 2:38 pm
    Post count: 264
    in reply to: iptables+fireHOL not blocking IP’s #6702

    Problem 1: iptables rules not being created

    When SecAst starts it creates a SECAST chain linked into your iptables’ INPUT chain like this:


    Chain INPUT (policy ACCEPT)
    target prot opt source destination
    SECAST all — anywhere anywhere

    And the SECAST chain is where dropping of attackers’ IP’s occurs. I see from your iptables list that the above rule is missing – and that’s why you are not able to block attacker IP’s. So the question is why is the SECAST chain rule being refused/lost. Are you updating/flushing your iptables rules (eg: regenerating using FireHOL) after SecAst starts? Is there an error in the SecAst log upon service start indicating any iptables related errors?

    Problem 2: Attackers not detected

    You did not include the [asterisk] stanza of your secast.conf, so ensure the securityevents key is blank (use the AMI), or points to a valid /var/log/asterisk/messages file. That’s usually the cause.

    I suggest you stop SecAst, delete the secast log file, and restart Secast, then manually ban 1 IP. Either post the secast log (or send to support@telium.io if you are concerned about making content public) and we can look there for further clues.

    If this is a commercial environment keep in mind that we recommend blocking attackers at the network edge (firewall) – letting SecAst add rules to your firewall.

    Avatar photoTelium Support Group
    Participant
    April 13, 2017 at 4:15 pm
    Post count: 264
    in reply to: Optimal configuration and synchronization interval #6700

    By design HAAst does not use disk mirroring (e.g. DRBD) or disk sharing (e.g. NFS, SMB, iSCSI). The reason is that with these protocols file corruption on a failing peer would immediately corrupt files on the other peer, and thereby destroy the entire cluster.

    Instead, HAAst brings the peers into sync at regular intervals. These intervals should leave enough time for HAAst to detect if a peer is failing, and then prevent synchronization if a peer is unhealthy. Do not use short sync intervals to simulate a mirrored disk (that defeats the benefit of this design).

    So your sensor intervals and sync intervals should work hand-in-hand. Keep in mind that HAAst’s internal sensors run at 0.5 second intervals, but external sensors (which you define) can run anywhere from seconds to hours apart. If you are only using internal sensors then synchronization no less than 15 seconds apart is usually sufficient (but 15 seconds is unusually low/short). If you are using external sensors then set your synchronization intervals to no less than 1/2 the sensor interval time. As well, set your sync intervals to non-multiples of one another; for example, 1,2,4 minute intervals are sub-optimal (as syncs will overlap), while 2,5,7 minute intervals are better (less chance of sync overlap).

    As well, set your synchronization intervals to match the value of the file/data being synchronized. For example, it doesn’t make sense to synchronize a MySQL database every 10 seconds if it only holds configuration data that might be changed once per day. Or, if you have a very large AstDB file (eg: 10,000 FreePBX users and devices on the host) then ensure your sync duty cycle is less than 30%; for example, if it takes 30 seconds to sync your AstDB then set your sync interval to no less than 90 seconds.

    Your interval settings need to balance the benefit of keeping both peers in sync quickly, with avoiding cluster failure in the event of file corruption, and adding too much load to a host. There are of course exceptions to every rule, but the above should serve as a guideline.

    The bottom line is NO – don’t make the interval as short as possible. When Telium is engaged to setup a cluster we usually set intervals in minutes (not seconds), other than for unusual circumstances.

    Avatar photoTelium Support Group
    Participant
    April 12, 2017 at 5:26 pm
    Post count: 264
    in reply to: Terminate with exit code 156 #6699

    Exit code 156 is defined as “Failure to setup NIC control” (see the Detailed Installation Guide for the meaning of all exit code). This means that the NIC you have told HAAst to use (in the [voipnic] stanza of haast.conf) is not responding as expected or not available.

    If you set the log level to DEBUG and restart HAAst, you will see more details of what is going wrong in the haast log file. Most often this relates to configuring HAAst to use an IP address that is already in use somewhere on the network, or use an interface that is not present in the system (possibly due to a typo in the interface name). If you post the [voipnic] stanza of your haast.conf, and the output of ifconfig we can offer more specific advice.

    Avatar photoTelium Support Group
    Participant
    April 4, 2017 at 12:58 pm
    Post count: 264
    in reply to: Automatic upgrade of FreePBX #6701

    The automatic upgrade feature of FreePBX poses a number of risks to your system, including changing the cluster members to incompatible states. Telium recommends that you disable the automatic upgrades and only perform upgrades following the steps outlined in the HAAst operations guide (see https://telium.io/topic/upgrade-to-configuration-generator-freepbx/).

    Aside from risks to the cluster, configuration generators sometimes release updates that break the PBX (only to be fixed by updates a week later). Many commercial installations using configuration generators avoid updates altogether, unless absolutely necessary (for a feature or security update). Even then, updates should be carefully tested before being promoted to production servers.

    In our experience most mid to large Asterisk(TM) installations do not use configuration generators, so this problem will primarily affect home office and small office users.

    • This reply was modified 4 years, 8 months ago by WebMaster.
    Avatar photoTelium Support Group
    Participant
    March 27, 2017 at 3:27 pm
    Post count: 264
    in reply to: Patented call survival add-on #6698

    You’re welcome. I forgot to answer the second part of your question:

    Yes you can use such a call survival device in combination with HAAst. But we do not recommend it. Such a product does nothing for real life failure scenarios, but adds new single points of failure. (Nothing to gain, lots to lose). You are better off using one of the techniques described above to keep calls up.

    If you want to build your own open source version of the commercial product above have a look at https://telium.io/topic/keeping-calls-up-when-cluster-switches-to-backup-node/.

    If you qualify for the OEM edition of HAAst then let HAAst perform the full call continuity function for you.

    • This reply was modified 4 years, 8 months ago by WebMaster.
    Avatar photoTelium Support Group
    Participant
    March 27, 2017 at 2:53 pm
    Post count: 264
    in reply to: Patented call survival add-on #6696

    Many call continuity solutions don’t work in a real-life Asterisk HA context. Most HA solutions attempt to maintain in progress calls by adding SIP devices in front of SIP devices. See this posting for a detailed discussion of how call survival can work with Asterisk/SIP: https://telium.io/topic/call-continuity-survival-on-failover/

    There is one small company that claims to offer HA call survival (using their “patented” methodology). If you look closely at their patent (image reproduced below) you will see that all they have done is place a SIP proxy in front of each PBX, plus a “sip peer” in front of the SIP proxies:

    Patented call survival addon

    So, will their ‘patented’ technology keeps calls up in case of:

    • Failure of SIP proxy? No
    • Failure of “SIP peer”? No
    • Asterisk failing to bridge calls? No
    • Power failure? No
    • Loss of internet service? No
    • Failure of router/firewall? No
    • etc…

    Making things even worse, placing a new single point of failure (the proxy, or “sip peer”) in front of an existing single point of failure (the PBX) doesn’t create HA – it just creates two single points of failure! You now have to create an HA solution for your SIP Proxy as well. This type of call “survival solution” solution only works in the most simplistic scenario, like the Asterisk box powering off and everything else continuing unaffected. Real life scenarios like trunk failures, power failures at the data center, firewall failures, etc. make such a call survival solution worthless.

    Some companies attempt to keep RTP streams without SIP continuity; however, there are many reasons that SIP dialogs may occur while a call is in progress and if they don’t handle SIP then the RTP may drop. Many engineers new to SIP/RTP make this mistake – there are lots of details to consider here.

    HAast OEM edition transitions calls between nodes without placing another device in front of either PBX. HAast integrates deeply with Asterisk to ensure calls don’t drop, queues re-populate, call recording resumes, etc. The issue is not as simple as just keeping an RTP stream up. HAast takes responsibility for transitioning the calls, rebuilding the Asterisk state, and transparently allow the peers to remain in full (SIP and RTP) contact.

    • This reply was modified 4 years, 8 months ago by WebMaster.
    • This reply was modified 4 years, 8 months ago by WebMaster.
    Avatar photoTelium Support Group
    Participant
    March 22, 2017 at 2:34 pm
    Post count: 264
    in reply to: License for preproduction / testing server #6694

    Although it’s not listed on the website, we do offer a special Commercial Unlimited edition license to be used only for preproduction / testing environments. This license includes all functionality of the CU edition, but is limited to 5 simultaneous calls. This license is 1/2 the price of the regular CU edition, and optional maintenance agreement (for updates) is also 1/2 price. Please contact support@telium.io with your current customer number to purchase this license. (This version is only available to customers with at least 1 CU license).

    If your customer wants to run a high volume of calls over the testing system then they would have to buy a full CU license. We don’t distinguish between testing and production systems if both need full features and full call volume. (We also have to prevent license fraud – so a full license has to be full price).

    Avatar photoTelium Support Group
    Participant
    February 24, 2017 at 2:01 pm
    Post count: 264
    in reply to: Upgrade to configuration generator (FreePBX) #6693

    When you perform an upgrade/update to any module in FreePBX (even a minor one) there is the possibility that FreePBX will change the structure of the tables in MySQL. Since HAAst will (intentionally) not sync metadata (SQL structures), you must ensure that the peers do not attempt to synchronize data during such an upgrade/update.

    The Maintenance and Operations Guide shows the complete upgrade procedure (see section 6). But if you are very experienced with Linux & FreePBX, you can follow this short-cut:

    1. Upgrade A
      1. Unplug the network connection from A
      2. Upgrade FreePBX on A
    2. Upgrade B
      1. Unplug the network connection from B
      2. Replug the network connection to A
      3. Upgrade FreePBX on B
    3. Re-establish cluster
      1. Replug the network connection from B
      2. Wait for the cluster to HAAst restablish automatically
      3. Use the telnet/web interface to make the preferred peer active. (Or wait for automatic fallback during the maintenance window if enabled in the haast.conf file)

    The key concept here is that a standby peer must NOT be able to see an active peer which is running a different version (or different modules installed/enabled) of the configuration generator.

    Note that this applies only to FreePBX. Other configuration generators do a much better job managing settings and keeping settings-code aligned.

  • Author
    Posts
Viewing 15 posts - 151 through 165 (of 258 total)
Previous 1 2 3 … 10 11 12 … 16 17 18 Next