May 2000

BY TONY ROUG

Write once, run everywhere -- it's the software industry's mantra for open, standards -- based computing. At a recent industry technical event, the head of a new Internet start-up stated it simply: "Today it costs about $10K to create a custom Web site and $100K to telecom-enable an existing Web site. Which model can lower the telecom part of the solution by an order of magnitude?" His second question was, "How can I get telecom to look just like Web? My application works in an IT organization or as Web hosting. How do I enable telecom hosting?"

The elusive golden telecom API seems like the answer that would enable that unbounded creative hacker in every garage, basement, attic, or Internet startup to build the killer application.

Getting the application community to converge on one API is no simple task. It hasn't happened yet, after years of trying. Do we just give up? Or is it possible that the golden telecom API isn't really the answer to writing once and running everywhere?

IN THE BEGINNING
No industry has worked harder to create a single API than telecom. If you are new to this saga, it's useful to begin with some history. First, let's define telecom. For this discussion, I define telecom as the processes of establishing and interacting with a real-time connection. Many people now expand telecom to include fax and video. This is certainly true in general, but I propose to focus on just the ability to make connections that allow voice-to-voice interaction. Since this has been the primary mechanism for real-time, person-to-person communication for about 100 years, it would seem we should be able to define an API for supporting it without much trouble. But it is exactly this point that has caused much frustration over the years.

When the computer telephony industry was launched back in the 1980s, it certainly seemed like it would be easy to define a standard API. Companies like Dialogic, Natural MicroSystems, and Brooktrout started from the bottom up, creating open hardware with simple, open telecom APIs. Although these key players all used different APIs, they were able to prove to the development community the concept of enabling an open telecom API.

As the market for intelligent call centers in the enterprise grew, it spawned a number of industry efforts to create a standard version of the open API. The candidates ranged from TAPI on Windows to the PBX APIs: SCAI (Nortel), ASAI (Lucent Phase I), and TSAPI (Lucent, Siemens, Nortel, and IBM Phase II). Finally, with the emergence of Java, there was Java TAPI (JTAPI). Although many of these APIs are in some form of deployment, no single one has been universally adopted.

ENTER THE ECTF
The Enterprise Computer Telephony Forum (ECTF), launched in 1995, heralded the promise of converging the alphabet soup of telecom API candidates into a single, standard API. The ECTF aggressively specified a comprehensive model for one part of the problem, interacting with the voice path. This was called S.100. The ECTF did not focus on the other part of the problem, setting up the call.

So has the ECTF succeeded? Unfortunately, the answer is not a simple yes or no. What the ECTF did produce was an open model for defining a telecom API. One implementation of a general telecom model is called a CT server. The model has three layers:

1. The application programming interface, or telecom API.
2. A telephony services layer supporting resource and call management abstraction.
3. A service provider layer, supporting new hardware and protocol resources.

This model enables applications written to the emerging APIs to work with multiple vendors and networks -- essentially answering the question of how to write once and run everywhere for the application developer. Just as the Web server enables Web applications to run anywhere, the CT server enables telecom applications to run anywhere. Does this also mean the public network?

AND ON THE PUBLIC SIDE?
While all this was happening in the enterprise community throughout the 1980s and 1990s, the public network was not just watching. It was aggressively looking at an evolutionary model called intelligent network (IN). Although IN has been deployed, it never seriously approached defining a golden telecom API.

Then, starting about three years ago, Internet telephony and telecom deregulation heated up the telecom landscape. New telecom enabled through deregulation and the Internet have a focused strategy for offering lower prices and more flexibility to attract high-value enterprise customers. The existing service providers are now forced to become more open and are pursuing strategies to leverage the Internet and attract high-value applications.

As a result, a whole new industry of application service providers has emerged, offering services from simple Web hosting to advanced services like customer relationship management (CRM) and enterprise resource planning (ERP). The public network now has the same needs as the enterprise in attracting third-party developers with the golden telecom API. So the next logical step seems to be putting the enterprise APIs and the ECTF CT server model into the public network. Unfortunately, it's not that simple.

The public network has started a whole new set of forums focused around the golden telecom API (see sidebar). As these forums explore enabling enterprise applications, they must begin to choose whether to create a new API or enable the existing telecom APIs. This is where the industry is today.

THE SOFTSWITCH MODEL
While this question is being answered, one common concept has emerged: an open model abstraction called the softswitch. Like the ECTF model, in its simplest form the softswitch consists of three components:

1. An application interface supporting third-party development hosted applications.
2. A network services layer supporting call abstraction.
3. A protocol adaptation layer enabling the softswitch to control network resources.

Ideally, this model allows softswitches being developed and deployed in the public network to support the CT server model and all the enterprise APIs.

WHAT NEXT?
Unfortunately there is no simple answer to the question of the elusive golden telecom API. What we can say is that the industry is aware of the issue and that momentum is building for a single model which can support the goal of write once, run everywhere. The Internet achieved this model with the "golden" Web servers. The CT server and the softswitch hold the promise of creating the "golden" telecom server.

Tony Roug is Director Advanced Networks for Dialogic, an Intel Company. For more information, visit their Web site at dialogic.com.

Looking for gold? Here are some places to do some prospecting.

Enterprise

• Microsoft -- TAPI, SAPI, and Web Telephony Engine.
• Enterprise Computer Telephony Forum -- S.100 and Java TAPI (JTAPI).
• European Computer Manufacturers Association -- Computer-Supported Telephony Applications (CSTA) and Telephony Services API (TSAPI).

Public Network

• The Parlay Group -- Parlay API.
• Java -- JAVA API for Integrated Networks (JAIN).
• International Softswitch Consortium -- Application Working Group.
• VoiceXML Forum -- Voice eXtensible Markup Language.

Joint Enterprise And Public Network Efforts

• Microsoft TAPI and Parlay have a goal of a common model.
• INForum and the ECTF are exploring a common model.
• The JAVA community has announced a JTAPI Cafe to explore a common model for JAIN and JTAPI