Call control, an essential part of telephony applications, provides a telephony network connection between two endpoints so that a telephone call can proceed. NCC is a NaturalAccess API for writing applications that perform call control.
Call control features include:
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
Call control (and therefore the NCC API) is not concerned with what happens once the call is connected (for example, voice file playing/recording, sending or receiving faxes). In the NaturalAccess model, telephony switching is outside the realm of call control, although switching may occur during call control.
Call control can be conducted in a variety of ways depending on the protocol that is running on the system. NaturalAccess implements specific protocols through trunk control programs that run on AG Series and CG Series board DSPs.
Call control is implemented differently in different situations, depending upon characteristics such as the network type and country. Each specific implementation of call control is called a protocol. Protocols are typically subdivided into groups based on signaling method (CAS, ISDN, SS7). Within each group, there are sub-groups, or variants such as loop start, MFC-R2, and 4ESS. The NCC API is designed to be largely protocol-independent: applications use the same NCC functions regardless of the protocol. However, an application can send protocol-dependent commands and information using the NCC API. For more information, see Protocol capabilities.
Most NaturalAccess APIs interact with telephony hardware in some fashion. For example, the Switching API controls the H.100 or MVIP switching chip on a telephony board. The Voice Message API uses a board's DSP resources to play and record files. The NCC API 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 API to interact with hardware differs depending upon the implementation. For example, with the 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 API in a protocol-specific manner, and translating protocol-specific trunk events and errors into standard NCC API events.
The following illustration shows the NCC API interacting with hardware:
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 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 nccQueryCapability. For more information, see Protocol capabilities.