Guest

Cisco MGX 8880 Media Gateways

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

  • Viewing Options

  • PDF (348.6 KB)
  • Feedback
Release Notes for Cisco Voice Switch Service Module (VXSM) Release 5.0.20

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
=============================================================
                 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.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