Cisco Voice Interworking Service Module Software

VISM 2.2(1) Release Notes

  • Viewing Options

  • PDF (321.5 KB)
  • Feedback
Release Notes for Cisco Voice Interworking Service Module Release 2.2(1)

Table Of Contents

Release Notes for Cisco Voice Interworking Service Module Release 2.2(1)


Features Introduced in Previous Releases of VISM Software

Important Notes

VISM Management Information Base

VISM Redundancy

VISM Call Rate


Limitations and Restrictions

Installation and Upgrade Procedures

VISM Firmware Download Procedure

Installing VISM Software Updates

Initial Conditions

Upgrade Procedure

VISM Boot Code Upgrade Procedure

VISM Downgrade Procedure

Upgrading VISM Software from 1.5(x) to 2.2(1)


Resolved Caveats

Open Caveats

Related Documentation

Obtaining Documentation

World Wide Web

Documentation CD-ROM

Ordering Documentation

Documentation Feedback

Obtaining Technical Assistance

Technical Assistance Center

Cisco TAC Web Site

Cisco TAC Escalation Center

Release Notes for Cisco Voice Interworking Service Module Release 2.2(1)

July 2002

The Cisco Voice Interworking Service Module (VISM) product is supported by Media Gateways. Refer to these release notes for Media Gateway and version level support guidelines.

The VISM Release 2.2(1) is a maintenance upgrade of the VISM Release 2.2(0). There are no new features introduced with this release.

This release is compatible with the Cisco MGX 8850/8250/8230 Release 1.1.40 and 1.2.00 software.

The VISM Release 2.2(1) is supported by the Cisco VISM Installation and Configuration Guide, which is available on the Web at the following locations:


These release notes contain the following sections:

"Important Notes" section

"Installation and Upgrade Procedures" section

"Caveats" section

"Related Documentation" section

"Obtaining Documentation" section

"Obtaining Technical Assistance" section

Features Introduced in Previous Releases of VISM Software

The following list describes the features introduced in previous VISM software releases. All previously released features are supported in VISM Release 2.2(1).

Mid-Call DTMF

Configurable Jitter Buffer

Adjustable Gain

Adjustable Music On-Hold Threshold

Communication Assistance for Law Enforcement Act (CALEA)

MGC Redundancy

External DNS

2 IP Address Support

VoIP Trunking

T.38 Fax Relay

CAS Feature Enhancements:

Programmable Tone Plans

Loop Start, DID, and Delay Dial


Configure Flash Hook and Glare Condition Attributes

Configure ANI and DNIS Digit Order

RFC 3064 Package Support

RFC 2833 Support

VISM Network Continuity Test

Configure PVC OAM Cell Parameters

Verified MGCP 0.1 protocol compliance

PBX CAS event delivery to a Call Agent using MGCP 0.1:

DTMF: Wink and ground start

MF: Wink

TFTP download of CAS variant state machine

Note RFC 3064 CAS packages—BL, MS, and DT—are not supported.

Interoperability enhancements:

Configurable codec strings (IANA naming conventions as well as customized ones).

Codec negotiation with configurable preference order.

Exponential backoff for:

XGCP retry timers.

SRCP retry timers.

Configurable per CAS variant.

DTMF Relay using Cisco-rtp (FRF-11 Annex A based).

Enhancement to Fax/modem up-speed/pass-through procedures:

Configurable CAC failure and carrier loss policies.

Up-speed to clear channel.

Added support for G.726: 16, 24, 32, and 40 kbps, with packetization periods ranging from 10 to 40 ms.

Support for VBR-rt (Variable Bit Rate-Real Time) and VBR-nrt (nonreal time) ATM traffic classes, including traffic shaping to the relevant traffic descriptors.

Configurable VAD model parameter for traffic engineering.

In E1 applications, support for 31 DS0 per span and a total of 248 channels per card.

Tested CRTP support through RPM for voice and voice band data calls.

Verified bearer interoperability with 3810.

Switched PVCs using SGCP 1.5

SDP and SGCP extensions allowing xGCP Call Agent control of AAL2 bearers.

Support of SGCP 1.5 digit maps and error codes.

Support for card level coexistence of switched AAL2 mode (under Call Agent control) and trunked AAL2 mode on PVCs, on an endpoint (DS0) basis.

PBX CAS event delivery to a Call Agent using SGCP 1.5:

DTMF: Wink and ground start.

MF: Wink.

