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. As a fax media server,
BladeWare knows no equal.
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 Open Telecommunications Framework Kernel and OpenMedia, finally gives the telecom OEM and service provider the needed solution..
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.
- SIP-based (RFC3261) call control
- OTF Kernel standards-based client-server middleware
- OpenMedia standards-based true host signal processing environment
- Transparent client, server, and media resource expansion
- Browser-based system admin
- Hardware independence
- Multi-vendor applications
- Multi-vendor media technologies
- Dual-network capable (PSTN & IP)
- Low-cost high-capacity processor blades
- Vendor independence
- System service extensible
- 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
- Limited-use paid-up source code
- Corporate paid-up source code
- Source with runtime license
- Paid-up object code
- Object Code with Runtime Licenses
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.
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 incremental value.
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 which makes the location of the media-processing resources transparent to both the system and the application-level software. With OTF or
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.
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.
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.
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.
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.
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.
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 few years, the MSP Consortium, Inc. (www.msp.org) 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.
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, and
- Application portability
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.
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 may be replaced in its entirety, or source code may be licensed to give the OEM or system developer absolute control over
BladeWare’s call control.
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.
As
BladeWare is a combination of several products, it is highly configurable. OTF Kernel provides the basic
system framework. It includes both IP and H.100 Transport Domain Controllers (TDCs), so it is equally suited to support IP, PSTN, or both. Commetrex offers a SIP Resource Service Manager (RSM). However, the licensee can easily substitute proprietary or third-party resource service managers.
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 two 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 or MOML to interface with an application server that implements the overall system function which 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.
The second application is
BladeWare Fax-to-Email, which implements inbound fax-to-email as a stand-alone application. Two versions are available. One determines subscriber information through a database lookup using the dialed-number information. SOAP is used to access a remote database. The second version used in conjunction with an ENUM-based proxy that supplies the subscriber’s email address during the SIP negotiation.
Commetrex offers general telephony, voice, fax, and data-modem technologies. As the media-technology product line is constantly updated, please check with your Commetrex sales representative regarding the availability of an algorithm you need.
Open Telecommunications Framework, PowerFax, and Commetrex are
registered trademarks of Commetrex Corp. All other
trademarks are the property of their respective holders. |
| 
