[asterisk-bugs] [Asterisk 0017089]: Background behaves strangely[t when priority 1 is not available in current extension.

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17089 
====================================================================== 
Reported By:                whardier
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17089
Category:                   Core/PBX
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.6.2.6 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-03-23 22:20 CDT
Last Modified:              2010-03-25 11:30 CDT
====================================================================== 
Summary:                    Background behaves strangely[t when priority 1 is
not available in current extension.
Description: 
Apparently whatever extension lookup method is being used by BackGround
fails when the extension calling BackGround does not have priority 1 in the
current context.  I discovered this when including an IVR menu into another
context using a 50000 offset to extension 's' and a named priority.  See
additional information for a quick sample.

In the example below, if a caller is sent to Goto(tree-dish-AK-ANC,s,1)
the extension detection fails with:

[Mar 23 19:17:41]     -- Sent into invalid extension 's' in context
'tree-dish-common' on SIP/0011-Sales-0000001c
[Mar 23 19:17:41]     -- Executing [i at tree-dish-common:1]
Gosub("SIP/0011-Sales-0000001c", "s,common") in new stack

If I attempt to dial a 4 digit extension starting with 0 when a '0'
extension exists.  Something is 'wonky' if I can get technical with you
all.

Previously [tree-dish-AK-ANC] included [tree-dish-common] and simply went
to the named priority at priority 50000 via a local Goto which may have
worked.. untested.  

I can see how some users may want to jump into a named priority in another
context and use DTMF detection of some kind.  If the extension does not
have priority 1 this will fail.
====================================================================== 

---------------------------------------------------------------------- 
 (0119901) lmadsen (administrator) - 2010-03-25 11:30
 https://issues.asterisk.org/view.php?id=17089#c119901 
---------------------------------------------------------------------- 
<Corydon76-dig> The reason for the message is that when we increment the
priority past one that doesn't exist, we don't know how we got there
<Corydon76-dig> So we do a little trick:  we check if priority 1 exists. 
If it does, we assume we got there through incrementing the priority and we
exit.  If not, we assume that we got there through a Goto
<leifmadsen> so to Goto(somewhere,extension,start) which is
[somewhere]\nexten=> extension,50000(start),NoOp() we actually start at
extension,s,1 and increment until we find 'start' ?
<Corydon76-dig> That's the reason for the wonky message, but the behavior
is entirely predictable, which is why no bug exists
<Corydon76-dig> No... we get to 50000, we execute
<Corydon76-dig> 50001, execute
<Corydon76-dig> ...
<Corydon76-dig> 50004, does not exist, we check if priority 1 existed, if
it does, we exit
<leifmadsen> oh... I don't understand the reason for the check
<Corydon76-dig> if it doesn't, we assume Goto logic
<Corydon76-dig> Otherwise, we would always go to the "i" extension when we
run out of priorities, instead of exiting
<leifmadsen> if we're executing away on priority 50000 and we get to the
end, why bother checking if priority 1 ever existed?
<leifmadsen> huh
<leifmadsen> why wouldn't that check be done at the start?
<Corydon76-dig> leifmadsen: Because it's all stateless.  When we get to
50004, we don't know how we got there
<leifmadsen> ah 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-03-25 11:30 lmadsen        Note Added: 0119901                          
======================================================================