Cisco MGX 8880 Media Gateways

Table Of Contents

Release Notes for Cisco Voice Switch Service Module (VXSM) Release 5.0.70.205

Table of Contents

About Release 5.0.70.205

New Features in Release 5.0.70.205

New Features in Release 5.0.70

Support for Media Gateway Control Protocol

NFAS with D-channel Backup

Multiprotocol Service Module Interoperability

New Features in Release 5.0.20

Additional Media Gateway Control Protocol

PRI Backhaul

Differentiated Services (DiffServ)

Communications Assistance for Law Enforcement Act (CALEA)

Voiceband Data Profiles and Event Mapping

Firmware Images

Upgrading from an Earlier VXSM Release

Feature Clarifications

Online Diagnostic feature as applied to VXSM.

DSP Resources under Mixed Codec Conditions

Configuring Switching and Trunking Applications

VXSM Management Information Base

Compatibility

Caveats for VXSM Release 5.0.70.205

Open Caveats in Release 5.0.70.205

Resolved Caveats in Release 5.0.70.205

Caveats Opened after 5.0.70 and now resolved in Release 5.0.70.205

Related Documentation

Obtaining Documentation

Cisco.com

Documentation DVD

Ordering Documentation

Documentation Feedback

Cisco Product Security Overview

Reporting Security Problems in Cisco Products

Obtaining Technical Assistance

Cisco Technical Support Website

Submitting a Service Request

Definitions of Service Request Severity

Obtaining Additional Publications and Information

Release Notes for Cisco Voice Switch Service Module (VXSM) Release 5.0.70.205

---

These release notes are part number OL-8289-01 Rev. A0, September 12, 2005.

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

The VXSM software release notes are supported by the Cisco Voice Switch Services (VXSM) Configuration Guide and Command Reference, Release 5, which is available on cisco.com.

Table of Contents

About Release 5.0.70.205

The VXSM Release 5.0.70.205 follows VXSM Release 5.0.70.

New Features in Release 5.0.70.205

Release 5.0.70.205 is a maintenance release that corrects a number of caveats that were open in the 5.0.70 release. This release contains no new features.

New Features in Release 5.0.70

Support for Media Gateway Control Protocol

VXSM Release 5.0.70 supports the Media Gateway Control Protocol (MGCP 1.0) in addition to the two protocols (TGCP and H.248) that are supported in the previous release. At any time only one gateway control protocol is supported on a VXSM card. The protocol is user selectable when the VXSM image is loaded from the PXM disk. This is accomplished through the PXM setrev command using the -ccp <CallControlProtocol> parameter.

Support for MGCP 1.0 permits interoperability between VXSM and Cisco PGW media gateway controllers.

NFAS with D-channel Backup

In VXSM Release 5.0.70, when performing ISDN PRI backhaul, the D-Channel in a Non-Facility Associated Signaling (NFAS) voice stream can be protected with the use of a backup D-channel.

NFAS voice streams employ 479 B channels plus 1 D-channel that controls up to a maximum of 20 DS1s interfaces. If the D channel fails it can bring down all the 479 bearer B channels.

Multiprotocol Service Module Interoperability

For AAL2 trunking applications, VXSM can now operate in conjunction with a Multiprotocol Service Module (MPSM) in which the MPSM provides the interface to the ATM network. Interworking with the MPSM enables the MGX Voice Gateway to support IMA, ATM and Frame Relay services with channelized capability on DS1 and DS0 levels.

The MPSM card must be configured for ATM context using the MPSM cnfclictx atm command. After the context is set to ATM, provisioning is performed with the upln, addport and addcon command sequence. For more details, please refer to the MPSM user documentation.

New Features in Release 5.0.20

The following new features were introduced in the 5.0.20 release of VXSM.

Additional Media Gateway Control Protocol

The Trunking Media Gateway Control Protocol (TGCP) is now supported for communication between the VXSM card and the Media Gateway Controller in switching applications. This is in addition to the H.248 protocol supported in earlier releases. VXSM does not support both protocols simultaneously. The user must select which one of the two protocols is to be used when the VXSM image is loaded initially from the PXM.

PRI Backhaul

In application where ISDN D channel signaling lines are connected to VXSM, the VXSM card can be configured to extract the layer 3 (Q.931) packets and backhaul them to the media gateway controller

For communication between VXSM and the media gateway controller the protocol stack is based upon the Cisco proprietary Session Manger and RUDP (Reliable UDP).

Communication between the VXSM and the gateway controller is session based. One session set must be established. The session set contain one or two session groups (one for non-fault tolerant or two for fault tolerant configurations). Each session group can support up to four RUDP sessions.

Differentiated Services (DiffServ)

VXSM provides support for the quality of service (QOS) feature known as DiffServ. The DiffServ feature permits devices at the edge of the network to specify the contents of the Type of Service (TOS) field in the IPv4 header as a differentiated services point code. This point code can then be used by routers in the network to determine per hop behavior (PHB).

Communications Assistance for Law Enforcement Act (CALEA)

VXSM provides support for CALEA intercepted calls. The CALEA feature functions only in switching applications using the TGCP gateway control protocol.

During call setup, the media gateway controller uses the TGCP commands of CRCX and MDCX with CALEA parameters to signify that a call is to be subject to CALEA surveillance. During a CALEA call, the VXSM sends a duplicate of the call contents to a TGCP defined CALEA server.

VXSM supports up to 60 concurrent CALEA calls. Statistics collection for CALEA streams is not supported.

CALEA support is an orderable item. Customers who require this feature must specify the VXSM CALEA firmware image at the time of order.

Voiceband Data Profiles and Event Mapping

Within a voice circuit call, VXSM now supports the handling of voiceband data such as clear channel, fax, and modem transmissions. VXSM can detect tones associated with voiceband data on both the voice and IP sides of the networks, and act accordingly. Upon detection of a voiceband tone, VXSM will perform the necessary upspeed procedure that may involve the following processing:

•Codec manipulation

•Silence suppression

•Disabling echo cancellation

•Modify packetization period, gain, DC offset, and jitter parameters.

VXSM informs the other (remote) end of the connection when an upspeed procedure is to be performed. There are two different methods by which upspeed at the remote end is triggered.

The first method is Fax/Modem passthrough with a Cisco proprietary protocol in which a Named Signaling Event (NSE) is sent to the remote end.

The second method is Fax/Modem passthrough with IP side tone detection and relies on both ends of the connection being able to detect tones on both the TDM and IP sides. This method is only supported with TGCP or MGCP call setup.

Fax/Modem passthrough features are as follows:

•FAX/Modem Provisioning redundancy.

•Upspeed codec from G711 to G711.

•Upspeed codec from G711 to G726.

•Upspeed codec from G729 to G711 with VXSM to VXSM with low priority.

•Upspeed codec from CCD to G711 with VXSM to VXSM with low priority.

•Upspeed codec from CCD to G726 with VXSM to VXSM with low priority.

•Graceful upgrade for fax/modem provisioning.

•Detection of the following tones, CNG(1100hz), CED/ANS(2100hz), /ANS(2100hz with phase reversal, and V.21 Fax Preamble.

The voiceband event mapping feature permits VXSM to determine how VBD events are to be handled. When this feature is configured, VBD events are mapped to different event handling functions categorized by the attributes defined in different kinds of profiles, such as fax relay profile, or VBD profile.

Firmware Images

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

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

The CALEA image supports TGCP only. However, this protocol must be explicitly selected when the image is loaded from the PXM using the setrev command.

Upgrading from an Earlier VXSM Release

VXSM can be gracefully upgraded (configuration is preserved) from VXSM Release 5.0.70 so long as the original and the upgraded images are of the same version (for example Non-CALEA, TGCP to Non-CALEA, TGCP). When loading or upgrading a boot or runtime image to a VXSM card, users must observe the following caution.

---

Caution 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 to the extent that it must be returned to the factory for repair.

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.

---

Feature Clarifications

Online Diagnostic feature as applied to VXSM.

The online diagnostics feature as implemented on the PXM45 card is supported on VXSM Release 5.0. When enabled, using the PXM45 cnfdiag command, this feature performs non-intrusive diagnostic tests that use four of the VXSM's DSP codecs.

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

MGX8850.9.VXSM.a > dspdspcodecpools

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

                 DSP codec capacity usage

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

Codec pool	 				Current utilized					Current available

					capacity (#calls)	 				capacity (#calls)

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

G711 family 							4 				8060

G729/G726/T.38 family	 						0 				4030

The online diagnostics feature does not reduce the maximum number of 8064 codecs 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 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 but towards the end, fragmentation could happen as the future pattern of calls cannot be predicted beforehand.

Configuring Switching and Trunking Applications

The simultaneous operation of mixed applications (Switched VoIP applications and Non-switched Trunking applications) is not supported on a VXSM card. However, both applications can be supported in the Media Gateway by using multiple VXSM cards.

VXSM Management Information Base

The VXSM Management Information Base (MIB) Version 5.0.70 is available by request through your Cisco VXSM product marketing representative.

Compatibility

---

Note VXSM Release 5.0.70.205 is only supported with PXM-45.

---

VXSM software interoperability with the Cisco MGX 8850 (PXM45) Multiservice Switch or the MGX 8880 Media Gateway platform software is listed in Table 1.

Table 1 VXSM Software Interoperability 

Product	Latest Firmware	Min. Firmware
PXM45	5.0.20	5.0.20
RPM-XF	12.3(7)T3	12.3(7)T3
CWM	15.0.0P4	15.0.0P4
MGM	5.0.0	5.0.0
VISM-PR*	3.3.10	3.3.10
MGX-AXSM-16-155/B	5.0.20	5.0.20
MGX-AXSM-4-622/B	5.0.20	5.0.20
BTS*	4.4.2	4.4.2
PGW	9.5.2	9.5.2
Cisco 2600 Series Routers*	c2600-ipvoice-mz.123-9.13.T	c2600-ipvoice-mz.123-9.13.T
Cisco 2600 for use as an IP Transfer Point*	c2600-itp-mz.122-21.SW bin	c2600-itp-mz.122-21.SW bin
Cisco 3700 Series Routers*	c3725-ipvoice-mz,123-9.13.T	c3725-ipvoice-mz,123-9.13.T
Cisco ATA 188*	3.2.0 for SIP/MGCP/H323	3.2.0 for SIP/MGCP/H323
Linksys PAP2 Phone Adapter	Version 2.0.6 (LS)	Version 2.0.6 (LS)
Linksys RT31 Router	Version 1.27.01	Version 1.27.01

Table 2 describes the software images available for Release 5.0.70 for VXSM.

Table 2 Software Images for Release 5.0.70.205 for VXSM 

Board Pair	Latest Boot Code Version	Minimum Boot Code Version	Firmware
MGX-VXSM-155, CALEA	vxsm_005.000.070.205_bt.fw	vxsm_005.000.070.205_bt.fw	vxsm_005.050.070.205.fw
MGX-VXSM-155, Non-CALEA	vxsm_005.000.070.205_bt.fw	vxsm_005.000.070.205_bt.fw	vxsm_005.000.070.205.fw
MGX-VXSM-T1E1, CALEA	vxsm_005.000.70.205_bt.fw	vxsm_005.000.070.205_bt.fw	vxsm_005.050.070.205.fw
MGX-VXSM-T1E1, Non-CALEA	vxsm_005.000.070.205_bt.fw	vxsm_005.000.070.205_bt.fw	vxsm_005.000.070.205.fw

Caveats for VXSM Release 5.0.70.205

This section describes software caveats for Release 5.0.70.205

Open Caveats in Release 5.0.70.205

Table 3 describes the open caveats in VXSM Release 5.0.70.205

Table 3 Open Software Caveats for VXSM Release 5.0.70.205 

DDTS Issue	Description
CSCei79385	Headline: Call rejected due to mgcp_connect_peer_vox_call_leg failure Symptoms: There is 0.01% of DSP channel failures.This causes about 0.01% of call failures as well. Conditions: DSP OPEN failures. And then there gateway initiated DLCX's. Workaround: None
CSCei88677	Headline: AAL2:cnfcon fails giving Internal Software Error (Agere fails) Symptom: Cnfcon fails on modifying lpcr and rpcr on VXSM master side of bearer. Conditions: It happens when the following conditions are met - 1. The service-type for the connection is CBR. 2. The old and new PCR values (adjusted to the next higher multiple of 50) are the same. Workaround: Set the new PCR to a different value so that condition 2 above is not met.
CSCeh12805	Headline: ip availability should not block entering configuration Symptom: addmgcgrpmgc,cnfxgcpmgc can not be done if cnfmgc returns error. Conditions: cnfmgc can fail if DNS server is not configured for this mgc domain or DNS server is not reachable. Workaround: Make sure mgc domain name entry is present in the DNS server configured and DNS server is available. If this can not be done then add IPs statically on the gateway till the DNS server is back up.
CSCei89988*	Headline: AAL2:Difference in Utilized cell rate after downspeed(cust prof 110) Symptom: When using custom 110 profile after a upseed and downspeed the CAC usage will be slightly higher. Conditions: This happens because after a downspeed the correct packetization period for the profile is not used. Workaround: None besides using a slightly higher BW for the PVC
CSCeh47956*	Headline: sysDiag reported online diag failure for VXSM causing reset Symptom: Online diag failure Conditions: The error happened under intermittent hardware failure condition of the ATMizer parity on the one card. Workaround: Online diag may be turned off by issuing cnfdiag slot# disable However, the errors noted was one-time occurrence for one card where the hardware failure occurred, and was un-reproducible on another chassis. The card will not be reset if there is no redundancy (as the diagnostic failures are Major, not fatal). If there is redundancy set up, the card would be reset.
CSCeh48876*	Headline: dspchanloops shows the opposite of configured chan loop type Symptoms: VXSM displays wrong loopback type information with dspchanloops command. Conditions: This symptom was observed while displaying dspchanloops command. Workaround: Use dspchanloop command to display loopback information.
CSCeh56654	Headline: AAL2MP:VSIC-2-VSIMAJORERR on VXSM-RED after PXM45 reset Symptom: VSI error log on the system Conditions: This error is for releasing TCB buffers and it happens when PXM card gets reset in the shelf without having redundancy for PXM card. Workaround: The error is harmless but needs to be identified
CSCeh36036	Headline: AAL2MP: Delcon failed on slave, stuck in Mismatch, after Switched Symptoms: VXSM was confogired for redundancy. VXSM displays "Invalid opcode in received passup response msg!" error instead of appropriate error when delcon command was executed while Standby is coming up. Conditions: This symptom was observed while deleting slave connection during standby card was in initialization state. Workaround: Don't delete the slave connection while standby is coming up.
CSCeh39863*	Headline: AAL2MP:SYS-3-RUNAWAYTASK error logged during Offline Diag Symptom: A SYS-3-RUNAWAY warning message is logged during offline diag execution. Conditions: There is no condition which will cause the message to be logged. WorkAround: There is no affect on the node and card under test, other than the warning message being logged.
CSCeh46000*	Headline: PcmTraceTas hogging mem.buffer (all caller-ctc_msg_evt_deliver) Symptom: PcmTraceTask blocks while taking an Empty Binary Semaphore. This could be viewed as a ssi memory leak. Conditions: The task will remain blocked until PCM tracing has started. Workaround: None Further Problem Description: The resource will be held up until PCM tracing is performed in order to debug any issue. With that the Empty Binary Semaphore is released and the Pcmtrace task unblocks. This is a very minor issue and the memory held is very small and it does not vary. There is not impact on the performance of other tasks and there is no resource contention with other tasks.
CSCeh43530*	Headline: Ecan still ON during V.34 modem calls with AAL2 M->M configuration Symptom: When make trunking modem call (CED with PR), during upspeed, the ECAN on the original side kept as ON. The modem call passed successfully. Conditions: It is happen only if both CAC are set to master. Workaround: Set CAC to slave in one side if it is allowed; otherwise none.
CSCeh50745*	Headline: cardMon task exception error caused card reset. Symptom: When resetcd is performed on a VXSM card there is a very slight chance that.it will encounter a Vector 7 Exception and then reset itself again. It should.then come up normally. Conditions: A large amount of VXSM resetcd calls should lead to this problem. Workaround: None is needed since it is self-correcting. Once it hits this Vector 7 exception it will reset itself and come up normally afterwards.
CSCei06436*	Headline: GW sends 510 for valid AUCX message (with Conn ID only) Symptom: An AUCX command with no RequestedInfo or an empty RequestedInfo is rejected with 510, protocol error in TGCP. Conditions: Always. Workaround: None.
CSCie06437*	Headline: GW sends 200 for AUEP with forbidden parameters Symptom: An AUEP command with forbidden params is wrongly rejected as "200 Endpoint exists" Conditions: Always. Workaround: None.
CSCei53902	Headline: Stuck calls on VXSM (crml_nw_reserve_cac failures) Symptom: A lot of CRCX failures due to '403, Gateway does not have available resource'. Conditions: This happens whenever a DIM timeout happens for an open channel requests and the subsequent close channel request. The resources for such calls are not released resulting in subsequent call attempts on that physical endpoint failing. Workaround: None.
CSCej00528*	Headline: DSP core number ## crashed Symptom: Card resets/switches-over Condition: DSP resources are leaked when doing a dellapd. This causes over utilization of DSP resources when running near capacity steady-state calls after addlapd/dellapd sequences. Workaround: If lapd channels must be deleted, issue dellapd and switchover to redundant card immediately.
CSCef92799	Headline: In AAL2 trunking, vad and ec while uspeeding gives wrong state Symptom: This is only for trunking upspeed (fax call) between VXSM and VISM and the fax call from VXSM to VISM which means the call is detected on VISM side. During upspeed, the ECAN of the VXSM changed to disable, but the ECAN of VISM kept as enable. The reason of ECAN of VXSM changed to disable is VISM sending NSE193 to VXSM. Conditions: (1) Add cid between VXSM and VISM as: VAD on ECAN on (2) Send fax call from VXSM to VISM (V.21 Fax pre. tone detected on VISM side) (3) During upspeed check ECAN for both VXSM cid and VISM cid: ECAN off in VXSM cidECAN on in VISM cid (4) the fax call passed successful Workaround: None.
CSCin96917*	Headline:Codec Change from PCMU to G726-32/G729 causes call to drop Symptom: The problem will happen when we do a non-calea call involving a codec change from lower complexity to higher complexity (say G711 to G726) after call cut-through on a CALEA image. If it is a normal image this will not happen. Conditions: This is a baseline problem. For any mid-call codec change a close and re-open of the DSP channel is involved. In these cases even though no CALEA is configured for the call the APIL module sets the CALEA configuration bit. When the bit is acted upon by CM the call fails. Workaround: The fix is to set the CALEA bits only if a CALEA IP server configuration is found in CRML.
CSCen91151*	Headline: AAL2:cnfcon fails giving Internal Software Error (Agere fails) Symptom: Cnfcon fails on modifying lpcr and rpcr on VXSM master side of bearer. Conditions: It happens when the following conditions are met - 1. The service-type for the connection is CBR. 2. The old and new PCR values (adjusted to the next higher multiple of 50) are the same. Workaround: Set the new PCR to a different value so that condition 2 above is not met. Otherwise, delete and re-add the connection.
CSCeh48550*	Headline: 30% of modem passthrough call connect in 14400 Symptom: About 30% (15/49) modem passthrough calls connect at 14400 instead of 50K when the initial codec is G726-32. This problem is more consistent from the IAD->VXSM direction. some calls in the VXSM->IADs direction also connect in 14400, but fewer than the other directions. When the initial codec is G711, 90%+ of the calls connect at 50K and above. the upspeed codec used is G711. Conditions: Workaround: No workaround. Use G711 as the initial codec.
CSCei02696*	Headline: dspconcacs/dspxgcpendptcons not working if ced event = none Symptom: dspconcacs/dspxgcpendptcons not working correctly Conditions: set ced event to none Workaround: use dspxgcpendptcon for each endpt
CSCei58143*	Headline: SYS-2-DCARPCCBFAILED Errors due to tRpc task after runrev Symptom: SYS-2-DCAPRPCCBFAILED Error messages Conditions: Loadrev/runrev Workaround: NONE

.

---

Note DDTS Items in the table above that are marked with an asterisk (for example, CSCeh47956*) are planned to be resolved in the VXSM Release 5.2 with an availability of October, 2005.

---

Resolved Caveats in Release 5.0.70.205

Table 4 lists the open caveats that existed in VXSM Release 5.0.20 and are now resolved in Release 5.0.70.

Table 4 Release 5.0.70 Caveats that are resolved in Release 5.0.70.205 

DDTS Issue	Description
CSCeh11539	Headline: Card failed with CRML DSPAPI ERR, sustaining 2STM1 g.729a
CSCeh47935	Headline: tsyncRamdb failed to unblock the application
CSCeh36036	Headline: AAL2MP: Delcon failed on slave, stuck in Mismatch, after Switched

.

---

Note A number of caveats listed as open in VXSM Release 5.0.70 have been deemed to be either invalid or inconsequentialand, as such, have been deleted from the VXSM caveats lists. The caveats in this category are:
CSCeh52082, CSCeh55195, CSCeh49855, CSCeh44232, CSCeh46551, CSCeh00191, CSCeh88929, CSCei86716, and CSCeh17624

---

Caveats Opened after 5.0.70 and now resolved in Release 5.0.70.205

Table 5 lists the caveats opened after VXSM Release 5.0.70 and are now resolved in Release 5.0.70.205

Table 5 Post Release 5.0.70 Caveats that are resolved in Release 5.0.70.205 

DDTS Issue	Description
CSCeh81952	Headline: In 48T1 mode, the HHM memory is corrupted due to invalid T1 index
CSCei10491	Headline: DSP keep-alive failure when rx-codec changes msec before prof-shrink
CSCei14438	Headline: DSP keepalive failure when pkts with 2 different SSRCs are received
CSCeh11539	Headline: 1.5MR:card failed with 45CPS and capacity over-subscription
CSCeh74408	Headline: cnfcon command unable to change slave side -rputil/-lputil commands
CSCeh76246	Headline: VXSM sends RTCP packets with 0 length SDES CMAME string
CSCeh88923	Headline: Bad voice quality using G726-32K by making call between AS5350&VXSM
CSCeh96282	Headline: PVC connection goes into alarm after changing utilization
CSCei02588	Headline: cnfcid for codec change G.729->G.726 => DSP crash
CSCei06218	Headline: VXSM doesnt handle an odd numbered UDP port for RTP
CSCei11163	Headline: DSP keep-alive failure when rx-codec changes msec before prof-shrink
CSCei12761	Headline: Active card takes a long time in init. state when resetcd with calls
CSCei18491	Headline: In 48T1E1, BC of active card(w. gangcard) reset when offln diag runs"
CSCei19901	Headline: DSP channel exception on some channels while running fax calls
CSCei19906	Headline: Standby recreate problem for modify operation (VoIP calls)
CSCei19938	Headline: VXSM needs to timeout if core-dump takes too long
CSCei25619	Headline: The TEMUX interrupt not handle properly, cause DC reboot in 48T1E1
CSCei30987	Headline: DSP Core-dump Enhancements based on issues unearthed at Vonage
CSCei32443	Headline: DLCX journalling fails after MDCX codec chg fails on ACTV card
CSCei38062	Headline: tdmDSX1cfg callback error on vxsm when processing 9cps
CSCei38079	Headline: Standby modify callback - DSP_DRV_FAILURE and CRML status 15
CSCei38085	Headline: VXSM resets under call load with bursty traffic
CSCei38902	Headline: Standby card pending for resource indefinitely
CSCei45037	Headline: Core-dump functionality stalled if one of the read req lost
CSCei48279	Headline: Codec change from G711->G726 fails after card swaitches over
CSCei52506	Headline: Close channel should not be blocked even if no trans elems available
CSCei77954	Headline: DSP keep-alive failure with exception 0x0433 and 0x04a5
CSCei83667	Headline: MGCP memory leak in MGCPAPP in the codec list chunk pool
CSCei88643	Headline: 48T1E1 card status is shown incorrectly from PXM after doing setrev
CSCeh66107	Headline: Random DS1s goes into alarm after VXSM configuration
CSCeh85646	Headline: Incorrect CP level for US/Canada and Freq. for France
CSCei15097	Headline: Benign errors seen on standby card when doing G711->g726 codec chang
CSCei24678	Headline: DSP ping failure during VOIP calls with some ATAs
CSCei30812	Headline: crml redundancy recreate error cause by DSP. standby didnt reset
CSCei39041	Headline: T.38 download codec error logged
CSCei39221	Headline: DSP open failure results in GW DLCX instead of nacked CRCX
CSCei65326	Headline: "ringback tone too loud, passing 0.0dBm0 to the DSP."
CSCei02195	Headline: Display per OC3 active call count
CSCei10496	Headline: DSP failure to be reported to CRML in addition to HHM
CSCei56675	Headline: Need to interop with linksys ATAs using odd RTP port numbers
CSCei84757	Headline: Enhancement: create histogram for jitter and packet loss for calls

.

The MGX-VXSM-155 card is also known as the MGX-VXSM-4OC card.

The MGX-VXSM-T1/E1 card is also known as the MGX-VXSM-48T1/E1 card.

Related Documentation

The following documents contains information that may be useful to software Release 5.0 for VXSM:

•Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830 Configuration Guide, Release 5

•Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830 Hardware Installation Guide, Releases 2 Through 5

•Cisco ATM Services (AXSM) Configuration Guide and Command Reference for MGX Switches, Release 5

•Cisco MGX Route Processor Module (RPM-XF) Installation and Configuration Guide, Release 4

•Cisco MGX 8880 Media Gateway: A Guide to User Documentation.

•Release Notes for Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830 Switches, Release 5.0.00

Obtaining Documentation

Cisco documentation and additional literature are available on Cisco.com. Cisco also provides several ways to obtain technical assistance and other technical resources. These sections explain how to obtain technical information from Cisco Systems.

Cisco.com

You can access the most current Cisco documentation at this URL:

http://www.cisco.com/univercd/home/home.htm

You can access the Cisco website at this URL:

http://www.cisco.com

You can access international Cisco websites at this URL:

http://www.cisco.com/public/countries_languages.shtml

Documentation DVD

Cisco documentation and additional literature are available in a Documentation DVD package, which may have shipped with your product. The Documentation DVD is updated regularly and may be more current than printed documentation. The Documentation DVD package is available as a single unit.

Registered Cisco.com users (Cisco direct customers) can order a Cisco Documentation DVD (product number DOC-DOCDVD=) from the Ordering tool or Cisco Marketplace.

Cisco Ordering tool:

http://www.cisco.com/en/US/partner/ordering/

Cisco Marketplace:

http://www.cisco.com/go/marketplace/

Ordering Documentation

You can find instructions for ordering documentation at this URL:

http://www.cisco.com/univercd/cc/td/doc/es_inpck/pdi.htm

You can order Cisco documentation in these ways:

•Registered Cisco.com users (Cisco direct customers) can order Cisco product documentation from the Ordering tool:

http://www.cisco.com/en/US/partner/ordering/

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

Documentation Feedback

You can send comments about technical documentation to bug-doc@cisco.com.

You can submit comments by using the response card (if present) behind the front cover of your document or by writing to the following address:

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

We appreciate your comments.

Cisco Product Security Overview

Cisco provides a free online Security Vulnerability Policy portal at this URL:

http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

From this site, you can perform these tasks:

•Report security vulnerabilities in Cisco products.

•Obtain assistance with security incidents that involve Cisco products.

•Register to receive security information from Cisco.

A current list of security advisories and notices for Cisco products is available at this URL:

http://www.cisco.com/go/psirt

If you prefer to see advisories and notices as they are updated in real time, you can access a Product Security Incident Response Team Really Simple Syndication (PSIRT RSS) feed from this URL:

http://www.cisco.com/en/US/products/products_psirt_rss_feed.html

Reporting Security Problems in Cisco Products

Cisco is committed to delivering secure products. We test our products internally before we release them, and we strive to correct all vulnerabilities quickly. If you think that you might have identified a vulnerability in a Cisco product, contact PSIRT:

•Emergencies — security-alert@cisco.com

•Nonemergencies — psirt@cisco.com

---

Tip We encourage you to use Pretty Good Privacy (PGP) or a compatible product to encrypt any sensitive information that you send to Cisco. PSIRT can work from encrypted information that is compatible with PGP versions 2.x through 8.x.

Never use a revoked or an expired encryption key. The correct public key to use in your correspondence with PSIRT is the one that has the most recent creation date in this public key server list:

http://pgp.mit.edu:11371/pks/lookup?search=psirt%40cisco.com&op=index&exact=on

---

In an emergency, you can also reach PSIRT by telephone:

•1 877 228-7302

•1 408 525-6532

Obtaining Technical Assistance

For all customers, partners, resellers, and distributors who hold valid Cisco service contracts, Cisco Technical Support provides 24-hour-a-day, award-winning technical assistance. The Cisco Technical Support Website on Cisco.com features extensive online support resources. In addition, Cisco Technical Assistance Center (TAC) engineers provide telephone support. If you do not hold a valid Cisco service contract, contact your reseller.

Cisco Technical Support Website

The Cisco Technical Support Website provides online documents and tools for troubleshooting and resolving technical issues with Cisco products and technologies. The website is available 24 hours a day, 365 days a year, at this URL:

http://www.cisco.com/techsupport

Access to all tools on the Cisco Technical Support Website requires a Cisco.com user ID and password. If you have a valid service contract but do not have a user ID or password, you can register at this URL:

http://tools.cisco.com/RPF/register/register.do

---

Note Use the Cisco Product Identification (CPI) tool to locate your product serial number before submitting a web or phone request for service. You can access the CPI tool from the Cisco Technical Support Website by clicking the Tools & Resources link under Documentation & Tools. Choose Cisco Product Identification Tool from the Alphabetical Index drop-down list, or click the Cisco Product Identification Tool link under Alerts & RMAs. The CPI tool offers three search options: by product ID or model name; by tree view; or for certain products, by copying and pasting show command output. Search results show an illustration of your product with the serial number label location highlighted. Locate the serial number label on your product and record the information before placing a service call.

---

Submitting a Service Request

Using the online TAC Service Request Tool is the fastest way to open S3 and S4 service requests. (S3 and S4 service requests are those in which your network is minimally impaired or for which you require product information.) After you describe your situation, the TAC Service Request Tool provides recommended solutions. If your issue is not resolved using the recommended resources, your service request is assigned to a Cisco TAC engineer. The TAC Service Request Tool is located at this URL:

http://www.cisco.com/techsupport/servicerequest

For S1 or S2 service requests or if you do not have Internet access, contact the Cisco TAC by telephone. (S1 or S2 service requests are those in which your production network is down or severely degraded.) Cisco TAC engineers are assigned immediately to S1 and S2 service requests to help keep your business operations running smoothly.

To open a service request by telephone, use one of the following numbers:

Asia-Pacific: +61 2 8446 7411 (Australia: 1 800 805 227)
EMEA: +32 2 704 55 55
USA: 1 800 553-2447

For a complete list of Cisco TAC contacts, go to this URL:

http://www.cisco.com/techsupport/contacts

Definitions of Service Request Severity

To ensure that all service requests are reported in a standard format, Cisco has established severity definitions.

Severity 1 (S1)—Your network is "down," or there is a critical impact to your business operations. You and Cisco will commit all necessary resources around the clock to resolve the situation.

Severity 2 (S2)—Operation of an existing network is severely degraded, or significant aspects of your business operation are negatively affected by inadequate performance of Cisco products. You and Cisco will commit full-time resources during normal business hours to resolve the situation.

Severity 3 (S3)—Operational performance of your network is impaired, but most business operations remain functional. You and Cisco will commit resources during normal business hours to restore service to satisfactory levels.

Severity 4 (S4)—You require information or assistance with Cisco product capabilities, installation, or configuration. There is little or no effect on your business operations.

Obtaining Additional Publications and Information

Information about Cisco products, technologies, and network solutions is available from various online and printed sources.

•Cisco Marketplace provides a variety of Cisco books, reference guides, and logo merchandise. Visit Cisco Marketplace, the company store, at this URL:

http://www.cisco.com/go/marketplace/

•Cisco Press publishes a wide range of general networking, training and certification titles. Both new and experienced users will benefit from these publications. For current Cisco Press titles and other information, go to Cisco Press at this URL:

http://www.ciscopress.com

•Packet magazine is the Cisco Systems technical user magazine for maximizing Internet and networking investments. Each quarter, Packet delivers coverage of the latest industry trends, technology breakthroughs, and Cisco products and solutions, as well as network deployment and troubleshooting tips, configuration examples, customer case studies, certification and training information, and links to scores of in-depth online resources. You can access Packet magazine at this URL:

http://www.cisco.com/packet

•iQ Magazine is the quarterly publication from Cisco Systems designed to help growing companies learn how they can use technology to increase revenue, streamline their business, and expand services. The publication identifies the challenges facing these companies and the technologies to help solve them, using real-world case studies and business strategies to help readers make sound technology investment decisions. You can access iQ Magazine at this URL:

http://www.cisco.com/go/iqmagazine

•Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering professionals involved in designing, developing, and operating public and private internets and intranets. You can access the Internet Protocol Journal at this URL:

http://www.cisco.com/ipj

•World-class networking training is available from Cisco. You can view current offerings at this URL:

http://www.cisco.com/en/US/learning/index.html

CCSP, CCVP, the Cisco Square Bridge logo, Follow Me Browsing, and StackWise are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, and iQuick Study are service marks of Cisco Systems, Inc.; and Access Registrar, Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, FormShare, GigaDrive, GigaStack, HomeLink, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, LightStream, Linksys, MeetingPlace, MGX, the Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, ProConnect, RateMUX, ScriptShare, SlideCast, SMARTnet, StrataView Plus, TeleRouter, The Fastest Way to Increase Your Internet Quotient, and TransPath are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.

All other trademarks mentioned in this document or Website 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. (0502R)

Copyright © 2005, Cisco Systems, Inc.
All rights reserved.