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.

Table 1 MGCP Return Codes and Descriptions

1.0
Return Code

0.1
Return Code

Description

000

NA

Response acknowledgement.

100

NA

Transaction is being executed. Completion response will follow.

101

NA

Transaction has been queued.

200

200

Transaction was executed normally.

250

250

Connection was already deleted.

400

400

Transaction not executed, transient error.

401

401

Phone is already off hook.

402

402

Phone is already on-hook.

403

400

Endpoint does not have sufficient resources.

404

400

Insufficient Bandwidth.

405

400

Endpoint is restarting.

406

400

Transaction timeout.

407

400

Transaction aborted.

409

400

Internal overload.

410

400

Endpoint not available.

500

500

Endpoint unknown.

501

501

Endpoint is not ready.

502

502

Endpoint does not have sufficient resources.

503

502

All of wildcard is too complicated.

504

510

Unknown or unsupported command.

505

510

Unknown remote connection descriptor.

506

510

Unable to satisfy both local connection option and remote connection descriptor.

507

510

Unsupported functionality.

508

510

Unknown quarantine handling.

509

510

SDP Error.

510

510

Protocol error.

511

511

Unrecognized extension.

512

512

Gateway not equipped to detect events.

513

513

Gateway not equipped to generate signal.

514

514

Transaction could not be executed because the gateway cannot send the specified announcement.

515

515

Invalid connection ID.

516

516

Unknown Call ID.

517

517

Unsupported/Invalid mode.

518

518

Unsupported/Invalid package.

519

519

Endpoint does not have a digit map.

520

520

Endpoint restarting.

521

NA

Endpoint redirected to another call agent.

522

510

No such signal or event.

523

510

Unknown action or illegal combination of actions.

524

510

Internal inconsistency in LocalConnectionOptions (LCO).

525

510

Unknown extension in LCO.

526

502

Insufficient bandwidth.

527

510

Missing RemoteConnectionDescriptor.

528

510

Incompatible protocol version.

529

501

Hardware failure.

530

501

CAS signaling protocol error.

531

501

Failure of a grouping of trunks (facility error).

532

510

Unsupported values in LCO.

533

502

Insufficient bandwidth. Response too large.

534

502

Codec negotiation failure.

535

510

Packetization period not supported.

536

510

Unsupported RestartMethod.

537

510

Unknown or unsupported digit map extension, since the gateway does not have the digit map.

538

512 or 513

Event/Signal parameter error.

540

515

Per endpoint connection limit was exceeded.

596

596

VISM-specific return code indicating VCC failure or VCC could not be set up.

598

598

Media connection failure.

599

599

VISM-specific return code indicating media connection loss.

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:

•MGCP 1.0 [RFC 2705 bis 5] Compliance

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 You configure the FaultRecoveryAuditTimer parameter only for the time interval between background audit procedures.

Caution Configuration of the Cisco MGC software requires that the system software be shut down. In a simplex system, calls cannot be processed during system shutdown. In a continuous service system, your system loses the ability to maintain calls during a critical event while the system software on one of the MGC hosts is shut down.

Configure the FaultRecoveryAuditTimer by performing the following steps:

Step 1 If you have not already done so, open the /opt/CiscoMGC/etc/XECfgParm.dat file on the active and standby Cisco MGC hosts using a text editor, such as vi.

Step 2 If you have not already done so, set the pom.dataSync parameter to false on the active and standby Cisco MGC hosts.

Step 3 Search for the FaultRecoveryAuditTimer parameter and enter the desired time interval on the active and standby Cisco MGC hosts.

Step 4 Save your changes and close the text editor.

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.

•When migrating from an earlier version of software to MGC software Release 9.5(2), the GWProtocolVersion value is MGCP0.1.

•If provisioning from "new" using MGC software Release 9.5(2), be aware that the default value for GWProtocolVersion is MGCP1.0.

•When connecting to gateways, be sure the MGCP version on all the platforms is the same. Set the GWProtocolVersion property value at the SigPath level by performing the following procedure.

To change the MGCP version property to MGCP 1.0, complete the following steps:

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:

•curr_ver—The name of the current configuration version. In place of the name of the current configuration version, you can also enter:

–active—Selects the active configuration as the source for configuration changes.

Note You can use "new" as the source configuration only when there is no existing, active set of provisioning data in the configuration library. Therefore, "new" cannot be used as the source configuration once a provisioning session has been saved and activated by using prov-cpy or prov-dply. Once you have saved and activated a set of data, you must use either "active" or the name of the set of provisioning data as the source configuration.

•mod_ver—A new configuration version name that contains your provisioning changes.

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.

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 Depending on the extent of your provisioning changes, using the prov-cpy and prov-dply MML commands can severely impact your system call processing performance. We recommend that these commands be issued during a maintenance window when traffic is minimal.

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 When you enter the prov-cpy command, your provisioning session is also automatically ended. If you want to make additional provisioning changes, you must start a new provisioning session, as described in the "Starting a Provisioning Session" section.

Caution Using the prov-sync MML command can severely impact your system call processing performance. We recommend that this command be issued during a maintenance window when traffic is minimal.

Note When the prov-sync MML command is used to synchronize the provisioning settings on the standby MGC host with current settings on the active MGC host, the system does not indicate when the synchronization process has failed.

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 When you enter the prov-dply command, your provisioning session is also automatically ended, unless an error occurs during execution. If you want to make additional provisioning changes, you must start a new provisioning session, as described in the "Starting a Provisioning Session" section.

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:

•MML_name—The MML name for the desired component. You can determine the MML names for the various components using the prov-rtrv:all MML command.

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 This command returns data on all signaling components, except for signaling service and linkset properties.

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:

Note You cannot use this command with components that are used to retrieve signaling or routing properties (that is sigsvcprop, lnksetprop, and trnkgrpprop). The properties for only one signaling or routing component can be listed per command instance. Please use the following MML format:

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:session

The system returns a response similar to the following:

MGC-02 - Media Gateway Controller 2003-01-13 13:39:19

M RTRV

"session=jtest:session"

/*

Session ID = mml1

SRCVER = active

DSTVER = 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:variants

Provisioning 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 Open a provisioning session on the active MGC by using the following MML command:mml> prov-sta::srcver="amm_rslt",dstver="mml_01"

Note You can use "new" as the source configuration only when there is no existing, active set of provisioning data in the configuration library. Therefore, "new" cannot be used as the source configuration once a provisioning session has been saved and activated by using prov-cpy or prov-dply. Once you have saved and activated a set of data, you must use either "active" or the name of the set of provisioning data as the source configuration.

Step 2 Add the ANNOUNCEMENT result to 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"

Step 3 Then, 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"

Step 4 Commit the changes by using the following MML command:mml> prov-cpy

Step 5 Use the following MML command to verify the Result table was correctly added: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.

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:

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.

Configuration Parameter

Definition

FaultRecoveryAuditTimer

The FaultRecoveryAuditTimer parameter configures the time interval between consecutive background audit procedures. The FaultRecoveryAuditTimer parameter contains an integer, representing the number of milliseconds between consecutive background audit procedures.

Valid values: any integer value

Default value: 15000

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.

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 ATMProfiles

atmprof1 ITU1;cust100

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

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. (It is a 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. The default value is 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 128-character string.)

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 Only one audit of any kind (AUEP) can be outstanding at any one time per gateway.

An example of the MML output for a successful MGCP AUEP query appears as follows.

Note The exact format may not be identical to the following.

mml> rtrv-aud-gw:sp1-mgcp1

MGC-02 - Media Gateway Controller 2003-01-20 09:28:40.842 PST

M COMPLD

"sp1-mgcp1:Audit ep received at 2003-01-20 09:28:36

Audit Endpoint PASSED for s0/ds-1/1

response code = 200 connection id = 32F345E2

request id = FE9FEA44 notified id = 128.96.41.12

requested evts = D/[0-9] detected evts =

observed evts = signal requests =

digit map = quarantine hdl = process

reason code = bearer info = A

max datagram = package list = res,atm

capabilities

a: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.

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 Due to the nature of the connection, calls arriving by EISUP (H.323) or SIP protocols are not supported.

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 in overlap numbering mode, all digits must be received and analyzed before any announcement is played. This means that any overlap announcement call effectively goes from overlap to enbloc.

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.

Table 3 Result Type Definitions

Result Number.

Result Type

Dataword1

Dataword2

Dataword3

Dataword4

Analysis Points

Result Type Valid For

Intermediate

End Point

A-digit analysis

B-digit analysis

Cause

Pre-analysis

8

ANNOUNCEMENT

AnnouncementId

Local/Remote

RouteListId

AnnData

X

X

X

X

X

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 When dealing with these results, first determine if there is announcement data and take the appropriate action.

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.

Table 4 Announcement Table Representation

AnnId

gwType

play
Duration

Repeat

Interval

locationString

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

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 The gateway is expected to support standard URL schemes for this notation (that is, file, http, or ftp), as described in RFC 1738.

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 Gateways do not support playDuration, repeat, and interval parameters at this time.

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

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)

Table 5 ATM Ingress Configured Profile Description Form

Name: ATM Ingress Configured Profile

Tag: 4092

Source: MDL

Description/Purpose: Indicates if an ATM profile was configured, based on the Service Level Agreement (SLA) for the ingress call leg.

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:

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.

Table 8 Software Properties Related to this Feature

Property Name

Parent Object

AVM

DPNSS

EISUP

IOCC

ISDNPRI

MGCP

RLM

SESSION

SGCP

SS7-ANSI

SS7-China

SS7-ITU

SS7-Japan

SS7-UK

TALI-IOCC

TCAPOverIP

TrunkGroup

VSI

AtmConnectionType

X

GWDefaultATMProfile

X

mgcpBulkAudit

X

NetworkType

X

PlayAnnouncement

X

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.

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 With regard to the terminating side, the trunk group property profile list is read only in the absence of any level 2 results from A-number or B-number analysis.

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 If results are collected from A-number analysis and then from B-number analysis, B-number analysis can further adjust or overwrite the existing profile list created by the A-number analysis. This provides the possibility for there being two sublevels within the level 2 capability.

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 This property is added in propSet.xml.dat for provisioning, added in properties.mod for migration, and added in tpTrunkgroup for importing and exporting.

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.

Table 9 Result Type Definitions

Result Number.

Result Type

Dataword1

Dataword2

Dataword3

Dataword4

Analysis Points

Result Type Valid For

Intermediate

End Point

A-digit analysis

B-digit analysis

Cause

Pre-analysis

59

ATM_ORIG_PROFILE

AtmProfIdx

Action

0 (not used)

0 (not used)

X

X

X

60

ATM_TERM_PROFILE

AtmProfIdx

Action

0 (not used)

0 (not used)

X

X

X

8

ANNOUNCEMENT

Announcement ID

Local/Remote

RouteListId

AnnData

X

X

X

X

X

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:

•ITU1

•ITU2

•ITU3

•ITU7

•ITU8

•ITU12

•Custom100

•Custom101

•Custom110

•Custom200

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 ATMProfiles

atmprof1 ITU1;cust100

Data 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 Dataword4 (AnnData) indicates if the requirement is to play an announcement and then clear down (FINAL_ON) or play an announcement and then continue processing (INTERIM_ON).

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.

Transient Error—It is used to respond to commands when the requested command cannot be processed at the current time; however, the expectation is that if the same command is requested in the very near future, it may succeed.

32

IC_NORMAL_UNSPECIFIED

401

Phone_Already_Off_Hook_401

The Phone is already off hook—It is returned to respond to an off-hook transition request while the phone is already off-hook. It is also returned when a request is made to generate a signal that is inappropriate for a phone that is off-hook. For example, S: l/rg, which is a request to ring the phone.

52

IC_USER_BUSY

402

Phone is already on-hook—It is returned to respond to an on-hook (or hook-flash) transition request (RQNT) while the phone is already on-hook.

It is also returned when a request is made to generate a signal that is inappropriate for a phone that is on-hook. For example, S: l/dl, which is a request to play a tone, such as dial-tone.

52

IC_USER_BUSY

403

Trans_Not_Executed_End_Pt_Insuff_Res_403

Endpoint does not have sufficient resources —It is returned if the request cannot be processed due to unavailability of pooled resources, such as CPU utilization, lack of DSP resources, lack of memory, and so on. However, the command may succeed at a later time when resources free up.

44

IC_RESOURCES_UNAVAIL_UNSPEC

404

Trans_Not_Executed_End_Pt_Insuff_Bandwidth_404

Insufficient Bandwidth—It is returned to requests when the gateway does not have enough bandwidth to establish the connection. As an example, the gateway shall use this error code to indicate the presence of RSVP failures.

44

IC_RESOURCES_UNAVAIL_UNSPEC

405

Trans_Not_Executed_Endpoint_Restarting_405

Endpoint is restarting—It is returned to requests when the gateway has initiated the Restart Procedures (RSIP) on an endpoint.

77

IC_SERVICE_TEMPORARILY_UNAVAILABLE

406

Trans_timed_out_406

Transaction Timeout —It is returned following a 100 code, if the request did not complete in a reasonable period of time and has been aborted.

14

IC_FACILITY_REJECTED

407

Trans_aborted_407

Transaction Aborted—It is returned to cancel a pending request. For example, DLCX is received during the processing of a CRCX or MDCX, or the same command is received with another transaction ID.

14

IC_FACILITY_REJECTED

500

Trans_Not_Executed_End_Pt_Unknown_500

Endpoint is unknown—It is returned if the endpoint ID supplied in the request is unknown.

33

IC_NO_ROUTE_TO_DEST

501

Trans_Not_Executed_End_Pt_Not_Ready_501

Endpoint is not ready—It is returned if the endpoint is in a permanent not ready state. This includes maintenance states, such as out of service and auto out of service.

59

IC_DTE_CONTROLLED_NOT_READY

502

Trans_Not_Executed_End_Pt_Insuff_Res_502

Endpoint does not have sufficient resources—It is returned when the endpoint does not have sufficient resources and future requests on this endpoint are guaranteed to fail. It indicates that the resources dedicated to the endpoint are broken.

44

IC_RESOURCES_UNAVAIL_UNSPEC

503

WildCardsTooComplicated_503

All of wildcard too complicated—It is returned when the wildcard convention used in the request is understood, but the requested command cannot be processed with wildcarding. An example of this would be an RQNT with a request such that a failure would make it too difficult to roll back the state of all the endpoints to what they were prior to the request.

MDL does not map this return code to an internal cause value. The MGC internally handles this return code.

509

SdpError_509

SDP error—It is returned if the SDP has parameters or attributes that are not recognized or parameters that are recognized but not consistent with the state of the connection. The gateway should ignore attributes that it does not recognize. Also as indicated in the MGCP specification, gateways should generate o, t, and s lines but be lenient if they do not receive them.

23

IC_MSG_IN_WRONG_STATE

510

Trans_Not_Executed_Protocol_Error_510

Protocol Error—It is returned if the requested command is not in compliance with the MGCP specification. Because this is a least specific error code, it is especially important that gateways provide supporting commentary text to reflect the nature of the error.

38

IC_PROTOCOL_ERROR_UNSPEC

511

Trans_Not_Executed_Unreognised_Ext_511

Unrecognized extension—It is returned if the requested command contains an unrecognized X+ extension. In MGCP 1.0, this specifically refers to unrecognized parameters, because other error codes are available for unrecognized connection modes (517), unrecognized packages (518), unrecognized LCO(541), and so on.

38

IC_PROTOCOL_ERROR_UNSPEC

512

Gateway_Unequipped_To_Detect_Request_512

GW not equipped to detect event—It is returned if the gateway is not equipped to detect one or more of the requested events.

14

IC_FACILITY_REJECTED

513

Gateway_Unequipped_To_Generate_Signal_513

GW not equipped to generate signal—It is returned if the gateway is not equipped to generate one or more of the requested signals.

14

IC_FACILITY_REJECTED

514

Gateway_Cannot_Send_Announcement_514

The gateway is not able to send an announcement.

8

IC_CALL_REJECTED

515

Incorrect_Connection_ID_515

Invalid Connection ID—It is returned if the connection ID supplied in the request refers to an unknown Connection ID. The connection ID can also supplied with events and signals (for example, S: L/rt@connId) or in the SDP.

17

IC_INVALID_CALL_REFERENCE_VALUE

516

Unknown_Call_ID _516

Unknown/Invalid Call ID—It is returned if the call ID supplied in the request refers to an unknown Call ID.

17

IC_INVALID_CALL_REFERENCE_VALUE

517

Unsupported_Mode_517

Unsupported/Invalid mode—It is returned if the command specifies a connection mode that the endpoint does not support.

78

IC_SERVICE_UNAVAILABLE

518

Unsupported_Package_518

Unsupported/Invalid package—It is returned if the command specifies an unsupported or invalid package.

95

IC_CALL_TYPE_INCOMPATIBLE

519

Gateway_Does_Not_Have_Digit_Map_519

Endpoint does not have a digit map—It is returned if the request is to accumulate digits according to the digit map and the endpoint does not have a digit map.

42

IC_REQ_FACILITY_NOT_IMP

520

Trans_Not_Executed_End_Pt_Restarting_520

Endpoint restarting—This code may be deprecated. Future implementation should use 405, instead.

77

IC_SERVICE_TEMPORARILY_UNAVAILABLE

521

Endpoint is redirected to another call agent.

N/A

NOTE: The gateway does not send this return code to the MGC. Also the MGC will not generate this return code at this time.

522

NoSuch_Signal_Event _522

No such signal or event—It is returned if the requested event or signal name is not registered with this package.

46

IC_SERVICE_OR_OPTION_NOT_IMP_UNSPEC

523

IllegalCombination_Of_Actions_523

Unknown action or illegal combination of actions—It is returned if the request contains an invalid or an unsupported action or an illegal combination of actions.

47

IC_SERVICE_OR_OPTION_NOT_AVAIL

524

InConsistency_LCO_524

Internal inconsistency in LocalConnectionOptions (LCO)—It is returned if one or more of LCO parameters are coded with values that are not consistent with each other or with the network type.

38

IC_PROTOCOL_ERROR_UNSPEC

525

UnknownExt_LCO_525

Unknown extension in LCO—It is returned if the request contains one or more unrecognized X+ extensions.

Missing RemoteConnectionDescriptor—It is returned if the requests do not contain the RemoteConnectionDescriptor when one is required to support the requested connection mode or a signal to be applied on the connection.

14

IC_FACILITY_REJECTED

528

InCompatible_Protocol_Version_528

Incompatible protocol version—It is returned if the protocol version does not match the protocol version(s) it was configured to support.

105

IC_REMOTE_PROC_ERROR

529

HardWare_Failure_529

Hardware Failure—It is returned if an endpoint experiences a hardware fault during the execution of a command.

Note If the hardware fault forces an endpoint to go out of service, an Restart In Progress (RSIP) is sent. Any command rejected due to an endpoint being out-of-service generates error code 501.

26

IC_NETWORK_OUT_OF_ORDER

530

Cas_Signaling_Protocol_Error_530

CAS signaling protocol error.

105

IC_REMOTE_PROC_ERROR

531

FailureOf_Grouping_Trunks_531

Failure of a grouping of trunks (facility failure)—It is returned if an endpoint being grouped becomes unavailable during the execution of a command due to a facility (for example, T1) failure.

Note If the facility failure forces an endpoint to go out of service, an RSIP is sent. Any command rejected due to an endpoint being out-of-service generates error code 501.

14

IC_FACILITY_REJECTED

532

UnsupportedValues_In_LCO_532

Unsupported values in LocalConnectionOptions—It is returned if one or more of the LCO parameters is coded with an unsupported value and the gateway does not have the authority to override the parameter value that is in error.

38

IC_PROTOCOL_ERROR_UNSPEC

533

Response_Too_Large_533

Response too large—This is likely to occur only in the case of an audit where the maximum response packet size is too large.

14

IC_FACILITY_REJECTED

534

Codec_Negotiation_Failure_534

Codec Negotiation failure—It is returned if the negotiated list of codecs is empty.

14

IC_FACILITY_REJECTED

535

PacketizationPeriod_Not_Supported_535

Packetization Period not supported—It is returned if the LCO contains an unsupported packetization period with no codec specified.

47

IC_SERVICE_OR_OPTION_NOT_AVAIL

537

Unsupported_DigitMapExt_537

Unknown or unsupported digit map extension.

47

IC_SERVICE_OR_OPTION_NOT_AVAIL

538

Event_Signal_Parameter_Error_538

Event/Signal parameter error—t is returned if the event or signal parameter is in error or not supported.

47

IC_SERVICE_OR_OPTION_NOT_AVAIL

539

Invalid_Unsupported_CommandParam_539

Invalid or Unsupported command parameter—It is returned if the command contains an invalid or unsupported parameter, which is neither a package nor a vendor-specific extension.

47

IC_SERVICE_OR_OPTION_NOT_AVAIL

540

PerEndPoint_ConnLimit_Exceeded_540

Per endpoint connection limit exceeded.

50

IC_TEMPORARY_FAILURE

541

Invalid_Unsupported_LCO_541

Invalid or Unsupported LCO—It is returned if the LCO parameter contains an unsupported or invalid parameter that does not have a package prefix or an X+ extension. If it is an unsupported parameter and has a package prefix, then error code 518 applies. For an unsupported X+ extension, error code 525 applies.

47

IC_SERVICE_OR_OPTION_NOT_AVAIL

596

Vcc_Failure_596

This is a VISM-specific return code and it means there is a VCC failure or that the VCC could not be set up.

50

IC_TEMPORARY_FAILURE

597

GW_Detected_Glare_597

50

IC_TEMPORARY_FAILURE

598

Media_Conn_Fail_598

50

IC_TEMPORARY_FAILURE

599

Media_Con_Loss_599

This is a VISM-specific return code and it means there was a media connection loss.

106

IC_TEMPORARY_OOS

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:

•BA/C: connection count list

•BA/EL: endpoint list

•BA/F: request info

•BA/M: connection mode list

•BA/NE: next endpoint ID

•BA/NU: maximum number of endpoints

•BA/S: endpoint state list

•BA/SE: start endpoint ID

•BA/X: instantiated endpoint list

•BA/Z: end point name list

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.

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:

Ordering Documentation

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:

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.

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

Never use a revoked or an expired encryption key. The correct public key to use in your correspondence with PSIRT is the one linked in the Contact Summary section of the Security Vulnerability Policy page at this URL:

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:

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:

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

Submitting a Service Request

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

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:

Definitions of Service Request Severity

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

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

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

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

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

Obtaining Additional Publications and Information

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

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

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

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

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

•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:

•Networking Professionals Connection is an interactive website for networking professionals to share questions, suggestions, and information about networking products and technologies with Cisco experts and other networking professionals. Join a discussion at this URL: