No doubt most people working with CDRs have felt that the Userfield is grossly inadequate to encode all of the details they would like to have. The problem is, how do you create a generic CDR engine that will satisfy different people on different systems with completely different needs?

The answer, in my mind, is to bring Mohammed to the mountain, instead of the mountain to Mohammed. Instead of trying to create a single static CDR engine that contains every possible field that anyone could ever want (which is damn near impossible), I am working on an engine which will dynamically query the underlying CDR table for its structure and then populate that table based upon the present fields along with the present CDR variables.

While the implementation is far from complete, you're welcome to monitor progress in this branch at /asterisk/team/tilghman/cdr_custom_odbc/. Testers will be needed in the near future. Once complete, it is possible that we will see a backport of this CDR engine to 1.4 and 1.2, similar to the backport of func_odbc to 1.2.

The functionality is now complete, and the code may be found in trunk at cdr/cdr_adaptive_odbc.c. As of the current date (May 2007), the module can be ported as-is to 1.4 and it will work perfectly. In time, we may create a backport for 1.4, if trunk changes significantly. It is unlikely at this time that a backport will exist for 1.2, unless I get significant demand for it.