[Home]

Summary:ASTERISK-03356: [patch] API for vendor-specified CDR fields
Reporter:Tilghman Lesher (tilghman)Labels:
Date Opened:2005-01-26 12:10:52.000-0600Date Closed:2011-06-07 14:04:56
Priority:MajorRegression?No
Status:Closed/CompleteComponents:CDR/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 20050126__cdr_extensions.diff.txt
Description:Rather than hacking cdr.h and cdr.c to include specific fields, or worse, allowing cdr_whatever.c to look up a channel and read the channel variables (forbidden by Mark), I have created an extensible way for vendor-specific CDR fields to be added and maintained, by allowing vendor-specific updates to occur, when ast_cdr_update() is called.

****** ADDITIONAL INFORMATION ******

While the CDRUserField could be used in this capacity, it is not optimal, given that certain vendor fields could change during a call, the limited length of the UserField, and the possible conflicts between field contents and delimiters.

The main reason for having vendor-specific CDRs is for billing systems whose APIs do not conform to Asterisk CDRs (for example, some vendors use stored procedures to post CDRs with lots of extra fields describing rate and route information).

Disclaimer on file.
Comments:By: Tilghman Lesher (tilghman) 2005-01-26 22:36:47.000-0600

It occurs to me that should probably post an example application; unfortunately, those that I have are covered under confidentiality agreements.  I'll look at possibly abstracting out a non-trivial case that doesn't violate our agreements.
By: Mark Spencer (markster) 2005-01-26 23:17:06.000-0600

I would also encourage you to double check your VENDOR_CDR_* macros, I believe there may be a mistake at least in the first one.  You can also build "function" macros (see astobj.h, kpflemings handiwork) to avoid the flag parameter in copyvar.  

I'm also a little bit concerned about the "vendor fields" being tied in the with the CDR engine.  

I'm not really sure what the best way is to handle this (clearly the constant adding of new fields isn't very effective), but let me make a suggestion at least to prime the pump:

That seems to defeat the purpose of abstracting CDR's at all since you would get different information in CDR's stored with different back ends.  I wonder if it would be more helpful to have an ast_variable list?  If so, we could potentially store special variables there (e.g. __CDR_*) when they are set in the dialplan and then the cdr engines could simply include them, kind of a more powerful version of userfield.  

What do you think?
By: Tilghman Lesher (tilghman) 2005-01-27 11:02:06.000-0600

markster: Using the variable structures doesn't seem to be a bad idea, but I think we need to be able to differentiate between different fields set by different vendors.  For example, if you were transitioning between billing systems on a production system, you might be logging CDRs into two different systems, where you might have name conflicts.  Or you might have CDRs into two different systems for billing two different types of calls (for example, a single system with multiple companies).  There are always field names that naturally would occur on both systems, introducing a possible conflict (e.g. account, route, quantity, rate, rate_cost, sales_rep).

I'll take a look at the macros again to see what might be the problem.  It might be the macros are specific to one particular vendor and don't need to be in cdr.h.

casper:  I would encourage you to file a separate bug with your suggestion.  It is not related to this feature.
By: Tilghman Lesher (tilghman) 2005-02-15 23:59:53.000-0600

See ASTERISK-3515