I'm having an intermittent issue where asterisk will play our greeting to the caller, and then drop the call instead of making our phones ring.
I'm unable to reproduce the problem with any phones I have here, and many callers get through just fine. Some callers though, run into the problem, and I can't find any pattern to it.
The bit of information I could find said it was caused by an error in evaluating a dialplan expression. I'm thinking it's this line:
exten => START,n,GotoIf($[${FORCE_CLOSED}=TRUE]?CLOSED,1)
But I'm not sure what's wrong with it.
I see the following error on the console:
[Apr 4 16:29:49] WARNING[27038]: ast_expr2.fl:459 ast_yyerror: ast_yyerror(): syntax error: syntax error, unexpected '=', expecting $end; Input:=TRUE^
Surrounding Console output:
-- Executing [START@AGInbound:1] Answer("IAX2/AtlantaTeliax-10086", "") in new stack -- Executing [START@AGInbound:2] BackGround("IAX2/AtlantaTeliax-10086", 0000_AG_THANK_YOU_FOR_CALLING_AG") in new stack -- Playing '0000_AG_THANK_YOU_FOR_CALLING_AG.slin' (language 'en') [Apr 4 16:29:49] WARNING[27038]: ast_expr2.fl:459 ast_yyerror: ast_yyerror(): syntax error: syntax error, unexpected '=', expecting $end; Input: =TRUE ^ [Apr 4 16:29:49] WARNING[27038]: ast_expr2.fl:463 ast_yyerror: If you have questions, please refer to doc/tex/channelvariables.tex in the asterisk source. -- Executing [START@AGInbound:3] GotoIf("IAX2/AtlantaTeliax-10086", "?CLOSED,1") in new stack -- Executing [START@AGInbound:4] GotoIfTime("IAX2/AtlantaTeliax-10086", "9:30-17:0|mon-fri|*|*?OPEN,1") in new stack -- Executing [START@AGInbound:5] GotoIfTime("IAX2/AtlantaTeliax-10086", "10:0-18:30|sat|*|*?OPEN,1") in new stack -- Executing [START@AGInbound:6] GotoIfTime("IAX2/AtlantaTeliax-10086", "12:0-17:0|sun|*|*?OPEN,1") in new stack
Relevant lines from the dial plan:
exten => START,1,Answer() exten => START,n,Background(0000_AG_THANK_YOU_FOR_CALLING_AG) ; See if we're open ; Force Closed if no one's going to be answering exten => START,n,GotoIf($[${FORCE_CLOSED}=TRUE]?CLOSED,1) exten => START,n,GotoIfTime(${AG_WEEKDAY_OPEN_HOUR}:${AG_WEEKDAY_OPEN_MIN}-${AG$ exten => START,n,GotoIfTime(${AG_SATURDAY_OPEN_HOUR}:${AG_SATURDAY_OPEN_MIN}-${$ exten => START,n,GotoIfTime(${AG_SUNDAY_OPEN_HOUR}:${AG_SUNDAY_OPEN_MIN}-${AG_S$ ; ...and we're not. But maybe the time of day has been overridden? exten => START,n,GotoIf($[${OVERRIDE_TIME_OF_DAY}=TRUE]?OPEN,1) ; No override... We're definatly closed. exten => START,n,Goto(CLOSED,1)
Any idea what's wrong with the expression? We recently upgraded from 1.4 to 1.6.
In an Asterisk
$[]
expression, undefined variables do not return an implicit empty string or zero. They expand as "nothing" prior to evaluation of the expression, so after the variable is expanded (to nothing), it isn't visible to the expression parser. This causes the error already noted by Pablo Alsina:There are two ways to avoid this:
$[]
expression, enclose your variables and literals with double-quotes. This will cause an undefined variable to be handled as an empty string, which can still be used for comparison purposes.Personally, I try to do both. For example:
Note the double-quotes around
${FORCE_CLOSED}
and the comparison value. Even if the variable is undefined, the expression will have""
(an empty string) to compare against"TRUE"
.Really, you can use any character you like, because it will just be tacked onto the variable expansion. It just gives you a literal value that is guaranteed to be there in case the variable is undefined. I like quotes because it makes the code resemble other programming languages. You could just as easily use something like
$[x${FORCE_CLOSED}=xTRUE]
, which is commonly seen in Bourne shell scripting. The end result is the same.Here's what I can tell you.
yyerror is an error from a parser generated by yacc.
The error complains of the =. So it seems that, on that line, the = is a construct that the grammar does not support.
Good luck on serverfault.com where this question is headed ...
Who defines ${FORCE_CLOSED}?
From what I see, it seems that that variable sometimes does not get an initial value, and then the parser raises and error when you evaluate
Check that the calls that raises an error have a reasonable value for FORCE_CLOSED