Table Of Contents
Release Notes for Cisco Voice Switch Service Module (VXSM) Release 5.0.20
Table of Contents
About Release 5.0.20
New Features in Release 5.0.20
Additional Media Gateway Control Protocol
PRI Backhaul
Differentiated Services (DiffServ)
Computer Assisted 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.20
Open Caveats in Release 5.0.20
Resolved Caveats in Release 5.0.20
Related Documentation
Obtaining Documentation
Cisco.com
Ordering Documentation
Documentation Feedback
Obtaining Technical Assistance
Cisco TAC Website
Opening a TAC Case
TAC Case Priority Definitions
Obtaining Additional Publications and Information
Release Notes for Cisco Voice Switch Service Module (VXSM) Release 5.0.20
These release notes are part number OL-5643-01 Rev. B0, March, 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.20
The VXSM 5.0.20 Release follows VXSM Release 5.0.02.
New Features in Release 5.0.20
The following new features are 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).
Computer Assisted 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 G729 to G711 with VXSM to VXSM with low priority.
•Upspeed codec from CCD to G711 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 or T1/E1), 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 is available in two versions. One version supports the H.248 media gateway controller protocol and the other supports the TGCP medil gateway controller protocol. The user must choose between the H.248 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 card is first loaded using the setrev command.
Upgrading from an Earlier VXSM Release
VXSM can be gracefully upgraded (configuration is preserved) so long as the original and the upgraded images are of the same version. Because CALEA and TGCP are being introduced in this release and therefore do not exist in earlier releases, the only upgrade support to 5.0.20 is from the Non-CALEA, H.248 version to the Non-CALEA, H.248 version.
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.
Afte the execution of the burnboot, clrsmcnf, loadrev, or setrev commands, the user must execute either a
dspcds or
dsprev command periodically to vefify 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
=============================================================
=============================================================
Codec pool Current utilized Current available
capacity (#calls) capacity (#calls)
========== ================= =================
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.20 is available by request through your Cisco VXSM product marketing representative.
Compatibility
Note VXSM Release 5.0.20 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.0P3
|
15.0.0P3
|
MGM
|
5.0.0
|
5.0.0
|
VISM-PR
|
3.3.00
|
3.3.00
|
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.1
|
4.4.0
|
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.1.1 for SIP/MGCP/H323
|
3.1.1 for SIP/MGCP/H323
|
Table 2 describes the software images available for Release 5.0.20 for VXSM.
Table 2 Software Images for Release 5.0.20 for VXSM
Board Pair
|
Latest Boot Code Version
|
Minimum Boot Code Version
|
Firmware
|
MGX-VXSM-155, CALEA
|
vxsm_005.000.002.200_bt.fw
|
vxsm_005.000.000.200_bt.fw
|
vxsm_005.050.020.200.fw
|
MGX-VXSM-155, Non-CALEA
|
vxsm_005.000.002.200_bt.fw
|
vxsm_005.000.000.200_bt.fw
|
vxsm_005.000.020.200.fw
|
MGX-VXSM-T1E1, CALEA
|
vxsm_005.000.002.200_bt.fw
|
vxsm_005.000.000.200_bt.fw
|
vxsm_005.050.020.200.fw
|
MGX-VXSM-T1E1, Non-CALEA
|
vxsm_005.000.002.200_bt.fw
|
vxsm_005.000.000.200_bt.fw
|
vxsm_005.000.020.200.fw
|
Caveats for VXSM Release 5.0.20
This section describes software caveats for Release 5.0.20.
Open Caveats in Release 5.0.20
Table 3 describes the open caveats in VXSM Release 5.0.20.
Table 3 Open Software Caveats for VXSM Release 5.0.20
DDTS Issue
|
Description
|
CSCeg20645
|
Headline: Enabling VAD causes voice quality score to drop
Condition:
1. Primary Condition:
CU-Timer >= 15msec: The definition of this profile does not give much timing information for the jitter-buffer to playout received cells when the jitter is greater than 15msec. With the CU-Timer >= 15msec, this condition occurs and leads to drops/losses at the jitter-buffer and poor voice quality.
2. Secondary Condition:
VAD Enabled: Custom 110 is defined such that it contains only one row for G.729ab at 30msec pkt period. Since G.729ab (standard VAD) transmits partial packets of 20msec and 10msec pkt period, the profile needs to contain those rows. However, with the current definition of the profile, we achieve the same voice-quality as VISM-VISM.
Workaround: Set the remote CU-Timer <= 10msec.
|
CSCin85117
|
Headline: cnfvifterm fails with error code 921 when descriptive name enabled
Symptom: If user configures the descriptive name option cnfh248nameschema, and then use cnfvifterm to configure the vif terms, the CLI fails.
Conditions: Steps to reproduce the bug:
cnfh248nameschema 1 # #
addvif
cnfvifterm
Workaround: Use non descriptive name option
|
CSCeg48031
|
Headline: VXSM sends line level RSIP instead of root level
Symptom: Line level RSIP's will be generated instead of the root level RSIP
Conditions: In the middle of an uppath and addvif configuration, an alarm on the line occurs.
Workaround: None
Further description: This shouldn't affect the functioning of the connections. The MGC still gets to know that the lines are in service and can accept new connections.
|
CSCeg51035
|
Headline: MGC traversal does not work in the right order for RSIP
Symptom: In the middle of the traversal of MGC's, a one-off RSIP is sent out of sequence
Conditions: Traversing 4 MGC's in the MGC group
Workaround: None
|
CSCeg53337
|
Headline: End to end bearer path is established when COT is in progress
Symptom: When a COT test is in progress towards the TDM side, the voice stream from the TDM is forwarded to the PKT side and vice versa.
Conditions: When a continuity test is in progress, the leakage of the COT signals/voice streams on the TDM network into the packet network happens when the DSP channel's mode is anything other than inactive (i.e., in case of calls set up via XGCP, the connection mode of the connection set up on this TDM endpoint is other than inactive and in calls set up via H.248, the stream mode of the PDN termination sharing a context with the SCN termination is anything other than inactive).
Workaround: None
|
CSCeg54211
|
Headline: delvif after switchover does not generate RSIP
Symptom: After switchover, the very first delvif doesn't work
Condition: Add a line, in a redundant setup and try to delete it after switchover
Workaround: None
|
CSCeg55517
|
Headline: Unsolicited Console display during CAC rejection
Symptom: An NSAP address is printed on the console of the VXSM.
Conditions: This happens whenever a CAC failure happens during call setup or upspeed attempt.
Workaround: From the VXSM shell, set the global variable gCrmlDebugOn to 0 (gCrmlDebugOn=0). This action essentially turns off CRML module's facility to upload debug information to PXM upon failures.
|
CSCin84810
|
Headline: Service Change not sent from 1.4 OC3 line upon introducing alarms
Symptom:
Service Change Message being not sent to Call Agent from VXSM for OC3 line 4 when it is put into alarm state
Conditions:
Configure the BFG for a regular VOIP configuration with vifterms added for all the 4 lines.
Now bring up the H248Voip call on the line 4. When the call is up, pull out the 4th OC3 line physically from the MGX chassis. Wait for few minutes. When attempted to tear down the same call ,no line level. Service Change message is sent from the Media gateway and the call is teared down smoothly.
Hence with any kind of alarms no line level Service Change message is not sent for line 4, whereas Service Change message is sent from line 1 or 2 with the same scenario.
Workaround: None
|
CSCef92799
|
Headline: In AAL2 trunking, vad and ec while uspeeding gives wrong state
Symptom: This is only for trunking upspeed (fax call) between BFG and VISM and the fax call from BFG to VISM which means the call is detected on VISM side. During upspeed, the ECAN of the BFG changed to disable, but the ECAN of VISM kept as enable. The reason that ECAN of BFG changed to disable is VISM sending NSE193 to BFG. This problem does not affect the service, the fax call passed successfully and this also may not be a BFG issue.
Conditions:
(1) add cid between BFG and VISM as:
VAD on
ECAN on
(2) send fax call from BFG to VISM (V.21 Fax pre. tone detected on VISM side)
(3) during upspeed check ECAN for both BFG cid and VISM cid:
ECAN off in BFG cid
ECAN on in VISM cid
(4) the fax call passed successfully
Workaround: Not need, it does not affect service
|
CSCeg29796
|
Headline: CCD codec upspeed has diff. Ecan state on ori & term. endpoints
Symptom:
This is only for TGCP upspeed (fax call) in the following condition:
(1) TGCP call setup on secondary card (primary card in standby status)
(2) upspeed from G729AB to Clear channel
The problem is:
During upspeed, the ECAN on original side changed from enable to disable, but ECAN on terminal side kept as enable, according to design intent, ECAN on both side should be keptas enable.
Conditions:
(1) add card redundancy
(2) switch to secondary card
(3) add TGCP VoIP call (with codec G729AB, ECAN on) on the secondary card or switch back to primary card and add the TGCP call on the primary card
(4) configure the upspeed codec to CC
(5) send fax call over the VoIP call
(6) during upspeed, the ECAN in the original side changed to off, but ECAN in the terminate side kept as on
(7) the fax call passed successfully
Workaround: None.
|
CSCeg40468
|
Headline: deleventmapping needs to delete entry with just one index
Symptom:
For each eventmapping index, there should be two event types (one is CED, another is V21Tone) associated with it. CLI "addeventmapping <EventMappingIndex>" automatically add two event mapping entries with the same event mapping index.
So CLI "deleventmapping <EventMappingIndex>" always delete these two event types at once, if somehow one of event types cannot be deleted, the system will automatically roll back the deletion.
The behavior of CLI deleventmapping causes problem when SNMP users add only one event type for a event mapping index without another event type, for example, only CED event type is added without V21Tone event type. Then this CED event type cannot be deleted by CLI deleventmapping because CLI always roll back while it encounters error of deleting V21Tone event type.
Conditions:
Use SNMP untility (setany) to add one (either CED or V21Tone) of event types for an event mapping index. Invoke CLI "deleventmapping <EventMappingIndex>" with error message - Err: Entry is not in table
Workaround:
Use SNMP utility (setany) to delete this event type.
Don't use CLI "deleventmapping <EventMappingIndex>"
|
CSCeg51713
|
Headline: With AAL2 trunking - some dtmf missing with vad on (G711 and G726)
Symptom: Some DTMF pass-through packets get dropped at the DSP jitter-buffer when VAD is ON using AAL2 trunking in the case of G.711 and G.726-32 codecs.
Conditions: DTMF pass-through cells get dropped at the jitter-buffer whenever there are SID retransmissions (more than 1 SID per silence).
Workaround: If the SID retransmission is disabled, we do not have the cell drops. This means 1 SID is sent per silence interval. Hence CNG adapts when moving from one silence interval to the other.
cnfdsp -vad -ds0 <LineNum:ds0> 2 -smtr 0
|
CSCeg46095
|
Headline: DTMF Relay doesn't work when MGC omits optional NTE fmtp line
1. Symptom: When MGC sends NTE information in CRCX m-line and rtpmap-line, but omits the optional fmtp line for NTE, the NTE payload type is ignored and DTMF relay is disabled:
m=audio 16416 RTP/AVP 0 101 100
a=rtpmap:101 telephone-event/8000
Since the fmtp line is optional, it is correct to send CRCX without it. When this line is absent, the default set of events 0-15 (digits 0-9A-D*#) should be implied for DTMF relay, and the NTE payload type should not be ignored.
Conditions: The problem occurs when fmtp line is omitted.
Workaround: Include the fmtp line even if it contains only the default events:
Example:
m=audio 16416 RTP/AVP 0 101 100
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
|
CSCeg57781
|
Headline: VXSM should reject RQNT if GW is forced OOS using cnfgwoos
Symptoms: When the GW is OOS, RQNT is accepted
Conditions: GW is places OOS using cnfgwoos CLI, then generate the RQNT
from the MGC
Workaround: None
|
CSCeg60497
|
Headline: cli updated needed for sensor 6 for new version hw
Symptom:
Voltage sensor 6 on the VXSM card has been removed, but CLIs that display voltage sensor information still shows it as present and reporting invalid information.
Conditions:
When "dspenvalms -volt 6" and "dspenvalmcnfs -volt 6" CLI commands are used to display voltage sensor 6 information, fixed (and invalid) values are display even there is no voltage sensor 6 on the VXSM card.
Workaround:
Please ignore any information related to voltage sensor 6 on the VXSM card.
|
CSCeg64615
|
Headline: RCON information displayed incorrectly when using VXSM.
Symptom:
When someone uses the "dsprcon #" or the "show inventory" cli command from the pxm it currently does not display a correct VID or 73-level part number for an rcon connected to a VXSM card.
Currently the "dsprcon #" command also incorrectly describes the rcon as a VXSM_RCON_1TO5 instead of the correct RCON-1TO5-8850 in the description field although the type field correctly reports it as RCON-1TO5.
Condition:
This condition occurs when a RCON is installed.
Workaround:
For now please ignore the "Description" field in the "dsprcon #" command and
instead use the "Inserted Rcon Nvid/Type" field to identify an rcon type. Also to obtain the VID or 73-Level Part Number, please use the rcon serial number and derive the VID or 73-Level Part Number from it.
|
CSCeg60879
|
Headline: Upgrade fails from 5.50(15.23)A to 5.50(16.17)P1
Symptom:
When perform loadrev during VXSM upgrade, the standby card will go into failed state.
Condition:
This problem occurs only if you are doing a graceful upgrade from any pre-FCS image to FCS image numbered 5.0(20.x) or 5.50(20.x).
Workaround:
This bug is due to some configuration on the cards that needs to be removed. If you have given any of the following commands before the upgrade, then that configuration needs to be deleted using the corressponding delete command. You can proceed with the upgrade after that and then re-add the configuration after the upgrade is complete.
In summary, here are the steps to workaround the problem.
(1) Stop all the calls.
(2) If you added an internal MGC using the following commands, delete that configuration:
Add Sequence:
addmgcdn
addmgcip
addmgcgrpmgc
cnfxgcpmgcgrp 1
Delete Sequence:
cnfxgcpmgcgrp 0
delmgcgrpmgc
delmgcip
delmgcdn
(3) If you added an external DNS server using the following commands, delete that configuration:
Add Sequence:
adddnsdn
adddnssrvrip
cnfgwdn
cnfmgc 1 2
Delete Sequence:
cnfmgc 1 1
cnfgwdn cisco.com (This is the default value)
deldnssrvrip
deldnsdn
(4) Perform the graceful upgrade to the new revision.
(5) Add back the configuration that you deleted in step (2) and (3).
(6) Start running the calls.
|
.
Resolved Caveats in Release 5.0.20
Table 4 describes the open caveats that existed in VXSM Release 5.0.02 and are now resolved in Release 5.0.20.
Table 4 Release 5.0.02 Caveats that are resolved in Release 5.0.20
DDTS Issue
|
Description
|
CSCee88282
|
Headline: Ecan still ON during hairpin modem calls
|
CSCef30919
|
Headline: Standby card failure on performing switchovers
|
CSCef33806
|
Headline: Resource Allocation failures after 3 swovers at 70cps
|
CSCef44373
|
Headline: addcon fails when 2 controllers (PAR,PNNI) are configured on PXM
|
CSCef59551
|
Headline: Call failures at high call rate with announcements
|
CSCin76515
|
Headline: Few lines go down on VXSM 48T1E1 after VXSM switchover.
|
CSCuk52672
|
Headline: VXSM sends error 430 when receives NULL context audit on busy term
|
.
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 on the World Wide Web at this URL:
http://www.cisco.com/univercd/home/home.htm
You can access the Cisco website at this URL:
http://www.cisco.com
International Cisco websites can be accessed from this URL:
http://www.cisco.com/public/countries_languages.shtml
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/index.shtml
•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 800 553-NETS (6387).
Documentation Feedback
You can submit e-mail 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.
Obtaining Technical Assistance
For all customers, partners, resellers, and distributors who hold valid Cisco service contracts, the Cisco Technical Assistance Center (TAC) provides 24-hour-a-day, award-winning technical support services, online and over the phone. Cisco.com features the Cisco TAC website as an online starting point for technical assistance. If you do not hold a valid Cisco service contract, please contact your reseller.
Cisco TAC Website
The Cisco TAC website provides online documents and tools for troubleshooting and resolving technical issues with Cisco products and technologies. The Cisco TAC website is available 24 hours a day, 365 days a year. The Cisco TAC website is located at this URL:
http://www.cisco.com/tac
Accessing all the tools on the Cisco TAC website requires a Cisco.com user ID and password. If you have a valid service contract but do not have a login ID or password, register at this URL:
http://tools.cisco.com/RPF/register/register.do
Opening a TAC Case
Using the online TAC Case Open Tool is the fastest way to open P3 and P4 cases. (P3 and P4 cases are those in which your network is minimally impaired or for which you require product information.) After you describe your situation, the TAC Case Open Tool automatically recommends resources for an immediate solution. If your issue is not resolved using the recommended resources, your case will be assigned to a Cisco TAC engineer. The online TAC Case Open Tool is located at this URL:
http://www.cisco.com/tac/caseopen
For P1 or P2 cases (P1 and P2 cases are those in which your production network is down or severely degraded) or if you do not have Internet access, contact Cisco TAC by telephone. Cisco TAC engineers are assigned immediately to P1 and P2 cases to help keep your business operations running smoothly.
To open a case 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 listing of Cisco TAC contacts, go to this URL:
http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml
TAC Case Priority Definitions
To ensure that all cases are reported in a standard format, Cisco has established case priority definitions.
Priority 1 (P1)—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.
Priority 2 (P2)—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.
Priority 3 (P3)—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.
Priority 4 (P4)—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. Go to this URL to visit the company store:
http://www.cisco.com/go/marketplace/
•The Cisco Product Catalog describes the networking products offered by Cisco Systems, as well as ordering and customer support services. Access the Cisco Product Catalog at this URL:
http://cisco.com/univercd/cc/td/doc/pcat/
•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 online at this URL:
http://www.ciscopress.com
•Packet magazine is the Cisco quarterly publication that provides the latest networking trends, technology breakthroughs, and Cisco products and solutions to help industry professionals get the most from their networking investment. Included are networking deployment and troubleshooting tips, configuration examples, customer case studies, tutorials and training, certification information, and links to numerous in-depth online resources. You can access Packet magazine at this URL:
http://www.cisco.com/packet
•iQ Magazine is the Cisco bimonthly publication that delivers the latest information about Internet business strategies for executives. 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
•Training—Cisco offers world-class networking training. Current offerings in network training are listed at this URL:
http://www.cisco.com/en/US/learning/index.html
CCIP, CCSP, the Cisco Arrow logo, the Cisco Powered Network mark, Cisco Unity, Follow Me Browsing, FormShare, 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 Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, LightStream, MGX, MICA, the Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, ScriptShare, SlideCast, SMARTnet, StrataView Plus, Stratm, SwitchProbe, TeleRouter, The Fastest Way to Increase Your Internet Quotient, TransPath, and VCO 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. (0401R)
Copyright © 2004, Cisco Systems, Inc.
All rights reserved.
Feedback
