[Freeswitch-users] Deployment information and use cases

João Mesquita jmesquita at gmail.com
Sat Feb 21 05:56:41 PST 2009


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 <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/20090221/3cdd410f/attachment-0002.html 


More information about the FreeSWITCH-users mailing list