[asterisk-users] Simple CDRs

[Steve Murphy]

On Fri, 2009-01-09 at 01:53 +0000, Grey Man wrote:

> I would be interested in additional information in the CDRs as I'm
> sure others would. My worry is it's not a critical peice of CDR
> information and because it sounds like information being generated at
> the dialplan level it could end up being complicated to implement or
> confusing to desgin and become a distraction from getting the core CDR
> fields sorted out.


I tend to agree. We were discussing this sort of thing on IRC today,
some
of us devs, trying to guess what new things users might throw at us as
to
requirements for the new CDR system(s). I have a feeling that there will
ALWAYS be implementers that will have a need for very... interesting
pieces
of information, and will want to see them in the CDR system.

But, there is a "userfield", and users can set it in the dialplan.
As long as funcs like CHANNEL() can get at the info you'd like to have,
then you can always shove that info into the userfield. If CHANNEL()
doesn't make a field available, it can easily be expanded.

(At the current moment, CEL doesn't carry channel vars into the event
data; it seems a pretty wasteful business; perhaps in the future, I
can make it so any channel vars starting with "cel-" would be
copied into the event data. In the meantime, copy what info you
need into the userfield.)

Another customization need would be where CDR's would be split-- 
what kind of things you want to time.
The Simple CDR spec really wouldn't allow any splitting, but the leg
based CDR approach would provide a simple call in the dialplan to 
split a cdr and assign a type to the newly completed CDR. I honestly
can't think of any other operations that might need to be done, except
attach extra info to a generated CDR; the only question would be
when it would be best to attach it; and that's something we have to 
think about. Before a dial, so the dial event/answer event records
it, or just before the channel closes (h exten?) or whatever...

In the case of CDR-legs, the timing of when you store info on the
channel, determines which leg(s) the info appears on. There are
possibly a lot of games that could be played with this. There are/were
a few bugs in the tracker that basically were complaining about
missing information. In most cases, this was due to the fact that
there were two place where data was being stored: on the channel, 
and in the CDR struct. And there is/was no simple explanation
of when the channel information was updated into the CDR struct(s).
Well, the new system will have simple rules to allow you to predict
when certain info on the channel will be taken to be copied
into a CDR. (I hope).

Another side-effect of moving the CDR system out of the pbx loop
is the fact that the h-exten may or not be the best place to try
to add/mod CDR related data any more. I could go on (and on) about
the h-exten, (for those of you wondering what the h-exten is, 
it's the hangup extension in the dialplan; the pbx will execute
that extension when the channel is being hung up.)... but I won't.

Just my thoughts on the fine points of the to-be-developed 
new CDR system...

murf



-- 
Steve Murphy <murf at digium.com>
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20090108/b2107f46/attachment.bin