[asterisk-bugs] [Asterisk 0013094]: Call Fails to go to extension using WaitExten

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13094 
====================================================================== 
Reported By:                p_lindheimer
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   13094
Category:                   Applications/app_playback
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.21 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             07-16-2008 20:19 CDT
Last Modified:              07-16-2008 20:29 CDT
====================================================================== 
Summary:                    Call Fails to go to extension using WaitExten
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.

====================================================================== 

---------------------------------------------------------------------- 
 jsmith - 07-16-08 20:29  
---------------------------------------------------------------------- 
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. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-16-08 20:29  jsmith         Note Added: 0090375                          
======================================================================