Second Phase of CTI Evolution

APIs for Everybody

The second phase of CTI evolved from the first phase, but it represented a tremendous leap over earlier approaches. It involved APIs that were independent of the telephone system. The phase-two approach was based on the prevailing philosophy that, given a small number of pervasive operating systems to support, each development platform would provide application developers and telephone system vendors with APIs. Each group then could develop the necessary software components to build a complete solution without being dependent upon one another. This is illustrated below.

The intent of the new approach was to minimize the work necessary for software developers writing CTI applications. Thanks to a single, stable API for a given platform, application software can, in theory, run independently of any specific telephone system or product. This allows software developers who sell shrink-wrap software (not just customers and systems integrators) to develop CTI software. The result should be more applications (so the thinking went), which in turn should mean a more attractive incentive for telephone system vendors to develop the necessary CTI interfaces for their products.

This approach was not perfect, however. While it addressed the needs of software developers, it did little for telephone system vendors relative to the first phase. Telephone system vendors still had to write code for all of the popular operating systems, and they still had to rewrite those pieces of code every time a particular operating system was revised. From their perspective, at a technical level, the only real difference between the first and second phases was the fact that they no longer had to take responsibility for the design of the API.

Another challenge associated with the second phase is that solutions built using this approach tend not to be as robust or reliable as desired. The reliability that people take for granted in the world of telephony is in large part the result of international standards that define, in precise terms, the protocols for the ways systems interact. APIs, unlike these protocol definitions, are open to much greater levels of selective interpretation. Applications that use a particular standard API might not work with certain telephone system implementations supporting that same API. This is in part because the behaviors of the telephone system software are not normalized. As it was for phase one, in these cases the applications must still be specifically modified to work with a particular telephone system. (Generally, however, there is less of this work to do.)