Pankaj Bhagchandani, Pankaj Bhagchandani G, Pankaj G Bhagchandani, G Pankaj Bhagchandani, G Pankaj Bhagchandani G, Pankaj G Bhagchandani G,

Cisco VoIP Internal Error Codes

---

The Cisco VoIP Internal Error Codes feature generates internal error codes (IECs) for gateway-detected errors that cause the gateway to release or refuse a call. IECs enhance troubleshooting for VoIP networks by helping to determine the source and reason for call termination.

•Prerequisites for Cisco VoIP Internal Error Codes

•Restrictions for Cisco VoIP Internal Error Codes

•Information About Cisco VoIP Internal Error Codes

•How to Configure IEC Options

•Configuration Examples for Cisco VoIP Internal Error Codes

•Troubleshooting VoIP Networks Using Cisco VoIP Internal Error Codes

Prerequisites for Cisco VoIP Internal Error Codes

Before this feature can be operational, a basic VoIP network must be configured.

Restrictions for Cisco VoIP Internal Error Codes

•Memory usage increases slightly when this feature is implemented, depending upon the number of subsystems that support IECs and upon the number of error codes defined for each subsystem.

•IECs are reported only in RADIUS accounting records. They are not supported in syslog accounting.

Information About Cisco VoIP Internal Error Codes

To configure the Cisco VoIP Internal Error Codes feature, you should understand the following concepts:

•Benefits of Cisco VoIP Internal Error Codes

•Feature Design of Cisco VoIP Internal Error Codes

•IEC Reporting

•Internal Error Code Notation

Benefits of Cisco VoIP Internal Error Codes

•Allows the service provider to see the cause of call disconnect in the accounting record.

•Provides enhanced diagnostic and troubleshooting capability for VoIP networks.

•Supports the development of enhanced analysis tools that can determine if patterns of call failures exist.

•Improves network reliability by enabling more effective monitoring and call management.

•Internal Error Code (IEC) reporting has been enhanced in Cisco IOS Release 12.4(4)T to provide better tracking and diagnostic capability for networks, and specifically for gatekeepers.

Feature Design of Cisco VoIP Internal Error Codes

Prior to the implementation of IECs, Q.850-based disconnect cause codes were used to track and diagnose network problems. These cause codes, defined by ITU Recommendation Q.850, were more applicable to traditional PSTN networks than to packet networks and were too generic to be useful for diagnosing and isolating faulty VoIP network components.

The Cisco VoIP Internal Error Codes feature allows an error code to be generated for a gateway-detected error that causes the gateway to release or refuse a call or call attempt. The error may not actually cause the call to fail; for example, in the case of rotary attempts, a subsequent attempt may result in the call completing. The error does not necessarily indicate a problem on the gateway itself, but may be due, for example, to a protocol error detected in a message, or to a timeout while communicating with a nonresponding party. IECs are not generated for normal calls that are released without an error; for example, no answer, busy, and user hangs up.

Each internal error in the voice signaling path that leads to the release of a call is assigned an IEC value. Fields within the IEC identify which network entity and subsystem originated the error, and specify the error code within the subsystem. The IEC mechanism maintains error counters and allows you to use command-line interface (CLI) commands to collect, display, and offload error counters. The CLI also allows you to clear counters. The IEC mechanism also generates a CLI-enabled syslog message and a new RADIUS vendor-specific attribute (VSA) whenever an IEC is generated.

The IEC feature supports a mechanism for enforcing disconnect cause code consistency for internal errors by providing a configurable mapping table to translate the IEC error category to an appropriate disconnect cause code.

In addition to generating IECs, this feature set makes use of enhanced release source indicators (RSIs) to report gatekeeper-released and route server-released calls. For more information on RSIs, refer to Call Release Source Reporting in Gateway-Generated Accounting Records.

---

Note IECs are not generated for the following types of calls: VoiceXML, fax, MGCP or SGCP, and SS7 continuity (COT).

---

IEC Reporting

Cisco implements IEC reporting by logging IEC values into the following records:

•VSAs in RADIUS accounting records

•Call history records

•Dial Control MIB

•Syslog messages

The gateway sends VSAs in RADIUS accounting stop records. Because each IEC is associated with a call leg, an IEC is reported only in the stop record for one of the legs in a call. VSAs are also sent by the gatekeeper. The gateway collects IECs for all call legs involved in a call and reports them to the gatekeeper, which inserts the IECs in its accounting stop record. In some scenarios, multiple errors may be encountered for a particular call leg; for example, multiple attempts to connect to an alternate endpoint. Up to five IECs may be generated per call.

Because IECs are reported through accounting records, if there is no voice call association or context, no IEC is generated. This scenario occurs, for example, if the gateway receives an ISDN setup message and the ISDN layer fails to allocate resources to process the setup message. In this instance there is no indication to the Voice Telephony Service Provider (VTSP) layer and no creation of a call-leg or call-history record, so no IEC is generated.

Gatekeeper Behavior and Cisco VoIP Internal Error Codes

Gatekeeper behavior for RADIUS accounting for start and stop records changes with the introduction of VoIP internal error codes. Prior to the Cisco VoIP Internal Error Codes feature, the gatekeeper generated two records for intrazone calls: one start record, based on the originating admission reject (ARJ) message, and one stop record, based on the first incoming disengage request (DRQ) message. This limitation resulted in data from the DRQ of the other gateway not being included in the accounting.

For intrazone calls the Cisco VoIP Internal Error Codes feature allows the gatekeeper to generate start and stop records based on each ARQ and DRQ; that is, two start and stop records are generated for each call.

Gatekeeper IEC Logging

The gateway collects IECs for all call legs involved in a call and reports them to the gatekeeper in a DRQ message during call release. The gateway also sends RSI information in the DRQ message. The gatekeeper then logs the RSI and IEC information in RADIUS accounting stop records.

IEC Differences in Gateway and Gatekeeper Accounting

On the gateway an IEC is logged in to a stop accounting record for the call leg that encountered the error. If an error occurred in the VTSP call leg, an IEC is logged in the telephony stop record; no IEC is recorded in the VoIP stop record, and vice versa.

Figure 9 shows the differences between gateway and gatekeeper accounting. On the gatekeeper, the two call legs, telephony and VoIP, are treated as one call leg, with IEC information merged from both originating gateway (Gateway 1) call legs. The DRQ message to the gatekeeper therefore contains IECs combined from both the telephony and VoIP call legs for a particular call. From the gatekeeper perspective, the second call leg is the terminating gateway (Gateway 2) call leg. This call leg records accounting information received as well.

Figure 9 Differences in Gateway and Gatekeeper Accounting

IEC and RSI Format in DRQ

IEC and RSI information is communicated in the RasnonStdUsageInformation field in the usageInformation information element (IE) of the DRQ message. The following example shows a partial DRQ message:

