[Asterisk-Dev] dev conf topic: better CDRs

[James Middleton]

This actually sounds more like a CTI application then CDR. If going down
that road, it would probably be beneficial if the data structure match the
capabilities of TSAPI or JTAPI so that an actual CTI interface could be
easily incorporated.

Since this also seems like a number cruncher, I would suggest that it be
structured as an API with the actual data offloaded to a separate server
where data mining and archival storage will not impact the processing
capacity of the PBX. Additionally, it would also open up the door to third
party applications.

Of course, I'm assuming that call control would be the long term goal and
not just call reporting.

Is there anyone else currently working any type of CTI interface that would
include event notifications for call processing?

James Middleton


-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com]On Behalf Of Asterisk
Sent: Thursday, February 24, 2005 10:02 AM
To: Asterisk Developers Mailing List
Subject: Re: [Asterisk-Dev] dev conf topic: better CDRs


We are interested :)

This is exactly what we're trying to do at the moment - would you be
able to strcture it so that by default it behaves like the standard CDR
(so doesn't break any code) but set a flag to turn on the advanced
behaviour for us bleeding edge folks ?

Julian

Kevin P. Fleming wrote:
> C. Maj wrote:
>
>> Does it rely on parsing the manager "Newexten" events ?  It
>> seems like this would be a route that can co-exist with the
>> current CDR system.  I think those events spit out Unique
>> IDs with everything.
>
>
> No, this is an entirely different CDR system, with hooks all over
> everywhere inside Asterisk. Essentially, I won't be happy until my CDR
> database records every detail of everything I did with the call while it
> was in my possession :-) That does not work by just adding lots and lots
> of fields, it requires a multi-level structure.
>
> Unlike ForkCDR(), this will be inherent in the pbx/modules/apps, not
> requiring the dialplan to create new records every time something
> occurs. It will also be more light weight (the secondary records are
> much smaller), and the secondary records will be identified so that they
> can be kept in order (since relying on timestamps is not adequate when
> many of them could be generated in a very short period of time).
>
> I don't expect many people will be interested in such a radical change,
> but I don't feel I can operate my system without being able to track
> everything that's happening. I may never need 99% of the data, but when
> I do, if I didn't record it when the call happened it's gone forever.
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>

_______________________________________________
Asterisk-Dev mailing list
Asterisk-Dev at lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev