[Home]

Summary:ASTERISK-07616: Extensions.conf parser ignores labels
Reporter:sedwards (sedwards)Labels:
Date Opened:2006-08-28 20:29:07Date Closed:2006-08-29 18:21:59
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/Configuration
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:The extensions.conf parser silently discards extension steps with wildcards and labels.

extensions.conf:
       [test-1]
               exten = s,1(MainDial),Dial(...)
               exten = s,MainDial+101,Voicemail(u100)

       [test-2]
               exten = _x.,1(MainDial),Dial(...)
               exten = _x.,MainDial+101,Voicemail(u100)

Asterisk 1.2.11:
       dt-ext> show dialplan test-1
       [ Context 'test-1' created by 'pbx_config' ]
         's' =>            1. Dial(...)               [pbx_config]
                           102. Voicemail(u100)       [pbx_config]
       -= 1 extension (2 priorities) in 1 context. =-

       dt-ext> show dialplan test-2
       [ Context 'test-2' created by 'pbx_config' ]
         '_x.' =>          1. Dial(...)               [pbx_config]
                           102. Voicemail(u100)       [pbx_config]
       -= 1 extension (2 priorities) in 1 context. =-

Asterisk SVN-trunk:

       s4> show dialplan test-1
       [ Context 'test-1' created by 'pbx_config' ]
         's' =>            1. Dial(...)               [pbx_config]
                           102. Voicemail(u100)       [pbx_config]
       -= 1 extension (2 priorities) in 1 context. =-

       s4> show dialplan test-2
       [ Context 'test-2' created by 'pbx_config' ]
         '_x.' =>          1. Dial(...)               [pbx_config]
       -= 1 extension (1 priority) in 1 context. =-

This breaks my dialplans where I tend to use "_x." a lot.
Comments:By: Steve Murphy (murf) 2006-08-29 10:02:18

I will look into this issue; but in the interest of upward compatibility,
let me note that priority number math is deprecated in trunk, and the ability to jump to n+101 will disappear in future revs.

In trunk and 1.2, to get Dial to jump to n+101, you have to use the j option, which is marked as deprecated. You should instead use the channel variable set by applications to properly react to them.  Use labels and GotoIf and its relatives to execute conditional code.

Your coding example would be better written:

[test-1]
 exten => s,1(MainDial),Dial(...)
 exten => s,n,GotoIf($[ ${DIALSTATUS} = NOANSWER ]?noans:notnoans)
 exten => s,n(noans),VoiceMail(u100)
 exten => s,n,Goto(dialdone)
 exten => s,n(notnoans),VoiceMail(b100)
 exten => s,n(dialdone), ....

Or, use AEL/AEL2 (and pardon the bit of embellishment below!):

macro std-priv-exten( dev, ext , timeout, opts, torcont, dontcont )
{
       Dial(${dev},${timeout},${opts});
       NoOp(${DIALSTATUS} was chosen);
       switch(${DIALSTATUS})
               {
       case TORTURE:
               goto ${torcont}|s|begin;
               break;
       case DONTCALL:
               goto ${dontcont}|s|begin;
               break;
       case BUSY:
               Voicemail(b${ext});
               break;
       case ANSWER:
               break;
       case NOANSWER:
               Voicemail(u${ext});
               break;
       default:
               Voicemail(u${ext});
       }
}

Pardon the lecture on channel variables, you probably know it all already! I'll investigate  why the priority got dropped.
By: sedwards (sedwards) 2006-08-29 10:45:21

Thanks for the "lecture." This "dial" example was from the wiki page.

My code was to process the result from a credit card authorization where my AGI returns the "reason" the card processor approved or declined the card. Thus "reason+101" (invalid card) and "reason+300" (authorization approved) made for a very readable dialplan. Using the channel variable with a switch statement would be even better so I guess I should learn AEL.

Is there any "standard" for naming application status channel variables? For example "<application-name>-STATUS"? (I find "RANDOMAPPLICATION-STATUS" easier to read than "RANDOMAPPLICATIONSTATUS.")
By: Steve Murphy (murf) 2006-08-29 11:04:09

OK, I'm able to reproduce this. Very interesting....!

Basically, your dialplan should work! Even if it's using 'deprecated' methods. I'm tooling up to debug this even as we... well... type... er... speak.

By: Steve Murphy (murf) 2006-08-29 11:12:53

oh, and a standard for naming the result channel variable for apps... what a novel idea!! Seriously, the doc/channelvariables.txt file seems to show the pattern is the less readable DIALSTATUS, DBGETSTATUS, etc.etc.
By: Tilghman Lesher (tilghman) 2006-08-29 11:27:54

I actually do a similar thing, to space out my Gosub routines, to ensure there's no accident collisions between jump code and my subroutines:

exten => _XXX,1,Gosub(checkcid)
exten => _XXX,n,Dial(...)
...
exten => _XXX,n+1000(checkcid),...
By: Steve Murphy (murf) 2006-08-29 18:20:20

I found and fixed the bug as revision 41283. I added some code that seems to have been removed in rev. 22317 of 24Apr06; The previous version to that, 21036 of 18Apr06 had this code. (See the func ast_extension_match() there). I guess I did add something, the old version did a plain strcmp. This version does strcasecmp.
By: Steve Murphy (murf) 2006-08-29 18:21:59

It seems natural to close this bug once it's been found, corrected, and committed to trunk.