bkml wrote: > The number one requirement of all of my customers has been > connectivity to the PSTN. VoIP is no more than icing on the cake, at > least as far as PBXes go. Consequently, for me, VoIP has to fit into > what's there today. I cannot make a living on selling future dreams > of a world in which there is nothing but a single VoIP model, which > is very unlikely to happen anyway.
I agree that a VoIP PBX without PSTN connectivity is pretty useless. Where I live, the major telco (Telecom NZ) are running out of BRI and PRI linecards in many busy exchanges (and the not-so-busy exchanges just don't have many ISDN linecards to begin with), so SIP trunks to a VoIP provider, who then does the PSTN breakout, are starting to become an attractive option. In the meantime, I've been deploying solutions using Eicon Divas BRI cards, Cisco 1760 and 2800 series routers with ISDN VIC/VWIC's, and we are interested in trialling Patton SmartNode 4630 series SIP to BRI gateways. At the moment, using the Eicon cards amounts to vendor lock-in, since they're really only supported by Asterisk and OpenPBX (or some other PBX that supports CAPI). With an external SIP to PSTN gateway such as a Cisco or Patton SmartNode, we then can use a much wider range of software, including FreeSWITCH. With the Cisco option at least, they are bundling more functionality than ever before on the router itself, such as CCME and SRST, which, in a small/remote office, essentially makes an Asterisk box redundant. It may still be useful to run a SIP trunk back to the head office for voicemail etc, or even use that SIP trunk for PSTN breakout at the head office (and do away with PSTN lines at the SOHO/ROBO). > I don't want to deal with the all too common ISDN is different from > POTS is different from Foo is different from Bar is different from > Baz. Precisely why we are favouring an external SIP to PSTN gateway these days, or centralised PSTN breakout with SIP trunks. > There is a clear need for a project that is neither encumbered by > Digium's nor by Tony's licensing policy. The inability to use > libraries that are GPL only, such as Unicall, is a serious > disadvantage and OpenPBX should stay away from incorporating > Freeswitch on these grounds alone. The nice thing about FreeSWITCH is that their development model can actually encourage closed source modules that have radically different licence terms to FreeSWITCH itself, and which companies can charge money for. It is not necessary for a project to "incorporate" FreeSWITCH - a company could simply release "Foobar Call Centre Module" that runs with FreeSWITCH. It's up to the end user to provide a functioning FreeSWITCH install, then purchase and install the "Foobar Call Centre Module". > As for a possible future direction of OpenPBX, I had a brief > discussion with Nathan a while ago in which we both concluded that > embedded devices are more future proof than running PBX software on a > PC and that there probably should be some work towards an embedded > OpenPBX, along the lines of AstLinux. I think that's a great idea, and I've been hoping somebody would start such a project. I suspect embedded devices probably have higher long term reliability than PCs, and are usually cheaper. Call volume becomes a concern though, especially with CPU-hungry codecs such as G.729a. Also, it would face competition from the likes of the Linksys SPA9000, which you can pick up for a few hundred dollars. If you can find a supply of embedded devices cheaper than that, and think the development/packaging of the software to run on it will only cost a couple hundred dollars worth of time, let us know :) From the recent deployments I've been doing, it's becoming apparent that our solution based on the Eicon cards, a PC (with RAID-1), and the man-hours spent on developing/configuring OpenPBX, is no longer so economical. Hence we are looking more to utilise cheap, off-the-shelf solutions in the SOHO/ROBO, and central, high volume call switching back end. It just makes better business sense. _______________________________________________ Openpbx-dev mailing list [email protected] http://lists.openpbx.org/mailman/listinfo/openpbx-dev
