This article has been updated since its original publication in November '97. To view the original article on the CTI Magazine website, Click here.
The MSP Consortium
November, 1997
BICOM, Calibre Industries, Centigram Communications, Cole Technical Services, CCS Trexcom, Commetrex, ECI, MiBridge, Pika Technologies, and QNX Software Systems are members of the MSP Consortium. The Consortium has developed a software specification which the members believe will help move the computer-telephony industry towards shrink-wrap media-processing software. The Consortium members believe the computer-telephony industry can benefit from a value-adding interface between system-resource hardware and media-processing software, just as the PC industry benefited from open architectures which have allowed different companies to develop a computer system’s hardware and software subsystems. Today, in computer telephony, the same company that develops the media-processing software also develops the underlying hardware.
New Architectures Create New Businesses
Every vendor in the industry works continuously to improve its product. But generally these improvements do not result in changes in the business definitions of their competitors. It takes a fundamentally new product which creates a new competitive space to do so. Prior to Dialogic’s first voice board other companies had developed multiline voice-processing hardware. But, by offering this system resource with its software interface to other companies, Dialogic created the value-adding computer telephony industry. Suddenly, hundreds of companies appeared to take advantage of the opportunity Dialogic’s innovation offered. When Natural MicroSystems and Rhetorex released DSP-based multiline voice boards in 1988 the technology was improved, but there was no change to the industry’s structure. That did occur again with the 1990 announcement of MVIP by NMS and 6 other companies (many of them competitors). MVIP fundamentally altered the industry’s structure by creating a new value-adding interface which dramatically improved the industry’s value-creation efficiency.
The common factor of these critical milestones in the history of computer telephony are architectural innovations that improved the efficiency of the industry’s value-adding chain. The ambitious goal of the MSP Consortium is to bring about such an improvement in the efficiency of the CT industry by developing the Media Stream Processor M.100 SpecificationTM a software specification which supports the separation of media-processing software (firmware) from the underlying hardware resources, creating new competitive arenas through the definition of a much needed value-adding interface.
Computer Telephony and the PC Industry: Value-Adding Partners
The advantages of layers of value-addition in the computer telephony industry are the same as those in the computer industry; it’s one of the chief reasons CT has grown to its near-$12-billion size in just 15 years. With standardized interfaces between adjacent layers of value addition, companies can choose to compete at a particular value-adding level, as is done to a greater extent in the computer industry. You can produce PCs without having to develop network adapters. You can develop video controllers without having to develop operating systems. And when an OEM purchases these components to create an application-specific system, there’s a good chance they will all work together. What’s more, competition within a value-adding layer fosters rapid improvements in price, performance, and function. As a result, the market expands, producing returns to the participants which exceed those gained with closed-architecture strategies.
Phase I¾ The Voice Board
In the history of value-adding computer telephony, there
have been two main architectural innovations that rewrote the rules of
the market; call them architectural phases. Phase I began in 1984 when
Dialogic created the industry with the introduction of the first
multiline "voice board". Prior to that the entire telecommunications
industry was vertically integrated and relatively inefficient.
Dialogic's innovation released a flood of entrepreneurism which produced
a multi-billion-dollar industry in less than a decade. Before
Dialogic’s voice board, a voice mail product, for example, could only be
brought to market if a company was willing to invest the development
resources necessary to produce the entire vertically integrated system.
But with Dialogic’s voice board, OEMs could add application value
starting where Dialogic left off, as shown in the Phase I diagram above.
But until CT’s second architectural phase (Phase II) the industry was
essentially limited to one medium: voice.
Phase II ¾ The PCM Highway
Phase II changed that when, in 1990,
Natural MicroSystems and its partners introduced Multi-Vendor
Integration ProtocolTM (MVIP). As the name implies, MVIP allows an
OEM to integrate system-level hardware resources (boards), that are
independently developed and marketed, into a system that is more
functionally integrated than was previously feasible. OEMs could then
produce systems which supported fax, text-to-speech, and speech
recognition ¾ as well as voice ¾ even though different companies produced
those media-processing system-resource boards. With MVIP the OEM’s
value-adding interface is the same as it was previously, but it became
possible to develop a system which supported more than one medium, and
switch the PCM stream between the dedicated-function resource boards
(see Phase II diagram). Moreover, MVIP increased the variety of network
interfaces available to the OEM. MVIP allowed companies with
competencies in ISDN interfacing, for example, to offer the CT OEM an
MVIP-compatible ISDN network interface. This one-function-per-board
architecture of MVIP systems is an effective way to marshal industry
resources as long as integrated circuits, and DSPs in particular, do not
significantly improve in performance.
But wait!. They are. Today’s DSPs have the power to support either a single medium, such as voice, in densities well over a 100 ports, or high-density multiple media. This brings into question the single-function-per-board Phase II architecture since the increased processing power makes it uneconomical to limit hardware resources to one function. But developers of media-processing technology are faced with a very significant barrier to developing the products which will translate these advances in silicon into the benefit of the industry’s end users: there is no value-adding interface which allows them to develop media-processing software product independently of the industry’s hardware vendors who are busy developing closed-architecture media-specific products.
Phase III ¾ Media Integration
Media-processing and hardware vendors must work together to produce integrated-media system resources because the vendors of "voice boards", still the industry’s mainstay, do not have the core competencies to develop fax, text-to-speech, speech recognition, high-speed data, and video media-processing software. Clearly, OEMs need system architectures which allow them to flexibly bind a media stream to a media-processing resource. So, without an interface specification, media-processing and hardware partners are wasting millions of dollars a year porting different technologies to the board vendor’s closed-architecture DSP-resource boards. From the OEM and end-user's perspective this is value-shuffling, not value-creation. The same development resources, invested in improving the technology rather than in moving it between proprietary boards, delivers more value to the end-user for a given industry investment.
The purpose of the M.100 specification, then, is to offer independent vendors a means of avoiding this constant porting effort by finally providing the industry with a truly open, resource-rich architecture appropriate for all media. M.100 will be an open, published architecture, intended to be the enabling specification for any vendor to develop and market M.100-compliant hardware and/or media-processing software products.
Today, "voice-board" vendors are taking
advantage of the rapid advances in DSP power by developing products
which support 64 and 128 "voice" streams. Although there are
applications which can take advantage of such density, there are many
more that could take better advantage of a system which used those same
DSP MIPS to apply any required processing (fax, data, voice, TTS, ASR,
video) to the media stream.
The voice-board
vendors are not closed to the idea of leveraging these MIPS to supply
additional media. Dialogic has announced DM-3, a closed-architecture
system which will support cooperative efforts between Dialogic and
third-party media-processing developers; Brooktrout has announced its
BOSTON architecture which supports closed-architecture integrated media.
But these architectures still don’t match the powerful paradigm of
the PC industry. The M.100 specification makes it possible to do exactly
that. M.100 fully supports multi-vendor media-diversity by managing the
resource demands of media-processing software (as shown in the Phase III
diagram), just as the latest client-server software systems from NMS and
Dialogic manage system resources from the host level.
Widespread adoption of the M.100 specification would result in computer telephony entering its third architectural phase, with a value-adding structure shown in the diagram above. M.100 will define the software environment inside the heavy border, plus other commonly needed media-processing services.
The M.100 Specification: Increased Industry Efficiency
The goal of the MSP Consortium is to make it economical to leverage the power of today’s DSPs to put all of a system’s necessary media processing on one hardware resource, taking advantage of the incredible power of today’s DSPs. Just as we don't use one PC for spreadsheets, one for text editing, and another for software development, we would no longer need one board for voice, another for fax, and yet another for speech recognition. The specification will make media-processing consolidation easier to accomplish. It will provide a defined environment for the software facilities needed to allow independent vendors' media-processing products to operate cooperatively on the same hardware resource. With M.100, instead of integrating fixed-function "boards" with an industry-standard PCM highway, such as MVIP, the OEM can integrate fax, voice, data, text-to-speech, speech recognition, and video media-processing products on a single, powerful, multi-vendor DSP-resource.
The M.100 specification could fundamentally change the structure of the value-adding computer telephony market: Today, the development of media-processing products usually involves developing not only the media-processing software, but the hardware platform as well. But M.100 creates an additional vendor-independent value-adding segment by separating the media-processing software (firmware) from the DSP-resource hardware. With a standard definition of the media-processing system-resource platform, companies can choose to develop just M.100-compliant hardware resources; others can develop M.100-compliant media-processing products. Yet others may choose to integrate M.100 into different host-level software environments.
The big winners will be the industry's OEMs and end users. And if the end user wins, everyone wins. The ultimate mission of the MSP Consortium is to create the age of off-the-shelf, plug-and-play, shrink-wrapped media-processing software.
Where does the M.100 Spec Fit?
The ECTF has become the computer telephony industry’s du jour standards body, but it has not defined a standard at the value-adding layer of M.100. The ECTF model supports a client-server architecture through its incorporation of client APIs (defined by S.100), a protocol for communicating with server entities (S.200), a Service Provider Interface (SPI¾ S.300), and a PCM highway (H.100).
Were M.100 to be placed into the ECTF context, it would exist below the S.300 SPI. M.100 defines the software environment for media-processing resources which do the boiler-room work of computer telephony. The M.100 specification does not specify protocols for communicating with a host entity; it does not specify a hardware architecture, PCM highway, DSP, or embedded OS. But it does define an environment for multiline media-processing software.
So What Does It Specify?
The keystone of M.100 is its Resource Manager and Task Processor Manager. These entities manage the widely varying resource requirements of different media. A voice-compression task may require fewer than 5 MIPS, while a V.17 (14.4K BPS) fax modem may require 13 MIPS. If each media-processing system resource is to be independently supplied by different vendors, there must be a board-level resource manager which processes requests for MIPS, RAM, and PCM streams. Of particular importance is the allocation of what the specification calls Task Processor (DSP) MIPS. The TP Resource Manager is responsible for managing the board’s DSPs as dispatchable processor objects.
The M.100 specification also defines how to "package" a DSP "processor object" so that the stream-processing task can be dispatched in a DSP-independent manner. To build an M.100-compliant media-processing software product, a developer presents DSP-specific media-processing software to a utility which takes the code and puts it into a task-processor object module which can be handled by the TP Manager. DSP-specific packaging utilities will be developed by any interested vendor and made available to all vendors via the MSP Consortium Web site (MSP.ORG). This means that, theoretically, an M.100-compliant media-processing product will execute on an M.100 platform provided it is "packaged" for the DSP used by the platform.
The Consortium is currently working on API definitions for stream management, resource management, task processor management, CT services, and communications services. So an M.100-compliant board-level system architecture would appear as shown below.

