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

[Steve Murphy]

On Thu, 2007-06-28 at 13:32 -0500, Tilghman Lesher wrote:
> On Thursday 28 June 2007 12:28, Steve Murphy wrote:
> > May I do this? Any violent objections?
> 
> I violently object.  The CDRs are supposed to reflect exactly certain
> channel settings.  When you make a change in the channel, the CDR is
> thus updated.  While we have created the ability for you to have
> arbitrary CDR variables, the core information should remain unaltered,
> more for sanity's sake (i.e. you might change something in the CDR, then
> the channel is altered, and your change to the CDR is overwritten with
> new channel information) than for any other reason.  We do NOT want to
> go down this route, which will then create the need to "protect" CDR
> variables which have been altered by the CDR() dialplan function (and
> "unprotect" them in certain circumstances, etc.)  This is likely to get
> messy, whereas prohibiting their change (current behavior) is simple
> and clean.
> 
> I would strongly suggest that you use the following logic in the Macro:
> [macro-whatever]
> exten => s,1,Goto(${MACRO_EXTEN},1)
> exten => _NXX-XXXX,1,Whatever()
> ...
> 
> This will ensure that you get the dst that you desired to have in your
> CDR, should the call end while the Macro is executing.
> 
> Over the long haul, Macro will be going away completely, which will
> resolve this little nastiness anyway.
> 

While I see your point, let me note that fixes to CDR's are involving
necessary changes to philosophies about them. There is no other way.

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. 

For instance, if a developer wanted to increase profits, he could pad
the answer and start times by merely subtracting 5 somewhere in the
source, probably in an answer() function somewhere. This would add 5
billable seconds to every call in the system, and might increase profits
by some percentage, and be fairly difficult to detect in billing
statements. While this would probably be considered dishonest/criminal,
it could be done. And the poor FBI analyst who got the code under
subpoena, might or might not easily find the mod via the [svn] diff, vs
studying what was done in the dialplan code.

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. 

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?

When we start shipping binary versions of Asterisk with published
checksums, we might be able to guarantee protection of fields, but even
then, I'm sure there are ways to run shadow copies of modified asterisk.
Until some really secure way of doing this kind of thing exists, I
really don't see the point of protection.
It isn't true. And even then, what's true isn't always useful.

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.

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.

murf

-- 
Steve Murphy
Software Developer
Digium
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20070628/5f3ec223/attachment.bin