Upper 'N' in 'exten => aNswer,...' breaks dialplan logic

(using v1.6.1.4 on 64bit CentOS 5.3)

just stumbled over a strange effect.
If i try to use
after a
command, I can not jump to Extensions s-ANSWER, s-NOANSWER, s-CONGESTION whereas s-BUSY works fine!
After having tested a lot, it turn out, that the upper case ‘N’ in the extension string prevents asterisk from finding it.


. exten => s,n,Goto(s-${DIALSTATUS},1) . . exten => s-ANSWER,1,Goto(s,end) .
will produce the following CLI output.

-- Goto (func_directcall,s-ANSWER,1) [Aug 14 20:48:58] WARNING[12754]: pbx.c:3831 __ast_pbx_run: Channel 'SIP/D001-cc07ad38' sent into invalid extension 's-ANSWER' in context 'func_directcall', but no invalid handler
but the ‘dialplan show context’ will prove, the extension ‘s-ANSWER’ is parsed and available.

*CLI> dialplan show func_directcall [ Context 'func_directcall' created by 'pbx_config' ] . . 5. Goto(s-${TOLOWER(${DIALSTATUS})},1) [pbx_config] [end] 6. Return() [pbx_config] 's-ANSWER' => 1. Goto(s,end) [pbx_config] .

if I change to

. exten => s,n,Goto(s-${TOLOWER(${DIALSTATUS})},1) . . exten => s-answer,1,Goto(s,end) .

it works like a charm.

Further testing showed, that you can use upper case, as long as there is no ‘N’ in the extension string.

This post is just to let you know. I now have my workaround for this.
But it may be worth fixing it (if it is really broken).

Best regards and many thanks for providing this great pice of software.

Can anyone confirm this misbehavior?
Am I the only one suffering from this?
I thought it was common use, to use the ${DIALSTATUS} var as a component of extension-names.
To me this looks like asterisk 1.6 tries to interpret the ‘s-ANSWER’ extension as if prefixed with an ‘_’, therefore interpreting the ‘N’ in ‘s-ANSER’ as a match for a integer larger than 2 as it would in extension patterns?


I would submit this to bugs.digium.com. You will get much better response there. This is a user forum. The majority of people here don’t even understand asterisk config files, since they are mostly GUI based deployments.

Actually, if they are GUI based, they need to be on the forum for their GUI, not here. I would say most people here don’t know how the various GUI implementations work, and will tend to tell you what to do to fix the actual dialplan, but possibly not in a way that the GUI will tolerate.

Also it is reasonable to try and confirm a bug here before going to issues.asterisk.org/, as one doesn’t make oneself popular by reporting a bug that turns out to be a configuration error.