Subject: [asterisk-dev] The Trouble with CDR's...!

Jonathan k. Creasy jonathan at bluegrass.net
Tue Dec 19 06:42:49 MST 2006


> -----Original Message-----
> From: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-
> bounces at lists.digium.com] On Behalf Of Freddi Hansen
> Sent: Tuesday, December 19, 2006 3:11 AM
> To: asterisk-dev at lists.digium.com
> Subject: Subject: [asterisk-dev] The Trouble with CDR's...!
> 
> 
> To He/She Who Cares about CDR's in Asterisk:
> > Now is the time to review CDR problems, and complaints; that is, if
you
> > want them fixed. If you like your problems to stay that way, you can
> > stop reading this now...
> Hi,
> I have 2 things that we always have do make 'workarounds' for when it
> comes to CDR's
> 1. is the old issue with no serverindentifier  or hostname so be
careful
> when mixing CDR's from different servers in the same  backend DB. Our
> workaround today is to add hostname via  cdr-userfield.
> 2. We are missing a 'forward link' when processing multiple cdr's from
> the same call. Trying to match 'destination channel name' won't work
> when you, as in our case, processes 150k+ cdr's per day.
> It would be nice to have a 'UniqueId2'  field that keeps the ID of the
> new CDR created with e.g. ForkCDR. It would be a generic way to allow
> creation of multiple CDR's from a single call. The manager interface
> also uses this join to identities (channels).
> I know that I can though not easy/clean 'just take the new id and add
it
> to the userfield  of the old cdr' in  cases like  ForkCDR. The problem
> is when the core itself start to create multiple CDR's from a single
> call.  The 'UniqueId2' field would be like a linked list that could be
> used to retrive all cdr's related to a single call.
>  I know this  is probably not  going to be accepted since it adds a
> field to the CDR, but that's my 2 cents.
> 
> Steve,
> sorry for the noise if you feel this is to much 'off-thread'
> 
> Freddi
> 

I would like to see the ability to have more user fields. Userfield1,
Userfield2, Userfieldn, etc. 

Possibly be able to define a field in the table and use it in the
dialplan like the user field. In the example above he would create a
field called "ServerID" and then in the dialplan he could reference
CDR(ServerID) and it would know since that was not a defined CDR field
it must go with the field that has that name in the table, if no such
field exists then just ignore it. 

-Jonathan


More information about the asterisk-dev mailing list