BladeWare HMP Media Server

BladeWare™ is the SIP-based HMP media-server edition of Commetrex’ Open Telecommunications Framework® (OTF) architecture. OTF is Commetrex’ digital-media system framework that supports any media, any network, any signaling, and any media-processing-related application. And it’s completely open. This means there are SDKs to support development at any level, including, of course, the application level, but also system services, signaling, and media technologies. And, with Commetrex’ fax technologies, BladeWare knows no equal as a fax media server terminating both G.711 pass-through and T.38 fax sessions.

For the last few years, the MIPS available on low-cost PCs have been adequate to process over 100 media streams while still leaving ample processing power to host several applications. And, following Moore’s Law, PC capacity doubles every 18 months. But if a single PC is not sufficient, blade servers make scaling the number of open-architecture processors in a system as easy as adding a board to a chassis. And the densities are nearly the same. Although blade-server architecture makes adding processors a snap, the software framework required to harness those MIPS and provide seamless system scaling through the addition of processors has not been available to the media-server OEM and service provider. Commetrex’ BladeWare, featuring industry-best fax technologies and voice play-record, gives the telecom OEM and service provider a new level of affordability and value.

Commetrex has combined OTF Kernel telephony middleware with a SIP resource service manager (RSM), OpenMedia media-stream framework, and IP-media technologies in a configuration specifically designed to allow the telecom OEM to easily develop a media server without the need for DSP-resource boards. System expansion is accomplished by adding server blades rather than DSP-resource blades. And with IP-only telephony, there is no need for specialized network interface boards. But if PSTN support is required, BladeWare supports the entire Sangoma product line of PCI and PCI Express telephony-interface boards.

BladeWare is a value-adding platform with an easy-to-use C or C++ APIs for system, call, and media operations. Applications include enterprise fax servers and integrated communications servers, hosted communications servers, voice and fax messaging, and IVR.

BladeWare is also available with three ready-to-deploy applications for the service provider: BladeWare Fax Media Server (FMS) for use in IMS and similar service- network architectures, BladeWare Fax-to-Email, and BladeWare Email-to-Fax.

Features

Commetrex’ industry-leading TDM and IP-based fax send-receive
TerminatingT38, including V.3/V.34 support
Terminating G.711 pass-through with V.34
Smart FoIP
Voice play and record
SIP-based (RFC3261) call control
OpenMedia standards-based true host signal processing environment
Transparent client, server, and media resource expansion
Browser-based system administration
Hardware independence
Multi-application support through resource sharing
Dual-network capable (PSTN & IP)
Low-cost high-capacity processor blades
Vendor independence
System service extensible

Benefits

Address TDM, IP, fax, and voice on one system to lower costs
Broadcast fax transaction success rivaling TDM-based servers
Increased time in market
Reduced development investment
Respond quickly to shifting market demands
OEM maintains control of product platform
No sunk investment in hardware
Tailor system services
Highest interoperability

System Overview

A digital-media telephony system can be decomposed to expose different value-adding components. Certainly, there is the application-level software, which provides the top-level characteristic functionality of the system, whether it is a corporate fax server or a telco-grade service platform. The application must have a compute platform on which to run, and that platform must be supported by a chassis and power supplies. To do the work of processing digital-media, call streams must be brought into the system, and there must be hardware and software resources to process those call streams. This gives us the following components

Application software
Compute engine
System chassis, power, cooling, etc.
Call-stream media-processing
Framework software
Network interfaces

BladeWare gives the system developer everything but the application. But, unlike competitive products, BladeWare is completely open below the application-level API, allowing the licensee to add or modify system services, signaling, and media technologies.

With traditional circuit-switched or TDM telephony, the network interfaces are a major proprietary cost and physical component with no standard value-adding interfaces between the interface and the balance of the system. That changes with an all-IP infrastructure. The network interfaces move from being a significant proprietary component to off-the-shelf high-performance IP connectivity, an inherent feature in every modern computing system. And if PSTN connectivity is required, BladeWare’s MSP product line offers ultra-low-cost analog and digital interfaces.

Network connectivity through standard components influences the consideration of whether to use DSPs or server blades for media processing. Without telephony interface blades and their attendant chassis and power systems available to host the DSPs, the addition of DSPs on proprietary blades must be independently justified. They will continue to be justified for the highest-density applications. However, with the semiconductor industry continuing to follow Moore’s law, host signal processing will support 1500 channels on one blade within a few years. DSPs will offer even higher densities, but if 1500 channels meets the system requirement, higher densities will have little value.

