Cisco Voice Switch Services (VXSM) Configuration and Command Reference Guide, Release 5 - Configuring VXSM Features [Cisco MGX 8880 Media Gateways]

Table Of Contents

Configuring VXSM Features

Configuring T1 Lines

Configuring SONET Lines and Paths

VTG/VT to DS1 Mapping Scheme

Configuring Clocking

Connection Admission Control (CAC)

Configuring Redundancy

1:1 Front Card/Back Card Redundancy

APS SONET Line Redundancy

PVC Channel Protection

Configuring PRI Backhaul

Configuring RUDP

Configuring LAPD

Configuring Announcements

Configuring Network Bypass

Configuring Differentiated Services (DiffServ)

Voiceband Data Configuration

Configuring a Voiceband Data Profile

Configuring Voiceband Event Mapping

Configuring the Online Diagnostic Feature.

DSP Resources under Mixed Codec Conditions

Configuring VXSM Features

Configuring T1 Lines

VXSM permits the user to configure many parameters associated with a physical T1 line. To configure a T1 line, perform the following procedure.

Step 1 Use the cnflnoos command to take the line out of service.

Step 2 Use the dspln command to display the current configuration of the line, for example
dspln n.m (where n is bay and m is the line number)
Step 3 Determine which parameters need to be changed,

Step 4 Use the cnfln command to change the required parameters.
cnfln <bay.line> [< -lt LineType >] [< -sc SendCode >] [< -lpb Loopback >] [< -signal 
SignalMode>]  
[< -detect LoopbackCodeDetection >] [< -lc LineCoding >] [< -len LineLength >] [< -lm LineMod>]  
[< -lbo LineBuildOut >] [< -rep Repetition >]
Step 5 Use the dspln command to display the new parameter values and verify that they are correct.

Step 6 Use the cnflnis command to bring the line into service.

Step 7 Use the upln command to bring the line up.

The BERT (bit error rate testing) and alarm parameters can also be configured for the line using the addbert, cnfbert and cnflnalm commands

Configuring SONET Lines and Paths

VXSM permits the user to configure many parameters associated with a physical SONET line/path.

To configure a SONET line, perform the following procedure.

Step 1 Use the dnln command to down the OC3 line

Step 2 Use the dspln command to display the current configuration of the line, for example
dspln n.m (where n is bay and m is the line number)
Step 3 Determine which parameters need to be changed,

Step 4 Use the cnfln command to change the required parameters.
cnfln bay.line [< -slt MediumType >] [< -lpb LoopbackType >] [< -sfs FrameScramble >] 
[< -rdiv DIVType >][< -rdip RDIPType >] [< -txtrace TraceToTransmit >] 
[< -extrace TraceToExpect >]
Note The cnfln command configures parameters at the physical OC3 level only. To configure parameters at the path (ds1) level, use the cnfpath command.

Step 5 Use the dspln command to display the new parameter values and verify that they are correct.

Step 6 Use the upln command to up the OC-3 line.

To configure a SONET path, perform the following procedure.

Step 1 Use the cnfpathoos command to take the path out of service.

Step 2 Use the dsppath command to display the current configuration of the path, for example
dsppath [< bay.line.path.vtg.vt >] | [< bay.line.path.ds1>]
Step 3 Determine which parameters need to be changed.

Step 4 Use the cnfpath command to change the required parameters.

This command has several versions depending upon the path type (ds1, ds3, e1, or sts). As an example, the ds1 version has the format:
cnfpath -ds1 [bay.line.path.vtg.vt] | [bay.line.path.ds1] [-lt <LineType>]  
[-sc <SendCode>] [-lpb <Loopback>] [-signal <SignalMode>]  
[-detect <LoopbackCodeDetection>] [-rep <Repetition>] 
Note VXSM supports two numbering schemes for mapping DS1 circuits to their vtg/vt values. These two schemes are known as `standard' and `Titan'. See next section for details.

Step 5 Use the dsppath command to display the new parameter values and verify that they are correct.

Step 6 Use the cnfpathis to bring the path into service.

VTG/VT to DS1 Mapping Scheme

For applications using the SONET-VT1.5/SDH-VC11 payload path type, VXSM supports two numbering schemes for mapping VTG/VT pairs to DS1s.

The first scheme conforms to ITU-T GR 253 (also Bellcore Std. TR 253) and is referred to as the `standard' scheme.

The second scheme supports certain types of DACS equipment (for example Tellabs 5500 DACS). This scheme is referred to as the Titan scheme (also referred to as the M13 count method).

With this feature, the user can specify which numbering scheme is to be used.

This feature adds two new CLI commands; one to display the currently selected mapping scheme and one to change the mapping scheme.

The SONET-VT1.5/SDH-VC11 payload path type supports 7 VTGs each containing 4 VTs for total of 28 DS1s.

The Standard Scheme

In the ITU-T GR.253 spec, the VTG-VT number pairs are incremented such that the VTG number increments from 1-7 before the VT number is incremented. That is, the first VTG-VT pair is 1-1, the second pair is 2-1, the third pair is 3-1 and so on up to 7-1. The next pair is then 1-2, followed by 2-2, 3-2,4-2 .... 7-2, then 1-3, 2-3...7-3 and so on until finally, 1-4, 2-4, .... 7-4.

The Titan Scheme

In the Titan (M13 Count) numbering scheme, VTG-VT number pair are incremented such that the VT increments from 1-4, before the VTG is incremented. That is, the first VTG-VT pair is 1-1, the second pair is 1-2, and so on up to 1-4. The next pair is then 2-1, followed by 2-2, 2-3, 2-4, then 3-1, 3-2, 3-3, 3-4 and so on until finally, 7-1, 7-2, 7-3, 7-4.

The complete mapping schemes are shown in Table 5-1.

Table 5-1 VTG/VT to DS1 Mapping

DS1

Standard, ITU-T GR 253

Titan, M13 Count

VTG

VT

VTG

VT

1

1

1

1

1

2

2

1

1

2

3

3

1

1

3

4

4

1

1

4

5

5

1

2

1

6

6

1

2

2

7

7

1

2

3

8

1

2

2

4

9

2

2

3

1

10

3

2

3

2

11

4

2

3

3

12

5

2

3

4

13

6

2

4

1

14

7

2

4

2

15

1

3

4

3

16

2

3

4

4

17

3

3

5

1

18

4

3

5

2

19

5

3

5

3

20

6

3

54

4

21

7

3

6

1

22

1

4

6

2

23

2

4

6

3

24

3

4

6

4

25

4

4

7

1

26

5

4

7

2

27

6

4

7

3

28

7

4

7

4

User Interface

The VTG/VT to DS1 mapping feature uses the following two CLI commands.

Display VT Mapping

Syntax: dspvtmapping

This command displays the current setting of VTG/VT to DS1 mapping scheme, values are "standard" or "Titan". Standard denotes ITU-T GR 253, Titan denotes M13 Count.

Configure VT Mapping

Syntax: cnfvtmapping <VtMappingMode>

1 - standard (default)

2 - titan

This command switches the current setting of VTG/VT to DS1 mapping scheme to the alternative scheme.

Note To execute the cnfvtmapping command:

1. The cnfvtmapping command is valid on the VXSM-OC3 card only.
2. All SONET lines on the card must be down.
3. All SONET lines on the card must be configured with medium type as `sonet'.
4. All SONET paths on the card must be configured as `VT1.5'.

Note When VT mapping mode is set to 'titan', the following commands will be affected on the VXSM-OC3 card.

cnfln: the option -slt (Medium Type) will be rejected

cnfpath -sts: the options -payload and -tg will be rejected

In Titan mode, the DS1 path order will be changed in the following commands (see Table 5-1 for path order).
CLI: dsppaths -ds1
dsppathalms -ds1
dsppathstates (for ds1 only)
dspvif***s (for ds1 only)
dsplapds (for ds1 only)
dspberts -ds1
dspds0xcons (for ds1 only)

Configuring Clocking

The clock for the media gateway can be one of the following sources.

•A BITS clock source received on the PXM-45 back card on ports 35 and 36 using an E1 or T1 RJ-48 connector. In a redundant configuration, a Y-cable is for the BITS clock.

•The PXM internal oscillator (stratum 3 circuit on PXM-45 back card)

•A Clock derived from VXSM line or AXSM line

The clock source is configured on the active PXM card using the cnfclksrc command.

The syntax of this command is:

cnfclksrc <priority> <portid>[ -bits { e1|t1 } ][ -revertive { enable|disable } ]

where:

priority—This is either primary or secondary (default = primary)

portid—The specification of the port ID depends upon the selected clock source.

If the BITS clock source is selected, portid is specified as:

[shelf.]slot.port

shelf—always 1 and is purely optional.

•slot—the logical slot number 7 for a BITS circuit on the PXM UI S3 (regardless of where the active PXM resides).

•port—a logical number that indicates the upper or lower external clock connector on the UI S3 back card. The logical port number for the upper connector is 35. The lower connector is 36.

If a service module line is selected as the source, portid is specified as:

•[shelf.]slot:subslot.port:subport

•shelf—always 1 and is purely optional.

•slot —the slot number of the service module.

•subslot—identifies the upper or lower bay of the back card, either a 1 for the upper bay or 2 for the lower bay (default is 1).

•port—is the line number on the service module back card. (The specified line must already be active (see upln).

•subport—is the logical port number. This value is the logical port (or ifNum) that you must have assigned through addport. Also, the logical port must be known to PNNI (see dsppnports).

Note When specifying a clock source on a VXSM card, the value "10" must be added to both the line and logical port numbers. For example, a primary clock source on a VXSM in slot 3, upper shelf, line 1, logical port 1 would be specified as:

cnfclksrc primary 3:1.11:11

•-bits This keyword parameter is required if slot number 7 and port number of 35 or 36 are specified in portid (indicating BITS as the clock source) Type the string "-bits" followed by a space then either "e1" or "t1."

•-revertive an option that applies to only the BITS clock. Type the string "-revertive" followed by the complete word "enable" or "disable." The default is disable.

Step 7 Use the cnfclksrc command again to configure the secondary clock source.

Step 8 Use the cnfclkparms command to configure the signal type and cable type for BITS sources (if applicable). The configuration applies to both (upper and lower) lines.

The syntax of this command is:

cnfclkparms <signal type> <cable type>

where:

signal type, 1 = data; 2 = syn (this parameter is not supported in this release)

cable type, 1 = twisted; 2 = coax

Note E1 lines can be either twisted pair or coaxial cable. T1 lines must always be specified as twisted pair.

Below is an example of a sequence of clock configuration commands.
8850japan.7.PXM.a > cnfclksrc primary 7.35 -bits t1 -revertive enable
8850japan.7.PXM.a > cnfclksrc secondary 7.36 -bits t1 -revertive enable
8850japan.7.PXM.a > cnfclkparms 1 1 
Confirm the clock source using the dspclksrc command.

On the PXM card, use the dspclksrcs command to display the clocking configuration.

For example:
8850japan.7.PXM.a > dspclksrcs
Primary clock type:     bits t1
Primary clock source:   7.35
Primary clock status:   bad
Primary clock reason:   no clock
Secondary clock type:   bits t1
Secondary clock source: 7.36
Secondary clock status: bad
Secondary clock reason: no clock
Active clock:           internal
source switchover mode: revertive
Appendix A in this document covers the subject of clocking in greater detail.

Connection Admission Control (CAC)

CAC is configured when an ATM connection is added using the addcon command. How CAC is applied depends upon the values specified for the service type, peak cell rate (PCR), and sustained cell rate (SCR) parameters.

These parameters permit the user to specify the bandwidth (expressed as a cell rate) requirements for the virtual circui being added. If the specified bandwidth is not available, the connection is denied.

The addcon command has four parametes for specifying required cell rate. These are -lpcr, -rpcr, -lscr, and -rscr. The l and r stand for local and remote respectively. An l means in the local to remote direction, r means remote to local direction. The four parameters allow the user to specify PCR and SCR values for the PVC in each direction.

If the service type is specified as CBR (constant bit rate), PCR values are used as maximum bandwidth requirements otherwise, SCR values are used as available bandwidth requirements.

To facilitate the CAC function, VXSM performs load balancing on all PVCs configured on the card.

Configuring Redundancy

VXSM provides the following redundancy features.

1:1 Front card/back card redundancy

1:1 APS SONET line redundancy

1+1 APS SONET line redundancy

PVC channel protection

1:1 Front Card/Back Card Redundancy

VXSM front and back cards can be configured for redundancy provided they are installed in adjacent slots (for example, 1 and 2, 9 and 10, etc.).

On the PXM card execute the addred command.
addred <redPrimarySlotNum> <redSecondarySlotNum> <redType>
redPrimarySlotNum and redSecondarySlotNum should be specified as the slot number of the active card andthe standby card respectively.

<redType> is redundancy type where redType = 1(1:1 Y-Cable) or 2(1:N). Enter 1 for Y-cable.

APS SONET Line Redundancy

To setup a working/protection line pair, use the addapsln command. This command allows the user to specify an OC-3 port as a working line and a corresponding OC-3 port as a protection line. 1:1, 1+1, and 1+1 Annex B protection types are supported.

To configure 1:1 or 1+1 line redundancy perform the following steps.

Step 1 Use the addapsln command to setup a working protection line pair.
addapsln <working line> <protection line> <archmode> 
Working line and protection line are expressed as slot.bay.line. The bay is always be the upper bay, 1 = adjacent card, 2 = same card. For same card, line is in the range 1 to 4, for adjacent card line is in the range 5 to 8.

Note 1+1 and 1+1AnxB are supported on the same card or across 2 card slots. 1:1 is supported only on the same card,.

Step 2 Use the cnfapsln to configure aps fault thresholds and other parameters.
cnfapsln <working line> [-sf <SigFaultBER>] [-sd <SigDegradeBER>]  
[-wtr <WaitToRestore >][-dr <Direction>] [-rv< Revertive>] [-proto <Protocol>]
working line is expressed as slot.bay.line of the working line.

SigFaultBER and sigDegradeBER are bit error rates for fault detect and fault degrade detect respectively. If these rates are detected, switchover takes place.

SigFaultBER
This is an integer n in the range from 3 - 5, with a default value of 3. This parameter represents a value of 10-n, where n is 10-3 to 10-5.

sigDegradeBER
This is an integer n in the range from 5 - 9, with a default value of 5. This parameter represents a value of 10-n, where n is 10-5 to 10-9.

Waittorestore
This parameter defines the interval in minutes to wait before attempting to switch back to the working line after a switchover (not applicable if the line is configured in non-revertive mode). The range is 1 to 12 minutes.

The framer clears the signal-fault and signal-degrade states when the APS switchover occurs.

The permissible value of this parameter is an integer in the range from 1 - 12.

Direction
This parameter configures the switching direction that this APS line will support.

1 = Unidirectional—On a failure, only that direction fails over.

2 = Bidirectional—On a failure, both directions fail over.

Revertive
This parameter is used to configure the APS revertive or nonrevertive mode.

1 = Nonrevertive mode—The protection line continues to be the active line. The active line does not switch to the working line.

2 = Revertive mode—Switches the working line back to the active state after the wait-to-restore interval has expired and the working line signal-fault/signal-degrade state has been cleared.

Protocol
This parameter configures the APS channel protocol to be implemented at the near end terminal.

The K1 and K2 overhead bytes in a SONET signal are used as an APS channel to effect the APS protocol.

1 = Bellcore—The APS channel protocol is implemented as defined in the Bellcore document GR-253-CORE.

2 = ITU—The APS channel protocol is implemented as defined in the ITU document G.783, Annex A.

PVC Channel Protection

Perform the following procedure to configure a dual PVC pair in which a primary PVC is protected by a secondary PVC.

Step 1 Create the primary PVC using the addcon command.The -pref parameter is used to specify whether the PVC is a primary, secondary, or none. Specify 1 for primary.

Step 2 Create the secondary PVC using the addcon command.The -pref parameter is used to specify whether the PVC is a primary, secondary, or none. Specify 2 for secondary.

Note The primary PVC should be added first and then the secondary. When a PVC is deleted, the secondary should be deleted first. The PCR and SCR values for the primary and secondary PVCs must be the same.

Changing the preference of a PVC from secondary to primary or unknown and from primary of unknown to secondary are not allowed. Only primary to unknown and unknown to primary are allowed.

Step 3 Use the cnfconprotect command to configure the protection.
cnfconprotect ifNum vpi vci protect fallbackPort fallbackVpi fallbackVci 
ifNum
This is the interface number of the PVC, specify 1

vpi, vci
These are the vpi and vci values of the already created PVC.

fallbackPort
This specified whether protection is to applied or not. 1 = protect, 2 = no protection (default).

fallbackVpi, fallbackVci
These are the vpi and vci values of the fallback PVC

Step 4 Use the cnfoamparams command to configure the operation, administration, and management (OAM) cells for a dual PVC protection group.
cnfoamparams gap retry recover
gap
This parameter defines in milliseconds the inter-cell gap for dual PVC (DPVC) operation, administration, and management (OAM) cells. The permissible range is 20 - 5000, with a default value of 5000.

retry
This parameter defines the retry threshold (in number of cells) during a PVC failure.

When the number of consecutive OAM cells being sent without receiving an acknowledgment (ACK) is equal to the value of this parameter, switchover occurs.

The permissible range is 0 - 20, with a default value of 3.

recover
This parameter defines the threshold (in number of cells) for recovery of a failed PVC.

The permissible range is 0 - 20, with a default value of 5.

When the number of consecutive OAM cells being sent while receiving an acknowledgment (ACK) is equal to the value of this parameter, the failed PVC is considered to have recovered from its failed state.

Note PVCs cannot be deleted while they are part of a dual PVC protection group and while they are active. To delete a PVC, first use cnfconprotect to set the group to unprotected (fallbackPort = 2). Then use the dncon to make the secondary PVC inactive, delete the secondary PVC and the primary PVC.

Configuring PRI Backhaul

In switching applications, VXSM is able to extract Q.931 signaling frames from an ISDN PRI D channel and backhaul them to the media gateway controller for processing (this feature is described in Chapter 2). Configuration of this feature consists of the following steps.

Step 1 Establishing a communication link between the VXSM and the media gateway controller. This communication link is based upon a RUDP (Reliable UDP) session set .

Step 2 Establishing an LAPD session between VXSM and the voice TDM network.

Configuring RUDP

To configure an RUDP session between VXSM and the media gateway controller, perform the following steps.

Step 1 Establish IP connectivity with the media gateway controller(s) (see Chapter 2 for details).

Step 2 Use the addsesset command to create a session set.
addsesset <set number> <fault tolerant>
set number
Integer value of 1 (currently only session set is supported)

fault tolerant
Integer value

1 = fault tolerant

2 = non-fault tolerant

Step 3 Use the adddnsdn command to add the domain server domain name
adddnsdn <Domain Name> 
Step 4 Use the adddnssrvrip command to add the IP address of the domain server
adddnssrvrip 1 172.29.66.35
Step 5 Use the addmgcdn command to ass the domain name of the media gateway controller
addmgcdn 1 mgc7
Step 6 Use the addsesgrp command to create each session group
addsesgrp <group number> <set number> <mgcname>
group number
Integer value of 1 or 2 (specify 1 for non-fault tolerant mode or 2 for fault tolerant mode).

set number
Integer value of 1(only 1 is supported)

mgcname
Domain name of the call agent (a text string of 1-64 characters.

Step 7 Use the addses command to create each RUDP session. Each session group can have up to four sessions.
addses <session number> <group number> <priority> <local port> <remote port>
session number
Integer value (1 to 8)

group number
Integer value (1 or 2)

priority
Integer value in the range of 1 to 4. A lower number means higher priority.

local port
Integer value in the range of 1124 to 65535

remote port
Integer value in the range of 1124 to 65535

Step 8 For each session that has been created, the session parameters can be further configured using the following commands (see Chapter 6 for CLI details).

Table 5-2 RUDP Session Commands

Command

Function

cnfsesport

To configure the local port/remote port values. The <local port, remote port and Remote IP address> combination must be unique across the group.

cnfsesmaxwindow

To configure the maximum number of segments that can be sent without getting an acknowledgement for a specific RUDP session.

cnfsessyncatmpts

To configure the maximum number of attempts to synchronize with MGC for a specific RUDP session

cnfsesmaxseg

To configure the maximum number of octets to synchronize with VSC for a specific RUDP session

cnfsesmaxreset

To configure the maximum number of auto resets that will performed before a connection is reset

cnfsesretrans

To configure the timeout value for retransmission of unacknowledged packets in millisecondes and the maximum number of times consecutive retransmission will be attempted before the connection is considered broken

cnfsesack

To configure the timeout value to send out an acknowledgment and the maximum number of acknowledgments that will be accumulated before sending an acknowledgment

cnfsesoutofseq

To configure the maximum number of out of sequence packets that will be accumulated before sending an EACK segment is sent. A value of 0 indicates an DACK will be sent immediately if an out of order segment is received

cnfsesnullsegtmout

To configure the number of milliseconds of idle time before sending a null segment

cnfsesstatetmout

To configure the number of milliseconds of idle time before sending a null segment

Configuring LAPD

To configure a LAPD parameters for a DS0 used for ISDN D channel, perform the following steps.

Step 1 Use the addlapd command to create an LAPD session on a specified DS0.
addlapd <bay.line.path.vtg.vt:ds0>|<bay.line.path.ds1:ds0>|<bay.line>:<ds0>[-side 
<LAPDside>][-type <Type>][-window <WindowSize>]{-n200<n200>}[-t200 <Timer200>][-t203 
<Timer203>][-ds0 <Ds0Format>][-profile <IsdnHdlcProfile>][-as <AS Name>][-appltype 
<AppType>]
Use one of these formats to specify the DS0 on an oc3 card

<bay.line.path.vtg.vt:ds0> |<bay.line.path.ds1:ds0>

bay: 1

line: 1 - 4

path: 1 - 3

vtg: 1 - 7

vt: 1 - 4(T1)/3(E1)

ds1: 1 - 28

ds0: 1 - 24 (T1), 1 - 16(E1)

Use this format to specify the DS0 on a T1/E1 card

<bay.line>:<ds0>

bay: 1

line: 1 - 4

dds0: 1 - 24 (T1), 1 - 16(E1)

The following parameters are the same for both OC3 and T1/E1 cards.

side <LAPDsid>

Specify whether the LAPD stack is at user side or network side

1 - network

2 - user

-type <Type>

Specify the switch type at the remote end of the ISDN line.

1 - CCITT

3 - AT&T 5ESS PRA

4 - AT&T 4ESS

6 - NT dms100 PRA

7 - VN 2 or VN 3

8 - INS Net

9 - tr6 MPC

10 - tr6 PBX

12 - Austel Primary

13 - National ISDN-1

14 - ETSI

15 - NT dms250

16 - Bellcore

17 - National ISDN-2

-window <WindowSize>

Specify the maximum number of sequentially numbered I-frames that may be outstanding

1..128 (default=7)

-n200 <n200>

Specify the maximum number of retransmissions of a frame

1..10 (default=3)

-t200 <Timer200>

Specify the maximum time to wait for acknowledgment of a transmit frame

100..1023000 ms (default=1000)

-t203 <Timer203>

Specify the maximum time in milliseconds allowed without frames being exchanged. This value should be greater than that for -t200

100..1023000 ms (default=1000)

-ds0 <Ds0Format>

Specify the DS0 format. 56k(1) is robbed-bit for T1.

1 - ds056k

2 - ds064k}

-profile <IsdnHdlcProfile>

Specify the HDLC profile which contains a list of HDLC attributes for the PRI backhaul connection

1..128

-as <AS Name>

Specify the LAPD application server (AS) name. An AS is a logical entity serving LAPD D-channel. Zero length string (size 0) means there is no AS association with this LAPD D-channel

255 chars. This paremeter is used for PRI backhaul using SCTP only and is not configurable for RUDP.

-appltype <AppType>

Specify the PRI backhaul application protocols as 1 or 2.

1 = sctp

2 = rudp

Step 2 When an LAPD session has been created, the session parameters can be further configured using the following commands (see Chapter 6 for CLI details).

Table 5-3 LAPD Session Commands

Command

Function

cnflapd

Modify an existing Lapd entry. The applType can not be modified in this command. The line must be deleted and then added back again to change the applType.

dsplapdcnt

Display LAPD statistics counters

dsplapdhdlccnt

Display LAPD HDLC statistics counters

Configuring Announcements

To configure the Announcements feature, perform the following steps.

Step 1 It is the responsibility of the user to record all announcements and have them stored in PCM format as computer files in the announcement file server. The announcement file server must IP reachable from the VXSM.

Step 2 Use the cnfanndn command to specify the name of the announcement file server.
cnfanndn <ServerDomainName>
Step 3 Use the cnfanncontrols command to configure announcement parameters
cnfanncontrols [-path <SubDirPath >] [-dn <DomainNameResolution>] [-ip <ipAddress>]  
[-age <ageTime>] [-tout <ReqTimeOut >] [-per <maxPermanent>] 
SubDirPath is a string up to 64 characters that specifies the subdirectory path to the default TFTP directory in the announcement file server in which the announcement files are stored.

DomainNameResolution specifies how the domain name of the announcement file server is to be resolved.

1 = Internal only (default value)—Indicates internal resolution of domain name for announcement file server.

2 = External only—Indicates external resolution of domain name for announcement file server.

If this parameter is set to the value 1, the IP address associated with the file server is determined according to the value of the -ip ipAddress parameter.

ipAddress is the IP address for the announcement file server. If the DomainNameResolution is configured as `external only', this item will be ignored.

ageTime is the time in minutes that an announcement will remain valid once it is fetched into the VXSM announcement cache. The range is 1 to 1440. Once in the cache an announcement will not be refreshed until it is aged -- subsequent "play announcement" requests do not effect the agetime or cause the file to be refreshed from the server.

ReqTimeOut is the time, in seconds, within which an announcement must start playing after the VXSM receives the announcement signal from the MGC.The default value is 5 second.

maxPermanant is the maximum number, in the range 0 to 136, that permanent announcement files can be added to Media Gateway. The default value of 41. A value of 0 indicates that the age time function is disabled.

Step 4 Use the addannfile to map an announcement name number to the announcement filename. This command also lets the user specify the number of times the announcement is to be played, whether the file is to be permanent or not, and the signal duration of the announcement file.
addannfile cannoAudioFileNumber FileName [-noc numberOfCycles] [-type fileType]  
[-dur signalDuration]
cannoAudioFileNumber is an index value that identifies the announcement file to be used by the media gateway. The permissible value of this parameter is an integer in the range from 1 - 1024.

Filename specifies the name of a valid announcement file that has been stored in the media gateway announcement table. This announcement file name, which can be composed of up to 64 characters, can incorporate path or subdirectory information

noc specifies the number of times the announcement file is to be played.

The permissible value of this parameter is an unsigned integer in the range from 0 - 65535, with a default value of 1.

