3.1 Introduction

3.2 Configuring and Starting the System with oamsys

3.2.1 Creating a System Configuration File for oamsys

3.2.2 Running oamsys

3.3 Changing Configuration Parameters

3.3.1 Using Board Keyword Files

3.3.2 Specifying Configuration File Locations

3.4 Configuring Board Clocking

3.4.1 Clocking References

3.4.2 Clock Fallback

3.4.3 Clocking Capabilities

3.4.4 Configuring CT Bus Clocks with Board Keywords

3.4.5 Example: Multiple Board System

3.5 Configuring Ethernet Connections

3.5.1 Setting Up the Ethernet Connections

3.5.2 Using Redundant Ethernet Mode

3.5.3 Using Multiple Subnet Mode

3.6 Configuring the Host Network Driver

3.7 Configuring Multi-homed Configurations

3.7.1 Load Balancing in Dual Ethernet Configurations

3.7.2 UDP Port Numbers in Multi-homed Configurations

3.8 Monitoring Ethernet Link Status Events

3.9 Setting Up DSP Resource Management

3.9.1 Resource Management Keywords

3.9.2 Resource Definition String Syntax

3.9.3 DSP Files

3.9.4 Resource Definitions

3.9.5 Conditional Relationships Between DSP Functions

3.9.6 Echo Cancellation Restrictions

3.10 Sample Board Keyword Files

3.1 Introduction

This chapter

• Lists and describes the sample board keyword files installed with the
  CG 6000 board.

• Describes the CG 6000 system configuration file.

• Describes how to run oamsys to start all boards.

• Explains how to configure the Ethernet interface.

• Provides a summary of the CG 6000 keywords.

3.2 Configuring and Starting the System with oamsys

To configure and start the boards, you must specify configuration parameters in the board keyword file for each board. In board keyword files, you specify configuration parameters as a keyword name/value pair (for example,
Country = USA).

The easiest way to use the board keyword files is to use the oamsys utility supplied with the OAM service software. oamsys configures and starts the boards based on the parameters you specify in the system configuration file and the board keyword files.

Note: Applications can use OAM service functions to retrieve and modify configuration parameters. For more information, refer to the NMS OAM Service Developer's Reference Manual.

For information about the OAM service utilities, refer to the NMS OAM System User's Manual.

To configure a system using the oamsys utility:

1. Install the boards and software, as described in Chapter 2.

2. Create a CG 6000 board keyword file (or edit one of the sample CG 6000 board keyword files) that specifies appropriate configuration information for each board. For more information about board keyword files, refer to Section 3.3.1, Using Board Keyword Files.

3. Determine the PCI bus and slot locations of the boards, using the pciscan utility.
   You can use the pciscan utility to identify any NMS PCI boards installed in the system, and return each board's bus, slot, interrupt, and board type. For more information about pciscan, refer to the NMS OAM System User's Manual.

4. Create a system configuration file (or edit one of the sample CG 6000 system configuration files, oamsys.cfg or oam_tmpl.cfg) that points to all the board keyword files for your system. Specify a unique name and board number for each board. For more information about system configuration files, refer to Section 3.2.1, Creating a System Configuration File for oamsys.

5. Use oammon to monitor the OAM system and all NMS boards.

6. Use oamsys to start all installed boards (ctdaemon must be running when you use oamsys) according to the configuration information in the system configuration file and any associated board keyword files. For more information about oamsys, refer to Section 3.2.2, Running oamsys.

3.2.1 Creating a System Configuration File for oamsys

NMS OAM system configuration files reference all of the boards in your system. The system configuration file is typically named oamsys.cfg and located in the \nms\oam\cfg directory (opt/nms/oam/cfg for UNIX). When you start oamsys, it looks for a system configuration file named oamsys.cfg.

The following table describes the board-specific information included in the system configuration files:

Keyword	Description
[name]	The name of the board, to be used to refer to the board in software. The board name must be unique.
Product	The name of the board product. Use CG_6000_QUAD for CG 6000/3200-4T/E boards and CG_6000 for CG 6000/3200 boards.
Number	The board number you use in a Natural Access application to refer to the board.
Bus	The PCI bus number. The bus:slot location for each board must be unique. Obtain with pciscan.
Slot	The PCI slot number. The bus:slot location for each board must be unique. Obtain with pciscan.
File	The name of the board keyword file containing settings for the board. Several board keyword files are installed with the CG software, one for each country or region.

Refer to the NMS OAM System User's Manual for specific information about the syntax and structure of this file.

Sample System Configuration File

The following system configuration file provides configuration information for several CG 6000 boards on a particular chassis. Each board has a separate section delimited by a unique user-defined board name (in square brackets).

Modify the bus and slot numbers for each board to match your chassis configuration, and if necessary, add new entries for additional boards.

[Board_VT_C5420_0]
  Product = CG_6000_QUAD
  Number  = 0
  Bus     = 1
  Slot    = 7
      #-------------------------------------------------------------
      # Detailed board settings are in the following board keyword files.
      # Uncomment one of the following board keyword files,
      # or add a new one.  You may need to modify the board keyword file
      # for your particular application.
      #------------------------------------------------------------
File = c6nocc.cfg      # T1, no call control
#  File = c6wnk.cfg
#  File = c6fgd.cfg
#  File = c6gds.cfg
#  File = c6ops.cfg
#  File = c6ss5.cfg
#  File = cgi6t1.cfg
#  File = cgi6e1.cfg


#------------------------------------------------------
# Uncomment the following section to boot another board
#-------------------------------------------------------
#[BoardName1]
#  Product = CG_6000_QUAD
#  Number = 1
#  Bus    = 2
#  Slot   = 14
#  File   = c6nocc.cfg

3.2.2 Running oamsys

To run oamsys, enter the following command from the command line:

oamsys filename

where filename is the name of a system configuration file.

Note: If you invoke oamsys without command line options, NMS OAM searches for a file named oamsys.cfg in the paths specified in the AGLOAD environment variable.

When you invoke oamsys with a valid filename, oamsys performs the following tasks:

• Checks the syntax of the system configuration file to make sure that all required keywords are present. oamsys discards any unrecognized keywords and reports any syntax errors it finds.
  Note: oamsys verifies the file syntax of the system configuration file, but not of board keyword files.
• Checks for uniqueness of board names, board numbers, bus numbers, and slot numbers.

• Shuts down all boards recognized by NMS OAM (if any).

• Deletes all board configuration information currently maintained for the recognized boards (if any).

• Attempts to start all boards according to configuration parameters specified in the NMS OAM system configuration file and the board keyword files it references.

The Natural Access Server (ctdaemon) must be running for oamsys to operate. For more information about the Natural Access Server, refer to the Natural Access Developer's Reference Manual.

3.3 Changing Configuration Parameters

When you run oamsys, NMS OAM reads parameters provided in the board keyword files. NMS OAM then starts all boards according to these parameters.

You can change board keyword parameters in the following ways:

