Call transfers are an integral part of daily communications in any organization. Whether it's a receptionist directing a caller, an agent escalating an issue, or a colleague forwarding a call, understanding the lifecycle of these transferred calls is vital for effective voice management. Cisco Call Detail Records (CDR) hold the key to dissecting these scenarios, offering the data points needed to troubleshoot issues, assess user experience, and compile precise call reports for your Cisco voice environment.
The first challenge is accurately identifying which calls involved a transfer. CUCM uses specific mechanisms and fields within CDRs to denote these actions.
A primary indicator of a transfer (or conference) is found in the origCause_value and destCause_value fields. A value of 393216 (or a similar Cisco-specific code) often signifies a "call split." This means CUCM has split the original call leg and created a new one to facilitate the transfer. The original leg involving the transferring party might be terminated with this cause code, while a new record or an existing record is modified to reflect the connection between the original caller and the transfer recipient.
This field is crucial for understanding call linkage. When a call leg joins another, such as during a transfer or conference, joinOnBehalfOf specifies the feature that initiated this join. A common code for "Transfer" (e.g., code 2, though the exact value can be found in Cisco's OnBehalfOf Codes dimension) in this field on a CDR indicates that this leg was joined to another as part of a transfer operation.
To trace all parts of a transferred call, the globalCallID_callManagerId and globalCallID_callId are indispensable. These values typically remain consistent across all CDRs generated for the various segments of a single logical call, allowing you to gather all related records for a complete picture. The pkid provides the unique identifier for each individual CDR record.
Once identified, the next step is to trace the call's path through the transfer process. Transfers can be consultative (warm) or blind (cold), and CDRs reflect these differently.
Consultative Transfer: Agent A puts Caller X on hold, calls Agent B to consult, then completes the transfer, connecting Caller X to Agent B. This usually involves multiple call legs:
Caller X to Agent A.
Agent A to Agent B (consultation leg).
Caller X to Agent B (after transfer completion).
CDRs will reflect these distinct phases, often linked by the Global Call ID and utilizing joinOnBehalfOf or call split cause codes.
Blind Transfer: Agent A transfers Caller X directly to Agent B without prior consultation. This might result in fewer distinct legs in CDRs but will still show the redirection.
callingPartyNumber, originalCalledPartyNumber, finalCalledPartyNumber: These fields track the "who called whom" for each leg. During a transfer, you'll see the finalCalledPartyNumber change from the initial answering party to the ultimate transfer destination.
lastRedirectDn: This field is key to identifying who initiated the transfer. If Agent A transfers a call to Agent B, Agent A's directory number might appear in lastRedirectDn on the CDR record representing the call leg going to Agent B.
origLegCallIdentifier and destLegIdentifier: These unique identifiers for each call leg within the CUCM cluster can help in meticulously mapping connections between different stages of the call.
dateTimeConnect, dateTimeDisconnect, duration: These timestamps are essential for understanding how long each party was connected and the total duration of interaction for each segment of the transferred call. This can help identify delays during the transfer process.
Beyond just tracing, CDRs allow for deeper analysis of transfer behaviors and outcomes.
By correlating lastRedirectDn with the callingPartyNumber and finalCalledPartyNumber across linked CDRs, and using the timestamp fields (dateTimeConnect, dateTimeDisconnect), you can build a precise narrative of the transfer.
While CDRs don't contain a "reason for transfer" text field entered by a user, patterns can indicate underlying reasons. For example, multiple transfers originating from a specific department might suggest a need for better initial call routing or further training. The comment field is rarely used for this but is a possibility if custom solutions are in place.
Manually piecing together these intricate details from raw CDR files for every transferred call is a complex and time-intensive endeavor.
Metropolis Corp’s Expo XT radically simplifies this. Expo XT intelligently correlates all related call legs, including complex transfers and conferences, to present a unified, clear cradle-to-grave view of the entire call journey.
The success of a transfer can be gauged by examining the destCause_value of the call leg directed to the final recipient. If it shows a normal connection and a reasonable duration, the transfer was likely successful. If it shows "No Answer," "User Busy," or an error code, the call transfer may have failed from the caller's perspective.
In complex scenarios where a call is transferred multiple times, consistently tracking the globalCallID_callId and observing the sequence of lastRedirectDn and finalCalledPartyNumber changes will allow you to follow the entire chain.
CDRs are invaluable for diagnosing common problems associated with call transfers.
Look for CDRs where a leg is terminated with an abnormal destCause_value shortly after a joinOnBehalfOf (transfer) event. The duration of the connected leg post-transfer would be very short.
The finalCalledPartyNumber and destDeviceName will reveal where the call actually landed. If it's consistently a voicemail system when it shouldn't be, or an unexpected number, it points to configuration issues or user error.
Analyzing the dateTimeConnect timestamps for the different legs of a consultative transfer can reveal if the consultation phase or the final connection is taking too long.
Collect all CDRs sharing the same globalCallID_callId.
Identify records indicating a transfer through joinOnBehalfOf codes or orig/destCause_value (call split codes).
Map the call sequence using callingPartyNumber, finalCalledPartyNumber, lastRedirectDn, and timestamps for each leg.
Examine origDeviceName and destDeviceName to pinpoint the specific phones or gateways involved.
Check destCause_value for each leg to understand its termination status.
Manually piecing together these intricate details from raw CDR files for every transferred call is a complex and time-intensive endeavor. Metropolis Corp’s Expo XT radically simplifies this. Expo XT intelligently correlates all related call legs,
including complex transfers and conferences, to present a unified, clear
of the entire Cisco call journey.
