Why Do VCs Throw Money Away?

No, we’re not talking about venture capitalists bidding against each other to fund the dot-com without a sensible business plan. This is about the VC that funds the digital-media telephony- equipment maker. They don’t mean to throw money away; they’re just unaware that much of their investment will reinvent the proverbial wheel. Just a few years ago they had no choice. But not any more. New solutions are available, and not just for early stage companies. Legacy vendors also have the same opportunity to save on new-product development while they dramatically shorten time to market and still maintain control of their strategic product platform.

Here’s the case: multi-service access equipment, gateways, media servers, and enterprise communications servers are examples of digital-media systems. All share seven major architectural elements: the application software that defines the system’s basic function, network interfaces and call signaling, processing resources, such as CPUs and DSPs, a box to put it all in, a system-level software framework, media-processing software, and a software framework to manage those media technologies. To the extent that any of these system elements that meet the system’s requirements are on the shelf and can be acquired for less than the cost to develop them in house, and they are redeveloped anyway, money is being wasted. There may be other factors involved, such as control of the developer’s product, but such concerns can be assuaged through modularity and source code. Some readers may look at the above list of architectural elements and remark that they aren’t available except bundled with hardware that may not meet the OEM’s requirements. And a year ago this was correct.

Generally, the OEM will develop the application since it sets the system’s functionality. Off-the- shelf chassis, power supplies, and system-level boards may or may not meet the OEM’s requirements, but many choices are available, including the new Advanced Telecommunications Computing Architecture (ATCA) from PICMG, which holds the promise of knocking several million dollars out of project budgets. Media technologies have been available for licensing for several years. Without that product category, integrated-media telephony systems wouldn’t be economically feasible. Due to the technical complexity of today’s integrated-media systems, not even the largest companies are trying to do it all.

So that leaves the software frameworks.

All digital-media systems have some kind of system-level software framework, often called middleware, from the simple and limited, to highly scalable client-server systems with broad functionality. But all telephony systems have some kind of framework to support application access to the media-processing technologies, which do the real work of a digital-media system. Except for the proprietary frameworks offered by a few media-technology licensors, there are no media-streams environments, and none are standards-based and vendor-neutral, except, as will be shown, Commetrex’ OpenMedia™. And, except for Commetrex’ Open Telecommunications Framework® Kernel, there are, quite simply, no system-framework products for the digital-media OEM. These two products define a new product category, so not everyone will be familiar with what they do. A system-level framework handles the system-level functions common to most high-capacity digital-media systems by providing system services to the application software through APIs. These services typically include a facility for system configuration, management, and maintenance. For client-server architectures you’ll usually find some kind of authentication service. For media servers, there will be a need for media storage, preferably OS non-specific. A system service that allows the application to manage call-stream connections is almost always needed. It could be PCM stream switching, packet switching/routing, or a combination. And finally, there are the media-processing resources, which are often isolated by resource service managers (RSMs).

An RSM can be designed so that it isolates the media resource from the balance of the system. The API offered to the application can be generic, allowing functionally conformant resources to be substituted without changing the application. However, this approach can lead to lowest- common-denominator resource functionality, which can be addressed by modifying the API to expose unique functionality.

A framework can be simplified by not supporting a client-server architecture, but only at the sacrifice of the extensibility and modularity inherent in the client-server architecture. Persistent media storage (e.g., “Container Manager”) can be OS specific and not include media-aware functions, moving that complexity to the application and sacrificing portability. That reduces framework complexity while increasing the complexity of every application. And permanently binding media-processing and interconnection resources to an application will require less framework complexity than a system that supports dynamic resource sharing among multiple applications.

A generalization of this architecture is shown below.

Notice that the resource service manager (RSM) isolates the media-processing resources from the balance of the system. The RSM exposes high-level functions, such as “SendFax”, to the application, by isolating the application from the low-level functions required to command modem data pumps and implement protocol engines, for example.

But those low-level functions must be processed by the call-stream-processing resources. In a multi-channel integrated-media system this means that call streams must be connected with the necessary transcoding software on a per-call basis. In a gateway, for example, a call on a particular PSTN interface may be voice, fax, data, or video. The system will need to classify the call and then connect the call’s media stream to the appropriate media-processing software for the necessary transcoding. From there, it must be interconnected with the packet-management and network interfacing software. For a media server, a call stream resource may be connected to an announcement on one call, connected into a conference resource on another, and a fax- receive resource on yet another. This is all managed by a “streams framework”, or environment, in response to commands from the application through the service layer.

A streams framework implements the system’s stream-processing resources. It’s where the digital-media “rubber meets the road”, to paraphrase the automobile tire ad. An effective streams framework reduces the development work necessary to implement a particular media-specific resource for the system. This is done through skill-set separation, which means the electrical engineers do the media-processing (DSP) algorithm implementation and an embedded-system developer can take care of the RSM implementation by translating high-level commands, such as play message, to lower-level functions, such as “StreamMount” and “StartGraph”. For productive development, the framework should define standardized interfaces between the system components. For example, components in the media stream will have an easy-to-use buffer- passing API.