[Freeswitch-users] Deployment information and use cases

Mon Feb 23 09:52:11 PST 2009

Mesquita,

Relatively speaking, I feel like we are near the end of our project
roll out. Perhaps the case would be stronger once everything is
completed. At that time, I will be very glad to share the story on the
wiki -- and hopefully elsewhere!

Ben

>>> On 2/21/2009 at 8:56 AM, João Mesquita <jmesquita at gmail.com>
wrote:
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 ha
ve
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 <raul at etellicom.com> 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
<red.rain.seven at gmail.com> wrote:
> > bandwidth.com has a service called phonebooth which is developed
upon
> > freeswitch.
> >
> >
> > On Tue, Feb 17, 2009 at 4:20 PM, Raul Fragoso <raul at etellicom.com>
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
> >> 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 
> >
> >
> >
> > --
> > Henry Huang
> > UniC Solution - Communication Unified
> > VoIP & Open Source software Consultant
> >

_______________________________________________
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/20090223/232e3701/attachment-0002.html 