[Freeswitch-users] FreeSwitch the Right Tool?

[Michael Jerris]

On Dec 2, 2007, at 5:59 PM, Bill Binko wrote:

> Hi everyone,
>
> 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.

Definitely not the right tool :D

>
> 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.
>
> 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.).
>
> 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.

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.

>
>
> 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.
>
> 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.
>
> Here's my concerns about it so far - let me know if they're unfounded.
>
> 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?

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.

>
> 2) It seems young (as a project, not the folks on it).  Things like  
> this post to the homepage worry me: http://www.freeswitch.org/node/ 
> 103 as it looks a bit cavalier.

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.

>
> 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).

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.

>
> We can contribute back to this project, both with development/ 
> debugging/etc. time and with documentation help, and right now it  
> feels like the right choice.  However, I thought I'd ask for some  
> help getting past the concerns above before we jumped in.

sounds great!

>
> Thanks in advance for your time,
>

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.


Mike


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20071202/18f295b2/attachment-0002.html