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

[Tilghman Lesher]

On Thursday 28 June 2007 14:07, David Boyd wrote:
> 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.
>
> I am unsure as to why you violently object to a move that allows
> people more flexibility to perform an action they warrant as needed.
> The caveat is user beware, you can change things that will break your
> CDR recording efforts. The change as I understand it is not to force
> something on anyone, it is  an opening of restrictions that would
> only be used when the user saw fit. If my understanding is not
> correct would you please let me know where I have it wrong.

The violent objection comes as a response to Steve's query (does anybody
violently object).  It is no more violent than the tongue-in-cheek
question to which it was addressed.

In answer to your question, thought:  specifically, if you use Goto
after setting CDR(dst), then whatever you had set CDR(dst) to would be
overwritten, which causes user confusion.  It's better to simply
prohibit the setting of variables which will be overwritten during
normal processing.  The same applies to src (which reflects
CALLERID(ani)) and every other CDR variable which is currently
protected from being directly written.  (Note that there is no
protection from being indirectly written:  if you change the
corresponding channel information, then the CDR variable is completely
changeable already.)

Nothing is preventing you from creating another CDR variable (and
logging it) called Destination.  Since it is not a standard CDR
variable, it will only be overwritten when you choose to do so via the
dialplan.  User flexibility is not impeded by preventing the standard
variables (whose purpose it is to mirror channel information) from being
altered.

-- 
Tilghman