TFTP download of CAS variant state machine.

Interoperability and configurability enhancements:

Configurable codec strings (IANA naming conventions as well as customized ones).

Profile negotiation and configurable preference order.

Configurable voice and VBD (i.e., up-speed codec) per profile.

Exponential backoff for:

XGCP retry timers.

SRCP retry timers.

Configurable per CAS variant.

Added support for custom profile 110 and 200 (clear channel), ITU profiles 3 and 8.

User-configurable AAL2 Silence Indicator Description (SID) for all profiles.

Type 3 Packet Support for proxy ringback (xrbk), packet side bearer continuity check (co3/co4 COT), and midcall DTMF relay.

Enhancement to Fax/modem up-speed/pass-through procedures:

Configurable CAC failure and carrier loss policies.

Up-speed to clear channel.

Supports VBR-rt and VBR-nrt ATM traffic classes, including traffic shaping to the relevant traffic descriptors.

Connection admission control (CAC) enhancements:

Patented CAC method factoring in VAD and subcell multiplexing savings.

Configurable VAD model parameter for traffic engineering.

Configurable AAL2 cell fill timer.

AAL2 alarm enhancements: per span, VC, and per channel (CID) conditioning.

Display, clear, and reset AAL2 performance related counters.

In E1 AAL2 trunking applications, support for 31 DS0 per span and a total of 248 channels per card.

Verified bearer interoperability with 3810 and third-party vendors.

Infrastructure work and enhanced support for three operating modes: VoIP switching, AAL2 trunking, and switched AAL2 PVC.

Graceful upgrade VISM 2.0 and 2.0(1) to VISM 2.1(0).

The ability to enable or disable the Call Agent protocol SDP OST feature in the event the peer gateway may or may not support SDP OST. This feature allows interoperability with the Cisco AS5300 Universal Access Server and other equipment.

The ability for VISM to perform as either the network or user side of the LAPD protocol for PRI backhaul.

CCS/PRI backhaul between VISM and a Call Agent in VoIP mode.

Support VoIP G.729ab compression.

Idle channel suppression.

Support for setting the IP precedence bit.

Support for Q.50 CAS signaling variant.

Negotiable packetization period.

AAL2 subcell multiplexing.

E1 back card support in AAL2 trunking mode.

E1 back card support (VoIP mode only).

Provides eight standard T1 interfaces with B8ZS, AMI and HDB3 line coding.

Support for voice over ATM using AAL2 cells (multiplexing only, no LLC/SNAP encapsulation).

VoIP using AAL5 cells to RFC 1889.

Support for both PCM a-law and u-law.

Programmable 24, 32, 48, 64, 80, 96, 112, 128 ms near-end echo cancellation.

Voice compression to G.711 and G.726-32K standards.

Nx64 clear channel (N = 1 only) support.

Voice activity detection (VAD) and comfort noise generation (CNG) using variable threshold energy (Cisco proprietary).

Support for call agent Simple Gateway Control Protocol (SGCP) Version 1.0, SGCP 1.1+, and Media Gateway Control Protocol (MGCP) 0.1.

Support for CCS signaling transport across an AAL5 trunk.

Support for Fax and modem VoIP bearer transmissions.

Support for dual (redundant) virtual circuits across the packet network.

Support for full continuity testing (COT). Supports origination and terminating loopback and transponder COT toward the packet bearer and the TDM sides.

Support for loop timing, payload and line loopbacks.

1:N cold redundancy using SRM-3T3 capabilities (bulk mode support for T1 lines only) for switched calls.

1:N hot redundancy for trunking applications only.

Courtesy downing of ongoing voice calls when the VISM card is taken out of service for maintenance or other reasons.

Important Notes

This section describes the following elements of VISM Release 2.2(1):

"VISM Management Information Base" section

"VISM Redundancy" section

"VISM Call Rate" section

"Compatibility" section

"Limitations and Restrictions" section

VISM Management Information Base

The VISM Management Information Base (MIB) Version 0.0.30 is provided with the delivery of VISM Release 2.2(1) software, which bundles with the MGX 8230, 8250 and 8850 Release 1 software on CCO and is located on the Web at the following location:

When the selected FW *.tar file or FW*.zip file is downloaded, untar or unzip the file and you will find all the latest MIBs bundled with this release.

The MIB is in standard ASN.1 form and can be compiled with most standards-based MIB compilers. Refer to the MIB release notes on CCO.

