<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Dec 2, 2007, at 5:59 PM, Bill Binko wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"> <div bgcolor="#ffffff" text="#000000"> Hi everyone,<br> <br> I'm looking at FreeSwitch as a platform for an area where we're expanding our business. I was wondering if I could get your guidance on whether it's the Right Tool for what I need. I realize this is potentially a Troll, and I apologize, but this seems so far to be a small, positive group and I thought I'd just come out and ask.</div></blockquote><div><br class="webkit-block-placeholder"></div>Definitely not the right tool :D</div><div><br class="webkit-block-placeholder"></div><div><blockquote type="cite"><div bgcolor="#ffffff" text="#000000"> <br> First some background. I have several clients who want various value-added phone services. Basically, they want IVR systems with some bells and whistles such as recording calls, integration with their websites, and "follow me" services. My company has done similar work for clients on the GIS (mapping) side, and I have personally worked with Asterisk as a true smart PBX solution, so we are considering adding this to our offerings.<br> <br> We have a SIP-based VOIP provider in the colocation site we use that has attractive pricing and we have good direct connectivity to them, so we would like to this to be a SIP-only solution (no TDM hardware, etc.). <br> <br> As we started looking at doing this with Asterisk, we found a few things. First, there are some real issues getting clear calls through Asterisk when there is no TDM hardware in place. This seems to be due to some timing issues, and seems to be worsened by some RTC changes on Linux 2.6.x. I wasn't surprised that there were some issues, but we have had a very hard time getting it to run well on a clean distro such as CentOS without custom kernel compiles, etc.</div></blockquote><div><br class="webkit-block-placeholder"></div><div>There is no current external timing modules available. Our default timing is all done with software, and should perform well without any specific hardware. There were some recent changes that should improve performance on newer linux kernels, but that is by no means required. Our development is mostly done on RHEL and CentOS, so those should all be fine. In addition, we are making packages for a variety of linux distributions, as well as solaris and windows, those should all be available as of beta3 that should be out very soon.</div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000"><br> <br> Perhaps most concerning, we aren't seeing the kind of community support we found (and came to rely on) in the open-source GIS space. Posts to the asterisk-users board get lost on the way to the list, and when they do make it through, they get responses like "buy a Digium card just for timing". Well, in our 1U servers with only a PCI-Express slot, that's going to be a trick.<br> <br> So, I quite literally went to Google and searched for "Asterisk alternative" and FreeSwitch came up all over the place. I installed it on our server and had it running in about an hour with only minimal pain. And the sound quality (so far) has been very good when just playing recorded sounds.<br> <br> Here's my concerns about it so far - let me know if they're unfounded.<br> <br> 1) It seems to be reliant on a huge collection of external tools. I'm ok with running the FreeSwitch recommended versions of all of them, but isn't going to be a bit fragile as these tools mature separately?</div></blockquote><div><br class="webkit-block-placeholder"></div><div>Many complain about it, but we build our own versions of all of these libraries, and build against them statically. This allows us to do heavy testing against specific versions of libraries and to ensure that they work correctly, without effecting other software on the system. This will also keep upgrading of another piece of software on your system from breaking your freeswitch if there is some bug in a new version of a library. There is an extra level of work to do for us when we need to track issues and upgrade those libraries, but some of our installations, for example ss7 gear, we can not have any of the software change unintentionally due to certification requirements. Net result, it shouldn't cause issues other than you need to test before you upgrade freeswitch, which I would recommend for any software.</div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000"><br> 2) It seems young (as a project, not the folks on it). Things like this post to the homepage worry me: <a class="moz-txt-link-freetext" href="http://www.freeswitch.org/node/103">http://www.freeswitch.org/node/103</a> as it looks a bit cavalier.</div></blockquote><div><br class="webkit-block-placeholder"></div><div>We have been a bit intentionally slow rolling our initial 1.0 release until we feel its ready as we loose a bit of development flexibility as far as insuring backwards compatibility once we do. The project has been in development for about 2 years now, perhaps that is young, but I would hope our efforts show in the result. Your testing and reporting back your experiences are the kinds of things that help show that.</div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000"><br> 3) It seems to have more options and less guidance that I expected. This may be a first-impression thing, but there are many ways to do everything (Dial Plan, Integration languages, etc.). That's sometimes good (Perl took that approach for years) and sometimes awful (the competing opinions get in the way).</div></blockquote><div><br class="webkit-block-placeholder"></div><div>The switch is very intentionally quite modular. This of course does lead to people having lots of options. That being said, as far as dialplan, the xml dialplan is the one that we use the most in our development, and is the generally recommended dialplan unless you have specific needs. The language module we have focused most of our energy on spidermonkey (javascript) for embedded ivr work, as javascript as a language was the one designed from the start to be embedded. The range of options for both internal and external control of calls is wide, but I think that is an advantage.</div><div><br class="webkit-block-placeholder"></div><blockquote type="cite"><div bgcolor="#ffffff" text="#000000"> <br> We can contribute back to this project, both with development/debugging/etc. time and with documentation help, and right now it <b>feels</b> like the right choice. However, I thought I'd ask for some help getting past the concerns above before we jumped in.</div></blockquote><div><br class="webkit-block-placeholder"></div><div>sounds great!</div><br><blockquote type="cite"><div bgcolor="#ffffff" text="#000000"><br> Thanks in advance for your time,<br> <br></div></blockquote><div><br class="webkit-block-placeholder"></div><div>Feel free to meet up with us on irc (irc.freenode.net #freeswitch) if you would like to discuss more real time. We are typically there during the daytime during the weekdays. Would love to discuss more.</div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div>Mike</div></div><br><div><br class="webkit-block-placeholder"></div></body></html>