A call detail record is the entry a SIP server writes when a call ends. It records who called whom, when, for how long, in which direction, and how the call terminated. Exact field names vary by vendor.

Are CDR fields standardised?

No. RFC 3261 standardises the SIP messages, but each server chooses its own record schema. The fields described here are common across implementations; confirm exact names in your server documentation.

What does duration mean in a CDR?

Usually the connected media time, not the ring time. A call that rang but was never answered has a duration near zero. Check your server's definition before reporting on it.

How do I tell who hung up?

Read the termination cause field. A normal end shows a BYE from one side; abnormal ends carry SIP codes such as 486 Busy Here, 480 Temporarily Unavailable, or 503 Service Unavailable.

What happens to CDRs if power fails mid-call?

The call ends without a graceful BYE and that record may be incomplete. Servers differ here; confirm the behaviour in the documentation. Records written before the outage to stable storage normally survive a reboot.

Can CDRs show echo or noise problems?

No. CDRs record signalling and call metadata, not audio quality. Acoustic echo and background noise are handled by the sister products FlyAec and FlyDenoise, not by the SIP server or its records.

OPERATIONS · SIP · 9 min read

SIP Call Detail Records: A Practical CDR Guide

What a SIP call detail record contains, how to read direction and duration, and how to use CDRs for audit and reconciliation.

2026-11-06 · FlySip engineering · All guides

A call detail record, or CDR, is the line your SIP server writes when a call ends. It is the difference between 'the phone rang' and 'we can prove what happened, when, for how long, and who hung up'.

CDRs are not standardised field-for-field. RFC 3261 defines the SIP messages, but each server chooses its own schema for the record it stores. The fields below are common across implementations; treat exact names as vendor-specific and confirm them in your server's documentation.

Common fields you will find

Most SIP servers store a core set of attributes per call. The names vary, but the meaning is consistent enough to read any vendor's export.

Typical fields include a call identifier, the calling and called party, the start and end timestamps, the call duration, the direction (inbound or outbound relative to the server), the termination reason, and the involved device or trunk. Some servers also record the codec and the RTP statistics.

Common field	What it tells you
Call ID / unique id	Correlates all SIP messages of one call
From / To	Calling and called party identifiers
Start / End time	When the call began and ended (UTC or local)
Duration	Connected seconds, not including ring
Direction	Inbound, outbound or internal to the server
Termination cause	Who ended it and the SIP reason

Field names differ by vendor. Map your server's schema to this list before building reports.

Reading direction and duration

Direction is always relative to the server writing the record. An 'inbound' call arrived at the server from an external trunk; an 'outbound' call left through one. Internal calls between two registered extensions are usually tagged separately, and mixing them into a trunk report double-counts.

Duration should mean connected media time, not the time from first INVITE to BYE. A call that rang for two minutes and was never answered has a duration near zero. If your report shows long 'calls' with no audio, you are likely counting ring time, not connected time.

Hang-up cause and who ended the call

The termination cause is the most useful field for troubleshooting. A normal call ends with a BYE from one side; the CDR should record which side sent it. Abnormal ends carry SIP response codes in the record: 486 Busy Here, 480 Temporarily Unavailable, 503 Service Unavailable, or a 4xx/5xx from the far end.

Reading the cause in bulk shows patterns a single ticket hides. If a whole floor shows 480 every morning, the cause is a power or network event, not individual handsets. If one extension shows 486 repeatedly, look at that device's call handling, not the server.

BYE from caller — normal user hang-up.
486 Busy Here — callee busy or DND active.
480 Temporarily Unavailable — callee offline or unreachable.
503 Service Unavailable — server or trunk side failure.

Export, retention and audit reconciliation

CDRs are only useful if you can get them out and keep them long enough. Most servers export to a file, a database table, or a syslog stream. Decide the export path before you need it, because a server with no export configured loses the data on rebuild.

Retention is a policy, not a default you can assume. Determine how many days or months you must keep records for the building or site's audit requirement, and set rotation so the store does not fill the disk. A full CDR store can stop the server from writing new records, which looks like a call-processing fault.

For reconciliation, match CDRs against the expected call plan: every door-release call should appear, every after-hours call should be explainable. Discrepancies between the call plan and the records are how misconfigured routing or unauthorised use gets caught.

Surviving a power loss

A call in progress when power fails simply ends; there is no graceful BYE, and the CDR may be incomplete or missing for that one call. Servers handle this differently, and the behaviour is worth confirming in your product's documentation rather than assumed.

What you can rely on is the design intent: a server that writes records to stable storage (not a volatile ramdisk) recovers its store on reboot, and completed calls before the outage remain intact. For sites where the call log is part of a safety or compliance record, pair the server with protected power so the outage window is minimised. The product page states capacity and reliability figures; ask for the test conditions before quoting them.

Remember: a CDR proves what happened after the fact. It does not make the call succeed. Treat missing records as a storage or power question, and missing audio as a media-path question.

Frequently asked questions

What is a SIP CDR?: A call detail record is the entry a SIP server writes when a call ends. It records who called whom, when, for how long, in which direction, and how the call terminated. Exact field names vary by vendor.
Are CDR fields standardised?: No. RFC 3261 standardises the SIP messages, but each server chooses its own record schema. The fields described here are common across implementations; confirm exact names in your server documentation.
What does duration mean in a CDR?: Usually the connected media time, not the ring time. A call that rang but was never answered has a duration near zero. Check your server's definition before reporting on it.
How do I tell who hung up?: Read the termination cause field. A normal end shows a BYE from one side; abnormal ends carry SIP codes such as 486 Busy Here, 480 Temporarily Unavailable, or 503 Service Unavailable.
What happens to CDRs if power fails mid-call?: The call ends without a graceful BYE and that record may be incomplete. Servers differ here; confirm the behaviour in the documentation. Records written before the outage to stable storage normally survive a reboot.
Can CDRs show echo or noise problems?: No. CDRs record signalling and call metadata, not audio quality. Acoustic echo and background noise are handled by the sister products FlyAec and FlyDenoise, not by the SIP server or its records.

CDRs are only meaningful when calls actually connect and route. For routing behaviour read ring groups and call routing, and for the faults that prevent a call from starting see SIP registration troubleshooting. Browse all SIP guides or the FlySip product overview.