• Duplicate the sample board keyword file appropriate for your country and board type, modify the new file, specify the name of the new file in the File statement of the oamsys.cfg file, and run oamsys again. For more information about the syntax used in NMS OAM board keyword files, refer to the NMS OAM System User's Manual.

• Create a new board keyword file, either with additional keywords or keywords whose values override earlier settings.

• Specify parameter settings directly using the oamcfg utility. For more information about this utility, refer to the NMS OAM System User's Manual.

• Specify the settings using OAM service functions. For more information, refer to the NMS OAM Service Developer's Reference Manual.

For example, this manual describes how to change the following settings:

• T1 or E1 interface configuration (Section 2.4.4)

• Software module files downloaded to the board at startup (Section 3.3.2)

• CT bus clocking (Section 3.4)

• Ethernet interface configuration (Section 3.5 to Section 3.7)

• DSP resource configuration (Section 3.9)

• Board switching (Chapter 5)

3.3.1 Using Board Keyword Files

A sample set of board keyword files are installed by the CG 6000 software. Each board keyword file configures boards for a different digital protocol:

File	Description
c6fgd.cfg	120 ports of IVR with Feature Group D protocol
c6gds.cfg	120 ports of IVR with Ground Start protocol
c6nocc.cfg	120 ports of IVR with No Call Control
c6ops.cfg	120 ports of IVR with Off Station Premises protocol
c6ss5.cfg	120 ports of IVR with Signaling System 5 protocol
c6wnk.cfg	120 ports of IVR with Wink Start protocol
ci6t1.cfg	120 ports of IVR using an ISDN variant and a T1 interface
ci6e1.cfg	120 ports of IVR using an ISDN variant and an E1 interface
cinfas.cfg	120 ports of IVR using an ISDN variant to run NFAS (T1 only)

These board keyword files use many common keywords. For example, the Resource keyword strings used to set up resource management for CG boards (for 120 ports of IVR) are the same in all of these files.

Refer to Section 3.10.to view a sample board keyword file. For more information about board keyword files, refer to the NMS OAM System User's Manual.

3.3.2 Specifying Configuration File Locations

Some board keywords require file names as parameters. For example, the DLMFiles keyword specifies an optional runtime component file (also called a DLM file) to download to the CG board:

DLMFiles[ 1] = cg6kfusion

If the filename keyword value contains a path specification, NMS OAM searches for the file in the specified directory. If the file does not exist in the specified path or if the parameter does not specify a path, NMS OAM searches the current working directory and then the load_directory defined by the AGLOAD environment variable.

3.4 Configuring Board Clocking

When multiple boards are connected to the CT bus, you can set up a bus clock to synchronize timing between them. In addition, you can configure alternative (or fallback) clock sources to provide the clock signal if the primary source fails. For detailed information about clocking, refer to the NMS OAM System User's Manual.

Caution:

NMS strongly recommends that you do not mix H.100 systems with MVIP systems when doing clock fallback.

Refer to Section 3.4.3 for more information about clocking capabilities.

Boards in a CT bus system can be configured in one of the following modes:

Board Mode	Description
Primary clock master	Drives the primary timing reference for boards connected to the CT bus. It can switch between its two specified timing sources to maintain the primary timing reference. However, if both of its timing references fail, the primary clock master stops providing a timing source (and the secondary master then provides bus synchronization).
Secondary clock master	Drives the secondary timing reference. When the primary clock fails, the secondary master continues to drive the secondary clocks using a network timing source as its timing reference.
Clock slave	References its timing from the primary clock master, and uses the secondary clock master as a fallback source of clock timing.
Standalone	Does not reference the primary or secondary master, and consequently cannot make switch connections to the CT bus.

CT bus clock fallback establishes a redundant system of timing references for the CT bus. It does not create an autonomous clock timing environment. When clock fallback occurs, your application must intervene to reset system clocking before other clocking changes occur. If both the primary and secondary clock masters stop driving the clocks (and the application does not intervene), the boards default to standalone mode.

Certain board models have more flexible and reliable clocking capabilities than other models. In a mixed board system, choose the boards with the best capabilities as your primary master and secondary master. To determine which boards to use as masters, refer to the NMS OAM System User's Manual.

3.4.1 Clocking References

Primary clock masters can synchronize their own timing signals from the following sources:

• NETWORK

• NETREF

• OSC

Secondary clock masters are hybrid systems. The primary timing source must be A_CLOCK or B_CLOCK. Their fallback timing source must be one of the following sources:

• NETWORK

• NETREF

• OSC

For further information about configuring clocks on the H.100 bus, refer to the NMS OAM System User's Manual or the ECTF H.100 Hardware Compatibility Specification: CT Bus R1.0.

Clock slaves must use A_CLOCK or B_CLOCK as their primary timing source.

3.4.2 Clock Fallback

The CT bus supports a system of clock fallback that enables the system to use alternate timing references when one or more sources fail. To enable clock fallback, set Clocking.HBus.AutoFallBack=YES. If you do not enable clock fallback, the application must perform all clocking tasks.

Note: If you want to support clock fallback on a CG board, refer to the NMS web site (www.nmscommunications.com) for application notes and other updates.

To implement clock fallback:

1. Configure a primary clock master to drive the CT bus clock (A_CLOCK or B_CLOCK) based on a network timing reference. All slave boards synchronize their timing through this clock.

2. Configure a secondary clock master to use the signal from the primary clock to drive the alternate CT bus clock (in other words, if the primary master drives the A_CLOCK, configure the secondary master to drive the B_CLOCK based on the A_CLOCK, or vice versa).

3. Specify a fallback network timing reference for the secondary clock master to use in the event the primary clock master fails.

4. Configure all slave boards to specify the secondary clock master as the clock fallback source.

When the boards are configured in this way, the secondary clock master continues to drive the secondary clock (based on its own network timing reference) if the primary clock master fails. Slave boards within the system fall back to synchronize their timing from the secondary clock master.

3.4.3 Clocking Capabilities

This section describes the rules and limitations that apply to setting up CT bus clocking on CG 6000 boards.

When a CG 6000 board is configured as the system primary clock master:

• The board's first timing reference must be set to a network trunk, a NETREF clock, or OSC.

• The board's fallback timing reference must be set to a network trunk or a NETREF reference.

When a CG 6000 board is configured as the system secondary clock master:

• The board's first timing reference must be the system's primary clock.

• The board's fallback timing reference must be set to one of the network trunks, a NETREF source, or OSC.

When a CG 6000 board is configured as a clock slave:

• The board's first timing reference must be the system's primary clock.

• The board's fallback timing reference must be the system's secondary clock.

  Caution:

  When configured as clock slaves, CG boards cannot fall back to NETREF1.

• If there is no secondary clock for the system, the board's fallback timing reference must be set to OSC. In this case, if clock fallback occurs, the board will not be synchronized with the system until you reconfigure the board's clocking.

