Realizing features such as call processing, directory services, and unified messaging requires designers to coordinate a complex array of functions, services, and processes in various types of complex telephony equipment. The S.100 application programming interface (API) provides just such a toolset by brokering transactions among hardware and software components in telephony-enabled products.
S.100 is the result of the work done by the Enterprise Computer Telephony Forum (ECTF), which was founded in 1995 as a non-profit organization ofcomputer telephony vendors, developers, integrators, and users from around the world. The result of this work is an architectural framework, that
encompasses software and hardware, allowing a broad collection of services and telephony resources to be combined in sophisticated applications (see
Figure 1, ).
A key component
A key component of this architecture is the S.100 API. This API fosters a development environment that opens the door to new and enhanced telephony
applications such as interactive voice response (IVR), enhanced call and automated attendant services, and other useful services.
The architecture provides several advantages for developers of computer telephony (CT) applications. The most important advantages include support for
multiple applications, improved scaleability, and cross-vendor support. The majority of telephony application products - designed to work with servers
dedicated to specific purposes - operate independently of each other, resulting in separate servers and telephone resources (See Figure 2, ). Generally, if a
corporation has a fax server, voice mail, an IVR system, and other applications, each resides in a separate server, uses a separate set of telephony
resource cards, and requires separate telephone lines from the local PBX.
A primary design goal of the S.100 architecture is flexibility, allowing multiple applications to execute and share telephony resources on a common
server. S.100 accomplishes this flexibility by implementing an abstraction layer that makes the actual telephony resources and their physical location in
the network transparent to the application.
As a result, one telephony server can provide the required telephone interface and media processing resources to enable one or more application servers
to execute a number of applications at the same time. For small-scale applications, the architecture allows the application and telephony server to be
combined into a common server (See Figure 3, ).
Products based on the S.100 framework significantly enhance the efficiency of telephony resources at all levels including DSP resources and network
interfaces such as lines and circuits from the PBX or central office. This resource efficiency results in a reduced total systems cost, eliminating the
proliferation of specialized hardware.
Is smaller better?
In addition to enabling different applications to share a single telephony server, the S.100 architecture also allows applications to be divided into smaller
components. Multiple smaller applications are easier to develop, easier to upgrade, and easier to test.
In the past, applications almost had to be written as one huge program. This was primarily because the application had to manage all the telephony
resources and determine how to allocate ports and route calls. S.100 handles nearly all resource allocation and call routing, which dramatically simplifies
the application and its development process, and allows the application to be broken into many smaller parts.
For example, instead of building one large executable voice messaging application that provides auto-attendant, voice-mail, and paging features, a
designer could build a suite of smaller applications. One application could implement only the auto attendant, for instance, with another application just
for voice mail, and a third for mailbox access features. The S.100 architecture allows applications to easily hand calls off to other applications without the
user's knowledge. Each resulting application would be smaller, easier to develop, and far easier to test.
Scaling up
The S.100 framework helps developers to scale applications that were originally envisioned for small system environments to larger environments. If a
potential customer wants a developer to scale a voice-mail application that was originally written to support 24 ports so that it supports a large wireless
phone network that needs 1,000 or more ports per site, the task is to scale the application to support the need. The S.100 architecture enables this task
by allowing multiple telephony and application servers to work together and grow as needed (see Figure 4, ). With the API, applications can be scaled to
larger deployments with a minimum amount of code changes.
The current support solution for systems with high resource demands of this type requires building a number of application servers. Each server
requires a copy of the application and the entire configuration. As an example, sophisticated computer telephony applications, such as automated
stock-option plans, typically use databases to implement certain features. Reliable commercial databases offer a per connection licensing model,
requiring a fee for each connection to the database, which results in higher costs. Using S.100, a designer can minimize the number of connections to the
database and reduce the total hardware requirements, dramatically simplifying administration.
One vision for S.100 is to provide a common API and development specification for many different manufacturers. Using a common API eliminates the need
to learn and use different APIs for different system components. Writing to one API speeds development and allows the developer to select the vendor
hardware that is best-suited for a particular CT application. At this time, however, the component that provides cross-vendor support within the ECTF
vision (S.300) is not yet ratified. As a result, different vendors must collaborate to implement the driver-level interfaces between S.100 and the actual
hardware components.
One of the challenges today's developers face is writing applications for the existing PSTN and, at the same time, planning ahead for the emerging IP-based
networks of the future. Ideally, a developer would be able to write an application once and deploy it on either network technology without modification.
Portability between network technologies allows applications to retain their value even though the underlying network infrastructure changes. This
preserves the investment put into applications and ensures their usefulness over a longer period of time.
By abstracting many of the call-control details away from the application, the S.100 development environment makes applications portable across the
various network types. This means that an application can be written and tested using simple loop start analog cards, but deployed on either T1/E1 digital
lines or IP-based systems of the future.
No longer will application developers need to code using conditional logic based on the particular DSP card type or network interface. Nor will developers
need to develop and maintain hardware abstraction layers of software. With S.100, developers use one API and common logic for all DSP cards and network
interfaces.
Building blocks
Building an application using S.100 is somewhat different than with many of the proprietary APIs of the past. While these differences might initially
seem odd to seasoned developers of vendor-proprietary APIs, the architectural advantages and development flexibility will eventually outweigh the
additional complexity found with S.100.
This difference is akin to the change from developing with the C programming language to C++. Once the more advanced capabilities are understood, the
improved efficiency can actually make development much easier. The hard part is learning the new terminology and concepts.
The following are some descriptions of the key components of the ECTF architecture that developers depend on when implementing applications using
S.100.
S.100 depends on a set of text configuration files known as profiles. These profiles reside on the server and provide details that identify the applications,
their required resources, and call-routing rules. The syntax for these profiles can be quite involved, but by providing the configuration information in a
text form, the system administrators and installers can adjust the system configuration on a site-by-site and application-by-application basis without
code modifications.
The profiles allow the server software to register the hardware resources available on the server. This eliminates the responsibility of initializing and
managing the hardware from the application.
A key concept within S.100 profiles is a group. A group is a named collection of required resources that an application will need when handling a call. The
name of each group and the resources needed by a group are defined in a profile configuration file.
Each group configuration entry in the profile defines the primary resource used to interface to the outside world (typically via some type of network
interface) and a number of secondary resources which are media-handling capabilities (usually a player, recorder, signal detector, and signal
generator).
The system call router
Since there are a number of applications on each client and telephone line connected to a server, a method of direct incoming calls to the different
applications is required. This task is accomplished by the system call router (SCR), which is a standard part of the ECTF architecture (see Figure 5, ).
Using a profile configuration file the SCR can determine, for any incoming call, which group of hardware resources to allocate to the call, and then which
application should handle the call. The SCR profile includes a number of optional criteria that can be used to direct incoming calls based on the calling
number, dialed number, and time of day. This is useful in situations where an auto-attendant application and fax-server application will operate on the
same server and use the dialed number to differentiate which application will handle each call.
In addition to handling incoming call traffic, the SCR also manages outgoing call traffic. As an application needs to initiate an outbound call, the SCR will
automatically allocate the required resources and select a port for that call.
Since the SCR automatically handles incoming and outgoing call routing, an application developer can then concentrate on just the application, rather than
the resource-management and telephony-bus "plumbing" tasks.
Key value pairs and sets
Another significant part of S.100 that was borrowed from client/server database technology concerns key value pairs and sets. Due to the distributed
nature of the S.100 architecture, the method used to pass parameters, return results, and represent events employs a technique called key value pairs
(KVPairs). KVPairs hold information elements that include a symbol and an associated value. Each symbol has an implied type (such as string or integer)
allowing the representation of a wide variety of values.
Lists of KVPairs can be assembled into key value sets (KVSets). KVSets are useful for storing and passing a list of parameters or event values as one
entity. This makes the KVSets easier to manage and pass from client to server.
The S.100 API includes a complete set of functions to create, examine, and manipulate KVPairs and KVSets. Using these functions, developers build the
parameters needed to initiate media operations (play, record) and to inspect resulting events (completion, error).
Application development
Actual application development is accomplished using the S.100 API. The API is more abstract than past proprietary APIs, but is very robust and can
accomplish many standard media, call-control, and management functions.
The biggest difference most developers notice almost immediately is the handling of incoming calls. Since most of the initialization, call detection, and
routing is handled by the SCR, the application is dramatically simplified.
For a developer to get a true understanding of what the development environment is really like, it helps to examine some source code. To accommodate this,
Code Listing 1 illustrates a function that plays a prompt from an already recorded file. For clarity, the actual initialization and setup of the call is
omitted, but the code sample does show the KVSets in action and the prompt playback function.
Integration tasks for current and future telephony-capable networks can often seem gargantuan. Use of the S.100 API can greatly simplify even the most
complex integration tasks, smoothing out one more step in the development process.
Alan Percy is a senior field engineer at Brooktrout Technology specializing in IP Telephony technologies. Percy holds a B.A. in computer science from the
State University of New York at Buffalo. He can be reached at apercy@brooktrout.com.
| Code Listing 1: Sample of Playing a Prompt from a File |
CTstatus PlayPrompt(CTses_ct hSession, CTgrp_ct hGroup,
CTstring Prompt, CTsymbol * Error)
{
CTstatus rc;
CTkvs_ct eventkvs, optional_args;
CTtranInfo TranInfo;
CTsymbol err;
CTkvs_ct rtc;
CTsymbol stop[] = { CCR_ECTF_Idle };
// create the kvsets
CTkvs_Create(&eventkvs, &err); // Resulting events
from Playback
CTkvs_Create(&optional_args, &err); // Arguments
for Playback
CTkvs_Create(&rtc, &err); // Playback Run Time
Controls
// initialise TranInfo Structure (used to catch result
ing events)
CTtran_Initialise(&TranInfo, eventkvs);
// stop the function if a hangup is detected
CTkvs_PutSymbolArray(rtc, Group_ECTF_Stop, &stop[0], 1,
&err);
rc = CTplyr_Play(hGroup, &Prompt, 1, 0, rtc,
optional_args, &TranInfo, CT_modeSync);
if(rc != CT_statusOK)
{
printf("CTplyr_Play Failed.\n");
PrintTranInfo(hSession, &TranInfo, stdout);
*Error = TranInfo.error;
}
// clean up kvsets
CTkvs_Destroy(eventkvs, &err);
CTkvs_Destroy(optional_args, &err);
CTkvs_Destroy(rtc, &err);
return rc;
|
---
Resources
- "Architecture Framework White Paper." This paper provides a more detailed look at the architecture and mission of the ECTF. The paper is available at:
http://www.ectf.org/ectf/tech/download.htm.
- S.100 Media Services (Revision 2). A six-volume specification, defining the S.100 framework and API for developers wishing to implement their
application within the ECTF architecture. The set is available at: http://www.ectf.org/ectf/tech/download.htm.
