Brian Degenhardt from Digium has posted information on the new CDR type logging that is being created. This will make a significant difference but will be available at the same time as CDR:

Murf and I have been working on a new branch that provides an alternate method for logging calls called Channel Event Logging or CEL. Despite naming the branch 'newcdr', this will not replace CDRs, but add an additional mechanism. Part of the need for this work grew from the disjoint between the fancy event-based logging capabilities of Switchvox, and the limitations of traditional CDRs. This branch is our attempt to satisfy the existing needs of Switchvox in a way that's usable to the community as a whole.

The main feature of Switchvox's logging is how it logs each event that occurs in the call. Here's a screenshot illustrating this, which shows each extension the system hits, a directed pickup event, and an assisted transfer.

By logging calls like this, we accomplish two goals that are sometimes challenging to do with just CDRs: First, we can accurately track each participant who was on a call. For example, the call in the screenshot above will show up in Switchvox when you search for calls that hit extension 800, even though it was just a transient IVR. The second thing this allows us to do is represent accurate call counts. Even though the above call passed through 4 different extensions, it's still just one call.

So that's the requirements for the CEL branch: a general purpose logging system that is able to carry on the existing Switchvox features. Let me talk specifically about the individual pieces, and why they were done:

First, CEL is based on asterisk's new event system. Each CEL backend just subscribes to the AST_EVENT_CEL and then acts on those events by putting them in the database or writing out to a log file. Asterisk's event subsystem is designed to work across the network, so a future direction is definitely to combine CEL events from multiple distributed systems in some manner.

Each event looks very much like an asterisk manager event. If you've ever tried to write code that tries to track calls based on manager events, you might know how tricky it is tracking channel name changes and transfers. To make this easier, murf has created a variable called linkedid, which is simply the oldest uniqueid of any channel involved in the call. By tracking linkedid, it's very easy to know which events belong to which logical call. To identify the end of the call, there is a CEL_LINKEDID_END event which signifies the hangup of the last channel with a given linkedid.

We've also extended the behavoir of a channel's accountcode. We've tied accountcode much more tightly to the channel it's set on, and added the CHANNEL(peeraccount) variable, which identifies the accountcode of the person you're talking to. While this slightly changes the existing behavior of accountcode, I'm confident that it won't affect anyone's real-world usage. On the upside, it's now much easier to figure out which account is involved in calls that go through many transfers, parks, unparks, and bridges.

The final change in the newcdr branch is the addition of CHANNEL(hangupsource) which allows asterisk to log which channel or action was responsible for a hangup. For example, if you're on a SIP call that suddenly ends, CHANNEL(hangupsource) will contain the channel name that issued the SIP BYE. If your dialplan executes Hangup(), CHANNEL(hangupsource) will be set to "dialplan/app". Check out the last event on the screenshot above to see this in action.

If these things sound interesting to you, I'd love to get any feedback at all. Here's the location of the branch:

http://svn.digium.com/svn/asterisk/team/group/newcdr

cheers
-bmd

Comments (Click to post)

Name:
Subject:
Website:
Message: