WARNING:	Natural MicroSystems obtains board-level approval certificates for supported countries. Some countries require that you obtain system-level approvals before connecting a system to the public telephone network. To learn what approvals you require, contact the appropriate regulatory authority in the target country.

1.4 About CAS Protocol Software

To communicate across a trunk line, parties must signal one another. The scheme used to signal across a telephone line is called a protocol. Many different protocol standards are in use throughout the world.
The AG CAS package includes: Analog and Digital Loop Start protocols (LPS) This protocol family includes protocols which use loop start signaling, where the presence or absence of current flow is interpreted by a switch as protocol signaling events. In the digital variations the loop current is represented by signaling bits variation. Operator Workstation protocol (STA) This protocol is the "other side" of the analog loopstart protocol. It is used to implement stations that connect to analog phones. Digital and Analog Wink Start protocol (WNK) This protocol family includes protocols used mainly in the USA on T1, DID analog, or E and M analog trunks . The protocol uses one-bit signaling (or presence or absence of current in the analog case), and owes its name to the "wink" (brief presence of current or variation of the signaling bit) that the inbound side uses to acknowledge line seizure. Register signaling is performed by in-band DTMF or MF tones, or by out-of-band decadic pulses. Multi-Frequency Compelled protocols based on the R2 standard (MFC) This protocol family includes the CCITT Signaling System R2 (Recommendations Q.421 to Q.442, CCITT Blue Book, 1988) implementation and numerous national variations. These protocols run on E1 trunks and use two-bit line signaling on the signaling channel associated with each voice channel, and in-band MF compelled register signaling. Ground Start protocol (GST) Natural MicroSystems ground start protocols cover digital interfaces, T1 trunks, connected to a private branch exchange (PBX) or PSTN switches. The protocol comes in two variations: FX (foreign exchange), and SA (special access). Pulsed E & M protocol (EAM) This protocol family includes country-specific protocols which use one-bit line signaling in a pulsed form, and variations on the compelled in-band MF register signaling specified by the CCITT in the 1988 Blue Book. These protocols run on E1 trunks and are specified in different countries by national regulatory agencies. European Digital Channel associated signaling protocol (EUC) This protocol family includes channel associated signaling protocols used in certain European countries. The protocols use two-bit line signaling specified by national standards for use over E1 trunks. The register signaling is either carried by in-band DTMF tones (not compelled) or by out-of-band decadic pulses. International Wink Start protocol (IWK) This protocol family includes country-specific variations of the US Wink Start protocol used on T1 trunks. The protocol uses one-bit signaling, and owes its name to the "wink" that the inbound side uses to acknowledge line seizure. Register signaling is performed by in-band DTMF or MF tones, or by out-of-band decadic pulses. Signaling System 5 protocol (SS5) This protocol is specified by the CCITT Recommendations Q.140 to Q.154 (CCITT Red Book, Volume VI Fascicle VI.2, Geneva 1985). The protocol uses in-band compelled signal frequency tones to perform line signaling and in-band MF tones for register signaling. Since no signaling bits are used, this protocol works the same way on T1 and E1 trunks. System R1.5 protocols (R15) This protocol family includes channel associated signaling protocols used for E1 lines in Russia (based on CCITT recommendations Q.511 and Q.544). The protocols use two-bit steady-state line signaling. Register signaling is either carried by in-band MF tones (MF acknowledged pulses) or by out-of-band decadic pulses. Two R15 protocol software modules are included with the NMS CAS software package. One is used (r150) for controlling inbound calls and the other (r151) is used for controlling outbound calls. MF-Socotel protocol (MFS) This protocol conforms to the Spanish National Specifications for Channel Associated Signaling over E1 trunks. It uses single bit steady-state line signaling, and MF-Socotel MF compelled in-band register signaling. Australian P2 protocols (AP2) This protocol is used in Australia for connections between PBX's and some PSTN carriers. It uses two-bits line signaling (derived from CCITT recommendation Q.421), and in-band DTMF register signaling.
Most of the protocols in these families have country-specific variations. NMS provides parameter files that determine how protocols interact with telephone networks in different countries. The package for each country contains software modules you need to download in order to enable telephony boards to communicate with telephone networks in that country.

1.4.1 Trunk Control Programs (TCPs)