The following tables summarize the CT bus clocking capabilities of the CG board:

Clocking Capabilities as Primary Master

Capability	Yes/No	Comments
Serve as primary master	Yes
Drive A_CLOCK	Yes
Drive B_CLOCK	Yes
Available primary timing references:
Local trunk	Yes	The secondary timing reference must also be a local trunk.
NETREF1	Yes	The application must reconfigure the board as soon as possible if NETREF1 fails.
NETREF2	No	This board does not support NETREF2.
OSC	Yes
Fallback to secondary timing reference	Yes
Available secondary timing references:
Local trunk	Yes	This is the only valid reference if the primary timing reference is a local trunk.
NETREF1	No
NETREF2	No	This board does not support NETREF2.
OSC	No
Slave to secondary master if both references fail	Yes

Clocking Capabilities as Secondary Master

Capability	Yes/No	Comments
Serve as secondary master	Yes
Drive A_CLOCK	Yes	If the primary master drives B_CLOCK, the secondary master drives A_CLOCK.
Drive B_CLOCK	Yes	If the primary master drives A_CLOCK, the secondary master drives B_CLOCK.
Available secondary timing references:
Local trunk	Yes
NETREF1	Yes
NETREF2	No	This board does not support NETREF2.
OSC	Yes

Clocking Capabilities as Slave

Capability	Yes/No	Comments
Serve as slave	Yes
Slave to A_CLOCK	Yes
Slave to B_CLOCK	Yes
Available fallback timing references:
A_CLOCK	Yes
B_CLOCK	Yes
OSC	Yes	The board is not synchronized until the application reconfigures the clock.

Other Clocking Capabilities

Capability	Yes/No	Comments
Drive NETREF1	Yes
Drive NETREF2	No	This board does not support NETREF2.
Operate in standalone mode	Yes

3.4.4 Configuring CT Bus Clocks with Board Keywords

CG 6000 board keywords enable you to configure a board in the following ways:

• System primary clock master

• System secondary clock master

• Clock slave

• Standalone board

You can also use board keywords to establish clock fallback sources.

The following sections describe how to use board keywords to specify clocking configurations on multiple-board or multiple-chassis systems.

Configuring the Primary Clock Master

Use the following keywords to configure the primary clock master:

Keyword	Description
Clocking.HBus.ClockSource	Specifies the source from which this board derives its timing. Set this keyword to a network source (NETREF or NETWORK).
Clocking.HBus.ClockSourceNetwork	(optional) Specifies the number of a trunk that the board uses as an external network clocking source for its internal clock (trunk numbering is 1-based).
Clocking.HBus.ClockMode	Specifies the CT bus clock that the board drives. Set this keyword to reference either the A_CLOCK (MASTER_A) or the B_CLOCK (MASTER_B).
Clocking.HBus.AutoFallBack	Enables or disables clock fallback on the board.
Clocking.HBus.FallBackClockSource	Specifies an alternate timing reference to use when the master clock source fails. Set this keyword to a network timing source (NETREF or NETWORK).
Clocking.HBus.FallBackNetwork	(optional) Specifies the trunk from which a fallback network timing source (for the clock fallback reference) can be derived when Clocking.HBus.FallBackClockSource= NETWORK. Note: Trunk numbering in this case is 1-based.

Note: If the primary master's first source fails and then returns, the board's timing reference (and consequently, the reference for any slaves) switches back to the first timing source. This is not true for the secondary timing master.

Configuring the Secondary Clock Master

Use the following keywords to configure the secondary clock master:

Keyword	Description
Clocking.HBus.ClockSource	The source from which this board derives its timing. Set this keyword to the clock driven by the primary clock master. For example, if the primary master drives the A_CLOCK , set this keyword to A_CLOCK.
Clocking.HBus.ClockSourceNetwork	(optional) Specifies the number of a trunk that the board uses as an external network clocking source for its internal clock.
Clocking.HBus.ClockMode	Specifies the CT bus clock that the secondary master drives. Set this keyword to reference the clock (MASTER_A or MASTER_B) not driven by the primary clock master.
Clocking.HBus.AutoFallBack	Enables or disables clock fallback on the board. Set this keyword to YES.
Clocking.HBus.FallBackClockSource	Specifies an alternate timing reference to use when the master clock does not function properly. Set this keyword to reference a network source (NETREF or NETWORK).
Clocking.HBus.FallBackNetwork	(optional) The trunk from which a fallback network timing source (for the clock fallback reference) can be derived. Note: Trunk numbering in this case is 1-based.

Note: If the primary master's timing reference recovers, the secondary master continues to drive the clock referenced by all clock slaves on the system until the application intervenes.

Configuring Clock Slaves

Use the following keywords to configure the clock slaves:

Keyword	Description
Clocking.HBus.ClockMode	The CT bus clock from which the board derives its timing. Set this keyword to SLAVE to indicate that the board does not drive any CT bus clock (although the board can still drive NETREF).
Clocking.HBus.ClockSource	Specifies the source from which this clock derives its timing. This keyword must reference the clock driven by the primary clock master.
Clocking.HBus.AutoFallBack	Enables or disables clock fallback on the board.
Clocking.HBus.FallBackClockSource	Specifies the alternate clock reference to use when the master clock does not function properly. For clock slaves, set this keyword to reference the clock (A_CLOCK or B_CLOCK) driven by the secondary clock master.

Configuring Standalone Boards

To configure a board in standalone mode so the board references its own clocking information, set Clocking.HBus.ClockMode to STANDALONE. The board can use either its own oscillator or a signal received from a digital trunk as a timing signal reference. However, the board cannot make switch connections to the CT bus.

For more information about clocking, refer to the NMS OAM System User's Manual.

3.4.5 Example: Multiple Board System

The following example assumes a system configuration in which four CG 6000 boards reside in a single chassis. The boards are configured in the following way:

Board	Configuration
Board 0	System primary bus master (driving the A_CLOCK)
Board 1	System secondary bus master (driving the B_CLOCK)
Board 2	Clock slave (clock fallback enabled)
Board 3	Clock slave (clock fallback enabled - drives the NETREF clock)

This configuration assigns the following clocking priorities:

Timing Reference	Timing reference
First	Board 0, digital trunk 1. A network signal from a digital trunk provides the primary master clock source.
Second	Board 3, digital trunk 3. The NETREF signal driven by a digital trunk (on Board 3) acts as the primary master clock fallback source.
Third	Board 1, digital trunk 2. A network signal from a digital trunk provides the secondary master clock fallback source.

Figure 24 shows an example of a multi-board system with a primary and secondary clock master:

Figure 24. Sample Board Clocking Configuration

The following table shows keywords used to configure the boards according to the configuration shown in Figure 24.

