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

[Tzafrir Cohen]

On Tue, Jul 03, 2007 at 12:53:06PM -0600, Steve Murphy wrote:
> On Tue, 2007-07-03 at 08:12 +0300, Tzafrir Cohen wrote:
> > 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?
> > 
> 
> A good question. For example, when cdr_custom was introduced, we could
> have marked cdr_csv as deprecated, and removed it, say in 1.4 or
> something. But we didn't. But we still can. I could see having both for
> a time, as those using
> cdr_csv need not change anything; If/when it disappears, they'll have to
> define 
> a cdr_custom, and the dir in which they find their CDR records will
> change.
> 
> It's more a matter of actively defining the migration path, than of
> active duplication. We've just chosen the 'easy' path for now.

Why not just add capabilities to the existing module? Why add a separate
module? 

(The result was that CDR was logged by default to both, IIRC, or some
ugly warnings)

> 
> It's more a matter of actively defining the migration path, than of
> active duplication. We've just chosen the 'easy' path for now.

Is it the easy migration path? Suddenly an extra configuration file with
a strange name was introduced. "custom" and "adaptive" don't really
describe the CDR recording itself. You will eventually need to get rid
of the name. 

A different and better example: The name "iax*2*" is sadly still here, 
but the config file is called "iax.ocnf" and not the strange "iax2.conf".

And of course: are bugs fixed in both? 

> 
> We could easily upgrade all the existing back ends (where 'easily' is a
> matter of relativity), and mark all the existing backends as deprecated,
> and remove them in a release or two.

(What I wrote is irrespective to the question of whether this should be
changed in the CDR core or in the backends, about which I really can't
add anything useful)

-- 
               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