[asterisk-bugs] [Asterisk 0017089]: Background behaves strangely[t when priority 1 is not available in current extension.
Asterisk Bug Tracker
noreply at bugs.digium.com
Thu Mar 25 09:51:40 CDT 2010
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 09:51 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.
======================================================================
----------------------------------------------------------------------
(0119883) lmadsen (administrator) - 2010-03-25 09:51
https://issues.asterisk.org/view.php?id=17089#c119883
----------------------------------------------------------------------
Lets say this worked for a moment.
What you're really doing is pretty much attempting to create a new
extension, but offsetting the starting priority number to 50000, although I
don't really see why you would do that.
Why wouldn't you just create a different named extension? I don't see the
purpose or reasoning behind why you would ever want to make this a standard
practice.
It's entirely possible I'm missing something here, but this really feels
like a method that shouldn't be employed -- working or not.
Issue History
Date Modified Username Field Change
======================================================================
2010-03-25 09:51 lmadsen Note Added: 0119883
======================================================================
More information about the asterisk-bugs
mailing list