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

[Tilghman Lesher]

On Thursday 28 June 2007 15:08, Steve Murphy wrote:
> I've noticed that Asterisk is itself open source software, so I
> really don't understand the concept of "protected" fields in CDR's.
> If the end user/developer wants to change the value of the dst field,
> he can always change the source... there is no real concept of
> "protection" of CDR fields, therefore.

You also have to ask what are we protecting the fields from?  In this
case, I think we are really protecting the user from being confused
about what fields will be overwritten during the normal dialplan
progression.

The most common case for CDRs is the user who does not fiddle with
the CDR at all and expects CDR information to be useful after the fact.
That speaks to continuing to automatically populate the CDRs with the
standard variables.  That means that CDR variables which will otherwise
be overwritten automatically should not be user-settable.

> There indeed are several "true" values for several of the fields, but
> any one of them may be of limited use to end users/developers. In the
> case of dst, it could be the context of the called macro, or the
> value of the exten in the calling exten. They are both true. But some
> users want to see the "s", "macroname", and others need the
> "7089237", "default" or whatever, that would call the macro.
> Right now, asterisk chooses the easiest, arbitrarily.

I think people have arbitrarily assigned meaning to various CDR
variables, whether they merit such meaning or not.  In this case, the
dst variable is currently no more and no less than the final extension
which executed in the dialplan.  I have intentionally used the words
'reflect' and 'mirror' in previous messages, because these fields are
exact copies of those bits of channel information.

> The current system makes it a royal pain to get the CDR's to look
> like you need it to look. While a Goto would most likely work as you
> suggest, it destroys the value of calling the Macro in the first
> place. It's kind of arbitrary that asterisk updates the CDR when the
> Goto is called, but not for every exten/priority. So, you might not
> actually get the "truth" anyway, in various circumstances. Using Goto
> to change CDR values is a pretty bad kludge, if you ask me, but
> people are using it to get the job done. Rather messy, isn't it?

What that speaks to, though, is the necessity of users to create their
own variables which correctly model the information they need to see
in the CDR, not to repurpose the standard variables.  The philosophy
you're bringing to this is that we have a limited number of fields and
that we need to shoehorn all of our precious information into those
fields.  While that may have been true in 1.0 and previous versions, it
is no longer the case.  The only thing that prevents people from
creating new variables is that most of the standard 'example' CDR
modules do not support more than that limited set.  This is due mostly
to the legacy of 1.0, when these modules first appeared.  The addition
of cdr_custom and cdr_adaptive_odbc permits users to define completely
arbitrary fields and store exactly what they need in as many fields as
they see fit.

> I see this approach as the "easiest" for current developers using 1.2
> based source in a 1.4 environment, to fix things up to remain
> compatible with software which turns the CDR records into billing
> statements.

Essentially, this argument is "the standards we have come up with don't
match everybody's needs, so therefore we should have no standards."
I respectfully disagree, and I think the answer is, if the standard
fields that we provide don't meet your needs, use other fields.  Don't
diminish the needs of other users to have reliable standard fields just
because certain users don't use them.

> The other way is for users to change their dialplans/processing code
> to put the ${EXTEN} into the CDRs via the "userfield", or
> "accountcode", or a CDR variable. Most of the backends allow this,
> via a "custom" backend, but not all. The expense of maintaining CDR
> related code rises, as code external to asterisk has to change, and
> dialplans will probably also have to be modified. Just using CDR to
> tweak things would be cheaper, methinks.

The userfield was put into place prior to allowing users to create their
own fields.  We really only keep it for legacy reasons.  It is far more
useful to be able to define unlimited custom fields than to force users
into cramming their extra billing information into a single field.

If we deprotect any field, I fully anticipate a bug report of "Wah!  I
set CDR(dst) to 123, but it was set to something else when the CDR
was written.  Oh, by the way, I used Goto after setting CDR(dst)" and
the bug marked as MAJOR.  We need to think about what that means
and what the path of least resistance is, to avoid bugs of this nature.
Sometimes the path of least pain involves protecting the user from his
own confusion.  This is mainly what I would like to avoid.

-- 
Tilghman