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 <m...@digium.com> Digium
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users