VISM Redundancy

Refer to Table 1 for the support level for 1:N Service Module Redundancy (N = 1 through 11).

Table 1 Service Module Redundancy 

Front Card Model Number
Redundancy Support


1:N redundancy (bulk mode support for T1 lines only).


1:N redundancy (bulk mode support for E1 lines only).

There is support for Bulk Distribution using the SRM-3T3B card.

VISM Call Rate

VISM Release 2.2(1) handles at least 10 CAS, SS7, or PRI calls per second per VISM card.


VISM software interoperability with MGX 8850, MGX 8250, and MGX 8230 platform software is listed in Table 2.

Table 2 VISM Software Interoperability 

PCB Description
CW2000 Name
Latest Firmware
Min. Firmware





























































































1 Cisco WAN Manager Release 10.4 does not support all of the new MIBs listed in the "VISM Management Information Base" section.

VISM software interoperability with other Cisco products is described in Table 3.

Table 3 VISM 2.2(1) Software Interoperability with Other Cisco Products

Cisco 3810

12.1(5) XM3

Network Management Software

CWM 10.5.10


Bundled in CWM 10.5.10

Virtual Switch Controller Software

VSC 9.1.4T

Table 4 describes the software boot code and run-time firmware requirements for VISM Release 2.2(1).

Table 4 VISM 2.2(1) Software Boot and Run-time Firmware Requirements 

Board Pair
Latest Boot Code Version
Minimum Boot Code Version









Note Loading this release of the backup bootcode is required for existing VISM cards not using this new release.

Limitations and Restrictions

The following limitations and restrictions are valid for VISM Release 2.2(x):

VISM Release 2.2(x) requires you to use 64-Mb VISM cards exclusively.

Table 5 describes the design constraints which are identified in VISM Release 2.2(1).

Table 5 Known Design Constraints 

DDTs Issue


The addcid command can put VISM into the fail state. If non-AAL5 cells are sent to an AAL5 PVC of VISM, the VISM SAR chip can hang and VISM can go into the failed state. This is because, in case of AAL5, the last bit of the Payload type indicator is used to determine which cell contains the end of that payload. All cells which have this bit set to 0 are held in the reassembly buffer until the cell with this bit set to 1 arrives. In case of non-AAL5 cells, this bit will never get set to 1, and ultimately this buffer will overflow. So, ensure that only AAL5 cells are sent to AAL5 PVCs of VISM.


DTMF digits are not passed from VISM 2.2 image to VISM 2.2 image due to faulty timestamp fields used in the VISM 2.1 type-3 tone control packets in the DSP 3.4 image.

DTMF-relay interworking is not supported between previous releases of VISM and Release 2.2. There is no workaround; however, you may either use a codec supporting in-band transport of DTMF (disable DTMF relay) or ensure version compatibility on both ends of the AAL2-Trunking connection.


Temporary traffic loss occurs when using the PXM newrev and commit commands for the VISM graceful upgrade procedure in releases of VISM 2.1.0, VISM 2.1.1, VISM 2.2.0, and VISM 2.2.1.

Installation and Upgrade Procedures

This section describes the following installation and upgrade procedures:

"VISM Firmware Download Procedure" section

"Installing VISM Software Updates" section

"VISM Boot Code Upgrade Procedure" section

"VISM Downgrade Procedure" section

"Upgrading VISM Software from 1.5(x) to 2.2(1)" section

Caution If you are upgrading the VISM software from 1.5(x), refer to the "Upgrading VISM Software from 1.5(x) to 2.2(1)" section. VISM Release 2.1(0) does not provide a graceful upgrade procedure from 1.5(x) to 2.1(x).

VISM Firmware Download Procedure

Download the selected revision of service module firmware into the service module in the selected slot.

Step 1 Download the selected revision of service module firmware into the service module in the selected slot.

tftp <node_name or IP address> 
put <backup boot> POPEYE@SM_1_<slot#>.BOOT
tftp <node_name or IP address>

Step 2 Proceed to Step 2a. to upgrade all VISM cards or proceed to Step 2b. to upgrade an individual VISM card.

a. put <FW file> POPEYE@SM_1_0.FW


b. put <FW file> POPEYE@SM_1_<slot number of card to upgrade>.FW


Note Do not enter two put commands in the same TFTP session.

Step 3 Proceed to the "Installing VISM Software Updates" section to install the download.

Installing VISM Software Updates

