OTF® Kernel

Open Telecommunications Framework Kernel (OTF Kernel) is a modular, distributed, client-server, open implementation of the ECTF S.100 R2 recommendation (see http://www.ectf.org).  It is a vendor- and hardware-independent telephony-middlewaresystem kernel that provides the core S.100 system services in the Wind32, Linux, and Sun Solaris environments.  OTF Kernel is used by developers of access equipment, gateways, service platforms, and enterprise equipment when complete control of the product platform is required yet time-to-market and investment hurdles preclude internal development.

OTF Kernel can be extended by the OEM to support multi-vendor system services, media resources, and client APIs.  Client APIs can be either S.100 compliant or proprietary.  This means that with OTF Kernel the equipment developer can gain the time-to-market advantages of the integrated value-adding platform, yet maintain control of his strategic product platform as if it were all developed in house.  With OTF, the system developer can assume full control of his strategic platform in every dimension.

The objective of the ECTF S.100 and its associated recommendations is to specify APIs and an architectural framework that support application portability.  S.100 also specifies a shared-resource management facility, the Group Manager, that holds the promise of multi- vendor applications with resource sharing on a common system platform.  An additional objective of the ECTF is to provide resource independence by specifying software interfaces between system media-processing and switching resources and the “server”.  OTF Kernel provides these benefits and gives the OEM the option of easily integrating first- and third-party proprietary system services and media-processing resources.

OTF Kernel is becoming the preferred middleware foundation for the developers of service platforms and media servers. It allows the OEM to bypass the dozens of man-months of development effort required to produce a viable middleware system foundation.

OTF Kernel includes all system services, including the System Call Router, specified in S.100 R2. As it is intended for the OEM, it excludes all media-specific elements. (They are available with Commetrex’ MSP Media Gateway products.)

Features

• Flat distributed architecture
• Transparent expansion in client and server dimensions
• Group Manager
• Connection Manager
• Transport Domain Controllers (Packet and TDM)
• Session/Event Manager
• Container Manager
• System Call Router
• OTF Administration Facility
• “Open Everywhere” SDKs
• Vendor independent
• Hardware independent
• Windows NT
• Source-code licenses

Benefits

• Avoid captive technologies (no vendor lock-in)
• Quick to market
• Control of product strategy
• Lower development cost
• Highest system quality by choosing “best-of-breed” system resources
• Low-cost development of complex switching systems

The Telephony Middleware Challenge
Where does the telephony system developer get the middleware, or the software framework, for system development?  The answer, of course, is either make or buy.  The developer that chooses to develop a system is buying into not just an unending development effort, but perhaps an insurmountable task of developing proprietary media-processing system resources.  In the simpler times of single-media single-PC systems this was feasible.  But with today’s reality of extensible client-server integrated-media systems, the investment in capital and time-to-market makes this an unjustifiable investment.

But does purchasing the system framework mean the OEM must relinquish control of his product strategy?  Usually it does.  The available products are sold with integrated support for the vendor’s traditional media-processing resource.  Using a third-party voice board with the system software of a voice-board vendor isn’t an option.  They are inherent technologies.  Voice and call control, parameter and resource management are considered the base-level functions.  Additional media, if available from the primary vendor are add-on functions.

The System Resource Challenge
So, if the software framework is bundled with a media-processing or network-access product, every “technology-resource” vendor must develop a telephony-middleware product. It is almost impossible, then, for the developer of telephony- system resource, such as voice, data, text-to- speech, or voice codecs, to offer the system developer an integrated multi-media system platform or a comprehensive middleware system due to the enormous size of the investment hurdles.

As a modular resource-independent kernel, OTF Kernel offers an alternative to in-house development with low investment hurdles, the broadest addressable markets, and strategic control perhaps greater than in-house development, which is often severely constrained by investment and time-to-market obstacles.

System Overview
The OTF Kernel is a modular building block that includes the system-services and framework for a distributed client-server system.  As a client-server system, OTF is scalable to virtually unlimited system size since it provides seamless expansion in two critical dimensions: PCs and client applications in the client dimension and PCs and resources in the server dimension.  The benefits of this architecture have the potential of moving the open-communications industry to a new level by supporting multi-vendor applications and scalability to support system capacities in the tens-of-thousands of ports.  While it is true that client-server systems have more “moving parts” than a single-PC monolithic system, application profiles effectively separate the added complexity of resource specification from the system developer, if desired.

As a modular building block, OTF Kernel does not include the S.100 “resource APIs” (except as example code) or any vendor-specific “Service Provider Interfaces” (SPIs), making it truly independent. It is the responsibility of the system- resource vendor to develop OTF Resource Service Managers (RSMs) for each resource, unless Commetrex’ or third-party OTF-compatible resources are used. RSMs expose the resource’s functionality to OTF’s client applications. S.100 resource APIs for client applications may also be furnished by independent developers.

The ECTF’s S.300 specification (once approved) specifies a resource-specific API between the “server” and the resource-vendor’s software. But the process of specification limits the functionality of the resource. Moreover, the S.300 model has the “server vendor” producing the resource API, removing control of the client API from the resource vendor. Commetrex solves this problem by giving the OEM the facilities to add both the RSM and the resource API. As long as the same developer controls both, there is no need for a published specification. This approach eliminates the need for S.300 and puts control where it belongs–in the hands of the OEM.

Commetrex offers OTF Kernel extensions to support voice, fax, data, VoIP, and FoIP. The OTF Kernel user may use these or resource extensions provided by others or developed by the licensee. This resource independence makes OTF the industry’s only multi-vendor integrating platform.

The diagram on the previous page shows the relationship between OTF and Commetrex- provided media-processing resources. (Third-party resources are also “behind” the RSM.) Commetrex’ system resources are based on the MSP Media Gateway DSP resource boards, the MSP Consortium M.100- compatible OpenMedia environment for media portability, and the Power Series of media technologies. Host-based signal processing of call streams is also available in Commetrex’ BladeWare product.

Inside S.100
S.100 specifies APIs that give access to system services and media-processing and stream-switching resources.  But to understand how S.100 supports multi-vendor applications through resource sharing requires an understanding of S.100’s Group Manager.

The Group Manager provides a facility that tokenizes system resources and the grouping of those resources into the configurations necessary to perform work for client applications (Resource Groups). OTF Kernel provides a mechanism for resource providers to offer resources to the Group Manager for allocation to client applications and configuration into groups. Applications can then use the resources, returning them to the resource pool for use by other applications when they are no longer needed.

System Services
OTF Kernel includes the system services defined in S.100 that constitute the core services of a digital- media system. They include

• Session/Event Manager
• Group Manager
• Connection Manager
• Container Manager
• System Call Router
• Key Value Sets
• Configuration Management

Session/Event Management
The OTF Kernel Session Manger is used by all OTF-Addressable Entities (OAEs) to register with the OTF Kernel. If authenticated, the client’s Application Interface Adapter (AIA) receives a resource profile that includes the addresses of the resource providers, which are then used by the AIA to communicate with the assigned resources transparently to the client application. Once registered, an OAE can participate in OTF communications via the OTF Transport.

Group Manager
An S.100 “Group” is an object that presents a unified interface for allocation, configuration, interconnection, and hand-off between system entities of the resources needed to perform digital- media functions. The resource that represents a media stream is the “Call Channel Resource” (CCR). An example of a group for a play-message function is a CCR, a “player”, and a “Signal Detector” to detect touch-tones. Groups may be explicitly reserved by an application or they may be implicitly reserved by invoking a higher-level function. The Switch Port Resource (SPR) is used to abstract a switch-fabric (either packet or TDM) connection.

OTF Connection Management
The OTF Connection Manager is exposed to the application through the Group Manager API. It gives the application an easy-to-use facility to switch and interconnect calls from one party to another, to monitor two other parties, and to control Conferencing Resources, if available.

In the traditional model, stream switching is controlled through vendor-specific switch control and signaling. For example, a line interface from one vendor may use channel-associated signaling while another uses a host-based call-control protocol. In a basic S.100 system, each vendor presents significant complications, forcing the OEM towards a single-vendor approach.

However, OTF includes switch-fabric-specific Transport Domain Controllers (TDCs) that are responsible for implementing connection commands from the Connection Manager. The TDCs (e.g. H.100 TDC, packet TDC) are then responsible for sending the connection command to the appropriate RSM via an open TDC-RSM protocol.

The Connection Management subsystem is extensible by the OEM with the CM SDK that supports the creation of proprietary TDCs and Switch Managers.

Container Manager
“The S.100 Container Manger and its client API provide an operating system-independent mechanism for the storage and interchange of
 system data between system services, resources, and the application.”  A “container” is an object made up of data, usually media data, and a set of attributes.  The S.100 Container Manager extends the functionality usually found in file systems with features required by Resources to manipulate media data in a convenient manner.

The OTF Container Manager SDK includes APIs that allow the system developer to add support for additional media and mass-storage devices. As shown above, the Container Manager System includes Data Object Managers (DOMs), such as the Spatial Media DOM for fax, that contain media-specific knowledge, and Mass Storage Media Managers that encapsulate the storage- system-specific functions. This means the OEM can extend the OTF CM system along both dimensions. In addition, the CM subsystem includes a low-level API that allows resource subsystems to access media data through a low- overhead mechanism.

System Call Router
The System Call Router (SCR) shields the application from the details of the Connection and Group Managers and the need to be aware of any vendor-specific call control.  If provides API functions such as answer, make, and disconnect call, greatly simplifying the routine placement of outbound call and accepting inbound calls in traditional CT applications.

The SCR does not include any resource-specific call-control function. Instead, the SCR communicates with “Call Control Subsystems” located in the resource-specific Resource Service Manager (RSM) using an open protocol between the two subsystems. The OTF SCR Software Developer’s Kit (SDK) includes the necessary DLLs and documentation to allow the OEM to extend the SCR to support additional network interfaces.

Key Value Sets
OTF operates by sending messages with all manner of payloads between system components. The basic information element used for this purpose in S.100 is a Key Value Set (KVSet). A KVSet is a set of Key Value Pairs (KVPairs) of unordered information elements. Each value is associated with a Key. KVSets are used to represent function arguments, attributes, parameters, events, message payloads, and many other information elements. The S.100 specification provides a full set of functions for creating, destroying, and manipulating KVSets that are fully supported by OTF.

OTF Administration Facility (OAF)
With its distributed client-server architecture, OTF is a network of cooperative applications that must be managed as a system. With its scalability, OTF may be extended to both enterprise and service- network scale, making effective system management essential. The OTF Administration Facility meets this requirement.

The OAF is a browser-based administration facility, extensible by the OEM using the OAF SDK, that provides for configuration, operation, management, logging, and fault isolation and correction. OAF is used as is by the majority of OTF OEMs. But the SDK allows the OEM to develop a new or augmented facility to meet a particular requirement. Naturally, resource and system service vendors will use the SDK to create proprietary interfaces, APIs or communication protocols.

The SDK includes an OAF API that offers the OEM a standardized, but not required, interface to the OAF managed-entity agent. This entity is included in every Commetrex-developed OTF addressable entity as a standardized starting point for entity-specific management. The OAF Agent implements all of the standardized information elements and responses the OAF assumes. The developer then adds custom extensions.

OTF Transport
All system entities authenticated by the OTF Authentication Server are addressable by the system and any other OTF Addressable Entity (OAE). The OTF Transport includes a Berkeley Sockets API that isolates OAEs from the specifics of the underlying transport, which is typically TCP/IP. In addition to the TCP/IP signaling channel, the OTF Transport includes a low-overhead bearer facility that is used to move bulk data, such as voice and fax between storage and media-processing resources.

During session establishment the Kernel issues an authorization profile to the Application Interface Adapter (AIA), a DLL that communicates with the Kernel on behalf of the client application. The profile includes the address of entities with which the application is authorized to communicate. This scheme supports the transparent provisioning and use of application services located on secondary servers on the same or other computers.

Product Structure
OTF Kernel SDK, Product Number 20110 - This SDK is provided for the OEM that needs the capability to extend the functionality of OTF. It includes the following SDKs:

• System Service SDK
• Container Manager SDK
• OAF SDK
• RSM SDK
• SCR/TDC SDK

OTF for MSP SDK, Product Number 20070 - This SDK is provided for the application-level developer that intends to use Commetrex’ OTF-compatible resources, such as PowerVox, PowerFax and PowerCall.

Related Products
MSP Media Gateway DSP-Resource Boards – The MSP product line includes the MSP-H8, targeting the 2-16-port application, and the MSP-320, targeting 16 lines and up.

PowerCall – PowerCall adds signal detection/generation and in-band call-progress analysis to an MSP Media Gateway resource board. Licenses are sold on a maximum-concurrent-port basis. The PowerCall SDK is a prerequisite for the PowerCall runtime licenses. (This is the case for all PowerMedia.)

PowerVox – PowerVox adds S.100-conforming Player/Recorder capability. It includes G.711 and G.726.

PowerFax – PowerFax adds S.100-conforming Fax Send/Fax Receive resources. PowerFax includes Commetrex industry-leading T.30 protocol engine and Image Conversion Library.

PowerRelay – PowerRelay adds fax-over-packet capability to an MSP-320. It includes T.38 for fax over IP and I.366.2 for fax over ATM.

PowerVoIP – PowerVoIP adds packet-based voice to an OTF/MSP Media Gateway system. It includes G.711, G.726, G.729a/b, and G.723.1.

OpenMedia – OpenMedia is Commetrex MSP Consortium M.100-conforming media-processing software framework. An OpenMedia runtime license is required for each MSP board that will be used in conjunction with Commetrex’ media technologies. The OpenMedia SDK is needed for the addition of media technologies to an MSP board that is not provided by Commetrex. The OpenMedia SDK is needed to add licensee or third- party media technologies to an OpenMedia environment.

H.323 Resource Service Manager – The H.323 RSM adds H.323 V4-conformant call control and signaling to the OTF Kernel.

SIP Resource Service Manager – The SIP RSM adds oSIP call control and signaling to the OTF Kernel.

Download this Bulletin in Adobe Acrobat™Format

Download the free Acrobat Reader™ from Adobe