value RasnonStdUsageInformation ::= 

    {

      rasMessageSpecificData drqRasnonStdUsageData :

      {

        callReleaseSource internalReleaseInVoipLeg :NULL

        iecInfo 

        {

          '10105480022C0000'H

The 64-bit IECs are communicated as an array of eight characters (of size eight bits). The callReleaseSource is communicated as an enumerated value.

Gatekeeper-Initiated Release Scenario

Prior to Cisco IOS Release 12.4(4)T, if the gatekeeper forcefully initiates a release for an active call by sending a DRQ message, then no IEC is generated. The IEC feature does not support gatekeeper-generated IECs. The ReleaseSource VSA for this scenario indicates a value of gatekeeper; however, there is no InternalErrorCode VSA.

Starting with Cisco IOS Release 12.4(4)T, the capability was expanded so that gatekeeper-detected errors that cause the gateway to release or refuse a call are covered. The IEC generated at the gatekeeper is sent in the ARJ/DRQ RAS message to the gateway. The gateway then sends the IEC in a RADIUS accounting record. The gatekeeper IEC clearly identifies:

•Physical network entity that encountered the error

•Type of error (category or class)

•Subsystem within that entity

•Subsystem-defined error code

•Private diagnostic code to allow developers to better pinpoint the software point of failure

Release Source Extension

Prior to Cisco IOS Release 12.3(2)T, both gatekeeper and Gatekeeper Transaction Message Protocol (GKTMP) server-released calls were treated as gatekeeper-released calls, and were indicated by an RSI value of external call control agent. The Cisoc IOS Release 12.3(2)T version provides extended release source values for GKTMP server and gatekeeper. RSI information is passed in the NonStandardUsageData parameter field of the ARJ and DRQ messages from the gatekeeper to gateway during call tear down.

There is no change in the GKTMP interface; instead the context of the release scenario is used to determine the RSI value at the gatekeeper. For example, the receipt of a RESPONSE.ARJ message from the route server results in an RSI value of external gktmp server. Similarly, a forced release from gatekeeper using the clear h323 gatekeeper call command results in the RSI value of gatekeeper.

Release Source Values

With respect to a single network, the following release sources are possible:

•Calling party located in the PSTN

•Calling party located in the VoIP network

•Called party located in the PSTN

•Called party located in the VoIP network

•Internal release in a POTS leg

•Internal release in a VoIP leg

•Internal call-control application (for example, Tool Command Language (Tcl) or Voice eXtensible Markup Language (VXML) script

•Internal release in VoIP authentication, authorization, and accounting (AAA)

•CLI or Man Machine Language (MML)

•External RADIUS server

•External network management application

•External call control agent

•Gatekeeper

•External GKTMP server

Obtaining IECs

Choose one or more of the following options to obtain IEC information:

•Display IECs as they are encountered in real time by enabling syslog messages. The IEC is not included in syslog-accounting records. For more information on enabling syslog messages, refer to the chapter "Task 2. Enabling Syslog" of Enabling Management Protocols: NTP, SNMP, and Syslog.

•Display running and interval IEC counters, and IEC descriptor strings using CLI commands.

•Export IEC counts to a specified server. For more information, refer to Voice Call Performance Statistics on Cisco Gateways.

•Retrieve IEC and RSI information using Tcl IVR 2.0 scripts. For more information on using Tcl scripts with the IEC feature, refer to Supplemental Tcl IVR API Version 2.0 Programmer's Guide.

If you use call detail recording (CDR) templates to filter VSAs that are included in accounting records to the RADIUS server, you must add the IEC VSA to the CDR template if you want to display IEC VSAs.

Sample IEC Syslog Message

The following example shows an IEC-generated syslog message:

Oct 14 17:13:21.534:%VOICE_IEC-3-GW:CCAPI:Internal Error (Trunk-group select

 fail):IEC=1.1.182.1.23.8 on callID 62 GUID=11C79B82DECF11D68044C61A8D4F75E3

Sample IEC Syslog Message for Gatekeeper

The following example shows an IEC-generated system logging (syslog) message for gatekeeper:

Oct 14 17:13:21.534:%VOICE_IEC-3-GK:Internal Error ("DRQ in progress"):IEC=1.2.182.1.23.0 
on ConfID 243 GUID=123a2b0912345678

If there is no call leg context, the ConfID is -1, and the GUID field is blank.

Sample RADIUS VSA Internal Error Code

The following example shows a partial RADIUS stop accounting record for an IEC:

[Vendor 9/1] cisco-avpair = "internal-error-code=1.1.179.2.37.0"

Sample Call History Record

The show call history voice command displays VSA information in the following format:

InternalErrorCode=1.1.128.7.47.0

Sample Dial Control MIB Entry

The IEC entry is controlled by the following indexes:

•cCallHistoryIndex, which indicates IECs related to a specific call history record.

•cCallHistoryIecIndex, which is used if there is more than one IEC for a call history record.

The following example shows a partial Dial Control MIB table entry for an IEC:

CCallHistoryIecEntry ::=

        SEQUENCE {

            cCallHistoryIecIndex         Unsigned32,

            cCallHistoryIec              SnmpAdminString

        }

The following example shows the use of the management tool command getmany to obtain the IEC:

getmany 10.7.102.32 cCallHistoryIec

cCallHistoryIec.5.1 = 1.1.180.1.26.0

getmany 10.7.102.32 cCallHistory

cCallHistorySetupTime.5 = 8540739

cCallHistoryPeerAddress.5 = 4085550190

cCallHistoryPeerSubAddress.5 =

cCallHistoryPeerId.5 = 1112224

cCallHistoryPeerIfIndex.5 = 213

cCallHistoryLogicalIfIndex.5 = 108

cCallHistoryDisconnectCause.5 = 3F

cCallHistoryDisconnectText.5 = service or option not available, unspecified (63)

cCallHistoryConnectTime.5 = 0

cCallHistoryDisconnectTime.5 = 8540740

cCallHistoryCallOrigin.5 = answer(2)

cCallHistoryChargedUnits.5 = 0

cCallHistoryInfoType.5 = speech(2)

cCallHistoryTransmitPackets.5 = 0

cCallHistoryTransmitBytes.5 = 0

cCallHistoryReceivePackets.5 = 0

cCallHistoryReceiveBytes.5 = 0

cCallHistoryReleaseSrc.5 = calledPartyInVoip(4)

cCallHistoryIec.5.1 = 1.1.180.1.26.0

In the preceding example, 5 is the index of the call history record and 1 is the index of the IEC for that record.

The following example shows the use of the indexes and the management tool command getone to obtain the IEC directly:

getone 10.7.102.32 cCallHistoryIec.5.1

cCallHistoryIec.5.1 = 1.1.180.1.26.0

Internal Error Code Notation

The IEC value takes the form of a dotted string of decimal numbers: version.entity.category.subsystem.errorcode.diagnosticcode.

Table 11 describes the six fields that identify the components of the IEC.