VISM Release 2.2 provides a procedure for the graceful upgrade (one in which the existing VISM configuration is preserved throughout the upgrade procedure) from the earlier VISM 2.0 release.

Caution Temporary traffic loss occurs during Step 4 and Step 5 of the VISM graceful upgrade procedure of the Upgrade Procedure for VISM Release 2.2.1.

Initial Conditions

The following initial conditions are required before the graceful upgrade procedure can be started:

The MGX 8000 Series shelf must be configured with at least two VISM cards in a redundant configuration (refer to the add redundancy, addred, command in the MGX 8850, MGX 8250, and MGX 8230 command references for more information).

The VISM cards must be running VISM 2.0 and be configured to the desired configuration.

The VISM Release 2.2(1) software must have been already downloaded to the MGX shelf.

Upgrade Procedure

In the following procedure:

Two VISM cards are involved, one initially active and one initially standby. The initially active VISM is identified as VISM 1 and the initially standby VISM as VISM 2.

Old-rev refers to the firmware before the upgrade (2.0).

New-rev refers to the firmware after the upgrade (2.1).

Complete the following steps to upgrade the VISM cards:

Step 1 Log in to the active PXM card (slot 7 or 8).

Step 2 Save the existing configuration as a contingency plan by entering:

savesmcnf <SM slot#>

This will save the existing configuration in the C:CNF directory. This file can be used during the downgrade procedure, if necessary.

Step 3 Execute the PXM install command:

install sm <SM slot#> <new-rev>


SM slot# is the slot number of the VISM 2 card and new-rev is the version number of the new firmware (for example, vism_8t1e1_002.001.000.000.fw).

This command causes the standby VISM 2 to reset and come up in the "hold" state, running the new-rev firmware. The active VISM 1 is unaffected by this command. At this point, the primary firmware is still the old-rev and the secondary firmware is new-rev.

Note If the VISM card is not part of a redundancy group, Step 1 to Step 3 are sufficient.

Step 4 Execute the PXM newrev command:

newrev sm <SM slot#> <new-rev>


SM slot# is the slot number of the VISM 2 and new-rev is the filename of the new firmware.

This command causes the VISM 2 to become the active VISM running the new-rev firmware. The previously active VISM 1 changes to a "hold" state and is still running the old-rev firmware. The primary and secondary firmware switches with the new-rev becoming the primary firmware.

Step 5 Execute the PXM commit command:

commit sm <SMslot#> <new-rev>


SM slot# is the slot number of the standby VISM 1 and new-rev is the filename of the new firmware.

This command causes both VISM cards to run the new-rev firmware. At first, VISM 2 is the active VISM with VISM 1 remaining in the hold state. After a short time, the cards switch automatically with VISM 1 becoming the active card and VISM 2 the standby card.

The two VISM cards are now back to their original condition except that both cards are now running the new-rev firmware.

Step 6 Log in to the active VISM card and use the display commands (dspendpts, dspcasvar, etc.) to confirm that the configuration has been preserved through the upgrade process.

It is also recommended that a further verification be performed by making some minor modifications to the configuration, checking that the changes have been executed correctly, and then changing the configuration back again.

VISM Boot Code Upgrade Procedure

There is a new backup boot code change from VISM Release 2.1(1) to VISM Release 2.2(0). Complete the following steps to upgrade the new backup boot code.

Note This procedure reprograms the VISM boot code for previous VISM cards using the VISM runtime image version 1.0 to 2.0.

Step 1 Telnet to MGX shelf and use the cc command to navigate to the VISM card.

Step 2 Type shellConn at the VISM card prompt.

Step 3 Type boot_permit = 1 at the shellConn prompt.

The boot_permit equals 0 by default, which does not allow an upgrade of boot code.

Note VISM must be in the active state in order to update the VISM boot code.

Step 4 Access the server where the VISM boot code resides and TFTP the VISM boot code to the VISM card with the following procedure:

a. Type tftp <IP address of the MGX shelf>.

b. Type bin at the tftp prompt.

Caution Ensure that you perform Step 4 b. If you do not perform Step 4 b. the boot code will be corrupted and not recoverable.

c. Type put <vism-backup-boot.fw> POPEYE@SM_1_<vism_slot_number>.BOOT

where <vism_slot_number> = the slot number where the VISM card is inserted.

Caution Do not touch the VISM card until the status comes back ('Sent xxx bytes in yyy seconds'). Failure to follow this recommendation will corrupt the boot code and will not be recoverable.

When the boot code is being written to PROM, you will see comments displayed at the VISM prompt. This is normal and expected behavior.

Step 5 Use the resetcd command for VISM from the PXM card for the latest boot to take effect.

Step 6 (Optional) Type the version command to verify the correct boot code.

You have completed upgrading the new VISM backup boot code.

VISM Downgrade Procedure

Use this procedure to downgrade VISM software from VISM Release 2.2 to the earlier VISM Releases 2.1 and 2.0. By following the downgrade procedure described here, the configurations will be retained after downgrade.

Note The configurations that existed with old-rev firmware should have been saved earlier.

Complete the following steps to downgrade the VISM software from Release 2.2 to Release 2.1 or 2.0:

Step 1 If the VISM card is in a redundancy group, remove the redundancy.

delred <SM slot#>

Step 2 Download the old-rev firmware onto the MGX shelf.

Step 3 Execute the PXM clrsmcnf command:

clrsmcnf <SM slot#>


SM slot# is the slot number of the VISM card to be downgraded.

The VISM card will be reset on executing this command. Wait for the card to come active.

Step 4 Execute the PXM restoresmcnf command:

restoresmcnf -f <filename> -s <SM slot#>


The filename is the name of the old configuration file that was saved while the old-rev firmware was running. The file can be found in the C:CNF directory on the MGX shelf.

The SM slot# is the slot number of the VISM card to be downgraded.

The VISM card will be reset again. When the card comes active, it will have the old-rev firmware running and will have the old configuration.

Step 5 Reconfigure the redundancy group, if required.

Upgrading VISM Software from 1.5(x) to 2.2(1)

If upgrading from a VISM Release 1.5, execute clrallcnf and start loading the software as if it is a new system configuration or clrsmcnf for individual card configuration (verify that there are no connections configured first).

Note VISM 2.2(1) provides a procedure for a graceful upgrade from VISM 2.0(0).


This section describes resolved and open software caveats for this release of VISM. Caveats describe unexpected behavior or defects in VISM software.

Resolved Caveats

Table 6 describes the caveats issued against VISM software that have been resolved in Release 2.2(1).

Table 6 Resolved Caveats for VISM Release 2.2(1) 

DDTs Issue


Title: The tstdelay command on VISM DAX connections varies over a large value.

Description: Varied delay times. DAX connection set up on a VISM card, in AAL2 trunking operating mode with the G.711u codec. A local connection may report large delay times that vary from 1000 to 4000000 when you use the tstdelay command.

Workaround: None.


Title: VISM cannot send an SRCP message greater than 4860 bytes to the call agent.

Description: VISM drops messages that are greater than 4860 bytes, in response to an SRCP AUGW from a call agent with a message sent by VISM. There is a hard-coded limit set in VISM of 4860 bytes. Maximum PDU size for SRCP is set to the default value of 16384 bytes. Always present.

Workaround: None.


Title: MGCP domain name should not be case sensitive in MGCP 1.0.

Description: VISM rejects commands with domain names having the same letters, but different cases (upper/lower). Always present.

Workaround: Configure both call agents and VISMs that have the same domain name with case-sensitive (upper/lower) matched MGCP domain names.


Symptom: Unable to set the addlapd command lapd-side argument to User (2). The dsplapd command shows the lapd-side argument as Network even though User was selected when adding the D channel.

Description: When adding a D channel on a VISM-T1/E1 with the addlapd command and the lapd-app-type argument is set to either PRI (1) or GR-303 (2) and the lapd-side argument is set to User (2) this issue may be present.

Workaround: To use the addlapd command with the lapd-side argument value set to User (2), and the lapd-app-type argument value set to PRI (1), do not specify the lapd-app-type argument value. It will be added by default. Example:

addlapd 1 16 2


COT test fails when a connection is not opened in the SEND RECV mode.


Title: The cnft38params command requires you to enter all of the optional arguments.

Description: The cnft38params command requires you to enter values for all of the optional arguments or none of them. Always present.

Workaround: None.


Configuration of dual PVCs for control on VISM is rejected by the PXM card.


Title: CAS Ground Start not alerting.

Description: When a CAS ground start call is placed, the terminating endpoint will not alert (alternates between loop_open_no_ring_ground and loop_open_ring_ground) when it receives the S:bl/rg signal request.

When an outgoing call is originated on a ground-start endpoint, the connected equipment (PBX) is not alerted.

