Google
 

 

 

 

CT, Phone Home

Will Bill G. Finally Get His Ultimate Wish,
and Rule The Heavens?

Francis Vale

What does Gates really want with computer telephony integration (CTI), and its ubiquitous Win95/NT TAPI, anyway? Why, nothing less than to be your new Ma Bell. To see how he probably plans to make this gender change, let's carefully eyeball the CTI scene, and see what it may hold in store for users.

Essentially, computer telephony came into being when a link was created between the mainframe that contained the data/applications, and the big digital PBX (private branch exchange) that controlled the telephones. Via this new 'CT link', mainframe applications could now assist/control how human operators interacted with calling customers. This was a third party call control system; i.e., the PBX did all the work on behalf of the user in either placing or receiving calls via different resources. In contrast, first party control is when all the telephone resources are under the user's direct control; e.g., your home phone -- unless you have teenagers, of course.

Digital PBX systems used to be the ultimate in closed systems. (See "So Who Ya Gonna Call? How PBX Vendors Finally Got The Message" ) Their 'terminals' are special telephones that use a proprietary signaling mechanism to communicate with a particular vendor's PBX. Thus, the PBX was a classic big iron-dominated architecture, with dumb clients. But in the 1980's, in the now known-to-be-horribly-mistaken belief that 'superPBXs' would control the new PCs (remember why IBM bought Rolm?), many of the PBX vendors began to open up their switches to new types of host programmable CT links. This effort was called the Open Architecture Interface. Nonetheless, under OAI, you still had to reprogram your applications to each different vendor's phone system. There was no standard application interface, or API.

But in the 1980's, of course, it was Novell which emerged as the driving force in linking PC networks, via its Netware server OS. It was thus natural that Novell would seek to gain market leverage by establishing an intelligent CT link between its Netware servers and the PBX servers. AT&T, one of the largest PBX vendors, would also ally itself with Novell in this effort. One of their goals was to use PC LANs to lower the cost of mainframe/CT/PBX applications from $20K per seat, to a fraction of that cost. Another goal was to move the intelligence for call control away from the PBX (which now becomes nothing but a fast, reliable, matrix switch) to LAN computer telephony software, and simple GUI-driven systems.

But what to do about a standard API from applications on the Netware server to the vendor-unique PBX? Fortunately for Novell/AT&T, they realized that the Europeans had a ready made solution for their API quest: The International Telecommunications Union's specification for Computer Supported Telephony Applications (CSTA). The CSTA specification also breaks the OAI bottleneck, and provides a standardized means for those OAI-based PBXs to communicate with other systems, like Netware. Novell's TSAPI (Telephony Server API) is based on this CSTA specification. Finally, in 1994, AT&T announced that some of its PBXs would be supporting TSAPI.

Greatly simplified, the Novell TSAPI architecture goes like this: At the lowest level, to access the Netware server via the CT link, the PBX or telephony board level vendor must provide a Netware NLM/PBX driver. Above that, is another Netware NLM, called the switch driver, that routes multiple application messages (CSTA service requests and TSAPI events), to and from the PBX driver. A couple of layers above the switch driver is TSAPI, the CSTA-based C language definition which the telephony-enabled applications use. Thus, if you program just to TSAPI, all the Netware/PBX supported call control functions are accessible (usually).

On the client side, Novell provides PBX independent libraries for Macintosh, OS/2, Windows 3.x, UNIXWare, with NT and Windows95 support on its way. These client libraries are used to access the TSAPI-enabled, NLM functions on the Netware server. Significantly, TSAPI only provides for call control. Telephony media control, such as over faxes, speech, etc., is not supported by TSAPI. That media control is the province of the client application. Packaged all up, Novell calls this multi-tiered wedding cake of APIs and NLMs 'Netware Telephony Services'. Novell has also introduced a run time version of this product, so you don't need to buy all of the functionality of a Netware server. You can purchase just the telephony services part. Novell's stated goal is to have 300 certified resellers to support its new technology.

