No subject

e scalability and stability. I don't have the financial and manpower resour=
ces for a large scale implementation so am looking at getting a high end se=
rver and a solution that can scale well until I can through in more resourc=
es. It seems also FS is more stable than * which is a huge plus for a small=
 operation like mine and since I only need few features from the solutions =
available then FS makes more sense

On Wed, Dec 8, 2010 at 8:29 PM, Michael Collins <msc at freeswitch.org> wrote:

> Dave,
>
> Thanks for your two cents. :)
>
> Regarding the PRI stuff, Sangoma is really doing a lot with FreeTDM=20
> (the replacement for OpenZAP) and it will be a full-featured PRI=20
> stack. If you're missing anything in the PRI implementation then=20
> Moises Silva would definitely want to hear about it.
>
> On the voicemail stuff we have heard similar reports. In fact, we have=20
> an intrepid community member who is building "Jester Mail" as a FS=20
> alternative to Asterisk's Comedian mail. The basic idea is that Jester=20
> Mail will be 100% customizable such that you can drop in FS as a=20
> 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=20
> swap out your remaining Asterisk servers.
>
> -MC
>
>
> On Wed, Dec 8, 2010 at 9:53 AM, Dave Singer <dave.singer at wideideas.com>wr=
ote:
>
>> We have both asterisk and Freeswitch in production. The primary place=20
>> where we have * installed is as a pbx for our business customers=20
>> (where we started doing business and didn't know any better). We are=20
>> still using * for them for two reasons: migration time and voicemail=20
>> app I feel is still better in a couple points. They are low volume=20
>> usage so crashes are very rare.
>> We also have some boxes where we connect to telecom PRI circuits=20
>> where the API for FS doesn't support some params we need to set. So=20
>> we are stuck there for now. There systems handle moderate volume, 30 - 9=
0 simultaneous calls.
>> This call volume has proved to be deadly to asterisk and we have to=20
>> restart asterisk daily or suffer a crash in the middle of peek times.
>> We use FreeSwitch as the workhorse with a custom routing module=20
>> combined with Opensips as a class 4 switch (whole sale trunking=20
>> service). With high powered servers (latest dual xeon quad core, 16GB=20
>> ram, and 10Gbit ethernet) it can handle thousands of simultaneous=20
>> calls. They run for months without problem (would be longer but for=20
>> reboots for upgrades, etc., not FS crashes).
>> We also have a class 5 system that handles residential users which=20
>> 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=20
>> we were developing the residential system and converted to using it.
>> Coming from * to FS has some difficulties because of the different=20
>> ways of doing things like the flow of the dialplan where all=20
>> conditions are evaluated at the time of entry to the dialplan, not as=20
>> each line is executed (executing another extension solved this problem f=
or me).
>> I do think FS has a little higher learning curve, I have found it=20
>> 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>wro=
te:
>>
>>> Comments inline. (Full disclosure: I am on the FreeSWITCH team, so=20
>>> 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 <=20
>>> paul.gore.j at gmail.com> wrote:
>>>
>>>> We use freeswitch in prod alone, no opensips yet. I would say fs is=20
>>>> definetly more scalable than *.
>>>> Stability wise seems like fs is on par with *.
>>>>
>>> YMMV, but a large percentage of FreeSWITCH users have abandoned=20
>>> Asterisk specifically because of stability issues, like random and=20
>>> inexplicable crashes.
>>>
>>>
>>>> * has substantially better interface for control over socket=20
>>>> connection
>>>> - it's easier to implement and it's more consistent.
>>>>
>>> This statement is patently false. The FreeSWITCH event socket=20
>>> interface is incredibly powerful and is absolutely more consistent=20
>>> than the AMI. Those wondering about inconsistencies in the AMI=20
>>> 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=20
>>>> is cumbersome and has no real advantage over *.
>>>>
>>> This one really is like Coke vs. Pepsi. Some people hate XML, some=20
>>> people hate INI-style config files. Personally, I've done both and=20
>>> now that I'm accustomed to FreeSWITCH's XML files I find them much=20
>>> easier to read than Asterisk's config files. There is one "real=20
>>> advantage" to using XML for configs and that is that machines and=20
>>> 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=20
>>> configuration - it's very cool and I recommend that you check it=20
>>> out.)
>>>
>>>
>>>> We have endless problems with fs nat handling, lots of no audio=20
>>>> issues with end users behind a nat. That's why we want to try=20
>>>> opensips solution for that.
>>>>
>>> Almost all NAT problems stem from phones which don't handle NAT=20
>>> properly or NAT devices that scramble ports and IP addresses when=20
>>> packets pass through. FreeSWITCH has several NAT-busting tools to=20
>>> assist the system admin. Some tools are for when FS is behind NAT,=20
>>> others are for when the phones are behind NAT. Bottom line is this:=20
>>> if the NAT device and the phones are not horribly broken then FS=20
>>> works great with NAT and in many cases "just works." However, when=20
>>> you start mixing crazy scenarios with broken phones then bad things=20
>>> will happen. Example: Polycom phones are wonderful except that they=20
>>> don't support rport - FS has a mechanism to assist with this but if=20
>>> you turn it on to "fix" the Polycom phones then it will break all=20
>>> other phone types. (There is a limit to the amount of pandering that=20
>>> the FS devs will do in order to interop with broken devices. In many=20
>>> cases they simply say "NO" to doing stupid things in order to work=20
>>> with broken devices. If you must work with such a device then=20
>>> perhaps FreeSWITCH isn't for you.)
>>>
>>> All that being said, the FreeSWITCH developers have a simple mantra=20
>>> that they follow to the letter: Use what works for your situation.=20
>>> If Asterisk works for you then by all means use it! You won't hurt=20
>>> our feelings. (I work daily with the FreeSWITCH dev team.) If you=20
>>> have people knowledgeable in Asterisk or FreeSWITCH then it might be=20
>>> advantageous to go with the project for which you have more=20
>>> resources. In any case, if you are interested in FreeSWITCH we have=20
>>> a great IRC channel (#freeswitch on irc.freenode.net), an actively=20
>>> 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=20
>>>> 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=20
>>>> from people who've integrated it to OpenSIPS how it compares to=20
>>>> Asterisk especially in the case of installation and intergration,=20
>>>> scalability and ease of maintenance.  Any info would be a huge help
>>>>
>>>> regards,
>>>> james
>>>>

_______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users