cc/td/doc/product/wanbu
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Configuring VISM Cards

Configuring VISM Cards

The VISM module performs voice internetworking service module functions. This chapter describes dialogs that show configuration information for:

The Supported Codec Templates Table parameters are described in Table 12-21.

Selecting and Displaying Card Parameters

Select the VISM card to display card configuration dialogs by doing one of the following:

The VISM Card Category menu contains the following dialogs:


Note   Some of these dialogs have sub-dialogs.

Card Configuration

Use the VISM Card Configuration dialog to view VISM card characteristics, hardware, firmware, and status information.


Figure 12-1: VISM Card Configuration Dialog


The Card configuration dialog parameters are described in Table 12-1.
Table 12-1: Card Configuration Dialog Parameters
Parameter Description

Slot Number

Number of the current slot containing the card.

Card Type

Current card type. In this case, it is a VISM.

Card State

Front card status. Can be one of the following:

  • nocard

  • standby

  • active

  • failed

  • selfTest

  • heldInReset

  • boot

  • mismatch

  • unknown

  • coreCardMisMatch

  • blocked

  • reserved

  • hold

Front Card Description

Description of the front card.

Front Card Serial No

Serial number of the front card.

Card Hardware Revision

Current card hardware revision.

Card Firmware Revision

Current card firmware revision.

MIB Version Number

MIB version number updated when any part of the MIB changes.

Card Reset Reason

Reason for the last card reset. Can be Powerup, parityError, watchDog, resource, clrAll, missingTask.

Line Module Type

Current line module number. In this case, it is an lm-RJ48-8T1.

Line Module State

Current back card state. Can be one of the following:

  • notPresent

  • Present

  • invalid

Line Module Description

Description of the current back card.

Line Module Serial Number

Serial number of the current back card.

Line Module Hardware Revision

Hardware revision of the current back card.

Line Module Firmware Revision

Firmware revision of the current back card.

Config Chng Type BitMap

Configuration change Type BitMap used in vismTableChanged trap and vismScalarChanged trap.

When used in vismTableChanged trap, the bits indicate the following:

  • bit 0 set = mgcTable changed

  • bit 1 set = mgEndpointTable changed

  • bit 2 set = mgcResolutionTable changed

  • bit 3 set = srcpPeerTable changed

  • bit 4 set = vismDsx1Table changed

  • bit 5 set = vismXgcpPeerTable changed

  • bit 6 set = xgcpPackageTable changed

  • bit 7 set = vismChanCacTable changed

  • bit 8 set = vismCasVariantTable changed

  • bit 9 set = vismCasXgcpVariantTable changed

  • bit 10 set = vismAal2CidCnfTable changed

  • bit 11 set = dsx0VismCnfTable changed

  • bit 12 set = vismHdlcChanCnfTable changed

  • bit 13 set = lineAssignmentTable changed

  • bit 14 set = vismCodecCnfTable changed

When used in vismScalarChanged trap, the bits indicate the following:

  • bit 0 set = mediaGateway group changed

  • bit 1 set = mediaGatewayEndpoint group changed

  • bit 2 set = mediaGatewayControllerResolution group changed

  • bit 3 set = srcpAdminObjects group changed

  • bit 4 set = vismConfig group changed

  • bit 5 set = vismXgcpCoreObjects group changed

  • bit 6 set = xgcpCoreObjects group changed

  • bit 7 set = xgcpExtensionObjects group changed

  • bit 8 set = xgcpPackageObjects group changed

The default value is 0, no change


Note   This MIB makes sense only in traps. A GET on this may not return a Useful result.

Card Integrated Alarm

Bit position represents the different types of alarm

For ASC:

  • bit 0: ShelfFunctionModuleState (BNM only) (failed/boot/mismatch/heldinReset)

  • bit 1: LineModuleState (BNM only) (notPresent/invalid)

  • bit 2: ASMPhysicalAlarmState (BNM only)

  • bit 3: ATMLMIFailure (ASC only)

  • bit 4: LineAlarmState (BNM only)

  • bit 5: LineStatisticalAlarmState (BNM only)

  • bit 6: PLCPAlarmState (BNM only)

  • bit 7: PLCPStatisticalAlarmState (BNM only)

  • bit 8: SmConnectionFailureAlarm

For SM:

  • bit 0: ShelfFunctionModuleState (failed/boot/mismatch/heldinReset)

  • bit 1: LineModuleState (notPresent/invalid)

  • bit 2: PortLMIFailure

  • bit 3: LineAlarmState

  • bit 4: LineStatisticalAlarmState

  • bit 5: FrameRelayPortState (RemoteLoopback/ FailedDueToLine/FailedDueToSig)

  • bit 6: ChannelState

For PXM/SRM Only (MGX8850 Platfrom):

  Only those marked with SRM are valid for both PXM/SRM. The rest are valid only for PXM.

  • bit 0: ShelfFunctionModuleState

  • bit 1: Backcard Line Module (SRM/PXM)

  This Alarm is generated when the Line Module(Trunk Backcard) is removed or goes to a mismatch state(or backcard type is unknown).

  • bit 2: Backcard UIModule

  This Alarm is generated when the UI backcard is removed or goes to a mismatch state(or backcard type is unknown).

  • bit 3: ASM Physical Alarm

  This specifies whether any of the environmental monitoring components like Temperature, Voltage Supply, Fan Speed have gone into alarm.

bit 4 : ATM LMI Failure

bit 5 : Line Alarm (SRM/PXM)

bit 6 : Line Statistical Alarm (SRM/PXM)

bit 7 : Lines Alarm (SRM/PXM)

bit 8 : PLCP Alarm

bit 9 : PLCP Statistical Alarm

bit 10 : Connections exist on removed SM

bit 11 : Disk related Failure on first PXM slot

bit 12: Disk related Failure on second PXM slot

  The Disk Alarms are generated when any of the file operations on Disk like open,read,write,lseek etc fail.

VSM Alarms

bit 13 : Port LMI Failure

bit 14 : Port State Alarm

bit 15 : Channel Shelf Alarm

bit 16 : Taskmon Task Suspended

bit 17 : Excess Power Consumption

bit 30: bit set(1) major alarm, else (0) minor alarm

The default value is 0.

VISM Features

Use the VISM Features dialog to view VISM card features. (See Figure 12-2.)


Figure 12-2: VISM Features Dialog


The parameters are described in Table 12-2.


Table 12-2: VISM Features Dialog Parameters
Parameter
Description

IP Address

IP address of the VISM card. The address is required to communicate with the Call agent. The IP address should be configured before adding endpoints.

SubNet Mask

The sub-netmask of the VISM IP interface.

Daughter Card Serial Num

A unique value for each VISM daughter card, entered in nvram by manufacturing. The serial number is on the non-volatile RAM on the VISM daughter card.

Daughter Card Desc

Describes the VISM daughter card.