Currently, there about fifty or so PBX vendors who are, or will be, supplying the PBX driver NLMs for their switches. Some of the TSAPI-PBX vendors are AT&T, Siemens, Fujitsu, NEC, Alcatel, Comdial, and others. On the client software side, there about 100 ISVs developing TSAPI-enabled applications. Like the number of PBX vendors, there are some fifty shipping TSAPI-compliant applications. Among these TSAPI ISVs are Active Voice, Answersoft, Aurora, AVT, Callware Technologies, and Q.sys. TSAPI applications include: voice mail, fax servers, speech synthesis and recognition, developer kits for CA Clipper, Btrieve, and Netware SQL, interactive voice response (IVR), telemarketing, conference calls, and even OLTP.

Cost wise, there are some issues that have to be faced in Netware TSAPI systems. The PBX vendors typically only provide TSAPI NLM driver support for their newest, top of the line systems. Moreover, these PBX NLM drivers are not cheap, and can cost $10K to $40K. For that princely sum, the PBX vendor typically builds a firewall between the PBX and the Netware server, adds in some PBX boards, and has to write some complex software to get the anachronistic beast talking nicely to Netware. If you have an older PBX, you may have to do a 'forklift' upgrade, whereby the truck comes in and takes out the old PBX, and plunks done a new one that supports TSAPI. This also runs up the TSAPI telephony bill many thousands of dollars.

A Netware Telephony Services 2.1 license is priced from $140 to $260 per user. (A five user license pack cost $1,295.) Then there is the cost of the TSAPI NLM application software. And finally, there is the hardware cost of the Netware server itself. So, to build a decent sized TSAPI system, you can plan on spending $50,000, or more. As this is a shared service, the more users you can load up unto the system, the cheaper it gets. Fifty users (Approx. $1,000 per seat) is probably the break point.

In this multi-user context, Novell/AT&T has obviously met its goal of reducing the cost per CTI seat from $20,000. But also bear in mind, that even before Novell, there was a thriving new industry devoted to creating low cost, PC-based telephony services that ran under DOS, OS/2, and UNIX. Most of these PC systems can do without a PBX, or can emulate one. A twelve line DOS-based system with a dedicated Pentium PC, telephones, fax, automated attendant, speech commands, audiotext, voice mail, etc., can be bought for less than $5,000. The magic number then drops from $1,000 a seat to about $400 a seat for a full featured CTI system. Moreover, this is for a small number of users. A Netware TSAPI-PBX system cannot compete at that limited seat/price level. The Netware-PBX solution is thus the classic downsized client/server system.

Now enter TAPI in 1993, Microsoft's and Intel's telephone application program interface. TAPI is part of Microsoft's WOSA (Windows Open System Architecture), which includes the database ODBC, and MAPI messaging services. TAPI was originally available within some Windows 3.x telephony applications, where it was an embedded feature. But the real action for TAPI began when it shipped with every copy of Windows95. The new Win95 TAPI also uses a dynamic link library (DLL). A DLL is a shared library, so if it is already loaded and being used, then it is shared by other applications.

Via Win95 TAPI, developers get a common interface to a wide variety of communications systems. Win95 is Microsoft's first attempt to separately abstract out telephony control and data communications functions. One set of Win95 APIs (Win32 COMM) does device configuration and sets up data I/O in a device independent way. TAPI works in parallel with Win32 COMM. Thus, data flows through Win32 COMM, and call control routes through TAPI. TAPI also does its control act over data, fax and voice calls in a standardized way. Via Win95's new APIs working together, TAPI-based applications run in a device independent environment. So, like Netware TSAPI, MS TAPI means no more writing unique software to accommodate a variety of vendors' systems. One TAPI size (hopefully) fits all. These TAPI supported systems can include a range of devices, from single line analog POTS (plain old telephone service) to ISDN phones, to PBXs, to fax/speech-data modems.

