Call Detail Records (CDRs): Fields, Examples, and How to Read Them

A call detail record (CDR) is a data record that a phone system, SIP proxy, or carrier switch creates for each call it processes. It captures the call’s metadata: who called whom, when the call started and ended, how long it lasted, and how it finished. It does not contain the audio, a transcript, or any content from the conversation itself.

CDR at a glance

What a call detail record actually contains

Every call that passes through a PBX, SIP trunk, or carrier switch leaves behind a record of what happened, separate from the audio itself. That record is the CDR. A softswitch or SIP proxy writes one automatically each time a call is set up, connected, and torn down, without needing anyone to request it.

A CDR is a metadata record, not a recording. It answers questions like which number called which number, when the call started, whether it was answered, how long it lasted, and why it ended, without storing anything about what was said. Call recordings are a separate, optional feature that some platforms attach to a CDR as a linked file, but the CDR record and the recording are not the same object.

There is no single global standard that defines exactly which fields a CDR must contain or what they must be named. Field names and formats vary by platform. This article uses field names that follow common conventions across widely deployed SIP platforms, most notably the open-source Asterisk PBX, whose documentation is one of the most detailed public references for how these fields behave in practice.

The fields inside a CDR

Most CDRs, regardless of vendor, group their fields into a similar set of categories.

A single CDR record has a defined set of default fields that are set automatically, including the calling party’s number, the destination, the full caller ID, a disposition value, and a unique identifier for the call leg, alongside optional fields such as an account code or a general-purpose user field . Disposition itself is typically limited to a small set of values such as no answer, failed, busy, answered, or unknown, which is what makes it useful for quickly filtering large volumes of call history.

A worked example: reading a CDR line by line

The table below shows one illustrative CDR line for an outbound call, using generic field names and a fictional UK number reserved for example use.

Reading this line top to bottom: a call went out from a US number to a UK number, rang for 7 seconds, was answered, ran for 4 minutes and 31 seconds in total, and ended normally rather than being dropped or rejected. The hangup cause code follows the ITU-T Q.850 numbering used across SIP and PSTN signaling, which is covered in more detail in SIP response codes explained, including how SIP responses map onto these underlying cause values.

Why one phone call can produce more than one CDR

A single phone call, from the caller’s point of view, is one continuous conversation. From the network’s point of view, it is usually a chain of separate legs, and each leg can be logged by a different system. A CDR fundamentally represents one path of communication between two endpoints, and a call that passes through multiple points, such as a PBX forwarding to a trunk which forwards to a carrier, produces a separate CDR at each hop . Platforms that support this typically add a shared linking identifier so that related CDRs from the same overall call can be reassembled later, though it is left to the billing or reporting system to decide which of the linked records to use and how to combine their durations.

This matters in practice for two reasons. First, if a business phone system, a SIP trunk provider, and a terminating carrier each keep their own call history, none of them alone tells the complete story, since each only sees its own leg of the call. Second, when a call is transferred, forwarded to voicemail, or bridged into a conference, additional CDRs are generated for each new path of communication, so a single logical call can appear as several rows across a report even though the caller only experienced one conversation.

Duration versus billsec: why they are different numbers

Two of the most commonly confused fields in any CDR are duration and billsec. Duration is the end time minus the start time, which includes any time spent ringing before the call was answered. Billsec is the end time minus the answer time, which only counts the connected portion of the call . Whether a billing system actually uses billsec for charging, or uses some other convention, is a decision left to that system rather than something the CDR format enforces.

This distinction explains a common troubleshooting confusion: a report that shows duration and billsec as very different numbers for the same call usually means the call rang for a long time before being answered, not that something is wrong with the record. Conversely, if a call was never answered, most platforms leave billsec at zero while duration still reflects the time spent ringing, which is why disposition should always be checked alongside these two timing fields rather than relying on a nonzero duration to assume a call connected.

CDR, Charging Data Record, and other easily confused terms

The abbreviation CDR is genuinely ambiguous outside a specific context, and conflating its two common meanings is one of the more consequential mix-ups in this space.

In fixed-line, PBX, and SIP telephony, CDR means call detail record: a log entry for a single call leg, in a format defined by whichever platform produced it. In mobile core networks, 3GPP standardizes a formally specified record under the same abbreviation, the Charging Data Record, described in the technical specification “Charging management; Charging Data Record (CDR) parameter description” , which covers CDR types across the circuit-switched domain, the packet-switched (GPRS) domain, and other 3GPP charging domains. These two records serve a similar purpose, generating a usage record for billing and reporting, but they are defined by different standards bodies, follow different structures, and are not interchangeable.

A related distinction worth keeping straight is between a CDR and a call management record (CMR), a term used in some enterprise telephony platforms for a separate diagnostic record that captures quality of service information such as jitter, latency, and packet loss, as opposed to the call’s origination, destination, and timing captured in the CDR itself . A CDR tells you that a call happened and how it was classified; a CMR, where a platform produces one, tells you how the media quality behaved during that call.

Finally, disposition and hangup cause are not the same thing as a SIP response code, even though they describe related events. A SIP response code such as 486 or 503 is generated during call setup signaling, while a hangup cause code (commonly following the ITU-T Q.850 numbering) explains why an established or attempted call ended. SIP response codes explained covers how the two relate and where the standard Q.850 mappings come from.

What CDR data is used for

CDR data underpins several distinct operational functions, often from the same dataset:

• Billing reconciliation. Aggregating billsec and rate fields across a period to reconcile invoices between a business and its provider, or between wholesale carriers.
• Fraud detection. Spotting unusual patterns, such as a sudden spike in short international calls or bursts of activity outside business hours, that can indicate a compromised trunk or account. VoIP toll fraud and SIP security: how attacks happen covers how this kind of activity typically develops.
• Troubleshooting. Using disposition and hangup cause together to work out why a specific call failed, rather than relying on a customer’s description of what happened.
• Capacity and quality reporting. Aggregating call volumes, average duration, and disposition ratios over time to track how a route or trunk is performing.
• Compliance and audit trail. Providing a verifiable record that a call took place between two numbers at a given time, independent of any recording.

Common mistakes when working with CDR data

• Treating duration and billsec as interchangeable. They measure different windows of the same call, and using the wrong one for billing overcharges for ring time that was never answered.
• Assuming one call always means one CDR. Transfers, forwards, and multi-leg routing all generate additional linked records.
• Assuming disposition values are consistent across every platform. Because there is no universal telephony CDR standard, the exact set of disposition strings and their meaning can differ between vendors, even when the concept is similar.
• Confusing a CDR with a call recording. A CDR proves a call happened and how it ended; it says nothing about what was discussed.
• Reading a nonzero duration as proof the call connected. Always check disposition first; a call that only reached ringing can still show a nonzero duration.
• Treating CDR exports as low-risk data because they are “just logs.” Call metadata can still identify individuals and relationships between them, which has consequences covered below.

CDRs, personal data, and retention

A CDR does not contain conversation content, but it does contain identifying information: phone numbers, timestamps, and patterns of who called whom. In the EU, this kind of information is treated as traffic data under the ePrivacy Directive, which requires that traffic data be erased or made anonymous once it is no longer needed for the call, except where it is retained for billing purposes and only for as long as an invoice could reasonably be disputed .

Specific retention obligations, and whether local law treats CDR data as personal data in a stricter sense, vary by country and by regulator. A business handling CDR exports for reporting or analytics should confirm its own retention policy with its legal or compliance team rather than assume a single global rule applies, since this is exactly the kind of requirement that differs by jurisdiction.

Where didlogic fits

didlogic operates at the SIP trunking and voice termination layer: the infrastructure that carries a call between a customer’s phone system or platform and the public telephone network. When a call is set up, connected, or terminated through didlogic’s network, that leg of the call generates its own CDR on didlogic’s platform, separate from any CDR the customer’s own PBX or a further downstream carrier might generate for the same overall call.

That CDR is retrievable through didlogic’s API, which exposes a call detail record endpoint supporting filtering by date range, call type, phone number, and SIP account, with results available in JSON or CSV and pagination for larger result sets <cite index=”62-1″>. The same API surface includes related endpoints for call statistics and downloading call recordings, alongside separate reporting for answer-seizure ratio (ASR). Typical uses include generating call history reports, analyzing call patterns and costs, exporting billing data, and monitoring SIP account usage.

didlogic is not a PBX, a dialer, or a call-recording application, so it does not see or control the CDR generated on the customer’s own phone system. It provides the connectivity layer and the CDR for the leg of the call that passes through its network, which is one part of the fuller picture described earlier in this article.

Frequently asked questions

What is a call detail record (CDR)?
A CDR is a metadata record that a phone system, SIP proxy, or carrier switch creates for each call it processes, capturing who called whom, when, for how long, and how the call ended. It does not contain the audio or content of the call.

What is the difference between duration and billsec in a CDR?
Duration measures from the start of call setup to the end of the call, including any ringing time. Billsec measures only from the moment the call was answered to the end, which is normally the portion a business would actually bill for.

Why can one phone call produce more than one CDR?
Because a call usually passes through several systems, such as a PBX, a SIP trunk provider, and a terminating carrier, and each one can generate its own record for its leg of the call. Some platforms link these records with a shared identifier, but they remain separate CDRs.

Is a CDR the same as a Charging Data Record?
No. Both share the CDR abbreviation, but call detail record refers to telephony call logs from PBXs, SIP platforms, and carrier switches, while Charging Data Record is a specific term standardized by 3GPP for mobile network charging, defined in a different specification with a different structure.

Does a CDR include the audio or content of a call?
No. A CDR is limited to metadata: numbers, timestamps, duration, and outcome. Call recordings, where a platform supports them, are a separate feature that may be linked to a CDR but are stored and governed differently.

Do CDRs count as personal data, and how long should they be kept?
Call metadata can identify individuals and their calling patterns, so many regulators treat it with data protection obligations similar to other personal data. In the EU, it is also treated as traffic data with its own retention rules. Exact retention periods vary by jurisdiction, so this is best confirmed with legal or compliance guidance rather than assumed.

Continue learning

• What is SIP trunking
• SIP response codes explained
• VoIP toll fraud and SIP security: how attacks happen
• What is the PSTN?
• HLR lookup explained: what it tells you about a number
• Caller ID Reputation and “Spam Likely” Labels Explained