The consortium founders are soliciting the assistance of any interested company. Please visit the MSP Consortium Web site at http://www.msp.org and contact Mike Coffee, the designated MSP Evangelist, at mcoffee@commetrex.com or 770-449-7775x310.
Commetrex’s M.100-compliant platform, the MSP-320
(A sidebar)
Commetrex has ported its MultiFax media-processing software to numerous hardware platforms, including Natural MicroSystems’s VBX and AG boards, BICOM’s LS-E, and CCS’s FirstLine, in addition to traditional office fax products. But when the Company started to do the same thing with high-speed data modems as it did with fax ¾ make it a software-defined computer telephony system resource ¾ it didn’t find the open-architecture hardware resources on the market needed to do so. Moreover, Commetrex had become convinced that to be competitive at the system-resource level of the CT market, it had to offer a platform to OEMs which would support all media-processing needs¾ but on one board.
What to do?
One approach would be to develop all the necessary media-processing technologies and offer them on a closed-architecture board ¾ the current paradigm. But this is hopelessly impracticable for an early stage company. Another approach would be to convince other vendors to port their technologies to the Commetrex platform. Also, not practicable for an early stage company. The answer stood out starkly: work with other like-minded companies to produce an open environment which could attract other vendors to develop competitive boards and compatible media-processing software. From this notion evolved the MSP Consortium. Meanwhile, Commetrex is developing the MSP-320 to host its in-development, high-speed data modems, MultiFax, and what it anticipates will be other vendor’s speech recognition, text-to-speech, video, and so on.
The newest Texas Instruments DSP, the TMS320C6x, rated at 1.6 GOPS, was chosen as the task processor for the MSP-320. Two of these DSPs should support approximately 128 voice, 30 high-speed data, and 48 fax streams. An Intel 386EX with an 8-MByte RAM, running the QNX Neutrino embedded OS, hosts OpenMedia, Commetrex's implementation of the M.100 environment. An H.100 PCM highway fills out the picture.
Commetrex believes the choice of the QNX Neutrino
embedded OS for the MSP-320 is critical. Neutrino offers all the
features, such as IPC and task switching, required by such a
resource-rich system, plus full support for the protected-mode memory
management system of the 386EX processor. Likewise, one of the reasons
for choosing the 386EX was its memory management system. User-user and
user-kernel memory protection is important in multi-vendor systems.
Commetrex intends to market the MSP-320 as a media-neutral hardware resource, meaning no media-processing will be packaged with the hardware. The company will offer M.100-compliant versions of its own MultiFax, PowerFax, and PowerModem, media-processing products. But it will invite other companies to offer M.100-compliant products to any user of the MSP-320.