TAPI also has a hierarchy of control functionality. At the basic (mandatory) services level, TAPI manages all signaling between a computer and phone network, including dialing, answering, and hanging up a call. At the (optional) supplementary services level, TAPI can also hold a call, transfer it, conference a call, 'park' a call, etc. These supplementary call control features are the usual province of PBXs. It is left up to the PBX vendor, or other such telephony switch device vendor, to decide whether or not they want to support these supplementary TAPI features.

The behavior of these supplementary features, if supported, is supposed to be consistent at the TAPI level. TAPI also has an Extended Services level. This level of driver specific services provides functions outside the standardized scope of TAPI. Remember, there is no free lunch in telephony. For example, the manner of signaling to a PBX for different call control functions varies widely from vendor to vendor. If the PBX vendor's functionality cannot be encapsulated within the standard supplementary TAPI, then TAPI can be extended by the device vendors themselves.

At this extended service level, the vendor must carefully document the behavior of its features. At each of the three TAPI service levels, it is up to the device vendor to supply a special Win95 driver, called a service provider interface (SPI), which communicates with its devices on one side, and the TAPI DLL on the other side. The TAPI DLL then connects to the TAPI-enabled application via the TAPI API.

With Win95, user/developer TAPI configuration and control therefore becomes much easier, if not simple. Moreover, unlike Windows 3.x, multiple communications boards can be simultaneously accessed without causing problems. Also, two applications can make a grab for a communications resource (same or different) and the system won't go into cardiac context switch arrest, like Windows 3.x would.

An issue that immediately comes up is how does one get a TAPI application talking to a Novell TSAPI NLM? The answer lies in a no cost contribution from Northern Telecom, called TMap (Telephony Mapping). The freeware TMap dynamically maps a TAPI application onto TSAPI. No modification of TAPI applications is necessary to invoke TMap.

Most significant, Win95 looks at voice as being just more one media data type. Control over telephony media, like voice and speech recognition, thus falls within the province of Microsoft's media APIs, not TAPI. Playing and recording voice files, for example, would use the WAVE (multimedia wave audio) API. Microsoft also seems intent on doing away with the need for special DSP boards to do speech processing (e.g., text into voice), via its new audio APIs.

As noted, Microsoft first announced TAPI for Windows 3.x. This made TAPI a first party control system. Thus, if an organization wanted to provide telephony functions such as speech recognition, fax, etc., it had to outfit each and very PC with the appropriate software/hardware. Windows95 TAPI does not change any of this. The cost for a complete set of TAPI-based telephony services in each PC can be upwards of $1,000 per seat.

But by making telephony resources shared, as in an NT Server system which has third party call control (a la Novell), then costs could be lowered as the number of users increased. Even more important, NT Server TAPI means the likely CT integration with SQL server, and Server Exchange, Microsoft's unified message passing system; i.e., TAPI goes into NT Backoffice. The NT Server Exchange software boosts the Exchange clients' power and flexibility, such as adding message threading, and simultaneous viewing and editing of shared documents on the network.

The Win95 Exchange client itself lets you receive e-mail from multiple sources, faxes, and voice mail (with third-party voice-mail products) in a single in-box. Put this all together with TAPI, and NT Server might just become the ideal place to put all those other traditional PBX functions, such as call-accounting database, storage of user files, messaging systems, and network management. Once you have done that, well, why not just throw out the PBX, and put in a cheap, reliable, matrix switch to simply route calls from one place to another?

If all else fails, don't be surprised to see a Microsoft-encouraged set of SPI 'state machines' for the big vendors' PBXs. These special SPIs would likely came from some unnamed third parties, and would attempt to provide a consistent TAPI application cross mapping between different PBX systems and their unique services. These PBX SPIs would also likely be free, and would probably be bundled into either the NT Server OS, or SQL Server. Bill's TAPI partner, Intel, has already graciously offered to build a line of add-in, low cost, PC cards that emulate the proprietary signaling protocols used by the PBX telephone keysets. These special phones are one of the largest revenue producers for PBX vendors. Moreover, when PBXs become nothing more than intelligent switching hubs for distributed computer telephony, how long will it take for Cisco, et al, to realize that the lumbering PBX vendors are easy pickings?

