[Home]

Summary:ASTERISK-15869: Background behaves strangely[t when priority 1 is not available in current extension.
Reporter:Shane Spencer (whardier)Labels:
Date Opened:2010-03-23 22:20:52Date Closed:2011-06-07 14:05:26
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/PBX
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
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@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.

****** ADDITIONAL INFORMATION ******

[tree-dish-common]

include => tree-common



exten => common,1,Gosub(tree-set-locale,s,1)

exten => common,n,Set(breadcrumbs=Tree-Dish-${locale})

exten => common,n,Set(CDR(userfield)=${breadcrumbs})

exten => common,n,Set(CDR(accountfield)=${CALLERID(DNID)})

exten => common,n,Set(CHANNEL(musicclass)=Tune3)

exten => common,n,Set(TIMEOUT(digit)=2)

exten => common,n,Set(TIMEOUT(response)=30)

exten => common,n,Set(TIMEOUT(absolute)=7200)

exten => common,n,Return()



exten => menu,1,NoOp(Entering DishNetwork Main Tree)

exten => menu,n,Answer()

exten => menu,n(menu),Gosub(common,1)

exten => menu,n,Set(CDR(userfield)=${breadcrumbs}-Menu)

exten => menu,n,WaitExten(1)

exten => menu,n,Background(custom/main-phone-tree-recording)

exten => menu,n,WaitExten(2)

exten => menu,n,Background(custom/main-phone-tree-recording)

exten => menu,n,WaitExten(2)

exten => menu,n,Background(custom/main-phone-tree-recording)

exten => menu,n,WaitExten(2)

exten => menu,n,Background(custom/main-phone-tree-recording)

exten => menu,n,WaitExten(2)

exten => menu,n,Background(custom/main-phone-tree-recording)

exten => menu,n,WaitExten(2)

exten => menu,n(voicemail),Set(CDR(userfield)=${breadcrumbs}-Voicemail)

exten => menu,n,Voicemail(0000,u)

exten => menu,n,Hangup()



exten => s,50000(makeitso),NoOp(Entering DishNetwork Main Tree)

exten => s,n,Answer()

exten => s,n(menu),Gosub(common,1)

exten => s,n,Set(CDR(userfield)=${breadcrumbs}-Menu)

exten => s,n,WaitExten(1)

exten => s,n,Background(custom/main-phone-tree-recording)

exten => s,n,WaitExten(2)

exten => s,n,Background(custom/main-phone-tree-recording)

exten => s,n,WaitExten(2)

exten => s,n,Background(custom/main-phone-tree-recording)

exten => s,n,WaitExten(2)

exten => s,n,Background(custom/main-phone-tree-recording)

exten => s,n,WaitExten(2)

exten => s,n,Background(custom/main-phone-tree-recording)

exten => s,n,WaitExten(2)

exten => s,n(voicemail),Set(CDR(userfield)=${breadcrumbs}-Voicemail)

exten => s,n,Voicemail(0000,u)

exten => s,n,Hangup()



exten => 3474,1,NoOp()

exten => _00XX,1,Goto(phones,${EXTEN},1)s f



exten => 0,1,Goto(operator,1)

exten => 1,1,Goto(sales,1)

exten => 2,1,Goto(dealer,1)

exten => 3,1,Goto(commercial,1)

exten => 4,1,Goto(techsupport,1)

exten => 5,1,Goto(accounting,1)

exten => 6,1,Goto(dishnetwork,1)

exten => 7,1,Goto(dispatch,1)



....



[tree-dish-AK-ANC]

exten => s,1,Set(locale=AK-ANC)

; exten => s,n,Goto(tree-dish-common,menu,1)

exten => s,n,Goto(tree-dish-common,s,makeitso)

exten => _.,1,Set(locale=AK-ANC)

exten => _.,n,Goto(tree-dish-common,${EXTEN},1)
Comments:By: Leif Madsen (lmadsen) 2010-03-24 08:55:58

This is not a bug in Asterisk, but rather a bug in your dialplan:

[tree-dish-AK-ANC]
exten => s,1,Set(locale=AK-ANC)
; exten => s,n,Goto(tree-dish-common,menu,1)
exten => s,n,Goto(tree-dish-common,s,makeitso)
exten => _.,1,Set(locale=AK-ANC)
exten => _.,n,Goto(tree-dish-common,${EXTEN},1)


In this case, if you do Goto(tree-dish-AK-ANC,s,1) your pattern match of _. will match the 's' extension, which then does the Goto(tree-dish-common,s,1) which of course doesn't exist because you don't have s,1 in [tree-dish-common].

Don't use the _. pattern match, and then you won't have the problem. The _. pattern match takes precedent over everything.
By: Shane Spencer (whardier) 2010-03-24 11:34:45

This report is against BackGround which is in the tree-dish-common context.  Ignore the tree-dish-AK-ANC context since it isn't the issue.  If it were I would never reach the menu in the first place.
By: Leif Madsen (lmadsen) 2010-03-24 13:20:27

This still looks like a dialplan issue to me.

Based on what you stated here:

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@tree-dish-common:1] Gosub("SIP/0011-Sales-0000001c", "s,common") in new stack

What I mentioned when I closed the issue still holds true.


What you're saying appears to be a separate issue altogether. You're going to have to provide the console output that demonstrates this issue.
By: Shane Spencer (whardier) 2010-03-24 13:34:15

