Bug on dialplan delete recordings

[davidbqzt]

Hi,

I've found that when you use the option 'Queue Continue Destination' the dialplan continues to the context sub-record-cancel, and on that context, I suppose there is a wrong if that open the door to delete the recording.

In every queue dialplan context you will find something like that:

exten => 6004,n(qcall),Queue(6004,${QOPTIONS},${QURL},${QAANNOUNCE},${QMAXWAIT},${QAGI},,${QGOSUB},${QRULE},${QPOSITION}) exten => 6004,n,Macro(blkvm-clr,) exten => 6004,n,Gosub(sub-record-cancel,s,1()) exten => 6004,n,Set(__NODEST=) exten => 6004,n,Set(_QUEUE_PRIO=0) exten => 6004,n,Set(QDEST=${VQ_DEST}) exten => 6004,n,Set(VQ_DEST=) exten => 6004,n(gotocontinue),GotoIf($["${QUEUESTATUS}"="CONTINUE"]?app-blackhole,hangup,1) exten => 6004,n(gotodest),GotoIf($["${QDEST}"=""]?app-blackhole,hangup,1:${CUT(QDEST,^,1)},${CUT(QDEST,^,2)},${CUT(QDEST,^,3)}) If you've used the option 'Queue Continue Destination' you will have the command Queue like that: Queue("SIP/100-000087f9", "6004,tc,,,,,,,,") If you didn't the command Queue will looks like that: Queue("SIP/7763-000087f9", "4004,t,,,,,,,,") If the c isn't present, when the calls were end by the agent, the dialplan will go right to hangup, end of story. But if c is present the dialplan will continue, first it will go to the context macro-blkvm-clr, after that will go to the context sub-record-cancel, this context is this (I've also compared an old Elastix 4 and the context is exactly the same):

`[sub-record-cancel] include => sub-record-cancel-custom exten => s,1,Set(REC_POLICY_MODE=${REC_POLICY_MODE_SAVE}) exten => s,n,ExecIf($["${REC_STATUS}"!="RECORDING"]?Return()) exten => s,n,StopMixMonitor() exten => s,n,Set(REC_STATUS=) exten => s,n,Set(MON_BASE=${IF($[${LEN(${MIXMON_DIR})}]?${MIXMON_DIR}:${ASTSPOOLDIR}/monitor/)}${YEAR}/${MONTH}/${DAY}/) exten => s,n,Set(MON_FMT=${IF($[${LEN(${MIXMON_FORMAT})}]?${IF($["${MIXMON_FORMAT}"="wav49"]?WAV:${MIXMON_FORMAT})}:wav)}) exten => s,n,ExecIf($[${LEN(${CALLFILENAME})} & ${STAT(f,${MON_BASE}${CALLFILENAME}.${MON_FMT})}]?System(rm -f ${MON_BASE}${CALLFILENAME}.${MON_FMT})) exten => s,n,Set(CALLFILENAME=) exten => s,n,Set(CDR(recordingfile)=) exten => s,n,Return()

;--== end of [sub-record-cancel] ==--;`

I think that the bug is when the context evaluate ExecIf($["${REC_STATUS}"!="RECORDING"]?Return()), because if REC_STATUS is RECORDING is because we want to record the call, but here the If evaluates 'if is not equal to', so it allows to the context to go forward and 5 lines after the dialplan deletes the call.

Solution: I think that the correct behavior must be:

ExecIf($["${REC_STATUS}"**=**"RECORDING"]?Return())

Maybe this was an old option that no one foresees because the option 'Queue Continue Destination' didn't exist on the Elastix 4 GUI.

Let me know your thoughts.

Thank you.

David

[asternic]

There is already a patch for fixing that bug,here:

https://github.com/IssabelFoundation/issabelPBX/commit/a1f98dc7ac5c317ec317a64f4d01f222edcef660#diff-f0b92393659ebd638aa14f2e32a77239

Best regards,

[davidbqzt]

Oh, ok, thank you Nicolas, when this patch will be available?

I've updated a few days ago and the bugs are still present on the server where I diagnosed this.

Regards,

David

[asternic]

IssabelPBX package was not updated yet, not sure when it will be, from the time being you will need to patch the file manually. We might be releasing a new version/iso at the end of the month, and with it update all issabelpbx modules.

Best regards,

[davidbqzt]

Awesome, thank you, I've done my own patch for now, but we will wait for the official release, thankyou.