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

[Dmitriy Serov]

09.10.2015 16:50, 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?
>

As one of those who raised this issue earlier (irc logs), I will write 
here my opinion on the possible implementation (suggested):
The channel hangup_handler that is called before closing the CDR session.

After trying different ways of catching the moments of completion of a 
Dial (with two channels) I found the use of hangup_handler the most 
convenient.
Another problem is that in the time of the call CDR session has ALREADY 
been closed, but NO records in the CDR table YET.

I will be extremely glad if such an opportunity and don't need to write 
it in a separate table with the following pending merge.