But low-cost, scalable MIPS are of no benefit unless system software is there to harness those MIPS to the task of processing call streams and make scaling the system in the client and server dimensions transparent to application software. This requires a new generation of telephony system software.
Every telephony system that requires call-stream processing has a software framework that is 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. 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. Some systems use the so-called stream graph, as shown above, to model the task.
The stream graph is built under the direction of a media-specific software entity that acts at the behest of a client application. The media controller will accept commands, build the stream graph, send events to the client, and tear down the stream graph when the call is complete, thereby freeing the call-specific resources.
Such an environment is 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 (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 the M.100-specified APIs, the server developer can choose technologies provided by multiple vendors. The evidence that quality will go up and prices will go down as a result of such a multi-vendor environment is too abundant to be ignored.
OpenMedia is Commetrex’ implementation of the MSP Consortium M.100 streams environment.
But having an open multi-vendor streams environment that executes on the multiple PCs (or other types of server blades) may be necessary but is not sufficient to make system expansion through the addition of server blades a viable system architecture. A client-server telephony- middleware software framework is required. Again, there is an open standard available. The Enterprise Computer Telephony Forum (ECTF) (www.ectf.org) has published S.100, a specification of a client-server telephony framework that supports implementations with the necessary features.
To date, most implementations of S.100 (there are four) have been vendor and resource specific, and they have not been integrated with a streams environment that supports host-based stream processing. Commetrex’ OTF® Kernel is an S.100-conforming telephony middleware software product that allows the system developer to implement blade-based servers which offer seamless expansion in both the client and server dimensions. OTF Kernel offers the system developer
- Control of strategic platform
- Resource independence
- Seamless scalability
- Application portability
Other than OTF Kernel, all telephony middleware products are closed-architecture products bundled with the vendor’s resource boards. As such, the system developer loses control of the system platform. An open, modular telephony middleware product puts the system developer back in control of the system platform.
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. Client applications are written without regard for the location of resources.
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 issues.