(Page 3 of 5 in this chapter)

2.2 CT Access Components

The CT Access architecture consists of three main components: Services Service managers Dispatcher
Services provide a group of telephony functions. Service managers provide a standard interface to the services. The dispatcher handles all routing of commands and responses between the services and the application.
Figure 2. CT Access Components
The services, service managers, and dispatcher are the internal components of CT Access. When creating applications with CT Access, you use system functions during set-up and service APIs for accessing telephony functions.

2.2.1 Services

A service is a group of logically related telephony functions. CT Access includes the following services: Service Functionality Switching Service Functions for controlling Multi-Vendor Integration Protocol (MVIP) switch blocks on telephony boards. Voice Message Service Functions for playing, recording and editing voice messages in files or memory. These functions include disk management. ADI Service Functions compatible with AG Access: Call Control Functions for establishing and maintaining network connections. Playing/Recording Functions for playing and recording voice buffers. Call Progress Functions for analyzing the progression of outbound calls. Tone Detection Functions for detecting tones. Tone Generation Functions for generating tones. DTMF Detection Functions for detecting and generating DTMF and MF tones. Auxiliary Functions Miscellaneous functions including low level control, signaling, and timing.
CT Access also supports extended services which are not included in the standard CT Access package. These services include Service Functionality NaturalFax Service providing fax functionality. NaturalText Service providing text-to-speech functionality. NaturalRecognition Service providing functions for accurate, automatic speech recognition. :
A service may be implemented on multiple hardware boards. No matter what hardware is providing the functionality, all services with the same functionality have a standard API. This allows device independent programming.
Figure 3. Application Programming Interface
Each service has a defined set of parameters which are managed by CT Access. These are referred to as standard parameters. Equivalent services implemented on different hardware platforms may have additional parameters to handle any unique functionality for that specific board. These are called extension parameters. CT Access provides the capability to access and modify both types of parameters.
There are two types of services: device services integration services
Device services interface directly to the hardware providing the service. Because of this interface, an implementation of a device service is specific to a particular telephony board. For example, the ADI service is an implementation of a device service which uses the resources on AG boards to provide functionality like call control, DTMF, etc.
You usually specify a device service with a board address, MVIP stream and timeslot. This indicates which channel or port on the telephony board to use.
Figure 4. Device Service
Integration services integrate a device service with other functionality to provide more convenient application programming. For example, the Voice Message service integrates disk management with voice playing and recording.
A device service provides the hardware interface for an integration service. When the integration service requires telephony resources, the associated device service is used. For example, the Voice Message service must be associated with a Player/Recorder service.
Figure 5. Integration Service

Service	Functionality
Switching Service	Functions for controlling Multi-Vendor Integration Protocol (MVIP) switch blocks on telephony boards.
Voice Message Service	Functions for playing, recording and editing voice messages in files or memory. These functions include disk management.
ADI Service	Functions compatible with AG Access:
	Call Control	Functions for establishing and maintaining network connections.
	Playing/Recording	Functions for playing and recording voice buffers.
	Call Progress	Functions for analyzing the progression of outbound calls.
	Tone Detection	Functions for detecting tones.
	Tone Generation	Functions for generating tones.
	DTMF Detection	Functions for detecting and generating DTMF and MF tones.
	Auxiliary Functions	Miscellaneous functions including low level control, signaling, and timing.

Service	Functionality
NaturalFax	Service providing fax functionality.
NaturalText	Service providing text-to-speech functionality.
NaturalRecognition	Service providing functions for accurate, automatic speech recognition.

2.2.2 Service Managers

Service managers have three main functions: Implement services Execute within the CT Access environment Adhere to standard CT Access interfaces
Service managers are dynamic link libraries (DLL) in Windows NT and OS/2; and in UNIX they are shared libraries which are linked to the application.
Service managers containing device services handle the hardware dependent features for the service so the application and CT Access do not have to. All commands sent to a service are routed through the service manager.
Figure 6. Service Managers Note: With the exception of defining what service manager provides what service during CT Access set-up, the application is not concerned with service managers.

2.2.3 Dispatcher

The dispatcher handles all the message routing in the CT Access system.
When the application invokes a function by using a service API, the dispatcher routes the commands to the appropriate service manager which is managing the service. When the response is received from the service, the dispatcher returns it to the application.
The dispatcher is used during system set-up to locate and define services and their parameters.
Figure 7. Dispatcher Note: The dispatcher is an internal component of the CT Access architecture. The application does not specifically address the dispatcher. The API functions used to set-up CT Access tell the dispatcher about the service and service manager bindings for the application.

(Page 3 of 5 in this chapter)

Tech_Support@nmss.com