[Freeswitch-users] Deployment information and use cases

Thu Feb 19 20:18:00 PST 2009

Ben,

Wow !!! Thank you very much for such descriptive and detailed
information !
Indeed, this is really more than I expected, and once again I thank you
for your collaboration. It's very cheering and inspiring to hear such
successful story regarding FreeSWITCH.

Kind regards,

Raul 

On Thu, 2009-02-19 at 15:23 -0500, 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 <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