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

[Ross Beer (JIRA)]

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

Ross Beer commented on ASTERISK-25458:
--------------------------------------

On further investigation, it looks like on a failed dial with an error response code setting variables after the dial command does not cause any information to be saved in the CDR. The only time data is saved is when the h or hangup_handler is called.

Ideally we should be able to set the hangup cause within the CDR for each call attempt, where as at the moment it's only possible to record the last call attempts hangup cause.

> 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
>            Assignee: 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)