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

Mon Nov 4 12:10:03 CST 2013

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

Matt Jordan updated ASTERISK-19853:
-----------------------------------

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

  was:
FreePBX uses it's own DYNAMIC_FEATURE for doing on-demand call recording, "*1" which previously used automixmon.