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 Natural Access service 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 service) is not concerned with what happens once the call is connected (for example, voice file playing/recording, sending or receiving faxes). In the NMS 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. Natural Access implements specific protocols through trunk control programs that run on NMS Communications 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 service is designed to be largely protocol-independent: applications use the same NCC service functions regardless of the protocol. However, an application can send protocol-dependent commands and information using the NCC service. For more information, see Protocol capabilities.
Most Natural 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. 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.
The following illustration shows the NCC service 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.