3.1 Introduction

3.2 Adding Board Configurations to the NMS OAM Database

3.3 Configuring and Starting the System with oamsys

3.3.1 Creating a System Configuration File for oamsys

3.3.2 Running oamsys

3.4 Changing Configuration Parameter Settings

3.4.1 Using Board Keyword Files

3.4.2 Specifying Configuration File Locations

3.5 Configuring Board Clocking

3.5.1 Clocking References

3.5.2 Clock Fallback

3.5.3 Clocking Capabilities

3.5.4 Configuring CT Bus Clocks with Board Keywords

3.5.5 Example: Multiple Board System

3.6 Configuring Ethernet Connections

3.6.1 Setting Up the Ethernet Connections

3.6.2 Using Redundant Ethernet Mode

3.6.3 Multiple Subnet Mode

3.7 Configuring the Host Network Driver

3.8 Configuring Multi-homed Configurations

3.8.1 Load Balancing in Dual Ethernet Configurations

3.8.2 UDP Port Numbers in Multi-homed Configurations

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 Specifying Conditional Relationships Between DSP Functions

3.9.6 Echo Cancellation Restrictions 3.10 Sample Board Keyword Files 90

3.9.6 Echo Cancellation Restrictions

3.10 Sample Board Keyword Files E1 Configuration with ISDN 89

No Call Control Configuration 91

3.1 Introduction

This chapter:

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

• Describes the CG 6000C system configuration file

• Describes how to run the oamsys utility to start all boards

• Explains how to configure the CG 6000C Ethernet interface

• Provides a summary of the CG 6000C keywords

3.2 Adding Board Configurations to the NMS OAM Database

To configure and start your boards appropriately, you must specify configuration parameters in q NMS OAM board keyword file for each board. In board keyword files you specify configuration parameters in keyword name/value pairs (for example, Country = USA).

The easiest way to update NMS OAM with board keyword file information is to use the oamsys utility supplied with the NMS OAM software. oamsys configures and starts boards based on the parameters specified in a system configuration file and 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 more about NMS OAM utilities, refer to the NMS OAM System User's Manual.

3.3 Configuring and Starting the System with oamsys

To configure a system with the oamsys utility:

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

2. Create a CG 6000C board keyword file (or edit one of the sample CG 6000C board keyword files) that specifies appropriate configuration information for each board.

3. Determine the Compact PCI bus and slot locations of the boards, using the pciscan utility.

4. Create a system configuration file (or edit a sample system configuration file) that points to all the board keyword files for your system. Specify a unique name and board number for each board.

5. Use oamsys to start all the installed boards (ctdaemon must be running when you use oamsys) according to the configuration information specified in the NMS OAM system configuration file and any associated board keyword files.

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.

3.3.1 Creating a System Configuration File for oamsys

NMS OAM system configuration files reference all of the boards in your system. System configuration files are 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 chart shows board-specific information included in NMS OAM 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 (for CG 6000C boards, this is CG_6000C_QUAD).
Number	The board number Natural Access associates with 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 NMS OAM system configuration file.

Sample System Configuration File

The following sample system configuration file provides configuration information for several CG 6000C 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 values appropriately for each board to match your chassis configuration and, if necessary, add new entries for additional boards.

[Board_VT_C5420_0]
  Product = CG_6000C_QUAD
  Number  = 0
  Bus     = 1
  Slot    = 7
      #-------------------------------------------------------------
      # 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_6000C_QUAD
#  Number = 1
#  Bus    = 2
#  Slot   = 14
#  File   = c6nocc.cfg

3.3.2 Running oamsys

To run oamsys, enter the following at the command line.

oamsys filename

Where filename is the name of an NMS OAM 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 system configuration files, but not for board keyword files.
• Checks for uniqueness of board names, board numbers and board bus/slot numbers.

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

• Deletes all board configuration information currently maintained for the recognized boards (if there is 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.4 Changing Configuration Parameter Settings

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

There are several ways to change board keyword parameters:

• 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 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:

• T1or E1 interface configuration (Section 2.4.1)

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

• CT bus clocking (Section 3.5)

• Ethernet interface configuration (Section 3.6 to Section 3.8)

• DSP resource configuration (Section 3.9)

• Board switching (Chapter 5)

3.4.1 Using Board Keyword Files

The following board keyword files are provided with the CG 6000C software. Each board keyword file configures boards for a different digital protocol:

File	Description
c6fgs.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 OAM service board keyword file. For more information about board keyword files, refer to the NMS OAM System User's Manual.

3.4.2 Specifying Configuration File Locations

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

For example:

DLMFiles[ 1] = /nms/fusion/config/cg6kfusion

If the filename keyword string specifies a path name, 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.5 Configuring Board Clocking

When multiple boards are connected to the CT bus, you must 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 or H.110 systems with MVIP systems when doing clock fallback.

Refer to Section 3.5.3 for more information about clocking capabilities.

Boards in a CT bus system can be configured 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 in order 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.

For information about the clocking capabilities that apply to configuring CT bus clocking with CG 6000C boards, refer to Section 3.5.3.

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, you must intervene to reset system clocking before all of the specified fallback timing references are exhausted. If all of the timing references specified for the primary and secondary clock masters fail (and no intervention takes place), boards on the system default to standalone mode.

3.5.1 Clocking References

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

• NETWORK

• NETREF

• NETREF2

• OSC

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

• NETWORK

• NETREF

• NETREF2

• OSC

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

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

3.5.2 Clock Fallback

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

To implement fallback clocking:

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 will 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 if the primary clock master fails.

4. Configure all slave boards to specify the secondary clock master as their 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.

For more information about the clocking capabilities that apply to setting up clocking on CG 6000C boards, refer to Section 3.5.3.

3.5.3 Clocking Capabilities

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

When an CG 6000C 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 6000C board is configured as the system secondary clock master:

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

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

When an CG 6000C 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 fallback 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 CG board CT bus clocking capabilities:

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
NETREF1	Yes
NETREF2	Yes
OSC	Yes
Fallback to secondary timing reference	Yes
Available secondary timing references:
Local trunk	Yes
NETREF1	Yes
NETREF2	Yes
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	Yes
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	This board can drive either NETREF1 or NETREF2, but not both at once.
Drive NETREF2	Yes	This board can drive either NETREF1 or NETREF2, but not both at once.
Operate in standalone mode	Yes

3.5.4 Configuring CT Bus Clocks with Board Keywords

CG 6000C board keywords allow 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 the system wide clocking configuration in a multiple-board or multiple-chassis system.

Configuring the Primary Clock Master

Use the following board 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, NETREF2, 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, NETREF2, 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 board 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 the 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, NETREF2, 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 slave boards on the system until the application intervenes.

Configuring Clock Slaves

Use the following board keywords to configure 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 may still drive NETREF or NETREF2).
Clocking.HBus.ClockSource	Specifies the source from which this clock derives its timing. Set this keyword to 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. 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.

3.5.5 Example: Multiple Board System

The following example assumes a system configuration in which four CG 6000C boards reside on 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:

Priority	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 21 shows an example of a multi-board system with a primary and secondary clock master:

Figure 21. Sample Board Clocking Configuration

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

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. This means that if the network timing signal derived from its own digital trunks fails, Board 0 will continue to drive the A clocks 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.

Note: For this to take effect, all the clock slaves must specify the A clocks as their clock source, and the B clocks as their clock fallback source.

3.6 Configuring Ethernet Connections

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

• Setting up basic 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 6000C Ethernet interface:

Keyword	Description
IPC.AddRoute[x].DestinationAddress	Specifies the IP address of a CG 6000C 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 6000C 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.6.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 6000C board. You can configure up to 32 separate routing table entries for the CG 6000C board.

Depending upon the desired mode of operation, you can configure each Ethernet interface on the CG 6000C 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 6000C, 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 6000C board allows you to configure multiple static IP routes by specifying the address of a router(s). Once it is configured, the static IP route manages the transfer of packets between the IP subnet associated with the
CG 6000C board and the IP network. The IP stack on the CG 6000C board uses standard IP routing algorithms to determine how to route outbound packets.

To specify a static IP route that the CG 6000C 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 6000C board by using a board keyword file and an NMS OAM utility (such as oamsys). The IPC.AddRoute statements in the
CG 6000C board keyword file determine the IP addressing and gateway information for the CG 6000C board.

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

#CG 6000C 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 6000C 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 6000C board resides in the board keyword file. Each time you reboot the CG 6000C 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 6000C board keyword file. cgroute is similar to the standard route utility found on most systems with IP processing capabilities. cgroute allows you to add, delete, and display routing information from the CG 6000C board. For more information about cgroute, refer to the Appendix D.

3.6.2 Using Redundant Ethernet Mode

By default, the Ethernet subsystem on the CG 6000C 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 connection. If the primary connection loses link integrity, the secondary connection takes over. Once link integrity returns to the primary connection, all Ethernet traffic converts back 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 6000C board in redundant Ethernet mode. This example shows a CG 6000C 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, this 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.6.3 Multiple Subnet Mode

If you want to direct different types or classes of IP traffic to separate IP networks, you can associate each CG 6000C 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 into the same IP subnet, but this is not recommended. When configured in this manner, the CG 6000C board receives packets for both addresses. Based on standard IP routing practice, outbound packets take the first route 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 6000C board in multiple subnet mode. Each Ethernet interface 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.7 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 6000C 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 6000C is the CG 6000C 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 within the IP Address 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 NT 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.

Note: If the host CPU in a Compact PCI system 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 6000C 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 6000C 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 A.

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.8 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 accomplishing this, the strong ES model and the weak ES model. For more information about the strong and weak ES models, refer to RFC 1122.

3.8.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 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 = 198.62.139.27
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 22 shows the relationship between the RTP endpoints and the CG board's Ethernet interface:

Figure 22. 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.8.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.9 Setting Up DSP Resource Management

CG 6000C 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 6000C DSP programs are distributed in files called Data Processing Modules (DPMs). Each of these files has an .f54 extension 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 6000C boards.

Caution:

The standard set of board keyword files provided with CG 6000C 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 6000C DSP resource management settings. You should understand how the CG 6000C DSP resource manager allocates resources before modifying the standard DSP resource definitions. For more information about how CG 6000C resources are calculated and how to set up CG 6000C DSP resource management, refer to Appendix B.

3.9.1 Resource Management Keywords

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

Keyword	Description
DSP.C5x[x].files	Specifies the data processing function modules (DPMs) to load to a specified CG 6000C board DSP.
TCPFiles[x]	Specifies the trunk control programs (TCP) loaded to the board.
Resource[x].TCPs	Specifies the TCPs 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 6000C 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 define the relationships between DPFs

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 6000C DSP resource manager recognizes and manages only DPFs that are specified with the Resource[x].Definitions keyword. The DSP resource manager recognizes only DPFs if the DPMs in which they reside have been loaded to board DSPs. Load DPMs to the CG 6000C 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 board error:
Board Error 0xa0e: Function 0xXXXX not found on any engine.

Where XXXX is the value of the DFF not found.

Example: Configuring Available DSP Resources

Use the DSP.C5x[x].Files keyword to load a particular DPM to specific DSPs on the CG 6000C 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 6000C 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:

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 can not).

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, you would set the Resource[x].Definitions keyword string to:

Resource[1].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, you would set the Resource[x].Definitions keyword string to:

Resource[1].Definitions = ( echo.ln20_apt100 & dtmf.det_all & \
     ptf.det_2f & voice.rec_32 )

3.9.5 Specifying 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[1].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[1].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 allows 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 ci6e1.cfg file shown below 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 6000C board using ISDN and E1 line interfaces.

# ci6e1.cfg
#               CG 6000 configuration file
#
# This file configures the board to run NMSVoice with NOCC.
#      
#
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 callp ptf
#DSP.C5x[1..31].Files            = voice tone dtmf echo rvoice \
               callp ptf wave 
DSP.C5x[0].Files            = qtsignal tone dtmf echo NULL NULL NULL
Resource[0].Name           = RSC1
Resource[0].Size           = 120
Resource[0].TCPs           = nocc isd0
Resource[0].Definitions           = ( dtmf.det_all & echo.ln20_apt25 \ 
             & ptf.det_2f & ( (voice.rec_24 & \
             (voice.play_24_100 |             \
             voice.play_24_150 |             \
             voice.play_24_200)) | tone.gen ))
#  The commented Resource Definition contains all IVR functions except OKI
# To use the commented out resource definition, uncomment all of the lines 
# up to the DLMFiles and comment out the shorter resource definition.  
# Do the same with the DSP.C5x[].Files keyword.
# Wave and rvoice must be loaded to the board for this resource definition.
#Resource[0].Definitions =( dtmf.det_all & echo.ln20_apt25 & ptf.det_2f & \
#( ( (rvoice.rec_mulaw | rvoice.rec_alaw | rvoice.rec_lin | \
#voice.rec_16 | voice.rec_24 | voice.rec_32 | voice.rec_64 | \
#wave.rec_11_16b | wave.rec_11_8b) & \
#(rvoice.play_mulaw | rvoice.play_alaw | rvoice.play_lin | \
#voice.play_24_100 | voice.play_24_150 | voice.play_24_200 | \
#voice.play_64_100 | voice.play_64_150 | voice.play_64_200 | \
#voice.play_32_100 | voice.play_32_150 | voice.play_32_200 | \
#voice.play_16_100 | voice.play_16_150 | voice.play_16_200 | \
#wave.play_11_16b | wave.play_11_8b)) | \
#tone.gen | callp.gnc | ptf.det_4f))


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 c6nocc.cfg file shown below 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 6000C 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 callp \ ptf NULL
DSP.C5x[0].Files                              = qtsignal tone dtmf echo  callp NULL NULL
Resource[0].Name                              = RSC1
Resource[0].Size                              = 120
Resource[0].TCPs                              = nocc
Resource[0].Definitions                       = ( dtmf.det_all & \ echo.ln20_apt25 & ptf.det_2f & ( (voice.rec_24 & (voice.play_24_100 | voice.play_24_150 | voice.play_24_200)) | tone.gen ))
DLMFiles[0]                                   = cg6krun
DebugMask                                     = 0x0