This will happen after the endpoint is configured as ground-start using the cnfcasendpt command unless the line is subsequently taken out of service and brought back in service using the cnflnoos and cnflnis commands respectively.

Workaround: After configuring the endpoint as ground-start, you should forcibly put the line out of service and bring it back in service. After that this problem will not happen.


Title: VISM reboot due to datamover receiving invalid offset value.

Symptom: VISM reboots when there is a SONET ring switch in the backbone. After the VISM at one end of the network finishes rebooting, the VISM at the other end of the network reboots.

Conditions: AAL2 trunking operating mode with CAS and CCS connections between the endpoints.

Workaround: Remove CAS or ATM encryption to prevent reboots.


Title: VISM one way voice path problem.

Description: Frame counter problem on DSP, causing a one way voice path after a prolonged period of time. Always present.

Workaround: Disable VAD or reset the VISM card.


Session Description Protocol (SDP) for VoIP needs to follow industry standards.


Title: VoIP switching operating mode, DTMF relay is only 1 way (terminating VISM to originating VISM). There is no DTMF relay in the direction of originating VISM to terminating VISM.

Description: Terminating VISM cannot detect any DTMF digits sent from originating VISM. Configured E1 VISMPR02 and VISMPR18 in the same MGX to SS7 VoIP switching operating mode and making calls between both VISM cards.

Workaround: None.


Title: Ringback tone not working on packet side.

Description: When the ringback method on a terminating gateway line is configured as proxy using the cnflnringback command and the S:rt CID is signalled to the terminating gateway, the audible ringing tone is not heard on the TDM side of the originating endpoint. The tone is not heard on the originating gateway lines whose signaling type is defined as other than CAS.

Workaround: If the concerned lines are defined as CAS, no workaround is needed. If the call agent can send local ringback to the originating side, configure it to send S:rt (without the CID) to the originating gateway. Otherwise configure the ringback method as inband on the concerned line at the terminating gateway with the cnflnringback command.


Title: Setting up multiple sessions on VISM and VISM-PR CARD causes reboot.

Description: Using CiscoView to configure multiple session on a VISM card causes a reboot and would not come back into service.

Workaround: None.


Title: CC_MGCP and CC_SGCP macros are incorrect.

Symptom: CC_MGCP and CC_SGCP macros cause an incorrect protocol to be returned, though the internal function returns the correct protocol.

Condition: Always present.

Workaround: None.


Title: VISM hangs at a low traffic rate.

Symptom: A connection is not deleted by VISM when receiving DLCX messages from a call agent.

Condition: If the call agent tries to place a new call, sending a CRCX message on any endpoint, VISM replies with a CRCX failure.

Workaround: Reset the VISM card.


No ringback tone for PSTN to SIP calls using the BTS call agent.


Reverse the detect and play TDM COT tones (dual tone COT).


VISM replies with error: 502 invalid LCN to CRCX message.


Fax calls fail when clear channel is configured as the upspeed codec; and no upspeed occurs when G.726-40K codec is configured as the upspeed codec.


Symptom: Card stops to transmit (or transmit very low data) after a while. Some connections may experience dead air problem.

Condition: AAL2 trunking with subcell muxing enabled, connections sending more data than configured for the bandwidth.

Workaround: Configure bandwidth on connections so that the data traffic does not exceed configured bandwidth.


AAL2 CIDs in the ITU-8 profile may get stuck in the CCD codec.


Symptom: When originating an Feature Group D (Operator Services), VISM dials ANI (calling party number) before dialing DNIS (called party number). Execution of the cnflndigitorder command does not change this behavior.

Conditions: This happens when FGD-OS calls are run on VISM (using the MO package of RFC 3064 on endpoints configured with the CAS variant fgd_os_e911.o).

Workaround: No workaround, unless the connected equipment can accept ANI first and then DNIS, or the call agent can be configured to pass the DNIS and ANI in the id and addr fields, respectively, of the sup message that is sent to VISM.


The ECAN should bypass when it receives COT tones as defined by ITU.


VISM ECAN performance is poor when there are slips.


Symptom: When you press the # key on the call going through the VISM, do not issue the dspmonecanendpt command more than once. Otherwise, the VISM card may reset.

Conditions: Press the # key without releasing it and issue the dspmonecanendpt command more than once, and the VISM card resets.

Workaround: When you monitor the voice/ECAN level, do not press the # key on the phone while you issue the dspmonecanendpt command.


