About This Release

The Voice Switch Service Module (VXSM) product is supported by the MGX 8880 Media Gateway and the MGX 8850 Multiservice Switch. Refer to their respective release notes for platform and version level support guidelines.

Note To verify that you have the latest version of Cisco IOS required to support the new features included in this release, please check Cisco IOS availability status at Cisco.com.

New Features in Release 5.5.10

Release 5.5.10 is a maintenance release which introduces one new feature.

V23-FSK Tone Detection Enhancement

VXSM supports fast detector for V23-FSK tone detection. When you enable the fast detector for V23-FSK, the channel capacity for each DSP reduces to 28 channels from 32 channels. When you disable the fast detector for V23-FSK, the capacity returns to 32 channels. By default, fast V23-FSK tone detection is disabled. In the following example, the user enables the V23-FSK tone detection:

unknown.2.VXSM.a > cnfv23mode 1

To disable V23-FSK detection, set the value to 0.

Restrictions

•The association between the VXSM and CA should be Out of Service. If the association is In Service, then change it to Out of Service by using the cnfh248oos command.

•All the CIDs should be deleted if VXSM is used for AAL2 trunking.

•If LAPDs were added, then they should be deleted because LAPDs allocate bearer and signaling DSP channels.

•If SS7 links were added, then they should be deleted because SS7 links allocate bearer and signaling DSP channels.

•If CAS endpoints were added, then they should be deleted.

•If online diagnostics were enabled on VXSM, then they should be disabled before executing the cnfv23mode command.

•Make sure that there is no hung CCBs. You can check hung CCBs by using the shellConn activeCcbs command. If there are any hung CCBs, then reset the VXSM card.

•This feature is supported only on TWG and TWG2 codec templates.

Firmware Images

For each VXSM card type (OC-3/STM-1, T1/E1, or T3), two firmware images are available, namely, Non-CALEA and CALEA. When placing an order, the user must specify whether a Non-CALEA or CALEA image is required.

Both CALEA and Non-CALEA images supports three Media Gateway Control protocols, namely, H.248, MGCP, and TGCP. However, VXSM supports only one protocol at a time. The user must choose between the H.248, MGCP, and TGCP protocols when the image is first loaded from the PXM using the setrev command.

The CALEA image supports LI based on SII architecture for H.248, TGCP and MGCP protocols. The PktCable CALEA is supported only with MGCP and TGCP protocols.

VXSM supports four different Codec templates; Tandem Gateway (TGW), Tandem Gateway 2, Fixed Mobile Convergence (FMC), and Cable. The Cable template can be used only in conjunction with TGCP.

Upgrading from an Earlier VXSM Release

VXSM can be gracefully upgraded (configuration is preserved) from VXSM Release 5.3.30 or later.

Note VXSM supports upgrade of non-CALEA to CALEA firmware. But upgrade from CALEA to non-CALEA is not supported.

When loading or upgrading a boot or runtime image to a VXSM card, users must observe the following caution:

Caution If an H.248 association is active with SrvChgProfile (used in service change message) as BT_TGW in 5.3.x.x release, after graceful upgrade to 5.5.10, the association will continue to use BT_TGW, but new association(s) cannot be added with SrvChgProfile as BT_TGW.

From the 5.4.00 release onward, the BT_TGW SrvChgProfile is no longer available. All new associations must be added using either etsi_tgw or CISCO_TGW.

Prior to upgrade, user should confirm that additional termtypes (other than the defaults) have not been configured for VXSM in H.248.

Warning Many of the commands involved in loading or upgrading boot and runtime images can take several minutes to execute completely. If the user resets or otherwise disturbs the VXSM card during a loading or upgrading process, the card can easily be damaged even to the extent that it must be returned to the factory for repair.In particular:Do not reset VXSM or PXM cards manually or through commands such as resetcd or resetsysDo not save all MGX configurations with commands such as saveallcnfs.Do not toggle primary/secondary cards through commands such as switchredcd, delred Do not change the name of software image before or during the upgradeDo not change any configuration of active primary card during the upgradeTHE REAPPEARANCE OF THE COMMAND PROMPT AFTER A COMMAND IS ENTERED DOES NOT INDICATE THAT THE IMAGE LOAD OR UPGRADE HAS BEEN COMPLETED. After the execution of the burnboot, clrsmcnf, loadrev, or setrev commands, the user must execute either a dspcds or dsprev command periodically to verify that the state of the VXSM card being loaded or upgraded is either Active, Standby, or Failed. ONLY WHEN THE CARD IS DISPLAYED TO BE IN ONE OF THESE STATES IS IT SAFE TO GO TO THE NEXT STEP.If the upgrade procedure is interrupted for reasons outside the control of the user (for example, a power outage), see "Interrupted Procedure Recovery" below for instructions.

Interrupted Procedure Recovery

In the event that a VXSM software upgrade procedure is interrupted (for example, power outage), and both Primary and Secondary are stuck in 'Failed-U' state, perform the following procedure

Step 1 Execute the abortrev command:

abortrev <PrimarySlot> <NewImageRevision>

Step 2 If the primary VXSM becomes "Failed/Active" (out of Failed-U/Active"), then execute the resetcd command

resetcd <PrimarySlot>

Step 3 If the secondary VXSM becomes "Failed/Active" (out of Failed-U/Active"), then execute the resetcd command:

resetcd <SecondarySlot>

Step 4 Both primary and secondary VXSM cards should now have their original SW image and original DB

Feature Clarifications

Call Rate Performance Support

VXSM OC3 Card supports the following call rates:

•In MGCP, the maximum CPS supported is 60 (without signaling). If signaling (M3UA/IUA/RUDP) is configured, then the maximum supported CPS is 50.

•In H.248, the maximum CPS supported is 85 (without signaling). If signaling (M3UA/IUA) is configured, then the maximum supported CPS is 50.

Online Diagnostics Feature as Applied to VXSM

The online diagnostics feature as implemented on the PXM45 card is supported on VXSM. When enabled, using the PXM45 cnfdiag command, this feature performs non-intrusive diagnostics tests that use four of the VXSM G711 DSP resources.

If the user executes the VXSM dspdspcodecpools command, the resulting display shows the four G711 DSP resources being used (for diagnostics) and subtracts them from the remaining available Codecs (see example below).

mgx.3.VXSM.a > dspdspcodecpools

=====================================================================

DSP codec capacity usage

=====================================================================

Codec pool Current utilized Current available

capacity (#DSP chans) capacity (#DSP chans)

========== ===================== =====================

G711 family/HDLC 179 7885

G729/G726/T.38 family 0 3919

G723 family 0 2911

In this example, 175 G711 calls have been established along with four G711 resources used for diagnostics.

The online diagnostics feature does not reduce the maximum number of 8064 G711 DSP resources available for calls on the VXSM card. If the number of call requests on the VXSM is sufficiently high, the online diagnostic feature is disabled automatically and the four Codecs are made available for active calls.

DSP Resources Under Mixed Codec Conditions

When the same Codec is used to setup calls on the gateway the available DSP resources will be fully utilized. However when different Codecs are used to setup calls the amount of utilizable DSP resources may be limited in certain cases due to resource fragmentation.

Fragmentation is said to have occurred when the available capacities on two different DSP resources have enough available capacity to support a call of a particular Codec type but cannot support that Codec type individually.

Consider two DSP resources whose available capacity is 1 unit each making the total available capacity 2 units. However a Codec that requires 2 units cannot be supported in the system because the available capacities have been fragmented across the individual DSP resources.

The DSP allocation algorithm on VXSM does make an attempt to smooth the effects of fragmentation. Fragmentation can happen because the pattern of future calls cannot be predicted beforehand.

Obtaining Documentation, Obtaining Support, and Security Guidelines

For information on obtaining documentation, obtaining support, providing documentation feedback, security guidelines, and also recommended aliases and general Cisco documents, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:

Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)