Daughter Card HW Rev

Hardware revision number for the daughter card.

vismDspHealth

The health of the DSPs as a percentage of the total DSPs currently functional.

vismEcanDspCnt

No. of Echo Canceller DSPs the VISM card need to be configured with from a pool of 12 multi-purpose DSPs. Remaining DSPs are used for compression.

Ecan Encoding

Voice encoding type, Mu-law or A-law. Mu-law is returned for T1 lines and A-law is returned for E1 lines.

vismEcanCnfIdlePattern

Echo Canceller pattern for Idle code.

  • Mu-Law : 1 - 7f, 2 - ff, 3 - 7f or ff, 4 - f7

  • A-Law : 1 - None, 2 - 54, 3 - 55, 4 - Programable Idle code.

  • DEFVAL : pattern3 (7f or ff) for Mu-law and pattern2 (54) for A-Law.

vismEcanCnfIdleDirection

vismEcanCnfNR

Echo Canceller NR (Non Linear Processor Re-enable).

  • 1 - Restore NLP on low energy

  • 2 - Restore NLP on end of call.

  • This parameter is applicable only when ToneDisable=G.165.

  • NLP is also known as Noise Matching.

vismEcanCnfNoiseMatch

Echo Canceller Noise Matching.

  • 1 - Phase randomize low level residual

  • 2 - Inject noise in place of low level residual.

vismEcanToneDisable

Echo Canceller Disable on Modem Tone. This parameter determines the behaviour of the echo canceller in the presence of a modem.

  • 1 - Ignore 2100 Hz modem answer tone;

  • 2 - G.164 mode;

  • Disable the canceller for all the tones, phase reversing or not.

  • 3 - Reserved; SETting the value to reserve(3) results in BadValue error.

  • 4 - G.165 mode;

Disable the canceller for Phase reversing tone only. (V.8 modulated phase reversing tone as well as the V.fast non standard phase reversing tone)

The default value is g-165.

Comp Packet (bytes)

Compressed output packet size. This value is used in the DSP interface API commands to configure the DSPs for the maximum packet size.

The valid values are 80 and 160 only.


Note   In the future this parameter will be applicable only in VoAAL1 mode.

The default value is 80.

Echo Return Loss

Provisions the return echo lost, i.e the db loss of the echo that the DSPs are supposed to cancel.

The default value is 6 db.

Packetization Period

This object is used to provision the packetization period to be applied. This object is applicable for VoIP adaptation only. For VoAAL2 adaptations, the packetization period is derived from the profile table entry. For VoAAL1 adaptation, it is fixed at 5.875 ms.

  • tenms (10),

  • twentyms (20),

  • thirtyms (30),

  • fourtyms (40)

The default value is tenms.

Jitter Delay Mode

Provisions the jitter buffer mode to apply to a call connection. Possible values are:

  • fixed—use a constant jitter buffer size, which is defined by the vismJitterInitialDelay mib variable.

  • adaptive—let the DSP pick the optimal value for the call connection.

The default value is fixed.

vismJitterInitialDelay

Defines the jitter buffer size. If the vismJitterDelayMode is set to fixed, the jitter buffer is fixed at this value for the call. If vismJitterDelayMode is adaptive, this is the initial jitter buffer size, and the DSP will adapt to an optimal size.

The valid range is from 1 - 100.

The valid increments for template 1 include: 1, 10, 20,30, 40, 50, 60, 70, 80, 90, 100

The valid increments for template 2 include: 1, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55, 60, 65, 70, 75, 80, 85, 90, 95, 100.

When the template of the card changes, either from template 1 to template 2, or vice versa, the value will be implicitly set to 60 (the default value).

Adaptive Gain Control

If set to on, the DSP will adjust the gain of the of the call connection to an optimal value.

The default value is off.

Codec Template Selection

This attribute describes the Codec template currently configured on the VISM card. The value refers to an index to the vismCodecTemplate table. This template is applicable for all connections on the card.

When a switch is made to a new template, the number of channels (endpoints) in use will be checked to ensure the switch will not occur if there are more endpoints active at the present time than what the new template (vismCodecTemplateMaxChanCount) allows.

Also whenever an attempt is made to add a new endpoint for any template, this template maximum number will limit the number of endpoints that may be added for this template.

Switching Mode

The connection model for the VISM card. After this parameter is modified, theVISM card resets to operate in the specified mode. The features of each mode are as follows:

  • voipSwitching—VoIP mode

  VISM interacts with the Call Agent using XGCP protocol, bearer path is VoIP (AAL5). Currently this mode offers CAS Backhaul feature. This mode corresponds to VISM release 1.5 Utah and 1.5 South Carolina.

  • aal2Trunking—AAL2 Trunking mode

  VISM does not interact with the Call Agent. Bearer Path is AAL2. Currently this mode offers trunking of CAS & PRI signaling. This mode corresponds to VISM release 1.5 Alabama.

  • aal1Svc—AAL1 SVC mode

  VISM interacts with Call Agent using XGCP protocol over AAL5 control PVCs. In this mode, bearer path is VoAAL1 and the bearer connections are SVCs. i.e VISM dynamically sets-up and tears down bearer connections. This value is applicable in VISM2.0 and onwards.

The default value is voipSwitching


Note   Only the CLI command, cnfvismmode can modify this parameter.

Available Ds0 endpoints

Number of DS0s available for new connections on VISM. This is modified by the VISM firmware after each connection is set up.

CAC Enable/Disable

Determines whether CAC (Connection Admission Control) functionality is applied on the VISM card; this is done on a per PVC basis. For some applications, the CAC functionality may not be required and in that case, it has to be disabled on a card basis.

The default value is enable.

PVC Protection

Use the PVC Protection Parameters dialog to configure a PVC protection scheme. The PVC Protection Parameters dialog are described in Table 12-3.

Only the vismChanPreference and vismChanLocking parameters will have read-write access. Other parameters will be read-only.


Table 12-3: PVC Protection Parameters Dialog
Parameter Description

Logical Channel Number

Logical Channel Number for the PVC. Note that only two PVCs are supported for VoIP.

The value of the range is 131..510.

VISM Slot

This VPI together with the local VCI and NSAP represents the local end point in this connection.

The value of the range is 0...255.

VISM Chan

This VCI together with the local VPI and NSAP represents the local end point in this connection.

The value of the range is 0..65535.

PXM VPI

This VPI together with the remote VCI and NSAP represents the remote end point in this connection.


Note   This parameter is required only if vismMastership is set to master.

PXM VCI

This VCI together with the remote VPI and NSAP represents the remote end point in this connection.


Note   This parameter is required only if vismMastership is set to master.

PXM NSAP

This NSAP is 20 bytes binary, among these 20 bytes: 13 bytes as prefix, 2 bytes for Cisco ID, 1 byte rsvd, 3 bytes for logical interface: slot (1 byte) and port number (2 bytes), the last byte is for SEL.


