# Other components

In addition to the NMS ISDN software, you need the following components to build an NMS ISDN protocol application:

- One or more NMS T1 or E1 trunk interface boards

- Natural Access

Warning: | NMS Communications obtains board-level approvals certificates for supported countries. Some countries require that you obtain system-level approvals before connecting a system to the public network. To learn what approvals you require, contact the appropriate regulatory authority in the target country.

## Natural Access

Natural Access is a complete development environment for telephony applications. It provides a standard set of telephony functions grouped into logical services. Natural Access services provide functions for telephony-related tasks such as call control, tone generation and detection, and voice playing and recording.

The Natural Access Switching service controls switching on MVIP-compliant devices. You can use this service to make or break connections, send patterns, and sample data, among other tasks. This service supports both MVIP-95 and MVIP-90 specifications. Alternatively, you can use the swish utility to control switching interactively or in a batch mode.

For information about installing and using Natural Access, see the Natural Access documentation.

## Contexts and event queues

Natural Access organizes services and accompanying resources around a single processing unit called a context. To access service functionality, an application creates a context and attaches the services it requires. A context usually represents an application thread performing a related set of functions, such as controlling a single telephone call.

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

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

The Natural Access Server (ctdaemon) must be running for NMS OAM to be available. If ctdaemon is stopped, all dependent applications receive an error.

For detailed information about Natural Access, see the Natural Access Developer's Reference Manual.

## oamsys and the OAM configuration file

When you set up the system, specify a board keyword file for each board. This file specifies whether or not a board performs MVIP switching, which board is the MVIP clock master, which software modules to transfer to the board's memory on startup (including which TCPs to load), and other settings. An OAM system configuration file references these board keyword files.

Run oamsys to configure your boards based on the information in the OAM system configuration file and the board keyword files it references. oamsys transfers all software modules specified in the file to each board and performs any other configuration activities specified in the board keyword files. You can also start oammon to monitor the boards for errors and other events.

Use oamcfg to change system information or board parameters after the system is running. oamsys, oamcfg, and oammon are installed with Natural Access and require Natural Access to run in Server mode.

To learn how to modify NMS OAM board keyword and system configuration files to set up your NMS ISDN software, see the NMS ISDN Installation Manual and the NMS OAM System User's Manual