Table Of Contents
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
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.
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.
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
•Allows the service provider to see the cause of call disconnect in the accounting record.
Allows the service provider to see the cause of call disconnect in the accounting record.
•Provides enhanced diagnostic and troubleshooting capability for VoIP networks.
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.
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.
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.
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).
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
VSAs in RADIUS accounting records
•Call history records
Call history records
•Dial Control MIB
Dial Control MIB
•Syslog messages
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
Physical network entity that encountered the error
•Type of error (category or class)
Type of error (category or class)
•Subsystem within that entity
Subsystem within that entity
•Subsystem-defined error code
Subsystem-defined error code
•Private diagnostic code to allow developers to better pinpoint the software point of failure
Private diagnostic code to allow developers to better pinpoint the software point of failureRelease 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 PSTN
•Calling party located in the VoIP network
Calling party located in the VoIP network
•Called party located in the PSTN
Called party located in the PSTN
•Called party located in the VoIP network
Called party located in the VoIP network
•Internal release in a POTS leg
Internal release in a POTS leg
•Internal release in a VoIP 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 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)
Internal release in VoIP authentication, authorization, and accounting (AAA)
•CLI or Man Machine Language (MML)
CLI or Man Machine Language (MML)
•External RADIUS server
External RADIUS server
•External network management application
External network management application
•External call control agent
External call control agent
•Gatekeeper
Gatekeeper
•External GKTMP server
External GKTMP serverObtaining 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 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.
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.
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.
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.
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.
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.
Entity
The entity field indicates the network signaling entity that generated the IEC. A value of 1 in this field indicates the IEC is generated by the gateway.
Category Codes
Cisco VoIP IEC category codes
Cisco VoIP IEC categories range from 1 to 278, allowing an exact category of error to be specified in the category field of an IEC. With the Cisco VoIP Internal Error Codes feature, the concept of error categories combines and extends the existing Q.850 cause codes to handle VoIP-specific errors as well.
IEC category codes are specified as follows:
•The value range 1 to 127 is equivalent to ITU-based Q.850 cause codes defined for PSTN networks.
The value range 1 to 127 is equivalent to ITU-based Q.850 cause codes defined for PSTN networks.
•The value range 128 to 278 is defined based on VoIP network errors. A mapping is maintained between these error categories to corresponding Q.850 codes (1 to 127 range).
The value range 128 to 278 is defined based on VoIP network errors. A mapping is maintained between these error categories to corresponding Q.850 codes (1 to 127 range).
Note Only the H.323 and Session Initiation Protocol (SIP) subsystems implement an approach to generate disconnect cause codes or Q.850 PSTN cause codes based on error categories. The disconnect cause is chosen based on the mapping from the corresponding error category. You can configure this mapping using CLI. This correspondence of IEC error category and Q.850 disconnect cause is implemented only for SIP and H.323 internal errors, and is not implemented for other subsystems in this release. For more information on SIP and H.323 cause codes, refer to Internal Cause Code Consistency Between SIP and H.323.
Only the H.323 and Session Initiation Protocol (SIP) subsystems implement an approach to generate disconnect cause codes or Q.850 PSTN cause codes based on error categories. The disconnect cause is chosen based on the mapping from the corresponding error category. You can configure this mapping using CLI. This correspondence of IEC error category and Q.850 disconnect cause is implemented only for SIP and H.323 internal errors, and is not implemented for other subsystems in this release. For more information on SIP and H.323 cause codes, refer to Internal Cause Code Consistency Between SIP and H.323.
Table 12 shows the category codes outside the Q.850 range, their descriptions, and the default Q.850 cause code used for each error category. The Q.850 cause codes for these categories can be changed using CLI.
Gatekeeper Category Codes
Cisco gatekeeper IEC categories range from 1 to 24, allowing an exact category of error to be specified in the category field of an IEC. Table 13 shows the category codes for gatekeeper IECs.
Subsystem Codes
Together the subsystem and error codes pinpoint the exact error that cause the call to be released. IECs are reported for the subsystems defined inTable 14.
Error Codes
The Error Code field of the IEC dotted-decimal string value indicates the subsystem-defined error code. Codes 1 through 20 are common to all subsystems and may occur in several places within a subsystem; for these errors, the point of failure can be further isolated by referring to the unique diagnostic code field. Subsystem-specific error codes begin at 21.
No comments:
Post a Comment