Table Of Contents
Release Notes for Cisco Voice Switch Service Module (VXSM) Release 5.4.21
Revised: August 20, 2010, OL-16164-02
The content of this document is arranged into the following major sections:
About This Release
Version .200 of Release 5.4.21 is a patch release for VXSM and introduces one new feature. The resolved caveats for Versions .200 are listed in Table 4.
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.
The VXSM software release notes are supported by Cisco Voice Switch Services (VXSM) Configuration Guide, Release 5.4 and Cisco Voice Switch Services (VXSM) Command Reference, Release 5.4, both of which are available on cisco.com.
New Feature in Release 22.214.171.124
V23-FSK Tone Detection Enhancement
Release 5.4.21 introduces a new command cnfv23mode to detect the V23-FSK tone. Using this command, you can either enable or disable the V23-FSK tone detection. By default, this feature is disabled.
When you enable V23-FSK on VXSM, the bearer channel capacity for each DSP core is reduced to 28 channels from 32 channels. This impacts the overall MGX capacity of VXSM OC3 card in which the overall call capacity reduces from 8064 to 7056. When you disable it, the capacity returns to 32 channels. Before you execute this command, remember the following:
•No active calls should be present utilizing the DSP. To make sure that no calls are utilizing the DSP, change the H.248 association between VXSM and CA to Out of Service. You can use the command cnfh248oos to change the state to Out of Service.
•Make sure that there are no hung CCBs. You can check hung CCBs by using the shellConn command activeCcbs. If there are any hung CCBs, then reset the VXSM card.
•If LAPDs were added, then it should be deleted because LAPDs allocate bearer and signaling DSP channel.
•If SS7 links were added, then it should be deleted because SS7 links allocate bearer and signaling DSP channel.
•If CAS endpoints were added, then it should be deleted.
•If online diagnostic is enabled on VXSM, then it should be disabled.
•All the CIDs should be deleted if VXSM is used for AAL2 trunking.
The syntax of the command is shown below:
cnfv23mode <V23 mode>
V23 Mode should be set to 1 to enable V23-SFK tone detection. Set the value to 2 to disable the feature. The default value is 2.
New Feature in Release 5.4.00.201
This release contains the enhancements to completely squelch DTMF digits. This feature can be provisioned using the CLI commands shown below.
Note These CLI commands are not new for this release. They already exist in the product.
cnfh248profdtmf <Index> <DigitOnDuration> <DtmfPauseDuration> <DetectLongDigitDuration> <SuppressBearerDigit>
Option SuppressBearerDigit should be set to 1 to enable DTMF squelching.
cnfxgcpprofdtmf <ProfileIndex> <SuppressBearerDigit>
Option SuppressBearerDigit should be set to 1 to enable DTMF squelching.
New Features in Release 5.4.00.200
Release 5.4.00 is a significant release with several major new software features over Release 5.3.10.
This release has no new VXSM hardware features.
The new software features include:
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 35.
•In H.248, the maximum CPS supported is 85 (without signaling). If signaling (M3UA/IUA) is configured, then the maximum supported CPS is 35.
Simple Network Management Protocol Version 3 (SNMPv3) is an standards-based protocol for network management. SNMPv3 provides secure access to devices using a combination of authentication and encryption of packets over the network. This assures that data can be collected securely from SNMP devices and that configuration messages cannot be viewed or altered.
The security features provided in SNMPv3 are:
•Message integrity—Ensuring that a packet has not been tampered with in-transit.
•Authentication—Determining that the message is from a valid source.
•Encryption—Scrambling the contents of a packet to prevent it from being seen by an unauthorized source.
V.110 Support for AAL2 Trunking Applications
VXSM supports the detection and handling of V.110 traffic used for modem and fax devices on mobile networks. This feature is used in conjunction with the AAL2 Trunking function. Upon detection of a V.110 bit pattern, VXSM provides a Clear Channel circuit for the duration of the V.110 (data) session.
The V.110 feature adds the following commands:
cnfeventmapping -v110 Configure V.110 events mapping
dspeventmapping -v110 Display V.110 events mapping
addccdprof Add clear channel data profile
cnfccdprof Configure clear channel data profile
delccdprof Delete clear channel data profile
dspccdprof Display clear channel data profile
dspccdprofs Display clear channel data profiles
Unique Virtual Gateway Domain Name for H.248
For H.248 applications, a VXSM card has the capability of being partitioned into a number of virtual media gateways (VMGs); where each VMG is a logical entity residing within a physical VXSM card. This feature permits each virtual gateway to be assigned its own unique domain name.
The Unique Virtual Gateway Domain Name feature modifies the following commands:
addh248assoc Add H.248 association
cnfh248mg Configure H.248 media gateway
dsph248assoc List configuration of H.248 Association
dsph248mg List configuration of H.248 Gateway
ptime Support for H.248
The ptime (packet period) attribute is defined in RFC 2327 as "the length of time in milliseconds represented by the media in a packet." ptime specifies the packet period for a codec, and maxptime specifies the maximum packet period.
The ptime and maxptime attributes are optional SDP attributes that can be sent down by the MGC in the local or remote descriptor SDP.
In release earlier than 5.4.00, the values of ptime and maxptime were ignored and the values configured on the platform were used.
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.
The Non-CALEA image 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 TGCP and MGCP only. The protocol must be explicitly selected when the image is loaded from the PXM using the setrev command.
VXSM supports two different codec templates; "TGW/wireline" 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.2.10 or later so long as the original and the upgraded images are both either CALEA or Non-CALEA.
Note Upgrading from CALEA to Non-CALEA, or Non-CALEA to 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.4.00, 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.
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.
Do not reset VXSM or PXM cards manually or through commands such as resetcd or resetsys
Do 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 upgrade
Do not change any configuration of active primary card during the upgrade
THE 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
Step 3 If the secondary VXSM becomes "Failed/Active" (out of Failed-U/Active"), then execute the resetcd command:
Step 4 Both primary and secondary VXSM cards should now have their original SW image and original DB
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 availablecapacity (#DSP chans) capacity (#DSP chans)========== ===================== =====================G711 family/HDLC 179 7885G729/G726/T.38 family 0 3919G723 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.
VXSM Management Information Base
The VXSM Management Information Base (MIB) Version 5.4 is available to users with CCO accounts who can access the MIB and VXSM software on-line at: http://www.cisco.com/kobayashi/sw-center/sw-wan.shtml
Step 1 Log on to http://www.cisco.com/kobayashi/sw-center/sw-wan.shtml
Step 2 Locate the VXSM platform (either VXSM 8880 or VXSM 8850) and click the down arrow to expand the "Select Release Level" drop down menu.
Step 3 Select the desired MIB release level (for example, Release 5400) to display a list of downloadable files.
Step 4 Click on the desired file (for example, mgx8850-fw-5400.tar).
Step 5 Read the license agreement and, if approved, click Accept.
Step 6 In the Software Download dialog box, click on Download: filename (where filename is the name of the file selected for download). This step starts the download procedure.
Step 7 Follow the normal file download procedure for your computer.
Step 8 When the file has been downloaded, untar or unzip the downloaded file. The MIB file is included in the downloaded file and is listed as a tar file (for example mgx8850rel5400mib.tar).
Step 9 Untar the MIB file to display its contents.
Service Module Support by Platform
Note VXSM Release 5.4.21 is supported only with PXM-45/C.
VXSM software interoperability with the MGX 8880 Media Gateway or the Cisco MGX 8850 (PXM45) Multiservice Switch platform software is listed in Table 1.
Table 2 describes the software images available for Release 5.4.21 for VXSM.
Caveats for VXSM Release 5.4.21
This section describes software caveats for the Release 5.4.21.
Open Caveats in Release 5.4.21
Resolved Caveats in Release 5.4.21
The following documents contains information that may be useful to software Release 5.4 for VXSM:
•Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830 Hardware Installation Guide, Releases 2 Through 5.3
•Cisco ATM Services (AXSM) Configuration Guide and Command Reference for MGX Switches, Release 5.2
•Cisco MGX Route Processor Module (RPM-XF) Installation and Configuration Guide, Release 4
•Cisco MGX 8880 Media Gateway, Release 5.4: A Guide to User Documentation.
•Release Notes for Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830 Switches, Release 5.4
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)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2009 Cisco Systems, Inc. All rights reserved.