[asterisk-dev] [Code Review] This patch implements CEL in trunk.
murf at digium.com
Mon Jan 26 22:49:10 CST 2009
This is an automatically generated e-mail. To reply, visit:
(Updated 2009-01-26 22:49:10.490555)
Review request for Asterisk Developers.
Updates from Russell's last review.
CEL stands for Channel Event Logging.
(It's big, so brace yourself!)
It's like the Manager interface, but a little
more specialized to report events that would
be used to form CDRs or call activity logs.
It logs to a set of backends much like CDR's
do. Higher performance event loggers can be
written on the CEL base, that would provide
better thruput for generating higher-level
event-based logging, like CDR's.
It's based in turn on Russell's event facility,
and expands on its base, and shares in its
advantages. For instance, the
ast_event_subscribe() func has been modified
to accept a "name" argument for the subscription,
for CLI viewing.
It also introduces a new channel field, the
'linkedid' field, that has 'viral' properties;
when two channels interact, the oldest linkedid
value of the two will override the younger. The
linkedID field starts being set to the uniqueID
field. All the channel drivers 'new' routines will
also now accept a linkedid argument, in the
which, if provided, will override the linkedid
field. This would happen, for instance, in the
Dial() app, when a peer channel is created
for the purpose of a call. From it's creation,
that peer channel will have the same linkedid
as the calling channel.
The linkedid field will be generated (by default)
on all CEL logged events, and can be used to tie
multi-legged calls and perhaps even call trees
formed by 3-ways and transfers.
Brian Degenhardt of SwitchVox formed a snazzy
real-time call logging facility using the CEL
text logging backends.
Analogs to the CDR backends were formed for
CEL event logging. It's been a while since they
were originally formed, and they may profit
from an overhaul to re-derive them from the
CDR backends. The TDS backend has been
recently re-derived, as the old version no
longer compiles against the newer TDS libs.
The odbc_adaptive interface has not been
adapted for CEL, but this is always an option
for the future.
hangupsource is also now being recorded into
a channel field by that name.
A long and perhaps tedious design doc about
CEL is in doc/cel-doc.tex
I added 'peeraccount', and 'linkedid' to the
existing CDR code; these may be useful to
folks who want to continue arranging deck chairs
on the CDR Titanic.
Peeraccount: when two channels are bridged,
they each update their peeraccount field with
the accountcode of their partner in their
respective 'peeraccount' channel fields.
The CDR field is updated, and a new manager
event is generated. The peeraccount info
is reported in CEL events.
Although reviewers may have issues of their own,
my major questions are these:
1. Should I just eliminate the cel-csv interface,
and let everyone use the cel-custom interface if
they want text logging?
2. Should I bring in the odbc-adaptive stuff?
3. Should I re-derive all the backends from
the cdr backends as they exist today?
4. Are the current tracked events sufficient
for CDR generation which I'm specifying
now in team/murf/RFCs?
bmd has built a reporting system using it; I have run
several simple tests to ensure updating with merges
hasn't broken it, and made appropriate fixes.
More information about the asterisk-dev