Jitter attenuation needs to be enabled in non-bulk mode.


With an MGX 8250/8850 with Release 1 PXM has clocking configured to take the BITS clock source as primary, and a VISM line as secondary, a BITS clock source failure results in a switch to the internal clock source instead of to the VISM line source. The display incorrectly shows the clock source is from the VISM line. You may see multiple frame slips/errors on equipment attached to the VISM cards which could cause data errors/voice quality issues, or force the attached equipment to bring the link out of service.

Workaround: Either configure the VISM line as the primary, and BITS as the secondary, or use another source rather than a VISM line if one is available.


Cell loss in bulk test. A codec G.711 with subcell muxing enabled configuration results in only 210 of the 248 DS0s supported. Use the dspconcnt command to display data.


DSPM hung problem on several VISM-PR cards.


TDM COT fails. Originating COT test fails when requesting R:co1, s:co1 in the CRCX2.


Codec negotiation fails for codec G.729 and CCD.


Receive 402 phone is already in the on hook state after DLCX and after FGDOS/911 calls on VoIP CAS.


Symptom: When the ring-back method on a line on a terminating gateway is configured as proxy using the cnflnringback command and rt@connection_id is signaled to the terminating gateway, the audible ringing tone is not heard on the TDM side of the originating endpoint.

Conditions: The tone is not heard on the originating endpoint if the line is CAS and the CAS variant is something other than ground_start or loop_start.

Workaround: If the call agent can send local ringback to the originating side, configure it to send S:rt (without the connection ID) to the originating gateway. Otherwise, configure the ringback method as inband on the concerned line at the terminating gateway using the cnflnringback command.


VISM card, configured for MGCP 0.1 resets for invalid port RQNT instead of returning an error message.

Open Caveats

Table 7 describes possible unexpected behavior by VISM Release 2.2(1).

Table 7 Open Caveats for VISM Release 2.2(1) 

DDTs Issue


Title: VISM telnet sessions lock, unable to use the cc command to access the card until reset.

Description: The VISM card allows up to two sessions. Both of these sessions have become locked, which prevents the user from being able to use the cc command to access the card. This condition has been reported twice and is not reproducible in the lab.

Workaround: Reset the card.


Title: XRBK/CO4 does not work with subcell muxing enabled for some calls.

Description: Start calls on 48 endpoints with ground start CAS variant and subcell muxing enabled. Calls were Inter-VISM and Intra-MGX. Some calls failed with the "Network COT test failure" error. When running calls with subcell muxing disabled, XRBK/CO works fine.

Workaround: Disable subcell muxing.


Title: G.726-16k, 24k and 40k cannot be configured as Vbdcodec.

Description for VISM 2.2: G.726-16k, G.726-24k, and G.726-40K should not be configured as Vbdcodec for upspeeding during fax/modem calls. This feature is not available in VISM Release 2.2.

Workaround: If configuring with VISM CLI commands, do not configure G.726-16k, G.726-24k, and G.726-40K with cnfvbdcodec. If configuring with SNMP, do not configure G.726-16k, G.726-24k, and G.726-40K for the vismUpspeedCodec MIB object.

Description for VISM 2.1: VISM does not allow G.726-16k, G.726-24k, and G.726-40K to be configured as Vbdcodec for upspeeding during fax/modem calls.

Workaround: None.


Title: CAS endpoint does not go idle after a failed call.

Description: When the terminating VISM is dialing the digits out (in immediate and wink start) and times out waiting for DSPs acknowledgment (that the digits were dialed out), CAS initiates a DLCX (E: could not dial digits) and goes to the wait for idle signal from PBX state.

Workaround: None.


Title: The cnfgwoos 2 (2 = forceful) CLI command string fails to delete some connections under error conditions.

Description: Upon a network COT failure—when network COT is initiated by the terminating gateway—the terminating gateway sends DLCX to the call agent. The call agent, upon receiving DLCX from the terminating gateway, sends DLCX with R: (empty list in requested events) to the originating gateway to delete the connection. The originating gateway fails to delete the connection and sends a NACK message to the DLCX. The connection is hung in this situation. Now, after this failed operation, the originating gateway does not delete the connection with the cnfgwoos 2 CLI command string and the connection stays hung.

Workaround: Reset the VISM card.


Title: Codec negotiation fails when certain specific strings are configured as codec names.