extensions.conf:

[test-inbound]

exten => 1,1,Goto(test-menu,test1,start)
exten => 2,1,Goto(test-menu,test2,start)

[test-menu]

exten => test1,1(start),NoOp(test1)
exten => test1,n,Background(silence/10)
exten => test1,n,Hangup()

exten => test2,2(start),NoOp(test1)
exten => test2,n,Background(silence/10)
exten => test2,n,Hangup()

exten => _00xx,1,NoOp(Entered ${EXTEN})

exten => 0,1,NoOp(Entered ${EXTEN})
exten => 1,1,NoOp(Entered ${EXTEN})
exten => 2,1,NoOp(Entered ${EXTEN})
exten => 3,1,NoOp(Entered ${EXTEN})
exten => 4,1,NoOp(Entered ${EXTEN})
exten => 5,1,NoOp(Entered ${EXTEN})

Console Output Test 1 - Attempt to dial 0000 (Passes):

[Mar 24 10:31:41]     -- Executing [1@test-inbound:1] Goto("SIP/0011-00000031", "test-menu,test1,start") in new stack
[Mar 24 10:31:41]     -- Goto (test-menu,test1,1)
[Mar 24 10:31:41]     -- Executing [test1@test-menu:1] NoOp("SIP/0011-00000031", "test1") in new stack
[Mar 24 10:31:41]     -- Executing [test1@test-menu:2] BackGround("SIP/0011-00000031", "silence/10") in new stack
[Mar 24 10:31:41]     -- <SIP/0011-00000031> Playing 'silence/10.ulaw' (language 'en')
[Mar 24 10:31:42]     -- Executing [0000@test-menu:1] NoOp("SIP/0011-00000031", "Entered 0000") in new stack
[Mar 24 10:31:42]     -- Auto fallthrough, channel 'SIP/0011-00000031' status is 'UNKNOWN'

Console Output Test 2 - Attempt to dial 0000 (Fails):

[Mar 24 10:31:57]     -- Executing [2@test-inbound:1] Goto("SIP/0011-00000032", "test-menu,test2,start") in new stack
[Mar 24 10:31:57]     -- Goto (test-menu,test2,2)
[Mar 24 10:31:57]     -- Executing [test2@test-menu:2] NoOp("SIP/0011-00000032", "test1") in new stack
[Mar 24 10:31:57]     -- Executing [test2@test-menu:3] BackGround("SIP/0011-00000032", "silence/10") in new stack
[Mar 24 10:31:57]     -- <SIP/0011-00000032> Playing 'silence/10.ulaw' (language 'en')
[Mar 24 10:31:59] WARNING[27367]: pbx.c:4358 __ast_pbx_run: Channel 'SIP/0011-00000032' sent into invalid extension 'test2' in context 'test-menu', but no invalid handler
By: Leif Madsen (lmadsen) 2010-03-24 13:54:59

That looks like it's because you don't have priority one. Asterisk must have some sort of rule that says you need at least a priority 1.

If you do "dialplan show" does it show you the test2 extension? Is there a WARNING when you start up Asterisk?

I'd just add:

exten => test2,1,NoOp()
exten => test2,50000(start),NoOp()
By: Shane Spencer (whardier) 2010-03-24 14:11:43

There are no errors because that is ligitimate dialplan.  Similar to how [stdExten] works off of priority 50000.

Here's another scenario that might explain the whys involved with handling dialplan this way (similarly to how stdExten works)

[test-inbound]
exten => 1,1,Goto(test-menu-anchorage,s,1) ; Go through the anchorage context first and do something
exten => 2,1,Goto(test-menu-anchorage,s,1)
exten => 3,1,Goto(test-menu-wasilla,s,1) ; Go through wasilla context first and do something
exten => 4,1,Goto(test-menu,s,start) ; Go directly because I want too for some reason

[test-menu]

exten => s,50000(start),NoOp(test1) ; Offset this so that we can be included
exten => s,n,Background(silence/10)
exten => s,n,Hangup()

exten => _00xx,1,NoOp(Entered ${EXTEN})

exten => 0,1,NoOp(Entered ${EXTEN})
exten => 1,1,NoOp(Entered ${EXTEN})
exten => 2,1,NoOp(Entered ${EXTEN})
exten => 3,1,NoOp(Entered ${EXTEN})
exten => 4,1,NoOp(Entered ${EXTEN})
exten => 5,1,NoOp(Entered ${EXTEN})

[test-menu-anchorage]
include => test-menu
exten => s,1,NoOp(Do something here)
exten => s,n,Goto(start)

exten => 3474,1,NoOp(Do stuff)

[test-menu-wasilla]
include => test-menu
exten => s,1,NoOp(Do something else here)
exten => s,n,Goto(start)

exten => 5787,1,NoOp(Do stuff)
By: Tilghman Lesher (tilghman) 2010-03-25 00:33:49

All this really points to is a wonky message which is trying to be helpful, but since it depends upon priority 1 existing, it looks weird to you.  I don't think it could really be considered a bug, because the actual dialplan behavior (ignoring all messages) is what we would expect.
By: Leif Madsen (lmadsen) 2010-03-25 09:51:40

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.
By: Leif Madsen (lmadsen) 2010-03-25 11:30:32

<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