Asterisk doesn't execute the whole dialplan, call stuck

Hello,

I’ve stumbled into an issue where a call randomly stucks, asterisk doesn’t execute the whole dialplan from start to finish.

[2022-03-14 18:03:27] VERBOSE[13901][C-00043c26] pbx.c: Executing [[email protected]:1] NoOp("SIP/VPBX40.BR.AWS-0008b8aa", "New Call Event") in new stack
[2022-03-14 18:03:27] VERBOSE[13901][C-00043c26] pbx.c: Executing [[email protected]:2] Set("SIP/VPBX40.BR.AWS-0008b8aa", "NOW=1647277407") in new stack
[2022-03-14 18:03:27] VERBOSE[13901][C-00043c26] pbx.c: Executing [[email protected]:3] Set("SIP/VPBX40.BR.AWS-0008b8aa", "__DAY=14") in new stack
[2022-03-14 18:03:27] VERBOSE[13901][C-00043c26] pbx.c: Executing [[email protected]:4] Set("SIP/VPBX40.BR.AWS-0008b8aa", "__MONTH=03") in new stack
[2022-03-14 18:03:27] VERBOSE[13901][C-00043c26] pbx.c: Executing [[email protected]:5] Set("SIP/VPBX40.BR.AWS-0008b8aa", "__YEAR=2022") in new stack
[2022-03-14 18:03:27] VERBOSE[13901][C-00043c26] pbx.c: Executing [[email protected]:6] Set("SIP/VPBX40.BR.AWS-0008b8aa", "__TIMESTR=20220314-180327") in new stack
[2022-03-14 18:03:27] VERBOSE[13901][C-00043c26] pbx.c: Executing [[email protected]:7] Set("SIP/VPBX40.BR.AWS-0008b8aa", "__MON_FMT=gsm") in new stack
[2022-03-14 18:03:27] VERBOSE[13901][C-00043c26] pbx.c: Executing [[email protected]:8] ExecIf("SIP/VPBX40.BR.AWS-0008b8aa", "1?Set(SRCPBX=1213)") in new stack
[2022-03-14 18:03:27] VERBOSE[13901][C-00043c26] pbx.c: Executing [[email protected]:9] ExecIf("SIP/VPBX40.BR.AWS-0008b8aa", "1?Set(EXTEN=49194)") in new stack
[2022-03-14 18:03:27] VERBOSE[13901][C-00043c26] pbx.c: Executing [[email protected]:10] ExecIf("SIP/VPBX40.BR.AWS-0008b8aa", "1?Set(UNIQUEID=VPBX40-1647277405.932020)") in new stack
[2022-03-14 18:03:27] VERBOSE[13901][C-00043c26] pbx.c: Executing [[email protected]:11] ExecIf("SIP/VPBX40.BR.AWS-0008b8aa", "1?Set(PLEXOPVAR=164ebb44-d83a-4351-8f2e-bd77c0aaae68_49194_22889851_18531_5511945423688_4_1)") in new stack
[2022-03-14 18:03:27] VERBOSE[13901][C-00043c26] pbx.c: Executing [[email protected]:12] ExecIf("SIP/VPBX40.BR.AWS-0008b8aa", "1?Set(INVESUSVAR=)") in new stack
[2022-03-14 18:03:27] VERBOSE[13901][C-00043c26] pbx.c: Executing [[email protected]:13] ExecIf("SIP/VPBX40.BR.AWS-0008b8aa", "1?Set(CDRINFOVAR=s=LM&cnt=BR&lang=pt&lead=22889851&b=48&eb=60&a=4&o=s&agt=18531&agtsk=33449&extagt=9571230&int=164ebb44-d83a-4351-8f2e-bd77c0aaae68&dst=5511945423688&prfx=&lgid=661)") in new stack
[2022-03-14 18:03:27] VERBOSE[13901][C-00043c26] pbx.c: Executing [[email protected]:14] Set("SIP/VPBX40.BR.AWS-0008b8aa", "SRC=551140409750_1213_49194") in new stack
[2022-03-14 18:03:27] VERBOSE[13901][C-00043c26] pbx.c: Executing [[email protected]:15] Set("SIP/VPBX40.BR.AWS-0008b8aa", "REALCALLERIDNUM=551140409750_1213_49194") in new stack
[2022-03-14 18:03:27] VERBOSE[13901][C-00043c26] pbx.c: Executing [[email protected]:16] Set("SIP/VPBX40.BR.AWS-0008b8aa", "__FROMEXTEN=551140409750_1213_49194") in new stack
[2022-03-14 18:03:27] VERBOSE[13901][C-00043c26] pbx.c: Executing [[email protected]:17] Set("SIP/VPBX40.BR.AWS-0008b8aa", "__CALLFILENAME=force-5511945423688-551140409750_1213_49194-20220314-180327-A2B_BR_AWS-1647277407.571562") in new stack
[2022-03-14 18:03:27] VERBOSE[13901][C-00043c26] pbx.c: Executing [[email protected]:18] Set("SIP/VPBX40.BR.AWS-0008b8aa", "CDR(recordingfile)=force-5511945423688-551140409750_1213_49194-20220314-180327-A2B_BR_AWS-1647277407.571562.gsm") in new stack

