1.1 Introduction

1.2 Call Control Overview

1.2.1 Protocols

1.3 NCC and CT Access

1.3.1 CT Access Services

1.3.2 CTA Contexts and Event Queues

1.3.3 CT Access Programming Model

1.3.4 Managing Parameters in CT Access

1.3.5 Operations, Administration, and Maintenance Service

1.1 Introduction

This manual describes how to use the Natural Call Control (NCC) service to perform call control within a CT Access telephony application, and provides detailed descriptions of the NCC service capabilities and functions. This reference manual should be used in conjunction with the CT Access Developer's Reference Manual.

This manual is targeted to developers of telephony and voice applications who are using CT Access. This document defines telephony terms where applicable, but assumes that the reader is familiar with telephony concepts and switching. It also assumes that the user is familiar with the C programming language.

1.2 Call Control Overview

Call control is an essential part of telephony applications that provides a telephony network connection between two endpoints so that a telephone call can proceed. The following application procedures are considered call control:

• Detecting, and answering or rejecting an incoming (inbound) call

• Placing an outgoing (outbound) call

• Transferring one call to another

• Placing a call on hold, retrieving a call from hold

• Disconnecting a call

• Blocking all calls on a trunk channel

• Querying the status of a trunk channel or call

The NCC service is an extension to the CT Access development environment that allows you to write applications that perform call control.

Other than transferring a call, querying it, or placing it on hold, call control (and therefore the NCC service) is not concerned with what happens once the call is connected (for example, voice file playing/recording, sending or receiving faxes). In the Natural Microsystems model, telephony switching is also not considered call control, although switching may occur during call control.

1.2.1 Protocols

Call control is implemented differently in different situations, depending upon the network type, country, etc. Each specific implementation of call control is called a protocol. Protocols are typically subdivided into groups based on signaling method (for example, Channel-Associated Signaling (CAS), ISDN, SS7). Within each group, there are sub-groups, or variants such as loop start, MFC-R2, and 4ESS. The NCC service is designed to be largely protocol-independent; that is, applications based on the service use the same NCC service functions regardless of the protocol. However, escape mechanisms are included which allow an application to send protocol-dependent commands and information using the NCC service.

1.3 NCC and CT Access

CT Access is a development environment providing standard programming interfaces for telephony functions that are hardware-independent. You must have CT Access installed on your system to build applications using the NCC service. This section provides background information about CT Access, and describes how the NCC service fits into the CT Access environment. For detailed information about CT Access, see the CT Access Developer's Reference Manual.

1.3.1 CT Access Services

A CT Access service is a group of logically related telephony functions. NCC is a CT Access service that provides call control-related functions. Other services address other aspects of a telephony application. For example, the Switching service controls circuit switching; the NaturalFax service provides fax functionality.

Figure 1. CT Access and the NCC Service

1.3.2 CTA Contexts and Event Queues

CT Access organizes services and accompanying resources around a single processing context. A CTA context usually represents an application instance controlling a single telephone call.

CT Access provides multi-processing support. Multiple CT Access application processes can perform tasks on behalf of the same CT Access context (referred to as context sharing). CT Access applications can transfer control of CT Access contexts (for example, contexts associated with individual telephone calls) to other CT Access applications (referred to as context hand-off).

An event queue is the communication path from a CT Access service to an application. A CT Access service generates events indicating certain conditions or state changes and sends them to applications via the event queue.

1.3.3 CT Access Programming Model

CT Access employs an asynchronous programming model in order to take advantage of concurrent processing. When called, most functions return immediately, indicating the operation was initiated. The application may then call other functions while CT Access is processing the command.

There are two types of functions in CT Access: synchronous and asynchronous.

• Synchronous functions indicate completion by sending a return value. The return value may be either SUCCESS or an error code.

• For asynchronous functions, if the return value is SUCCESS, the function has been successfully initiated, and the execution result will arrive later via an event. If the return code is not SUCCESS, the function was never initiated; therefore, no subsequent events associated with the function will be generated.

During the function execution, events are generated indicating the occurrence of certain conditions or state changes. If an asynchronous function fails after being initiated, CT Access delivers a DONE event to the application and the event value field contains an error code.

