[Home]

Summary:ASTERISK-10048: Variables in AEL2 context names
Reporter:Chris Tracy (adiemus)Labels:
Date Opened:2007-08-08 18:04:53Date Closed:2007-08-14 09:41:44
Priority:MinorRegression?No
Status:Closed/CompleteComponents:PBX/pbx_ael
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 10411.patch
Description:As part of our migration to 1.4.x, we're looking at moving to AEL2.  In so doing, I've run across what looks like a bug in the native AEL parser.  (Or I'm just missing something obvious, which I admit is very possible)

The relevant bits from extensions.ael:

globals {
 OFFICE_CODE=503;
}

context from-enum {
 includes {
   internal-extensions;
   pbx-extensions;
 }

 _${OFFICE_CODE}XXXX => {
       Answer();
       goto ${EXTEN:3}|1;
 }
}

With extensions.ael being loaded (and no extensions.conf), if I try to dial into this context, I get:

[Aug  9 00:45:47] NOTICE[15582]: chan_iax2.c:7406 socket_process: Rejected connect attempt from XXX.XXX.XXX.XXX, request '5039000@from-enum' does not exist

Interestingly, if I have aelparse dump an extensions.conf version of extensions.ael, I end up with the following relevant code:

[globals]
OFFICE_CODE=503

[from-enum]
include => internal-extensions
include => pbx-extensions
exten => _${OFFICE_CODE}XXXX,1,Answer()
exten => _${OFFICE_CODE}XXXX,2,Goto(${EXTEN:3}|1)

If I have asterisk load this instead of the AEL, the context works as expected.  (Hence my suspiscion it's the native AEL parser that's at fault)

In the meantime, I've simply changed the extension to:

_XXXXXXX => {

which will work for now.  But I would like, if possible, to put variables into extension names.

If there's any further information I can provide, please let me know.

Thanks,

-Chris

(NOTE: Mantis only lets me select 1.4.9, but I'm actually running into this issue on 1.4.10)
Comments:By: Steve Murphy (murf) 2007-08-09 00:23:13

I've uploaded the 10411.patch file, please merge the changes into your
release (there might be some offsets-- I built this on trunk; as long as there's no rejects, you'll be ok).

Please let me know if it solves the problem.

I discovered that the pbx_config stuff calls the pbx_substitute_variables_helper func on the extension name before calling add_extension2(). I will try to duplicate this when compiling. When merely dumping extensions.conf format, we don't have to evaluate the variables out, because the pbx_config stuff will do it for us.
By: Chris Tracy (adiemus) 2007-08-09 09:51:32

The patch applied fine but seemed to completely screw up several of my contexts.  I'm rebuilding the patched asterisk from scratch to verify the issue.
By: Chris Tracy (adiemus) 2007-08-09 22:13:47

Ok, I've applied this patch to two systems now.  In each case, it seems to lead to contexts being changed in ways they shouldn't be.  For example:

context iaxtel-outbound {
   _91700NXXXXXX => Dial(IAX2/iaxtel/${EXTEN:1}@iaxtel);
}

context iaxtel-inbound {
   s => {
       Wait(2);
       Answer();
       goto voip-inbound|s|1;
   }
}  

when loaded into a patched asterisk server yields the following when "dialplan show" is run:

[ Context 'iaxtel-inbound' created by 'pbx_ael' ]
 's91700NXXXXXX' => 1. Wait(2)                                    [pbx_ael]
                   2. Answer()                                   [pbx_ael]
                   3. Goto(voip-inbound|s|1)                     [pbx_ael]

[ Context 'iaxtel-outbound' created by 'pbx_ael' ]
 '_91700NXXXXXX' => 1. Dial(IAX2/iaxtel/${EXTEN:1}@iaxtel)        [pbx_ael]

This pattern continues throughout the rest of the contexts in my dialplan.  Essentially, the first parsed extension seems to fill a buffer with "_91700NXXXXXX" and every context/extension later just reuses the same buffer, giving me extensions like:

s91700NXXXXXX (s91700NXXXXXX)
_393.2NXXXXXX (_393.)
s393.2NXXXXXX (s)
v393.2NXXXXXX (v)
s393.2NXXXXXX (s)
ASTERISK-390.2NXXXXXX (#)

I'm not much of a C programmer, but I'm confused with your call to strncpy().  Shouldn't:

strncpy(cp2,cp1,strlen(cp2));

instead be:

strncpy(cp2,cp1,count);

Unfortunately though, making that change and recompiling with it doesn't seem to have any effect.
By: Chris Tracy (adiemus) 2007-08-09 23:29:30

Ahh, I didn't realize that there are now two functions named:

pbx_substitute_variables_helper

I'd been trying to mod the one in utils/ael_main.c instead of seeing that pbx_ael.c was using the one in main/pbx.c.  Anyway, the comments for that function state that it assumes cp2 is zero-filled.  Since the call to pbx_substitute_variables_helpe() inside of add_extensions() takes place in a do/while loop, the realext string never gets zeroed out, leading to the behavior described.

Since I didn't want to muck with pbx_substitute_variables_helper, I simply added the following to the top of the do/while in add_extensions():

memset(realext, '\0', sizeof(realext));

With this mod to your patch, the contexts/extensions interpolate properly and otherwise behave as I'd expect.
By: Thiago Garcia (thiagarcia) 2007-08-13 16:36:17

The patch caused issues for me.
Does not it find the context.
If I rever the pbx_ael.c to revision 67526 the issue does not occur.

NOTICE[7120]: chan_iax2.c:7456 socket_process: Rejected connect attempt from 192.168.248.6, request '9614@trunk-fns' does not exist

[Aug 13 18:35:59] WARNING[4731]: app_macro.c:214 _macro_exec: Context 'macro-ramais-filiais' for macro 'ramais-filiais' lacks 's' extension, priority 1
By: Steve Murphy (murf) 2007-08-14 09:25:52

Patch, applied to 1.4 in 79255
             and the memset was also added in 79363 to 1.4
To trunk, 79392

Many thanks to adiemus for his help in reporting, testing, and feedback!
By: Steve Murphy (murf) 2007-08-14 09:39:48

Oh, for the standalone aelparse, I created a dummy variable-helper function, that just copies the input to the output. This should suffice for standalone applications. I **could** make it verify that any variables mentioned should be defined in the globals, but this will have to be in the enhancements list.
By: Steve Murphy (murf) 2007-08-14 09:41:44

thiagarcia-- try an svn update and I'll bet your problems will disappear. Sorry for the inconvenience.