[asterisk-bugs] [Asterisk 0014940]: Background application executed in post-Dial Application Macro terminates call
Asterisk Bug Tracker
noreply at bugs.digium.com
Mon Apr 20 17:16:31 CDT 2009
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=14940
======================================================================
Reported By: p_lindheimer
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 14940
Category: Applications/General
Reproducibility: always
Severity: major
Priority: normal
Status: new
Asterisk Version: 1.4.24
Regression: No
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!): 177786
Request Review:
======================================================================
Date Submitted: 2009-04-20 11:37 CDT
Last Modified: 2009-04-20 17:16 CDT
======================================================================
Summary: Background application executed in post-Dial
Application Macro terminates call
Description:
Note: I have not had access to a system to further isolate and run some
further tests yet but am providing some details of this issue as requested
on #asterisk-bugs channel. As a result, I can not conclusively say if this
is reproducible on a regular basis or if there are specific circumstances
that must be presented to create the problem.
This dialplan is from FreePBX 2.5 base.
This issue appears to have started at about Asterisk 1.4.24 where it was
first reported on the following two thread and then observed on a
customer's system who was running SVN r177786:
http://freepbx.org/forum/freepbx/users/call-confirmation-fails-after-asterisk-1-4-24-upgrade
http://freepbx.org/forum/freepbx/users/confirm-calls-hang-up
The crux of the issue is that macro-confirm is executed as a post dial
macro in a dialplan that would look something as follows:
Dial(Local/7365924 at from-internal/n,30,M(confirm^^^222)tTwWr))
The macro-confirm code is as follows:
[macro-confirm]
include => macro-confirm-custom
exten => s,1,Set(LOOPCOUNT=0)
exten => s,n,Set(__MACRO_RESULT=ABORT)
exten => s,n,Set(MSG1=${IF($["foo${ARG1}" !=
"foo"]?${ARG1}:"incoming-call-1-accept-2-decline")})
exten =>
s,n(start),Background(${MSG1},m,${CHANNEL(language)},macro-confirm)
exten => s,n,Read(INPUT,,1,,,4)
exten => s,n,GotoIf($[${LEN(${INPUT})} > 0]?${INPUT},1:t,1)
exten => 1,1,GotoIf($["${DB_EXISTS(RG/${ARG3}/${UNIQCHAN})}" =
"0"]?toolate,1)
exten => 1,n,dbDel(RG/${ARG3}/${UNIQCHAN})
exten => 1,n,dbDel(${BLKVM_OVERRIDE})
exten => 1,n,Set(__MACRO_RESULT=)
exten => 1,n(exitopt1),MacroExit()
exten => 2,1,Goto(noanswer,1)
exten => 3,1,SayDigits(${CALLCONFIRMCID})
exten => 3,n,GotoIf($["${DB_EXISTS(RG/${ARG3}/${UNIQCHAN})}" =
"0"]?toolate,1:s,start)
exten => t,1,GotoIf($["${DB_EXISTS(RG/${ARG3}/${UNIQCHAN})}" =
"0"]?toolate,1)
exten => t,n,Set(LOOPCOUNT=$[ ${LOOPCOUNT} + 1 ])
exten => t,n,GotoIf($[ ${LOOPCOUNT} < 5 ]?s,start:noanswer,1)
exten => _X,1,Background(invalid,m,${CHANNEL(language)},macro-confirm)
exten => _X,n,GotoIf($["${DB_EXISTS(RG/${ARG3}/${UNIQCHAN})}" =
"0"]?toolate,1)
exten => _X,n,Set(LOOPCOUNT=$[ ${LOOPCOUNT} + 1 ])
exten => _X,n,GotoIf($[ ${LOOPCOUNT} < 5 ]?s,start:noanswer,1)
exten => noanswer,1,Set(__MACRO_RESULT=ABORT)
exten => noanswer,n(exitnoanswer),MacroExit()
exten => toolate,1,Set(MSG2=${IF($["foo${ARG2}" !=
"foo"]?${ARG2}:"incoming-call-no-longer-avail")})
exten => toolate,n,Playback(${MSG2})
exten => toolate,n,Set(__MACRO_RESULT=ABORT)
exten => toolate,n(exittoolate),MacroExit()
exten => h,1,Macro(hangupcall,)
If the user presses a DTMF digit while the message is playing (typically
"1" to confirm and accept the call) then the call is failing with a log
file entry as shown below.
If they allow the message to play to completion, thus allowing the
dialplan to progress to the subsequent Read() application, then the
dialplan works as expected.
In one reported instance the log file reported the following:
[Apr 2 21:30:21] WARNING[12523] file.c: Unexpected control subclass '-1'
[Apr 2 21:30:27] DEBUG[12523] app_macro.c: Oooh, got something to jump out
with ('1')!
[Apr 2 21:30:27] DEBUG[12523] app_dial.c: Macro exited with status 49
[Apr 2 21:30:27] VERBOSE[12527] logger.c: -- Executing
[h at macro-dialout-trunk:1] Macro("Local/xxxxxxx at from-internal-182b,2",
"hangupcall|") in new stack
In another instance the following was reported:
[Apr 3 10:34:59] DEBUG[17927] app_macro.c: Oooh, got something to jump out
with ('1')!
[Apr 3 10:34:59] DEBUG[17927] app_dial.c: Macro exited with status 49
[Apr 3 10:34:59] DEBUG[17927] channel.c: Hanging up channel
'Local/xxxxxxx at from-internal-d163;1'
[Apr 3 10:34:59] DEBUG[17931] channel.c: Didn't get a frame from channel:
Local/xxxxxxx at from-internal-d163;2
[Apr 3 10:34:59] DEBUG[17931] channel.c: Bridge stops bridging channels
Local/xxxxxxx at from-internal-d163;2 and SIP/vitel-outbound-08632ed8
As can be seen for the dialplan, the background command is properly
directing back to the macro-confirm context. This dialplan has been working
flawlessly for 1-2 years on Asterisk 1.4 and it's variant on Asterisk 1.2
(the variant adjusting for Channel(language) that changed on 1.4).
======================================================================
----------------------------------------------------------------------
(0103507) p_lindheimer (reporter) - 2009-04-20 17:16
http://bugs.digium.com/view.php?id=14940#c103507
----------------------------------------------------------------------
More data related to this. There is a macro that allows for a recording to
be listened to and re-recorded in FreePBX that uses a similar Background()
command within a macro, it is here:
[macro-systemrecording]
include => macro-systemrecording-custom
exten => s,1,Set(RECFILE=${IF($["${ARG2}" =
""]?/tmp/${AMPUSER}-ivrrecording:${ARG2})})
exten => s,n,ExecIf($["${ARG3}" != ""],Authenticate,${ARG3})
exten => s,n,Goto(${ARG1},1)
exten => dorecord,1,System(rm ${ASTVARLIBDIR}/sounds/${RECFILE}.*)
exten => dorecord,n,Record(${RECFILE}:wav)
exten => dorecord,n,Wait(1)
exten => dorecord,n,Goto(confmenu,1)
exten => docheck,1,Playback(beep)
exten =>
docheck,n(dc_start),Background(${RECFILE},m,${CHANNEL(language)},macro-systemrecording)
exten => docheck,n,Wait(1)
exten => docheck,n,Goto(confmenu,1)
exten =>
confmenu,1,Background(to-listen-to-it&press-1&to-rerecord-it&press-star&astcc-followed-by-pound,m,${CHANNEL(language)},macro-systemrecording)
exten => confmenu,n,Read(RECRESULT,,1,,,4)
exten => confmenu,n,GotoIf($["x${RECRESULT}"="x*"]?dorecord,1)
exten => confmenu,n,GotoIf($["x${RECRESULT}"="x1"]?docheck,2)
exten => confmenu,n,Goto(1)
exten => 1,1,Goto(docheck,dc_start)
exten => *,1,Goto(dorecord,1)
exten => t,1,Playback(goodbye)
exten => t,n,Hangup
exten => i,1,Playback(pm-invalid-option)
exten => i,n,Goto(confmenu,1)
exten => h,1,Hangup
You will notice that it has a valid option "1" as one of the menu items.
In the CLI of a 1.4.24 system, that is verified:
pbx72*CLI> show dialplan 1 at macro-systemrecording
[ Context 'macro-systemrecording' created by 'pbx_config' ]
'1' => 1. Goto(docheck|dc_start)
[pbx_config]
-= 1 extension (1 priority) in 1 context. =-
As expected. Now, when going into that macro and trying to choose option
1, note the behavior:
[Apr 20 22:00:11] VERBOSE[9969] logger.c: -- Executing
[confmenu at macro-systemrecording:1] BackGround("DAHDI/1-1",
"to-listen-to-it&press-1&to-rerecord-it&press-star&astcc-followed-by-pound|m|en|macro-systemrecording")
in new stack
[Apr 20 22:00:11] VERBOSE[9969] logger.c: -- <DAHDI/1-1> Playing
'to-listen-to-it' (language 'en')
[Apr 20 22:00:12] VERBOSE[9969] logger.c: -- <DAHDI/1-1> Playing
'press-1' (language 'en')
[Apr 20 22:00:13] DEBUG[9969] app_macro.c: Oooh, got something to jump out
with ('1')!
[Apr 20 22:00:18] VERBOSE[9969] logger.c: -- Invalid extension '1' in
context 'from-internal' on DAHDI/1-1
[Apr 20 22:00:18] VERBOSE[9969] logger.c: == CDR updated on DAHDI/1-1
[Apr 20 22:00:18] VERBOSE[9969] logger.c: -- Executing
[i at from-internal:1] Playback("DAHDI/1-1", "privacy-incorrect") in new
stack
Note that is got a '1' to jump out with, but then it reports that there is
no valid extension '1' in from-internal and in this case, goes on to play
the invalid extensions since defined.
from-internal is the context that macro-systemrecording was called from.
However, you will note the explicit directive to use macro-systemrecording
in the context:
exten =>
confmenu,1,Background(to-listen-to-it&press-1&to-rerecord-it&press-star&astcc-followed-by-pound,m,${CHANNEL(language)},macro-systemrecording)
So there seems to be something clearly broken with Background()
Issue History
Date Modified Username Field Change
======================================================================
2009-04-20 17:16 p_lindheimer Note Added: 0103507
======================================================================
More information about the asterisk-bugs
mailing list