Downloads |
 Feedback
|
Table Of Contents
MGCP 1.0 and Additional MGCP Packages
MGCP 1.0 Error and Return Codes
Supported Standards, MIBs, and RFCs
Provisioning the ANNOUNCEMENT Result Type
Provisioning the ToneAndAnnouncement Database Table
Exporting an Announcement File
Importing an Announcement File
Provisioning the ANNOUNCEMENT Result Type
Provisioning ATM Profiles Result Types
Provisioning Trunk Group Properties
Provisioning SigPath Properties
Adding an ATM Profile to routeAnalysis.dat
Adding ATM Profiles to the Result Table
NUMAN-ADD—announcement
NUMAN-ED—announcement
NUMAN-DLT—announcement
NUMAN-RTV—announcementMML Commands to Provision the Tone and Announcement Database Table
MML Commands to Provision the ANNOUNCEMENT Result Type
MML Commands to Provision ATM Profiles in routeAnalysis.dat
MML Commands to Provision ATM Profiles Result Types
MML Commands to Provision Trunk Group Properties
MML Commands to Provision SigPath Properties
MML Provisioning of ANNOUNCEMENT(8) Result Type
Added Gateway Announcement Capability
Action If Announcement Is Disabled
Action When Announcement Is Enabled by Trunk Group and/or Analysis Result
Times-Ten Database Announcement Table
ATM Ingress Configured Profile (Tag: 4092)
ATM Egress Configured Profile (Tag: 4093)
ATM Negotiated Profile (Tag: 4094)
Cisco Product Security Overview
Reporting Security Problems in Cisco Products
Obtaining Technical Assistance
Cisco Technical Support & Documentation Website
Definitions of Service Request Severity
Obtaining Additional Publications and Information
MGCP 1.0 and Additional MGCP Packages
Document Release History
May 17, 2004
Initial release of the document
October 26, 2005
Added bulk audit information
Feature History
9.5(2)
This feature was introduced on the PGW 2200 (MGC) in software Release 9.5(2).
The MGCP 1.0 and Additional MGCP Packages Feature is described in the following sections:
•
Supported Standards, MIBs, and RFCs
•
•
•
Feature Overview
The PGW 2200 Softswitch, also known as the Media Gateway Controller (MGC), has been enhanced to support MGCP 1.0 (IETF RFC 2705 bis 5) and additional MGCP packages, including the Announcement package, ATM package, and Bulk Audit package.
The MGCP 1.0 protocol provides better management of endpoints, especially where adverse network conditions exist. Some other enhancements supported in MGCP 1.0 are more return codes, additional restart methods and procedures, and additional capabilities, such as bulk audit support.
The PGW 2200 using MGC 1.0 can operate with the AS5300, AS5350, AS5400, AS5850s (using IOS Release 12.2(11)T, or higher), and the MGX 8000 Voice Gateway.
Benefits
Enhancement of the MGC from MGCP 0.1 to MGCP 1.0 is mainly targeted at increasing the robustness of the PGW 2200 MGC communication. It does not change the fundamental services offered within the supported solutions or applications. However, adding some of the MGCP packages makes possible more efficient service operations.
Endpoint Management
The primary driver for the MGCP 1.0 and Additional MGCP Packages feature is the additional features and functionality that is associated with the better management of endpoints during adverse network conditions.
Additional Feature Support
The secondary driver for the MGCP 1.0 and Additional MGCP Packages feature is support for new features and enhancements, including the announcement package, Bulk Call Audit, and ATM Package. For example, the added features support:
•
•
•
•
•
•
•
MGCP 1.0 Error and Return Codes
Table 1 contains the error and return codes that are added to support the MGCP 1.0 and Additional MGCP Packages feature. Table 10 lists the return codes and the corresponding internal cause code.
Restrictions
The PGW 2200 using MGC 1.0 operates with the AS5300, AS5350, AS5400, and AS5850 (using IOS Release 12.2(11)T or higher), and the MGX 8000 Voice Gateway.
You can run both MGCP 0.1 and MGCP 1.0 on the same MGC.
Related Documents
This document contains information that is related strictly to the MGCP 1.0 and Additional MGCP Packages feature. The documents that contain additional information related to the Cisco MGC are listed below:
•
•
•
•
•
•
•
•
•
•
•
Supported Platforms
The hardware platforms supported for the Cisco MGC software Release 9.5(2) are described in the Release Notes for Cisco Media Gateway Controller Software Release 9.5(2); and include the AS5300, AS5350, AS5400, AS5850s (using IOS Release 12.2(11)T, or higher), and the MGX 8000 Voice Gateway.
Supported Standards, MIBs, and RFCs
Standards
No new or modified standards are supported by this feature.MIBs
No new or modified MIBs are supported by this feature.For more information on the MIBs used in the Cisco MGC software, refer to the Cisco Media Gateway Controller Release 9 MIB Guide.RFCs
The MGCP 1.0 and Additional MGCP Packages feature supports the following RFC:•
Configuration Tasks
This section contains the steps necessary for configuration of the Cisco MGC software to support the MGCP 1.0 and Additional MGCP Packages feature. If you are installing and configuring the Cisco MGC software on your system for the first time, refer to the Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide, and return to this section once you encounter the FaultRecoveryAuditTimer parameter in the XECfgParm.dat file.
Note
Caution
Configure the FaultRecoveryAuditTimer by performing the following steps:
Step 1
Step 2
Step 3
Step 4
Troubleshooting Tips
There are two alarms (AnnTableReadingFail and AnnRespTimeout) specific to this feature. If you find that you are having trouble with your system and you suspect the MGCP 1.0 and Additional MGCP Packages feature is causing an error, verify the provisioning data for the system. If your system is incorrectly configured, fix the faulty data. If that does not solve the problem, or if your system is correctly configured, contact the Cisco TAC for assistance.
•
•
•
To change the MGCP version property to MGCP 1.0, complete the following steps:
Step 1
Note
Step 2
Step 3
Step 4
Step 5
Note
For more information on troubleshooting the rest of the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide.
Provisioning Tasks
The following sections describe the provisioning tasks related to this feature:
Planning for Provisioning
It is recommended that you gather the following information:
•
•
•
For more information on planning the provisioning for the rest of the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.
Provisioning Procedures
This section covers the following provisioning topics:
Provisioning Basics
Use the procedures in this section to start a provisioning session and save and activate the changes you have made.
•
•
•
For more detailed information about provisioning your Cisco PGW 2200, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.
Starting a Provisioning Session
You may need to start a provisioning session as part of your system operations. Start a provisioning session by logging on to the active Cisco MGC and starting an MML session using the following MML syntax:
mml> prov-sta::srcver="curr_ver",dstver="mod_ver"Where:
•
–
–
Note
Note
•
For example, to use a configuration version called ver1 as the basis for a version to be called ver2, you would enter the following command:
mml> prov-sta::srcver="ver1",dstver="ver2"Once a provisioning session is underway, use the prov-add, prov-ed, or prov-dlt MML commands to add, modify, or delete components on your system. This following sections describe how to add, modify, and delete system components. For more information on provisioning other components on your Cisco PGW 2200, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.
There are two ways to close your provisioning session: saving and activating your provisioning changes, as described in the "Saving and Activating Your Provisioning Changes" section or ending your provisioning session without saving and activating your changes, as described in the "Ending a Provisioning Session Without Activating the Changes" section.
Saving and Activating Your Provisioning Changes
When you have completed making provisioning changes in your session, you must enter an MML command to save and activate your changes. The prov-cpy and prov-dply MML provisioning commands do this.
Caution
Use the prov-cpy MML command to save and activate your changes on the active Cisco MGC. This command is typically used to save and activate changes on a Cisco MGC in a simplex configuration. However, you can use the prov-cpy MML command on Cisco MGCs in high-availability or continuous-service configurations, to save and activate your changes on the active Cisco MGC. If you choose to do this, you should enter the prov-sync MML command immediately afterwards, to have your changes saved and activated on the standby Cisco MGC.
Note
Caution
Note
Use the prov-dply MML command to save and activate your changes on the active and standby Cisco MGCs. This command is typically used to save and activate changes on Cisco MGCs in high-availability or continuous-service configurations. This command should not be used on a Cisco MGC in a simplex configuration.
Note
Ending a Provisioning Session Without Activating the Changes
If you want to end a provisioning session without saving and activating the changes you have entered, enter the prov-stp MML command. This command ends your current provisioning session and your changes are not entered.
Retrieving Provisioning Data
You can use the prov-rtrv MML command to retrieve information about your current provisioning settings. The ways you can use this command to retrieve provisioning data are described in the following sections:
•
•
•
•
•
Retrieving Data for an Individual Component
You can retrieve provisioning data on any individual component on your system. To do this, log in to the active Cisco MGC, start an MML session, and enter the following command:
prov-rtrv:component:name=MML_nameWhere:
•
•
For example, to view the provisioning data for a SS7 signaling service called ss7svc1, you would enter the following command:
prov-rtrv:ss7path:name="ss7svc1"The response to the command is dependent upon the component type associated with the desired component. For example, to view the properties for an SUA routing key called suakey1, you would enter the following command:
prov-rtrv:suakey:name="suakey1"Retrieving Data for Select Components
You can retrieve data on select components provisioned on your system by logging on to the active Cisco MGC, starting an MML session, and entering the following command:
mml> prov-rtrv:all
Note
Retrieving Data for All Components of a Particular Type
You can retrieve provisioning data on all components of a particular type on your system. To do this, log in to the active Cisco MGC, start an MML session, and enter the following command:
mml> prov-rtrv:component:"all"Where: component is the MML component type associated with the desired component group. You can find a complete list of MML component types in the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.
Note
mml> prov-rtrv:propComp:name="compName" | name="ss7famName"
Where:
propComp—MML component name appropriate to the property type you want to retrieve:
sigsvcprop—Provides maintenance access to the properties of signaling services
trnkgrpprop—Provides maintenance access to the properties of trunk groups
lnksetprop—Provides maintenance access to the properties of linksets
compName—MML name of a previously provisioned signaling service or trunk group.
ss7famName—MML name of the SS7 family associated with the desired linkset.For example, to view the provisioning data for all signaling services, enter the following MML command:
mml> prov-rtrv:ss7path:"all"Retrieving Data on the Current Provisioning Session
You can retrieve provisioning data on the current provisioning session by logging on to the active Cisco MGC, starting an MML session, and entering the following command:
mml> prov-rtrv:sessionThe system returns a response similar to the following:
MGC-02 - Media Gateway Controller 2003-01-13 13:39:19M RTRV"session=jtest:session"/*Session ID = mml1SRCVER = activeDSTVER = jtest*/Retrieving Data on Supported Signaling Protocols
You can retrieve protocol data for the current provisioning session by logging on to the active
Cisco MGC, starting an MML session, and entering the following command:mml> prov-rtrv:variantsProvisioning the ANNOUNCEMENT Result Type
Perform the following steps to provision the ANNOUNCEMENT result type as part of the MGCP 1.0 and Additional MGCP Packages feature:
Step 1
mml> prov-sta::srcver="amm_rslt",dstver="mml_01"
Note
Step 2
mml> numan-add:resulttable:custgrpId="T002",name="result10",
resulttype="ANNOUNCEMENT",dw1="1234",dw2="0",dw4="1",setname="setname1"Step 3
mml> numan-add:bdigtree:custgrpid="T002",digitstring="7034843355",
callside="originating",setname="setname1"Step 4
mml> prov-cpyStep 5
mml> numan-rtrv:resulttable:custgrpid="<cust group ID>",setname="<result set name>",name="<result name>"
or you can use:
mml> numan-rtrv:resulttable:custgrpid="<cust group ID>","all"
Provisioning the ToneAndAnnouncement Database Table
To provision the ToneAndAnnouncement database table, use the following MML commands to add, edit, delete, retrieve, or export an announcement.
Adding an Announcement
The following MML command is an example of adding an announcement:
mml> numan-add:announcement:annid=123,gwtype="AS5400",duration=60,repeat=2,interval=3, locationstring="xyz.aud"Editing an Announcement
The following MML command is an example of editing an announcement.
mml> numan-ed:announcement:annid=123,gwtype="AS5400",locationstring="welcome.aud"Deleting an Announcement
The following MML command is an example of deleting an announcement:
mml> numan-dlt:announcement:annid=123,gwtype="AS5400"Retrieving an Announcement:
The following MML command is an example of retrieving an announcement:
mml> numan-rtrv:announcement:annid=123,gwtype="AS5400"Exporting an Announcement File
You can generate a data file called announcement.dat along with the file import command by using the following MML command:
mml> prov-exp:numan:dirname="exp1"After you edit this file, you can import it into the data base by using the following MML command:
mml> prov-add:files:name="announcementfile",file="exp1/announcement.dat",action="import"Importing an Announcement File
The following MML command is an example for importing an announcement file:
mml> prov-add:files:name="announcementfile",file="exp1/announcement.dat",action="import"Provisioning the ANNOUNCEMENT Result Type
To add a remote announcement result: announceId=123, remote, RoutelistId=dulles, use the following MML command:
mml> numan-add:resulttable:custgrpId="T002",name="result59",resulttype="ANNOUNCEMENT", dw1="123",dw2="1",dw3="dulles",setname="set1"To add a local announcement result: announceId=123, local, Final_on for playing announcement, use the following MML command:
mml> numan-add:resulttable:custgrpId="T002",name="result60",resulttype="ANNOUNCEMENT", dw1="123",dw2="0",dw4="1",setname="set1"To associate a B-digit tree number to the result set, use the following MML command:
mml> numan-add:bdigtree:custgrpid="T002",digitstring="7034843375",callside="originating", setname="set1"Provisioning ATM Profiles
Profiles are used on the MGC to change the network Service Level Agreement. You can provision ATM profiles in routeAnalysis.dat by using the following MML commands to add, edit, delete, or retrieve an ATM profile:
mml> prov-add:atmprofiles:name="atmprof1",atmprofiles="ITU1;custom100"mml> prov-ed:atmprofiles:name="atmprof1",atmprofiles="ITU1;custom200"mml> prov-dlt:atmprofiles:name="atmprof1"mml> prov-rtrv:atmprofiles:name="atmprof1"mml> prov-rtrv:atmprofiles:"all"Provisioning ATM Profiles Result Types
Provision ATM profiles result types by using the following MML commands:
mml> numan-add:resulttable:custgrpId="T002",name="result59", resulttype="ATM_ORIG_PROFILE",dw1="atmprof1",dw2="1",setname="set1"mml> numan-add:resulttable:custgrpId="T002",name="result60", resulttype="ATM_TERM_PROFILE",dw1="atmprof1",dw2="1",setname="set1"Provisioning Trunk Group Properties
Provision trunk group properties by using the following MML commands:
mml> prov-add:trnkgrp:name="1000",svc="ss7svc1",type="ATM"mml> prov-ed:trnkgrpprop:name="1000",playannouncement="0"mml> prov-ed:trnkgrpprop:name="1000",GWDefaultATMProfile="profile1;profile2"mml> prov-ed:trnkgrpprop:name="1000",NetworkType="1"mml> prov-ed:trnkgrpprop:name="1000",AtmConnectionType="4"Provisioning SigPath Properties
Provision the SigPath properties by using the following MML commands:
mml> prov-add:mgcppath:name="mgcpsvc1",extnode="AS5400",desc="MGCP service"mml> prov-add:sigsvcprop:name="mgcpsvc1",GWProtocolVersion="MGCP 1.0"mml> prov-add:sigsvcprop:name="mgcpsvc1",mgcpBulkAudit="1"For more information on provisioning for the rest of the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.
XECfgParm.dat Changes
This feature adds the FaultRecoveryAuditTimer parameter to the XECfgParm.dat file. The following table describes the FaultRecoveryAuditTimer parameter.
Additional examples of configuration for the Cisco MGC software can be found in the Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide.
Command Reference
This section documents new, modified, or deleted Man-Machine Language (MML) commands. All other MML commands are documented in the Cisco Media Gateway Controller Software Release 9 MML Command Reference Guide.
New MML Commands
This section contains the MML commands that are new for the MGCP 1.0 and Additional MGCP Packages feature.
The MGC PlayAnnouncement trunk group property enables per trunk group playing of an early announcement. If the gateway associated with this trunk group can support announcements, then it is appropriate to configure this property to initiate that action.
The PlayAnnouncement property contains a value providing an announcement ID. Alternatively, if it is set to empty, Null, or 0, then the announcement function is considered to be disabled at the trunk group level.
Adding an ATM Profile to routeAnalysis.dat
ATM profile support is provided by using the following MML command:
mml> prov-add:atmprofiles:name="atmprof1",atmprofile="ITU1;custom100"The following example represents the result of the previous MML command in routeAnalysis.dat:
$ATMProfiles# CiscoMGC: 01#name ATMProfilesatmprof1 ITU1;cust100Adding ATM Profiles to the Result Table
Add result types ATM_ORIG_PROFILE and ATM_TERM_PROFILE to the T002 dial plan tpResultTree includes these two result types and handling their respective datawords.
MML command examples:
mml> numan-add:resulttable:custgrpId="T002",name="result59",resulttype="ATM_ORIG_PROFILE", dw1="atmprof1",dw2="1"mml> numan-add:resulttable:custgrpId="T002",name="result60",resulttype="ATM_TERM_PROFILE", dw1="atmprof1",dw2="1",setname="set1"The result in T002.dialplan
$resultTable# Customer: T002#type dw1 dw2 dw3 dw4 nextResult# result1 result5959 1 1NUMAN-ADD—announcement
NUMAN-ED—announcement
NUMAN-DLT—announcement
NUMAN-RTV—announcement
Modified MML Commands
This section contains the MML commands that were modified for the MGCP 1.0 and Additional MGCP Packages feature.
The existing MML command, sta-aud-gw, now allows the MGCP AUEP audit endpoint command to be used for synchronization on a specified gateway or on a specified endpoint. The endpoint is provided as a string parameter.
The MML command syntax allows the user to add an endpoint name to indicate that an MGCP AUEP is required.
The MML command sta-aud, which starts an MGC-level audit for all the configured gateways, now accepts parameters to allow gateway-level and line-level audits.
The MML command to retrieve the audit results, rtrv-aud-gw, is not changed, and no endpoint name is expected.
Note
An example of the MML output for a successful MGCP AUEP query appears as follows.
Note
mml> rtrv-aud-gw:sp1-mgcp1MGC-02 - Media Gateway Controller 2003-01-20 09:28:40.842 PSTM COMPLD"sp1-mgcp1:Audit ep received at 2003-01-20 09:28:36Audit Endpoint PASSED for s0/ds-1/1response code = 200 connection id = 32F345E2request id = FE9FEA44 notified id = 128.96.41.12requested evts = D/[0-9] detected evts =observed evts = signal requests =digit map = quarantine hdl = processreason code = bearer info = Amax datagram = package list = res,atmcapabilitiesa:PCMU, p:10-100, e:on, s:off, v:L;S,m:sendonly;recvonly;sendrecv;inactive;netwloop;netwtest";mml>sta-aud
This MML command starts an audit for all endpoints on the MGC. The audit is flow-controlled, based on the configurable timer and the number of endpoints. The stp-aud command stops the audit.
sta-aud:<mgcp sigPath>
This MML command starts an audit for endpoints on gateways associated with the specified MGCP signal path. This audit is flow-controlled and is stopped by the stp-aud command.
sta-aud:<mgcp sigPath>:ENDPOINT="a/b/c"
This MML command starts an audit for the specified endpoints ("a/b/c"). The <mgcp sigPath> specifies the gateway and "a/b/c" specifies the endpoints. A wildcard is allowed only for parameter "c" so endpoints on E1 or T1 can be audited. MML validates the wildcard limitation on the endpoint parameter.
The sta-aud-gw MML command now allows MGCP audits of the endpoints.
The syntax for the MML audit commands is listed in Table 2.
Note
The endpoint name cannot contain any * characters (wild cards). The format of the endpoint name is a/b/c.
For example:
sta-aud-gw:sp1-mgcp1:"s0/ds1-1/4"The MML command to retrieve the audit results, rtrv-aud-gw, does not change and no endpoint name is expected.
Modified Properties
The following property has been modified.
GWProtocolVersion
The GWProtocolVersion property is expanded to support the following two values:
*.GWProtocolVersion = MGCP0.1
*.GWProtocolVersion = MGCP1.0
MML Commands to Provision the Tone and Announcement Database Table
To provision the ToneAndAnnouncement database table, use the following MML commands.
To add an announcement, use the following MML command:
mml> numan-add:announcement:annid=123,gwtype="AS5400",duration="60",repeat="2", interval="3",locationstring="xyz.aud"To edit an announcement, use the following MML command:
mml> numan-ed:announcement:annid=123,gwtype="AS5400",locationstring="welcome.aud"To delete an announcement, use the following MML command:
mml> numan-dlt:announcement:annid=123,gwtype="AS5400"To retrieve an announcement, use the following MML command:
mml> numan-rtrv:announcement:annid=123,gwtype="AS5400"Use the following MML command to generate a data file called announcement.dat along with the file import command in numan.MML by the following MML command:
mml> prov-exp:numan:dirname="exp1"After editing, use the following MML command to import this file back into the database:
mml> prov-add:files:name="announcementfile",file="exp1/announcement.dat",action="import"MML Commands to Provision the ANNOUNCEMENT Result Type
To add a remote announcement result: announceId=123, remote, RoutelistId=dulles, use the following MML command:
mml> numan-add:resulttable:custgrpId="T002",name="result59",resulttype="ANNOUNCEMENT", dw1="123",dw2="1",dw3="dulles",setname="set1"To add a local announcement result: announceId=123, local, Final_on for playing announcement, use the following MML command:
mml> numan-add:resulttable:custgrpId="T002",name="result60",resulttype="ANNOUNCEMENT", dw1="123",dw2="0",dw4="1",setname="set1"To associate a B-digit number to the result set, use the following MML command:
mml> numan-add:bdigtree:custgrpid="T002",digitstring="7034843375",callside="originating", setname="set1"MML Commands to Provision ATM Profiles in routeAnalysis.dat
The following MML command examples show how you can add, edit, delete, and retrieve ATM profile support:
mml> prov-add:atmprofiles:name="atmprof1",atmprofiles="ITU1;custom100"mml> prov-ed:atmprofiles:name="atmprof1",atmprofiles="ITU1;custom200"mml> prov-dlt:atmprofiles:name="atmprof1"mml> prov-rtrv:atmprofiles:name="atmprof1"mml> prov-rtrv:atmprofiles:"all"MML Commands to Provision ATM Profiles Result Types
The following MML command examples show how you can add ATM_ORIG_PROFILE and ATM_TERM_PROFILE:
mml> numan-add:resulttable:custgrpId="T002",name="result59", resulttype="ATM_ORIG_PROFILE",dw1="atmprof1",dw2="1",setname="set1"mml> numan-add:resulttable:custgrpId="T002",name="result60", resulttype="ATM_TERM_PROFILE",dw1="atmprof1",dw2="1",setname="set1"MML Commands to Provision Trunk Group Properties
The following MML command examples show how you can add or edit trunk group properties:
mml> prov-add:trnkgrp:name="1000",svc="ss7svc1",type="ATM"mml> prov-ed:trnkgrpprop:name="1000",playannouncement="0"mml> prov-ed:trnkgrpprop:name="1000",GWDefaultATMProfile="profile1;profile2"mml> prov-ed:trnkgrpprop:name="1000",NetworkType="1"mml> prov-ed:trnkgrpprop:name="1000",AtmConnectionType="4"MML Commands to Provision SigPath Properties
The following MML command examples show how you can add sigpath properties:
mml> prov-add:mgcppath:name="mgcpsvc1",extnode="AS5400",desc="MGCP service"mml> prov-add:sigsvcprop:name="mgcpsvc1",GWProtocolVersion="MGCP1.0"mml> prov-add:sigsvcprop:name="mgcpsvc1",mgcpBulkAudit="1"MML Provisioning of ANNOUNCEMENT(8) Result Type
The following is an example of provisioning the ANNOUNCEMENT result from B-number analysis is as follows. First, configure the result in the result table, by using the following MML command:
mml> numan-add:resulttable:custgrpId="T002",name="result10", resulttype="ANNOUNCEMENT",dw1="1234",dw2="0",dw4="1",setname="setname1"Next, assign the result from a position in the B-digit tree, by using the following MML command:
mml> numan-add:bdigtree:custgrpid="T002",digitstring="7034843355", callside="originating",setname="setname1"Added Gateway Announcement Capability
The ANNOUNCEMENT result, described in Table 3, enables playing an early announcement to the MGC originating side before completing call routing. An application example might involve providing a "Welcome to the Network" message before setting up the call. This requires the associated gateway to have the capability to play announcements.
Note
Applying an announcement is provisioned on the MGC at three levels: as an incoming trunk group property, as an A-number analysis result, or as a B-number analysis result. The trunk group property (PlayAnnouncement) provides the initial announcement identity and can be optionally over-written during A-number or B-number analysis.
Upon receiving a new call, the MGC analysis function carries out Pre-analysis, A-number analysis, B-number analysis, and routing. Early in the analysis function, the incoming trunk group property PlayAnnouncement is read and any provisioned announcement identity (integer value) is retrieved. If the PlayAnnouncement trunk group property is not configured, the property has a null or zero value indicating that no announcement action is required. If an announcement identity is retrieved, this indicates that an early or welcome announcement is to be played and that this data is stored locally before starting analysis, which is where the selection of announcement can be overridden.
If an ANNOUNCEMENT result is collected at Pre-analysis, A-number analysis, or B-number analysis, it is in addition to any announcement identity collected from the trunk group property. If only the PlayAnnouncement trunk group property is present, it is applied. However, if one of the analysis areas also has provided an ANNOUNCEMENT result, then the result either overrides the trunk group property or negates the trunk group property by not applying the announcement for the incoming number. The basic rule is that the last analysis area determines the final result.
Note
If the final ANNOUNCEMENT result has dataword4 set to indicate OFF, then no announcement is played. In this case, generic analysis completely removes the ANNOUNCEMENT result and the call status is determined by the other collected results.
Once generic analysis determines which announcement Id to use, this information is passed back to number analysis to perform the necessary action. The announcement data accompanies any other results being returned. The result from analysis varies according to the announcement type and according to both the final result and the delivered announcement data.
When the RSLT_ANNOUNCEMENT analysis result arrives, the accompanying data is examined. The first check is to determine if it is a remote or local (gateway) announcement. If the announcement is remote, then the previous functionality and handling are invoked. If the indicator is set to local, then a gateway announcement is required, the Times-Ten Announcement table is read, and the data is stored in readiness.
A check is made to determine the course of action. That is, the check determines if the announcement is the final action (play announcement and clear down) or an intermediate action (play announcement and continue processing), as indicated by dataword4.
With the course of action determined, the required call processing is initiated. The MGC sends a CRCX[M: recvonly] over MGCP to the originating side gateway to prepare the channel for announcement playing. Then the MGC sends an ACM signal back to the preceding switch. This is necessary to allow time for playing the announcement, without exceeding the ACM timers, and to prepare the speech path on the previous switches.
At this point, the announcement playing is started and an Notification Request (RQNT) is sent to the gateway. Upon receiving RQNT, the gateway plays the announcement and also positively responds to the command. The MGC times the announcement playing activity and awaits a Notify (NTFY) message from the gateway. Once announcement playing is complete, the gateway responds with the NTFY message, and the completion indication is passed back to the MGC.
The action the MGC takes at this point depends on the indication given by analysis in dataword4. If the indication is ANN_final, then the call is cleared down. However, if the indication is Ann_Interim, then processing continues with the remaining results and the ANNOUNCEMENT result is discarded. If the remaining results include a trunk group, then circuit selection takes place.
The ANNOUNCEMENT result type datawords and their corresponding definitions are as follows:
AnnouncementId—Indicates the identity value corresponding to the announcement identity (or tone identity) that is played to the caller. This is one of the two access keys for which the table is searched. It is a 4-digit integer value.
Local/Remote—Indicates if the Announcement is to be played on a local gateway or routed to a remote announcement server elsewhere in the network. Values 0-Local (gateway), 1-Remote (gateway).
RouteListId—Indicates the RouteListId that is used to route to a remote announcement server. This dataword is applicable only when dataword2 is set to remote (1).
AnnData—Enables the switching off of a trunk group property Announcement for certain A-numbers or B-numbers. It also enables the applying an announcement for certain A-numbers or B-numbers if no trunk group property has been configured. Values are 0-Off, 1-Interim announcement on, or 2-Final announcement on. This dataword is applicable only when dataword2 is set to local (0).
Action If Announcement Is Disabled
You can allow an analysis ANNOUNCEMENT result to disable (switch off) an Announcement according to the A-number or the B-number. For example, the trunk group property PlayAnnouncement can be provisioned with an Announcement identity to play on all calls delivered to a specific trunk group. Then, later in A-number analysis, an ANNOUNCEMENT result is collected that switches this requirement off (dataword4 = 0). Effectively now there is no Announcement requirement, so Generic Analysis must discard the ANNOUNCEMENT result. When this occurs, there is no ANNOUNCEMENT result or Announcement data returned for further processing.
Action When Announcement Is Enabled by Trunk Group and/or Analysis Result
If an ANNOUNCEMENT result type is received with dataword2 set to 1 (indicating a remote announcement), a Route is forwarded to the remote announcement server. Announcement information is also returned containing all the dataword information that has been collected.
If an ANNOUNCEMENT result type is received with dataword2 set to 0 (indicating a local announcement), then local gateway announcement handling is required. If in the accompanying Announcement data, dataword4 (AnnData) is set to 2 (Final announcement on), this indicates that the Announcement is required and the announcement is treated as a final action (that is, play the announcement and then clear down the call).
If an ANNOUNCEMENT result type is received with dataword2 set to 0 (indicating a local announcement), then gateway announcement handling is required. If in the accompanying announcement data, dataword4 (AnnData) is set to 1 (Interim announcement on), the announcement is required and is treated as an intermediate action (meaning that other results determine the final call processing action). For example, an early announcement case could occur if the MGC initiates the playing of an announcement and then routes the call forward. In this scenario, the announcement data is returned as optional data. However, the main result is set to reflect the end of analysis result retrieved (for example, TRUNK_GROUP, ANALYSIS_PERFORMED (nailed call), or ROUTE (Cause analysis result).
Note
Times-Ten Database Announcement Table
Once it has been established that Tone or Announcement playing is required, the data must be retrieved to support the MGCP message request to the gateway. Within the MGC, the Times-Ten database holds this data in the Announcement table, which is represented in Table 4.
The Announcement table contains the following fields of data relevant to the Announcement package:
AnnId—Indicates the announcement identity (or tone identity), which matches the announcement identity defined by the ANNOUNCEMENT result type. This is one of the two access keys for which the Announcement table is searched for a match. (4-digit integer).
gwType—A string containing a value that is part of an enumerated set identifying the gateway type for this side of the call. This is the second access key used to read the Announcement table. (10 characters maximum).
playDuration—Indicates the intended duration, in seconds, for which the announcement or tone is played. The default value is 60. Value range: 0 through 120 (4-digit integer).
repeat—Indicates the number of times the announcement or tone is repeated; or indicates if it must be played continuously for the specified duration. A value of 0 indicates continuous playing. The default value is 1. Value range: 0 through 5 (4-digit integer).
interval—Indicates the silence interval duration, in milliseconds, between re-playing an announcement or tone. Default value: 3000. Value range: 0 through 5000 (4-digit integer).
locationString—A string indicating to the gateway the audio file to load to enable announcement or tone playing. The string format varies according to the gateway type and its configuration. The string information is part of a URL string that the MGC sends by MGCP to the gateway. (Maximum length of string: 128-characters).
Note
For file or ftp versions, the data provisioned in this field is the required filename, because the gateway is expected to already know the directory location or ftp address.
For example:
Audiofile1.txt (file or ftp version, gateway knows where to find the file)
MyName@host.dom/etc/Audiofile1.txt (http version, gateway will retrieve the file from this location).
Note
Obsolete Parameters
The following property is no longer used.
NotifySetupComplete
The NotifySetupComplete property is obsolete and no longer used. Since the Setup complete parameter is required in the terminating CreateConnection (CRCX), NotifySetupComplete is no longer necessary.
Reference Information
The following sections contain reference material related:
•
XECfgParm.dat Parameters
For information on the other XECfgParm.dat parameters, refer to the Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide.
Alarms
This section contains the alarms that are added to support this feature.
AnnTableReadingFail
Description This alarm is raised when reading the Times-Ten database ToneAndAnnouncement table fails.
Severity Minor
Cause This alarm can be caused by a provisioning error (for example, provisioning an invalid announcement ID), the use of the wrong database version, or any database (Times-Ten) related problem.
Type 1 (Communication error)
Action Check Provisioning. Check Times-Ten database. Verify that all components (Times-Ten database) have the right version for this package. Refer to the "Alarm Troubleshooting Procedures" section of the Troubleshooting chapter of the Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide.
AnnRespTimeout
Description This alarm is raised when the gateway does not respond to the announcement playing and a timeout occurs.
Severity Minor
Cause This alarm can be caused by a provisioning error, the use of the wrong database version, or any database (Times-Ten) related problem.
Type 1 (Communication error)
Action Check why the gateway did not play this announcement. Check the gateway configuration for the announcement. Check that the gateway has that announcement. Verify that the gateway received the announcement request correctly from the MGC. Refer to the "Alarm Troubleshooting Procedures" section of the Troubleshooting chapter of the Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide.
For information on the other alarms for the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Messages Reference Guide.
Logs
MGC logs the return codes, except 100, 200, and 250 codes, and their associated commentary. Refer to Table 1 for a list of error and return codes.
Billing Interface
This feature uses the existing Tag 4044 (Announcement Id) for both local and remote announcements. The following billing interface data is added to the MGC software.
ATM Ingress Configured Profile (Tag: 4092)
ATM Egress Configured Profile (Tag: 4093)
ATM Negotiated Profile (Tag: 4094)
The collection of the profile list information data must be carried out in two places. The level 1 trunk group property information is collected by the MGC and is stored in call context. This is for the situation where analysis does not deliver any results.
Generic analysis typically deals with the level 2 analysis results and adjusts the profile list stored in call context accordingly. However, there is a difference in handling between the originating and terminating sides with regard to the property information.
On the originating side, if the trunk group property has a profile list, the list is collected first. Subsequently, if the analysis result is mandatory, the profile list is overwritten. If the analysis result is preferred, then the result profile list is appended with the trunk group profile list to form a new list.
On the terminating side, the analysis results (if present) are written to call context first. Subsequently, once the Terminating Call Control (TCC) side is determined, the trunk group property is read. Because the analysis results have a higher priority than the trunk group property, however, if the call context variable is written to, then the trunk group profile is not read. This means there is no list-appending on the terminating side.
For correct handling of the data and Call Detail Record (CDR) collection of profile information, the following call context variables are required:
Ingress Configured Profile
Egress Configured profile
Negotiated Profile
For billing interface information for the rest of the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Billing Interface Guide.
Properties
This section indicates the properties this feature adds, modifies, or deletes in the MGC software. Refer to the Cisco MGC Software Release 9 Provisioning Guide for section setup examples for properties.
The properties in this section are used for this feature. For information on other properties for the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.
The parent objects for the properties involved in this feature are found in Table 8.
AtmConnectionType
The trunk group property AtmConnectionType populates the connection type parameter (ct:) in local connection option parameters. This property is read for both originating and terminating legs of all ATM-switched calls.
Applying MGC influence, that is, bias, in the profile negotiation process is hierarchical and is applied through using the GWDefaultATMProfile property at the trunk group level, and then by analysis results in A-number or B-number analysis.
Note
Valid values: 1 (AAL1), 2 (AAL1_SDT), 3 (AAL1_UDT), 4 (AAL2), 5 (AAL 3/4), 6 (AAL5)
Default value: 4 (AAL2)
Profile Negotiation Levels
This implementation provides the following structure with regard to ATM profile negotiation when the MGC is involved.
Level 0
At level 0, nothing is defined on the MGC. That is, no trunk group properties and no analysis results are defined. This means that the decision for the profile used for the call is made at the gateway level. However, the MGC, using MGCP messages, negotiates between ingress and egress gateway. This is the only role of the MGC at this level.
Level 1
At level 1, the MGC can influence the profile negotiation by the trunk group property GWDefaultATMProfile configuration on the originating side and even on the terminating side.
With GWDefaultATMProfile configured on the originating side, the MGC offers to the originating gateway the profile list extracted from this property within the CreateConnection (CRCX) request. The originating gateway then matches this received list with its own ActiveProfileList to produce a new list composed of the matched profiles. This list is returned by the gateway to the MGC in the SDP information returned in the CRCX Acknowledgement.
If the terminating side trunk group has this property configured, the retrieved profile list is sent along with the SDP profile list (received previously from the originating side) to the terminating-side gateway.
If no terminating trunk group property is configured, then only the originating-side SDP information is sent.
Note
The MGC passes the originating SDP and any retrieved terminating profile list to the terminating-side gateway in another CRCX message. The egress gateway then matches the received list with its own ActiveProfileList to develop a final list. The egress gateway then chooses from this resultant final profile list, which is transported back to the MGC in the CRCX Acknowledgement message.
Finally, the MGC passes this profile choice to the originating gateway in an MDCX message. Once this exchange has been carried out, only one profile exists for both the ingress and egress gateways, which is the result of profile negotiation (influenced by the MGC applying a bias for the SLA between those gateways).
Level 2
At level 2, the MGC can apply another layer of SLA bias to profile negotiation. This additional layer provides the capability of provisioning ATM_ORIG_PROFILE and ATM_TERM_PROFILE results within the MGC A-number and B-number analysis functions. These results contain the same data words and both results deliver a profile list to bias negotiation on either the ingress or egress gateway.
Dataword2 in the result type provides a mandatory or preferred indication for the profile list, which determines the actions that must take place. If dataword2 is set to mandatory, then the profile list from the previous stages is ignored and the egress gateway supports a profile from the list identified by dataword1. If dataword2 is set to preferred, then the profile list identified by dataword1 is retrieved and the existing list (from previous stages, if collected) is appended to the profile list, thus forming a new list to forward to the gateway.
Note
GWDefaultATMProfile
When the MGC is acting as a Call Agent making ATM voice connections between two gateways, it must provide the capability to influence the profile negotiation between the two sides to the gateway.
To accomplish this profile negotiation, a list of profiles supported by the code image on the gateway, but is refined by configuration according to the prevailing network Service Level Agreement (SLA). The MGC applies the SLA changes or refinements to the profile list rather than apply them as configuration changes on the gateways. Thus, the gateways contain a list of profiles that their respective code images can support. The MGC retrieves a provisioned profile list from the GWDefaultATMProfile trunk group property or as the ATM_ORIG_PROFILE or ATM_TERM_PROFILE result delivered from A-number (Calling number) or B-number (Called number) analysis. This list is then passed over MGCP to the gateway to bias profile negotiation.
While establishing the connection between two gateways, the originating gateway profile list is refined by ANDing with a new profile sent from the MGC in the originating side CRCX message. The resultant profile list is passed in the Session Description Protocol (SDP) to the terminating gateway. Also, the MGC can optionally produce another profile choice to bias the profile on the terminating gateway according to the SLA. This profile accompanies other data sent in the CRCX message to the terminating gateway. Upon receiving this profile, the terminating gateway ANDs the SDP profile with any existing received profiles and then ANDs the profile list with the existing gateway ActiveProfileList to produce a resultant profile list. From the resultant profile list, the gateway chooses a profile entry and passes back the profile list to the originating side.
The MGC produces a profile choice list (ProfileList1) that is sent to the originating gateway in the first CRCX command. The originating gateway forms a new list by ANDing the received profile with its own ActiveProfileList and generates ProfileList2, which consists only of the profile choices that were present in both lists. This profile information is embedded in the SDP that is sent back to the MGC in the CRCX Acknowledgement.
If the MGC also has an SLA profile for the terminating gateway (ProfileList3), it is added to the profile list in the SDP and both profiles are sent to the terminating gateway in another CRCX message. Upon receiving this profile, the terminating gateway ANDs all three lists to produce a single profile list that is refined by the SLA conditions from both sides. The terminating gateway makes a choice from the final profile list that is then sent to the MGC in the CRCX Acknowledgement message and the profile is then sent to the originating gateway in an MDCX message.
Once this process has been carried out, a single profile exists for both the originating and terminating gateway, which is the result of profile negotiation between the two gateways by the MGC and application of the prevailing SLAs.
The trunk group property GWDefaultATMProfile provides, on a per trunk group basis, an initial list of profiles for use in ATM gateway profile negotiation. This property contains a list of profile choices separated by semi-colons, that influences ATM gateway profile negotiation. If GWDefaultATMProfile is set to NULL (default), then there is no profile list negotiation bias applied from the trunk group level.
Valid values: NULL, <Profile1>;<Profile2>;<ProfileN>
Default value: NULL
Note
mgcpBulkAudit
The mgcpBulkAudit SigPath property determines if bulk audit is supported. The mgcpBulkAudit SigPath property contains either an integer (1) indicating that bulk audit is supported on that gateway, or contains a Null (0) indicating that bulk audit is not supported on that gateway.
Valid values: 1 or 0
Default value: 0
NetworkType
The trunk group property NetworkType populates the network type parameter (nt:) in local connection parameters. This property is read for both originating and terminating legs of all calls. Based on this property, the MGC software determines if the underlying network is ATM or IP. Based on the network type retrieved, various network-specific parameters (for example, for ATM networks, profiles are sent down) are sent down to gateways.
Valid values: 0 (IP), 1 (ATM), 2 (IN)
Default value: 0 (IP)
PlayAnnouncement
The trunk group property PlayAnnouncement enables, on a per trunk group basis, playing an early announcement. This property can either contain an Integer Announcement Identity, or, if it is set to 0 (default), the announcement function is considered disabled at the trunk group level.
Valid values: any integer value greater than 0.
Default value: 0
For information on other properties for the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.
Result Type Definitions
Result analysis provides the capability to group actions into result sets that can be attached at different points of analysis. The main attachment points are: Pre-analysis, A-number analysis, B-number analysis, and Cause analysis.
The following result type definitions are added, modified, or deleted for this feature.
Analysis result types ATM_ORIG_PROFILE (59) and ATM_TERM_PROFILE (60) have been added to deliver an ATM AAL2 profile choice for either A-number or B-number analysis. The profile information is passed from the MGC to the gateway for use in profile negotiations. Additionally, the ANNOUNCEMENT (8) result type has been modified by the addition of dataword4 and has become an intermediate analysis point.
ATM_ORIG_PROFILE/ ATM_TERM_PROFILE
Dataword1—AtmProfIdx provides an index value that is used to read the ATM Profiles table from the routeAnalysis.dat file. This enables retrieving a list of ATM profiles for use in the profile negotiation process.
Dataword2—Action provides an indication as to whether this profile list is to be considered preferred or mandatory. Values are: 0 (mandatory) or 1 (preferred).
Possible profile entries are:
•
•
•
•
•
•
•
•
•
•
MML provisioning for analysis results ATM_ORIG_PROFILE and ATM_TERM_PROFILE can be performed for either the A-numbers or the B-numbers.
Supporting routeAnalysis.dat table ATMProfiles
To support the ATM result types, ATM_ORIG_PROFILE and ATM_TERM_PROFILE, a table is used to provide the list of ATM profiles. The profile list is assigned a name during provisioning, and a semicolon-separated list of profile choices is entered against this name.
The format of the routeAnalysis table is as follows:
$ATMProfiles# CiscoMGC: 01#name ATMProfilesatmprof1 ITU1;cust100Data words
Dataword1—AnnouncementId. This integer represents the announcement identity. This value interrogates the tone and announcement table and retrieves the data for the MGCP message.
Dataword2—Local/Remote. Indicates if the announcement is locally supported (that is, on an MGC-controlled gateway) or remotely supported (that is, routed forward to an announcement server).
Dataword3—RouteListId. This integer is required only for routing to a remote announcement server and is not applicable when gateway announcements are used.
Dataword4—AnnData. This integer indicates if the announcement is applied or not and indicates if the announcement signals the end of a call or continued processing. Valid values: 0 or NULL=OFF, 1=INTERIM_ON, or 2=FINAL_ON.
Note
For information on other result type definitions for the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.
The ANNOUNCEMENT result type has been modified to become an Intermediate result type. This result type is now available to the Pre-analysis and A-number analysis areas, in addition to Cause and B-number analysis.
ANNOUNCEMENT
The ANNOUNCEMENT result type within generic analysis has been modified by introduction of the processing of Dataword4, which indicates if an announcement is to be applied. This modification provides the ability to override a trunk group property setting according to this analysis result.
AnnouncementId—Identification value corresponding to the announcement that is played to the caller (INTEGER value).
Local/Remote—Indicates if the announcement is to be played on a local gateway or routed out to a remote announcement server elsewhere in the network. Values: 0 = Local (gateway) or 1 = Remote (gateway).
RouteListId—Indicates the RouteListId that is used to start routing analysis to route to a remote announcement server (INTEGER value).
AnnData—Enables or disables the announcement trunk group property for certain A-numbers and B-numbers or applies an announcement for certain A-numbers and B-numbers where no trunk group property has been configured. Values: 0 = Off, 1 = Interim Announcement On, or 2 = Final Announcement On.
Cause and Location Codes
The MGCP 1.0 and Additional MGCP Packages feature supports the cause codes listed in Table 10 in the MGC software. RETURN codes listed in the first column of Table 10 are mapped to internal cause values. The values listed in Table 10 are for reference purposes only.
For information on other cause and location codes for the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.
Bulk Audit
The Cisco MGC supports the MGCP Bulk Audit Package, as defined in the IETF RFC 3624 (which is a subset of the specification implemented to support basic bulk audit). The MGCP Bulk Audit Package is used by the Call Agent to determine the connection and endpoint state for a group of endpoints on the gateway.
Bulk audit is more resource efficient than a regular audit on a single endpoint. For a single endpoint audit, the Call Agent has to send an audit message for each endpoint. However, for bulk audit, the Call agent has to send only one bulk audit message for a group of endpoints. Bulk audit significantly reduces the number of messages exchanged between the Call Agent and the gateway during the audit.
The bulk audit support is implemented in the MGC. The MGC uses the following parameters to determine the connection and endpoint state: BA/C, BA/S(I), BA/SE and BA/NU.
Bulk audit messages are used to exchange information between the MGC and the gateway. The bulk audit (BA) message parameters are:
•
•
•
•
•
•
•
•
•
•
The gateway property mgcpBulkAudit is defined to enable the bulk audit for a specified gateway. The property can be set 0 (disabled bulk audit for single endpoint audits to take place) or 1(enable bulk audit). The default value is set to 0.
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/techsupport
You can access the Cisco website at this URL:
You can access international Cisco websites at this URL:
http://www.cisco.com/public/countries_languages.shtml
Product Documentation DVD
Cisco documentation and additional literature are available in the Product Documentation DVD package, which may have shipped with your product. The Product Documentation DVD is updated regularly and may be more current than printed documentation.
The Product Documentation DVD is a comprehensive library of technical product documentation on portable media. The DVD enables you to access multiple versions of hardware and software installation, configuration, and command guides for Cisco products and to view technical documentation in HTML. With the DVD, you have access to the same documentation that is found on the Cisco website without being connected to the Internet. Certain products also have .pdf versions of the documentation available.
The Product Documentation DVD is available as a single unit or as a subscription. Registered Cisco.com users (Cisco direct customers) can order a Product Documentation DVD (product number DOC-DOCDVD=) from Cisco Marketplace at this URL:
http://www.cisco.com/go/marketplace/
Ordering Documentation
Beginning June 30, 2005, registered Cisco.com users may order Cisco documentation at the Product Documentation Store in the Cisco Marketplace at this URL:
http://www.cisco.com/go/marketplace/
Nonregistered Cisco.com users can order technical documentation from 8:00 a.m. to 5:00 p.m. (0800 to 1700) PDT by calling 1 866 463-3487 in the United States and Canada, or elsewhere by calling 011 408 519-5055. You can also order documentation by e-mail at tech-doc-store-mkpl@external.cisco.com or by fax at 1 408 519-5001 in the United States and Canada, or elsewhere at 011 408 519-5001.
Documentation Feedback
You can rate and provide feedback about Cisco technical documents by completing the online feedback form that appears with the technical documents on Cisco.com.
You can send comments about Cisco 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-9883We 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:
•
•
•
A current list of security advisories and notices for Cisco products is available at this URL:
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:
•
An emergency is either a condition in which a system is under active attack or a condition for which a severe and urgent security vulnerability should be reported. All other conditions are considered nonemergencies.
•
In an emergency, you can also reach PSIRT by telephone:
•
•
Tip
Never use a revoked or an expired encryption key. The correct public key to use in your correspondence with PSIRT is the one linked in the Contact Summary section of the Security Vulnerability Policy page at this URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
The link on this page has the current PGP key ID in use.
Obtaining Technical Assistance
Cisco Technical Support provides 24-hour-a-day award-winning technical assistance. The Cisco Technical Support & Documentation website on Cisco.com features extensive online support resources. In addition, if you have a valid Cisco service contract, Cisco Technical Assistance Center (TAC) engineers provide telephone support. If you do not have a valid Cisco service contract, contact your reseller.
Cisco Technical Support & Documentation Website
The Cisco Technical Support & Documentation 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, at this URL:
http://www.cisco.com/techsupport
Access to all tools on the Cisco Technical Support & Documentation 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
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 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 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-2447For 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.
•
http://www.cisco.com/go/marketplace/
•
•
•
http://www.cisco.com/go/iqmagazine
or view the digital edition at this URL:
http://ciscoiq.texterity.com/ciscoiq/sample/
•
•
http://www.cisco.com/en/US/products/index.html
•
http://www.cisco.com/discuss/networking
•
http://www.cisco.com/en/US/learning/index.html
Glossary
Table 11 contains definitions of acronyms and technical terms used in this document.
