When calls go astray, callers experience long wait times, or reports indicate inefficiencies, a deep dive into Cisco Call Detail Records (CDRs) becomes essential for voice engineers to troubleshoot. CDR offers a granular, chronological log of every call processed by CUCM, providing the raw data needed to troubleshoot routing anomalies and optimize call flow performance.
To effectively trace a call through a Cisco Hunt Group or Call Queue, understanding specific CDR fields is crucial. These fields act as breadcrumbs, allowing you to reconstruct the call's path from the moment it enters your system until it's answered or terminated.
callingPartyNumber: This field identifies the originator of the call. Knowing who initiated the call is the first step in any analysis.
originalCalledPartyNumber: This shows the very first number the caller dialed to reach your organization or a specific service. For a Hunt Group, this might be the main pilot number.
finalCalledPartyNumber: This is where the call ultimately connected, rang out unanswered, or was last presented. In a successful Hunt Group call, this would be the directory number of the agent who answered.
pkid: The Primary Key Identifier, a unique UUID for each CDR record, ensuring you can distinctly identify and reference specific call legs.
globalCallID_callManagerId and globalCallID_callId: These together form a unique identifier for the call across the CUCM cluster, vital for linking multiple CDR records that may pertain to a single user interaction, especially in complex scenarios.
lastRedirectDn: This is perhaps one of the most critical fields for analyzing Hunt Groups and Queues. It indicates the directory number (DN) of the entity that performed the last redirection. As a call moves through a Hunt Group (e.g., from pilot to group members, or forwarded due to no answer/busy), this field will update, showing the sequence of DNs involved in routing the call.
Simply knowing where a call was redirected isn't enough; understanding why and by what mechanism it was redirected provides deeper insight into the behavior of your Hunt Groups and Queues.
origCalledPartyRedirectOnBehalfOf and lastRedirectRedirectOnBehalfOf: These fields use "OnBehalfOf" codes to specify the feature or entity that caused the redirection. For example:
A code for "Call Forward Busy" would indicate the original or last called party was busy, triggering a forward.
A code for "Call Forward No Answer" signifies the call rang for a specified duration without being picked up.
Specific codes might directly indicate a Hunt Group algorithm at play, distributing the call. (Note: The exact codes are defined in CUCM's "OnBehalfOf Codes dimension" documentation.)
origCalledPartyRedirectReason and lastRedirectRedirectReason: These fields provide reason codes for the redirection, often aligning with ISDN cause codes or Cisco-specific values. No answer, busy, deflection, and unconditional forwarding are all examples.
By analyzing the sequence of lastRedirectDn entries in conjunction with their corresponding RedirectOnBehalfOf and RedirectReason codes for a given globalCallID_callId, engineers can meticulously map out how a call navigated through a Hunt Group, why it moved from one member to another, or why it perhaps left the queue.
Beyond simple path tracing, CDRs enable the calculation of key performance indicators (KPIs) and the diagnosis of common Hunt Group and Queue problems.
While CUCM CDRs don't always provide a direct "time in queue" field (this is often more explicit in dedicated contact center platform reporting like UCCX), you can infer wait times. By examining the dateTimeOrigination (when the call leg started) and dateTimeConnect (when the call leg connected) for sequential redirected legs of a call before it's finally answered, you can piece together periods of ringing or holding. The duration field of each leg is also informative.
An abandoned call in a Hunt Group context typically means the caller hung up while the call was being presented to group members or was in a queue. This can often be identified by looking at the destCause_value for the call leg that was ringing at a Hunt Group member or pilot. A cause code indicating the caller terminated the call (e.g., normal clearing by the originator before connection) before dateTimeConnect shows a value, points to an abandonment.
The finalCalledPartyNumber and associated destDeviceName show which agent or device ultimately handled the call. Consistent forwarding or calls ringing out without an answer from certain members (indicated by lastRedirectDn and RedirectReason like "No Answer") can point to availability issues or misconfigured membership.
Calls Not Reaching Available Agents: CDRs can show if calls are being redirected away from the Hunt Group prematurely or if the redirection logic within the group is flawed.
Calls Ringing to Incorrect Members: Verify the sequence of lastRedirectDn against the configured Hunt Group membership and distribution algorithm.
Excessive Forwarding/Looping: A long chain of redirections for a single call can indicate a configuration loop or overly complex forwarding rules.
1. Isolate all CDRs for the call using globalCallID_callId.
2. Start with the originalCalledPartyNumber.
3. Follow the chain of lastRedirectDn entries.
4. At each hop, examine RedirectReason and RedirectOnBehalfOf codes.
5. Note dateTimeConnect and duration for each segment to understand timing.
6. Check the finalCalledPartyNumber and its destCause_value to see the ultimate outcome.
Partitions play a vital role in CUCM's call routing logic and can significantly impact how calls reach or are routed by Hunt Groups. Fields like originalCalledPartyNumberPartition, callingPartyNumberPartition, finalCalledPartyNumberPartition, and lastRedirectDnPartition specify the partitions associated with these numbers. An incorrect partition assignment can prevent calls from reaching a Hunt Pilot or prevent members from receiving calls from the Hunt Group. CDR analysis can help identify if partition-related issues are the root cause of routing failures.
Manually dissecting raw CDR files, correlating multiple records, and translating codes for every Hunt Group inquiry can be incredibly laborious and prone to errors. Expo XT visualizes call flows, highlights abandoned calls, identifies inefficient routing patterns, and allows IT Managers and Voice Engineers to quickly generate valuable reports, ensuring accurate cradle-to-grave insights not just within Cisco platforms but across integrated third-party systems as well.
