Naturally, since CT Media is itself built within a framework that was established by a standards organization (the ECTF), one would assume it ultimately wouldn't be the only "middleware" game in town. And it's not.

So far two other vendors have released information (if not actual product) on server software packages that support applications written to the S.100 API. They are Brooktrout and Commetrex.

Brooktrout's RealComm 100

Brooktrout Technology (www.brooktrout.com; Needham, MA - 781-449-4100) announced this communications server and software development kit (SDK) late last year. They said they were getting ready to ship a General Availability release just before we went to press with this supplement (April 26th), so the SDK should be downloadable from their site now.

Release 1 of RealComm 100 includes Windows NT client and server software that implements the S.100 Revision 2 specification, GUI-based configuration management utilities and GUI installation scripts.

Brooktrout says it will be available in two configurations: a software only kit, which includes client and server software, API reference manual, configuration utilities, installation programs, and sample applet code; and in a complete hardware and software kit.

Initially, RealComm 100 will support the following Brooktrout hardware: Vantage PCI, Vantage VRS, Vantage Volare, RTNI-ATI, RTNI-ASI, RDSP integrated DSP/analog line cards and DSP resource cards. They also say it will drive T-1/E-1 cards from a third-party manufacturer, although, at the time of this writing, they weren't at liberty to divulge the identity of this vendor.

Like Dialogic, Brooktrout, too, is mocking up something along the lines of how they think S.300 is going to turn out. They say they're "providing an S.300 like layer to encapsulate service providers and will implement S.300 once it is ratified."

Initially, through S.100 Application Interface Adapters, RealComm 100 will support Player, Recorder, Signal Generator, Signal Detector and Call Channel. They say that Automatic Speech Rec, Text to Speech and Fax will be supported in their second release - due in August.

In the initial release, they will support most of the server components described in the body of the main tutorial on page 4, including a Configuration Manager and accompanying Application Profile database, Session Manager, Group Factory, Resource Allocation Service, Container Manager, Logical Connection Manager, Switch Fabric Controller and System Call Router.

Interestingly, Brooktrout is quick to stress that they're going to support other OSes other than NT (a subject that Dialogic has been somewhat coy about). Their planned timeframes for rolling out this support:

• Full Linux client and server - August 2000;

• Full Solaris client and server - December 2000.

They also say they'll be releasing a Win 2000 version in August.

Brooktrout also announced an Early Adopter Program. According to Mike Seto, VP of Marketing for Brooktrout's Voice Technology Division, program "participants are provided an opportunity to evaluate and develop applications with RealComm 100 in advance of general market availability.

Participants are also granted many exclusive features and privileges including a high degree of focused technical and development support. In exchange, participants must document their applications, tests, results and communicate status back to Brooktrout."

CMP Media's Converging Communication Group is also in the process of arranging server and client interoperability testing for RealComm 100 ala the tests that CT Labs is performing for the CT Media Value Network. Check CommWeb's OTSF (www.commweb.com/forum/otsf/) for the latest details.

Commetrex Open Telecommunications Framework

Commetrex (Norcross, GA - 770-449-7775; www.commetrex.com) bills its OTF as a "CT middleware product" that's S.100-conforming (Rev 2 for this as yet to be released software). Commetrex says it will include the S.100 core system services, including Group Manager, Connection Manager, Session/Event Manager, Container Manager and System Call Router.

But Commetrex definitely doesn't see its platform as a CT Media clone and a strict implementer of the ECTF Framework. Rather, they fully expect developers and OEMs to add proprietary extensions to the OTF's kernel. This, they say, can happen at both the resource and client-side levels, where the API can be either S.100-conforming or otherwise.

Further, they argue that this makes their OTF "truly independent because it does not actually include the S.100 'resource APIs.'" Instead of requiring the resource vendor to interface with an S.300 resource-specific SPI, as provided for in the S.100 recommendation, the accompanying OTF Transport defines an internal communications transport that allows any developer to augment the system by adding both the client API and the system resource. As long as the same vendor develops both, all that must be known to add a system resource is the OTF transport and the S.100 kernel APIs.

Mike Coffee, Commetrex president, explains the concept and his middleware further:

"OTF includes what we call the OTF Kernel. It's everything but the ECTF media resources (Player, Recorder, Signal Generator..., etc.), some of which Commetrex has chosen to complete so far, but not all.

"There are two reasons why we don't automatically provide the media resources: one is that, unlike CT Media, OTF is intended for both the system developer whose business model calls for adding only application-level value and for the OEM that needs a CT middleware software system but has his own resource or resources, with either S.100-conforming or proprietary client APIs. We don't care.

"So the OEM adds its resource and matching client API - by dropping it on top of OTF's AIA - to the OTF Kernel, shaving years off of time to market and millions off its development budget.

"The other reason we don't provide the media resources automatically is because our particular resource boards don't provide any resource until one is licensed - and on a maximum-concurrent-port basis, at that.

"So if you take one of our MSP-320s, for example, you might be able to support 120 voice ports and 30 V.90 ports, but you might only have 71 ports of voice, 16 ports of V.90 and 43 ports of fax. So when the OEM licenses these media functions it gets the client API, MSP Resource Service Manager for the MSP-320, and the Resource Service Provider for each of the licensed media."

Commetrex also totally eschews the notion of a S.300-like hardware abstraction layer. Says Mr. Coffee: