Asterisk: Dropping calls with an “ast_yyerror”

asterisk

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.

Best Answer

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:

GotoIf("IAX2/AtlantaTeliax-10086", "?CLOSED,1")

There are two ways to avoid this:

  1. Always give your variables reasonable defaults before you use them (as Pablo suggested).
  2. In any $[] 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:

exten => START,n,Set(FORCE_CLOSED=FALSE)
exten => START,n,GotoIf($["${FORCE_CLOSED}"="TRUE"]?CLOSED,1)

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.

Related Topic