Each protocol software package includes a trunk control program (TCP) that you load and configure in the on-board memory of a line interface board. The TCP performs all of the signaling to connect applications with a network that uses the target country's protocol.
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 are specified in the AG configuration file (described in Section 1.5). When you run the agmon board configuration and monitoring utility (described in Section 1.5.2), it downloads the specified TCPs to the board.

1.4.2 Parameter Files

In addition to the basic TCP software, each protocol software package contains binary parameter files (.pf files) that configure the TCP. Each country uses its own protocol implementation, and the parameter file configures the TCP for a specific country or network variation. CT Access applications load these parameters automatically at initialization time.
In most cases, the majority of the parameters specified in TCP parameter files cannot be changed without violating national regulatory laws. However, you can change a subset of these parameters based on the needs of your application. For more information about loading parameters, refer to Chapter 5. For information about parameters for each protocol, refer to Chapters 7 - 19.

WARNING:

You may only change a subset of parameters for each CAS protocol without effecting regulatory approvals.
Chapters 7 - 19 list all parameters for each protocol and indicate which parameters may be edited. Editing other parameters may result in violations of country-specific regulations.

WARNING:	You may only change a subset of parameters for each CAS protocol without effecting regulatory approvals. Chapters 7 - 19 list all parameters for each protocol and indicate which parameters may be edited. Editing other parameters may result in violations of country-specific regulations.

1.5 Software Requirements

In addition to the protocol software, you need CT Access software to build a CAS protocol application. CT Access is an NMS software development environment that contains: Application Programming Interfaces (APIs) that perform call control, play and record, and switching. agmon utility that loads and monitors AG board(s). Sample AG configuration files that specify configuration information for all AG boards in a system and is used by the agmon utility. Sample AG configuration files are supplied with CT Access and with your protocol software (see Chapter 3 for more information). Runtime software that provides the low-level on-board processing code required for operating AG boards. This software is transferred to the board by the agmon utility. The Runtime software consists of a coprocessor software (a core runfile), loadable modules and DSP files. Figure 1. AG Board Software Components

1.5.1 Application Programming Interface

Applications can control TCPs by using functions from the CT Access API. The CT Access API offers a complete development environment for telephony applications. It consists of a standard set of telephony functions grouped into logical services that perform call control, tone and DTMF generation/detection, and voice playing/recording.
CT Access communicates with TCPs in such a way that makes applications protocol-independent. Figure 2 shows how the components of a CT Access CAS protocol application relate to one another: Figure 2. Components of a Typical CAS Protocol Application

1.5.2 agmon and the AG Configuration File

When you set up your system, you specify configuration information for all boards in the system in an AG configuration file. This information includes: Whether a board performs MVIP switching Which board is the MVIP clock master What software modules to transfer to the board's memory on startup (including which TCPs to load)
Refer to Chapter 3 for more information about modifying your AG configuration file to set up your protocol software during board initialization.
Running the agmon utility configures your boards based on the information in the AG configuration file. agmon transfers to each board all software modules specified in the file, and performs any other configuration activities needed. It then monitors the boards for errors and other events. Whenever you make a change to your AG configuration file, launch agmon again to make these changes effective.

1.5.3 Runtime Software

Runtime software consists of the following modules: Software Module Function Core runfile Basic low-level processing code that runs on an on-board coprocessor. Run module Optional runtime components that are transferred to the board by agmon to provide additional functionality to the system. DSP program files Programs that run AG board on-board digital signal processors and perform particular tasks, such as DTMF signaling, and voice recording and playback.
Several runtime components and DSP files are installed with CT Access. When agmon runs, the runtime software is transferred from the host into on-board memory, and the board boots. The AG configuration file specifies which files to load.
For more information about runfiles, refer to the appropriate board installation and developer's manual or AG Runtime Configuration and Developer's Manual. For information about the DSP files shipped with CT Access, refer to the ADI Service Function Reference Manual.

Software Module	Function
Core runfile	Basic low-level processing code that runs on an on-board coprocessor.
Run module	Optional runtime components that are transferred to the board by `agmon` to provide additional functionality to the system.
DSP program files	Programs that run AG board on-board digital signal processors and perform particular tasks, such as DTMF signaling, and voice recording and playback.

1.6 Protocol Software Package Contents

