Ben, thank you for your story. I would very much like to add this to
the wiki if you don't mind and everyone else agrees. What do you think
guys? Use cases are _ALWAYS_ a good thing for new users.
Mesquita
On Feb 19, 2009, at 6:23 PM, Ben Holtsclaw wrote:
Raul,
I am in the process of rolling out a FreeSWITCH IP PBX solution
similar to what you describe. When I was trying to procure funds for
a FreeSWITCH solution, I looked for the same information you're
after, but came up with little. I'll briefly describe what we're
trying to accomplish, and the tools I'm using to do it. This is
probably more information than what you are looking for, but maybe
it will also benefit someone else.
We had several schools with aging or dying PBX's or KSU's. Each site
had something different system, and was supported by a different
VAR. Of course, the VAR's charged some outlandish fee to make onsite
repair visits. Some number of Centrex lines supplied each school's
dial tone. All in all, we had a very outdated and financially
draining mess. Our district's long term goal had been to move to a
more unified phone system. That made sense for many reasons, the
chief of which was cost. We already had a strong fiber WAN in place.
Why not use that for trunking and eliminate the monthly cost of the
Centrex lines? That's the path we started down.
Being a public entity, we had to be sure to explore all possible
avenues. We looked at everything from traditional PBX's with IP add-
on modules for trunking to a full blown Cisco CallManager solution.
With third party proprietary systems, we were just never able to
find the sweet spot between required feature set and cost. Would
Cisco have been a workable solution? Absolutely. Could our small,
rural, K12 public school district afford that? Not in a million
years. I looked at several software packages -- some open source,
some not -- but always came back to FreeSWITCH. The scalability and
active development community were major factors for us.
Server Hardware. Each of our five sites has a dedicated FreeSWITCH
server. For hardware, we went with Dell PowerEdge 1950's with dual
quad core Xeon 2.33 GHz processors, and 4GB of RAM. I have mirrored
disks set up with enough space to accommodate users' voicemail. Each
server will average only about 60 voicemail boxes, and we're storing
sound as MP3. Disk space shouldn't be an issue. We have always been
a Novell shop, so SLES is naturally our Linux distribution of
choice. We chose to go with server hardware at each site so that in
the event of a WAN outage, we would still at least have intra-
building and emergency communication (see below).
Telephony Hardware. Each of our servers includes Sangoma hardware.
We actually looked at doing IP trunking to a carrier from our
network core, but decided to use telco provided PRI's instead.
Presently, we have two PRI's that connect to a FreeSWITCH server at
the center of our network via a Sangoma A102 dual port telephony
card. All calls to and from the PSTN traverse this primary server.
Servers at each remote site include one of Sangoma's A200 analog
cards. Emergency calls to 911 route out over this analog card
through one of at least two POTS lines that remain connected at each
site. Not only does this provide some redundancy in the event of a
WAN outage, but it ensures proper caller location is delivered to
the 911 dispatcher. Granted, there are some other solutions for the
latter, but this seemed to be the most cost effective solution for us.
Telephone Desksets. We chose to go with Aastra for the telephones.
The standard phone that we will place in each classroom and office
is the 9143i. This is an attractive phone with an adequate feature
set at a price we can afford. The person that is primarily
responsible for answering the phone at each site will have an Aastra
57i and some number of 560M expansion modules. We have purchased
roughly 300 Aastra desksets.
Logical Layout. As new sites come online, their primary phone number
is being moved from the Centrex to our PRI group. All inbound calls
hit our primary server, and then FreeSWITCH bridges to the
appropriate secondary server based on the DID it received. On the
reverse, each servers dial plan is set up to route outbound calls
(save 911) to the primary server where FreeSWITCH bridges with
Openzap. Site to site calls, accomplished via four digit dialing, do
not hit the primary server. Outbound calls to the PSTN deliver the
site's DID as the calling number. In other words, if a user from
site two calls my cell phone, I see site two's published telephone
number on my caller ID. Our dial plans are set up so that
receptionists at each site still answer all outside calls. If not
answered, the call fails over to an IVR. Should we ever decide to do
so, we are now perfectly positioned to have all inbound calls to the
district answered by one operator or IVR. "Welcome, and thank you
for calling Avery County Schools."
Stumbling Blocks. Problems we've faced so far have primarily
surrounded Openzap and the Sangoma Wanpipe driver. FreeSWITCH
developers won't mind telling you that this is an area that is
currently not well "funded" and not 100% complete. There is some
known issue where voice channels on the PRI get stuck in the wrong
state and become unusable. We have experienced this a couple of
times and have not been able to make or receive calls. Bouncing the
Wanpipe driver has fixed this each time. We have also had trouble
with DTMF detection across the PRI. If a user hits the IVR, it is
oftentimes difficult to get it to properly recognize the digits that
are being keyed in by the caller. This can be very, very frustrating
to a caller that doesn't want to deal with an IVR anyway. The
developers have suggested to me that this is a problem with the
Sangoma's echo cancellation goofing up Openzap's ability to
interpret the DTMF. The Sangoma hardware does have its own DTMF
decoder and API, but the Openzap code currently does not make use of
it. I have created a patch that makes use of the hardware decoder.
We have been running it in production for a couple of weeks, and
that does seem to have helped the problem. The problem hasn't gone
away altogether. Those have been our two biggest issues, but we
haven't let them hold us up.
Conclusion. Of the five sites that will be on this system, one is
fully functional with calls inbound and outbound from the PSTN. A
second site is up and running with full outbound PSTN access. Their
inbound DID is scheduled to move over to the PRI in one week. The
server has been worked up for a third site, and the phones are
starting to roll out. Sites four and five should come online by the
end of April. Currently, I don't have numbers compiled for things
like concurrent calls. At this point in my project, it is just not
important. I really don't think our implementation will ever push
FreeSWITCH's abilities in that regard. I base that statement
primarily on other users' benchmarks, and what I've heard some are
doing in carrier class environments.
FreeSWITCH has made our project viable. An open source solution was
the only way we could meet all of the project goals and stay within
our budget. FreeSWITCH has proven to have all the features we
require in a district wide phone system. It has not locked us into
annual support contracts with third party vendors. I could go on
with the accolades. However, I'll end this terribly lengthy post by
saying that, overall, we have been very pleased with our choice to
go with FreeSWITCH.
The information in this email will seem very elementary to most
people on this list, but having a message of this nature in hand
would have made me feel much more confident the first time I ever
went to my supervisor to mention something called FreeSWITCH. :-)
Thanks Tony, Brian, and Mike for a great product!
Ben Holtsclaw
Network Engineer
Avery County Schools
Ph: 828.733.3567 x2301
>>> On 2/18/2009 at 11:13 PM, Raul Fragoso <[email protected]> wrote:
Thanks guys, this is very useful information.
Anyone else willing to share your experience ?
Regards,
Raul
On Wed, 2009-02-18 at 16:19 -0200, Pablo Hernan Saro wrote:
> Hi Raul,
>
> In my company (http://www.globant.com) we're using FreeSWITCH for
high
> quality conference services, integrated with OpenSIPS
> (http://www.opensips.org) and Asterisk. Its performance is pretty
> good.
>
> Pablo
>
> On Wed, Feb 18, 2009 at 4:09 PM, Henry Huang <[email protected]
> wrote:
> > bandwidth.com has a service called phonebooth which is developed
upon
> > freeswitch.
> >
> >
> > On Tue, Feb 17, 2009 at 4:20 PM, Raul Fragoso
<[email protected]> wrote:
> >>
> >> Hello FreeSWITCHERS,
> >>
> >> My company is currently creating a suite of applications which
uses
> >> FreeSWITCH as the back-end for an IP-PBX solution. We currently
have a
> >> prospect to have our first customer installation - a governmental
> >> department. That is a tender to have an IP-PBX installation to
connect
> >> their four office branches, each one with about 300 users -
which I am
> >> sure FreeSWITCH is able to handle. Since this is an official
tender,
> >> it's part of their protocol to ask about real sites using the
product.
> >>
> >> Having said that, would you mind sharing some information about
your
> >> experience with FreeSWITCH deployments ?
> >>
> >> No need to give many details, but a short summary with company
name (if
> >> possible), when it was deployed, server equipment, number of
users,
> >> number of concurrent calls, what kind of functions and services
are used
> >> and overall capacity of the system.
> >>
> >> I would really appreciate if you can share that information.
And if you
> >> guys agree (and explicitly manifest your agreement), I can
compile the
> >> information in the FreeSWITCH wiki under a "Use Cases" page so
it can
> >> serve as a common reference as well.
> >>
> >> Kind regards,
> >>
> >> Raul Fragoso
> >>
> >>
> >> _______________________________________________
> >> Freeswitch-users mailing list
> >> [email protected]
> >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> >> http://www.freeswitch.org
> >
> >
> >
> > --
> > Henry Huang
> > UniC Solution - Communication Unified
> > VoIP & Open Source software Consultant
> >
_______________________________________________
Freeswitch-users mailing list
[email protected]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
_______________________________________________
Freeswitch-users mailing list
[email protected]
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