Media-Stream Processing

Types of HMP Media Servers

Not everyone means the same thing when using the term “HMP media server.” There are at least three different types of HMP systems, performing varying degrees of actual signal processing, and we believe it’s important to know into which category BladeWare fits.

Modern digital-media telephony systems require signal processing to transform a call stream or extract information from it. Transformation includes the processing required to send or receive a fax and to transcode the stream from one speech codec to another for capability matching or bandwidth reduction. DTMF detection, caller ID, and in-band call-progress analysis are good examples of information extraction.

There are many limited-function media servers on the market that don’t actually do any media (signal) processing. There is an IETF RFC (2833) that defines how a gateway can perform the in-band-tone analysis to extract some of the embedded information, such as DTMF and caller ID. In this case, all the media server need do is parse the RTP buffers to derive the tone information.

But what about transcoding? The media server that simply processes buffers can’t do transcoding, so they are limited to low-function voice messaging. RTP packets are stored and played back as they are received. This means no AGC, volume control, time-scale modification (playback speedup and slowdown), or capabilities matching with endpoint terminals, making this (the “Host Buffer Processing” media server) a viable option only in the most functionally constrained applications.

Then there’s the board-emulator HMP media server. This approach is often taken by the CTI “board vendors” of the ‘90s that have a large investment and customer inertia in their software framework and media technologies. But their aging framework architectures do not readily support resource-location independence, making it difficult to move the media processing and stream-connectivity functions from an embedded resource to the host.

The time-to-market answer is often “board emulation”, which means the user is in something of a functional straightjacket, unable to take advantage of the flat processing resource offered by a powerful host processor. The board-emulator HMP media server does offer some cost and operational advantages over the equivalent hardware-based resources, but users often find their strategic options severely limited since they emulate older resources. Moreover, they are never open, prohibiting the OEM from adding third-party signaling, media, or system-service resources.

BladeWare’s OpenMedia stream-processing framework offers a normalized interface to the higher-level OTF Kernel that makes the location of the media-processing resources transparent to both the system and the application-level software. With BladeWare, applications are written without regard to the location of the media-processing resource, the network, or call control and the network interface. If a call needs to be placed or two call streams joined, there are functions available. The system takes care of the details.

Value-Adding Modularity

Every multi-channel digital-media telephony system represents dozens of developer-years of investment. Since it is clearly impracticable for every system to support such an investment, the industry has evolved a value-adding structure with different companies developing solutions to different parts of the problem. When a required piece of the puzzle was missing, the developer had to come up with a proprietary solution.

User-specific and lower-volume applications have relied more completely on value-adding platforms, while high-volume highly capitalized developments have favored more proprietary architectures, even including application-specific integrated circuits. But today’s technical complexities, market uncertainties, and the necessity of greater capital efficiency are moving the industry towards greater dependence on value-adding architectures. Using the model of the PC industry for guidance, this new industry architecture, which Commetrex is helping define, is partitioned into more modular components. This modularity gives the system designer more options through vendor independence.

Commetrex’ OTF architecture defines three modular system-software components: a multi-channel integrated-media stream-processing framework, the telephony middleware, and the media-processing technologies and resources.

Streams Framework

Every telephony system that requires call-stream signal processing has a software framework responsible for binding a media-processing resource (hardware and software) to a call stream.

M.100 external Interfaces If the system supports multiple calls and multiple media, the necessary software framework can represent a significant portion of total system complexity and development cost. Although complexity can be reduced by making this binding static, this is a poor tradeoff when the resulting reduction in resource utilization and system scalability are considered. This means a software framework is required that dynamically binds a call-stream processing resource to a stream source and a stream sink under the control of the application-level software. Commetrex models this with a stream graph, as shown below.

Stream Processing The stream graph is built under the direction of a media-specific service entity that acts at the behest of a client application, as depicted in the previous diagram. The media controller will accept commands, build the stream graph, start the graph, send events to the client, and tear down the stream graph when the call is complete, freeing the resources.

Such an environment can be just as suitable to execution on a host computer as on a DSP or distributed across multiple processors.

Partitioning a digital-media system to expose the media-streams software environment is necessary for it to become the subject of specification. Over the last several years, the MSP Consortium, Inc. has developed and published such a specification, M.100 Media Stream Processing Environment (MSP). M.100 specifies a streams environment by specifying the APIs that entities within the environment use to perform stream-processing tasks. As long as software within the environment uses these APIs, the server developer can choose technologies provided by multiple vendors.