with what you have provided, all i can say is “Neat!”
Whats the dialplan you’re hoping for it to run?
Where is it dying?

You would need to let us see [custom-bforex] to get anything more than guesses

Here is the custom context.
This issue occurs pretty randomly.

[custom-bforex]
exten => _X.,1,Noop(New Call Event)

same => n,Set(NOW=${EPOCH})
same => n,Set(__DAY=${STRFTIME(${NOW},%d)})
same => n,Set(__MONTH=${STRFTIME(${NOW},%m)})
same => n,Set(__YEAR=${STRFTIME(${NOW},%Y)})
same => n,Set(__TIMESTR=${YEAR}${MONTH}${DAY}-${STRFTIME(${NOW},%H%M%S)})
same => n,Set(__MON_FMT=${IF($["${MIXMON_FORMAT}"=“wav49”]?WAV:${MIXMON_FORMAT})})

same => n,ExecIf($["${SRCPBX}" = “”]?Set(SRCPBX=${SIP_HEADER(X-SRCPBX)}))
same => n,ExecIf($["${EXTEN}" = “”]?Set(EXTEN=${SIP_HEADER(X-EXTEN)}))
same => n,ExecIf($["${UNIQUEID}" = “”]?Set(UNIQUEID=${SIP_HEADER(X-UNIQUEID)}))
same => n,ExecIf($["${PLEXOPVAR}" = “”]?Set(PLEXOPVAR=${SIP_HEADER(X-PLEXOPVAR)}))
same => n,ExecIf($["${INVESUSVAR}" = “”]?Set(INVESUSVAR=${SIP_HEADER(X-INVESUSVAR)}))
same => n,ExecIf($["${CDRINFOVAR}" = “”]?Set(CDRINFOVAR=${SIP_HEADER(X-CDRINFOVAR)}))
same => n,Set(SRC=${CALLERID(num)}${SRCPBX}${FILTER(0-9,${EXTEN})})
same => n,Set(REALCALLERIDNUM=${SRC})
same => n,Set(__FROMEXTEN=${IF($[${LEN(${AMPUSER})}]?${AMPUSER}:${IF($[${LEN(${REALCALLERIDNUM})}]?${REALCALLERIDNUM}:unknown)})})

;;;Call Recording
same => n,Set(__CALLFILENAME=force-${EXTEN:7}-${FROMEXTEN}-${TIMESTR}-${UNIQUEID})

same => n,Set(CDR(recordingfile)=${CALLFILENAME}.${MON_FMT}) ===>>> THE CALL SAMPLE IN THE TICKET SIMPLY STOPPED EXECUTING HERE

same => n,Set(CDR(userfield)=SRCPBX=${SRCPBX},SRCEXTEN=${EXTEN},SRCUNIQUEID=${UNIQUEID},RECFILE=${CDR(recordingfile)},PLEXOPVAR=${PLEXOPVAR},INVESUSVAR=${INVESUSVAR},CDRINFOVAR=${CDRINFOVAR},${CDR(userfield)})
same => n,Goto(callchecks)

;;;Call Checks
same => 50(callchecks),Noop(Performing multiple DB checks for call validation)
same => 51(calltorture),GotoIf($["${ODBC_CALLTORTURE(${EXTEN},60,7,20)}" = “1”]?CALLTORTURE,${EXTEN},1)
same => 52(callbarring),GotoIf($["${ODBC_CALLBARRING2(${SRCPBX},${EXTEN:7},${EXTEN})}" = “1”]?CALLBARRING,${EXTEN},1)
same => n,Goto(outbound)

;;;Outbound Routes
same => 70(outbound),Noop(Going to A2Billing Outbound Routes)
same => n,Set(CALLERID(dnid)=${EXTEN:3})
same => n,Goto(custom-bforex-a2billing,${EXTEN:3},1)

What is the version of FreePBX and the version of Asterisk being run on the system?

Why do you use so many equal signs. I am afraid that this is what’s breaking it.

And it will certainly overflow the CDR(userfield) which is 255 by default.

So in very recent published versions of Asterisk 16/18/19 there is the new JSON_DECODE function. I’ve been meaning to publish a bit of a user guide, but this will do until I get a round tuit. [It’s done now, see it here]

You can store 1D array JSON in the CDR(userfield) or in a channel var (or in the extension accountcode :slight_smile: ahem @billsimon ) something like:

{
"SRCPBX":"${SRCPBX}",
"SRCEXTEN":"${EXTEN}",
"SRCUNIQUEID":"${UNIQUEID}",
"RECFILE":"${CDR(recordingfile)}",
"PLEXOPVAR":"${PLEXOPVAR}",
"INVESUSVAR":"${INVESUSVAR}",
"CDRINFOVAR":"${CDRINFOVAR}",
}

and then later when you need to ref one of those values you can do so using

${JSON_DECODE(CDR(userfield),SRCUNIQUEID)}
1 Like

Nice addition, but still needed is

mysql asteriskcdrdb -e "ALTER TABLE cdr MODIFY userfield varchar(NNN)"

where NNN is large enough to catch the } under any set of values.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.