Home › Forums › HAast (High Availability for Asterisk) › General › Patented call survival add-on
-
AuthorPosts
-
I’m looking for an HA solution for Asterisk, and yours seems to check off all of the boxes except call survival (available as “OEM” edition only). Does that mean I can buy the OEM edition? I found one product that says it does “call survival” using a patented technology (but nothing else in terms of features). Can you confirm if your product does call survival, or how it compares with the call survival feature of a competitor? Can I use you HAAst product in combination with their call survival tool?
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://autocommander.aws2.ocg.ca/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:
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.
Thank you! I had no idea that their HA solution was just placing a proxy in front of each PBX. I called them to confirm and you are right. And this makes no sense. And by the way, i dug a little deeper and it turns out their “cluster” software has no sensors – other than the Asterisk process dying. So no detection of failed routes, failed disks, depletion of file handles, etc…all the ways that Asterisk dies in real life. Even worse, ask them about data synchronization and you are in for more surprises. All they are really selling is a pair of SIP proxies and forcing you into their Asterisk GUI !!!!
I am running one PBX at each data center, and if the Asterisk process stopped bridging calls or the power went out to the DC or the network connection was lost to the DC their solution would NOT keep any calls up. Thanks for your information above. I would never have thought to ask such an obvious question. (It just seemed too stupid to be selling a SIP proxy as an HA solution!!!)
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://autocommander.aws2.ocg.ca/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, 7 months ago by
WebMaster.
-
AuthorPosts
- You must be logged in to reply to this topic.