Coagulación de la leche

Consistent with the iterative development of interoperability specifications for telephony, and the maturing of technology in the overall information technology industry, there have been three distinct phases in the evolution of CT technology:

1. Custom systems 2. APIs for everybody

3. Protocols for systems, APIs for applications

1-4 _{API — API literally stands for Application Programming Interface. In general usage, it has come}

to refer to any programmatic interface that allows two independent software components to interact. It is not limited to application software programming. To avoid confusion, this book uses the term programmatic interface to refer to generic interfaces between software components. The term API is used here to reflect conventional usage.

Each phase represents a paradigm shift in the approaches used to develop CT solutions. Each shift was based on changing economics, technology, and priorities in the telephony, computer hardware, and software industries. The products and practices associated with each phase will continue to exist and interoperate for some time to come. The economics and opportunities associated with developing products for the third phase, however, will mean that more and more industry investment and activity will migrate to this approach.

This book deals with all three phases and is intended to help anyone who is considering the alternatives to choose the best approach for meeting their own needs.

First Phase: Custom Systems

The first phase in the evolution of CT involved custom development. Anyone who wanted to integrate a telephone system and a computer system had to work directly with the telephone system vendor to obtain that vendor's proprietary (and often product-specific) CT interface. These CT interfaces ranged from specifications for how a computer could be interfaced to the telephone system in question, to special APIs for specific operating systems. This is illustrated in Figure 1-9.

The economics of this arrangement were very poor. In most cases, customers themselves (or systems integrators working on behalf of customers) were developing vast quantities of highly specialized software that was hard-coded to a very specific telephone system. Rarely could this software be reused by others who had the same telephone system. Furthermore, should customers ever need to upgrade their telephone systems, they generally needed to rewrite their CT software.1-5

1-5 _{Conspiracy? — Those who like to believe in conspiracy theories have suggested that the lack of}

CT interoperability was a direct result of telephone system vendors seeking to "lock in" their customers. A better explanation is simple supply-and-demand economics.

Figure 1-9

The first phase: custom systems

In instances where telephone vendors had invested in some type of custom API, it was often on the wrong operating system for many customers. The vendor's API still required custom software specialized to each specific telephone system. In addition, the telephone system vendor had to keep track of all the popular operating systems. Vendor's had to split their development resources between maintaining existing custom API implementations (as new versions of supported operating systems were released), and trying to adapt ("port") the API for new operating systems as they appeared.

Both of these arrangements severely limited the potential size of the CT industry for a very long time.

Second Phase: APIs for Everybody

The second phase of CT 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 only a small number of pervasive operating systems needed support. Each development platform would therefore provide application developers and telephone system vendors with APIs.1-6 _{Each group then}

could develop the necessary software components to build a complete solution without being dependent upon one another. This is illustrated in Figure 1-10.

Figure 1-10

The second phase: API layering

The intent of the new approach was to minimize the work necessary for software developers writing CT applications. Thanks to a single, stable API for a given platform, application

software could, 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 CT software. The result

1-6 _{Telephony APIs — The first mainstream telephony API was the Telephone Manager, developed}

by Apple in the late 1980s. IBM, Microsoft, Novell, Sun, and others were quick to follow over the next few years.

should have been more applications, which in turn should have meant a more attractive incentive for telephone system vendors to develop the necessary CT 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.1-7

Another challenge associated with the second phase is that solutions built using this approach tend to be less robust or reliable than 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.)

Third Phase: CT Protocols for Systems—APIs for Applications

While the second phase was characterized by its focus on the needs of application developers, the third phase in the evolution of CT is characterized by its focus on the needs of telephone system vendors and customers. It involves improving on phase two by addressing the

reliability issues and eliminating the key bottleneck, that is, the effort

1-7 _{API design — Despite the fact that all CT API developers worked with telephony vendors when}

designing their APIs, some telephony vendors did not consider this loss of design control to be a positive thing.

required by telephone system vendors to implement and maintain all the different APIs for all the different operating systems. Both of these objectives are accomplished through the

addition of standardized CT protocols to the APIs developed during phase two.

Figure 1-11

The third phase: CT protocols

In the third phase, telephone system vendors are responsible only for implementing software that runs internally on their own products. The only interaction with application software is through standardized CT protocols. This is illustrated in Figure 1-11.

Now telephone system vendors no longer need to know with how many operating systems they support or which operating systems their customers are using as the standards are the same regardless. This also allows their telephony products to be used by devices that don't even have operating systems (or CT APIs in the conventional sense). Freeing up their resources from platform-specific development projects allows telephone system vendors to focus on providing richer functionality and more robust operation.

The benefit for customers and application developers is that the normalized protocols provide a much higher level of reliability and robustness using the existing operating system-based APIs. Application developers don't have to ''special-case" specific telephone systems (unless they want to take advantage of special and unique features)1-8 _{and customers then can use}

applications without having to worry about compatibility.

1.10.3 CT Plug & Play

The term CT Plug & Play refers to the ability to take two CT products out of the box, hook them together, and have them work together without having to install special "driver," "mapper," or other proprietary software in either.

CT Plug & Play1-9 _{is made possible by the CT protocols of the third phase. The use of CT}

protocols allows one device to negotiate automatically with other devices to determine their CT capabilities. No effort is required beyond instructing one to connect to the other.

In the paradigm of the second phase, telephone system vendors had to develop special pieces of software1-10 _{for a computer to work with the CT interfaces on their products. If these pieces}

of software are not installed in the appropriate devices, or do not exist, the products simply will not work with one another.

CT will truly be universal when all CT products are CT Plug & Play.

1-8 _{Vendor specific extensions — Vendor specific extensions are defined in Chapter 5. They refer}

to unique capabilities supported by a telephone system beyond the standard superset.

1-9 _{Plug and play — It should be noted that CT Plug & Play is different from Microsoft's Plug and Play.}

A device that supports CT Plug & Play will work with any other CT Plug & Play device. A device that supports Microsoft Plug and Play will work with a PC that is running the correct version of the Windows operating system and has the correct driver installed.

1-10 _{Telephony vendor software — The names of these pieces of telephony vendor software differ,}

depending on the platform. They include telephone drivers, telephony service providers, telephone tools, and mappers.