Slashdot Mirror
Is Linux Used in Production Telephony?
jamesva asks: "The telecommunications industry is rapidly converging on Windows NT/2000 for all telephony and voice-related needs. Most ACD systems, virtual operators, and voicemail are being ported to Windows if they're not already running on it.
In the past, telephony apps have existed most
notably on OS/2, SCO, and even DOS. However,
free Unix (or unix-like) platforms have absolutely no penetration in this area, with seemingly no chance on the horizon.
The Bayonne app server from the GNU folks seems to be the one exception, but even then there doesn't
seem to much built around it or anyone using it. It reached a 1.0 release in September and was met with no fanfare. Even the
LinuxTelephony doesn't seem to have much news. Can someone prove me wrong? Why is this the case? I'm interested in finding out if anyone is using Linux (or any free OS) in a production environment for something like voicemail or ACD. These types of systems require high availability and reliability and Linux just seems like a natural fit."
Either this is complete & total ignorance on my part, or, well, it's just complete & total ignorance. I thought that Large scale Unix based systems basically ran the switches, backbones/large servers behind Telephone/Telecommunication Networks. That's how the uber geeks found out about it, trashing for manuals to all of these VAX/VMS/UNIX systems, dialing in to them, and hax0ring their way in to screwing with their friends/enemies who may have flamed them on a local BBS. Am I wrong?
Here at work we use a 3Com NBX 100 system .
I've FTP'd into it and it seems to be running some sort of a BSD variant.
I guess it could also run linux.. but I don't quite feel like pokeing around in our production telephone system.
They probably *could* do the same thing under Linux, but I'd rather that they not do it. (The situation with Oracle on Linux is already too close IMHO).
I consult at a large telco.
There is tremendous fear from the legal part of the house that using Linux _could_ open us up for lawsuits, primarily in the area of intellectual property, but stability and support is also a concern. What would happen if a 911 call didn't get through and somehow linux was to blame? Lawsuit?
In fact, use of any GNU or other free/shareware licensed SW is completely forbidden throughout the enterprise. There are exceptions, but those are difficult to get signed.
Uptime, huge amounts of support (SUN, EMC, HP, STK, Nortel, Cisco) are required. For Linux, I don't believe the support companies could keep up with our support needs for even a small subset of the applications (we have 1,000s). We won't get into scalability, but it is routine to have 8 64-way servers performing a task and to be considering adding a few more for additional processing and failover. Sometimes I wonder why we're leaving mainframes, then I remember the costs.
...even then there doesn't seem to much built around it or anyone using it. It reached a 1.0 release in September and was met with no fanfare.
So I'm supposed to bet the farm, our company, and MY job on recommending a 1.0 release of a pivotal tool that:
a) no one else uses
b) requires a massive $ investment to get off the ground
c) has only been out for 30 days.
d) has no support from the company that builds the call center respondent database.
Not likely.
If for whatever reason it craps out, we are out of business. I don't care so much about the operating system as I do the combination of operating system AND application. A crappy tool that runs under Linux is far, far worse than a good tool that runs under a properly administered Win2k OS.
Recommending Linux merely because it is Linux is a fast way to the unemployment line.
In addition to our WAN/LAN I also run a medium size phone switch (195 nodes / 16 IP Phones / 2 PRIs for switched access / 1 dedicated Long Distance T1). When you get to the corporate level you're buying a solution; not building one in house, because phones are essential to the day to day operation of the company. Period. I think generically when you say phone switch you're referring to everything telco past the demarc; switch T1s/PRIs, operate internal digital stations, provide analog lines, route calls, manage security, reporting/tracking/billing, Voicemail, Auto Attendants, Hunt Groups, Digital Faxing- the whole 7 layer enchilada. Few corporations are going to allow their IT departments to go the Slashdot way w/ so much on the line. A modern phone switch must reliably scale to thousands of nodes including IP devices, support Unified Messaging (receiving faxes & voice mails through PC), have reporting right out of the box, must be easy to use, and work on the first cut over. While the word 'easy' is certainly a very relative word- in my experience most geeks (a word of complimentary endearment in my vocabulary) can easily master telco while the reverse is not often true. Believe it or not, in the old days these were sometimes the roles of separate administrators / departments.
You're right that *nix is a perfect fit for all of this; remember Unix was invented at Bell Labs. The auxiliary applications are there; to support your phone switch you need to reliably record and report all activity across your switch for billing, acct. tracking, etc. I would guess that *nix runs the backbone.
If you'd like you can become a dealer for the company that claims to have 'the world's first Linux technology based voice processing' including Unified Messaging.
By the way I think that Bayonne is encompassed in the umbrella project of GNUComm; hopefully it's just a matter of time before someone finishes the Embedded Linux Phone Switch. As an incentive to anyone who develops and releases a free system: even used handsets cost big money for a particular phone switch; pick wisely 'cause you're most likely stuck with it for a little while. Caveat: you will most likely be pushed out of the market by softphones.
Since you're in the market and I just went through this myself contact me off list and I'll share my experience with Inter-Tel Technologies which is one of the fastest growing companies in the US (short version: no I don't work there and overall positive).
Great occasions do not make heroes or cowards; they simply unveil them to the eyes. -Bishop Westcott
I've been involved in many Large carrier switch control application platforms being delivered using Linux since 1994. Sprint was an early adopter in Asia. Hutchison Telecom also used Linux in their cellular network application switching platform. British Telecom deployed a worldwide unified messaging platform in 2000 that was controlled by Linux in the U.S.,U.K.,Japan, Australia, Norway, Spain, Italy and Germany. NTT used a Linux controlled calling card platform in Japan that ran well over 20,000,000 minutes per month. Embratel and Worldcom deployed the first carrier installed calling card platform in Brazil in 1999/2000 that was running a Linux based switch control platform. If I remember correctly the platform at Hutchison made it over 400 days without a reboot.
Hmmm... A year ago I got a phone call from my US counterpart about a "PC" that was spreading Nimda.
Turned out that it was the PABX control system. It didn't run any virus protection software, because all antivirus software tested brought down the software.
Now, here's the horrible bit. The PABX itself is a solid bit of engineering, with an ASCII only bit of RS232 based interface controlling it. If those bits had even remotely been documented, anyone with experience with something as simple as expect could have coded up an interface to it in a day at most -- much less time than what was invested in bringing the Windows interface to it on line.
To this date, we're not using the advanced features of the system because just getting it to work right on the supported platform turned out to be too great a nightmare to offset the possible gains from it.
PABX interfaces are the prototypical illustration of why documenting the low level interface can benefit the advanced user without impeding sales of the "integrated" windows "solution" to customers who can deal with interfacing Windows stuff. We're as shortstaffed in Windows DDE skills as we are in low level Unix stuff, but if the RS232 interface had been documented, we could've assessed the risks and benefits of talking directly to the hardware and make an informed decision on which group should handle the PABX interface and which tools to use.
The PABX is basically on life support, because the bundled apps suck and implementing a simple toolkit that covers our basic needs is impossible for lack of docs. That, in management terms, is a "lose-lose" proposition.
Bert Driehuis -- All I asked was a friggin' rotatin' chair. Throw me a bone here, people.