[Freeswitch-users] FreeSwitch the Right Tool?

Jason Garland jgarland at gmail.com
Sun Dec 2 17:30:23 PST 2007


I'm happily running freeswitch in Xen. Try that with Asterisk!

Sent from my iPhone

On Dec 2, 2007, at 8:08 PM, Michael Jerris <mike at jerris.com> wrote:

>
> 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
>
>
> _______________________________________________
> Freeswitch-users mailing list
> Freeswitch-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20071202/e2cd57ba/attachment-0002.html 


More information about the FreeSWITCH-users mailing list