Summary:	ASTERISK-12396: Call Fails to go to extension using WaitExten
Reporter:	Philippe Lindheimer (p_lindheimer)	Labels:
Date Opened:	2008-07-16 20:19:42	Date Closed:	2011-06-07 14:07:59
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_playback
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Please hear me out as this is a bit of a corner case. I wasn't going to report it but Jared convinced me I should so that we can conclude on how/if to deal with it. I have a Post-Dial Macro called using the M() option of Dial(). The macro calls the Background() application specifying itself as the context where extensions should be searched. That works fine. However, once it leaves the BackGround() application and goes to WaitExten() all bets are off, hitting any digit fails other than timeout in which case the 't' extension is executed. I understand the issue wrt to Background() used inside of a macro, although in this case it is not a 'normal' macro given the M() option of the Dial() application. That is why I specify the context and why it works. The issue is with WaitExten(). Given that it is very much designed to go with the BackGround() application, it feels like a solution is in order. Either specify the context or use the context that was most recently specified in the last executed BackGround() application, which would be a great solution. Please note, I have a work around that I can use in this case, which is keep the old code and limit READ() to a single sound file, or call READ() after the background application and integrate them together. I just thought it was important to bring this issue up for potential discussion and resolution. ****** ADDITIONAL INFORMATION ****** Here is a bit of the dialplan to give you a flavor of what I am describing. [macro-confirm] 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,Set(TIMEOUT(digit)=3) exten => s,n,Set(TIMEOUT(response)=5) ; If a digit is entered while playing the message, it works exten => s,n(start),Background(${MSG1},m,${CHANNEL(language)},macro-confirm) ; If a digit is entered in the WaitExten command, all bets are off exten => s,n,WaitExten(,) 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,MacroExit() exten => 2,1,Goto(noanswer,1) exten => 3,1,Noop(CID: ${CALLCONFIRMCID}) exten => 3,n,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 => i,1,Playback(invalid) exten => i,n,GotoIf($["${DB_EXISTS(RG/${ARG3}/${UNIQCHAN})}" = "0"]?toolate,1) exten => i,n,Set(LOOPCOUNT=$[ ${LOOPCOUNT} + 1 ]) exten => i,n,GotoIf($[ ${LOOPCOUNT} < 5 ]?s,start:noanswer,1)
Comments:	By: Jared Smith (jsmith) 2008-07-16 20:29:38 In it's simplist form, this seems to be an oversight in the WaitExten() application.   Imagine if you will for a moment, two contexts named [one] and [two], like this: [one] ; my IVR menu goes here exten => 123,1,Background(menu,,,two) ; look for matches in the [two] context exten => 123,n,WaitExten() [two] exten => 123,1,Playback(asterisk-friend) If you happened to dial extension 123 during the menu, it would match in the [two] context.  But because WaitExten() doesn't let you specify a context in which to match, if you waited until the menu prompt was done playing and then entered extension 123, it would match in the [one] context. As I see it, we should add an optional context argument to WaitExten() to match the existing one in the Background() application. By: Tilghman Lesher (tilghman) 2008-07-17 08:41:25 This is not a forum appropriate for discussion.  Please take this discussion to the asterisk-dev list.  When you have an appropriate candidate patch for inclusion, you may reopen this issue.