[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.

[Matt Jordan (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-19853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Jordan reassigned ASTERISK-19853:
--------------------------------------

    Assignee: Matt Jordan
    
> 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: Matt Jordan
>            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:
>     -- 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
> Partial dump of channel after call is bridged:
>   CDR Variables:
> level 1: dnid=9203760286
> level 1: recordingfile=INITIALIZED
> level 1: clid=702
> level 1: src=702
> Partial dialplan when DYNAMIC_FEATURE is being executed:
>     -- 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
> Now confirmation from a dump of the channel while the call is still active after the feature is pressed:
>   CDR Variables:
> level 1: recordingfile=out-9203761234-702-20120508-141552-1336511752.1205.wav
> level 1: dnid=9203760286
> level 1: clid=702
> Now some debug code in the hangup macro showing what is in the CDR(recordingfile):
>     -- 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
> 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