The value zero specifies that an announcement file is to be played or looped continuously.

type is used to specify the type of the announcement file.

The integer value for this parameter must be one of the following:

1 = Dynamic file type (default)—A dynamic file can be removed from cache when the age of the file reaches a specified limit or in accordance with a least recently used (LRU) algorithm when the cache is full.
2 = Permanent file type—A permanent file can be stored in cache until it is deliberately deleted.

This parameter indicates the duration (in milliseconds) that the announcement file is to be played during an announcement cycle. This parameter is applicable only for purposes of playing a fixed announcement.

For fixed announcement play, the -noc numberOfCycles parameter and the -dur signalDuration parameter are used together to determine how long the announcement is to be played.

The permissible value for these parameters is an integer in the range from 0 - 65535.

A value zero for -dur indicates that the duration of the announcement is variable and that the -noc numberOfCycles parameter (see above) will be used to determine play time.

This parameter is used only when the Play Announcement signal from the MGC does not incorporate a parameter specifying the number of cycles that the announcement is to be played.

Step 5 Use the cnfannfile to configure a specific announcement file.
cnfannfile cannoAudioFileNumber FileName [-noc numberOfCycles]  
[-dur signalDuration]
cannoAudioFileNumber is an index value that identifies the announcement file to be used by the media gateway. The permissible value of this parameter is an integer in the range from 1 - 1024.

Filename specifies the name of a valid announcement file that has been stored in the media gateway announcement table. This announcement file name, which can be composed of up to 64 characters, can incorporate path or subdirectory information

noc specifies the number of times the announcement file is to be played.

The permissible value of this parameter is an unsigned integer in the range from 0 - 2147483647, with a default value of 1.

The value zero specifies that an announcement file is to be played or looped continuously.

For fixed announcement play, the -noc numberOfCycles parameter and the -dur signalDuration parameter are used together to determine how long the announcement is to be played.

The permissible value for these parameters is an integer in the range from 0 - 65535.

A value zero for -dur indicates that the duration of the announcement is variable and that the -noc numberOfCycles parameter (see above) will be used to determine play time.

This parameter is used only when the Play Announcement signal from the MGC does not incorporate a parameter specifying the number of cycles that the announcement is to be played.

Configuring Network Bypass

Configuration for the Network Bypass feature consists of making a mesh of PVCs between VXSM and other cards in the gateway. When the mesh of PVCs is complete the feature is enabled through the cnfnwbypass command.

For each PVC in the following procedure the attributes of the PVC are:

•AAL5

•PVC type is bearer

•Traffic type: UBR

•Peak Cell Rate to support 24 OC3s

•No CAC (all internal PVCs run over the shelf's backplane)

•Internal PVCs are not assigned IP addresses

In order to configure the media gateway for the Network Bypass feature, perform the following procedure.

Step 1 Create a pvc between each VXSM card and its associated RPM or AXS M card. Specify the attributes listed above. The procedure is to configure the slave end at the RPM or AXSM first and the master end on the VXSM second. Details are provided in Chapter 3 under the heading "Create Connections To RPM-XF Card'.

Step 2 For each VXSM card create a single pvc to each of the other VXSM cards in the shelf. Use the addcon command and specify the attributes listed above. It does not matter which is the master and which is the slave.

Step 3 For each VXSM card create a single pvc for which the VXSM card is specified for both ends. Use the addcon command and specify the attributes listed above.

Step 4 By default, the network bypass feature is disabled. To enable the feature, enter the cnfnwbypass command on each VXSM card. The format of this command is:

cnfnwbypass <nwbypass>

nwbypass --has the value 1, 2, or 3

1 - disable (default)

2 - unconditional enable

3 - conditional enable

The conditional enable allows the MGC to control the use of this feature. It can explicitly, in a given call flow, ask for this attribute to be returned.

The current status of the network bypass feature can be shown by entering the dspnwbypass command.

Configuring Differentiated Services (DiffServ)

For VoIP applications, VXSM provides support for the quality of service (QOS) feature known as DiffServ. The DiffServ feature permits devices at the edge of the network to specify the contents of the Type of Service (TOS) field in the IPv4 header as a differentiated services point code. This point code can then be used by routers in the network to determine per hop behavior (PHB).

VXSM's support of this feature is to permits users to specify the values of the point code to be inserted into the IP header TOS field. The specified values are entered through the cnfiptos command and are applied card-wide. VXSM does not check the entered value nor does it understanding the meaning of the point code values. It is the responsibility of the network administrator to ensure that the routers understand how to process the point codes.

The cnfiptos commands allows the user to specify TOS values for both control and bearer packets (although DiffServ is really confined to bearer packets). The command has the format:

cnfiptos <ControlTOS> <BearerTOS>

ControlTOS—An integer in the range of 0 to 255 with a default of 104

BearerTOS—An integer in the range of 0 to 255 with a default of 184

For the Control Path, the default of 104 maps to DiffServ Codepoint 011010 which is Assured Forwarding (AF31 PHB) for signalling/control (see RFC 2597 for more information)

For the Bearer Path, the default of 184 maps to Diffserv Codepoint 101110 which is Expedited Forwarding (EF) PHB or "Premium Service". (see RFC 2598 for more information)

The current values of the ControlTOS and the BearerTOS parameters can be displayed with the dspiptos command.

Voiceband Data Configuration

VXSM supports the handling of Voice Band Data (VBD) within a voice connection. Examples include clear channel, fax or modem pass-through over a VoIP or VoATM network.VXSM provides the event handling for the VBD events detected in the voice or IP interface of the media gateway. The event handling is mapped to different event handling functions categorized by the attributes defined in different kinds of profiles, such as fax relay profile, or VBD profile.

Configuring a Voiceband Data Profile

The VBD profile is used to determine the handling of voiceband data when it is detected in a voice interface. The profile includes such information as codec to be used for upspeed, size of jitter buffer, and the value for the inactivity timeout.

Perform the following procedure to configure a voiceband data profile.

Step 1 Use the addvbdprof command to create a vdb profile. The format of this command is:

addvbdprof <VbdProfileIndex>[-upscodec <UpspeedCodec>]
[-jmax <MaxJitterDelay>] [-jnom<NomJitterDelay>]
[-inact <InactivityTimeout>]

VbdProfileIndex—Identifies the VBD profile. The entry with the value of this object set to 1 is the default VBD profile for the media gateway. The default VBD profile is automatically created by the system and cannot be added or deleted, but can be modified by network manager. An integer in the range of 2 to 25

-upscodec<UpspeedCoded>—Specifies the CODEC type to use for upspeed. Upspeed is used to change the transmission rate of the voice interface to a higher rate of CODEC type."

14 = G.726-32 (h248 only)

15 = G.711u

16 = G.711a

27 = Clear channel

-jmax<MaxjitterDelay>—Specifies the maximum jitter buffer size in the VBD connection. The value of cvbdpVbdProfJitterMaxDelay should be greater than the value of cvbdpVbdProfJitterNomDelay and the value of cvbdpVbdProfJitterMinDelay. An integer in the range of 20 o 135 milliseconds

-jnom<NomJitterDelay>—Specifies the nominal jitter buffer size in the VBD connection. The value of NomDelay should be smaller than the value of MaxDelay, but greater than the value of MinDelay. An integer in the range of 5 to 135 milliseconds.

-inact<InactivityTimeout>—Specifies a timeout value before teardown the call if there is no activity in the VBD connection. The value of 0 is to disable the inactivity detection. An integer in the range of 0 to 65535 seconds.

Step 2 When a VBD profile has been created, the parameter values can be changed with the cnfvbdprof command. The format of this command is:

cnfvbdprof <VbdProfileIndex>[-upscodec <UpspeedCodec>]
[-jmax <MaxJitterDelay>] [-jnom<NomJitterDelay>]
[-inact <InactivityTimeout>]

VbdProfileIndex—Identifies the VBD profile to be configured. An integer in the range of 1 to 25

-upscodec<UpspeedCodec>—Specifies the CODEC type to use for upspeed. Upspeed is used to change the transmission rate of the voice interface to a higher rate of CODEC type."

14 = G.726-32 (default)

15 = G.711u

16 = G.711a

27 = Clear channel

28 = G.726-40

-jmax<MaxjitterDelay>—Specifies the maximum jitter buffer size in the VBD connection. The value of cvbdpVbdProfJitterMaxDelay should be greater than the value of cvbdpVbdProfJitterNomDelay and the value of cvbdpVbdProfJitterMinDelay. An integer in the range of 20 o 135 milliseconds

-jnom<NomJitterDelay>—Specifies the nominal jitter buffer size in the VBD connection. The value of NomDelay should be smaller than the value of MaxDelay, but greater than the value of MinDelay. An integer in the range of 5 to 135 milliseconds.

-inact<InactivityTimeout>—Specifies a timeout value before teardown the call if there is no activity in the VBD connection. The value of 0 is to disable the inactivity detection. An integer in the range of 0 to 65535 seconds.

Each of the commands in the procedure has an equivalent display command for displaying the current parameter values

Configuring Voiceband Event Mapping

The voiceband event mapping feature permits VXSM to determine how VBD events are to be handled. When this feature is configured, VBD events are mapped to different event handling functions categorized by the attributes defined in different kinds of profiles, such as fax relay profile, or VBD profile.

Perform the following procedure to configure a voiceband event mapping.

Step 1 Use the addveventmapping command to create the event mapping feature. The format of this command is:

addeventmapping <EventMappingIndex>

EventMappingIndex— Identifies a set of voice data events supported by VXSM and how they will be handled in the media gateway. An integer in the range 2 to 10. A value of 1signifies the default handling for the voice data events in the media gateway

Step 2 When event mapping has been added, the parameter values can be changed with the cnfeventmapping command. This command has two formats as follows:

cnfeventmapping -ced<EventMappingIndex>[-htype <EventMappingType>]
[-prof <EventMappingProfileIndex>] [-hmode<EventHandlingMode>]

cnfeventmapping -v21Tone<EventMappingIndex>[-htype <EventMappingType>]
[-prof <EventMappingProfileIndex>] [-hmode<EventHandlingMode>]

The difference between these commands is how VBD events are identified.

cnfeventmapping -ced uses CallEd termination iDentification, for example, 1200 Hz tone

cnfeventmapping -v21Tone uses the V.21 preamble signal (ITU-T V.21 channel-2) event detection.

The parameters for these commands are the same.

EventMappingIndex—Identifies a set of voice data events supported by VXSM and how they will be handled in the media gateway. The entries with value 1 of this object is the default handling for the voice data events in the media gateway."

-htype<EventMappingType>—This object specifies the type of the handle function in response to this event detection.

1 = none

2 = vbd

3 = fax

-prof<EventMappingProfileIndex>—Specifies the index of the profile in which defines the handling attributes in response to the event detection. If the EventHandleType is equal to 'none', this object is not applicable.

If the EventHandleType is equal to 'vbd', this object is the same as Vbd