The software package for a given country-specific protocol includes: One readme file (common for all protocols and countries) One or more trunk control programs (TCPs) One country-specific binary parameter file One or more SLAC files (for AG 2000 boards) One editable (ASCII) country-specific parameter file Sample country-specific agmon configuration files
Each installed protocol includes all of these components. When you install multiple protocols or install protocols for multiple countries, several versions of each component are created. Note: CT Access includes several call control demonstration programs that can use any of the AG CAS protocols to place or receive calls. Please refer to the ADI Service Developer's Manual for more information about running these programs.

1.7 About Trunk Control Programs (TCPs)

A trunk control program (TCP) is a script that is run by the on-board processor to implement a telephony protocol. TCPs are able to receive and place calls on both one-way and two-way trunks. CAS TCPs include the following: Protocol File name Loop Start lps0.tcp, lps8.tcp, lps9.tcp, Operator Workstation sta0.tcp Wink Start wnk0.tcp, wnk1.tcp, did0.tcp, did1.tcp, ogt0.tcp, ogt1.tcp Digital Ground Start gst8.tcp, gst9.tcp MFC-R2 mfc0.tcp Pulsed E and M eam0.tcp European Digital CAS euc0.tcp International Wink Start iwk0.tcp Signaling System 5 ss5.tcp System R1.5 (inbound) r150.tcp System R1.5 (outbound) r151.tcp MF-Socotel mfs0.tcp Australian P2 ap20.tcp

Protocol	File name
Loop Start	`lps0.tcp`, `lps8.tcp`, `lps9.tcp`,
Operator Workstation	`sta0.tcp`
Wink Start	`wnk0.tcp`, `wnk1.tcp`, `did0.tcp`, `did1.tcp`, `ogt0.tcp`, `ogt1.tcp`
Digital Ground Start	`gst8.tcp`, `gst9.tcp`
MFC-R2	`mfc0.tcp`
Pulsed E and M	`eam0.tcp`
European Digital CAS	`euc0.tcp`
International Wink Start	`iwk0.tcp`
Signaling System 5	`ss5.tcp`
System R1.5 (inbound)	`r150.tcp`
System R1.5 (outbound)	`r151.tcp`
MF-Socotel	mfs0.tcp
Australian P2	ap20.tcp

1.8 About Configuration and Parameter Files

The following sections summarizes the files that are used for board and protocol configuration, either by configuring the component to be loaded onto the board, or by defining parameter categories, or by providing a way to change the values of the protocol parameters. These files include: AG configuration files Binary parameter category definition files Parameter value definition files SLAC files
This chapter uses the following parameter file naming conventions:

Abbreviation

Description

<prt>

Protocol identifier (3 characters)

<cty>

Country abbreviation (3 characters)

<pp>

Product identifier (board, 2 characters)

<ss>

Signaling type (for analog boards, 2 characters)

<i>

Line impedance (for analog boards, 1 character)

WARNING:

You may only change a subset of protocol parameters without effecting regulatory approvals. Chapter 7 - 19 list parameters for each protocol and indicate which parameters may be edited. Editing other parameters may result in violations of country-specific regulations.

Abbreviation	Description
<prt>	Protocol identifier (3 characters)
<cty>	Country abbreviation (3 characters)
<pp>	Product identifier (board, 2 characters)
<ss>	Signaling type (for analog boards, 2 characters)
<i>	Line impedance (for analog boards, 1 character)

WARNING:	You may only change a subset of protocol parameters without effecting regulatory approvals. Chapter 7 - 19 list parameters for each protocol and indicate which parameters may be edited. Editing other parameters may result in violations of country-specific regulations.

1.8.1 About AG Configuration and Parameter Files

AG configuration files contain information that determines how agmon sets up AG boards. These files also contain country-specific information for different protocols. File name Location Description ag<prt>.cfg Windows NT: \nms\ag\cfg UNIX: /opt/nms/ag/cfg The default example AG configuration file to configure one board with all the modules and settings to run the protocol <prt>. It reflects the last country installed in the system for the protocol <prt>. For AG-8, AG-T1, AG-E1, AG 2000. ag<prt><cty>.cfg Windows NT: \nms\ag\cfg\country UNIX: /opt/nms/ag/cfg/country The example AG configuration file to configure one board with all the modules and settings to run the protocol <prt> in the country <cty>. A different file is installed for each country. For AG-8, AG-T1, AG-E1, AG 2000. q<prt>.cfg Windows NT: \nms\ag\cfg UNIX: /opt/nms/ag/cfg The default example AG configuration file to configure one board with all the modules and settings to run the protocol <prt>. It reflects the last country installed in the system for the protocol <prt>. For AG Quad and Dual T1 and AG Quad and Dual E1. q<prt><cty>.cfg Windows NT: \nms\ag\cfg\country UNIX: /opt/nms/ag/cfg/country The example AG configuration file to configure one board with all the modules and settings to run the protocol <prt> in the country <cty>. A different file is installed for each country. For AG Quad and Dual T1 and AG Quad and Dual E1. a4<prt>.cfg Windows NT: \nms\ag\cfg UNIX: /opt/nms/ag/cfg The default example AG configuration file to configure one board with all the modules and settings to run the protocol <prt>. It reflects the last country installed in the system for the protocol <prt>. For AG 4000 boards. a4<prt><cty>.cfg Windows NT: \nms\ag\cfg\country UNIX: /opt/nms/ag/cfg/country The example AG configuration file to configure one board with all the modules and settings to run the protocol <prt> in the country <cty>. A different file is installed for each country. For AG 4000 boards.
For more information about AG configuration files, refer to the AG Runtime Configuration and Developer's Manual. For information about configuring this file for your protocol setup, refer to Chapter 3 of this manual.

File name	Location	Description
`ag<`prt`>.cfg`	Windows NT: `\nms\ag\cfg` UNIX: `/opt/nms/ag/cfg`	The default example AG configuration file to configure one board with all the modules and settings to run the protocol <prt>. It reflects the last country installed in the system for the protocol <prt>. For AG-8, AG-T1, AG-E1, AG 2000.
`ag<`prt`><`cty`>.cfg`	Windows NT: `\nms\ag\cfg\country` UNIX: `/opt/nms/ag/cfg/country`	The example AG configuration file to configure one board with all the modules and settings to run the protocol <prt> in the country <cty>. A different file is installed for each country. For AG-8, AG-T1, AG-E1, AG 2000.
`q`<prt>`.cfg`	Windows NT: \nms\ag\cfg UNIX: /opt/nms/ag/cfg	The default example AG configuration file to configure one board with all the modules and settings to run the protocol <prt>. It reflects the last country installed in the system for the protocol <prt>. For AG Quad and Dual T1 and AG Quad and Dual E1.
`q`<prt><cty>.`cfg`	Windows NT: \nms\ag\cfg\country UNIX: /opt/nms/ag/cfg/country	The example AG configuration file to configure one board with all the modules and settings to run the protocol <prt> in the country <cty>. A different file is installed for each country. For AG Quad and Dual T1 and AG Quad and Dual E1.
`a4<`prt`>.cfg`	Windows NT: `\nms\ag\cfg` UNIX: `/opt/nms/ag/cfg`	The default example AG configuration file to configure one board with all the modules and settings to run the protocol <prt>. It reflects the last country installed in the system for the protocol <prt>. For AG 4000 boards.
`a4<`prt`><`cty`>.cfg`	Windows NT: `\nms\ag\cfg\country` UNIX: `/opt/nms/ag/cfg/country`	The example AG configuration file to configure one board with all the modules and settings to run the protocol <prt> in the country <cty>. A different file is installed for each country. For AG 4000 boards.

1.8.2 Binary Parameter Category Definition Files

Binary parameter files contain the complete set of country-specific parameters and default values. These files are loaded by CT Access at initialization time. There are two types of binary parameter category definition files: File name Location Description adi<prt>.pf Windows NT: \nms\ag\cfg UNIX: /opt/nms/ag/cfg This file defines the CT Access parameter category ADI.<prt>. This category holds all protocol-specific parameters for the <prt> protocol. The parameter default values defined by this files program the TCP implementing the protocol <prt> for the last country installed. Installing another country variation of the protocol <prt> overwrites this file. <prt><cty>.pf Windows NT: \nms\ag\cfg\country UNIX: /opt/nms/ag/cfg/country This file is a backup of the previous one. It defines the parameters for the category ADI.<prt>, for the country <cty>. If more than one country variation is installed for the protocol <prt>, there are multiple <prt><cty>.pf files, one for each country.
For more information about editable parameters for each CAS protocol, refer to Chapters 7 - 19.