OpenMedia is Commetrex’ implementation of the MSP Consortium M.100 streams environment, and provides the host signal-processing environment in BladeWare.

Telephony Middleware

However, an open multi-vendor streams environment that executes on multiple server blades is the business end of the total digital-media system. Client-server telephony-middleware is necessary to provide system management and services. Commetrex’ middleware is OTF Kernel, which offers the system developer:

Control of strategic platform
Resource independence
Seamless scalability
Configurability/Extensibility
Application portability

OTF Kernel

Other than OTF Kernel, all telephony middleware products are closed-architectures bundled with the vendor’s media resources, requiring that the OEM cede control of the system platform. BladeWare’s open architecture puts the system developer back in control of the end product.

Resource independence is achieved by abstracting the media-processing resource behind a resource service manager combined with an open environment at the client API.

Seamless scalability is achieved through a distributed client-server architecture that moves command routing, resource configuration and allocation, container management, connection management, and system management to system-service entities, as shown above. Connection Management includes support for call termination as well as pre-paid and PBX connectivity. Services are invoked by name rather than by location or address.

System expansion, then, is achieved by adding a processor and configuring it through the system-management facility. Of course, clients and servers are software abstractions, making their assignment to a particular processor a function of system-availability and management considerations.

SIP Resource Service Manager

BladeWare’s SIP Resource Service Manager (RSM) has been extensively tested with a wide range of gateways and application servers and many different call scenarios. The RSM includes support for SIP Digest Authentication. And, BladeWare’s SIP RSM’s five-years of field experience in supporting FoIP means network-integration problems are minimized, especially with Smart FoIP.

Reliably transporting a fax that originates in a ‘traditional’ fax terminal over a packet network to a receiving terminal in real-time requires that a fax-relay be situated between each terminal and the packet network. These entities—the relays—must render the delays and timing uncertainties of packet networks transparent to the T.30 protocol engines operating on the transmitting and receiving legacy terminals.

Smart FoIP, Commetrex’ patent-applied-for technology, is optionally available with T.38 fax relay for use in SIP networks. Smart FoIP eliminates the problems caused by late-arriving T.38 re-INVITES from the receiving gateway that can cause the call to fail if incorrectly accepted by the calling gateway.

Commetrex has found that significant practical problems with SIP negotiations exist in carrier-based SIP networks. After much testing and analysis, we have developed what we call “Smart FoIP”, which improves the reliability of fax-session establishment for ATAs and access gateways. The technology increases the likelihood of a session remaining in G.711 fax pass-through mode, so it also includes a new technology that eliminates PCM-clock synchronization problems.

PSTN Interfaces

BladeWare supports the Sangoma A2xx and A10x PCI and PCI Express PSTN/TDM interface boards, giving the OEM the flexibility of supporting PSTN and SIP applications on the same systems.

System Administration

As shown in the diagram above, system administration is a separate entity in the distributed BladeWare system. The admin facility manages the system via “admin agents” in each system entity. The admin SDK exposes an API that the developer can use to implement proprietary administration features. The user has access through a browser-based control console.

Product Structure

As BladeWare is highly configurable by the OEM. Stream-processing technologies, such as Commetrex’ exclusive TerminatingT38 and PowerVox packet-voice technologies, can operate in the OpenMedia streams framework, which is available in SDK form, allowing the licensee to add proprietary or third-party media technologies.

Commetrex also offers three ready-to-deploy fax-server applications in SDKs that include the application’s source code. The licensee can either use the application as is, modify it to suit a specific requirement, or engage Commetrex to make the modification.

BladeWare Fax Media Server uses MSCML to interface with an application server that implements the overall system function and uses BladeWare FMS as the fax send-receive resource. SIP-based calls are redirected to the BladeWare system once the application server determines that the call requires fax services. Unified messaging, fax broadcast, and document management are typical applications.

BladeWare Fax-to-Email and BladeWare Email-to-Fax are stand-alone ready-to-deploy applications for the service provider.

FoIP Interoperability

Commetrex has led the industry effort for T.38 interoperability since January 2002, when it launched the T.38 Interoperability Test Lab. Recently, Commetrex has done extensive interoperability testing with the BladeWare HMP telephony platform, with international carriers, service providers, and enterprises.