Note   This parameter is required only if vismMastership is set to master.

Protection

This object is used to configure a PVC protection group (or redundant group) with the PVCs protecting each other. Currently only two PVCs are supported in a protection group. One of them is primary and the other one is secondary. This is intended for PVCs designated to carry control traffic and needs to be protected. (However the same PVC may also be used to carry VoIP bearer traffic or other traffic).

Channels that are protected share the following characteristics:

  • They are monitored for their health (including emission of traps in case of state changes)

  • An active channel is protected by another protected channel which is standby. This means when an active channel fails, switchover to another channel will happen if one is available.

  • It is also possible to do a forced switchover (through locking). Even in the case of forced switchover, switchover to another channel, which is in standby, will happen.

  • Channels may be locked to force switchover and/or to take the channel out of service in a graceful fashion.

This object takes the default value of unprotected during the creation of the table entry. Once the primary and secondary channels have been created as unprotected channels, they can be protected by doing a SET on the primary channel by specifying the vismChanProtection as protected and by specifying the vismChanFallbackLcn as the LCN number of the secondary channel.

The sequence of operations for setting up the protection group is:


Step 1   Add primary channel as unprotected.

Step 2   Add secondary channel as unprotected. The PCR value for the secondary should be the same as that of the primary.

Step 3   Do a SET on the primary channel with vismChanProtection set to protectedand vismChanFallbackLcn set to the LCN number of the secondary channel.


This operation sets-up the protection group. The primary channel becomes active and the secondary channel becomes standby. Once the protection group is setup, if the active channel fails, it automatically switches over to the standby. The standby channel then becomes active. The channels can be removed from the protection group by setting this object to unprotected.

Deletion of a protected channel is not allowed. Channels have to be removed from the protection group first before deleting. The sequence of operations for deleting protected channels is:


Step 1   Remove the channels from the protection group by setting vismChanProtection to unprotected.

Step 2   Delete secondary channel.

Step 3   Delete primary channel.


The default value is unprotected.

Preference

This object is used to identify a PVC as primary or secondary. The primary PVC should be added before the secondary. Similarly, secondary should be deleted before deleting the primary.

When the protection group is setup, the primary becomes active and secondary becomes standby. The distinction of primary and secondary is meaningful only if the PVC is protected.

This is a mandatory parameter when adding a PVC.

The default value is primary.

Activity

Indicates whether the PVC is currently used to carry IP traffic or not, and whether it has failed. The possible states are:

  • active - Channel is healthy and is currently designated to carry IP traffic. A channel can only be active if it is also unlocked.

  • standby - Channel is healthy but not designated to carry IP traffic. Switchover to this channel is allowed.

  • failed - Channel is unable to carry any traffic.

  • unknown - Channel is unprotected and hence health of the channel is not monitored.

The default value upon creation of the row will be standby for a protected channel and unknown for an unprotected channel. VISM may then transition a protected channel to active if it determines that this channel should be the one carrying the traffic.

Locking

This object is used to control the switchover of protected channels.

The possible values are:

  • unlock - Transition state to unlock. A channel which is in lock state has to be brought to unlock state for it to be available for switchover.

    • Whether a switchover to a channel is allowed or not is dependent on both vismChanActivityState and vismChanLockingState. A switchover is allowed if its vismChanActivityState is standby and its vismChanLockingState is unlock.

    • Changing the vismChanLockingState to unlock does not cause a change in the vismChanActivityState.

    • A channel which is in unlock state may carry traffic depending on its activity state (active or standby).

  • lock - Transition state to lock. If the activity state is active, it transitions to standby and a switchover occurs to another channel which is standby and unlocked.

    • When a channel is in lock state, switchover to this channel is not allowed.

    • A channel which is in lock state, is always in either standby or failed state. Hence it will not carry any traffic. Switchover to a channel which is in lock state is not allowed.

The default value of this object is unlock. It can be set to locked to force a switchover and/or to perform maintenance operations related to that channel.

A channel that is unprotected will always be in unlock state. It can not be set to lock state.

VOIP Parameters

Use the VOIP Parameters dialog to configure the type of service. (See Figure 12-3.)


Figure 12-3: VOIP Parameters Dialog

The VOIP Parameters dialog are described in Table 12-4.


Table 12-4: VOIP Parameters Dialog
Parameter Description

Control Tos

Used to provision the bitmask used for the TOS (Type of Service) octet for cells carrying the control (xGCP) traffic. The default value is 96 = 0x60 => Precedence = 3. TOS nibble = 0. The bitmask can be only a byte value.

VoIP Bearer

Used to provision the bitmask used for the TOS (Type of Service) octet for cells carrying VOIP bearer (RTP) traffic. The default value is 160 = 0xA0=> Precedence = 5. TOS nibble = 0. The bitmask can be only a byte value.

RTCP Report Interval

Defines the RTCP report interval (defined in RFC 1889). The interval at which the RTCP reports should be sent to participating members. The RTCP reports are not sent at a fixed rate at this interval. Rather, this value is used as a base value to arrive at a random number between 0.5 and 1.5 times this value.

This interval timer also serves the purpose of RTP packets receive timer. At every 5 times this interval, a check is made on a VOIP connection (which is in SENDRECV or RECVONLY x GCP modes) to see if any RTP packets have been received. If not, gateway-initiated DLCX should be sent to the Call Agent.

Currently, this interval timer is a card-specific value, which means the value is configurable on a per card basis and not on a per call basis.

RTP Rcv Timer

Determines if the RTP packets receive timer on VISM needs to be enabled. For some VOIP applications, if a connection is in send-recv mode, after the bearer cut-through is done, the RTP stream should be monitored for RTP packets. If there are no packets received within a time interval specified by 5 seconds, then a Gateway initiated DLCX (Delete connection) should be sent on that connection.

If enabled, the RTP stream is monitored.

SGCP/MGCP

Use the following dialogs to configure SGCP/MGCP protocol parameters.

SGCP/MGCP Parameters

Use the SGCP/MGCP Parameters dialog to configure message transmission parameters. (See Figure 12-4.)


Figure 12-4: SCGP/MGCP Parameters Dialog


The SGCP/MGCP Parameters are described in Table 12-5.


Table 12-5: SGCP/MGCP Dialog Parameters
Parameter
Description

Request Timeout

Determine sthe timeout value used for retransmitting unacknowledged message.

It is the responsibility of the requesting entity to provide suitable timeouts for all outstanding commands, and to retry commands when timeouts exceeded. The default value is 500 milliseconds.

Request Retries

The number of retries for a request that exceeds timeout. It is the responsibility of the requesting entity to provide suitable timeouts for all outstanding commands, and to retry when times out. The default value is 3.

RSIP Restart Delay

The Restart Delay Timeout for the restart process.