The following table summarizes the differences between asynchronous and synchronous functions. Section 2.3 lists all NCC service functions and indicates whether they are synchronous or asynchronous.

Characteristic	Asynchronous	Synchronous
Operation complete when function returns.	No	Yes
Returns an appropriate event when function is complete.	Yes	No
Function can fail after function returns.	Yes	No

As shown in Figure 2, for asynchronous functions, CT Access sends a command to the service which sends a command to a telephony board. The board performs the functions and sends events to the service indicating its state (e.g., function was started, function is complete, etc.). The service sends events to CT Access, which makes them available to the application.

Figure 2. Asynchronous Programming Model

Appendix A contains a complete list of NCC service errors.

Most CT Access services interact with telephony hardware in some fashion. For example, the Switching service controls the H.100 or MVIP switching chip on a telephony board. The Voice Message service uses a board's DSP resources to play and record files, etc. The NCC service interacts with a board's processing resources to perform call control on trunks connected to the board (either directly through the board's ports or indirectly through the H.100 or MVIP bus).

The method used by the NCC service to interact with hardware differs depending upon the service implementation. For example, with the NMS ADI implementation, a protocol-specific Trunk Control Program (TCP) is downloaded to the board at startup. The TCP interacts directly with the trunk, interpreting commands from the NCC service in a protocol-specific manner, and translating protocol-specific trunk events and errors into standard NCC service events.

Figure 3. NCC Service Interacting with Hardware (ADI Implementation)

One or more TCPs is provided for each protocol. You load the TCP into the on-board memory of a line interface board. For applications that must simultaneously support multiple protocols and/or protocol variations, more than one TCP can be loaded to the telephony board at the same time. Each line supports one TCP at a time.

The TCPs to be loaded for an application are specified in the configuration file. When you run your board configuration utility, it downloads the specified TCPs to the board. For more information about configuring your boards, see your board-specific installation and developer's manual.

Some protocols do not support all of the call control features available via the NCC service. For example, some protocols do not support call transfer; other protocols do not support call hold/retrieve. Once a TCP is loaded to the board, the application can determine the capabilities of the TCP using the nccQueryCapability function. For more information, see Chapter 3.

1.3.4 Managing Parameters in CT Access

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

CT Access manages parameters for services on a CTA context basis. The CTA context maintains a copy of the parameters for all services opened on the context.

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

Function	Description
ctaGetParmByName	Retrieves a single field for a given parameter name.
ctaSetParmByName	Modifies a single field for a given parameter name.
ctaGetParmID	Retrieves the parameter ID for a given parameter descriptor name.
ctaGetParmInfo	Retrieves a parameter field definition.
ctaGetParms	Returns parameter values for a given parameter structure.
ctaRefreshParms	Resets the values of all context parameters on a CTA context to the global defaults.

Refer to the CT Access Developer's Reference Manual for information about the parameter functions. Refer to the ADI Service Function Reference Manual for detailed descriptions of ADI service function parameters.

1.3.5 Operations, Administration, and Maintenance Service

The Operations, Administration, and Maintenance (OAM) service is the API for the NMS OAM software. OAM is an extension to CT Access that performs operations on, administration of, and maintenance of telephony resources in a system.Use OAM to configure and initialize the NMS hardware in your chassis. OAM can manage

• Hardware components, such as NMS boards, or

• Software components, such as the NMS Hot Swap process.

Since these components are being managed by OAM, they are called managed components.

Using NMS OAM, you can

• Create, delete, and query the configuration of a board managed component.

• Start (boot), stop (shut down), and test a managed component.

• Receive notifications from managed components.

Software processes supported by OAM include

• Hot Swap: the ability to insert and extract CompactPCI boards without powering down the system.

• Basic H.110 clock management operations: configuring and setting the bus clock across all boards in a system.

OAM is available with versions of CT Access 4.0 and later. For general information about OAM, refer to the OAM System User's Manual. For more information about the OAM service, refer to the OAM Service Developer's Reference Manual.

Note: OAM operates only when the CT Access Server (ctdaemon) is running.