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

[David Boyd]

On Thu, 2007-06-28 at 15:02 -0500, Tilghman Lesher wrote:
> 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.
> 
Thank you Tilghman for the candid response. In my past dealings of
writing billing software for MCI, GTE, and Lightnet. there would be
'VIOLENT' response so sorry for not understanding the tongue in cheek.
As for the protection aspect, I agree with murf, in open source there is
no such thing as protected, however there is such a thing as more easily
implemented to accomplish need.

dave