[asterisk-bugs] [JIRA] (ASTERISK-25458) Unable to set CDR variable in h extension or hangup_handler

[Matt Jordan (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-25458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=228791#comment-228791 ] 

Matt Jordan commented on ASTERISK-25458:
----------------------------------------

I've spent some time digging into this, and while I believe we can fix 90% of what the issue describes, there is one part of the current behaviour that isn't worth changing.

When a CDR accounts for a bridged party - that is, when there is both a Party A and a Party B in the CDR - we *have* to finalize the CDR when the bridge is broken. That rule is pretty much impossible to change: the ripple effects of not doing that would be rather difficult to even begin to account. If we take a fairly simple scenario, where Alice calls Bob, that means that when either party leaves the bridge, we lock down the CDR that accounts for Alice's time with Bob.

If we have a hangup handler or an 'h' extension, we now have two options:
# We don't generate a new CDR. This leaves the CDR that is on Alice in a 'locked' state, but accessible in the hangup logic.
# We do generate a new CDR. This allows systems to account for the time that is spent processing things during hangup logic.

That behaviour is rightly governed by the {{endbeforehexten}} option. Because most people will not want a new CDR generated, this defaults to {{yes}}.

All of that really can't be easily or correctly changed, and I wouldn't want to try.

There are two bugs that exist in the code today with respect to this behaviour though:
# There are ways in which, even when {{endbeforehexten}} is set, we will not actually set the end time on the CDR. This would happen in our "Alice calls Bob" scenario, as that CDR gets finalized no matter what we want. However, if you merely have Alice executing dialplan, a glitch in the existing checks prevents this from occurring. That's wrong; {{endbeforehexten}} should always set the End time on the CDR if set to {{yes}}.
# The real crux of this issue: we can't set properties on a CDR in the {{h}} extension or a hangup handler, particularly if {{endbeforehexten}} is {{yes}}. Most people don't want another CDR that accounts for the time spent in hangup logic; they do, however, want to set some property on the CDR that accounts for the actual call.

Those two bugs should be fixed by the patch I've attached to this issue. The patch does the following:
# First, we are a bit more aggressive about setting the end time. We previously called a method that inspected the snapshot on the CDR to see if we needed to set the end time; that always failed with {{endbeforehexten}} as we are explicitly not updating the state of the channels on the CDR while it executes in hangup logic. Explicitly setting the end time via {{cdr_object_finalize}} suffices.
# Second, we now allow setting properties on a finalized CDR if there are no other CDRs left in the chain. This should preserve the 'locking' of attributes that can occur with ForkCDR, as well as allowing setting multiple CDRs if the Forked CDRs are not finalized when forked.



> Unable to set CDR variable in h extension or hangup_handler
> -----------------------------------------------------------
>
>                 Key: ASTERISK-25458
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25458
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: CDR/General
>    Affects Versions: 13.6.0
>            Reporter: Ross Beer
>            Severity: Minor
>         Attachments: ASTERISK-25458-13.diff
>
>
> It is not possible to add CDR variables in the h extension or the hangup_handler. 
> The CDR should only be closed once the hangup block has been processed. This would allow for calls that dial more than one extension (or fail-over to a secondary route) to store the hangup cause etc for each dial attempt which is the same way CDRs are created in Asterisk 13.
> Matthew Jordan via the dev mailing list commented:
> "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."



--
This message was sent by Atlassian JIRA
(v6.2#6252)