[asterisk-bugs] [JIRA] (ASTERISK-19853) CDR(custom_field) field set in a DYNAMIC_FEATURE is reverted to the previous value when the call is terminated.

Wed Nov 6 08:10:04 CST 2013

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

Matt Jordan commented on ASTERISK-19853:
----------------------------------------

FreePBX is currently working around the problem by using a channel variable to store the property, then setting it in the {{h}} extension as well as in a macro executed by the dynamic feature. If I'm reading the code correctly, if you don't need to make a decision based on the value in the {{h}} extension but simply want to record the value in the CDR, you shouldn't have to do anything - the correct value *should* get stored. In FreePBX's case, however, this value tracks information about call recording, so some logical decisions are made in the {{h}} extension. Using a channel variable is a valid work around in that case.

> CDR(custom_field) field set in a DYNAMIC_FEATURE is reverted to the previous value when the call is terminated.
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-19853
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-19853
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_cdr
>    Affects Versions: 1.8.11.1, 10.2.1
>         Environment: FreePBX 2.10 or later system
>            Reporter: Philippe Lindheimer
>            Assignee: Philippe Lindheimer
>            Severity: Minor
>
> FreePBX uses it's own DYNAMIC_FEATURE for doing on-demand call recording, "*1" which previously used automixmon.
> The specific bug is that a value set in a dynamic feature using the CDR(variable)=xyz function reverts back to the value that was set prior to the call being bridged when the call is hung up even though after the dynamic feature is pressed it can be confirmed that the value has in fact been properly set and present in the channel.
> Repro:
>  - Enable on-demand recording on an extension but no record always settings
>  - Make a call
>  - press the *1 'start recording' button and confirm it started (check the CLI)
>  - now check the channel contents - 'core show channel SIP/702-xxxxxx' to confirm that CDR(recordingfile) was set properly.
>  - now hangup, check the DB and no value is set
> The specific variable in question is CDR(recordingfile) and here are some snap-shot examples to demonstrate the behavior:
> Partial Dialplan before call is bridged:
> {noformat}
>     -- Executing [s at sub-record-check:12] Set("SIP/702-000002c0", "__REC_STATUS=INITIALIZED") in new stack
>     -- Executing [s at sub-record-check:13] Set("SIP/702-000002c0", "CDR(recordingfile)=INITIALIZED") in new stack
> {noformat}
> Partial dump of channel after call is bridged:
> {noformat}
>   CDR Variables:
> level 1: dnid=9203760286
> level 1: recordingfile=INITIALIZED
> level 1: clid=702
> level 1: src=702
> {noformat}
> Partial dialplan when DYNAMIC_FEATURE is being executed:
> {noformat}
>     -- Executing [s at macro-one-touch-record:16] Set("SIP/702-000002c0", "MASTER_CHANNEL(CDR(recordingfile))=out-9203761234-702-20120508-141552-1336511752.1205.wav") in new stack
>     -- Executing [s at macro-one-touch-record:17] Set("SIP/702-000002c0", "CDR(recordingfile)=out-9203761234-702-20120508-141552-1336511752.1205.wav") in new stack
> {noformat}
> Now confirmation from a dump of the channel while the call is still active after the feature is pressed:
> {noformat}
>   CDR Variables:
> level 1: recordingfile=out-9203761234-702-20120508-141552-1336511752.1205.wav
> level 1: dnid=9203760286
> level 1: clid=702
> {noformat}
> Now some debug code in the hangup macro showing what is in the CDR(recordingfile):
> {noformat}
>     -- Executing [h at macro-dialout-trunk:1] Macro("SIP/702-000002c0", "hangupcall,") in new stack
>     -- Executing [s at macro-hangupcall:1] NoOp("SIP/702-000002c0", "recordingfile: INITIALIZED") in new stack
>     -- Executing [s at macro-hangupcall:2] GotoIf("SIP/702-000002c0", "1?theend") in new stack
>     -- Goto (macro-hangupcall,s,5)
>     -- Executing [s at macro-hangupcall:5] Hangup("SIP/702-000002c0", "") in new stack
> {noformat}
> As can be seen it has reverted.
> Further testing shows that IF we set a different channel variable during the dynamic feature execution and then IN the hangup macro we set CDR(recordingfile) to that variable, that it is then properly stored in the database, and also confirms that the channel variable survives the hangup macro and does not revert unlike the CDR(recordingfile)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira