So here comes the second Telirati newsletter, and it is further evidence that skepticism seldom goes far enough. In this case, I predicted the decline of conventional telephony CPE, and its replacement with telephony servers. However deep that pessimism was, and the decline of that industry is as deep as I could have imagined, the full measure of pessimism would have also encompassed the possibility that no replacement would emerge.
What do we have today? Lucent and Ericsson shed their dowdy CPE businesses on the way to bubble-economy doom. Nortel's CPE hobbles along, and none of the big iron CPE-makers have made a dent with VoIP systems that don't change end-user costs significantly. The answer to "Who will replace legacy PBX-makers?" appears to be "Nobody."
I don't even know what I would buy if I were shopping for a PBX today. Cisco's VoIP CPE? It's mature enough, but no bargain. If cost matters, I suppose a quality used system would be the first thing that comes to mind. All the horrors of CPE costs - voice mail storage rip-offs, add/move/change fees to retailers, etc. are still there. The replacement of business CPE with mobile wireless service is only in its infancy in Europe, and the sight of an Ericsson receptionist using her mobile handset to handle calls to an attendant station confirmed my suspicions that more work is needed.
So here it is, the second Telirati newsletter, and another lesson that pessimism and skepticism can hardly ever be too deep:
Newsletter #2: Telephony Servers
Two words: segments and alliances. Without thinking about the telephony server business in terms of segments and alliances, it is overwhelming. With this approach, the problem of creating a viable business in telephony servers becomes manageable.
First, let's think about it the wrong way: I'm going to build a telephony server. S.100 seems like a good place to start. I'll just hire a bunch of engineers to fill in all the blank spaces in S.100 hardware and software implementations. OK, but my telephony server will probably run on a Windows NT machine, which doesn't use S.100 for installing, identifying, controlling, and interfacing software to telephony systems - it uses TAPI. More engineers and I'll have a TAPI-to-S.100 layer. Now for the applications. I'll need unified messaging, an attendant position, call queuing, ACD, IVR, fax, pager notification, call accounting and nice Internet telephony gateway to top it all off. That'll be 200 man-years altogether, give or take. Heck that's way smaller than a good-sized switch project used to be - why are you all looking at me like I'm crazy? I'll see you in three to five calendar years with a fully formed product. Good day.
Some people think that way. Some other people want to make money this year. "Internet time" has replaced the glacial product time-scale in the telephony industry. Segments and alliances help get things moving. By identifying segments, you can identify the best approach to creating the product, to selling it, and to finding the right partners.
Let's start at the low end:
Hardware: It'll be new, high volume, and cheap. Don't worry about the installed-base. Don't worry about standards other than TAPI. To be cheap, the hardware is probably a single board, probably made by the company integrating the product. But single boards inside PCs are not the be-all and end-all. Every variant from radical new interpretations of KSU-less key-systems to mutations of key systems that enable easy connection to PCs will flower in the low-end. There are lots of ways to cost-optimize.
Software: TAPI is the standard to obey. Here's why: the hardware at the low end is going to be a single-board, no separate voice processing resource or network interface - all in one. Software makers can't count on the Dialogic or Rhetorex proprietary APIs to be there, and unless they want to go nuts interfacing their products to a bunch of different hardware from a bunch of companies attacking the low end, most of which will be out of business in a year, the software and hardware people will have to agree on TAPI. Unified messaging is the most important software to bundle, with Internet telephony gateways close behind.
Channel: VARs and OEMs. OEMs are finicky - use them to figure out if your product is good enough. Does it install and uninstall cleanly. Does it look right next to Microsoft Office, or is it a specimen from the User Interface Museum of Horrors?
Partnering: Nobody can do this alone, but it's a balancing act. At the low end, the product must be inexpensive. Altigen , for example, focused on creating a software bundle encompassing the basic requirements of unified messaging so they would not have a royalty burden there. Altigen probably shouldn't roll their own Internet telephony gateway. Partnering with VocalTec might make sense there. Low-end fax sharing from Microsoft is good enough, and the price is right. Would an OEM take this product? Picture this: major clone maker ships telephony servers that include everything a small business needs for Internet connectivity, e-mail, voice mail, fax, and you hook your phones up to it. Easy enough to sell mail order. Not quite there yet, but tantalizingly close.
That's the low end. Low cost, high volumes characterize the low end. A lot of the customers are new or growing businesses, and their capital investment in a small business phone system is small enough to be replaced. Their installed base of computers is also small enough to be easily upgraded. Sounds like nirvana except that these are picky customers, too. They have no time to mess around with these systems, and nobody on the premises dedicated to taking care of them. These customers will measure products against off the shelf, mass market software and peripherals. Does the telephony server install as easily as a Zip drive? Does the user interface look as good as Outlook? Now the mid-range segment: The key differences here are that the customer won't throw away what he has, but he'll pay enough for the system to allow for more partnering, a more component-oriented design, and more support.
Another characteristic of the mid-range is diversity. Flexibility in product formulation in the mid-range breeds diversity. S.100-based servers, and servers that ignore S.100. Servers based on NT, servers based on Unix. Servers that use Exchange Server for unified messaging, servers that use Internet mail standards. Servers that put switching inside the PC, and servers that put the PC inside the switch. ISA bus, PCI bus, Compact PCI, and none-of-the-above, in combination with SCSA or MVIP.
Here are the hardware, software, channel and partnering possibilities in the mid-range:
Hardware: Modular. At the low end of the mid range, you will find multiple ISA-card products, consisting typically of a network interface, a switching fabric and station interface card, and a voice processing resource, or, more generally, a DSP resource that does voice processing, fax, and data modem. SCSA or MVIP bus connects the cards. All this running under Windows NT. Moving up, you'll find Compact PCI for the modular systems, and for the PBX-centric telephony servers you'll see "in-the-skin" deployment of pre-configured computers, mostly PCs, mostly NT, but more and more UNIX as you go up-market.
Software: More layers, more standards, more choices. S.100 will gain traction in the mid-range, but so will servers based on TAPI as the primary application layer. Two major camps will be Microsoft-centric, and Internet-centric. Customers will want a full range of choices in all application areas. The cost of these systems will be high enough to support a reasonable level of integration and support, so that a locked-in suite of applications is not needed. Indeed choice is required, since the customer may have parts of a telephony server, such as a conventional PBX, a fax server, an e-mail environment, in place and will be unwilling to replace what he has.
Channel: Flexibility and diversity reign here in the mid-range. Everything from one-stop shopping where a technology giant might provide almost all the product content and delivery on its own, to completely ad-hoc integrations by mid-sized resellers will be seen in the mid-range. The locus of system integration will move around, depending on customer need and market segment.
Partnering: Lively partnering will characterize the mid-range. More products are ready for this market, and more combinations are possible in the mid-range than in the low-end or the high-end of telephony servers. This is where the flexibility required by customers plays to suppliers' advantage. Those willing to stick to their core competencies and partner most effectively for the rest of the system will get to the business first.
Low-end telephony servers give the little guy big telecommunications capabilities at a friendly price. And in the mid-range, telephony servers will replace conventional PBXs deployed in businesses with more powerful, productive, and flexible systems. But what is a high-end telephony server? Who uses it, for what? Picture this: Your cable company launches a broadband Internet service. At their head-end they will, for a reasonable fee: Take phone calls originated from your PC or your household phones, carry them over their network locally, and connect directly to a long-distance carrier at their facility (perhaps even bypassing the long-distance carrier); Eliminate the need for a conventional modem for your PC to make data or fax calls (and, by the way, enable you to receive in-bound faxes without using a modem or tying up a phone line); Back up your PC's data; Take your calls when you do not answer, and deliver the messages by e-mail; Enable you to fetch your e-mail from any telephony and have it read to you, or faxed to you; Provide you with a single, unified identity in both switched-circuit and packet-switched worlds so that people can reach you by whatever means is most convenient to you. All this in addition to Internet access. All this is the function of a high-end telephony server. Of course, the phone company is up to much the same thing, only it will use xDSL technology over the phone line.
At the high end, these are the hardware, software, channel and partnering possibilities:
Hardware: Customers are big ISPs and LECs. At this level, the difference between the way ISPs view the world and the way LECs at it can make all the difference - the difference between needing to meet NEBS standards or not, for example. ISPs are more likely to buy off-the-rack, and to look for what computer people regard as standard. LECs have their own world of standards. The trajectory of hardware has moved from the cost-optimized at the low end, to the flexible in the mid-range, to the customer-specified in the high end.
Software: The Internet didn't need to bring it back - this is where UNIX never left. Though NT, as everywhere, is growing in importance. The biggest PC OEMs have carrier-class telephony servers in their sights. This is in no small measure due to the fact that systems in this range are customer-specified. One consequence of that is that computer people, who have had trouble formulating products for computer telephony can rely on the customer in this segment to lead the way. This is almost the exact opposite of the situation at the low end of the market, wherein the customer may not know or care what a telephony server is - they just want solutions and convenience.
Channel: Direct. You can write all the customer names on one side of one sheet of paper. On an index card if LECs are the target market. Any significant deals, especially for innovative products, are an executive selling situation.
Partnering: Partnering at the high end is situational. Many sales will be made in response to formal requests for proposal. So partners are picked - and sometimes dictated - by customer demands. As in hardware selection and software, some vendors will find the high-end more congenial just because the customers here are much more likely to know, in detail, what they want. Companies on the outside of this market can make use of partnering to become insiders.
Those are the market segments. Each has its own characteristics. At the low end, producing a telephony server means taking an understanding of telephony and coming up with a product that is much like a computer peripheral. It has to be cheap, easy to install, and virtually maintenance free. At the high end, itâ€™s the telephony that matters, and the considerations that go into creating telephony servers at the high-end are nothing like those that go into successful mass-market computer products. But no matter if a telephony server is low-end, mid-range, or high-end, this is what a telephony server does:
A telephony server provides dial tone to handsets.
A telephony server connects handsets and Internet conferencing clients to switched-circuit PSTN trunks.
A telephony server enables computers to look like extensions on a PBX.
A telephony server enables handsets to call in to Internet telephony endpoints.
A telephony server provides a platform for the full range of telephony applications: unified messaging, call-center functions, remote-access, Internet router, fax server, and personal productivity applications.
A telephony server is, to sum it up, a way of blending and sharing packet switched and circuit switched resources so that the users of a telephony server get their work done without having to think about sharing, using, balancing, and optimizing those resources themselves. It still is an application platform, but the role a telephony server plays in blending circuit-switched and packet-switched network capabilities and uses is now its most important aspect. Sharing resources and blending utilization have been and will remain the foundations of value in communications products. This fact has moved IP telephony gateway technology into the heart of the telephony server. Even if the telephony server sits outside the router and outside the PBX, its job is to make the usefulness of the router and the PBX look seamless to the user.
Copyright 1997 Zigurd Mednieks. May be reproduced and redistributed with attribution and this notice intact.