At CTI Labs, we review plenty of computer-telephony integration products,
and we devote a lot of attention to the features and functions they provide. However, we
also like to inspect the platforms that support these products. So, when we had the chance
to review CT Access, a new development product by Natural MicroSystems (NMS), we jumped at
the opportunity.
NMS, a premier vendor of development products in the CTI industry, caters
to a wide variety of telecommunications clients. Fields addressed by NMS include
traditional applications (such as Interactive Voice Response and voice mail), special
applications (such as logging and monitoring), network applications (such as wireless and
central office), testing applications, and Internet telephony applications. A proponent of
the H.100 and MVIP (MultiVendor Integration Protocol) architectures, NMS has a strong
international presence with approvals in over 30 countries.
Over the years, we have grown accustomed to seeing telephony products
built on NMS’s hardware and software platforms. Now, here was our chance to take a
peek at one of these newly released platforms, CT Access. CT Access is a modular run-time
and development environment for voice, fax, and call processing applications. It provides
a consistent API (Application Programming Interface) library that allows applications to
efficiently access and integrate with underlying telecommunications hardware.
INSTALLATION
For our review, we decided to work with a Pentium 133 PC that had 32 Megabytes of RAM and
that ran Windows NT Workstation 4.0. (CT Access is compatible with several operating
systems, including Windows NT, OS/2, UnixWare, and SCO OpenServer.) On this machine we
installed Microsoft’s Visual C++ 5.0, a component of the Developer Studio suite. We
planned to use Visual C++ to compile and link CT Access programs, rendering us executables
that we could run on our PC.
Hardware
We installed the AG-8 board that we had received with CT Access. The AG-8, one of
several cards belonging to the AG (Alliance Generation) family, can support up to 8 ports
of call and voice processing with either loopstart or DID (Direct Inward Dial) interfaces.
We plugged the AG-8 card in to an available ISA slot on our PC and turned on the PC.
Since we already had a SoundBlaster 16 in our PC, we had previously checked with their
documentation to get the AG-8 default settings. Thus, we knew how to avoid conflict. The
PC came up fine with the sound card functioning properly. Of course, we could have used a
board other than the AG-8. Other AG boards, such as the AG-T1, have different types of
interfaces and can handle more ports. The AG-60 can provide up to 60 ports of voice and
call processing on a single PC expansion slot. Other hardware offerings from NMS include
the AGRealtime family with DSPs (Digital Signal Processors) for wireless and IP telephony
solutions. Also, NMS provides network and data communications products, such as SS7 and
the TX line of network interface cards.
Software
We expected that the software installation would be a two-step process. First,
install the ADI service. Then, install CT Access. However, when we set about installing
the ADI service, we found that we couldn’t, not until we installed AG Access. At
first, this threw us for a loop. We had thought that CT Access was a new and improved
development kit to replace AG Access. So why did we need to install AG Access before
installing CT Access?
It turns out that AG Access provides multiple telephony functions for the Alliance
Generation family of hardware, and that there are two development platforms to access
these functions: AG Access SDK (Software Development Kit) and CT Access SDK. It is the AG
Access SDK that CT Access has improved upon. And the ADI functions of AG Access are now a
service component of CT Access. Frankly, we found all this a bit confusing. We think it
would be better if NMS were to supply one set of diskettes (or better yet a CD-ROM) under
the name of CT Access, rather than breaking it up into two installations, one for AG
Access and one for CT Access.
- AG Access: The AG Access installation, which went through three diskettes,
began by asking us to let it change a few environment variables, such as PATH, INCLUDE,
and LIB. These variables need to be defined so the compiler and linker can find the
appropriate library files when building applications.
The next step was to create the AG configuration file, AG.CFG. Residing in the CFG
subdirectory, this file contains configuration entries such as interrupt, I/O address,
MVIP parameters, and Trunk Control Program (TCP). These entries are used to initialize the
board. We used AGMON.EXE, a utility program provided with AG Access, to initialize the
board. AGMON relies on APIs from the AGM library. In fact, these APIs facilitate the
initialization and monitoring of the AG boards. Specifically, these APIs allow an
application to read the AG configuration file, install device drivers, boot the AG boards,
and download files to the boards. Based on the AGM APIs, AGMON reads the AG.CFG file to
determine the appropriate configuration parameters for the AG board and downloads the
corresponding firmware to the board.
From the command screen, we ran AGMON, and right away we got an error message
complaining about the missing configuration file. It turns out that the CFG directory does
not come with a AG.CFG file; instead, it has a few sample configuration files for
different AG boards. In our case, we copied the appropriate sample configuration file
(AG8.CFG) to AG.CFG, and then we re-ran AGMON. This time we received an error message
about an I/O address problem. Figuring that the problem might be a conflict between the
AG-8 board and the sound card, we checked with Windows NT Diagnostics. However, there was
no conflict. Next, we opened the AG.CFG file for a closer look. We found this statement:
Address = 2C0 Since this was the default address for the board, our first reaction was to
assume it was correct. However, we took a closer look anyway, just to make sure that the
board address was really set to 2C0. It wasn’t.
With the PC powered down, we set the address on the AG-8 to 0x2C0 (easily done from the
DIP switch on the face of the card). Then, we powered up the PC. This time AGMON went a
bit further, but now it complained about the interrupt. We changed the default interrupt
from 12 to 11, and then other values, but we still had the same problem. Finally, we
called NMS technical support. They gave us the solution right away. It seems most mouses
on PCs today use interrupt 12, which makes this interrupt unavailable to other devices.
But why weren’t other interrupts working? The answer here was in the BIOS under the
Peripheral Setup menu. We chose the unused interrupt 7 and made it available to the
system. After a reboot, we opened the AG.CFG file and changed the interrupt to 7 and then
invoked the AGMON program once again. Success at last! The board was initialized.
- CT Access: CT Access, which came in two floppy diskettes, was just as simple to
install as AG Access. When the program finished its installation, we verified that the
system was operating correctly by running the CT Access Version Checker program. This
program opened a command window displaying the versions of all CT Access components with
their build dates.
- Sample Program: We ran the sample program CTATEST to verify that the board and
CT Access were working in harmony. An interactive test program, CTATEST can be used to
demonstrate that CT Access functions are executing in asynchronous mode. Also, using
CTATEST, we could verify proper installation and operation of the ADI service. Before
starting the program, we connected two PSTN lines to the first two ports of the AG-8
board. Next, we invoked CTATEST from the command window and observed a long menu of
commands to choose from. Using the various menu commands, we were able to open a port and
initiate the loopstart protocol on the port. Then, we dialed into the port from an outside
telephone set and used the command menu to answer the call. We were also able to record
our voice in memory and play it back to the caller.
- Voice Editor: We installed Syntrillium Software’s Cool Edit 96, a voice
editor with play, record, and utility functions for several compression algorithms and
file formats including NMS’s .vce format.
DOCUMENTATION
With CT Access, you need to negotiate a great variety of functions, events, messages, and
code. You must also be aware of numerous procedures for the development of solid and
robust applications. Clearly, CT Access, as a complex and rich development environment,
demands clear and comprehensive documentation. This demand was met, and then some, by the
manuals we inspected. In fact, the CT Access documentation gets an A for its usability,
clarity, completeness, and attention to detail. We were particularly impressed with the
abundance of sample code segments in the manuals. These samples certainly make the
developer’s life a lot easier.
Hardcopy/Printed Documentation
Natural MicroSystems provided a wealth of printed information on both the
hardware and software aspects of CT Access. For example, on the hardware side, we reviewed
several manuals that described how to work with the AG-8 board. These manuals included an
installation guide, a hardware reference manual, and an installation card. This last piece
of documentation, which was an extremely compact (and convenient) reference, was what we
relied on most to guide us through the configuration and installation of the AG-8 board in
our PC.
On the software side, Natural MicroSystems provided many pieces of CT Access
documentation, which were gathered together into a couple of loose-leaf binders. The
documents included an AG Access installation manual, a CT Access installation manual, an
AGM library developer’s reference manual, and a CT Access migration manual. (The
migration manual described how developers could carry over applications from ME/2/X, AG
Access, or SwitchPath to CT Access. This document made useful comparisons between the
other architectures and CT Access. In addition, it summarized the newer functions from CT
Access that could serve as replacements.) The loose-leaf binder also included these
documents:
- CT Access Developer’s Manual: This manual covers the CT Access
architecture, application development methods, and concepts for CT Access, as well as CT
Access and ADI services and their usage. The manual concluded with a chapter on
demonstration programs, as well as utilities and appendices on VOX file format, Prompt
Builder, and a sample switching application.
- CT Access Function Reference Manual: This manual contains the complete function
reference for CT Access, including a function summary and a detailed alphabetical function
reference. Errors, events, parameters, and encoding formats are covered in appendices.
- ADI Service Function Reference Manual: This document, like the CT Access
Function Reference, contained the complete function reference for ADI services, including
a function summary and a detailed alphabetical function reference. Errors, events,
telephony protocols, parameters, and DSP files were covered in appendices.
Diskettes/Online Documentation The diskettes, like the printed manuals, provided the CT
Access and ADI Service Function references and the CT Access Developer’s Manual.
These diskettes were in HTML format, so we could access them via a browser (Figure 19) or
our Visual C++ development application.
We were pleased to see that the online reference documentation was provided in an
organized and easy-tonavigate HTML format. This arrangement made it easier to locate and
reference the desired functions.
FEATURES
In this summary of the features of CT Access, we will concentrate on two broad areas: the
main structural components of CT Access (which we divide into Foundation and
Superstructure), and the benefits that CT Access extends to developers.
The Foundation
As a NMS product, CT Access is based on the Telephony Services Architecture
(TSA), a hardware and software framework to support open, high-capacity, switching
intensive, mixed-media applications for tele-phonenetwork integration. Moreover,
TSA’s framework provides a standardsbased, layered, OS independent, and modular
approach to application development.
TSA components include:
- Natural Platforms: These are the hardware and firmware products, including the
Alliance Generation (AG) family of digital signal processor (DSP) engines and the AG
Connect family of telephone network interfaces.
- Natural Media: These are the software and hardware extensions to the Natural
Platforms products for integrating facsimile, speech recognition, and text-to-speech into
a single application.
Products in this category include NaturalFax and NaturalRecognition.
- Natural Access: The Natural Access set of products provide programming tools to
support the Natural Platforms and Natural Media products as well as third-party products.
The AG Access toolkit provides an API library which supports the Alliance Generation
Family.
The Superstructure
CT Access architecture consists of three main components:
- Services: These are groups of logically related telephony functions which at
its heart include switching service, voice message service, and ADI service. (For more on
services, see the section on benefits.)
- Service Managers: Under Windows NT and OS/2 Service managers are DLL’s
(Dynamic Link Libraries) which are used to route commands to services handling the
dependent features of the services and therefore hiding those specific implementations
from the application.
- Dispatcher: The dispatcher handles message routing from the API to the
appropriate service manager. It also returns responses from the services back to the
application.
CT Access Benefits
- Standard set of telephony functions grouped into logical services: One of the
greatest advantages of the CT Access development environment is grouping telephony
functions into logical services. As noted earlier, key telephony functions include the ADI
service, the switching service, and the voice message service.
The ADI service (part of the AG Access APIs) provides the functions for call and voice
processing (interfacing with AG boards); the switching service provides MVIP switch
control; and the voice message service provides functions for playing, recording and
editing voice messages in files or memory.
In general, there are two types of services: device services and integration services.
Device services interface directly to the hardware providing functionality like call
control and DTMF (Dual-Tone MultiFrequency) detection. Integration services, on the other
hand, integrate a device service with other functionality to provide easier application
programming. For example, the voice message service is an implementation of an integration
service whereby it integrates disk management with voice playing and recording.
CT Access also supports extended services not included in the standard package. These
services include NaturalFax providing fax functionality, NaturalText providing
text-to-speech functionality, and NaturalRecognition for automatic speech recognition.
It could be concluded that other, yet unknown functionalities could be packaged into
services in the same manner under CT Access. This is unlike the AG Access development
environment, where, for example, the MVIP switching control is provided using a separate
NMS package, SwitchPath. By using standard APIs, CT Access can abstract the lower levels
from the development process allowing for an easy, flexible, and unified development
environment with support for numerous interfaces.
- Standard hardwareindependent APIs: This is a true win for the developer as
he/she needn’t be concerned with the underlying hardware. This feature shifts the
burden of compatibility from the developer to the hardware manufacturer.
- Standard interface for accessing and changing service parameters: CT Access
provides a standard set of functions to retrieve and modify service parameters for special
configurations. The service parameters, however, have default values that are sufficient
for most configurations.
- Error trapping features: CT Access allows the developer to define error
handling modules and register them within the application.
- Correct resource allocations: As most developers know, resources are always
scarce. Fortunately, CT Access allocates resources only to those specified by the
developer.
- Support for single-threaded and multithreaded programming: CT Access
accommodates either type of programming, which lets the developer decide which model is
appropriate in any given project. Basically, the developer may choose to work with a
single, multithreaded process, and emphasize efficiency, or the developer may work with
multiple single-threaded processes, and emphasize availability and uptime.
- Support for asynchronous programming: CT Access uses an asynchronous
programming model for its operation in order to take advantage of concurrent processing.
In an asynchronous model, the application does not have to wait for each function invoked
to be completed before proceeding further. So how does the application check for the
function return status or code? The return codes are delivered by CT Access to the
application as events. The application then must check for these events and take necessary
actions depending on the returned events.
An application uses CTA contexts to organize services and resources for a single
processing context such as a telephone call. When a CTI context is created, an event queue
is also specified. Then all events from the services on the CTA context are sent to the
event queue attached to the context. The application then retrieves the arriving events
from the event queue and takes action according to the events. Eventdriven applications
are very common today. In fact, Windows programs are another example of event-driven
applications.
EXECUTING APPS
You can usually divide your preparations for running your completed application into two
parts. First, you have setup chores that are so basic to most applications they are
virtually mandatory. Second, you have tasks that are more specific to whatever application
you happen to be working with.
Application Setup
With CT Access, application setup consists of the following core functions:
- Initializing CT Access for the process: This is done by calling the
ctaInitialize function to register services and specify parameter management as well as
other initialization actions to create the CT Access environment.
- Creating event queues: This step is accomplished by calling the ctaCreateQueue
function which returns an event queue handle to be used for the queue related functions.
- Creating CTA contexts and attaching them to a queue: This is done by calling
the ctaCreateContext function and providing the queue handle returned by the
ctaCreateQueue function to be associated with the CTA context. A CTA context handle is
returned which must be supplied by the application when invoking CT Access functions.
- Opening services: Finally the application must open relevant services on the
created CTA context by calling the ctaOpenServices function. The application can open and
close services as needed on the CTA context to preserve resources.
Application-Specific Functions
Once you’ve take care of application setup, you can begin addressing
functions that are more specific to your application, a task that involves invoking the CT
Access APIs. In this section, we will review the more “application-specific”
functions provided under CT Access, functions that can be divided into two categories: CT
Access functions and ADI service functions.
CT Access functions include: set up application; process event queues; terminate
services and destroy contexts and queues; modify parameters; handle errors; verify
compatibility; and perform tracing. In general, these define CT Access system functions.
Other, miscellaneous tasks under the umbrella of CT Access functions include switching
service functions; control MVIP switch blocks (for example, making connections,
configuring clocks); access MVIP device drivers; voice message service functions; play,
record, and edit voice messages; support multiple file formats; and support advanced voice
functions.
ADI service functions include: call control (establish and maintain network
connections); playing/recording (play and record voice buffers); call progress (analyze
the progression of outbound calls); tone detection/generation (detect and generate tones);
DTMF detection/ generation (detect and generate DTMF and MF tones); and auxiliary
functions (miscellaneous functions including signaling and timing).
OPERATIONAL TESTING
A good way for a developer to get started with a new development platform is to follow the
examples provided with the development tool. In our case, we used the CTATEST program
(mentioned earlier in the Installation section). CTATEST is provided as one of the sample
programs with CT Access together with its source code in C. We decided to rebuild this
program using Microsoft’s Visual C++ installed on our Windows NT Workstation.
Of course, we wish we had the time to build a full, GUI-based application using CT
Access. But not to worry: several companies are already developing their telephony
applications using CT Access. They should start hitting the market soon.
In Visual C++ we started a new project, “sample.” Since CTATEST is a command
window program, we chose the “Win32 Console Application” for our project. Then
we added the source files to this project which included CTATEST.C, CTADEMO.C, and
CTADEMO.H (Figure 20). The sample applications also came with their own Makefile, which
was used to build the application.
We could have just as well had our sample project use the accompanying CTATEST Makefile
to build the application (Visual C++ uses the NMAKE program to do so), but we decided to
use the Project Settings to set compile and link options, among other things. In the Link
screen, we added three CT Access libraries, adimgr.lib, cta.lib, and vcemgr.lib (Figure
21). These library modules are referenced when function calls are encountered by the
linker.
Making sure that our LIB and INCLUDE environment variables included references to the
correct CT Access directories, we clicked on Visual C++’s Build button and watched as
CTATEST was successfully compiled and linked, creating CTATEST.EXE. Since CT Access
applications make use of DLLs, we also had to make sure that the PATH environment variable
included a reference to the bin subdirectory where the DLLs reside. We ran our newly
created CTATEST program. It actually worked!
Finally, we took a quick look at the CTATEST.C source file to see how our commands were
being executed (Figure 22). For example, command AC (for answer call) calls the
adiAnswerCall function, or command PC (for place call) calls the adiPlaceCall function.
Both of these functions are part of the ADI service call control API. On the other hand,
command OP (for open port) calls the ctaCreateContext and ctaOpenServices functions to
create a context and service instances within the context. These functions are part of the
CT Access system API.
CONCLUSION
If you are in the market to develop a telephony application or polish up on your old
applications, CT Access by Natural MicroSystems is the development environment to beat. In
our opinion, NMS has done an impressive job of simplifying call control and media
processing by unifying them under the CT Access umbrella. With CT Access, many low-level
and cumbersome layers of telephony functions have been abstracted, giving the application
developers a standard API and common functions to create telephony applications regardless
of the underlying hardware, the interface, and the operating system.
We also found that the CT Access documentation was well organized, user-friendly, and
instructional. We would like to see AG Access and CT Access combined in one easy-toinstall
CD-ROM. We would also like to see some GUI samples utilizing CT Access in addition to the
current demonstration programs. We were also impressed with the modularity and scalability
of CT Access. Indeed, this platform has already demonstrated it can support continued
enhancements. For example, NMS recently announced the integration of Fusion 2.0 (a
development platform for IP telephony gateways) with CT Access. Also, the newly released
CT Access 1.1 has brought more enhancements to the CT Access platform, such as running
AGMON as a service under Windows NT and providing fullduplex, echo-canceled voice, which
is a valuable feature for IP telephony gateways. |
Internet Telephony Magazine
Click here to read latest issue
CUSTOMER 
Cloud Computing Magazine
Click here to read latest issue
IoT EVOLUTION MAGAZINE