Board	Role	Clocking Keyword Settings
0	Primary clock master	Clocking.HBus.ClockMode = MASTER_A Clocking.HBus.ClockSource = NETWORK Clocking.HBus.ClockSourceNetwork = 1 Clocking.HBus.AutoFallBack = YES Clocking.HBus.FallBackClockSource = NETREF Clocking.HBus.NetRefSpeed = 8K
1	Secondary clock master	Clocking.HBus.ClockMode = MASTER_B Clocking.HBus.ClockSource = A_CLOCK Clocking.HBus.AutoFallBack = YES Clocking.HBus.FallBackClockSource = NETWORK Clocking.HBus.FallBackNetwork = 2
2	Clock slave	Clocking.HBus.ClockMode = SLAVE Clocking.HBus.ClockSource = A_CLOCK Clocking.HBus.AutoFallBack = YES Clocking.HBus.FallBackClockSource = B_CLOCK
3	Slave driving NETREF	Clocking.HBus.ClockMode = SLAVE Clocking.HBus.ClockSource = A_CLOCK Clocking.HBus.AutoFallBack = YES Clocking.HBus.FallBackClockSource = B_CLOCK Clocking.HBus.NetRefSource = NETWORK Clocking.HBus.NetRefSourceNetwork = 3 Clocking.HBus.NetRefSpeed = 8K

In this configuration, Board 0 is the primary clock master and drives the A_CLOCK. All slave boards on the system use the A_CLOCK as their first timing reference. Board 0 references its timing from a network timing signal received on its own trunk 1. Board 0 also uses the NETREF signal (driven based on digital signal received on trunk 3 of Board 3) as its clock fallback source. In other words, if the network timing signal derived from its own digital trunks fails, Board 0 continues to drive the A_CLOCK based on NETREF timing reference.

If, however, both of the clocking signals used by Board 0 (the network timing signal and the NETREF signal) fail, then Board 0 stops driving the A_CLOCK. The secondary clock master (Board 1) then falls back to a timing reference received on its own trunk 3, and uses this signal to drive the B_CLOCK. The B_CLOCK then becomes the timing source for all boards that use the B_CLOCK as their backup timing reference.

For this configuration to take effect, all the clock slaves must specify the A_CLOCK as the clock source, and the B_CLOCK as the clock fallback clock source.

3.5 Configuring Ethernet Connections

The CG 6000 board has two 10/100Base-T Ethernet connections. The
CG 6000 Ethernet interfaces can be configured in several ways. This section describes the following configurations:

• Setting up generic Ethernet connections

• Configuring the interface in redundant Ethernet mode

• Configuring the interface multiple subnet mode

• Setting up multi-homed configurations

Use the following board keywords to configure the CG 6000 Ethernet interface:

Keyword	Description
IPC.AddRoute[x].DestinationAddress	Specifies the IP address of a CG 6000 board Ethernet interface. You can specify up to 32 destination addresses.
IPC.AddRoute[x].GatewayAddress	Specifies the IP address of the network router.
IPC.AddRoute[x].Interface	Specifies the number (1 or 2) of the Ethernet interface you are configuring.
IPC.AddRoute[x].Mask	Specifies the subnet mask for the IP address specified in IPC.AddRoute[x].DestinationAddress.

Note: For these keywords, x represents an entry in the routing table.

CG 6000 Ethernet interfaces must be configured for Fusion systems. For more information about Fusion software, configurations, and programming models, refer to the Fusion Developer's Manual.

3.5.1 Setting Up the Ethernet Connections

The IPC.AddRoute keywords are used to set the IP addressing and static IP routing table information for the CG 6000 board. You can configure up to 32 separate routing table entries for the CG 6000 board.

Depending upon the desired mode of operation, you can configure each Ethernet interface on the CG 6000 board with its own IP addressing information. To do this, specify the IP address, the IP subnet mask, and the particular Ethernet interface.

IP Addresses

To specify the IP address of an Ethernet interface on the CG 6000 board, define the following keywords:

IPC.AddRoute[x].DestinationAddress = [IP Address of Ethernet interface]
IPC.AddRoute[x].Mask          = [Subnet Mask for above IP Address]
IPC.AddRoute[x].Interface          = [Ethernet Interface # (1 or 2)]

Static IP Routes

In addition, the CG 6000 board enables you to configure multiple static IP routes by specifying the address of the router(s) on the IP subnet. Once it is configured, the static IP route manages the transfer of packets between the IP subnet associated with the CG 6000 board and the IP network. The IP stack on the CG 6000 board uses the standard IP routing algorithms to determine how to route outbound packets.

To specify a static IP route the CG 6000 board IP stack uses, define the following keywords:

IPC.AddRoute[x].DestinationAddress = [IP Address]
IPC.AddRoute[x].Mask          = [Subnet Mask for above IP Address]
IPC.AddRoute[x].GatewayAddress          = [IP Address of router]

Example

Normally, you configure the CG 6000 board by using a board keyword file and an NMS OAM utility (such as oamsys). The IPC.AddRoute statements in the CG 6000 board keyword file determine the IP addressing and gateway information for the CG 6000 board.

The following example shows how to use IPC.Addroute statements in the
CG 6000 board keyword file to specify the board's IP address, subnet mask, and gateway IP address:

#CG 6000 Board IP Address, subnet mask, and gateway IP address. 
IPC.AddRoute[0].DestinationAddress = 10.102.64.151 
IPC.AddRoute[0].Mask = 255.255.255.0
IPC.AddRoute[0].Interface = 1

#Gateway IP Address, subnet mask, and gateway IP address. 
IPC.AddRoute[1].DestinationAddress = 0.0.0.0
IPC.AddRoute[1].Mask = 0.0.0.0
IPC.AddRoute[1].GatewayAddress = 10.102.64.1

Note: In this example, the first three IPC entries specify the IP address and mask of the CG 6000 board. The second three entries configure the address of the gateway.

When you configure the board this way, the IP addressing and gateway configuration information for each CG 6000 board resides in the board keyword file. Each time you reboot the CG 6000 board with oamsys, oamsys reconfigures the IP addressing information for the specified board.

The cgroute utility provides an alternative way to configure specific IP addressing information without editing the CG 6000 board keyword file. cgroute is similar to the standard route utility found on most systems with IP processing capabilities. cgroute enables you to add, delete, and display routing information from the CG 6000 board. For more information about cgroute, refer to Appendix D.

3.5.2 Using Redundant Ethernet Mode

By default, the Ethernet subsystem on the CG 6000 board initializes in redundant Ethernet mode. In this mode of operation, Ethernet 1 provides the primary Ethernet connection and Ethernet 2 operates in a standby mode.

All IP configuration and routing information applies to both the primary and secondary Ethernet connections. If the primary connection loses link integrity, the secondary connection takes over. Once link integrity returns to the primary connection, all Ethernet traffic reverts to the primary Ethernet connection.

While in standby mode, the secondary Ethernet connection establishes link integrity, but remains passive. It does not send or receive packets to or from the IP network. When the primary connection loses link integrity, the secondary connection enables its transmitter and receiver and takes over for the primary connection. The fallback process is automatic, occurring in less than 1 ms, and is transparent to both the network and the application.

When you explicitly configure the secondary Ethernet connection with any IP addressing information, you disable the board's redundant Ethernet capability.

Example

The following example configures a CG 6000 board in redundant Ethernet mode. This example shows a CG 6000 board on a Class C subnet (198.62.139.x), with a single router providing access to the external IP network.

When you specify 0.0.0.0 as the router destination address and Subnet mask, the configuration specifies that all IP addresses not on the local subnet (198.62.139.x) are forwarded to the router 198.62.139.1 (typically referred to as the default route).

IPC.AddRoute[0].DestinationAddress = 198.62.139.32
IPC.AddRoute[0].Mask               = 255.255.255.0
IPC.AddRoute[0].Interface          = 1

IPC.AddRoute[1].DestinationAddress = 0.0.0.0
IPC.AddRoute[1].Mask               = 0.0.0.0
IPC.AddRoute[1].GatewayAddress     = 198.62.139.1

3.5.3 Using Multiple Subnet Mode

If you want to direct different types or classes of IP traffic to separate IP networks, you can associate each CG 6000 board Ethernet interface with a separate IP subnet. When you configure the secondary Ethernet connection with an IP address, the board operates in multiple subnet mode rather than redundant Ethernet mode.

Note: It is possible to configure both Ethernet connections on the same IP subnet, but this is not recommended. When configured in this manner, the CG 6000 board receives packets for both addresses. Based on standard IP routing practice, outbound packets take the first route found that matches. Therefore, the CG board sends all outbound packets to the Ethernet connection associated with the first IP address in the routing table.

Example

The following example shows how to configure a CG 6000 board in multiple subnet mode. Each Ethernet connection is configured for a separate Class C subnet, and each specifies a separate router. However, the second router is configured so that only IP addresses in the Class A subnet of 10.x.y.z are forwarded to the second router. All other external IP addresses are forwarded to the first router.

#  Specify IP address
IPC.AddRoute[0].DestinationAddress = 198.62.139.32
IPC.AddRoute[0].Mask               = 255.255.255.0
IPC.AddRoute[0].Interface          = 1

#  Specify route
IPC.AddRoute[1].DestinationAddress = 0.0.0.0
IPC.AddRoute[1].Mask               = 0.0.0.0
IPC.AddRoute[1].GatewayAddress     = 198.62.139.1

#  Specify IP address
IPC.AddRoute[2].DestinationAddress = 198.62.140.75
IPC.AddRoute[2].Mask               = 255.255.255.0
IPC.AddRoute[2].Interface          = 2

#  Specify route
IPC.AddRoute[3].DestinationAddress = 10.0.0.0
IPC.AddRoute[3].Mask               = 255.0.0.0
IPC.AddRoute[3].GatewayAddress     = 198.62.140.1

3.6 Configuring the Host Network Driver

On Windows NT systems, you can configure the CG board to operate as an Ethernet network interface card (NIC) for the host CPU. When configured in this way, the host network protocol stack views the board as a simple Ethernet NIC. Fusion software enables you to configure the CG 6000 board as a NIC card.

When the CG board is configured to operate as an Ethernet NIC, the board's IP configuration must match the IP configuration of the host CPU. The CG board network interface driver manages CG board IP configuration settings based on the host CPU configuration.

For example, in Windows NT, the network interface driver for the CG 6000 is the CG 6000 NDIS (Network Driver Interface Specification) driver. When you add the NDIS driver to the system, you can configure the host system IP addresses through the IP Address dialog of the Windows NT Network configuration applet (accessible through the Windows NT Control Panel).

Under Windows NT, you can use the Protocols dialog applet to configure IP addresses in the following modes:

IP Address Mode	Description
Static	Specify an IP address and gateway for the NIC. When using a statically configured IP address, the CG board NDIS driver reads the IP address and gateway configuration information from the Windows registry and automatically configures the board with this information each time the board boots.
Dynamic	Use DHCP (Dynamic Host Configuration Protocol) to assign the IP addresses for the board. DHCP is a protocol for assigning dynamic IP addresses to devices on a network. DHCP allows devices to use different IP addresses every time they connect to the network. When using dynamic addressing, the software keeps track of IP addresses rather than requiring an administrator to manage the task. When the host system uses DHCP, the CG board monitors the DHCP packets sent between the host CPU and the DHCP server. From the information in the DHCP packets, the board automatically sets its IP addressing and gateway information to the same values used by the host CPU.

When you install the CG board NDIS driver, the host operating system detects only the CG board's first Ethernet interface. If the CG board is configured in redundant Ethernet mode, the second Ethernet interface is transparent to the operating system, even if the second Ethernet interface is also available. In effect, the operating system regards the CG board as a single-interface NIC card. If the CG board is configured in dual subnet mode, the host detects only the CG board's first Ethernet interface and does not detect the boards's second Ethernet interface.

Note: If the host CPU has one or more available Ethernet connections, using the CG board as another Ethernet NIC adds little or no functionality to the system.

Since you can reset CG 6000 boards without also resetting the host CPU, the boards save DHCP configuration information in non-volatile RAM. Because the boards save this configuration information, CG 6000 boards can recover IP configuration information after being reset.

Caution:

If you remove the NDIS driver from the system, you must remove IP configuration information saved in non-volatile RAM. Use cgroute to remove this IP configuration information. If you do not remove this IP configuration information, unpredictable behavior may result. For more information about cgroute, refer to Appendix D.

Preventing UDP Port Conflicts

When you use CG boards to transfer RTP/RTCP data while simultaneously providing Ethernet NIC capabilities for the host IP stack, the host IP stack and the CG board's embedded IP stack typically use the same IP address. This occurs even though they are running separate IP stacks.

Conflicts can occur if you run an IP application that uses CG board resources (for example, a Fusion gateway application) while running a host-based IP application that uses the same UDP port number. When a conflict occurs, data received on the shared UDP port (in Fusion applications, by an RTP or UDP endpoint) is not forwarded through the NIC card interface to the host application.

To ensure that no conflicts occur when opening a UDP socket on the CG board, open a socket for the same UDP port on the host. When you open this socket, it reserves the associated UDP port number. Later, when the gateway application terminates the RTP session, close the socket associated with the host IP stack. When you avoid UDP port conflicts in this way, gateway applications can use the host IP stack to generate unique UDP port numbers for each RTP session without creating address conflicts.

Note: Gateway applications configured in this way must manage UDP port numbers so that no conflicts occur between the UDP port numbers associated with RTP/RTCP sessions and UDP port numbers used by host-based IP applications.

3.7 Configuring Multi-homed Configurations

On CG boards, each board Ethernet interface can be configured to a different IP subnet, and associated with a separate default router. This type of configuration is called a multi-homed configuration. Applications can use the Fusion MSPP service to direct the flow of data to the separate IP subnets associated with
multi-homed configurations.

The MSPP service enables applications to create MSPP endpoints that act as transmission and reception points for data at the CG board's network interfaces. Applications can join endpoints together with MSPP channels that perform processing tasks with voice or fax data as it moves from endpoint to endpoint. For more information about Fusion MSPP endpoints and channels, refer to the Fusion Developer's Manual.

In multi-homed configurations running Fusion gateways, applications can use the MSPP service to set endpoint address parameters (for RTP and UDP endpoints) that control the inbound demultiplexing and outbound routing behavior of the CG board IP stack. On an endpoint-by-endpoint basis, applications set the data transfer characteristics that apply to RTP or UDP sessions by setting the source IP addresses (specified through endpoint address parameters) of the RTP or UDP endpoints associated with these sessions. In this context, endpoint source IP addresses and destination IP addresses are oriented from the perspective of the CG board when transmitting data. That is, the source IP address is the IP address and port number of the local CG board, while the destination IP address is the IP address and port number of a remote system.

The following sections provide several examples of how applications can set up multi-homed configurations.

Note: RFC 1122 describes the requirements for multi-homed end systems (ES). It outlines two models for this type of system: the strong ES model and the weak ES model. For more information about the strong and weak ES models, refer to RFC 1122.

3.7.1 Load Balancing in Dual Ethernet Configurations

In multi-homed, multi-router configurations, applications can balance the amount of data transferred through each Ethernet interface by using the Fusion MSPP service to specify which Ethernet interface an RTP or UDP endpoint uses to transmit data. Applications specify which Ethernet interface to use by setting the endpoint source IP addresses to match the IP address assigned to one of the CG board's Ethernet interfaces.

In the following example, the CG board's NMS OAM board keyword file assigns IP addresses and subnet masks for each of the board's Ethernet interfaces, and defines default routes for these interfaces.

/* Ethernet #1: IP Address 198.62.139.27, Subnet 255.255.255.0 */
IPC.AddRoute[1].Interface = 1
IPC.AddRoute[1].DestinationAddress = 198.62.139.27
IPC.AddRoute[1].Mask = 255.255.255.0

/* Ethernet #2: IP Address 139.37.200.43, Subnet 255.255.255.0 */
IPC.AddRoute[2].Interface = 2
IPC.AddRoute[2].DestinationAddress = 139.37.200.43
IPC.AddRoute[2].Mask = 139.37.200.43

/* Default Route #1: 0.0.0.0/0.0.0.0 Router IP Address: 198.62.139.1 */
IPC.AddRoute[3].DestinationAddress = 0.0.0.0
IPC.AddRoute[3].Mask = 0.0.0.0
IPC.AddRoute[3].GatewayAddress = 198.62.139.1

/* Default Route #2: 0.0.0.0/0.0.0.0 Router IP Address: 139.37.200.1 */
IPC.AddRoute[4].DestinationAddress = 0.0.0.0
IPC.AddRoute[4].Mask = 0.0.0.0
IPC.AddRoute[4].GatewayAddress = 139.37.200.1

In this case, an application can implement load balancing by creating MSPP service endpoints in the following way:

• Creating an endpoint (RTP Endpoint 1) and specifying the following endpoint's source IP address:
  198.62.139.27

• Creating an endpoint (RTP Endpoint 2) and specifying the following endpoint's source IP address:
  139.37.200.43

Figure 25 shows the relationship between the RTP endpoints and the CG board's Ethernet interface:

Figure 25. Load Balancing at the Ethernet Interface

If the CG board is configured in redundant Ethernet mode, or if it does not matter which CG board Ethernet interface the application uses to transferring packet data, the application can set the endpoint source address parameter to 0.0.0.0. In this case, the CG board directs the outbound packets to the first valid route in its IP routing table.

Note: If the application specifies an invalid SourceIpAddress parameter, the CG board defaults to standard IP routing and sends the outbound packets to the first valid route found in the CG board's IP routing table.

3.7.2 UDP Port Numbers in Multi-homed Configurations

In a multi-homed IP environment, the application can treat the UDP port number range as a single port number domain or a multiple port number domain (qualified by the local IP address, or a combination of both of these). When the application creates RTP and UDP endpoints, the way the application sets endpoint source IP addresses determines whether the UDP port number uses a single port number domain or multiple port number domain.

• If the application sets the endpoint's source IP address to 0.0.0.0, then the IP address of any inbound RTP or UDP packets are not used to qualify the UDP Port number domain.

• If the application sets the endpoint's source IP address to an IP address corresponding to one of the CG board's Ethernet interfaces, then the destination IP address of any incoming packets is used to further qualify the RTP or UDP session to which the packet is bound.

3.8 Monitoring Ethernet Link Status Events

NMS OAM provides a way for applications to monitor board level events. The application must register with the OAM service before receiving NMS OAM events. Then the application can use the Natural Access function ctaWaitEvent to retrieve NMS OAM events. This function returns event information that describes which event occurred on which context.

In addition, the buffer field in NMS OAM events provides a pointer to an OAM_MSG structure that provides the following information:

typedef struct oam_msg_tag
{
    DWORD dwMsgLen;   // Msg length, including appended name & msg strings
    DWORD dwCode;     // Msg event code (use OAMEVN_xxx)
    DWORD dwSeverity; // Msg severity
    DWORD dwOfsSzName;// Offset to name string of source managed object
    DWORD dwOfsSzMessage; // Offset to text msg string
    DWORD dwValue;        // Possible additional event-specific data
         // string data is appended here
} OAM_MSG;

When state transitions occur at the CG board Ethernet interface (that is, when one of the Ethernet interfaces goes out of service or returns to service), the dwCode field of this structure contains an OAMEVN_ALERT message code. In addition, the dwValue field returns one of the following values:

dwValue	Description
IPMGR_ETH1_LINK_FAIL	The CG board Ethernet link 1 has gone out of service.
IPMGR_ETH1_LINK_ACTIVE	The CG board Ethernet link 1 has returned to service.
IPMGR_ETH2_LINK_FAIL	The CG board Ethernet link 2 has gone out of service.
IPMGR_ETH2_LINK_ACTIVE	The CG board Ethernet link 2 has returned to service.

For more information about processing OAM service events, refer to the NMS OAM Service Developer's Manual.

3.9 Setting Up DSP Resource Management

CG 6000 DSP resource management is configured to operate on a per-port basis. A port is associated with a circuit-switched call (for PSTN-based applications) or another type of media stream. DSP resource management determines the DSPs on which particular DSP functions run and can ensure that the DSP resources required to support a call are available when needed.

CG 6000 DSP programs are distributed in files known as Data Processing Modules (DPMs). Each of these files has a .f54 extention and contains executable code for an entire family of algorithms. Each algorithm in that family is known as a Data Processing Function (DPF) and can be referenced by a unique string generated by combining the DPM ID with a function ID string.

This section describes the keywords used to control DSP resource management on CG 6000 boards.

Caution:

The standard set of board keyword files provided with CG 6000 software (and Fusion software) contains DSP resource management settings suitable for most applications. Therefore, in most cases you do not need to modify these resource definitions. However, if your application requires resources not specified in the sample board keyword files, you may need to customize the CG 6000 DSP resource management settings. You should understand how the CG 6000 DSP resource manager allocates resources before modifying the standard DSP resource definitions. For more information about how CG 6000 resources are calculated and how to set up CG 6000 DSP resource management, refer to Appendix B.

3.9.1 Resource Management Keywords

The following keywords are used to configure CG 6000 board DSP resource management:

Keyword	Description
DSP.C5x[x].Files	Specifies the data processing function modules (DPMs) to load to a specified CG 6000 board DSP.
TCPFiles[x]	Specifies the trunk control programs (TCP) loaded to the board.
Resource[x].TCPs	Specifies the TCPs that the resource manager uses with the resource definition.
Resource[x].Name	Associates a name (character string) with a particular resource definition.
Resource[x].Definitions	Specifies a relational string of Data Processing Functions (DPFs), describes the functionality that can occur on a single port, and describes how and when functions execute in relation to each other.
Resource[x].Size	Specifies the number of channels or ports managed by the on-board resource manager.

The following sections describe in detail how to use the DSP.C5x[x].Files and Resource[x].Definitions keywords. For more information about these and other CG 6000 DSP resource management keywords, refer to Chapter 6.

3.9.2 Resource Definition String Syntax

When specifying resource definitions, you can use a set of logical operators in board keyword files to combine DPFs and define the relationships between them.

The following operators are supported in board keyword files:

Operator	Description
&	And
|	Exclusive Or
()	Inclusion and the beginning and end of the resource string
\	Line break

Note: Resource[x].Definitions strings always start with an open parenthesis, and end with a close parenthesis.

3.9.3 DSP Files

The DSP.C5x[x].Files keyword specifies the DPMs that are loaded to particular DSPs.

Note: In general, most configuration files load DSPs 1-31 with the same DSP files.

The CG 6000 DSP resource manager recognizes and manages only DPFs that are specified with the Resource[x].Definitions keyword. The DSP resource manager recognizes DPFs only if the DPMs in which they reside have been loaded to board DSPs. Load DPMs to the CG 6000 board by specifying the DPM name in a DSP.C5x[x].Files keyword string, where x represents a DSP or range of DSPs.

If the DSP resource manager is allocating resources, but finds that a DPF is not loaded to any DSP, it returns the error:
Board Error 0xa0e: Function 0xXXXX not found on any engine.

Where XXXX is the value of the DPF not found.

Example: Configuring Available DSP Resources

Use the DSP.C5x[x].Files keyword to load a particular DPMs functionality to specific DSPs on the CG 6000 board. Specify DPM files to load by using the following format:

DSP.C5x[x].Files = dpmfilename dpmfilename dpmfilename...

Where x refers to the DSP core, or a range of DSP cores, to load (there are 32 DSP cores on the CG 6000 board, so the value of x ranges from 0 to 31), and dpmfilename refers to a DPM to load to the corresponding DSP cores.

For example, the string

DSP.C5x[1,5,11].Files = echo dtmf

indicates to load cores DSP[1], DSP[5], and DSP[11] with the DPMs echo and dtmf.

You can also specify to load the DPM files to a range of DSPs, as in the following string:

DSP.C5x[1..31].Files = echo dtmf ptf

In this case, the string indicates to load cores DSP[1] through DSP[31] with the DPMs echo, dtmf, and ptf.

3.9.4 Resource Definitions

The following sections provide several examples of Resource[x].Definitions strings that use the DPFs echo.ln20_apt100, dtmf.det_all, ptf.det_2f, and voice.rec_32. These examples specify which DPFs run on a specific DSP, as well as the relationship between these DPFs (that is, which DPFs can run simultaneously and which cannot).

Example: All DPFs Running Exclusively

In the following example, all the DPFs specified in the resource definition string run exclusively (in other words, only one DPF can run at a time). In this case, set the Resource[x].Definitions keyword string to

Resource[0].Definitions = ( dtmf.det_all | ptf.det_2f | voice.rec_32)

Example: All DPFs Execute Simultaneously

In the following example, all of the DPFs specified in the resource definition string can run at the same time. In this case, set the Resource[x].Definitions keyword string to

Resource[0].Definitions = ( echo.ln20_apt100 & dtmf.det_all & \

ptf.det_2f & voice.rec_32 )

3.9.5 Conditional Relationships Between DSP Functions

The following examples specify conditional relationships between DPFs using the AND operator, OR operator, and parentheses to combine DPF string IDs. In these examples, some DPFs or groups of DPFs run simultaneously while others run exclusively.

Example 1

In the following example, any one OKI play DPF runs simultaneously with

• OKI record

• DTMF detection

• Echo cancellation

• Precise tone detection with two single frequencies

You can run simultaneous 24 kbit/s OKI ADPCM play and record functions by specifying the following Resource[x].Definitions string:

Resource[0].Definitions = ( dtmf.det_all & echo.ln20_apt25 &   \ 
ptf.det_2f & (( oki.rec_24 & (oki.play_24_100 | oki.play_24_150 | \  oki.play_24_200 ) ) )

This resource definition string reserves DSP resources so that one of the OKI play functions (oki.play_24_100, oki.play_24_150, or oki.play_24_200) runs simultaneously with the OKI record function (oki.rec_24).

Example 2

In this example, OKI play, OKI record, or tone functions run in the connected state, but not at the same time. Functions that execute simultaneously with OKI play, OKI record, or tone functions include

• DTMF detection

• Echo cancellation

• Precise tone detection with two single frequencies
  Note: In this example, the tone generator does not run if the OKI ADPCM play or record functions are running.

You can run a 24 kbit/s ADPCM OKI play function or a 24 kbit/s ADPCM OKI record function (a 24 kbit/s ADPCM OKI play function never runs at the same time as 24 kbit/s ADPCM OKI record function) by specifying the following Resource[x].Definitions string:

Resource[0].Definitions = ( dtmf.det_all & echo.ln20_apt25 & \ ptf.det_2f & ( oki.rec_24 | oki.play_24_100 | oki.play_24_150 \ |oki.play_24_200 | tone.gen ))

This resource definition string enables either the record functions, one of the play functions, or the tone generator to run at the same time as the DTMF detection, echo cancellation, and precise tone detection functions.

3.9.6 Echo Cancellation Restrictions

Only one echo canceller runs per call. Therefore, there should be only one occurrence of echo cancellation in the Resource[x].Definitions string.

3.10 Sample Board Keyword Files

The following sample configuration files are provided with Natural Access software.

E1 Configuration with ISDN

The following cgi6e1.cfg file is a sample board keyword file provided with Natural Access software. It is located in the \nms\cg\cfg (or opt/nms/cg/cfg for UNIX) subdirectory under the Natural Access installation directory. This file shows a typical set of board keywords necessary to configure and start a
CG 6000 board using ISDN and E1 line interfaces.

# cgi6e1.cfg
#               CG 6000 configuration file
#
# This file configures the board to run ISDN on E1.
#      
##
Clocking.HBus.ClockMode             = STANDALONE
Clocking.HBus.ClockSource             = OSC
Clocking.HBus.ClockSourceNetwork             = 1
TCPFiles             = nocc isd0
DSPStream.VoiceIdleCode[0..3]             = 0xD5                                                                                                         
DSPStream.SignalIdleCode[0..3]             = 0x0D                                                                                          
Hdlc[0,3,6,9].Boot             = YES
Hdlc[0,3,6,9].Comet.TxTimeSlot             = 16
Hdlc[0,3,6,9].Comet.RxTimeSlot             = 16
NetworkInterface.T1E1[0..3].Type             = E1
NetworkInterface.T1E1[0..3].Impedance             = G703_120_OHM
NetworkInterface.T1E1[0..3].LineCode             = HDB3
NetworkInterface.T1E1[0..3].FrameType             = CEPT
NetworkInterface.T1E1[0..3].SignalingType             = PRI
NetworkInterface.T1E1[0..3].D_Channel             = ISDN
DSP.C5x[0..31].Libs[0]             = cg6kliba 
DSP.C5x[0..31].XLaw             = A_LAW                                                                                 
DSP.C5x[1..31].Files             = voice tone dtmf echo \ rvoice callp ptf wave oki ima gsm_ms g726 mf
DSP.C5x[0].Files             = qtsignal tone dtmf echo \ NULL NULL NULL
Resource[0].Name             = RSC1
Resource[0].Size             = 120
Resource[0].TCPs             = nocc isd0
################################################################
# Before modifying this resource definition string refer to the CG6000 
# Installation and Developers Manual.
#################################################################
Resource[0].Definitions           = ( dtmf.det_all & echo.ln20_apt25 & \ ptf.det_2f & tone.gen & \
    callp.gnc & ptf.det_4f & \
    ( (rvoice.rec_mulaw & rvoice.play_mulaw) | \
    (rvoice.rec_alaw & rvoice.play_alaw) | \
    (rvoice.rec_lin & rvoice.play_lin) | \
    (voice.rec_16 & (voice.play_16_100 | voice.play_16_150 | \ voice.play_16_200)) | \
    (voice.rec_24 & (voice.play_24_100 | voice.play_24_150 | \ voice.play_24_200)) | \
    (voice.rec_32 & (voice.play_32_100 | voice.play_32_150 | \ voice.play_32_200)) | \
    (voice.rec_64 & (voice.play_64_100 | voice.play_64_150 | \ voice.play_64_200)) | \
    (wave.rec_11_16b & wave.play_11_16b) | \
    (wave.rec_11_8b & wave.play_11_8b) | \
    (oki.rec_24 & (oki.play_24_100 | oki.play_24_150 | oki.play_24_200)) | \
    (oki.rec_32 & (oki.play_32_100 | oki.play_32_150 | oki.play_32_200)) | \
    (ima.rec_24 & ima.play_24) | \
    (ima.rec_32 & ima.play_32) | \
    (gsm_ms.frgsm_rec & gsm_ms.frgsm_play) | \
    g726.rec_32 | g726.play_32) )

DLMFiles[0]           = cg6krun
DLMFiles[1]           = isdnetsi
# For USA ISDN configurations uncomment one of the DMSFile[1] keywords
#DLMFiles[1]           = isdnvn6
#DLMFiles[1]           = isdnqsig
#DLMFiles[1]           = isdnaus1
#DLMFiles[1]           = isdnkor
DebugMask           = 0x0

No Call Control Configuration

The following c6nocc.cfg file is a sample board keyword file provided with Natural Access software. It is located in the \nms\cg\cfg (or opt/nms/cg/cfg for UNIX) subdirectory under the Natural Access installation directory. It shows the set of board keywords necessary to configure and start a CG 6000 board.

#
#     c6nocc.cfg
#     CG 6000 configuration file
#
#     This file configures the board to run Voice with NOCC.
#

Clocking.HBus.ClockMode             = STANDALONE
Clocking.HBus.ClockSource             = OSC
Clocking.HBus.ClockSourceNetwork             = 1
TCPFiles             = nocc
DSPStream.VoiceIdleCode[0..3]             =  0x7F                                                                                                         
DSPStream.SignalIdleCode[0..3]              =  0x00                                                                                          
NetworkInterface.T1E1[0..3].Type             = T1
NetworkInterface.T1E1[0..3].Impedance             = DSX1
NetworkInterface.T1E1[0..3].LineCode             = B8ZS
NetworkInterface.T1E1[0..3].FrameType             = ESF
NetworkInterface.T1E1[0..3].SignalingType             = CAS
DSP.C5x[0..31].Libs[0]             = cg6klibu
DSP.C5x[0..31].XLaw             =   MU_LAW                                                                                 
DSP.C5x[1..31].Files             = voice tone dtmf echo \ rvoice callp ptf wave oki ima gsm_ms g726 mf
DSP.C5x[0].Files             = qtsignal tone dtmf echo \ 
callp NULL NULL
Resource[0].Name             = RSC1
Resource[0].Size             = 120
Resource[0].TCPs             = nocc
################################################################
# Before modifying this resource definition string refer to the CG6000 
# Installation and Developers Manual.
#################################################################
Resource[0].Definitions             = ( dtmf.det_all & \ echo.ln20_apt25 & 
ptf.det_2f & tone.gen & \
    callp.gnc & ptf.det_4f & \
    ( (rvoice.rec_mulaw & rvoice.play_mulaw) | \
    (rvoice.rec_alaw & rvoice.play_alaw) | \
    (rvoice.rec_lin & rvoice.play_lin) | \
    (voice.rec_16 & (voice.play_16_100 | voice.play_16_150 | \ voice.play_16_200)) | \
    (voice.rec_24 & (voice.play_24_100 | voice.play_24_150 | \ voice.play_24_200)) | \
   (voice.rec_32 & (voice.play_32_100 | voice.play_32_150 | \ voice.play_32_200)) | \
    (voice.rec_64 & (voice.play_64_100 | voice.play_64_150 | \ voice.play_64_200)) | \
(wave.rec_11_16b & wave.play_11_16b) | \
    (wave.rec_11_8b & wave.play_11_8b) | \
    (oki.rec_24 & (oki.play_24_100 | oki.play_24_150 | oki.play_24_200)) | \
    (oki.rec_32 & (oki.play_32_100 | oki.play_32_150 | oki.play_32_200)) | \
    (ima.rec_24 & ima.play_24) | \
    (ima.rec_32 & ima.play_32) | \
    (gsm_ms.frgsm_rec & gsm_ms.frgsm_play) | \
    g726.rec_32 | g726.play_32) )
DLMFiles[0]                                      = cg6krun
DebugMask                                        = 0x0