« Back to all articles

These aren’t the CDRs you’re looking for

Written by Luit van Drongelen on 11th March 2015

• Asterisk
• CDRs

Our telephony platform VoIPGRID is built on open source software. At its core, it has Asterisk doing most of the heavy lifting. Until recently, we tracked call activity using the Call Detail Records that Asterisk creates. We’ve now completely stopped using them.

Call Detail Records or CDRs are records describing call activity handled by a telephony system. Our CDRs used to be generated based on Asterisk’s CDRs. Asterisk’s CDRs in turn are based on Asterisk internal state, and this is where the trouble begins. Let’s begin with an overview of what Asterisk does.

Channels and Bridges

Asterisk internally works with channels and bridges. Channels are streams of data between Asterisk and a remote party (e.g. through a SIP channel) or with itself, called a Local channel. A bridge is when two channels are connected end to end. External channels have one end, Local channels have two ends called semi-channels.

The basis of a call is a channel calling in, in two main ways. One is when a SIP account calls in, for example when someone dials a number on his desk phone. The other is when someone on the telephony network calls a number we handle, and reaches us through our upstream provider. In Asterisk the channel created that way is called a master channel. While handling master channels, Asterisk will run through its dial-plan and figure out what other channels to open to serve this call.

The problem with CDR

With this knowledge, let’s come back to Call Detail Records. In it’s CDRs, Asterisk describes a pair of channels being linked for a certain duration. Asterisk assumes a bridge is the same as a call. That’s a fair assumption, because most simple calls are handled that way. For example, a call comes in from the telephony network (master channel), we find an account to deliver it to, and deliver it by bridging the master channel to it. Or an account dials a number (master channel), and we find the route to reach that number, bridging it to the master channel.

So what happens when calls are being transferred? Or when a call is handled by something other than a bridge, like voicemail or an IVR system? Being a telephony platform targeted at small and medium-sized enterprises, for us those situations are actually quite common. We have to work around the fact that the bridge-based approach discards some data we want to have, or mangles data in a way we have to revert.

The transformation from Asterisk CDR to VoIPGRID CDR was quite an involved process. Even then, some of the data was incorrect or absent. Attempts to fix these problems in this CDR parser often caused more problems than they solved.

To fix this problem, we needed more control. The data we needed was in a different place. Something that’s built around channels instead of bridges.

CEL

Asterisk has something called the Channel Event Log. It describes the series of events that happen to the channels Asterisk handles. This channel-based approach seemed to be a much better fit to handling our call registration.

Based on this Channel Event Log, we developed the new call registration and billing systems deprecating the CDR based infrastructure since January 1st this year.

My next article will explain how we started using the Channel Event Log.