<!DOCTYPE html PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN'>
<html><head><meta http-equiv="Content-Type" content="text/html;charset=us-ascii">
<style>BODY{font:10pt Tahoma, Verdana, sans-serif}</style></head><body>
<DIV>Tony,</DIV>
<DIV> </DIV>
<DIV>I'm glad you're thinking this way. I've been looking into this myself, and I think we both got the same idea. I've been playing around with how to hook up the eventing system to external Service Bus implmentations as a starting point. Is there a chance we could all plan a meeting on the FS conference (out of band from the wednsday meetings) to maybe discuss this with the interested ppl?</DIV>
<DIV> </DIV>
<DIV>--Dave</DIV><BR>
<BLOCKQUOTE style="BORDER-LEFT: #0000ff 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px">
<HR>
<B>From:</B> Anthony Minessale [mailto:anthony.minessale@gmail.com]<BR><B>To:</B> FreeSWITCH Users Help [mailto:freeswitch-users@lists.freeswitch.org]<BR><B>Sent:</B> Mon, 11 Feb 2013 13:30:25 -0800<BR><B>Subject:</B> Re: [Freeswitch-users] High Availability Cluster Module for FreeSWITCH<BR><BR>
<DIV>I believe some more planning and thought needs to go into this before proceeding with code.
<DIV>I recommend a continued discussion. My point of view is we should specifically review the way FS does the message exchange since its the cornerstone of many other possible cluster scenarios besides just fault tolerance. Some are starting to build this externally and I think the real answer is a more clean abstraction between the framework for many FS communicating with each other and the business logic. So some of what people like plivo and 2600hz do externally would be better served as part of FS at the comms level and then still separate the logic. That way everyone can benefit from the low level code.</DIV>
<DIV><BR></DIV>
<DIV> </DIV></DIV>
<DIV class=gmail_extra><BR><BR>
<DIV class=gmail_quote>On Mon, Feb 11, 2013 at 12:37 PM, Henry Huang <SPAN><<A href="mailto:red.rain.seven@gmail.com">red.rain.seven@gmail.com</A>></SPAN> wrote:<BR>
<BLOCKQUOTE style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class=gmail_quote>
<DIV>
<DIV><FONT color=#333333><FONT size=+0><FONT face=verdana,sans-serif>I would choose to go<FONT size=+0> with </FONT></FONT></FONT></FONT>Elliot's idea of having the HA being build within the FS itself under the condition that it's a easy adaptation comparing to having to use and struggling with Pacemaker and Corosync. They can literally take months if someone is starting from scratch. <BR><BR></DIV>And it would be nice to have this kind of capability to go against those brand name solutions.<SPAN name="Eliot Gable"></SPAN></DIV>
<DIV class=gmail_extra><BR><BR>
<DIV class=gmail_quote>
<DIV>
<DIV class=h5>On Mon, Feb 11, 2013 at 6:06 AM, Eliot Gable <SPAN><<A href="mailto:egable+freeswitch@gmail.com">egable+freeswitch@gmail.com</A>></SPAN> wrote:<BR></DIV></DIV>
<BLOCKQUOTE style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class=gmail_quote>
<DIV>
<DIV class=h5>
<DIV>On Mon, Feb 11, 2013 at 7:36 AM, Marcin Gozdalik <SPAN><<A href="mailto:gozdal@gmail.com">gozdal@gmail.com</A>></SPAN> wrote:<BR></DIV>
<DIV class=gmail_quote>
<DIV>
<BLOCKQUOTE style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class=gmail_quote>+1<BR><BR>I do not doubt mod_ha is necessary inside of FS and it may be<BR>better/simpler than writing Pacemaker resource agent, but writing<BR>yet-another-cluster-communication-engine is IMHO the wrong way to go<BR>and using Corosync for communication will give a lot of value from<BR>mature codebase.<BR><BR></BLOCKQUOTE>
<DIV><BR></DIV></DIV>
<DIV>I understand what you are saying, but what I am trying to get across is that I am not writing yet-another-cluster-communication-engine. All I am really doing is combining a multicast messaging API written by Tony and the event API in FS to broadcast existing state information between multiple FS nodes, as well as adding a tiny amount of logic on top of that to coordinate call fail over and recovery. That's probably a little over-simplified, but it gets the point across. The network communication code is already in FS and well tested. The event system is already in FS and well tested. I have already written the code to the point that it parses the configuration files and starts sending heartbeats out all of the interfaces configured. I have also already written a lot of the code that deals with the state transitions. All I am talking about doing is implementing a tiny little finite state machine. It's a pretty trivial programming task. In fact, I think it was covered in my first year at Carnegie Mellon University. Of course, I had already figured out how to write such things in high school, I just did not know what it was called at that point. My point is, that this is not yet-another-cluster-communication-engine. It is a very specific and small finite state machine designed solely with the goal in mind of making FS have just enough information to coordinate call fail over internally. If I recall correctly, a lot of people also said writing yet-another-VoIP-server was a waste of time, but now we have FreeSWITCH, and it was obviously worth the effort. And I am not even trying to do something as complex as that. If you think this is yet-another-cluster-communication-engine, you are missing the point. It is not. It never will be. </DIV>
<DIV><BR></DIV>
<DIV>Look at Sonus, Genband, Broadsoft, Veraz, etc. All the big-name carrier-grade telecom providers have a built-in solution for automatic call fail over. The only way FreeSWITCH will ever compete with such solutions is if it also has that feature. Pacemaker and Corosync are overkill just to get FS to handle single node failures and provide call recovery. It took me a full 3 months of working with them every day to really understand how to deploy them properly in conjunction with FreeSWITCH and Postgres to provide a carrier-grade hot-standby solution which was robust enough to handle 99% of the failures I could throw at it. Granted, this was back when the configuration still needed to be written by hand in XML and prior the existence of any resource agent for FreeSWITCH. But, even with those changes, deploying Pacemaker and Corosync is not a simple task. If that is the requirement for FS to have HA, it will never truly stand a chance against commercial offerings.</DIV>
<DIV><BR></DIV>
<DIV><BR></DIV></DIV><BR></DIV></DIV>
<DIV class=im>_________________________________________________________________________<BR>Professional FreeSWITCH Consulting Services:<BR><A href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</A><BR><A href="http://www.freeswitchsolutions.com/">http://www.freeswitchsolutions.com</A><BR><BR>FreeSWITCH-powered IP PBX: The CudaTel Communication Server<BR><A href="http://www.cudatel.com/">http://www.cudatel.com</A><BR><BR>Official FreeSWITCH Sites<BR><A href="http://www.freeswitch.org/">http://www.freeswitch.org</A><BR><A href="http://wiki.freeswitch.org/">http://wiki.freeswitch.org</A><BR><A href="http://www.cluecon.com/">http://www.cluecon.com</A><BR><BR>FreeSWITCH-users mailing list<BR><A href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</A><BR><A href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</A><BR>UNSUBSCRIBE:<A href="http://lists.freeswitch.org/mailman/options/freeswitch-users">http://lists.freeswitch.org/mailman/options/freeswitch-users</A><BR><A href="http://www.freeswitch.org/">http://www.freeswitch.org</A><BR><BR></DIV></BLOCKQUOTE></DIV><BR></DIV><BR>_________________________________________________________________________<BR>Professional FreeSWITCH Consulting Services:<BR><A href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</A><BR><A href="http://www.freeswitchsolutions.com/">http://www.freeswitchsolutions.com</A><BR><BR>FreeSWITCH-powered IP PBX: The CudaTel Communication Server<BR><A href="http://www.cudatel.com/">http://www.cudatel.com</A><BR><BR>Official FreeSWITCH Sites<BR><A href="http://www.freeswitch.org/">http://www.freeswitch.org</A><BR><A href="http://wiki.freeswitch.org/">http://wiki.freeswitch.org</A><BR><A href="http://www.cluecon.com/">http://www.cluecon.com</A><BR><BR>FreeSWITCH-users mailing list<BR><A href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</A><BR><A href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</A><BR>UNSUBSCRIBE:<A href="http://lists.freeswitch.org/mailman/options/freeswitch-users">http://lists.freeswitch.org/mailman/options/freeswitch-users</A><BR><A href="http://www.freeswitch.org/">http://www.freeswitch.org</A><BR><BR></BLOCKQUOTE></DIV><BR><BR clear=all>
<DIV><BR></DIV>-- <BR>Anthony Minessale II<BR><BR>FreeSWITCH <A href="http://www.freeswitch.org/">http://www.freeswitch.org/</A><BR>ClueCon <A href="http://www.cluecon.com/">http://www.cluecon.com/</A><BR>Twitter: <A href="http://twitter.com/FreeSWITCH_wire">http://twitter.com/FreeSWITCH_wire</A><BR><BR>AIM: anthm<BR><A href="mailto:MSN%3Aanthony_minessale@hotmail.com">MSN:anthony_minessale@hotmail.com</A><BR>GTALK/JABBER/<A href="mailto:PAYPAL%3Aanthony.minessale@gmail.com">PAYPAL:anthony.minessale@gmail.com</A><BR>IRC: <A href="http://irc.freenode.net/">irc.freenode.net</A> #freeswitch<BR><BR>FreeSWITCH Developer Conference<BR><A href="mailto:sip%3A888@conference.freeswitch.org">sip:888@conference.freeswitch.org</A><BR><A href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org">googletalk:conf+888@conference.freeswitch.org</A><BR>pstn:+19193869900 </DIV></BLOCKQUOTE>
<STYLE>
</STYLE>
<DIV> </DIV>
<DIV> </DIV></body></html>