Choosing Telephony Middleware

Telephony middleware? Isn’t that the API—the “driver” as it is sometimes called—that comes with a voice board”? Well, perhaps. But the term “middleware” is borrowed from enterprise client-server computing. It denotes the “connectivity software that consists of a set of enabling services and their APIs that allow multiple processes running on one or more machines to interact across a network”. So the term is more appropriately used for the third-generation of CT environments exemplified by Commetrex’s Open Telecommunications Framework® (OTF) and Dialogic’s CT Media.

But if middleware is the software that comes with a voice board, once the board vendor is chosen what’s left to choose? Just a few years ago the answer was ‘nothing’ since the two were bundled by the board vendor. But open communications has a layered value-adding structure. It’s similar to the PC industry but it’s less efficient, offering participants fewer opportunities to specialize. Throughout the ‘80s and ‘90s there have been three significant value-adding layers: an open computing platform, be it PCI, CompactPCI, or VME; the media-processing and switching resources (boards) bundled with their APIs (and drivers), and the application layer. But that’s changing, and the change is making the open-communications industry more open and efficient.

In the last half of the ‘90s new open interfaces have been published that support further specialization. The ECTF has published S.100, an open client-server system framework and API that promotes application integration and portability. (That’s middleware.) To take matters even further, the MSP Consortium has published M.100, an open-specification for a multi-vendor media-processing software environment. It promotes the portability and integration of media technologies from multiple vendors onto one media-processing resource. The PCI Industrial Computer Manufacturers Group has published specifications that will bring the development efficiencies of the open-communications industry to carrier-class equipment. What this means is that in the coming decade vendors can enter the market without spreading their resources thin, focusing on just piece, such as

An application
PC-based middleware
Boards and their environments
Network interfaces
Media-processing firmware
System-level hardware

This list has expanded by 50% over what it was just a few years ago. But why is that specialization good, and what’s wrong with the way it was done in the early 90s? The answer is that as the technology shaping the industry changes, so must computer telephony.

In the days of first-generation open communications life was simple. We had DOS systems with four-port voice boards that supported voice processing. (The second generation began with MVIP.) But today we have affordable 550-MHz processors and high-function multi-threaded operating systems. Industry-standard PCM highways, such as H.100 interconnect DSP-resource boards with several DSPs, each capable of supporting 60 voice ports. The only effective way to apply such power is to integrate media and applications onto one high-function, high-capacity platform. And today, with CompactPCI supporting open communications’ move into the carrier-equipment market, that platform must be easily scalable to support thousands of ports. So far, the only practicable way to do that is with client-server architectures.

Since media and application competencies are generally limited within one company, value-adding interfaces are required to allow the integration of multi-vendor products onto one platform, just as in the PC industry. What this means is the system integrator can take media-processing hardware resources from one vendor, fax from another, and high-speed data modems from another to create an integrated-media resource on just one board. And instead of one vendor having to develop each application for an integrated-applications communications server, S.100-conforming applications can be selected from companies that specialize in their respective area, such as voice, fax, or data, and integrated onto one common platform.

Matching Solutions To Needs

But there are applications that do not need telephony middleware. The developer of a low-density voice system has many choices of a simple cost-effective platform if multiple media and scalability are not a concern. But let’s look at the developer of a new system resource, such as a CompactPCI-based media-processing resource or a PCI-based conference bridge. Regardless of whether the developer wants to offer these products as system building blocks on the open market or to use them as components in an integrated system, a system environment will be required. That is the reason few companies can justify the investment required for such products. It is not the cost of the hardware, or even the DSP software, it’s the investment required in the total system software environment. So if the product is brought to market the environment that is developed to support it is usually low in function to keep development costs reasonable.

Third-Generation Value-Adding Layers

If you are developing a specific system you have some very definite requirements. If you anticipate very large volumes of that one system you might be able to narrow your middleware selection to focus on just those requirements. On the other hand, you may have a wide range of requirements. In the former case you need a platform for today’s specific application; in the latter case you need a strategic platform that will take you well into the future.

Strategic Control

