Hello,
Digging a bit further, having a local cdr_custom CSV seems to make
updatings work !
I did have enough time to properly test this and become more affirmative
but it seems to depend on active CDR backend;
2018-02-21 22:19 GMT+01:00 Olivier :
> As a complement to my previous post, may I add that I observed the
> following behaviours:
>
> 1. On one system (Debian Stretch/asterisk 13.19 compiled from source),
> hangup causes are correctly saved in a custom CDR column.
>
> 2. On an other system (Debian Stretch/packaged asterisk), some rtcp stats
> are not-correctly saved in a custom CDR column (I also tried unsuccessfully
> with userfield column).
>
> In both cases:
> - CDR updates are triggered by a hangup handler pushed with
> CHANNEL(hangup-handler-push).
> - CDR are saved through ODBC i, aMariaDB or Postgres database.
>
> Toughts ?
>
> 2018-02-21 0:07 GMT+01:00 Olivier :
>
>> Hi,
>>
>> Reading this old thread, may I ask if keeping hangup handlers from
>> updating CDR values still enforced in Asterisk 15 ?
>> If positive, would it be very complex to add in Asterisk, a configuration
>> option allowing a system administrator to list in cdr.conf, the CDR fields
>> allowed to be updated in hangup handlers ?
>>
>> I'm planning to store some RTCP stats.
>> Saving them in CDR(userfield) would be perfect.
>>
>> Cheers
>>
>>
>> 2015-08-10 15:05 GMT+02:00 Matthew Jordan :
>>
>>>
>>> On Tue, Aug 4, 2015 at 9:16 AM, Filip Jenicek
>>> wrote:
>>>
With endbeforehexten=no I actually get two CDR entries. One for the
call and a second one for the "h" extension.
"","13","10","sip-locals","""13"" <13>","SIP/13-0006","SIP/1
0-0007","Dial","SIP/10","2015-08-04 06:28:44","2015-08-04
06:28:45","2015-08-04 06:28:47",3,1,"ANSWERED","DOCU
MENTATION","1438669724.6","empty"
"","13","h","sip-locals","""13""
<13>","SIP/13-0006","","NoOp","changed","2015-08-04
06:28:47","2015-08-04 06:28:47","2015-08-04 06:28:47",0,0,"ANSWERED","DOCU
MENTATION","1438669724.6","changed"
The first one contains the call itself. There are durations, CDR
variables set during the call, etc.
The second one contains only things configured in the "h" extension.
With endbeforehexten=yes, the cdr contains:
"","13","10","sip-locals","""13"" <13>","SIP/13-0006","SIP/1
0-0007","Dial","SIP/10","2015-08-04 06:28:44","2015-08-04
06:28:45","2015-08-04 06:28:47",3,1,"ANSWERED","DOCU
MENTATION","1438669724.6","empty"
There is only the call, nothing from the "h" extension.
I forgot to mention that I'm using Asterisk 13.1-cert2. Modifying CDR
records in the "h" extension used to work fine with Asterisk 1.8.
By analyzing the code I must confirm that the endbeforehexten option
behaves exactly according to its description:
As each CDR for a channel is finished, its end time is updated
and the CDR is finalized. When a channel is hung up and hangup
logic is present (in the form of a hangup handler or the
h extension), a new CDR is generated for the
channel. Any statistics are gathered from this new CDR. By enabling
this option, no new CDR is created for the dialplan logic that is
executed in h extensions or attached hangup handler
subroutines. The default value is yes, indicating
that a CDR will be generated during hangup logic.
I tried to delay the "h" extension by several seconds and I found out,
that the CDR record is sent to the cdr backend later. Unfortunately, it is
not modifiable from the "h" extension, because the cdr_object is already in
the finalized table.
Is there a way how to modify the CDR without hacking the code?
>>> Unfortunately, no.
>>>
>>>
How bad idea is it to comment the (it_cdr->fn_table ==
&finalized_state_fn_table) tests in ast_cdr_setuserfield and ast_cdr_setvar
and thus allow the "h" extension write to a finalized CDR?
>>> Well... I'm not sure :-)
>>>
>>> As the guy who signed himself up for the dubious honour of porting the
>>> CDR code to Asterisk 13 - and trying to figure out a consistent way to make
>>> it work - I err'd on the side of extreme caution. That is, if someone could
>>> make a mess of things, I should probably try to keep it from happening.
>>>
>>> A CDR can be finalized in a variety of ways:
>>> - Due to someone leaving a bridge
>>> - Due to a channel being hung up
>>> - Due to the CDR being forked
>>>
>>> Of those, modifying values is generally dangerous only in the "fork"
>>> scenario, as it may result in a CDR that a user 'ended' being modified.
>>> This is a concern when, as updating a value on a CDR walks the entire chain
>>> of CDRs, for all CDRs related to the channel:
>>>
>>> for (; (cdr = ao2_iterator_next(it_cdrs)); ao2_unlock(cdr),
>>> ao2_cleanup(cdr)) {
>>> ao2_lock(cdr);
>>> for (it_cdr = cdr; it_cdr; it_cdr = it_cdr->next
