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 <r...@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.se...@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 <r...@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@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@lists.freeswitch.org > 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 Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org