No subject

h are
scalability and stability. I don't have the financial and manpower reso=
urces
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 resource=
s. 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 solutio=
ns
available then FS makes more sense

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

> 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 hav=
e an
> intrepid community member who is building "Jester Mail" as a FS alter=
native
> 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 Asteri=
sk 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.co=
m>wrote:
>
>> We have both asterisk and Freeswitch in production. The primary plac=
e
>> where we have * installed is as a pbx for our business customers (wh=
ere we
>> started doing business and didn't know any better). We are still usi=
ng * for
>> them for two reasons: migration time and voicemail app I feel is sti=
ll
>> 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 whe=
re the
>> API for FS doesn't support some params we need to set. So we are stu=
ck 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 comb=
ined
>> with Opensips as a class 4 switch (whole sale trunking service). Wit=
h high
>> powered servers (latest dual xeon quad core, 16GB ram, and 10Gbit et=
hernet)
>> it can handle thousands of simultaneous calls. They run for months w=
ithout
>> 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 u=
ses 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 w=
ays 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 be=
tter
>> 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 i=
s
>>>> definetly more scalable than *.
>>>> Stability wise seems like fs is on par with *.
>>>>
>>> YMMV, but a large percentage of FreeSWITCH users have abandoned Ast=
erisk
>>> specifically because of stability issues, like random and inexplica=
ble
>>> crashes.
>>>
>>>
>>>> * has substantially better interface for control over socket conne=
ction
>>>> - it's easier to implement and it's more consistent.
>>>>
>>> This statement is patently false. The FreeSWITCH event socket inter=
face
>>> is incredibly powerful and is absolutely more consistent than the A=
MI. Those
>>> wondering about inconsistencies in the AMI should listen to a seaso=
ned 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 tha=
t I'm
>>> accustomed to FreeSWITCH's XML files I find them much easier to rea=
d 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 th=
e fly.
>>> (FreeSWITCH uses "mod_xml_curl" as the basis for dynamic configurat=
ion -
>>> it's very cool and I recommend that you check it out.)
>>>
>>>
>>>> We have endless problems with fs nat handling, lots of no audio is=
sues
>>>> with end users behind a nat. That's why we want to try opensips so=
lution for
>>>> that.
>>>>
>>> Almost all NAT problems stem from phones which don't handle NAT pro=
perly
>>> or NAT devices that scramble ports and IP addresses when packets pa=
ss
>>> through. FreeSWITCH has several NAT-busting tools to assist the sys=
tem
>>> admin. Some tools are for when FS is behind NAT, others are for whe=
n the
>>> phones are behind NAT. Bottom line is this: if the NAT device and t=
he phones
>>> are not horribly broken then FS works great with NAT and in many ca=
ses "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 t=
his but
>>> if you turn it on to "fix" the Polycom phones then it will break al=
l 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 device=
s. 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 As=
terisk
>>> 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 knowledgeab=
le 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 interest=
ed in
>>> FreeSWITCH we have a great IRC channel (#freeswitch on irc.freenode=
.net),
>>> an actively mailing list, and a small but growing international com=
munity 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 Asteris=
k 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 fr=
om
>>>> people
>>>> who've integrated it to OpenSIPS how it compares to Asterisk espec=
ially
>>>> in
>>>> the case of installation and intergration, scalability and ease of
>>>> maintenance.  Any info would be a huge help
>>>>
>>>> regards,
>>>> james
>>>>