(Page 1 of 1 in this chapter)

Chapter 1

Introduction

1.1 About the Digital Trunk Monitor Service
1.1.1 About Alarms and Digital Trunks
1.2 About the CT Access Environment
1.2.1 Programming Model
1.2.2 CT Access Components
1.2.3 Managing Parameters in CT Access

1.1 About the Digital Trunk Monitor Service

This chapter presents general information about the Digital Monitor Service and the CT Access environment.

The Digital Trunk Monitor (DTM) service is a CT Access service. CT Access is a development environment for computer-based telephony applications that provides a standard, hardware-independent programming interface.

A CT Access service is a group of logically related telephony functions. Each service is contained in a service manager, which is a software wrapper surrounding one or more service. The service manager implements binding functions that enable a service to seamlessly integrate into CT Access.

The DTM service enables an application to monitor for alarms on T1 and E1 trunks, and to gather performance statistics. Using the DTM service enables applications to detect digital trunk failures easily.

A trunk is a transmission channel between two switching stations. For the purpose of the DTM service, we are considering a T1 or E1 line, the aggregate of 24 or 30 channels, to be one trunk. The DTM service operates directly on trunks, rather than on ports or CTA contexts. A CT Access service is a group of logically related telephony functions. A service may be implemented on multiple hardware boards.

The DTM service can be used to collect statistics, report error counts, and report errored/failed seconds counts. A DTM event is generated when any count changes. The application can synchronously retrieve the current counter values from the DTM service's internal cache.

A DTM service demonstration program called trunklog is included with CT Access.

1.1.1 About Alarms and Digital Trunks

A T1 trunk enters an alarm state upon the presence of red, yellow, or blue alarms. An E1 trunk enters an alarm state upon receipt of local or remote Loss of Frame errors, or excessive bit errors. When the DTM service is used as an alarm monitor, an event is generated when a digital trunk goes into or out of an alarm state. Since failure monitoring is done in the same processing context as call processing, an application can terminate a call and mark its port as unavailable upon receipt of a trunk failure event.

Multiple trunks can be monitored using a single CTA context. The same trunk can be monitored by multiple CTA contexts (and multiple processes).

1.2 About the CT Access Environment

This section provides background information about the CT Access API and summarizes the main elements of the CT Access environment. For more detailed information about CT Access and the ADI service, see the CT Access Developer's Reference Manual, the ADI Service Developer's Manual, and the ADI Service Function Reference Manual.

1.2.1 Programming Model

CT Access employs an asynchronous programming model in order to take advantage of concurrent processing. Each function called will return immediately with either a return value of SUCCESS or an error code. Synchronous functions are complete when the return code is received.

For asynchronous operations, if the return value is SUCCESS, the function has been successfully initiated, and the execution result will arrive asynchronously. If the return code is not SUCCESS, the operation is not initiated and no events associated with the particular function will be generated.

The execution result is indicated by an event or a series of events. An event is a data structure which includes an event ID that indicates which operation it refers to, and operation-specific results. For a more extensive discussion of events in the CT Access environment, refer to the CT Access Developer's Reference Manual.

CT Access has common system error codes that all the services use, which are defined in the header file ctaerr.h and are prefixed with CTAERR_. Refer to the CT Access Developer's Reference Manual for detailed descriptions of CT Access error codes, and to the ADI Service Function Reference Manual for detailed descriptions of ADI service error codes. Use ctaGetText to obtain the text description of an error code.

1.2.2 CT Access Components

A CTA context organizes services and accompanying resources around a single processing context. A CTA context usually represents an application instance controlling a single telephone call. Some CTA contexts are not associated with a call; for example, an operation performing speech recognition on a buffer of data does not require a telephone line.

Only one instance of a service may be opened on a single CTA context.

Each type of service has defined parameters. Each service instance has its own copy of these parameters maintained by the CTA context. This allows each telephone call to have its own characteristics.

To use the DTM service in the CT Access environment, an application must obtain a CTA context and open the DTM service on it.

An event queue is the communication path from a service to an application. A service generates events indicating certain conditions or state changes. An application retrieves the events from the event queue.

When the event queue is created, you specify the service managers to be attached to it. Use the ADI service manager (ADIMGR) for the DTM service. When creating a CTA context, you specify an associated event queue. All events from the services on the CTA context are sent to the event queue attached to the context.

One queue can be created for the entire application process or multiple queues may be used. The number of queues you create depends on the programming model used. Some models use one queue to handle all CTA contexts; multiple telephone calls are handled with the same queue. Other models use one queue for each call.

1.2.3 Managing Parameters in CT Access

The characteristics for CT Access services can be altered by modifying associated parameters. Each parameter structure has default values that are sufficient for most applications.

CT Access manages parameters for services on a CTA context basis. The CTA context will maintain a copy of the parameters for all services opened on the context. This allows each operation to have its own characteristics.

The following CT Access functions allow you to obtain or change parameter information:

Refer to the CT Access Developer's Reference Manual for details about CT Access parameter management, and for details about CT Access functions.


(Page 1 of 1 in this chapter)

tech_support@nmss.com
Copyright © 1999, Natural MicroSystems, Inc. All rights reserved.