The PBX industry is obviously about to convulse. And if you follow this logic all the way through, then telephony control probably moves away from the telecommunications side of the house to the MIS side. CTI is about to become a new turf war supreme. It's the client-server saga played out all over again. But this time, MIS is the likely winner.

But there is still one big impediment to NT Server CTI uber alles: all telephony media control is still done at the desktop via the Windows multi-media APIs. NT Server only does call control, just like Novell's TSAPI. NT Server has no telephony multi-media, services-oriented resource manager. So, how do you build a distributed telephony multimedia system via NT/Windows? Well, as of today, you don't, and you can't.

But Gates had better hurry up, because such a service level, resource manager for distributed media control for PC-based CTI already exists. It is called the SCSA TAO (Telephony Application Object) framework, and it is well on its way to becoming widely supported. The MVIP/SCSA vendors are now offering PC-based telephony systems with a thousand+ lines, which are fully distributed (including media services), are very intelligent, are systems independent, and can work without a PBX; except perhaps as a pass through matrix switching hub. (Significantly, Mitel, one of the world's largest PBX vendors, has already endorsed this distributed, non-PBX vision.)

So, assuming that it takes some time for Microsoft to get these complex, distributed telephony media issues sorted out, how can it expect to outflank these now entrenched PC/CTI upstarts? One key element of Gate's battle strategy may be centered around the integration of Backoffice with ISDN (Integrated Services Digital Network). This integration could allow Microsoft to offer a killer telephony application: The wide area, distributed, all digital, intelligent CTI network.

It has been reported that Gates is spending a tremendous amount of time in Washington D.C. talking up the case for ISDN. Apart from the fact that Microsoft is now supposed to be the largest single user of ISDN services in the country (accounting for almost 10% of all installed ISDN BRI lines in North America), there are probably other reasons for his interest in this digital telephone technology. The clue to his collecting all these frequent flyer miles may be the fact that a proprietary PBX system is an island unto itself. It cannot communicate with another PBX. But the new, all digital, ISDN PBXs can communicate between themselves, cross town, or cross country. Moreover, being all digital, these PBXs are primarily software driven systems.

ISDN is not a telephone service. Rather, it is a technology that's based on the way information moves across public telephone networks. It used to be that all signaling information about the phone call you were making (who you were, who you were calling, time of day, etc.,) was carried in-band; that is, it moved ahead of the call along the same calling circuit. To speed things up, that signaling information was moved outside the call circuit, onto a separate high speed network. This was the advent of out of band signaling. ISDN takes advantage of this out of band signaling to establish a separate link for call set-up and control.

On T1 lines, via just one twisted pair, you get up to 24 digital channels (30 in Europe, on E1). When the ISDN protocol is used with this 24 channel T1 circuit, it is called PRI, or primary rate interface. PRI provides 23 bearer (B) channels for data/voice, with each channel moving along at 64Kbps. The 24th channel is the D channel, and it is the key to the whole PRI scheme. The D channel carries an HDLC-based (High Density Link Control) packet data channel which runs various transport protocols, and a transaction-oriented call-progress state machine.

The D channel can carry incredibly content rich information. Included in the D channel data can be caller ID (it displays the caller's phone number), advanced maintenance and diagnostic messages, and can control the way the other B channels are dynamically grouped together, for things like video teleconferences. Significantly, PRI lets an ISDN PBX in New York easily and quickly communicate with an ISDN PBX in Los Angeles over the signaling D channels. The smaller brother to PRI is BRI, or Basic Rate Interface. BRI carries to the home all the benefits of ISDN's B and D channels, but you get only two 64Kbps bearer channels (2B), and one 16Kbps D channel. [Or stated more correctly, sometimes you can: see "The ISDilemma Network"]

Now, suppose Backoffice succeeds in getting all the PBX intelligence placed on it (e.g., call accounting, network management); and Exchange messaging services become the primary means of sending/receiving integrated e mail, voice mail, etc. Further, let's assume that NT Server finally gets a distributed resource manager for media services, like SCSA TAO has. And let's not forget that Microsoft has already done an NT deal with Digital to gain access to the latter's cluster technology.

Finally, let's say that ISDN PBXs become commodity items, thanks to market forces. And if this CTI/MS puzzle of parts should cleanly came together, what would you have? An enterprise capable, robust, scaleable, international digital telephony network with all the call intelligence distributed via NT Backoffice, that's what. And because ISDN networks are software based, how long would it be before Microsoft starts up a metered use, wide area telephony network, to provide value added services, like videconferencing? The much ballyhooed and boo'd MS Network would be but a pale shadow compared to this Ma Gates scheme, if it was pulled off.

But there is another key factor in the overall Gates computer telephony calculation, one which he has already (he hopes) planned for. It concerns the possible future of CT eating the desktop, and along with it Microsoft's and Intel's lunch. George Gilder, the economist, has already written a series of articles on such a possibility. Realize this: Bandwidth is to communications what faster clock cycles are to CPU power. The more you got, the more power you have. And the present contrived scarcity of communications bandwidth is the telecommunications industry Watergate. There is absolutely no reason why you should not have multi-megabit delivery to your desktop today. Some large companies, in fact, like EDS, know this, and have already made their moves to open up the nation's dormant fiber pipes for their private, internal use. These are the so called 'dark fiber' networks; millions of miles of unused sections of fiber laid down by the phone companies for future use.

A single strand of fiber, running free and unfettered by switching electronics, has an intrinsic bandwidth of 25 thousand gigahertz per each of the three groups of frequencies (three passbands) it can support. Just one such fiber thread can carry twice the peak hour telephone traffic in the U.S. Within the next five years, if fiber was used at its true data carrying capacity, 500 megahertz two way communications can be brought into the home (your house currently shuffles along at 4Khz over copper). This is multimegabit speeds straight into your PC. Via compression or more advanced technologies, speeds would soar into scores of gigabits. In this scenario, ATM as the communications protocol might be used, as its fixed packet, 53 byte cells facilitate fast networks.

So what's stopping all this bandwidth progress? For fiber to work at these awesome high speeds, it needs to be all optical. Put an intelligent, electrical switch in its path, and it slows way down. Thus, fiber nets work fastest when they are 'dumb'. But the telephone companies make their money by building intelligent switches that monitor your calls so they can then bill you. Thus, to make money, they have to artificially hamstring fiber's go fast capabilities. The phone companies are therefore in no hurry to use the full bandwidth potential of what they already own.

But, as all will now ask in confused unison, if there are no intelligent switches, how do you route the dumb fiber call? The answer is surprisingly simple: With massive bandwidth, you can create any type of logical switch you desire. The best analogy is AM or FM radio. The 'air' bandwidth is sufficient that you simply turn to the desired station frequency on your radio dial. Likewise, if fiber bandwidth is abundant enough, you just 'tune' your PC to the fiber frequency assigned you. That means millions of frequencies over fiber, of course. This incredible feat has already been accomplished; with IBM having the first fully functional, all optically switched fiber system, called, appropriately enough, 'Rainbow'. Its opto-electronics interface fits on a single PS/2 Microchannel card. To the Bell operating companies and long distance carriers, Rainbow must rank right up there with flood, pestilence, and the FCC.

From the computer side, the folks who control the CPUs (i.e., Intel) also see a market threat from such a bandwidth firehose. You get enough bandwidth into your PC, and it can flood even a fast Pentium. At 622 megabits/second ATM rates, the processing power of a Pentium class machine has under 100 instruction cycles to read store, display, and analyze a packet, plus do its other housekeeping chores, like run spreadsheets, etc. But as networks approach gigabit+ speeds, the demands on conventional CPUs, no matter how fast, will simply be overwhelming. And if unlimited bandwidth becomes 'free', does your PC now become a multimedia/telephony/videconferencing machine first, and a spreadsheet/WP/DB system second? In that possible event, what does it mean for the Intel/Microsoft PC cabal? What do you use for a PC processor/OS to deal with this bandwidth torrent?

If such a watershed event should come to pass, Gates, along with TV cable baron John Malone, have already hedged their desktop/cable box CPU bets by each ponying up $15M to invest in a Silicon Valley startup called Microunity. This remarkable company's hopes are pinned on making communications processor chips that can process this coming bandwidth deluge a 100 times faster than a P6; but do so at clock speeds that are only ten times faster than the new Intel CPU. The low clock speed is the key to Microunity's success. For otherwise, how do you develop memory subsystems that can keep up at this blinding pace?

But if Microunity does not succeed, other contenders are ready to take its -- and Intel's -- place. The most notable contender being digital signal processing (DSP) chips. (See Why Digital Signal Processing Chips Might Put Intel and Cray on the Trailer ). Both Texas Instruments and Analog Devices have announced 32 bit superfast DSPs that are inherently parallel processing. (Their architecture is very Transputer-like, for those whom that term means something.) In a word, they are blindingly fast. Working in parallel, these big DSP chips routinely cruise at two and three BOPS (billion operations per second), or approximately 1,000 to 1,500 DSP MIPS. Whereas DSP MIPS and regular computer MIPS are apples and oranges; to get the equivalent DSP MIPS of a standard microprocessor, an industry rule of thumb says divide by three. So, an Intel part would have to run at 3,000 MIPS to catch up to one of these new generation DSPs.

Needless to say, Intel is doing all it can to discourage such heretical thinking, e.g., its push for NSP. And why Microsoft is trying to kill DSPs off with its own anti-NSP approach. (See "Why Intel & Microsoft May Fail to Communicate"). Seemingly arcane industry arguments suddenly become crystal clear when it's put in the proper context. The ascendance of DSP-based processing on the new multimedia desktop, running a new breed of OS, would mean that Intel and Microsoft could find themselves forcibly pushed out of the PC catbird seat.

But even if Gates doesn't succeed in keeping his PC monopoly going, he still has one surprise left for his users. He intends to populate the heavens with 840 low earth orbit (LEO) satellites, all focused on providing packet-based computer telecommunications. This, of course, is the now (in)famous McCaw/Gates Teledesic system. In effect, Teledesic is one massive, space-based, parallel processing system. Once you get past all the bombast, it seems that Teledesic might actually work, and would not, as some critics charge, be a boondoggle kludge that will blot out the sun (and cast Gates' looming shadow across the earth).

In sum, should Gates succeed in creating this all digital, Backoffice-based, even-unto-the-heavens, global telephony/multimedia network, then Ma Bell had indeed better move over. On the other hand, as we have seen, Bill is far from alone out there in CTI land. Also, the conjoined IBM/Lotus Notes package has real potential for significantly slowing down Microsoft. OS/2 also has a fanatical following among the CTI crowd.

In fact, while NT may be doing damage to UNIX-based telephony systems, OS/2 is reportedly holding its ground. Then there is also the fact that Notes now supports telephony applications. Via Telephone Notes, you get voice mail and voice annotation for this popular enterprise messaging and data system. Further, Novell's telephony strategy is still evolving, and it also has its own suite of group messaging applications. And there is always the 'X' factor, the unexpected techno-comet that just drops out of the sky one day, obliterating all current CTI life forms.

The CTI ball is now in your court. So, who ya gonna call?

Copyright 1996, Francis Vale, All Rights reserved

21st, The VXM Network, http://www.vxm.com

s