Before the introduction of the 4-port voice board in 1984 there was no make-buy decision for a strategic platform. But the investment that went with “rolling your own” in the ‘80s was not as great as today since voice, the only media processing required, was also the simplest to implement. Today, with the requirement for media diversity in strategic platforms, doing it all in house can rarely be justified. However, outsourcing the platform means ceding significant control of your product’s architecture to the third-party vendor. And the fewer value-adding layers within that platform the more control you give up.

If there is a value-adding interface between the media-processing resource hardware and software (usually DSP software), the developer/OEM can select from a variety of vendors. Indeed, with an MSP Consortium M.100-conforming environment on the hardware resource, the various media technologies from different vendors can be easily integrated. Furthermore, if there is an interface between the telephony middleware and the media resources then the choice of middleware can be made independently of the other system components. And if the middleware supports multi-vendor application integration, as does S.100, applications can be chosen from multiple vendors. This opens the possibility of the developer of a PBX application, for example, integrating it with fax-server and voice-messaging applications from different vendors, dramatically lowering the cost of developing the integrated communications server.

Extensibility

Today, the vast majority of systems fit within the resource boundaries of one PC. But many of those are limited to one PC because to run out of MIPS or slots means a major investment in development must be made to expand to a multi-PC system, unless a client-server middleware system is being employed. With second-generation architectures media resources must be in the same PC as the controlling application. And if PCM highways are used to transfer a call stream between media resources instead of packet switching/routing, a significant investment in inter-chassis PCM highway interconnection must be made. This means large multi-PC systems based on second-generation architectures are disproportionately expensive.

The solution to this problem is to move to third-generation architectures and embrace packet-based transport over PCI for intra-chassis stream switching, and Ethernet infrastructure for inter-chassis transport. Yes, the benefits of packet-based telephony in the wide area apply just as well to scaling computer-telephony systems. And with client-server architectures, the media-processing resource does not have to be co-located with its controlling application. One application can utilize resources in multiple computers without the application being located on the additional computers.

Resource Independence

With value-adding separation between media resources and the host-based software, the system developer has the option–only available with third-generation architectures–of choosing resources from multiple vendors, all of which interoperate with common host-system software. CT Media from Dialogic exposes CT Media resource-specific interfaces between the server and the resource-provider entity. This allows a resource vendor to substitute its media resource for the Dialogic resource provided the third-party resource conforms to the exposed interface. Commetrex’s OTF exposes a transport interface, rather than a resource-specific interface, allowing third-party media resources to be added to the system as long as the vendor provides both the resource and the client API.

So the question is this: If your vendor does not supply a media-processing resource you need now or may need for some future requirement how do you add it to your system? Questions to be answered by your prospective vendor are

Can the media-processing software be purchased or developed in house and easily integrated into the middleware environment?
Can that media-processing software be easily ported to the same hardware resource you are using for other media and still be supported by the environment?

Application Integration

One of the promises of S.100 is multi-vendor application integration. Because S.100 is relatively new, systems with cooperative multi-vendor application integration are rare. Consider the current attempts by a dozen or so start-ups to develop integrated-application communications servers. They are developing all the applications themselves. Is it because they believe they can do better than the vendors specializing in each application, or is it because of the lack of multi-vendor integration at the application level? Just as specialization in multiple media-processing technologies is rare, so too is it rare in the application space. But few organizations are really good in multiple applications, so an environment that supports multi-vendor application integration is required. It means the system integrator can choose one application from vendor A and a complementary application from vendor B, finally bringing value-adding market efficiencies to the integrated communications server.

The Decade Ahead

In the next decade, client-server telephony middleware will give the application and system-resource developer new options that will enable new markets to be entered. The open-communications market is subsuming adjacent markets because of its development efficiencies. Moreover, the advent of next-generation architectures always accelerates the pace of innovation. So expect to see this industry move vigorously into carrier-class network equipment including high-capacity gateways and integrated-access equipment. Expect to see affordable support for high-speed data and video conferencing. Service platforms of all types will be almost exclusively built on open-system components.

For the OEM interested in