[asterisk-bugs] [Asterisk 0010411]: Variables in AEL2 context names

noreply at bugs.digium.com noreply at bugs.digium.com
Thu Aug 9 22:13:47 CDT 2007


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10411 
====================================================================== 
Reported By:                adiemus
Assigned To:                murf
====================================================================== 
Project:                    Asterisk
Issue ID:                   10411
Category:                   PBX/pbx_ael
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.9  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             08-08-2007 18:04 CDT
Last Modified:              08-09-2007 22:13 CDT
====================================================================== 
Summary:                    Variables in AEL2 context names
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 at 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)
====================================================================== 

---------------------------------------------------------------------- 
 adiemus - 08-09-07 22:13  
---------------------------------------------------------------------- 
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)
http://bugs.digium.com/view.php?id=393.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. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
08-09-07 22:13  adiemus        Note Added: 0068693                          
======================================================================




More information about the asterisk-bugs mailing list