Description: VISM rejects the call with the "admission failed to identify admitted codec" error message when the codec string has a specific parameter.

Workaround: You should not use the following codec names in the cnfcodecparams CLI command:


















Related Documentation

The following document contains information that may be useful to VISM Release 2.1(1):

Cisco Voice Interworking Service Module Guide

Obtaining Documentation

The following sections explain how to obtain documentation from Cisco Systems.

World Wide Web

You can access the most current Cisco documentation on the World Wide Web at the following URL:

Translated documentation is available at the following URL:

Documentation CD-ROM

Cisco documentation and additional literature are available in a Cisco Documentation CD-ROM package, which is shipped with your product. The Documentation CD-ROM is updated monthly and may be more current than printed documentation. The CD-ROM package is available as a single unit or through an annual subscription.

Ordering Documentation

Cisco documentation is available in the following ways:

Registered Cisco Direct Customers can order Cisco product documentation from the Networking Products MarketPlace:

Registered users can order the Documentation CD-ROM through the online Subscription Store:

Nonregistered users can order documentation through a local account representative by calling Cisco corporate headquarters (California, USA) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).

Documentation Feedback

If you are reading Cisco product documentation on, you can submit technical comments electronically. Click Feedback at the top of the Cisco Documentation home page. After you complete the form, print it out and fax it to Cisco at 408 527-0730.

You can e-mail your comments to

To submit your comments by mail, use the response card behind the front cover of your document, or write to the following address:

Cisco Systems
Attn: Document Resource Connection
170 West Tasman Drive
San Jose, CA 95134-9883

We appreciate your comments.

Obtaining Technical Assistance

Cisco provides as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools by using the Cisco Technical Assistance Center (TAC) Web Site. registered users have complete access to the technical support resources on the Cisco TAC Web Site. is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information, networking solutions, services, programs, and resources at any time, from anywhere in the world. is a highly integrated Internet application and a powerful, easy-to-use tool that provides a broad range of features and services to help you to

Streamline business processes and improve productivity

Resolve technical issues with online support

Download and test software packages

Order Cisco learning materials and merchandise

Register for online skill assessment, training, and certification programs

You can self-register on to obtain customized information and service. To access, go to the following URL:

Technical Assistance Center

The Cisco TAC is available to all customers who need technical assistance with a Cisco product, technology, or solution. Two types of support are available through the Cisco TAC: the Cisco TAC Web Site and the Cisco TAC Escalation Center.

Inquiries to Cisco TAC are categorized according to the urgency of the issue:

Priority level 4 (P4)—You need information or assistance concerning Cisco product capabilities, product installation, or basic product configuration.

Priority level 3 (P3)—Your network performance is degraded. Network functionality is noticeably impaired, but most business operations continue.

Priority level 2 (P2)—Your production network is severely degraded, affecting significant aspects of business operations. No workaround is available.

Priority level 1 (P1)—Your production network is down, and a critical impact to business operations will occur if service is not restored quickly. No workaround is available.

Which Cisco TAC resource you choose is based on the priority of the problem and the conditions of service contracts, when applicable.

Cisco TAC Web Site

The Cisco TAC Web Site allows you to resolve P3 and P4 issues yourself, saving both cost and time. The site provides around-the-clock access to online tools, knowledge bases, and software. To access the Cisco TAC Web Site, go to the following URL:

All customers, partners, and resellers who have a valid Cisco services contract have complete access to the technical support resources on the Cisco TAC Web Site. The Cisco TAC Web Site requires a login ID and password. If you have a valid service contract but do not have a login ID or password, go to the following URL to register:

If you cannot resolve your technical issues by using the Cisco TAC Web Site, and you are a registered user, you can open a case online by using the TAC Case Open tool at the following URL:

If you have Internet access, it is recommended that you open P3 and P4 cases through the Cisco TAC Web Site.

Cisco TAC Escalation Center

The Cisco TAC Escalation Center addresses issues that are classified as priority level 1 or priority level 2; these classifications are assigned when severe network degradation significantly impacts business operations. When you contact the TAC Escalation Center with a P1 or P2 problem, a Cisco TAC engineer will automatically open a case.

To obtain a directory of toll-free Cisco TAC telephone numbers for your country, go to the following URL:

Before calling, please check with your network operations center to determine the level of Cisco support services to which your company is entitled; for example, SMARTnet, SMARTnet Onsite, or Network Supported Accounts (NSA). In addition, please have available your service agreement number and your product serial number.