The purpose of setting the restart timer before sending the Restart In Progress notification to the media gateway controller is to avoid the network congestion during the critical period of service restoration.

-1: infinity which indicates no timeout.

0: immediate timeout which indicates immediate shutdown.

The default value is -1.

RSIP Max Waiting Delay

The maximum waiting delay (MWD) timeout value is used for the Media Gateway to send the Restart In Progress to the Media Gateway Controller.

The default value is chosen in an implementation-dependent manner by the MGCP functionality based on the call volume of the system.

Default Package

Contains the default package name for the MGCP/SGCP protocol and it should have the same value as xgcpCapabilityPackageName.

SGCP/MGCP Packages

Use the SGCP/MGCP Packages dialog to specify the availability of packages. (See Figure 12-5.)


Figure 12-5: SGCP/MGCP Packages Dialog


The SGCP/MGCP Packages parameters are described in Table 12-6.


Table 12-6: SGCP/MGCP Packages Dialog Parameters
Parameter
Description

  • Package Name

Capability Package letter names as follows:

Generic Media Package—G

DTMF package—D

MF Package—M

Trunk Package—T

Line Package—L

Handset Package—H

RTP Package—R

Netwark Access Server Package—N

Announcement Server Package—A

Script Package—S

  • Enabled

Enables/disables the Package Capability.

SGCP/MGCP Peers

Use the SGCP/MGCP Peers dialog to configure peer entries. (See Figure 12-6.)


Figure 12-6: SGCP/MGCP Peers Dialog


The SGCP/MGCP Peers parameters are described in Table 12-7.


Table 12-7: SGCP/MGCP Peers Dialog Parameters
Parameter
Description

Peer Number

The value is the same as mgcNumber from MGMIB.

Protocol Number

The value is the same as mgcProtocolNumber from MGMIB. (Serves as an index to this table?)

UDP Port

Configures the local UDP port used by the SGCP and MGCP protocols to communicate with the call agent. This parameter together with vismIpAddress identifies the local end of an SGCP/MGCP connection.

The default value is 2427 WHAT UNITS?.

ALTERNATE DEFINITION:

Configures the UDP port of the peer used by the XGCP protocol variant referred by this row.

The default value is 2427. Upon creation of the row, this parameter will be set to the default value. The value can be modified once the row has become active.

SGCP/MGCP Messages

Use the SGCP/MGCP Messages dialog to configure peer message statistics. (See Figure 12-7.)


Figure 12-7: SGCP/MGCP Messages Dialog


The SGCP/MGCP Messages parameters are described in Table 12-8.


Table 12-8: SGCP/MGCP Messages Dialog Parameters
Parameter
Description

Message Success Count

The number of successful messages that communicate with the Media Gateway Controller on that IP address. Successfu l messages apply to both transmit and receive messages.

Transmit: Positive ACK is received from the Media Gateway Controller

Receive: Positive ACK is sent to the Media Gateway Controller. This implies that the format of the message is correct and the request can be fulfilled.

MGP IP Address

The IP address of the Media Gateway Controller. The value of this parameter is the same as xgcpIpAddress of XGCP-MIB.

Message Fail Count

The count of failed messages that communicate with the Media Gateway Controller on that IP address. Failed messages apply to both transmit and receive messages.

Transmit: Either NAK is received from the MGC or message times out waiting for ACK.

Receive: Format of the received message is bad or the request can not be fulfilled.

SGCP/MGCP Message Counts

Use the SGCP/MGCP Message Counts dialog to configure message statistics. (See Figure 12-8.)


Figure 12-8: SGCP/MGCP Message Counts Dialog


The SGCP/MGCP Message Counts parameters are described in Table 12-9.


Table 12-9: SGCP/MGCP Message Counts Dialog Parameters
Parameter
Description

IP Address

The IP address of the Media Gateway Controller. The value of this parameter is the same as xgcpIpAddress of XGCP-MIB.

CRCX

The count of CRCX (Create Connection) messages received from the call agent since reset.

MDCX

The count of MDCX (Modify Connection) messages received from the call agent since reset.

DLCX Recv

The count of DLCX (Delete Connection) messages received from the call agent since reset.

DLCX Sent

The count of DLCX (Delete Connection) messages sent to the call agent since reset.

RQNT

The count of RQNT (Request Notify) messages received from the call agent since reset.

NTFY

The count of NTFY (Notify) messages sent to the call agent since reset.

AUEP

The count of AUEP (Audit Endpoint) messages received from the call agent since reset.

AUCX

The count of AUCX (Audit Connection) messages received from the call agent since reset.

RSIP

The count of RSIP (Restart In Progress) messages sent to the call agent since reset.

SGCP/MGCP Failures

Use the SGCP/MGCP Failures dialog to configure message failure statistics. (See Figure 12-9.)


Figure 12-9: SCGP/MGCP Failures Dialog


The SGCP/MGCP Failures parameters are described in Table 12-10.


Table 12-10: SGCP/MGCP Failures Dialog Parameters
Parameter
Description

IP Address

mgcResolutionTable???

mgcResolutionIpAddress

Denotes the IP Address of the entity. Once the row has become active, this value may not be changed. To change the IP address, an entry will have to be removed and a new entry will have to be added.

CRCX Fail

This refers to the count of CRCX (Create Connection) messages received from the call agent that were responded to with a failure return code.

MDCX Fail

This refers to the count of MDCX (Modify Connection) messages received from the call agent that were responded to with a failure return code.

DLCX Recv Fail

This refers to the count of DLCX (Delete Connection) messages received from the call agent that were responded to with a failure return code.

DLCX Sent Fail

This refers to the count of DLCX (Delete Connection) messages sent to the call agent since reset.

RQNT Fail

This refers to the count of RQNT (Request Notify) messages received from the call agent that were responded to with a failure return code.

NTFY Fail

This refers to the count of NTFY (Notify) messages sent to the call agent for which a response with failure return code was received or which timed out waiting for a response.

AUEP Fail

This refers to the count of AUEP (Audit Endpoint) messages received from the call agent that were responded to with a failure return code.

AUCX Fail

This refers to the count of AUCX (Audit Connection) messages received from the call agent that were responded to with a failure return code.

RSIP Fail

This refers to the count of RSIP (Restart In Progress) messages sent to the call agent for which a response with failure return code was received or which timed out waiting for a response.

SRCP

The following set of dialogs control administration and configuration of theSRCP protocol.

SRCP Parameters

Use the following parameters to coordinate SRCP communications with the call agent (See Figure 12-10.)


Figure 12-10: SRCP Parameters Dialog


The SRCP parameters are described in Table 12-11.


Table 12-11: SRCP Parameters Dialog Parameters
Parameter
Description

SRCP version

The name of the SRCP protocol version. E.g. SRCP 1.0.2. If MGMIB is supported, this name corresponds to mgProtocolName in an entry to mgSupportedProtocolTable.

