With the new Java Telephony API, the integration of computers and phones will finally become a reality
Through the Java Telephony API (JTAPI), technologies offered by telecommunications and telephony vendors can be merged with Web technology. This article takes a look at how JTAPI provides a universal framework for different telephony standards and systems.
The Java Telephony API: NC phone home
If you are one of the few people on Earth who has not seen Steven Spielberg’s global movie hit E.T.: The Extraterrestrial, you may miss the point of this section’s title. In the movie the lovable alien hero makes a very long-distance telephone call using common household appliances. With the computer industry poised to take on the world of telecommunications, the not-as-cute-and-huggable heroes of the industry are proposing to do the opposite: Make phone calls with not-so-common household appliances.
Computer telephony integration (CTI) has been on the radar of many vendors who look to break the global oligopoly of telephone companies and telephone hardware vendors. The problems of directing a telephone line over digital data networks has resulted in either high costs or poor data transmission. Until recently, these associated problems have been due to the lack of good analog-to-digital processing capabilities and, more so, to the lack of support in common operating systems. With digital signal processing (DSP) technology becoming readily available in even low-cost systems such as PCs, and telephony integration in operating systems like Windows NT, Windows 95, and even a few Unix systems, these final hurdles just may be overcome.
Java’s appearance has upset the way we think about computing. Before the language’s arrival, the concept of multiplatform software meant creating a separate product line per platform. CTI has been approached by using proprietary operating systems or interfaces to operating systems. JTAPI provides the first mechanism that spans the different CTI standards and integrates telephone systems with any Java-capable server system regardless of platform. Additionally, one of the original focuses of Java (when it was called “Oak”) was to create an embedded computing infrastructure for appliances and electronic devices. With JTAPI this goal is now coming to fruition.
This integration recently materialized with the Java Telephony API 1.0, which was announced in November 1996. Scott McNealy, CEO of Sun Microsystems, has promised to take Java into the embedded market, and JTAPI will play a crucial role here. Java may soon become the minuscule operating system that is found in future cellular telephones or even in microwave ovens. It may be possible to dial into your house computer from your workstation in order to find out, through your Web browser, if your significant other left the clothes in the washer again. Impractical, you say? Just think how important and useful your TV/VCR/stereo remote-control unit is today!
JTAPI also will provide the capacity to make your network computer (NC) into a voicemail or telephone unit. Given Oracle Corp.’s plan to make an NC with a phone unit built into it, this is not as ridiculous as some may think.
Put your JTAPI shoes on and bring on da noise!
The concept behind JTAPI is to provide the framework for creating telephony applications and services. Like other Java APIs, it is not restricted to specific telephony APIs. In fact, JTAPI can be implemented over existing popular standards like Microsoft TAPI, Novell TSAPI, Sun Microsystems SunXTL, and so on.
JavaSoft plans to integrate JTAPI with the Java Media API, providing services for audio and video to Java applets and applications. This tight integration will remove the common redundancy in many systems between audio/video in the operating system and the telephony system.
One goal is to provide enough functionality to support 80 percent of all industrial solutions. Although this aim is vague, still it provides the impetus to create common applications such as digital telephone systems, call-center systems, video conferencing, and so on, with a platform- and system-independent basis of the Java machine.
Although high-level services such as packages for call-center systems and management systems exist, programmers have easy, application-level access to JTAPI through simplified interfaces; in other words, JTAPI has both the noise of heavy-duty applications and the funk of small, “cool” applets.
Getting into JTAPI
JTAPI has a set of core APIs and many support packages. The core API provides functions for creating a connection, designating a telephony software- or hardware-based provider subsystem, instantiating a call, identifying unique telephone or directory numbers, and managing devices and terminals.
The extension packages provide services for advanced call control, Java Media API integration, managing isochronous (time-based) and synchronous network communications, call-center management, terminal management, private data communications and interchange, and a capabilities identification mechanism. There is also a separate extension package for Java in mobile telephones.
These extensions are divided by function so as to separate need and utility from implementation. Some functions make sense for the individual caller, while others make sense only in high-end situations like a call center or a technical support center.
JTAPI: an example
Consider as an example of typical JTAPI use a simple applet/application that allows a network-computer user to dial another station over the data network rather than using analog lines. Within one office this may be overkill, but in cases where traffic occurs long distance between locations in different cities or between countries, the result could be significant cost savings.
When a caller initiates a connection, the application will make a Call.connect() with a given directory number. On the remote end, the call recipient’s computer and Java application are waiting on Connection.answer(). The caller’s application sends the request, and the call recipient’s application changes from an “idle” state to an “alerting” state. Once the recipient accepts the call, both systems move into a “connected” state. Audio and video data are transmitted as usual during this phase until one person hangs up. Both applications transition into a “disconnected” state before returning to idle. Should communications abruptly terminate for any reason other than a user hanging up, the software moves to a “failed” state. At this point, the applications may attempt to redial one another, or they may handle this failure in another way.
The applications can also fall into a “passive” state or even an “unknown” state. A passive state might be used in applications whereby the receiver or dialer is in complete control from their end, or this state is used by a moderator. An unknown state is an application-level failure due to an unpredictable error in the application.
Drop a phone book on ’em
You know how big telephone books can get; just getting in touch with someone can become a big headache. Try choosing a global directory system for all telephone-capable systems. JTAPI itself does not decide on how to uniquely identify users since this involves attempting to unify parts of other telephony standards. Instead it specifies a URL that depends on the type of protocol being used.
JTAPI makes connections using a new type of URL schema similar in function to JDBC. Let me warn you that what you’ll be seeing is a little weird; I’ll explain shortly. The new URL type is shown below:
telephony:[company stock symbol][subprotocol][address]
The address portion is specific to the type of subprotocol that you use. For example, it could be:
telephony:SUNWxtl://phone.extraterrestrialhomeworld.com:7777/microwave()
or
telephony:LUtsapi:CTI-driver;UID=ET;PWD=Earth
As an explanation of some of the terms above, “SUNW” is the New York Stock Exchange symbol for Sun Microsystems, “xtl” is the protocol standard that Sun created for network telephony some time ago, and “microwave()” indicates the type of connection or certain subaddress information to connect with.
The weirdness I alluded to above involves the stock symbol identifier. When I saw this, I became curious about JavaSoft’s intentions. In my years of programming, I have seen many different ways of uniquely or globally identifying names; using a company’s stock symbol certainly is unique. It raises a lot of questions about the approach in design and other elements that most programmers are not as familiar with; for example, what happens when you are a privately held company? JavaSoft engineers simply indicated that, in such a case, they would “make something up.” This procedure sounds too ad hoc to me.
Ending our conversation
JTAPI introduces a very practical side of Java — in the area of voice communications. I believe, as Sun does, that digital voice and video communications over the network will become a very important part of the future; this vision also is shared by some of the big industry leaders such as AT&T and Lucent Technologies, Nortel, and Novell. This support probably has something to do with the fact that the future of the multitrillion-dollar global telecommunications market is at stake.
JTAPI provides the framework for application developers to quickly integrate common telephone services such as call forwarding, voicemail, and so on into their other software applications. In addition, with the projected extensions and the ability to create new ones, JTAPI also will serve the high-end voice communications and call-center markets. It will be some time, however, before these systems become commonplace, so don’t toss out your regular telephone yet.
