[asterisk-dev] Asterisk 13.6.0-rc2 Possible CDR Bug

[Matthew Jordan]

On Wed, Oct 7, 2015 at 2:06 PM, Ross Beer <ross.beer at outlook.com> wrote:
> Hi,
>
> I am having an issue setting custom variables in a CDR record for a call
> once it has hung up. Setting variables before a dial are inserted into the
> CDR correctly. I am using the following hangup_handler as per previous
> versions:
>
> [record-hangupcause]
>
> exten => s,1,Set(CDR(hangupcause)=${HANGUPCAUSE})
> exten => s,n,Return()
>
>
> Before the dial a hangup handler is registered:
>
> Set(CHANNEL(hangup_handler_push)=record-hangupcause,s,1)
>
>
> The routine is called and the variables are being set, however not on the
> channel's CDR which made the call.
>
> By changing the cdr option 'endbeforehexten=no' this should keep the CDR
> accessible, however all this does is cause another CDR to be created for the
> 'h' extension.
>
> Is there currently a bug with accessing CDR data for a channel that has been
> hung-up? It looks to me that the CDR is closed before the hangup_handler is
> called. However this shouldn't be the case!
> I would be grateful for any feedback you can offer!
>
> I am happy to open a bug report, but I would prefer to have this
> acknowledged before doing so.
> Ross
>

Hey Ross -

Sorry I didn't reply sooner.

The short answer is that it is working as designed; the long answer is
that I think the design is wrong. (As the guy responsible, I feel like
I'm only throwing stones at myself.)

Keeping a single CDR running after channels have left a bridge was one
of those things that was relatively "easy" in 11 and earlier versions,
and is a bit more challenging in 13. I think in this case that we
probably should revisit the rules around it.

I do know this has come up a few times on the mailing lists, but I
don't think anyone has made an issue yet. Please do made one,
referencing this discussion.

Just to summarize what I think should happen:

endbeforehexten=no should cause no new CDR to be created in the 'h'
extension, and the 'end' time on the CDR should not be set. The CDR
should allow manipulation of its properties via the CDR function.

Does that sound right?

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org