[asterisk-dev] Violent Objections? CDR dst/dcontext probs in 1.4+ when a macro is involved.

[Tzafrir Cohen]

On Mon, Jul 02, 2007 at 10:41:46PM -0600, Steve Murphy wrote:
> On Fri, 2007-06-29 at 07:30 -0500, Tilghman Lesher wrote:
> > On Friday 29 June 2007, Benny Amorsen wrote:
> > > >>>>> "TL" == Tilghman Lesher <tilghman at mail.jeffandtilghman.com> writes:
> > >
> > > TL> Nothing is preventing you from creating another CDR variable (and
> > > TL> logging it) called Destination.
> > >
> > > You cannot tell the database backend to include special fields in
> > > CDR's. Very inconvenient.
> > >
> > > I have a similar problem in this setup:
> > >
> > > [outgoing-sipprovider]
> > >  exten => _X,1,Set(CALLERID(num)=00${CALLERID(num)})
> > >  exten => _X,n,Dial(00${EXTEN}@sipprovider
> > >
> > > I want to log everything in E.264-format -- a US call would look like
> > > this: source 11235556666, destination 11235557777. The sip provider
> > > wants it like this: source 0011235556666, 0011235555777. If I could
> > > manipulate the CDR variables directly, it would be relatively easy to
> > > fix.
> > 
> > http://svn.digium.com/view/asterisk/trunk/cdr/cdr_adaptive_odbc.c
> > 
> > This module allows you to use custom fields, now.  It is compatible with
> > 1.4, and if trunk is changed such that it is no longer compatible with 1.4,
> > I will create a branch in svncommunity that will house cdr_adaptive_odbc
> > for 1.4 (as a backport).  Due to architectural limitations, this module cannot
> > be backported to 1.2.
> > 
> 
> Tilghman made some excellent points. One of the major ones is that EVEN
> IF I
> ALLOW users to CHANGE CDR fields from the dialplan, it is hard to
> predict what events might override the user's settings. Asterisk has a
> ton of places that 
> tweak CDR's, and in interesting ways.  So, even with the restrictions
> removed
> from the CDR() func, you still might end up frustrated and confused. 
> 
> His suggestion to use customizable backends like cdr_adaptive_odbc is an
> excellent suggestion. It gives the user complete "final" control, no
> experiments needed, no goto (or other non-obvious) hacks to get the
> fields the way you want them. Correct me if I'm wrong, but it looks like
> you could pack data into a
> seperate column, and then replace any CDR field with the contents of
> that column.

But then you would need to duplicate every backend.

Then again, what was the real point in the duplication of cdr_csv and
cdr_custom ? I think people usually ended up using cdr_custom.

What is the point for this code duplication?

-- 
               Tzafrir Cohen       
icq#16849755                    jabber:tzafrir at jabber.org
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com       
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir