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

[Steve Murphy]

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.

This kind of approach appears to me to the best. With only a small
effort, you can store away whatever fields you want, and in the CDR
mappings, use those vals to override CDR fields that aren't what you are
wanting.

So, those of you using ODBC capable db's like mysql, etc. can get around
any fancy CDR dances you've invented by switching to the adaptive_odbc
backend, and playing with the mappings.  The real challenge will be
providing equivalent functionality in all the other CDR backends that
odbc can't cover. Whatever they might be. (With the name of Murphy, I
can't even hope to hope that ODBC interfaces exist for all the DB
backends!)

In this kind of scenario, all I have to do is try to make the CDR's that
are now generated just generate "correct" values. If that means that
some billing interfaces need tweeking, so be it. The dialplan/billing
interface designer needs to use the dialplan to store the fields they
need into some variable name on the CDR, and then map them into the
right spots into the CDR backend DB.

Am I picturing this correctly? If I am, I'll try to make this vision of
CDR's come true... Let's write the "CDR Bible", and explain the
philosophies, show a few examples, and let the developers do their
thing(s).

murf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3239 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20070702/33047464/attachment.bin