Third Quarter 2008

     There’s been plenty of buzz on the Internet of late regarding the suitability PC-based open-source PBXs that use host MIPS for media processing (HMP) for use in so-called carrier-class applications. The blogs and discussion forums have been comparing these PC-based software-only telephony platforms, such as Asterisk, to what is frequently referred to as “real” carrier-grade—read commercial—hardware-based products.

      Not many of these commentators bother to address what is actually meant by “carrier grade”. Perhaps it’s like pornography: I can’t define it, but show me an example and I’ll tell you whether on not it is. But those that do bother to discuss the term often come down to considering “scale”. Can the system scale? If it can scale to thousands of ports, it’s carrier-class; if it can do so without falling over, it’s carrier-grade. I know…I know…there’s a lot more to it, but that’s beside the point because what I really want to talk about is HMP system architectures that support scaling to carrier-class dimensions.

     When these discussions get cranked up, the comparison is inevitably between what can be done on one PC versus what can be done on a DSP-based system that scales by adding DSP blades. But is the discussion being properly framed? Should the comparisons be between a PC and non-PC-based systems, or should the comparisons be made between architectures and their scalability, regardless of the underlying hardware? And what about software-only systems whose architecture supports a hardware-software architecture, or even a fully embedded version as well as HMP? It turns out that the PC versus non-PC debate is actually a proxy for the real issue of scalable architectures.

     But, in all fairness, it’s difficult to compare system architectures since there is little publicly available information that really exposes the architecture of these systems in a useful way. The vendors of commercial (real) products don’t normally publish their product’s architecture for competitive reasons. And open-source is notorious for its lack of documentation. For example, I’ve been unable to find a usable diagram of the Asterisk architecture on the Web. It may be there, I just can’t find it. There’s one in the Asterisk Handbook, by Mark Spencer, but it is not detailed enough to support an analysis.

     Since the voice media server isn’t going to do it. So the discussion usually centers on how well a system scales in practice, not why. We have the same problem when comparing Commetrex’ BladeWare telephony platform to that of other HMP and hardware-based systems. Other than BladeWare and Commetrex’ Open Telecommunications Framework®, on which it is based, I can’t find another system, open-source or otherwise, HMP or otherwise, with an open distributed client-server architecture, which happens to be the foundation of BladeWare’s scalability.

     So the discussion usually centers on how well a system scales in practice, not why. We have the same problem when comparing Commetrex’ BladeWare telephony platform to that of other HMP and hardware-based systems. Other than BladeWare and Commetrex’ Open Telecommunications Framework®, on which it is based, I can’t find another system, open-source or otherwise, HMP or otherwise, with an open distributed client-server architecture, which happens to be the foundation of BladeWare’s scalability.

     Even if you limit a processor blade running OpenMedia, BladeWares’ media-processing environment, to say 200 simultaneous T.38 fax transactions or G.711 voice calls, a 10-blade chassis will yield 2,000 channels. Is that carrier-class? No? How about multiple 7 U chassis in a 7-foot relay cabinet? Five of them get you 10,000 ports. Are we there yet? Yes, there are issues of footprint and power that would need to be compared, but the discussion here is whether the architecture supports carrier-class capacities, and it does, even though it’s a PC-based HMP system.

     OTF Kernel is Commetrex’ vendor- and hardware-independent telephony-middleware system kernel that provides the core telephony system services for a high-capacity digital-media system in a Linux or Windows NT environment. It’s used by developers of access equipment, gateways, service platforms, switching systems, and enterprise equipment that require strategic control of their product platform, yet see that time-to-market, investment hurdles, and on-going maintenance preclude internal development.

     OTF Kernel can be extended by the OEM to support multi-vendor system services, media resources, and client APIs. This means that the equipment developer can gain the time-to-market advantages of a closed-architecture integrated platform, such as those available from several vendors, yet maintain control of his strategic product platform as if it were developed in house. With OTF, the system developer can assume full control of his strategic platform in every dimension.

     Commetrex’ key requirements for OTF, a service platform for any system required to process telephony media streams, were

• Scalability,
• Feature extensibility,
• Vendor independence,
• Resource independence,
• Resource efficiency,
• Availability,
• Portability, and a

     The requirement for scalability led to the selection of a distributed client-server architecture. The result is that OTF can be scaled by adding industry-standard processors (PCs) to provide more compute resources in any dimension: client applications, system services, signaling, and media-processing resources. We call the HMP version of OTF “BladeWare” since it can leverage the architecture of blade servers to scale. With OTF, server blades are added just as DSP blades are added in DSP-based systems. In fact, OTF also allows the processors to be DSP based. It just does not matter.

     Regression problems are eliminated since adding a new service does not touch the balance of the system. This is facilitated by OTF’s use of a standard entity shell, called the Application Interface Adapter (AIA). The AIA ensures that the developer’s OTF entity meets all requirements for inclusion in an OTF system domain, whether it’s host-based or embedded.

     Vendor independence means that nothing in the system is tied to a proprietary Commetrex product, including media-processing resources. In fact, Commetrex developed a related software environment, OpenMedia, that hosts independent media-processing technologies, just as effectively and efficiently as it hosts Commetrex’ media-processing products. OEM customers have used OTF with more than Commetrex DSP and TDM-interface boards. Dialogic (Brooktrout and Dialogic) boards are being used today in OTF-based systems.

     Resource efficiency is a benefit of OTF’s shared-resource management facility, which supports multi-vendor applications with resource sharing on a common system platform. OTF abstracts signaling, switching, conferencing, and media resources through software objects that model those resources and are managed by the system. The resource manager’s API allows client applications and system services to assemble the required resources on a per-call basis and relinquish them upon call completion, making them available to other applications. Other applications, even from other vendors, can then use the same resource. Moreover, this architecture naturally supports hot-swap for high availability since resources are dynamically allocated.

     OTF allows the OEM to bypass the several-dozen developer-years of effort required to produce a viable system foundation, which, prior to OTF Kernel and OpenMedia, has been required if the developer intended to maintain control of his strategic platform. And all of Commetrex’ extensive library of media technologies are available for use in OTF systems.

Thanks for listening, Mike Coffee CEO, Commetrex