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@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@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@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