January 1999

Whither S.100?

BY MIKE COFFEE

Much has been written of late about S.100, but critical questions about this standard have yet to be answered. S.100 is the seminal work of the ECTF, and there has been much hope for it within the industry, yet I don’t know of a single implementation that has been brought to market since it was ratified. The only product I know of on the market that claims to conform to S.100 actually preceded the standard and served as its model. Over two years after its release, it is appropriate to question S.100’s relevance to today’s computer telephony market. Why haven’t the industry’s market-share leaders supported S.100? Why, in spite of all the hoopla, is there so little real support for S.100? Does it have a hidden flaw, or are the industry’s market-share leaders just not interested in making a large investment in a non-proprietary API and system architecture? Here’s what you need to know to make an informed judgment about the probable role S.100 will play in the future of open telecommunications and whether or not you should consider it as a part of your product-platform strategy.

DEFINING S.100
First, let’s agree on what S.100 is and isn’t. It’s not a “driver.” And it’s not just an API, although it does specify several. S.100 is a client-server CT middleware environment that supports resource-location independence and distributed-system architectures. As such, it is far more comprehensive and complex than the typical API and drivers provided by CT resource board vendors. So let’s call S.100 “CT middleware” (the software that interfaces client applications and server-controlled system resources).

It’s understandable why industry volume leaders that have not developed an S.100-conforming systemface aren’t in a hurry to do so. They have been quite successful with their proprietary, closed-architecture systems and APIs, and they will need a good reason to make the large investment in development and marketing required to produce an S.100 product. And if the current specification is implemented as is, what they would end up with is yet another closed-architecture system notable only by its non-proprietary APIs (APIs that may not even expose the best features of their media-processing resources).

“What?” you say. “Isn’t S.100 open?” Well, yes and no. It’s open in that an application can be developed to resource-independent APIs, but it’s really no more open than proprietary APIs in most other important respects.

So why bother? Let’s look beneath the covers with S.100 to try to discover why it has yet to take hold as a standard and why it may eventually do so. First, let’s consider the four common factors of a successful standard:

