[asterisk-dev] Channel Event Logging (CEL) design goals and changes

[Brian Degenhardt]

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:

http://www.switchvox.com/misc/cdr.jpg

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:
https://origsvn.digium.com/svn/asterisk/team/group/newcdr

cheers
-bmd