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

[Steve Murphy]

I'm looking at bug 10067. 

For an outgoing call from an exten he:

exten => _6508XXX/_66508XXX,1,Macro(call-sip-nap,6${EXTEN})

calls a macro to place the outgoing call. Unfortunately,
that macro call louses up his dst/dcontext fields, which he desperately 
wants to remain at the previous values.

One user suggests that the problem can be fixed by running a deadagi 
script to modify the DB values, (something you can only do if you
are using a db CDR backend, BTW).

I reflected on the different approaches that people have taken to 
make sure that certain CDR fields contain the "right stuff", mostly
discovered by experiments and advise from folks who have suffered
in times past, and posted wiki pages or whatever. Some of these
work-arounds
involve using a Goto to update the CDR, when otherwise you would not use
a 
Goto; Or re-arranging your code to NOT use a Goto. Or not calling a
Macro,
when otherwise you would, even if it is better to do so; Or the advise
posted to 10067... 

And it hit me, that why force you-all to resort to such tactics when all
you 
really want to do is:

Set(CDR(dst)=${EXTEN});

So, I propose to the user community, that I lift the restrictions on the
CDR() function (to only allow modification of userfield, AMA-flags, and
accountcode), so that rather, you can change ANY field you need to.

I propose doing this in 1.4 and trunk. Trunk is a no-brainer. I was
going to 
do that anyway, as I pretty much did it in the CDR_CONTROL stuff I'll be
introducing, so it's only logical to lift the restrictions for regular
CDRs, too. 

But 1.4 is harder. Is it a bugfix or an enhancement? I propose doing
this to
1.4, as it will allow workarounds to current CDR bugs, like that
reported in 10067; I tend to think that this mod will make it much
cheaper for users to 
tweak CDR's to say what they need them to say, than to try to find some
obtuse method to trick asterisk into supplying what you need.

It is backwards compatible, as working dialplans simply don't take
advantage of
the feature (they couldn't, as they would get an error previous to
this).

May I do this? Any violent objections?

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/84cc131d/attachment.bin