Port number

Configures the UDP port used for SRCP on the system (local UDP port). It is configurable only if the system is in a locked or disabled state (i.e If MGMIB is supported, mgAdministrativeState should be 'locked' before the UDP port can be configured).

SRCP Peers

The SRCP peer administration table contains a set of parameters for each SRCP peer/Media Gateway Controller.


Figure 12-11: SRCP Peers Dialog


The SRCP Peers parameters are described in Table 12-12.


Table 12-12: SRCP Peers Dialog Parameters
Parameter
Description

Peer Name

Denotes the name of the SRCP peer. If MGMIB is supported, this is the same as the mgcName from the mgcTable. It is provided here as a read-only parameter as a convenience feature.

Peer ID

Identifies the SRCP peer and serves as index to this table. If MGMIB is supported, this is the same as the mgcNumber fromthe mgcTable.

Port Number

Configures the UDP port of the SRCP peer.

Heartbeat Interval

Configures the length of the heartbeat interval, in milliseconds. If 0, heartbeat for this peer is not monitored. The heartbeat interval less than 100 is not allowed (except 0).

Last Heartbeat

The time since the last heartbeat was received, in milliseconds. This represents the difference between the current time and the last time an SRCP command was received.

A value of 0 shall be returned if the heartbeat is not monitored.

Even if the heartbeat is monitored, a value of 0 shall be returned if any of the following is true:

i) the system is locked or disabled (as indicated by mgAdministrativeState of MGMIB or xgcpOperStatus of XGCP MIB).

ii) the srcpPeer is unassociated (as indicated by mgcAssociationState of MGMIB).

Max PDU Size

Configures the maximum UDP PDU size, in octets, that may be used for SRCP communications with the peer.

This value may not be configurable for all agents.

SRCP Peers Statistics

The SRCP Peers Statistics table contains statistics concerning SRCP communications with a particular peer/Media Gateway Controller.


Figure 12-12: SRCP Peers Statistics Dialog


The SRCP Peers Statistics parameters are described in Table 12-11.


Table 12-13: SRCP Peers Statistics Dialog Parameters
Parameter
Description

MGC Name

Denotes the name of the media gateway controller. This corresponds to a domain name under which the MGC could also be registered in a DNS.

IP

The IP address of the SRCP peer and serves as index to the table.

Bad Packets

packetsDiscardedCnts??

The number of objects that were received and discarded. The packets may get discarded because of indecipherable PDUs like bad protocol version, bad command verb etc, or because of unknown transaction IDs (in case of SRCP clients).

AUGW In

augwCnts??

The total AUGW commands received from the peer on this IP address.

AUGW Fail

Media gateway: The total AUGW commands received that were responded to with a failure return code.

Media gateway controller: The total number of AUGW commands sent which were timed out without a response or for which a response with failure return code was received.

AULN In

The total number of AULN commands received from or sent to the peer on this IP address.

AULN Fail

Media gateway: The total number of AULN commands received that were responded to with a failure return code.Media gateway controller: The total number of AULN commands sent which were timed out without a response or for which a response with failure return code was received.

NTFY In

The total number of NTFY commands received from or sent to the peer on this IP address.

NTFY Fail

Are these options?

Media gateway : The total number of NTFY commands sent which were timed out without a response or for which a response with failure return code was received.

Media gateway controller: The total number of NTFY commands received that were responded to with a failure return code.

RQNT In

The total RQNT commands received from or sent to the peer on this IP address.

RQNT Fail

Media gateway: The total RQNT commands received that were responded to with a failure return code.

Media gateway controller: The total RQNT commands sent which were timed out without a response or for which a response with failure return code was received.

Media Gateway

The following dialog s are used to configure the Media Gateway Controller protocol.

Media Gateway Parameters

The following parameters pertain to the media gateway as a whole, such as global parameters and state(See Figure 12-13.)


Figure 12-13: Media Gateway Dialog


The Media Gateway parameters are described in Table 12-11.


Table 12-14: Media Gateway Dialog Parameters
Parameter
Description

Media Gateway Name

Denotes name of the media gateway, as it is identified by media gateway controllers. This corresponds to a domain name under which the Media Gateway could also be registered in a DNS.

Admin State

Indicates the current admin state of the Media Gateway. The possible admin states are:

  • inService— Media gateway is ready to provide service. In this state, Media Gateway will respond to connection control requests, emit autonomous messages to Media Gateway Controllers as applicable, etc.

  • commandedOutOfService—Media Gateway does not provide service and all resources have been released. In this state, Media Gateway will not respond to any connection control requests nor emit autonomous messages.

  • pendingOutOfService—This is a transitional state prior to going outOfService. In this state the Media Gateway provides service but does not accept new service requests (i.e creation of connections); will transition to outOfService according to mgShutDownGraceTime.

Admin State Control

This control parameter is used to change the service state of the Media Gateway from inService to outOfService or from outOfService to inService. The resulting service state of the gateway is represented by mgAdministrativeState. If set, this parameter triggers the following:

  • inService: transition mgAdministrativeState to inService. In the course, the MG's MGCs may get notified of this transition, e.g. in the case of MGCP through emission of RSIPs to registered call agents according to policy.

  • forcefulOutOfService: Take the gateway out-of-service forcefully. This releases any resources at the Media Gateway. In the course, the MGCs may get notified of this transition, e.g. in the case of MGCP through emission of RSIPs to registered call agents according to policy.

  • gracefulOutOfService: Take the gateway out-of-service gracefully. If there are no resources existing, mgAdministrative transitions to outOfService immediately. If resources exist, mgAdministrativeState transitions to pendingOutOfService thus initiating a graceful shutdown.In the course, the MG's MGCs may get notified of this transition, e.g. in the case of MGCP through emission of RSIPs to registered call agents according to policy.

Shutdown Grace Time

The time in seconds after which an MG will transition from shuttingDown to locked. A value of -1 indicates that the MG allows for draining, i.e. will automically transition after the last resources in use have been released. Otherwise, it essentially indicates the amount of time an MGC has to perform any cleanup, e.g deletion of connections etc.

Maximum Number of MGC's

The maximum number of MGCs that the MG can be configured with. In other words, the maximum number of entries that mgcTable can have. If 0, there is no limitation.

Supported Protocols

The Supported Protocol table identifies the protocols and revisions a media gateway supports.


Figure 12-14: Supported Protocols Dialog


The Supported Protocols parameters are described in Table 12-11.


Table 12-15: Supported Protocols Dialog Parameters
Parameter
Description

Media Gateway Protocol

A control protocol and its revision supported by the call gateway. example: 'MGCP 0.1 11/9/99'

The protocol can be one of the control protocols like MGCP or it can be a signalling backhaul protocol or it can be resource co-ordination protocol like SRCP.

Protocol Number

Serves as index to this table.

Call Agents

The following dialogs pertain to the media gateway controllers (Call Agents) and the media gateway's association with them.

Media Gateway Controllers

Use the Media Gateway Controllers table to specify Call Agents.


Figure 12-15: Media Gateway Controllers Dialog


The Media Gateway Controllers parameters are described in Table 12-11.


Table 12-16: Media Gateway Controllers Dialog Parameters
Parameter
Description

Controller Domain Name

Denotes the name of the media gateway controller. This corresponds to a domain name under which the MGC could also be registered in a DNS.


Note   Once the row has become active, this value may not be modified.

Number

Serves as an index to this table.

Association State

Represents the state of the association between the Media Gateway and the Media Gateway Controller. The possible values are:

  • mgcUnassociated : MG and MGC are not associated. E.g. in the case where MGCP is the coordination protocol, it means no subscription to autonomous messages such as RSIP but control requests would be answered.

  • mgcAssociated : MG and MGC are associated. E.g. in the case where MGC is the coordination protocol, it means MGC is subscribed to autonomous messages such as RSIP.

  • mgcAssociatedCommLoss : Associated but MGC unreachable.

Association State Control

Used to control the association state, as represented by mgcAssociationState. The possible value for a set operation on this parameter are:

  • mgcUnassociate : Transition from any state to unassociated.

If registered, MG will initiate unregistration.

  • mgcAssociate : Transition to associated. If applicable, MG will register with MGC. If MGCP is the coordination protocol, MG will send RSIP.

If MG cannot establish communication, it will subsequently transition into mgcAssociatedCommLoss.

If MG is already associated with MGC, no transition will take place and mgcAssociationState shall not change.

mgcClear : No action will be taken. This means that the Media Gateway will not initiate any association/unassociation.

mgcRowStatus

Controls the creation and deletion of a table entry. An entry may be created using the 'createAndGo' option. When the row is successfully created, the RowStatus would be set to 'active' by the agent. An entry may be deleted by setting the RowStatus to 'destroy'. Other options such as `CreateAndWait', 'notInService', 'notReady' will not be used.

For creating the row, a value for mgcName must be provided. To all other parameters, defaults defined by the agent implementation may apply.

Deletion of a row with mgcAssociationState other than unassociated shall be rejected.

Configured Protocols

Use the Configured Protocols table to specify relationships between the Media Gateway Control table and a supported protocol.


Figure 12-16: Configured Protocols Dialog


The Configured Protocols parameters are described in Table 12-11.


Table 12-17: Configured Protocols Dialog Parameters
Parameter
Description

Add or Delete Protocols

Controls the creation and deletion of a table entry. An entry may be created using the 'createAndGo' option. When the row is successfully created, the RowStatus would be set to 'active' by the agent. An entry may be deleted by setting the RowStatus to 'destroy'. Other options such as `CreateAndWait', 'notInService', 'notReady' will not be used.

Modification of the row is not allowed.

Number

Serves as index to this table.

Protocol Number

Serves as index to this table.

CAN BOTH BE TRUE??

Internal Name Resolution

Use the Internal Name Resolution parameters table to specify the name to IP address mapping for each of the MGCs. This mapping can be used where a DNS is not applied. Several addresses may be associated with a single name.


Figure 12-17: Internal Name Resolution Dialog


The Call Agents parameters are described in Table 12-11.


Table 12-18: Call Agents Dialog Parameters
Parameter
Description

Domain Name

Denotes the name of the media gateway controller. This corresponds to a domain name under which the MGC could also be registered in a DNS. Once the row has become active, this value may not be modified.

Index

Serves as index to this table.

IP Address

Denotes the IP Address of the entity. Once the row has become active, this value may not be changed. To change the IP address, an entry will have to be removed and a new entry will have to be added.

Comm State

Indicates whether the address is the one currently applied for communications with the system of that name.

  • csActive - name resolves to that IP address

  • csInactive - IP address currently not in use.

On creation of the row, this value will be csInactive, although it may transition immediately afterwords to active, triggering the applicable trap.

Preference

Allows to optionally configure primaries and secondaries. Can be used by the MG in the selection of an IP address if multiple IP addresses are available for the same name.

Row Status

Controls the creation and deletion of a table entry.

