[Asterisk-Dev] dev conf topic: better CDRs

[James Middleton]

I guess it is in part a symantics issue here. To me, CDR when applied to
billing doesn't usually care if the customer entered dtmf tones in response
to a prompt for routing, or if someone conferences another extension onto a
call or if the caller heard music-on-hold or an announcement. The monitoring
of individual communication events has traditionally fallen within the realm
of CTI applications. CDR is usually more restricted in information
presentation.

The second part is the impact of the additional CDR functionality on
processing. If you code it and run it, it takes up cycles. Additionally, how
much data will be retained on the * server. If you record every event (ie
ring station, answer, hold, conference, dtmf tones, transfer, etc..) and
have to hold that data then it is going to require memory, hard drive space,
or both.

Let's say I do want to push the CDR data off to another server (I certainly
don't want to do data mining on my live PBX across 5 years of data - don't
forget Sarbanes-Oxley). If the link drops (ie second server with CDR
application crashes or is taken off line for maintenance) then I need to
buffer the data to prevent loss. How much data will be buffered, and when do
I start to drop records. One hour, two hours, 3 Meg, 3 Gig, 300 records, or
30,000 records. For me, if I never had to store data life would be so much
simpler.

Maybe I've over complicated things. Maybe it's just two parts to the same
puzzle. I just think that looking from a long term perspective of where the
architecture is going requires that these questions at least be raised.

Another thing to think about is the unique ID. I would suggest that the *
server have a variable that assigns a unique ID to the specific server that
would be included in the ID. This would permit the passing of ID's between
multiple servers while at the same time being able to uniquely identify the
call within the network. This allows the passing of sreen pops, and global
tracking of the call. This should be at least a six byte identifier. Why six
bytes? Again, from a long term perspective, using a variable this size would
allow a universal database of PBX's. This allows an oppportunity for B2B
connectivity with the passing of calls between systems and tracking of call
origination. This can be passed within the IE of an ISDN call.

James Middleton

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


Chris Wade wrote:

> You're talking the Asterisk Manager at this point.  It already does what
> your talking about.  Kevin is talking about a revised CDR for POST
> processing the call flow, call control already exists in the manager.
> More detailed CDR's like Kevin is going after would allow better(more
> accurate) billing and call accounting without having to increase the
> load on the manager/manager proxy.  Anyway, just my $0.02.

Couldn't have said it better myself :-) I won't allow what I'm working
on to have a negative impact on call processing, that's for darn sure!
_______________________________________________
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