File name	Location	Description
`adi<`prt`>.pf`	Windows NT: `\nms\ag\cfg` UNIX: `/opt/nms/ag/cfg`	This file defines the CT Access parameter category ADI.<prt>. This category holds all protocol-specific parameters for the <prt> protocol. The parameter default values defined by this files program the TCP implementing the protocol <prt> for the last country installed. Installing another country variation of the protocol <prt> overwrites this file.
`<`prt`><`cty`>.pf`	Windows NT: `\nms\ag\cfg\country` UNIX: `/opt/nms/ag/cfg/country`	This file is a backup of the previous one. It defines the parameters for the category ADI.<prt>, for the country <cty>. If more than one country variation is installed for the protocol <prt>, there are multiple <prt><cty>`.pf` files, one for each country.

1.8.3 ASCII Parameter Value Definition Files

ASCII parameter value definition files can be used to reset the values of the country specific parameters. Some of the parameters values may be changed without affecting the regulatory approvals in the target country. There are two types of ASCII parameter value definition files: File name Location Description adi<prt>.par Windows NT: \nms\ctaccess\cfg UNIX: /opt/nms/ctaccess/cfg This file contains the values of all the parameters of the category ADI.<prt>. The parameters are divided into two classes: · Those that can be changed by the user to fit the applications needs · Those that should not be changed because have regulatory relevance. The file contains the parameter values for the last country variation installed for the protocol <prt>, and is overwritten with each new installation of <prt>. This file can be used to set the parameters values system-wide, using the CT daemon, or it can be parsed by the application for dynamical parameter management via the relevant CT Access functions. <prt><cty>.par Windows NT: \nms\ctaccess\cfg\country UNIX: /opt/nms/ctaccess/cfg/country This file is a backup of the previous one. It contains the parameter values for the category ADI.<prt>, for the country <cty>. If more than one country variation is installed for the protocol <prt>, there are multiple <prt><cty>.par files, one for each country.
For more information about editable parameters for each CAS protocol, refer to Chapters 7 - 19.

File name	Location	Description
`adi<`prt`>.par`	Windows NT: `\nms\ctaccess\cfg` UNIX: `/opt/nms/ctaccess/cfg`	This file contains the values of all the parameters of the category ADI.<prt>. The parameters are divided into two classes: · Those that can be changed by the user to fit the applications needs · Those that should not be changed because have regulatory relevance. The file contains the parameter values for the last country variation installed for the protocol <prt>, and is overwritten with each new installation of <prt>. This file can be used to set the parameters values system-wide, using the CT daemon, or it can be parsed by the application for dynamical parameter management via the relevant CT Access functions.
`<`prt`><`cty`>.par`	Windows NT: `\nms\ctaccess\cfg\country` UNIX: `/opt/nms/ctaccess/cfg/country`	This file is a backup of the previous one. It contains the parameter values for the category ADI.<prt>, for the country <cty>. If more than one country variation is installed for the protocol <prt>, there are multiple <prt><cty>`.par` files, one for each country.

1.8.4 SLAC Files

SLAC files contain information that must be loaded into the QSLAC devices of AG 2000 boards so that the board line interface is appropriate for country-specific line conditions.
For more information about the SLAC files refer to AG 2000 Installation and Developer Manual. Refer to Appendix C for the list of SLAC files available for different countries. File name Location Description <pp><cty><ss><i>.slc Windows NT: \nms\ag\load UNIX: /opt/nms/ag/load File that programs the QSLAC devices on <pp> boards to implement the analog specifications of country <cty>, for the signaling protocol <ss> and with a line impedance <i>. Only one file per configuration is installed. SLAC files are referenced by the AG configuration files installed for the signaling protocol <ss> in country <cty>.

File name	Location	Description
`<`pp`><`cty`><`ss`><`i`>.slc`	Windows NT: `\nms\ag\load` UNIX: `/opt/nms/ag/load`	File that programs the QSLAC devices on <pp> boards to implement the analog specifications of country <cty>, for the signaling protocol <ss> and with a line impedance <i>. Only one file per configuration is installed. SLAC files are referenced by the AG configuration files installed for the signaling protocol <ss> in country <cty>.

(Page 1 of 1 in this chapter)

tech_support@nmss.com