Page tree
Skip to end of metadata
Go to start of metadata


Call Detail Records are the data recorded during each call session. A CDR may contain attributes specific to each call session and eventually each leg of the call.

CDR contain the phone numbers originating the call and receiving the call, time of the call, call duration and many more attributes.

CDR Examples

An example of FreeSWITCH CDRs stored in /usr/local/freeswitch/log/cdr-csv/Master.csv

Sample CSV CDR  Expand source

An example of detailed XML CDR stored in /usr/local/freeswitch/log/xml_cdr/a_80183ec8-d424-11e3-8fb2-65b6c3cdac7d.cdr.xml

Sample XML CDR  Expand source

Store CDR

There are several ways which FreeSWITCH can save CDR (Call Detail Record).

The best way to store "live" call detail records is to write all the data fields to a temporary area on disk or RAM drive and write a script to scan that same area of the file system for the long-running processing of storing them in your database. This avoids hanging the voice call thread in FS if the http or db server is down at the end of the calls.

DO NOT write CDR scripts in the hangup hook of your dialplan or ESL script as this will delay the termination of the voice thread and will not scale to large systems. Allow the voice thread to handle only voice; handle your back-end business processes separately, off-line. This approach works for all installations from small to huge.


Popular ways include:

  • mod_cdr_csv - saves a CSV file with the variables you specify in a template.
  • mod_cdr_mongodb - saves detailed CDR data to a MongoDB database, in a format similar to mod_json_cdr.
  • mod_odbc_cdr - saves any channel variable from call to your choice of ODBC database.
  • mod_cdr_pg_csv - Asterisk Compatible CDR Module with PostgreSQL interface.
  • mod_cdr_sqlite - saves directly to an sqlite DB with the variables you specify in a template.
  • mod_json_cdr - Saves to file or POSTs a JSON representation of the channel variable and callflow. It can post directly to CouchDB.
  • mod_xml_cdr - Saves to file or POSTs an XML representation of the channel variable and callflow.
  • mod_radius_cdr - RADIUS CDR Module.

CDR Handling

You can instruct FreeSWITCH to not log a call, or only log leg B or the like. See: Variable_process_cdr

You can also specify hangup causes that should not generate a CDR. See Variable_skip_cdr_causes (added V1.2.3 3cf238fc)

Calculating Various Time Values For A Call

FreeSWITCH CDRs contain lots of information. From those values one can extract other information:

What time a call started ringing (PDD)

When a call starts ringing it either has media or does not have media. If it has media then progress_media_time will be set; if not, progress_time will be set. The value not set will be zero. Therefore this formula will always yield the exact time the call started to ring:

Calculating Ring Start

The PDD (post-dial delay) is the period of silence between the call starting and the call ringing, therefore for calls that ring:

Post-Dial Delay

How long was the talk time

If the call was answered then there is a talk time. If call was unanswered then answered_time will be 0. If answered_time is greater than zero:

Calculating Call Duration

How long did the phone ring

How long the phone rang is determined either by the hangup_time or the answered_time:

Calculating Ring Duration

How long was the call on hold

As of September 13th, 2012, FreeSWITCH also provides the hold_events field. This field is structured as a flattened, multi-dimensional array of uepoch values representing the start and stop time of hold events for the channel. For example: {{1347907323618493,1347907328495937},{1347907309458486,1347907314655415},{1347907298602214,1347907304095908},{1347907285118780,1347907291355494}}

It is structured in native PostgreSQL array text format so it is very easy to work with in PostgreSQL. Here is an example showing how to work with such a field in PostgreSQL:

Calculating Hold Time

The "WITH" clause converts the multi-dimensional array into a set of row result records with two columns: start_time and stop_time. The "SELECT" clause below the "WITH" clause converts the resulting micro-second Epoch timestamps into TIMESTAMP WITH TIME ZONE types and returns the resulting set of rows. The FOR loop assigns each row in turn to the RECORD variable "tmp," which is used in the RAISE NOTICE line to print out the resulting values. This allows you to treat the hold_events field as a TEXT type in the database and convert it into a record-based result-set on demand anywhere you need to iterate through the hold records.

Putting Together CDRs

If you are saving both A and B leg for CDRs, you'll need to piece them together.

1) The self-uuid is stored in "uuid"

 2) A-legs - it's an A-leg if:

  • "originatee" or "origination" or "originate_disposition" is set. (NOTE: The original channel that triggered a loopback shows up as B leg in xml_cdr)

3) B-legs - it's a B-leg if:

  • "ent_originate_aleg_uuid" is set. "ent_originate_aleg_uuid" contains the UUID of the A leg.
  • "originator" or "originating_leg_uuid" is set. Both contain the UUID of the A leg.

4) What's the connecting leg?

  • For enterprise originates: on B-leg, use ent_originate_aleg_uuid.
  • "bridge_uuid" (not in bypass mode)
  • "signal_bond"
  • "last_bridge_to"
  • In B-leg: originator or originating_leg_uuid
  • In A-leg: Parse originated_legs or originate_causes (added 2012-10-18, commit 3099445a95933a52954c64d5f2fd314a55577c9d)