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

[Andrew Kohlsmith]

On Thursday 28 June 2007 2:32 pm, Tilghman Lesher wrote:
> 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()

I disagree -- Asterisk is a flexible platform, and this nonsense of having 
CDRs locked in certain (and arbitrary) ways is nonsense.  Using a Goto() 
inside of a macro just to work around this is idiocy.

I'm all for consistency and "path of least surprise" -- if some numb-nuts has 
mangled his dialplan so hideously that his CDRs are not what he expects, 
Asterisk should not try to babysit him at the cost of preventing those who 
want to aim the gun just to the right of their right foot from doing so.

This is exactly like the idiotic problem that caused channel drivers to 
respond differently a year or so back.  If I had a call from a PRI that 
dumped into a context that did not have a match for a valid DID, the call 
would be rejected instead of going to the 'i' extension.

Follow the path of least surprise -- there is absolutely no reason to prevent 
Set(CDR(dst)) except to babysit people.  Education, not protection, is the 
right solution.

> Over the long haul, Macro will be going away completely, which will
> resolve this little nastiness anyway.

Agreed, but I'm sure there are other pockets of CDR nastiness... In fact, I 
think the proposed CDR overhaul takes care of all of these problems, so maybe 
the entire point is moot for the future.

-A.