An entry may be created using the 'createAndGo' option. When the row is successfully created, the RowStatus would be set to 'active' by the agent thereby creating an endpoint. An endpoint may be deleted by setting the RowStatus to 'destroy'. Other options such as `CreateAndWait', 'notInService', 'notReady' will not be used.

On creation of the row, values for mgcResolutionName, mgcResoltuionIpAddress, and mgcResoltuionPreference need to be supplied.

CAS Management

The following dialogs are used to configure the CAS backhaul feature on VISM.

CAS Parameters

The following are CAS general management parameters.


Figure 12-18: CAS Parameters Dialog


The CAS parameters are described in Table 12-11.


Table 12-19: CAS Parameters Dialog Parameters
Parameter
Description

vismCasVariantName

A string identifier for the CAS variant. It is used as index to the table. The maximum length allowed is 64 bytes.

vismCasFileName

The file which contains the signal definition and the Finite State Machine definition for the CAS variant. The name is supplied during the creation of the table entry.

Modifying the value of this parameter is not allowed.

Upon the creation of the table entry, the file will be downloaded from a tftp server configured in the vismTftpServerDn parameter and the CAS finite state machine will be initialized based on the information contained in this file.

This parameter is required to create en entry in this table.

vismCasTRinging

The ringing time in seconds for the Cas Variant. Ringing remains on until this timer expires or until an off hook is received.

vismCasDigitMethod

The default digit method to be used for digit collection. If the digit method can not be derived from the digit map specified by the call agent in the XGCP message, this digit method will be used.

vismCasInterdigitTpart

The partial dial timing in seconds and is used along with a digit map as the inter-digit timer. The timer is not started until the first digit is entered, and the timer is restarted after each new digit is entered until either a digit map match or mismatch occurs.

vismCasInterdigitTcrit

The critical timing in seconds. If used along with a digit map, the timer is started when the last digit is received. i.e and when no more digits are required for a digit map match. After this timer expires, the digit map match is assumed to be complete. If used without a digit map, the timer is started immediately and cancelled (but not restarted) as soon as a digit is entered.

vismCasInterdigitTMF

The interdigit timeout value for MF digits. The timeout value is in seconds.

vismCasVariantState

NO DEFINITION AVAILABLE

vismCasRowStatus

NO DEFINITION AVAILABLE

vismCasCountryCode

NO DEFINITION AVAILABLE

CAS BackHaul Management

The following parameters are specific to the CAS BackHaul feature.


Figure 12-19: CAS BackHaul Management Dialog


The CAS BackHaul Management parameters are described in Table 12-11.


Table 12-20: CAS BackHaul Management Dialog Parameters
Parameter
Description

vismCasXgcpVariantName

A string identifier for the CAS variant. It is used as index to the table.

vismCasXgcpFileName

The file which contains the signal definition and the Finite State Machine definition for the CAS variant.

vismCasXgcpMaxReXmitTime

The maximum timeout value in milliseconds, used for retransmitting unacknowledged XGCP messages at the Call Agent - CAS/PBX interface. The value can be set in 10 ms increments.

vismCasXgcpInitialReXmitTime

The initial timeout value in milli seconds, used for retransmitting unacknowledged XGCP messages at the Call Agent - CAS/PBX interface. The increments for this value are 10 ms.

vismCasXgcpMaxRetries

The number of retries for a message that exceeds vismCasXgcpMaxReXmitTime or vismCasXgcpInitialReXmitTime.

Supported Codec Templates

Use the Supported Codec Templates table dialog to define the DSP templates that are applicable on a card basis. A table defines the set of codecs supported in each template and the maximum number of DS0s supported on the VISM card for a given template (See Figure 12-20.)


Note   This table is supported only for the aal2Trunking VISM type.


Figure 12-20: Supported Codec Templates Dialog


The Supported Codec Templates Table parameters are described in Table 12-21.


Table 12-21: Supported Codec Templates Dialog Parameters
Parameter
Description

vismCodecCnfIndex

An index to this table.

  • 1—G.711u

  • 2—G.711a

  • 3—G.726-32K

  • 4—G.729a

  • 5 —G.729ab

  • 6—clear channel

vismCodecName

The name of the codec for example index 1 will have G.711u as the codec name index 2 will have G.711a as the codec name and so on....

vismCodecPktPeriod

The packetization period for a particular codec in millisecs.

  • for G.711a allowed values are 10 & 20

  • for G.711u allowed values are 10 & 20

  • for G.726-32K allowed values are 10 ,20 30 & 40

  • for G.729a allowed values are 10, 20 ,30 & 40

  • for G.729ab allowed values are 10, 20, 30 & 40

  • for clear channel allowed values are 10 and 20

Card/Endpoints (VISM)

Use the Card/Endpoints table dialog to create and configure new endpoints (Table 12-21.)


Figure 12-21: Card/Endpoints (VISM) Dialog


The Card/Endpoints (VISM) dialog parameters are described in Table 12-21.

Table 12-1 Card/Endpoints (VISM) Dialog parameters

Parameter Description

Line

Identifies the line. This should be at the level of a DS1 (due to restrictions to the number of channels that can be represented in a bit map). Generally, this will correspond to the ifIndex of the physical interface terminating the line. Where the line is physically not a DS1 but higher (e.g. DS3), an algorithm shall be applied that logically partitions the line into virtual DS1s which are identified by this parameter. Once the row has become active, this value may not be changed.

Endpoint

Identifies endpoint as it is known by the NE. The EndpointNumber is unique for the entire Media Gateway and ranges from 1 to the maximum number of endpoints that the media gateway can support.

Name

Identifies endpoint as it is known by the MGC. If MG and MGC use a mutually agreed upon convention, this may be supplied by the agent, i.e. be read-only.

Speed

Indicates the endpoint's bandwidth, in Kbps. Typically, this will be 64 times the number of channels terminated by the endpoint.

State

Indicates the state of the endpoint.

  • active - the endpoint is in service and operational.

  • failed - the endpoint is in service but not operational, e.g. because a line that the endpoint belongs to is in a state of service affecting alarm.

  • degraded - the endpoint is in service but not fully operational, e.g. in cases with endpoints with channels on multiple lines, when one of the lines is in a state of service affecting alarm.

If MGCP is used as the control protocol, the following transitions will generally trigger an RSIP command:

  • from active/degraded to failed

  • from failed to degraded/active

Transitions between active and degraded will generally not trigger emission of RSIP.

ChannelMap

Bit map of DS0s used by the endpoint. Bit positions set to '1' represent DS0s used by the endpoint. The position corresponds to the DS0 number.

MGs may have restrictions regarding the creation of endpoints (e.g. only one channel, only consecutive channels, only channels of one line). Once the row has become active, this value may not be changed.

Row Status

Controls the creation and deletion of a table entry.

An entry may be created using the 'createAndGo' option. When the row is successfully created, the RowStatus would be set to 'active' by the agent thereby creating an endpoint. An endpoint may be deleted by setting the RowStatus to 'destroy'. Other options such as `CreateAndWait', 'notInService', 'notReady' will not be used.

On creation, values for mgEndpointLineNumber and mgEndpointChannelMap have to be supplied.

Displaying and Configuring Lines

There are four ways to select the line (using either a front or rear view of the card) to display the appropriate line configuration dialog:

To display the configuration parameters for a particular line/port, select the name of the category from the Category popup menu at the top of the dialog. The categories of line configuration available are:

Physical Line Config (dsx1)

Use the Physical Line Configuration dialog to view and configure dsx1 physical line configuration information. (See Figure 12-22.)


Figure 12-22: Physical Line Config (dsx1) Dialog

The Physical Line Configuration (dsx3) dialog parameters are described in Table 12-22.


Table 12-22: Physical Line Config (dsx1) Parameters
Parameter Description

Line Num

Line number.

Type

Line type Choose one from the popup menu:

  • dsx3CbitParity

  • g832-g804

  • dsx3M23

  • g751

  • dsx3Unframed

  • e3Unframed

Connector

Line coding. Can be dsx3B3ZS or e3HDB3.

Line Enable

Choose enable or disable.

Coding

Line length. Choose lessThan225 or moreThan225 from the popup menu.

Length

Line OOF decision criteria. Can be fBits30f8 or fBits3Of16.

Xmt Clock

Choose checkCbits or ignorebits from the popup menu.

If checkCbits, AIS is declared when 1010 pattern is found and C-Bits are all zero. If ignorebits, an AIS condition is declared when the AIS pattern 1010 is detected, regardless of the state of the C-Bits.

Loopback

Loopback configuration of the DS3/E3 interface. Choose one from the popup menu:

  • dsx3NoLoop

  • dsx3RemoteLineLoop

  • dsx3LocalLineLoop

  • dsx3InbndLocalLoopback

Code Sent

Far-end alarm and control (FEAC) code validation criteria.

Choose fFEACCodes4Of5 or fFEACCodes8Of10 from the popup menu.

If FEACCodes4Of5 is specified, a valid FEAC codes is declared if four of five codes match. If fFEACCodes8Of10 is specified, a valid FEAC code is declared when eight of ten codes match.

DS0's Used

Indicates the bit-oriented code to transmit over the far-end alarm and control (FEAC) channel. Choose one from the popup menu:

  • dsx3SendNoCode

  • dsx3SendLineCode

  • dsx3SendLineCode

  • dsx3SendPayLoadCode

  • dsx3SendResetCode

  • dsx3SendDS1LoopCode

  • dsx3SendSendTestPattern

Loopback code Detect

Line transmit clock source. Choose one from the popup menu:

  • backplaneClk

  • recoverClk

  • localClk

Enable BERT

Bitmap of the dsx3 FarEnd line loopback status bits.

To modify the parameters, make the changes you want and click Modify.

Line Config (VISM)

Use the following parameters to configure lines, line alarms, and realtime counters.


Figure 12-23: Line Config (VISM) Dialog



Table 12-23: Line Config (VISM) Dialog Parameters
Parameter
Description

Line

The line number. This should be at the level of a DS1 (due to restrictions to the number of channels that can be represented in a bit map). Generally, this will correspond to the ifIndex of the physical interface terminating the line. Where the line is physically not a DS1 but higher (e.g. DS3), an algorithm shall be applied that logically partitions the line into virtual DS1s which are identified by this parameter.

Enable

Echo cancellation feature is enabled or disabled.

Ecan Tone Disable

Echo Canceller Disable on Modem Tone. This parameter determines the behaviour of the echo canceller in the presence of a modem.

  • 1 - Ignore 2100 Hz modem answer tone;

  • 2 - G.164 mode

  Disables the canceller for all the tones, phase reversing or not.

  • 3 - Reserved;

  SETting the value to reserve(3) results in BadValue error.

  • 4 - G.165 mode

  Disables the canceller for Phase reversing tone only.
  (V.8 modulated phase reversing tone as well as the V.fast non- standard phase reversing tone)

Ecan Re-enable

Echo Canceller Re-enable (NRN). This parameter determines when an echo canceller re-enables and begins cancellation after it has been disabled due to detection of a modem answer tone.

  • 1- Re-enable canceller when modem data gone(low energy)

  • 2 - Re-enable at end of call

This parameter is not applicable when ToneDisable=Ignore.

MaxTail (ms)

Maximum TAIL in milliseconds (ms).

Should be set just higher than the worst round trip delay anticipated. Convergence times may increase for longer tails and more resource will be used. Only following discrete values are allowed:

  • 24

  • 32

  • 48

  • 64

  • 80

  • 96

  • 112

  • 128

The default value is 32.

Residual Echo Control

Residual Echo Control(REC) instructs the canceller how to treat echo remaining after cancellation. When set to cancelOnly, REC is diabled.

When set to suppressResidual, the residual echo is replaced with silence.

When comfortNoise is chosen, noise is injected in place of residual echo at the same level as the ambient noise at the near end.


Note   SETting the value to reserved(3) results in BadValue error.

VAD Compres

VAD (Voice Activitiy Detection) Enable or Disable on the Compression DSPs.

The default value is Enable.

vismSignalingType

The type of signaling used for the line.

  • CAS - Channel Associated Signaling

  • CCS - Common Channel Signaling

  • none - no signaling used.


Note   This cannot be modified if endpoints are present and if/or if cids/ccs channels are associated with this line in aal2Trunking mode.


Note   The CAS signaling type is not allowed if any of the DS0's on this line have loop back set to RemoteLoop or if any of the DS0's has InsertLocalCas enabled.

vismCcsChannels

Describes the CCS signaling channels or DS0s (also refered to as D-channel). It is used only for lines configured as CCS signaling type. It is a bit map of the DS0s configured as D channel. A one in the bit position represents that DS0 as the D channel. In most of the applications, only one D channel per T or E span is required. However, since some applications may require multiple D channels, this is supported by providing a bit map. This parameter is set by 'addccs' CLI command.

VISM ds0's

Use the VISM ds0's dialog parameters to configure the DS0s on T1/E1 lines of VISM.


Figure 12-24: VISM ds0's Dialog



Table 12-24: VISM ds0's Dialog Parameters
Parameter
Description

ds0IfIndex

Defines the index for this table. The index value is derived from the formula, index = 31 (DS1# - 1) + DS0# where:

  • DS1# - The T1/E1 line number ranges from 1 - 8.

  • DS0# - The DS0 channel number ranges for T1, from 1 to 24, and for E1, from 1 to 31.

ds0RobbedBitSignalling

Turns on/off Robbed Bit Signalling for a given DS0. This only applies to DS0s on a DS1 link.

For E1 links, the value is always off (false).

For T1 links, the default value is true if the line is configured for CAS signaling, the default value is false if the line is configured for CCS signaling or no signaling.

ds-IdleCode

The code transmitted in the ABCD bits when the DS0 is not connected and ds0TransmitCodesEnable is enabled. The parameter is a bitmap and the various bit positions are:

  • Bit 0 (value 1) D bit

  • Bit 1 (value 2) C bit

  • Bit 2 (value 4) B bit

  • Bit 3 (value 8) A bit

This parameter is useful for DS0 conditioning to be done if an alarm condition is detected from the network side. DS0 conditioning is implemented in the trunking application only.


Note   This parameter is not applicable in the CAS backhaulapplication.

The default value is 0.

ds0SeizedCode

The code transmitted in the ABCD bits when the DS0 is connected and ds0TransmitCodesEnable is enabled. The parameter is a bitmap and the various bit positions are:

  • Bit 0 (value 1) D bit

  • Bit 1 (value 2) C bit

  • Bit 2 (value 4) B bit

  • Bit 3 (value 8) A bit

This parameter is useful for DS0 conditioning to be done if an alarm condition is detected from the network side. DS0 conditioning is implemented in the trunking application only.


Note   This parameter is not applicable in the CAS backhaul application.

The default value is 15.

ds0ReceivedCode

The code received in the ABCD bits. The parameter is a bitmap and the various bit positions are:

  • Bit 0 (value 1) D bit

  • Bit 1 (value 2) C bit

  • Bit 2 (value 4) B bit

  • Bit 3 (value 8) A bit

ds0BundleMapped

The endpoint number as specified by mgEndpointNumber of endpoint table. If it is not associated with any endpoint, then it is set to -1.


Note   The endpoint is associated with bearer DS0s only. For signaling channel or DS0 as in the case of CCS channel, there is no endpoint number associated with it and the value is set to -1.

ds0IfType

The interface type associated with the DS0.

ds0 ifType is considered as bearer if the DS0 is used for carrying voice traffic.

ds0 ifType is considered as ccs-signaling, if the DS0 is configured as the D-channel

ds0CasVariantName

The index to the CAS variant table. This parameter can be configured after configuring this DS0 as an endpoint. This parameter cannot be modified while connections exist on this endpoint. The CAS variant table is used for configuring the system parameters associated with various types of CAS signaling methods supported on VISM.

ds0CasCadenceOnTime

This parameter describes the duration of digit tone generation. The value is expresssed in units of milliseconds.


Note   This parameter is applicable only for CAS backhaul applications. Not for trunking applications.

The default value is 75.


hometocprevnextglossaryfeedbacksearchhelp
Posted: Mon Oct 2 21:02:28 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.