Whether it's a dropped call, a failed setup, or a normal hang-up, Cisco Call Detail Records (CDRs) provide the essential clues as to why calls ended. By decoding the termination cause codes and related fields within these records, technical teams can effectively troubleshoot issues, improve call completion rates, and maintain a resilient Cisco voice infrastructure.
The most direct indicators of why a call leg terminated are the origCause_value and destCause_value fields. These fields store numeric codes representing the reason for the call clearing, one for the originating side of the call leg and one for the destination side. The party that initiates the disconnect typically dictates the cause code recorded.
Many of these codes are based on the ITU-T Q.850 standard, originally developed for ISDN, but widely adopted in VoIP and SIP signaling. Familiarity with common Q.850 codes is essential:
1: Unallocated (unassigned) number – The number dialed is not in use.
16: Normal call clearing – The call ended as expected, e.g., one party hung up.
17: User busy – The called party was engaged in another call.
18: No user responding – The destination device was alerted but did not answer (timeout).
19: No answer from user (user alerted) – Similar to 18, specifically means the user was alerted but didn't pick up.
21: Call rejected – The called party actively rejected the call.
22: Number changed – The dialed number has been changed and is no longer reachable at the dialed address.
27: Destination out of order – The destination device or network segment is non-operational.
31: Normal, unspecified – A normal clearing, but the specific reason is not provided.
34: No circuit/channel available – Network congestion or trunk capacity issues preventing call setup.
38: Network out of order – Indicates a significant failure within the network.
41: Temporary failure – A transient issue preventing the call; retrying might succeed.
47: Resources unavailable, unspecified – Similar to 34, but could be other resources like MTPs, transcoders.
Cisco-Specific and Other Codes: Beyond Q.850, Cisco may use its own specific cause codes for particular scenarios or features. For example, 393216 is often seen for call splits (transfers/conferences). It's crucial to consult Cisco documentation for the specific CUCM version for a comprehensive list of proprietary codes.
These fields provide context about where the cause originated (e.g., user, private network local to the user, public network). This can help narrow down whether the issue is on-net or off-net.
While cause codes tell you why a call ended, the origCallTerminationOnBehalfOf and destCallTerminationOnBehalfOf fields indicate which entity or feature initiated the termination. This is represented by "OnBehalfOf" codes.
These codes map to specific CUCM entities (refer to Cisco's "OnBehalfOf Codes dimension" for specifics):
0: Unknown – The terminating entity couldn't be determined.
1: Station Device – Typically means the user at an IP phone hung up.
2: Trunk Gateway – The call was terminated by a gateway (e.g., PSTN disconnect).
4: Voice Mail System – The call was terminated by the voicemail system (e.g., after leaving a message).
5: Media Resource – Termination by a media resource like a conference bridge, Music On Hold server, or Media Termination Point (MTP).
12: Call Park – Call terminated because it was parked and then, for instance, reverted or was retrieved and then ended.
Understanding these helps distinguish between a user-initiated disconnect, a system-initiated action, or an issue with a specific network component.
Armed with cause codes and OnBehalfOf information, engineers can tackle common call failure scenarios:
Look for calls with an unexpected destCause_value (e.g., 38 - Network out of order, 41 - Temporary failure, 47 - Resources unavailable) and check the destCallTerminationOnBehalfOf to see if it points to a network element like a gateway (2) or a media resource (5). Short duration values post-connection are also red flags.
Frequent occurrences of codes like 1 (Unallocated number), 22 (Number changed), 27 (Destination out of order), or 34 (No circuit/channel available) point to dial plan issues, incorrect numbers, device problems, or capacity shortages on trunks/gateways.
If calls terminating via a specific gateway (identified by destDeviceName or destSpan) frequently show cause codes like 34 or 38, it points to issues with that gateway or the associated trunk circuits.
While CDRs don't directly diagnose issues like one-way audio, they can offer clues. If calls connect (dateTimeConnect is populated) but then terminate very quickly (low duration) with an unusual cause code, it might suggest media negotiation failures or RTP stream problems. Fields like origMediaTransportAddress_IP, destMediaTransportAddress_IP, origMediaCap_payloadCapability (codec), and destMediaCap_payloadCapability provide data on the media session that can be correlated with network monitoring tools.
Though not always populated, the comment field can sometimes contain valuable information. For example, features like Malicious Call Identification (MCID) might flag a CDR with "CallFlag=MALICIOUS."
The timing of events is crucial in call termination analysis:
dateTimeOrigination: When the call leg attempt began.
dateTimeConnect: When the call leg was established (ringing stopped, conversation started). If zero, the call never connected.
dateTimeDisconnect: When the call leg ended.
duration: The length of the connected portion of the call in seconds. A zero duration for a call that attempted to connect means it failed before being answered. Very short durations after connection might indicate an immediate problem perceived by the user or system.
To effectively use CDRs for troubleshooting terminations:
Filter and Aggregate: Collect CDRs for the period or numbers in question. Aggregate by destCause_value and origCause_value to identify the most common termination reasons.
Prioritize Investigation: Focus on the most frequent abnormal cause codes or those with significant impact (e.g., "Network out of order").
Examine OnBehalfOf Codes: For problematic calls, determine which entity triggered the termination.
Correlate with Device Information: Use origDeviceName and destDeviceName to see if issues are tied to specific devices, gateways, or user groups.
Analyze Timings: Check call durations and the time between origination, connection, and disconnection for patterns.
Manually interpreting thousands of CDRs, translating cryptic cause codes, and correlating multiple fields to diagnose call termination issues is a monumental task. Metropolis Corp’s Expo XT UC Analytics solution automates this entire process. Expo XT ingests, normalizes, and analyzes Cisco CDR data, translating termination codes into plain English, providing dashboards of call completion rates, and allowing for powerful drill-downs into specific failure reasons. This empowers IT Managers and Voice Engineers to proactively identify and resolve issues, enhance user satisfaction, and gain true cradle-to-grave visibility across their Cisco communications landscape and any integrated third-party platforms.
