(Page 1 of 1 in this chapter) Version

Chapter 1

Introduction

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.1 Introduction

The Natural Call Control (NCC) service is an extension to the CT Access development environment which allows you to write applications that perform call control. This chapter provides an overview of the NCC service, and defines some basic concepts.

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 provides the means for an application to perform all of these tasks.
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 (e.g., voice file playing/recording, sending or receiving faxes, etc.). In the Natural Microsystems Telephony Services Architecture 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; e.g., Channel-Associated Signaling (CAS), ISDN, SS7. Within each group, there are sub-groups, or variants (e.g., loop start, MFC-R2, 4ESS, etc.). 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

NCC is implemented as a CT Access service. CT Access (Computer Telephony 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, providing call control-related functions. Other services address other aspects of a telephony application (e.g., the Switching service controls circuit switching; the NaturalFax service provides fax functionality).
Figure 1. CT Access and the NCC Service
The following is a partial list of available services: Service Description Switching Controls Multi-Vendor Integration Protocol (MVIP) switch blocks on telephony boards. This service is able to drive any board providing an MVIP compliant DLL. NCC Performs Call Control: establishes and maintains telephone network connections. Voice Message Used for playing, recording, and editing voice messages in files or memory. ADI · Playing/Recording: Playing and recording voice buffers. · Call Progress: Analyzing the progression of outbound calls. · Tone Detection: Detecting tones. · Tone Generation: Generating tones. · DTMF Detection: Detecting and generating DTMF and MF tones. · Auxiliary Functions: Signaling, low-level control, and timing. · Call control. Note that the Natural Call Control Service supercedes ADI call control. ADI call control functions have been retained only for backward compatibility.

Service	Description
Switching	Controls Multi-Vendor Integration Protocol (MVIP) switch blocks on telephony boards. This service is able to drive any board providing an MVIP compliant DLL.
NCC	Performs Call Control: establishes and maintains telephone network connections.
Voice Message	Used for playing, recording, and editing voice messages in files or memory.
ADI	· Playing/Recording: Playing and recording voice buffers. · Call Progress: Analyzing the progression of outbound calls. · Tone Detection: Detecting tones. · Tone Generation: Generating tones. · DTMF Detection: Detecting and generating DTMF and MF tones. · Auxiliary Functions: Signaling, low-level control, and timing. · Call control. Note that the Natural Call Control Service supercedes ADI call control. ADI call control functions have been retained only for backward compatibility.

1.3.2 CTA Contexts and Event Queues

A CTA context organizes services and accompanying resources around a single processing context. CTA contexts are created by the application.
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. An application retrieves the events from 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 are complete when the return value is received. 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 if 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 B 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 via the board's ports or indirectly via 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. (See Figure 3.) 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 AG configuration file. When you run the agmon board configuration and monitoring utility, it downloads the specified TCPs to the board. For more information about agmon, see your AG Configuration and Runtime 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.

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

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 will maintain 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.

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.

(Page 1 of 1 in this chapter) Version

tech_support@nmss.com