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.

RTP Multiplexing

RTP Multiplexing enables VXSM to optimize the use of IP bandwidth between two gateways. VXSM achieves this by reducing the RTP header size and multiplexing different RTP session's payloads into a single UDP payload. In RTP Multiplexing, the RTP sessions destined for a particular IP address are multiplexed into a single IP datagram. The following commands were added to support this feature:

–cnfrtpmux

–dsprtpmux

Usage Guidelines

Follow these guidelines when you configure the RTP Multiplexing:

•To enable In Service upgrade, you have to configure the gateway to OOS.

•RTP Multiplexing is supported only for the Tandem Gateway (TGW) codec template. Feature support is available only for G729 and G.723 codec families. It is not supported for Data and Fax/T.38 calls.

•RTP Multiplexing is not applicable for SII and Calea calls. That is, these calls will not be multiplexed. However, MUX is supported on Calea images for normal voice calls.

•RTP Multiplexing is supported only on an OC3 VXSM card.

•VXSM will not initiate RTP Multiplexing on endpoints which have moved to voice mode after Modem/ Fax transmission.

•VXSM will stop RTP Multiplexing for calls which are IP forwarded.

•RTP Multiplexing is not supported for H.248 protocol in Release 5.6.00.

•VXSM initiates RTP Multiplexing only if there are at least three calls having the same source IP and destination IP pair.

•VXSM does not support multiplexing for intra-card calls even if IPs are different.

•There is a DS0 density impact when RTP Multiplexing is enabled. The total DS0 capacity impact would be 384.

•While VXSM is used for AAL2 trunking, if you want to run the RTP Multiplexing commands, you have to first delete all the CIDs.

•If online or offline diagnostics is enabled on a VXSM card, you have to disable it before you run the RTP Multiplexing commands.

•You have to delete SS7, LAPD, and CAS signaling links before you enable RTP Multiplexing.

•DSP redownload must be disabled before enabling the RTP Multiplexing commands.

DSP RAS and Memory Error Detection

Before Release 5.6.00 (for MGCP protocol, it is before Release 5.5.11), when a DSP core fails in an active VXSM, the standby VXSM takes over the active card's role. If the DSP core fails in a standby VXSM, then it reboots the standby VXSM. In such a case, if the active VXSM also fails due to some reason, then there is a complete outage for 3 to 5 minutes. When a DSP core fails in a standalone VXSM, the failed DSP core is marked as a bad core, along with other sibling cores in the DSP chip. In such a case, the existing calls on the affected DSP chip are dropped and no new calls are allowed. In Release 5.6.00, these issues are resolved with the implementation of DSP RAS feature. The following commands were added to support this feature:

–cnfDspRedownload

–dspDspRedownload

Usage Guidelines

Follow these guidelines when you configure DSP RAS and Memory Error Detection:

•VXSM drops T.38 calls when the DSP core where the calls reside fails (VXSM as active in redundant mode or in standalone mode). VXSM exhibits similar behavior if the card was switchover.

•DSP-RAS cannot be enabled simultaneously with other new 5.6.00 feature RTP Multiplexing.

•DSP-RAS feature is not supported on VXSM cards used as a Transcoding Gateway.

Support for Text Over IP

Text over IP (ToIP) is a means of providing a real-time text service that operates over IP-based networks. TTY text phones use ToIP for transmitting messages from one phone to another. VXSM supports Text Relay and TTY Upspeed for transmitting text characters using TTY phones. The following commands were added to support this feature:

–cnfTextRelayprof

–delTextRelayprof

Usage Guidelines

Follow these guidelines when you configure Text Relay:

–VXSM Text Relay does not guarantee the support of third-party gateways.

–Text Relay feature is supported only with the FMC template.

–VXSM as an IP-IP gateway supports Text Relay feature only for transcoding and transparent IP-IP voice calls. Text Relay is not be supported in fast-routing mode.

T38-VBD Interworking for Fax Over IP

In Release 5.6.00, VXSM supports T38-VBD interworking for fax over IP. VXSM acts as a transcoding gateway and provides the interworking functionalities.

V23 Support with Increased Channel Density

With Release 5.6.00 and later versions, the channel capacity is increased to 30 channels when the V23 FSK detector is enabled.

Usage Guidelines

Follow these guidelines before you enable this feature:

•Association between VXSM and CA should be Out of Service.

•Delete all the CIDs if VXSM is used for AAL2 trunking.

•Delete all LAPDs, SS7 links, and CAS endpoints.

•Delete online or offline diagnostics for the particular VXSM slot.

•V23 feature is supported only on the VXSM OC3 card.

•V23 feature is supported only for H.248 Call Control protocol.

•VXSM slot must be configured in H.248 protocols.

•RTP Multiplexing must be disabled to enable V23 feature but vice versa is not true.

•MIB support for V23 mode is supported only for the TGW and TGW2 templates.

NSE Negotiation Based VXSM Up-speed

From Release 5.6.00, in gateway controlled mode, VXSM upspeeds upon detecting the modem tones only when the NSE negotiation is successful in the Call Signaling. You can enable this feature by using the cnfNseNegoUpspeed command. This command is supported in both the xGCP and H.248 protocols.

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.4.21 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.6.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.

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.

Restrictions

This section includes information about restrictions pertaining to performance and the recommended actions:

•If the G.723 codec is not used as a voice codec, then disable all variants of the G.723 codec using the cnfcodecparam command.

•If the G.723 codec is enabled but not used in voice calls, then ensure that the codec list is specified without the G.723 codec while creating a call. If no codec is specified while creating a call on VXSM, then the resources for the G.723 codec are reserved. This affects the normal resource allocation algorithm, which in turn results in anomalous behavior of VXSM.

Symptoms: Standby VXSM reboots when the same core is killed twice back- to-back.

Conditions: This issue is seen when the same core is killed twice 5-10 seconds after the re-download.

Workaround: None.

CSCth64133

Headline: Standby VXSM resets on first core kill with full DSP capacity of calls.

Symptoms: Standby VXSM resets on first core kill with full DSP capacity of calls.

Conditions: This issue is only seen when the card is at full capacity and 80 cps.

Workaround: None.

CSCth76631

Headline: When card goes to active-F state after a DSP crash, all calls are deleted.

Symptoms: All active calls on the card are deleted when a DSP crash happens on a standalone card.

Conditions: Card should be in standalone mode.

Workaround: Add VXSM redundancy baseline behavior.

CSCth79803

Headline: Standby VXSM card reloads unexpectedly.

Symptoms: Standby VXSM reboots with CRML-ERR: REDM error.

Conditions: While processing back to back Modify on standby VXSM under load conditions, when the DSP responses for the first modify is delayed, the second modify comes before that. This is a rare race condition.

Workaround: None.

CSCth87422

Headline: IUA-H.248: VXSM resets intermittently on high cps while killing a lapd core.

Symptoms: VXSM resets intermittently on high cps while killing a lapd core.

Conditions: This issue occurs intermittently on high cps after a DSP crash on a lapd core.

Workaround: None.

CSCti18177

Headline: The dspsctps command shows wrong MGC IP when two IPs are configured for a single active MGC.

Symptoms: The dspsctps command shows wrong MGC IP when two IPs are configured for a single active MGC.

Conditions: Occurs when two IPs are configured under one MGC and one of the IP is in down state or does not exist actually.

Workaround: This is a display issue, hence collect the SCTP traces to verify the IPs.

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 or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: 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. (1110R)