[OpenSIPS-Users] Freeswitch vs Asterisk
Michael Collins
msc at freeswitch.org
Wed Dec 8 19:29:50 CET 2010
Dave,
Thanks for your two cents. :)
Regarding the PRI stuff, Sangoma is really doing a lot with FreeTDM (the
replacement for OpenZAP) and it will be a full-featured PRI stack. If you're
missing anything in the PRI implementation then Moises Silva would
definitely want to hear about it.
On the voicemail stuff we have heard similar reports. In fact, we have an
intrepid community member who is building "Jester Mail" as a FS alternative
to Asterisk's Comedian mail. The basic idea is that Jester Mail will be 100%
customizable such that you can drop in FS as a replacement for Asterisk and
your voicemail users would be none the wiser.
By early next year you will probably have more options if you wish to swap
out your remaining Asterisk servers.
-MC
On Wed, Dec 8, 2010 at 9:53 AM, Dave Singer <dave.singer at wideideas.com>wrote:
> We have both asterisk and Freeswitch in production. The primary place where
> we have * installed is as a pbx for our business customers (where we started
> doing business and didn't know any better). We are still using * for them
> for two reasons: migration time and voicemail app I feel is still better in
> a couple points. They are low volume usage so crashes are very rare.
> We also have some boxes where we connect to telecom PRI circuits where the
> API for FS doesn't support some params we need to set. So we are stuck there
> for now. There systems handle moderate volume, 30 - 90 simultaneous calls.
> This call volume has proved to be deadly to asterisk and we have to restart
> asterisk daily or suffer a crash in the middle of peek times.
> We use FreeSwitch as the workhorse with a custom routing module combined
> with Opensips as a class 4 switch (whole sale trunking service). With high
> powered servers (latest dual xeon quad core, 16GB ram, and 10Gbit ethernet)
> it can handle thousands of simultaneous calls. They run for months without
> problem (would be longer but for reboots for upgrades, etc., not FS
> crashes).
> We also have a class 5 system that handles residential users which uses FS
> and opensips for failover. Again no FS crashes.
> FS is also our conference server for all our services.
>
> We started out using * building the business PBXs. Later found FS as we
> were developing the residential system and converted to using it.
> Coming from * to FS has some difficulties because of the different ways of
> doing things like the flow of the dialplan where all conditions are
> evaluated at the time of entry to the dialplan, not as each line is executed
> (executing another extension solved this problem for me).
> I do think FS has a little higher learning curve, I have found it better in
> almost every area, especially stability and flexibility.
>
> Well, those are my 2 cents. :-D
> Dave
>
> On Tue, Dec 7, 2010 at 11:27 AM, Michael Collins <msc at freeswitch.org>wrote:
>
>> Comments inline. (Full disclosure: I am on the FreeSWITCH team, so if I
>> come off as biased then you know why. ;)
>>
>> On Tue, Dec 7, 2010 at 8:29 AM, paul.gore.j at gmail.com <
>> paul.gore.j at gmail.com> wrote:
>>
>>> We use freeswitch in prod alone, no opensips yet. I would say fs is
>>> definetly more scalable than *.
>>> Stability wise seems like fs is on par with *.
>>>
>> YMMV, but a large percentage of FreeSWITCH users have abandoned Asterisk
>> specifically because of stability issues, like random and inexplicable
>> crashes.
>>
>>
>>> * has substantially better interface for control over socket connection -
>>> it's easier to implement and it's more consistent.
>>>
>> This statement is patently false. The FreeSWITCH event socket interface is
>> incredibly powerful and is absolutely more consistent than the AMI. Those
>> wondering about inconsistencies in the AMI should listen to a seasoned AMI
>> developer talk about the challenges:
>> http://www.viddler.com/explore/cluecon/videos/29/
>>
>>
>>> Configuration wise, I think * is easier, xml- based approach in fs is
>>> cumbersome and has no real advantage over *.
>>>
>> This one really is like Coke vs. Pepsi. Some people hate XML, some people
>> hate INI-style config files. Personally, I've done both and now that I'm
>> accustomed to FreeSWITCH's XML files I find them much easier to read than
>> Asterisk's config files. There is one "real advantage" to using XML for
>> configs and that is that machines and humans can both produce XML, so it's
>> relatively simple to let a machine generate XML-based configs on the fly.
>> (FreeSWITCH uses "mod_xml_curl" as the basis for dynamic configuration -
>> it's very cool and I recommend that you check it out.)
>>
>>
>>> We have endless problems with fs nat handling, lots of no audio issues
>>> with end users behind a nat. That's why we want to try opensips solution for
>>> that.
>>>
>> Almost all NAT problems stem from phones which don't handle NAT properly
>> or NAT devices that scramble ports and IP addresses when packets pass
>> through. FreeSWITCH has several NAT-busting tools to assist the system
>> admin. Some tools are for when FS is behind NAT, others are for when the
>> phones are behind NAT. Bottom line is this: if the NAT device and the phones
>> are not horribly broken then FS works great with NAT and in many cases "just
>> works." However, when you start mixing crazy scenarios with broken phones
>> then bad things will happen. Example: Polycom phones are wonderful except
>> that they don't support rport - FS has a mechanism to assist with this but
>> if you turn it on to "fix" the Polycom phones then it will break all other
>> phone types. (There is a limit to the amount of pandering that the FS devs
>> will do in order to interop with broken devices. In many cases they simply
>> say "NO" to doing stupid things in order to work with broken devices. If you
>> must work with such a device then perhaps FreeSWITCH isn't for you.)
>>
>> All that being said, the FreeSWITCH developers have a simple mantra that
>> they follow to the letter: Use what works for your situation. If Asterisk
>> works for you then by all means use it! You won't hurt our feelings. (I work
>> daily with the FreeSWITCH dev team.) If you have people knowledgeable in
>> Asterisk or FreeSWITCH then it might be advantageous to go with the project
>> for which you have more resources. In any case, if you are interested in
>> FreeSWITCH we have a great IRC channel (#freeswitch on irc.freenode.net),
>> an actively mailing list, and a small but growing international community of
>> users. You are most welcome to join us to see what we're about.
>>
>> Happy VoIPing!
>> -Michael S Collins
>> IRC:mercutioviz
>>
>>
>>
>>>
>>>
>>> -----Original Message-----
>>> From: James Mbuthia
>>> Sent: 12/07/2010 8:54:51 AM
>>> Subject: [OpenSIPS-Users] Freeswitch vs Asterisk
>>>
>>> Hi guys,
>>>
>>> I want to integrate my Opensips implementation with either Asterisk or
>>> Freeswitch to do the following functions
>>>
>>> - Act as a Media server
>>> - Connect to the PSTN
>>> - Act as a B2BUA
>>>
>>>
>>> There's been alot of hype about Freeswitch and I wanted to know from
>>> people
>>> who've integrated it to OpenSIPS how it compares to Asterisk especially
>>> in
>>> the case of installation and intergration, scalability and ease of
>>> maintenance. Any info would be a huge help
>>>
>>> regards,
>>> james
>>>
>>> :::0:a0e8dc7ff9acb0ae85abefba43f14c73:-1:x:::
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20101208/95bc3dfb/attachment.htm>
More information about the Users
mailing list