1. The standard must solve a significant problem ( one big enough to justify a non-proprietary solution. And potential implementers must have the vision and technical know-how to understand the problem and its solution.
2. The standard must be technically credible. If the standard developers didn’t do a good job technically, it won’t be supported by developers and will fail.
3. The benefit to the developer must be significantly greater than the cost of developing the product.
4. The standard must be successfully marketed.

Let’s see how S.100 meets these criteria.

THE PROBLEM
What problem is S.100 designed to solve? In a word: interoperability. But interoperability between what and what? And is interoperability viewed as a big problem among the vendors of platform-level technology products and their OEM customers?

The primary objective of S.100, and the only one met by the 1.0 version, is application-level portability across different vendors’ implementations of the APIs. If there were more than one S.100-conforming product available, this would be possible, since S.100 offers well-defined APIs for system services and selected resource APIs, such as fax, voice play/record, and speech recognition. But given a choice, would a CT OEM rather have an interoperable middleware system, or one that can be controlled to meet its strategic objectives?

Apparently, the ECTF did not contemplate the OEM or system-developer user of S.100 actually controlling it from a strategic standpoint. That was to be the role of the ECTF and the S.100 vendor. Would the OEM rather have a system that supports “swapping out” the middleware, the system resources, or both? S.100 supports the former, but support for the latter is only an objective.

Another stated objective is system-resource independence, or interoperability between different vendors’ system resource boards. Different vendors’ voice, fax, data, text-to-speech, and speech recognition resources are supported by the standard. A good indicator of resource-vendor independence would be whether the S.100-compliant product comes without system resources attached, or if it is only available with the vendor’s voice board. Can a third-party voice board be easily substituted? There are no alternate vendors of voice boards for the only current market offering. S.100 doesn’t do a very good job here. Current implementations don’t offer standards-supported resource board substitution since the necessary interfaces have yet to be specified.

Are these goals the solution to a big industry problem? It depends on whom you ask. Let’s look at the first goal: interoperability between different vendors’ implementations of the S.100 APIs. The most likely motivation to do that is to allow switching vendors, but vendors of what? The vendor of the S.100 software system -- the CT middleware? What about the vendor of one or another system resource? Even assuming there were more than one vendor of S.100 CT middleware systems, today the two would be one and the same. With the current implied S.100 architecture, one can’t be changed without also changing the other. That’s because the system resources are rather firmly wedded to the S.100 server, just as in non-compliant middleware products.

“But how can that be?” you exclaim. “S.100 is open!” That may be, but S.100 is also designed to be an “opaque” server. The client applications and the Telephony Service Providers (TSPs) can only “see” the server, requiring separate specifications for the client and service-provider interfaces. Moreover, the S.100 architecture assumes that resource APIs, such as voice play and record, are all furnished by the S.100 vendor. Although S.100 provides a facility for applications to communicate (CTses_SendMessage) in order to substitute a third-party service that is accessible by applications, there must be a defined interface between the TSP and the Server: S.300 -- and it must be resource-specific. Theoretically, the service can be provided by third-party vendors, but S.300 is not defined, rendering S.100 opaque and effectively non-extensible. If there is no interface defined between either the client application and the server nor the TSP and the server, we’ve got a fixed-function, non-extensible system. So S.100 fails what many developers say is a key test of openness within this context.

TECHNICAL CREDIBILITY
Technical credibility is comprised of layers. The uppermost layer, and the one whose value can overwhelm all that follow, sets a system’s requirements. Once the system requirements are set, design and implementation can only be judged in how effectively they support the requirements. In the case of S.100, there is some excellent engineering work in the specification, and many important requirements are met. But S.100 comes up short, more due to the few very important requirements that are omitted than to the many that are included.

Let’s look at the important requirements met by S.100. The primary system services required in a CT middleware system are provided:

• Session and event management.
• Parameter management (Key Value Sets).
• Resource management (Group Manager).
• Connection management.
• Container management.

After studying the recommendation in detail, it’s obvious that significant talent and effort went into S.100 to specify these system services, but except for Group Management and a few other features, all of these facilities are available in most reasonably comprehensive CT software systems, such as those provided by Brooktrout, Dialogic, and Natural MicroSystems. However, the Group Manager specified in S.100, along with the Real Time Control (RTC) mechanism, goes well beyond current systems. These system-level facilities support resource-location independence and give the user the services needed in a CT system capable of supporting applications from multiple vendors. This is a significant advance in the state of the art, but what about that one critical feature: open interfaces to allow seamless third-party extensions? It’s not there.

BENEFIT TO THE IMPLEMENTER
Why should a resource vendor implement S.100? Let’s look at the pros and cons.

There are surely other considerations, but judging from those listed, it’s not difficult to see how an enabling-technology vendor could decide to pass on S.100 provided the vendor has a high-function CT middleware product. However, if a vendor planning to enter the market at the high end were to take a look at the table, quite a different answer could result.

MARKETING
The lack of widespread adoption of S.100 is not due to lack of marketing effectiveness. H.100, another ECTF specification which has received less media attention than S.100, is being widely adapted. S.100 marketing has been superb. Hardly a person in the field of CTI hasn’t heard of the ECTF, and everyone has some idea of what S.100 is.

A SOLUTION
In spite of its lack of effective openness, S.100 has much to offer. Consider the requirements of a client-server computer-telephony system:

• A facility to create the logical binding between the client process and system services.
• A facility to create the logical binding between service providers and the system-services kernel.
• A facility to manage system-wide parameters.
• Event management.
• Resource management.
• Connection management.
• Call routing.
• Container Management.

S.100 has all that, and has specified it beautifully. So a vendor starting from ground zero with a requirement to develop a highly advanced system (e.g., distributed, client-server, resource-location independence, etc.) could view S.100, at a minimum, as an outstanding jumping-off point.

S.100 also specifies resource APIs for fax (two of them), automatic speech recognition, voice play/record, and signal detector and generator. Not a bad start, but hardly sufficient for many applications. What about text-to-speech, data, video, VoIP, and FoIP? Looking beyond what’s specified, if S.100 is really open, shouldn’t the system-developer user (OEM) be able to add any resource required by an application? Even though this is not readily achieved with today’s closed-architecture product offerings, most developers would probably answer that as an open system, S.100 should provide at least this measure of openness and extensibility. But it doesn’t. With the system architecture implied by the S.100 specification, a developer cannot integrate a proprietary API that appears as a seamless peer of the system vendor’s APIs or substitute another for one included with the base system.

What if, instead of bothering with the S.300 interface, the S.100 kernel defined a robust system transport that all entities -- both client applications and system-service entities -- could use to communicate with any other entity? And, suppose the system entity responsible for locating resources for the client had an interface defined for service providers? With these two changes, any vendor could easily replace existing resource APIs, and additional APIs and system resources could be easily added. Any resource could be accommodated as long as the same vendor provided both the client API and the TSP entities that would communicate over the system transport.

The result would be a truly open S.100 kernel -- one that would furnish the core S.100 system services, such as session and event management and container management, yet support vendor-specific extensions. The system developer/OEM would regain control of his strategic platform. Today, if a text-to-speech vendor wants to add his product as a system resource to an S.100 system and sell it as a software add-in to users of an S.100-conforming middleware product, he’s out of luck. With the changes suggested above, it could be easily done.

But if the primary goal of S.100 is interoperability at the API level, wouldn’t an architecture that allowed the user to easily extend the S.100 system by adding a special-purpose API and its associated system resource be counter to that goal? Sure, but maybe every system developer doesn’t share that goal. Maybe all the OEM wants is a cost-effective starting point. Or, perhaps all that is needed is the core system services listed above. The ideal situation would be for the OEM to be able to purchase the S.100 kernel from one vendor and matched TSPs and client APIs from “best-of-breed” selections of resource vendors. If a developer were really interested in being able to interchange resource vendors, he could limit his application to S.100-conforming resource APIs.

As it turns out, the S.100 specification doesn’t preclude solving these problems, and with a little out-of-the-box thinking it can be done. What’s needed is a server that can be made transparent to the vendor of system resources. Consider the theoretical design of the Intelligent Network (IN) -- not the way it works in practice, the theory.

The IN is the “server” to the subscriber “clients.” Using Signaling System 7 (SS7) the IN routes service requests to Service Switching Points (SSPs) that query Service Control Points (SCPs) to locate a service provider. The request is ultimately routed to a service provider that provides the requested service to the caller. Since all the protocols are defined, any vendor (theoretically) can attach a service node to the network and, with proper connection to the signaling network, have his service become a seamless extension of the network services.

Mapping this model onto S.100 has the S.100 kernel and its system transport equaling the IN; S.100 client applications are the network-subscriber terminals; and network service nodes equal S.100 system resources, such as a fax resource. Just as a non-network vendor can attach a new service to the IN, a third-party vendor can attach a new and even unspecified resource to the S.100 kernel.

But there is one more missing element: S.100 has no signaling protocol. There is no specification to support inter-vendor call-control signaling. It must all be handled by a special design of either the application developer or the S.100 vendor. But with the addition of a robust signaling protocol, the S.100 system can economically support complex switching applications such as in a PBX or ACD.

Such an addition to the system means a third-party network-access or station interface can become a seamless part of the system’s signaling network without requiring any special design by either the S.100 kernel vendor or the application developer. The S.100 System Call Router and Connection Managers are combined to provide the necessary services.

Applications determine the routing rules, or can determine the routing on a call-by-call basis. Of course, routing rules can be used to route calls to the appropriate application, as specified for the System Call Router by S.100.

WHITHER S.100?
With only one implementation of S.100 and the possibility of high-clout vendors entering the market, it’s difficult to say whether S.100 will become a real factor within the open telecommunications space. However, we do know that it will not be successful as originally envisioned if only one platform vendor supports it, and it’s doubtful that either of the other two market-share leaders will support it anytime soon. So, it could be argued that the success of S.100 will be determined by companies not currently in the front ranks of CT system-resource vendors.

Mike Coffee is the president of Commetrex Corp. Commetrex develops, produces, and markets software products for computer telephony integration original equipment manufacturers (OEMs), system developers, and integrators. For more information, contact the company at 770-449-7775, or visit their Web site at www.commetrex.com.